Tag: high

Canonical 推出的 Dqlite (High-Availability SQLite)

第一眼看到的時候直接有種不知道 Canonical 在幹什麼的感覺，翻完說明後大概知道可以用的地方，但還是覺得範圍有點小：「Dqlite - High-Availability SQLite」。

一種使用情境是，在 embedded system 上面同步資料的一種方案... 吧？例如網路連線的頻寬或是品質受限，無法順利傳到 Internet 端的伺服器上，所以希望在本地端就可以解決一些事情，但又不方便在本地端直接弄個 PostgreSQL 出來？

Dqlite is a fast, embedded, persistent SQL database with Raft consensus that is perfect for fault-tolerant IoT and Edge devices.

另外一個是用到了 C 實做的 Raft 協定：

Dqlite (“distributed SQLite”) extends SQLite across a cluster of machines, with automatic failover and high-availability to keep your application running. It uses C-Raft, an optimised Raft implementation in C, to gain high-performance transactional consensus and fault tolerance while preserving SQlite’s outstanding efficiency and tiny footprint.

讓 IoT 裝置參與 Raft 嗎... 好像只能說有趣... XD

加快 ls 的速度

看到「When setting an environment variable gives you a 40x speedup」這篇在講 ls 的速度。

文章是由 Stanford 的 Sherlock 發出來的，不過看起來跟電視劇沒關係，從網站上的標語「The HPC cluster for all your computing needs」可以看出是 HPC 相關的單位。

在 HPC 環境裡面可以預期單一目錄裡會有很多檔案，所以使用者跑來抱怨 ls 的速度就不算太意外了。不過這次使用者有提到在他自己的 laptop 上跑 ls 反而很快：

It all started from a support question, from a user reporting a usability problem with ls taking several minutes to list the contents of a 15,000+ entries directory on $SCRATCH.

Having thousands of files in a single directory is usually not very file system-friendly, and definitely not recommended. The user knew this already and admitted that wasn’t great, but when he mentioned his laptop was 1,000x faster than Sherlock to list this directory’s contents, of course, it stung. So we looked deeper.

直接跳到後面的結論... 原因是出自於因為需要顯示不同顏色，而需要透過 lstat() 查詢額外的檔案性質 (可執行、setuid 以及 setgid 這些資料)，導致速度變慢：

From 13s with the default settings, to 0.3s with a small LS_COLORS tweak, that’s a 40x speedup right there, for the cheap price of not having setuid/setgid or executable files colorized differently.

Of course, this is now setup on Sherlock, for every user’s benefit.

透過設定 LS_COLORS='ex=00:su=00:sg=00:ca=00:'，可以讓 lstat() 消失，所以被放進 Sherlock 的預設值了... 而沒有遇到這個問題的環境 (像是有設計好對應的目錄結構)，或是想要維持原來的樣子的人，則可以 unset 掉這個值讓輸出還是有色彩差異 :o

JPMorgan Chase 的 WePay 用的 MySQL 架構

看到「Highly Available MySQL Clusters at WePay」這篇講 WePay 用 MySQL 的設計，本來以為是 WeChat 的服務，仔細看查了之後發現原來是 JPMorgan Chase 的服務...

架構在 GCP 上面，本來的 MySQL 是使用 MHA + HAProxy (patch 過的版本，允許動態改變 pool)，然後用 Routes 處理 HAProxy 的 failover。

他們遇到的問題是 crash failover 需要至少 30 分鐘的切換時間，另外就是在 GCP 上面跨區時會有的 network partition 問題...

後續架構變得更複雜，讓人懷疑真的有解決問題嗎 XDDD

改用 GitHub 推出的 Orchestrator 架構，然後用兩層 HAProxy 導流 (一層放在 client side，另外一層是原來架構裡面的 load balancer)，在加上用 Consul 更新 HAProxy 的資訊？

思考為什麼會有這樣設計 (考慮到金融體系的背景)，其實還蠻有趣的...

在 MySQL 上遇到 Replication Lag 的解法

看到 Percona 的 blog 上寫了一篇 MySQL 遇到 replication lag 時要怎麼解決：「MySQL High Availability: Stale Reads and How to Fix Them」，另外在留言也有人提到 Booking.com 的解法：「How Booking.com avoids and deals with replication lag」。

在業務成長到單台 MySQL server 不夠用的情況下，最簡單的擴充方式是架設 slave server，然後把應用程式裡讀取的部份導到 slave 上 (也就是 R/W split)，但因為 MySQL 的 replication 是非同步的，所以有可能會發生在 master 寫入資料後 slave 還讀不到剛剛寫的資料，也就是 replication lag。

這就大概有幾種作法，一種是當發現 lag 時就回 master 讀，但通常這都會造成 master 過載... 所以另外一種改善的作法是發現 lag 時就換其他 slave 看看，但這個方法就不保證讀的到東西，因為有可能所有的 slave 都 lag。

以前遇到的時候是拆情境，預設還是 R/W split，但敏感性的資料處理以及金流相關的資料就全部都走 master。

