RAID6 的 Erasure code 實作

Daily Hacker News 上看到的紋章,「Erasure Coding for Distributed Systems」這篇討論了 Erasure code

以前在學校裡面學 coding theory 的時候有學到一些經典的演算法,尤其是一定會教到 Reed-Solomon error correction 這個演算法,不過實務上 Reed-Solomon 因為用到 finite field 運算 (又稱 Galois field,所以簡寫常用 GF),所以效率並不算好,在 RAID 系統上面除非 controller 的 CPU 或是晶片對 GF 運算加速,不然大多都會用替代算法。

For the special cases of 1-3 parity chunks (m \in {1,2,3}), there are algorithms not derived from Reed-Solomon and which use only XORs:

允許掛一顆的演算法就是 RAID 5,這邊用 XOR 就很容易導出來,並且分析證明。

開始有難度的是允許掛兩顆的演算法,也就是一般熟知的 RAID 6,在這篇文章裡面提到了好幾個演算法,不過有些有專利問題:

m=2 is also known as RAID-6, for which I would recommend Liberation codes[8][9] as nearly optimal with an implementation available as part of Jerasure, and HDP codes[10] and EVENODD[11] as notable but patented. If k+m+2 is prime, then X-Codes[12] are also optimal.

允許掛三顆的則是提到 STAR coding:

m=3 can be done via STAR coding

算是留個記錄好了,這些演算法又讓我想到先前剛進 Migo 的時候還學到 Raptor code,但使用場景不對反而遇到問題,又是另外一個故事了...

回到開頭的 Reed-Solomon,會印象很深還是因為當初在數學系的集合論學了 finite field 好幾年後,在資工系第一次看到居然可以用 finite field 解決這個問題...

Linux 6.2 的 Btrfs 改進

Hacker News 上看到 Btrfs 的改善消息:「Btrfs With Linux 6.2 Bringing Performance Improvements, Better RAID 5/6 Reliability」,對應的討論在「 Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability (phoronix.com)」這邊。

因為 ext4 本身很成熟了,加上特殊的需求反而會去用 OpenZFS,就很久沒關注 Btrfs 了,這次看到 Btrfs 在 Linux 6.2 上的改進剛好可以重顧一下情況。

看起來是針對 RAID 模式下的改善,包括穩定性與效能,不過看起來是針對 RAID5 的部份多一點。

就目前的「情勢」看起來,Btrfs 之所以還是有繼續被發展,主要還是因為 OpenZFS 的授權條款是 CDDL,與 Linux kernel 用的 GPLv2 不相容,所以得分開維護。

但 OpenZFS 這邊的功能性與成熟度還是比 Btrfs 好不少,以現階段來說,如果架構上可以設計放 OpenZFS 的話應該還是會放 OpenZFS...

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 都應該可以拉上來...

Netflix 把金流相關的系統轉移到 AWS 上跑 MySQL 的故事...

這次要提的是「Netflix Billing Migration to AWS」、「Netflix Billing Migration to AWS - Part II」與「Netflix Billing Migration to AWS - Part III」這三篇。

Netflix 先前的金流相關系統跑的是 Oracle 的資料庫:

然後換成 MySQL

系統上是採用 DRBD,然後底層是 5 個 4TB 的 EBS 組成的 RAID 0,跑 LVM

High performance with respect to reads and writes was achieved by using RAID0 with EBS provisioned IOPS volumes. To get more throughput per volume, 5 volumes of 4TB each were used, instead of 1 big volume. This was to facilitate faster snapshots and restores.

LVM to manage two Logical Volume’s (DB and DRBD Metadata) within single Volume Group.

可以看到裡面用的都是很經過時間考驗的技術,像是 DRBD、標準的 Replication 架構...

Etsy 用 SSD 的故事

EtsyLaurie Denness 對於 Etsy 使用各種品牌 SSD 的情況給出了他的經歷:「SSDs: A gift and a curse」。

重點在於開頭說的:

SSD firmware is buggy

可以看到當 SSD 配上 RAID controller 的時候,常常會需要找問題... (而且很難找)

Intel 的評價很不錯:

Okay, bad start, we’ve actually had no issues with Intel. This seems to be common across other companies we’ve spoken to.

OCZ 倒了,被 Toshiba 收購,而且 S.M.A.R.T. 資訊很差,很難預測什麼時候會掛掉 (有助於提前替換):

However, they had poor SMART info (none) so predicting failures was hard.

HP 是個大黑盒:

