Backblaze 釋出 2023Q2 的硬碟報告

Backblaze 釋出了 2023Q2 的硬碟報告:「Backblaze Drive Stats for Q2 2023」。

看硬碟數量有破千顆的會比較準確,跟以前的趨勢差不多,HGST 與改牌到 WDC 的硬碟在第一梯隊,再來是 Toshiba,然後是 Seagate

特別被拿出來講的是 0% 死亡率的:

前面三顆 Drive Days 都夠高,還可以維持 0% 死亡率,算是可以選擇的型號?

另外比較特別的是 8TB 與 10TB 硬碟的死亡率比平均值高不少,不過文章裡面有提到 10TB 因為量太少所以跳過 (可能還在統計誤差的範圍):

Given there are relatively few 10TB drives (1,124) versus 8TB drives (24,891), let’s dig deeper into the 8TB drives models.

而 8TB 的資料可以看到這幾顆的狀況:

這邊算是提供要避開的型號?

Backblaze 的 SSD failure rate 資料

Backblaze 整理了 SSD failure rate 的資料:「The SSD Edition: 2022 Drive Stats Review」,裡面比較有興趣的是歷史資料這部份:

SSD 用在系統碟的關係,數量沒像 HDD 那麼多,所以有些信心區間的值會差異很大。

裡面比較亮眼的是 DELLBOSS VD,用的數量不算少,而且看平均使用時間應該是比 MX500 多了一倍多,但都還沒有掛掉的記錄,所以 failure rate 就算是信心區間的上限值都還是很漂亮。

然後用最多得是 Seagate 的 SSD,平均使用時間又比 Dell 那批更長了。

Backblaze 對 SSD 存活率的報告

Backblaze 發了一篇對 SSD 存活率的報告:「The SSD Edition: 2022 Drive Stats Mid-year Review」,報告分成兩大塊,一塊是單講 SSD 的,另外一塊是跟傳統磁頭硬碟 HDD 比較。

首先是這張總表,從 2018 年到現在的 SSD 硬碟的 AFR 資料:

可以看到有特地標出信賴區間,因為對於某些量真的太少的型號,算出來的 AFR 沒有太大意義,所以重點只有在幾個數量比較多的型號。

Seagate 的 ZA250CM10003 最多,AFR 是 0.70% (CI 在 0.3%-1.3%);接下來是 Seagate 的 ZA250CM10002,AFR 是 0.78% (CI 在 0.4%-1.4%)。

第三多的是 Dell 的 DELLBOSS VD,AFR 是 0% (CI 在 0.0%-0.8%),不過要注意這是 M.2 界面,而且是 server 等級:

It is a server-class drive in an M.2 form factor, but it might be out of the price range for many of us as it currently sells from Dell for $468.65.

接下來是比較 SSD 與 HDD。這邊的比較中,兩者都是相同的用途 (開機碟 & 系統碟):

The SSDs and HDDs we are reporting on are all boot drives. They perform the same functions: booting the storage servers, recording log files, acting as temporary storage for SMART stats, and so on.

因為 SSD 目前只有五年的記錄,可以看到如果只比較五年的話,SSD 的 AFR 是比 HDD 好上不少的:

不過這邊還是以機房環境來說明,像是機櫃的振動與使用的 pattern 都是可以想到的因素。一般的情況下,如果沒有一堆 HDD 在 JBOD 裡面振動的話,是不是可以活比較久就不知道了...

但現在開機碟用 HDD 應該也會開到天花地老,好像也沒有什麼特別的理由會換回 HDD...

Backblaze 的 2022 Q2 硬碟報告

Backblaze 發表了 2022 Q2 硬碟使用的報告:「Backblaze Drive Stats for Q2 2022」。

第一張是綜合性的資料,從 2013 年到現在還活著的型號都拉出來:

表格裡面好像有些錯誤的地方,像是 SeagateST12000NM0007 這顆的數字就對不太起來,1288 顆但是有 1989 次的 failure,另外 drive days 累計有 35,823,850 days,平均下來是 27813 天 (76 年?),另外 AFR 只有 2.03% (低 1.90%,高 2.10%)。

就算硬碟數量多一個零變成 12880 顆也還是對不太起來,查 datasheet 看起來這個型號是 2017 年出的,到現在也才五年多,76 年的 1/10 變成 7.6 年也對不起來,這個部份看後續會不會更正好了...

另外作者另外把比較有指標性的型號拉出來,可以看到 HGST 在歷史上的表現很好:

然後就算只過濾 2022 Q2 的故障資料,還是可以看到 HGST 在近期的 AFR 表現很不錯:

另外最後提到他會在 DEFCON 30 上聊聊:

If you will be at DEFCON 30 in Las Vegas, I will be speaking live at the Data Duplication Village (DDV) at 1 p.m. on Friday, August 12th. The all-volunteer DDV is located in the lower level of the executive conference center of the Flamingo hotel. We’ll be talking about Drive Stats, SSDs, drive life expectancy, SMART stats, and more. I hope to see you there.

Hacker News 前幾天炸很久的 root cause

前幾天 Hacker News 炸了很久,如果是從 Twitter 上的資料來看,是從 2022/07/08 14:08 UTC 這篇:

中間還原失敗 (2022/07/08 17:35 UTC):

到最後恢復 (2022/07/08 20:48 UTC):

