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.

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

RAID5 會遇到的 Multi-disk failure 問題

How multi-disk failures happen」這篇畫了不少圖解釋在 RAID5 上面偶而會遇到的 Multi-disk failure 問題 (RAID6 也會,風險比較低而已)。

RAID 5

平常壞軌時,RAID 系統不一定會發現,直到 RAID rebuild 時讀過所有的磁區,系統才發現其他壞軌,造成第二顆被標為損壞... (推論到 RAID6 的情況就是再發生一次)

這在 I/O 比較頻繁的 RAID 比較不容易發生 (因為在量小的時候就容易偵測到)。

對於比較閒的系統,應該放個 cron 跑 dd if=/dev/XXX of=/dev/null 嗎?:p