今回は前回に引き続き、OpenZFS 2.1の変更点を確認します。

OpenZFS 2.1での変更点

シーケンシャルな resilver 処理

zpool の resilver 機能は、zpool 内のデータを再構成する処理です。この処理は、デバイス追加や交換の際に実行されます。また、ミラー構成やRAIDZなどの回復可能な構成でない場合には使用できません。特にRAIDZのデバイス交換などパリティからデータを再構築する際は、時間がかかる処理になります。

シーケンシャルなresilver処理は、より伝統的な RAID 再構築の仕組みを ZFS に追加します。具体的には、ミラー対象のデバイスをLBA(Logical Block Addressing)順に再構築できます。LBAは、ストレージ上のセクタを管理する方法の1つで、すべてのセクタにシーケンシャルな番号をつけ、先頭からのセクタ数でセクタの位置を識別する方法です。順次再構成は従来の resilver で行うヒーリング処理を行わないため、よりも短い時間で冗長性を回復できます。その代わり、zpool scrubを実施することで、データの正常性を担保します。

ただし、現在はRAIDZに対してこの機能を使用できません。その代わり、新機能である分散型スペアRAID(dRAID)で使用可能です。

この機能を使用するときは、zpool attach/replace の引数に -s オプションを使用します。

zpool attach -s <pool> <existing vdev> <new vdev>
zpool replace -s <pool> <old vdev> <new vdev>

分散型スペアRAID (dRAID)

分散型スペアRAID(dRAID)という新しいトップレベルvdevタイプが追加されました。これは、Distributed spare RAID の略です。このプール構成では、分散ホットスペアデバイスを再構築する際に、すべてのdRAID デバイスが参加できます。これにより、故障したデバイスを使用してプールに完全なパリティを復元するために必要な総時間を大幅に短縮できます。

ここで重要なのは、分散スペアへのシーケンシャル resilver が、従来のスペアと比較していかに高速であるかということです。従来のレジルバは、新しいドライブへの書き込み帯域幅によって制限されます。16TBドライブの場合、150-160MB/sの書き込み帯域を維持し、約30時間かかります。分散型スペアにリシルバーする場合、プール内のすべてのドライブが参加し、この単一デバイスのボトルネックを解消します。さらに、冗長ストライプ幅(D+P)は、プールの利用可能な読み取り帯域幅によって制限されるため、復元をどれだけ速く達成できるかを決定します。ストライプ幅が広いと、失われたデータを再構築するためにより多くのディスクを読み込む必要がありますが、使用可能な容量はより大きくなります。逆に、ストライプ幅が狭いと、必要なディスクの数が少なくなり、容量を犠牲にしてより迅速に再構築されます。デフォルトのストライプ幅8+Pを使用すると、復元時間は7～8時間、または従来のホットスペアへの復元に必要な時間の 25% 未満に短縮されます。

dRAIDは、RAIDZと同様に1~3つのパリティを使用できます。以下は、dRAID構成のzpoolを作成するコマンドです。

zpool create <pool> draid[1,2,3] <vdevs...>

終わりに

今回は、OpenZFS 2.1以降の変更点について掘り下げてみました。次回も、OpenZFS 2.1以降の変更点について掘り下げます。次回をお楽しみに。

さて、このコラムを掲載いただいているデジタル・ヒュージ・テクノロジー社は老舗のOSSインテグレーターです。特にLinuxは強く、OSSを活用した業務システムの実績も多いです。興味がある方は以下のページもご覧ください。
DHT OSS導入コンサルティングサービス