Backblaze 的 2021Q1 硬碟報告

Backblaze 昨天放出來 2021Q1 的硬碟報告:「Backblaze Drive Stats for Q1 2021」。

前半部沒有什麼意外,HGST 的硬碟比起其他家的看起來還是好不少。

比較有趣的是首次拿 SSD 與 HDD 對決,這邊比較的對象是開機碟。可以看到如果以 2021Q1 的時間來看,SSD 的 AFR 低不少:

拉長到 lifetime 來看也還是低不少:

但裡面也有提到 HDD 的最大壽命比目前 SSD 都高不少,時間看起來可能還不夠長,算是一個很初步的資料...

Backblaze 在 2020 年對機械硬碟的回顧

前幾天 Backblaze 放了 2020 年的回顧資料出來:「Backblaze Hard Drive Stats for 2020」。

整體的 AFR (Annualized Failure Rate) 在 0.93% 左右,而如果照品牌拆開,HGST 的數字依然是最漂亮的 (雖然他現在是 WD 的品牌),大約在 0.36% 左右 (111/(1083774+4663049+372000+820272+275779+3968475)),Toshiba 次之,大約低了平均值一些落在 0.89%,而 Seagate 光是看就就知道會超過 1%...

官方有提到,低於 250,000 drive days 以下的數據僅供參考,因為資料量太少,在統計上無法提供結論:

For drives which have less than 250,000 drive days, any conclusions about drive failure rates are not justified. There is not enough data over the year-long period to reach any conclusions. We present the models with less than 250,000 drive days for completeness only.

然後 WD 本家的硬碟回到戰線了,記得之前基本上算是被唾棄 XDDD

另外一張表則是講到這三年的情況,可以看出來 2020 年的 AFR 數字降了不少,裡面也解釋了為什麼 (看起來就是活下來的穩下來了...):

The answer: It was a group effort. To start, the older drives: 4TB, 6TB, 8TB, and 10TB drives as a group were significantly better in 2020, decreasing from a 1.35% AFR in 2019 to a 0.96% AFR in 2020. At the other end of the size spectrum, we added over 30,000 larger drives: 14TB, 16TB, and 18TB, which as a group recorded an AFR of 0.89% for 2020. Finally, the 12TB drives as a group had a 2020 AFR of 0.98%. In other words, whether a drive was old or new, or big or small, they performed well in our environment in 2020.

Kubernetes 的失敗案例

有人把 Kubernetes (通常縮寫成「K8S」) 的失敗案例 (轉移失敗、爛掉、...) 整理到 GitHub 上:「Kubernetes Failure Stories」,裡面有文章也有演講影片,然後也有重複的公司在不同時間點說明。

先來講 K8S 好了,如果要粗略的解釋 K8S 是什麼東西,我會說就像是架一組 AWS 服務起來,但是是基於 container 而非 VM。

拿 AWS 的詞彙來說,他在上面疊了一層 Amazon VPC (會對應到 Kubernetes 的 overlay network 與 CNI),然後也提供 AMI (透過 Docker Image) 與 EC2 (因為是比喻,這邊就拿 AMI + EC2 來對比),還有基本的 ELB (各種 NodePort、HostPort 與 Ingress) 與 Service Discovery。

比較特別的是 Pod 的概念,在一般的雲上不太會看到。

不過大致上你可以想像這是一個小型的 AWS,而試著去猜測管理一個小型的 AWS 會需要了解多少底層知識,加上 K8S 一直在發展,很多功能可能都還不成熟 (所以用起來會覺得設計很奇怪),然後上面整理出的失敗案例就不意外了... XD

如果你是自己有機房,或是用便宜的 VPS (像是 LinodeDigitalOceanVultr),那麼我覺得在上面堆 K8S cluster 還算合理,畢竟你可以透過 K8S 幫你整合不少以前得自己架設的服務。

但如果你是已經在 Cloud 上面,然後還想在上面跑 K8S cluster,我是覺得還是要有個理由 (不管是技術上或是政治上的)。如果只是因為 K8S 潮到出水而用的話,可能過一個月後你家就淹水了 XD

另外講一些題外話,因為最近弄 Kubernetes 的關係 (可以參考我的筆記「Kubernetes」),才能理解為什麼 Linode 這些 VPS 會推出 load balancer 與 block storage,算是後知後覺...

AWS 提供模擬 Amazon Aurora 異常的測試功能...

Twitter 上看到 Jeff Barr 提到了在 Amazon Aurora 上的模擬 (這邊應該是講 MySQL):

指到的頁面是文件「Managing Amazon Aurora MySQL - Amazon Relational Database Service」,翻了一下 Wayback Machine,看起來之前就有了,只是現在拿出來再宣傳一下:「Managing Amazon Aurora MySQL - Amazon Relational Database Service」。