Unfortunately, HP have proprietary RAID controllers, and they don’t support SMART. Or rather, they refuse to talk to non-HP drives using off the shelf technology, they have their own methods.

Samsung 的評價不錯,C/P 值很高,而且有 S.M.A.R.T.:

Samsung saved the day and picked up from OCZ with a ludicrously cheap 960GB offering, the 840 EVO. A consumer drive, so very limited warranty, but for the price (~$400-500) you got great IOPS and they were reliable. They had better SMART info, and seemed to play nicely with our hardware.

不過 BB6Q 版的韌體搞爆了效能,雖然最後修好了:「Samsung Releases Firmware Update to Fix the SSD 840 EVO Read Performance Bug」。

LiteOn 則是掛在 GC 上 (RAID 裡同時掛掉兩顆以上):

The SSDs were having extended garbage collection periods, exacerbated by a smaller amount of SSDs with higher IO, in RAID6. This caused the controller to kick the drive out of the array… and unfortunately due to the write levelling across the drives, at least two of them were garbage collecting at the same time, destroying the array integrity.

不過後來 Dell 與 LiteOn 分別就 RAID controller 與 SSD 本身都跳下去修正,最後還是解決了:

Dell and LiteOn together identified and fixed weaknesses in their RAID controller, the backplane and the SSD firmware.

算是經驗分享,在 SSD 硬碟成熟的過程中間必經的道路 XD

Linux 上跑 ZFS

Linux 上可以跑 ZFS 的消息已經一陣子了,但在「71 TiB DIY NAS Based on ZFS on Linux」這篇看到有人跳下去玩還是覺得很特別... (大多還是看到 FreeBSD 或是 Oracle 的系統)

用的是 Debian Wheezy,文章裡沒提到是不是跑 OpenZFS,不過我猜應該是...

跑出來的效能相當好:

With a storage capacity four times higher than the original and an incredible read (2.5 GB/s)/write (1.9 GB/s) performance, it's a worthy successor.

約 6012 歐元,大約 23.5 萬台幣。

RAID 卡的電池維護

實際的世界都是由 workaround 疊 workaround 解決問題的...

MySQL 資料庫一般都用 RAID 10,利用 RAID 1 的特性保護資料,並且利用 RAID 0 的特性提昇 IOPS 能力。

而這些 RAID 卡通常都會提供 cache,預設應該都會開 read cache,可以大幅增加 random read 的速度。而另外也可以打開 write cache (也就是 write-back),寫入時先寫到 cache 裡,RAID 卡馬上就會跟作業系統回報完成,藉以加速 random write 的速度。

但這樣就會有風險,當資料還沒寫入硬碟就斷電時就會遺失資料。所以在設定 write-back 的 RAID 卡上安裝電池就變成解法之一。

而電池會有壽命問題,所以配電池的 RAID 卡會每隔一陣子就放電測試電池可以撐多久,但在放電測試時,如果斷電就有可能造成資料遺失,於是又冒出很多方法解決。

也就是在「Learning to Deal With Learning」這篇提到 RAID 卡電池維護的事情。

每一層都是 workaround 想辦法解決問題,然後再用 workaround 解決前面造成的問題...

Anyway,有幾種解法,其中仍然對上層作業系統與應用程式透明的解法是:

  • 雙電池架構,很明顯的可以一次只測一顆。
  • 改用 NVRAM,就不需要電池了,不過速度以及成本會是另外一個問題。

另外,對上層作業系統與應用程式有影響的方式:

  • 放電測試時將 write cache 關閉,切回 write-through。這點在原文裡也有提到,效能其實會受到蠻大的影響。
  • 不放電測試了,但這樣的缺點就是拿安全性交換,當斷電時不知道能不撐過去。
  • 或是自己控制放電測試的時間,這可以配合上面切回 write-through 的方式,挑負載比較輕的離峰時間做。

看了下來雙電池架構還不錯,增加的成本還算可以接受,而且因為效能不受到影響,也確保資料安全性,整體維護起來比較簡單。而之後在規模更大的時候,應該就會直接考慮跳到自己放電測試的方式來處理電池問題...

LSI 賣給 Avago Technologies

原來之前搞錯了... LSI 之前是把 Engenio 產品線賣給 NetApp,不是整家公司 (出自維基百科的「LSI Corporation」條目):

In March 9, 2011 LSI announced its sale of its Engenio external storage systems business to NetApp for $480 million in cash.

這次才是整家公司賣給 Avago Technologies,不知道是什麼原因而買的,看 Avago 的產品頁好像是拓展新的事業?

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