不過文章裡的解法更一般性，在寫入時多寫一份資料，然後在 slave 等這組資料出現。唯一的缺點就是要 GC 把多寫的資料清掉...

同樣的想法，其實可以讓 MySQL 在 commit 時直接提供給 binlog 或 GTID 的資訊，然後在 slave 等待這組 binlog 或 GTID 被執行。

看起來算是很不錯的解法，不知道各家 framework 對這些方式的支援度如何...

Amazon Aurora Global Database

AWS 對 Aurora (MySQL) 推出 Amazon Aurora Global Database：「Announcing Amazon Aurora Global Database」。

看起來不是 multi-master (從 secondary region 這個字看)，所以寫入的部分還是得送回 primary region 處理：

Aurora Global Database uses storage-based replication with typical latency of less than 1 second, using dedicated infrastructure that leaves your database fully available to serve application workloads. In the unlikely event of a regional degradation or outage, one of the secondary regions can be promoted to full read/write capabilities in less than 1 minute.

應該是單一 endpoint 幫你處理這些雜事...

CloudFront 十週年、在東京的第十個 PoP，以及支援 WebSocket 與 Origin Failover

CloudFront 宣佈十年了，另外這次在東京又加節點了，變成 10 個：「Celebrating the 10 year anniversary of Amazon CloudFront by launching six new Edge locations」。

另外宣佈支援 WebSocket：「Amazon CloudFront announces support for the WebSocket protocol」，以及支援 Origin Failover：「Amazon CloudFront announces support for Origin Failover」。

WebSocket 算是大家等蠻久的功能，大家主要是希望利用 CloudFront 擋 DDoS，正常流量才往後丟。而 Origin Failover 則是可以設定兩個 Origin，當主要的掛掉時可以切到備用的，對於支援多節點的架構算是第一步 (目前看起來只能設兩個)：

With CloudFront’s Origin Failover capability, you can setup two origins for your distributions - primary and secondary, such that your content is served from your secondary origin if CloudFront detects that your primary origin is unavailable.

都是隔壁棚 Cloudflare 支援許久的功能... 算是補產品線與進度？

在家裡 (???) 建立 HA 的網路環境...

Brad Fitzpatrick 在他家裡弄的 HA 架構，對一般人來說是有點誇張了 (看起來主要還是玩得開心)，但對網路公司來說是個可以參考的方式，降低網路與設備故障帶來的業務衝擊... 先前在弄辦公室連外網路時也有弄過類似的架構，還蠻有趣的。

然後發現原來西雅圖的電這麼便宜，一度大約 NTD$3：

The whole setup including all APs and switches draws about 220 watts idle. Power is pretty cheap in Seattle. Washington State (as of April 2018) has the cheapest electricity in the United States, at $0.0974/kWh.

其他技術的東西反而是看看而已 XD

EC2 的 Dedicated Instance 也支援 Auto Recovery 了...

所以除了一般的 EC2 instance 可以設定 Auto Recovery 外，實體機的 Dedicated Instance 也可以設定了：「Amazon EC2 Auto Recovery is now available for Dedicated Instances」。

不過能用架構做 High Availability 還是用架構做會比較好 (像是透過 ELB 擋在前面提供服務)，Auto Recovery 因為是透過 CloudWatch 偵測 (目前最短的偵測時間應該是 10 秒一次)，再加上要等新機器接手，還是會有明顯的 downtime。

Avast 放出他們的 Decompiler，RetDec

Avast 以 MIT License 放出他們的 Decompiler，叫做 RetDec：「Avast open-sources its machine-code decompiler」，專案在 GitHub 上的 avast-tl/retdec 這邊。

Decompiler，也就是直接把 machine code 試著轉回高階語言的程式碼：

這對於分析工作來說簡化很多，尤其是在資安產業的人... 以往比較常見是轉成 assembly 再用人工分析，現在這樣有機會讓大腦輕鬆一些。

雖然目前有些限制 (像是 32 bits only)，不過 open source 出來後，可以預料會有不少人開始加功能進去：

  • Supported file formats: ELF, PE, Mach-O, COFF, AR (archive), Intel HEX, and raw machine code.
  • Supported architectures (32b only): Intel x86, ARM, MIPS, PIC32, and PowerPC.

Cloudflare 新推出的 Geo Key Manager

Cloudflare 對新推出的 Geo Key Manager 寫了兩篇文章說明：「Introducing the Cloudflare Geo Key Manager」、「Geo Key Manager: How It Works」。

這個服務是之前推出的 Keyless SSL 的延伸應用。

Keyless SSL 是將 Private Key 放在自己家，透過加密協定讓 Cloudflare 使用 (有點像是 HSM 的概念，也就是 Hardware security module，不讓應用的人存取到 Private Key)。這次推出的 Geo Key Manager 則是取中間值，希望針對效率與 High Availability 做出改善。

改善的方法還是將 Private Key 上傳到 Cloudflare 裡，但不是 Cloudflare 所有的機房，而是讓使用者挑選某些風險比較低的地區。

像是只放在美國，或是只放在歐盟，或是以安全度來選擇：

這其實是不信任政府單位而設計出來的系統，雖然效果如何還不知道...