透過主動觸發 Amazon Aurora 異常,可以測試整個系統的後續反應:

  • A crash of the master instance or an Aurora Replica
  • A failure of an Aurora Replica
  • A disk failure
  • Disk congestion

前面三種都屬於 Aurora 本身的故障測試,第四種除了有可能是 Aurora 本身的問題外,也可以測壓力過大時的情境 (i.e. 前面透過 auto scaling 撐住了,但後面的資料庫可能沒有足夠的能力支撐)。

Backblaze 2017Q1 對硬碟的分析

Backblaze 放出 2017Q1 對硬碟的分析資料:「Hard Drive Stats for Q1 2017」。

相較於之前的報告 (Backblaze Hard Drive Stats for 2016),這次則是把硬碟數量考慮進去,做了一份有正負誤差的:

最近的趨勢沒什麼變,整體上來看 HGST 的品質還是最好的。

Backblaze 分析了 2015 年的硬碟故障比率

照慣例,Backblaze 每隔一段時間就會公佈最近的硬碟死亡率,在「Hard Drive Reliability Review for 2015」的這張圖好像說明了不少事情:

不過分開各個容量來看,又有一些不同的地方...

Backblaze 2015 年上半年的硬碟穩定度報告出爐了... (又黑了某公司一把)

Backblaze 這次丟出了 2015 年上半年的數據,標題雖然是寫 2015Q2,但文章裡有半年的統計資料:「Hard Drive Reliability Stats for Q2 2015」。

雖然都知道某公司的產品故障率偏高,但這樣是有仇嗎 XDDD

這是統計資料:

另外是 4TB 的歷史紀錄,右邊兩家的數字有點少啊,不過 45 顆硬碟壞一顆不就 2.x% 了嗎,這數字到底是怎麼出來的啊:

Facebook 因為 Connection Pool 選擇機制,加上系統的複雜性而導致的慘案...

Facebook 的 engineer 寫了一篇文章,說明他們花了超過兩年的時間找到一個 bug:「Solving the Mystery of Link Imbalance: A Metastable Failure State at Scale」。

整個故事是個通靈的故事...

Facebook 在底層的架構使用了 Link Aggregation 的規劃,多條線路 channel bonding 在一起連到骨幹上。但發現有時候會卡在某一條線路壅塞而導致 system failure。

於是就一路追下去,從 switch 本身開始懷疑,最後去組織跨部門的研究小組跳下去分析 (通靈)。後來才觀察到是因為 connection pool 的機制本身用的演算法在 Facebook 這個複雜的系統架構下造成的慘案...

當 query burst 發生時,Facebook 的系統會同時到 50~100 組資料庫撈資料出來寫入 cache,而 connection pool 的機制用的是 MRU (Most Recently Used),從 congestion link 回來的 connection 會在 pool 裡面的最上方,於是就愈來愈塞...

知道問題後,解決的方法就簡單多了。只是把 connection 選擇演算法從 MRU 換成 LRU 後就解決了,但中間用了超過兩年的時間,以及至少 30 個人的努力才把問題找出來並且解決。

可以看到最後銘謝的對象一卡車:

Thanks to all of the engineers who helped us manage and then fix this bug, including James Paussa, Ernesto Ovcharenko, Mark Drayton, Peter Hoose, Ankur Agrawal, Alexey Andreyev, Billy Choe, Brendan Cleary, JJ Crawford, Rodrigo Curado, Tim Eberhard, Kevin Federation, Hans Fugal, Mayuresh Gaitonde, CJ Infantino, Mark Marchukov, Chinmay Mehta, Murat Mugan, Austin Myzk, Gaya Nagarajan, Dmitri Petrov, Marco Rizzi, Rafael Rodriguez, Steve Shaw, Adam Simpkins, David Swafford, Wendy Tobagus, Thomas Tobin, TJ Trask, Diego Veca, Kaushik Veeraraghavan, Callahan Warlick, Jason Wilbanks, Jimmy Williams, and Keith Wright.

最後附上 Facebook 解釋的圖:

前幾天 Gmail 收信延遲的問題...

前幾天 Gmail 可以正常運作,但一直收不到信的問題由官方發公告出來解釋了:「More On Gmail’s Delivery Delays」。

官方宣稱,這次的問題出自於兩個獨立的網路同時掛掉,造成 Gmail 的收信處理能力大幅下降:

The message delivery delays were triggered by a dual network failure. This is a very rare event in which two separate, redundant network paths both stop working at the same time. The two network failures were unrelated, but in combination they reduced Gmail’s capacity to deliver messages to users, and beginning at 5:54 a.m. PST messages started piling up.

最後是十個多小時後完全恢復。