Twitter 這邊的資料看起來差不多是六個小時多,以一個應該是只有 database 需要還原的站台來說的確是蠻久的,所以後續在「HN is up again」這邊就有在討論原因,裡面 HN 的老大 dang 也有提到 downtime 是七個小時多:

8 hours of downtime, but not data loss, since there was no data to lose during the downtime.

Last post before we went down (2022-07-08 12:46:04 UTC): https://news.ycombinator.com/item?id=32026565

First post once we were back up (2022-07-08 20:30:55 UTC): https://news.ycombinator.com/item?id=32026571 (hey, that's this thread! how'd you do that, tpmx?)

So, 7h 45m of downtime. What we don't know is how many posts (or votes, etc.) happened after our last backup, and were therefore lost. The latest vote we have was at 2022-07-08 12:46:05 UTC, which is about the same as the last post.

There can't be many lost posts or votes, though, because I checked HN Search (https://hn.algolia.com/) just before we brought HN back up, and their most recent comment and story were behind ours. That means our last backup on the ill-fated server was taken after the last API update (HN Search relies on our API), and the API gets updated every 30 seconds.

I'm not saying that's a rock-solid argument, but it suggests that 30 seconds is an upper bound on how much data we lost.

另外大家就在找 dang 的回應是什麼 (畢竟是第一手資料),用 Ctrl-F 找一下就看到有趣的猜測,從 32028511 這個節點可以看到這串有趣的討論,首先是 mikeiem

You are never going to guess how long the HN SSDs were in the servers... never ever... OK... I'll tell you: 4.5years. I am not even kidding.

然後是 kabdib 的回應:

Let me narrow my guess: They hit 4 years, 206 days and 16 hours . . . or 40,000 hours.

And that they were sold by HP or Dell, and manufactured by SanDisk.

Do I win a prize?

(None of us win prizes on this one).

接著就是 dang 說他覺得這個猜測很有可能:

Wow. It's possible that you have nailed this.

Edit: here's why I like this theory. I don't believe that the two disks had similar levels of wear, because the primary server would get more writes than the standby, and we switched between the two so rarely. The idea that they would have failed within hours of each other because of wear doesn't seem plausible.

But the two servers were set up at the same time, and it's possible that the two SSDs had been manufactured around the same time (same make and model). The idea that they hit the 40,000 hour mark within a few hours of each other seems entirely plausible.

Mike of M5 (mikiem in this thread) told us today that it "smelled like a timing issue" to him, and that is squarely in this territory.

後續他也從自家的 /newest 裡面撈了相關的資料出來,依照他撈出來的關鍵字,看起來是用 HPE 出的 SSD:

It's also an example of the dharma of /newest – the rising and falling away of stories that get no attention:

HPE releases urgent fix to stop enterprise SSDs conking out at 40K hours - https://news.ycombinator.com/item?id=22706968 - March 2020 (0 comments)

HPE SSD flaw will brick hardware after 40k hours - https://news.ycombinator.com/item?id=22697758 - March 2020 (0 comments)

Some HP Enterprise SSD will brick after 40000 hours without update - https://news.ycombinator.com/item?id=22697001 - March 2020 (1 comment)

HPE Warns of New Firmware Flaw That Bricks SSDs After 40k Hours of Use - https://news.ycombinator.com/item?id=22692611 - March 2020 (0 comments)

HPE Warns of New Bug That Kills SSD Drives After 40k Hours - https://news.ycombinator.com/item?id=22680420 - March 2020 (0 comments)

(there's also https://news.ycombinator.com/item?id=32035934, but that was submitted today)

這次 downtime 看起來很像是中了 SSD firmware bug,目前看起來先搬到 EC2 上面了:

$ host news.ycombinator.com
news.ycombinator.com has address 50.112.136.166
$ host 50.112.136.166      
166.136.112.50.in-addr.arpa domain name pointer ec2-50-112-136-166.us-west-2.compute.amazonaws.com.

看討論串應該是暫時性的?

Backblaze 的 2021 年硬碟死亡報告

Backblaze 放出 2021 年的硬碟統計數據了:「Backblaze Drive Stats for 2021」。

最後一張圖是 Backblaze 機房內還活著的硬碟資訊,大概是整篇裡面最有用的 (而且有 AFR 的信心區間),先拉出來看:

比較好奇的是還沒有導入 18TB 的硬碟...

另外從上面依照廠牌分類的部份也可以看出個感覺,這時候如果再針對各廠牌的歷史記錄拉出圖的話就很殘酷了,要說 Seagate 不愧是 Seagate 嗎 (大家的刻板印象好像也不刻板了,數字都對的上...):

如果就廠牌可以看出來 HGST 不論哪個型號,死亡率 (AFR) 都很低,而 Toshiba 與 Seagate 則是很吃型號,有的型號 AFR 很高,但有的就蠻低的...

另外裡面有提到一個比較有趣的現象,大顆硬碟的 AFR 反而比較低,目前猜測是新硬碟的關係,但時間要拉長才會看的比較明顯,不確定是不是有什麼技術發展出來 (過個幾年再回來看的意思):

話說前陣子才送修一顆 Seagate 的硬碟回來 (還在保固內),SMR 的死亡率果然高不少...

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 撐住了,但後面的資料庫可能沒有足夠的能力支撐)。