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.

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

FreeBSD 的 Amazon EC2 Image 打算自動使用本機空間當作 Swap

Twitter 上看到 Colin Percival 說計畫將 FreeBSD EC2 image (AMI) 自動偵測並使用 ephemeral disk 的空間當作 swap:

就算是使用 EBSgp2 或是 gp3,甚至是其他 VPS,我也很習慣開一點點的 swap 空間來用 (通常是用 file swap 的方式開 512MB,無論記憶體有多大),這算是我自己的 best practice 了,這可以把一些完全沒用到的 daemon 塞進 swap。

不過對於已經把 ephemeral disk 規劃拿來用的人可能會不太開心,需要去改設定...

Backblaze 的 2021 年硬碟死亡報告

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

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

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

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

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

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

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

用 Ephemeral Storage 加速 MySQL over ZFS 的效能

Percona 的「MySQL/ZFS in the Cloud, Leveraging Ephemeral Storage」這篇裡面在探討是不是可以看看 ZFS 在 Ephemeral Storage (機器附的本地硬碟) 上的效能。

一開始測試是直接當主力硬碟來測,可以看到跑 ZFS 的情況下,本地的 storage 還是會比 SSD Premium (這是 Azure 的產品線) 還快不少:

但把資料放在本地的 storage 上其實有點刺激,至少在 production 應該不太會這樣搞,所以後面用 L2ARC 的方式來測,可以看到效率提昇相當明顯,甚至接近本來直接把資料放在本地的 storage:

另外測了 ext4/bcache,看起來效率就沒那麼好:

這樣看起來是個不錯的選擇...

Amazon EC2 上的一些小常識

Twitter 上看到 Laravel News 轉發了「Mistakes I've Made in AWS」這篇,講 Amazon EC2 上面的一些小常識。

在 EC2 中,T 系列的機器 (目前主要是 t2/t3/t3a/t4g) 對於開發很好用,甚至對於量還不大的 production system 也很好用,加上 Unlimited 模式可以讓你在 CPU credit 用完時付錢繼續 burst。

文章裡面有討論到,使用 T 系列機器時,常常是不怎麼需要大量 CPU 資源的情境,這時候 AMD-based 的 t3a 通常都是個還不錯的選擇,大概會比 Intel-based 的 t3 省 10% 的費用。另外如果可以接受 ARM-based 的話,t4g 也是個選項,價錢會更便宜而且在很多應用下速度會更快。不過同事有遇到 Python 上面跑起來的行為跟 x86-64-based 的不同,這點就得自己琢磨了...

另外就是目前的 EBS 預設還是會使用 gp2,而在 gp3 出來後其實大多數的情況下應該可以換過去,主要就是便宜了 20%,加上固定的 3000 IOPS。

不過也是有些情境下是不應該換的,主要是 gp2 可以 burst 到 250MB/sec,但 gp3 只給了 125MB/sec。雖然 gp3 可以加價買 throughput,但加價的費用不低,這種需求改用 gp2 應該會比較划算。

不過這邊推薦比較技術的作法,可以掛兩個 gp3 (也可以更多) 跑 RAID0 (像是在 Linux 上可以透過 mdadm 操作),這樣 IOPS 與 throughput 都應該可以拉上來...

AWS 宣佈 EBS io2 的新花樣 Block Express Volumes

看到「AWS Announces General Availability of Amazon EBS io2 Block Express Volumes」這篇,在 EBSio2 上面又推出了新的花樣 Block Express Volumes:

Today AWS announced general availability of io2 Block Express volumes that deliver up to 4x higher throughput, IOPS, and capacity than io2 volumes, and are designed to deliver sub-millisecond latency and 99.999% durability.

要再提供更高的效能,在 R5b 的機種下,單個 volume 可以拉到 256k IOPS 與 4000MB/sec 的傳輸速度,以及在 well-tuned 的環境下 (應該是多個 volume) 可以拉到 260k IOPS (多一點點) 與 7500MB/sec (將近原來的兩倍) 的傳輸速度:

Using R5b instances customers can now provision a single io2 volume with up to 256,000 IOPS, 4000 MB/s of throughput, and storage capacity of 64 TiB.

R5b instances are well-suited to run business-critical and storage-intensive applications as they offer the highest EBS-optimized performance of up to 260,000 IOPS and 7,500 MB/s throughput.

是個用錢炸效能的東西,用的到的就用...

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.