次のリビジョン
|
前のリビジョン
|
blog:2020:2020-10-07 [2020-10-07 21:33] Decomo 作成 |
blog:2020:2020-10-07 [2021-02-24 13:25] Decomo |
====== ZFSにdRAID(パリティ非クラスタ化RAID)が来る ====== | ====== ZFSにdRAID(パリティ非クラスタ化RAID)が来る ====== |
| |
OpenZFS 2.1で分散ホットスペアを実現する新たなvdev構成「[[https://openzfs.org/wiki/OpenZFS_Developer_Summit_2020_talks#dRAID.2C_Finally_.28With_a_New_Tile_Layout.29_.28Mark_Maybee.29|dRAID]]」がリリースされる見込みだそうだ。dRAIDによってホットスペアが抽象化され、障害発生時のプールのリビルドが高速化されるとのこと。実装の解説を見ると、Declustered RAIDそのものな気がするが、OpenZFSでは慎ましく“Parity Declustered RAIDZ”と言っているようだ。 | 分散ホットスペアを実現する新たなプール構成「[[https://openzfs.org/wiki/OpenZFS_Developer_Summit_2020_talks#dRAID.2C_Finally_.28With_a_New_Tile_Layout.29_.28Mark_Maybee.29|dRAID]]」が、OpenZFS 2.1でリリース見込みだそうだ。dRAIDによってホットスペアが抽象化され、障害発生時のプールのリビルドが高速化されるとのこと。実装の解説を見ると、Declustered RAIDそのものな気がするが、OpenZFSでは慎ましく“Parity Declustered RAIDZ”と言っているようだ。 |
| |
現在のZFSでは、ホットスペアはプールの予備デバイスという扱いとなっている。伝統的なRAIDシステムと同じ考え方で、ホットスペアは障害が起きたvdevの物理デバイスを置き換え、vdev内でresilver(データの復元とパリティの再計算)が行われる。抽象化が進んでいるZFSシステムの中では珍しく、割と物理デバイスを意識させる実装となっている。 | 現在のZFSにおいて、ホットスペアはプールの予備デバイスという扱いとなっている。伝統的なRAIDシステムと同じ考え方で、ホットスペアは障害が起きたvdevの物理デバイスを置き換え、vdev内でresilver(データの復元とパリティの再計算)が行われる。抽象化が進んでいるZFSシステムの中では珍しく、割と物理デバイスを意識させる実装となっている。 |
| |
dRAIDでは、そんなホットスペアデバイスの抽象化が行われる。表面上は今まで通りプールにスペアデバイスがあるように振る舞うが、内部的にはホットスペア用のブロックがvdevを構成する物理デバイスに分散して確保され、vdevに所属する仮想的な予備デバイスという扱いになる。デバイス障害時には、プールの全デバイスがかかわり分散的にデータ/パリティとスペアブロックを読み書きするため、リビルド時間が短縮されるという構図のようだ。ちなみに、dRAIDのrebuildはチェックサムとパリティの検証を行わないため、resilverとは明確に違うらしい。 | dRAIDでは、そんなホットスペアデバイスの抽象化が行われる。表面上は今まで通りプールにスペアデバイスがあるように振る舞うが、内部的にはホットスペア用のブロックがvdevを構成する物理デバイスに分散して確保され、vdevに所属する仮想的な予備デバイスという扱いになる。デバイス障害時には、プールの全デバイスが分散的にデータ/パリティとスペアブロックの読み書きに携わり、従来は1台のスペアデバイスで律速していた部分解消されるため、リビルド時間が短縮されるという仕掛けのようだ。ちなみに、dRAIDのrebuildはチェックサムとパリティの検証を行わないため、resilverとは明確に違うらしい。 |
| |
言葉だけだとイメージが付きにくいが、図を見れば簡単に理解できるかと。 | 言葉だけだとイメージが付きにくいが、図を見れば簡単に理解できるかと。 |
HCIのストレージの挙動に近いかも? | HCIのストレージの挙動に近いかも? |
| |
RAID-Z同様、dRAIDのvdev構成を後から変えることは現時点では出来ないとされている。ただし、dRAIDのデータ構造からするに、いわゆるdRAID Expansionはそう難しくない気がする。[[https://docs.google.com/presentation/d/1uo0nBfY84HIhEqGWEx-Tbm8fPbJKtIP3ICo4toOPcJo/edit#slide=id.g9d6b9fd59f_0_42|コードソンで会おう!]] | RAID-Z同様、dRAIDのvdev構成を後から変えることは現時点では出来ないとされている。ただし、dRAIDのデータ構造からするに、いわゆるdRAID Expansionはそう難しくない気がするが果たして…?。[[https://docs.google.com/presentation/d/1uo0nBfY84HIhEqGWEx-Tbm8fPbJKtIP3ICo4toOPcJo/edit#slide=id.g9d6b9fd59f_0_42|コードソンで会おう!]] |
| |
===== 参考サイト ===== | ===== 参考サイト ===== |
* [[https://github.com/openzfs/zfs/pull/10102|Distributed Spare (dRAID) Feature by behlendorf · Pull Request #10102 · openzfs/zfs · GitHub]] | * [[https://github.com/openzfs/zfs/pull/10102|Distributed Spare (dRAID) Feature by behlendorf · Pull Request #10102 · openzfs/zfs · GitHub]] |
* [[https://sc18.supercomputing.org/proceedings/tech_poster/tech_poster_pages/post185.html|Characterizing Declustered Software RAID for Enhancing Storage Reliability and Performance]] | * [[https://sc18.supercomputing.org/proceedings/tech_poster/tech_poster_pages/post185.html|Characterizing Declustered Software RAID for Enhancing Storage Reliability and Performance]] |
| * [[https://glennklockwood.blogspot.com/2020/04/understanding-random-read-performance.html|Glenn K. Lockwood: Understanding random read performance along the RAIDZ data path]] |