序

AoEにしてみたり、複数ボリュームにしてみたり、内蔵で盛ってみたりと様々な手法で拡張を続けてきたストレージだが、ようやくNASを含む構成に変更された。 これにより片側最大192TBのボリュームを確保できるようになった。

NAS ReadyNAS528

NASはReadyNAS 528。

8ベイのNASである。 箱のサイズが随分大きくて驚いてしまったが、本体は8ベイとしては最小限のサイズになっている。

普通に構成するとRAID6になってしまい、選択の余地がない。 一旦ボリュームを削除してから再度作る必要がある。

この際RAID5を選択すると6台以上でのRAID5を推奨しないことを警告される。 この場合は、バックアップもされているので、RAID5で強行する。安心感で言えばRAID6のほうが良いと思う。

そしてiSCSI LUNを作成し、グループに追加する。 残念ながらLUNの最大サイズは全容量の90%とかなり少なく、10%もの領域が余る上に、ディスク全容量の21.25%も削られてしまうことになり、なかなかつらい。フルディスク使える場合はRAID6を使うのとあまり変わらないと考えると余計に辛い。

ReadyNASには暗号化機能があり、起動時に暗号化キーを含むUSBディスクを挿すことで起動できる仕組み。 どうもこれはLUKSによるものであるらしい。

また、ReadyNASは4つものNICを搭載している。 チーミングも可能だが、「グローバルLANへの経路を持つネットワーク」と「ストレージ専用ネットワーク」の2つに同時に接続できるという点は大きい。

Btrfsボリュームの構成

従来はなんらかのディスク(基本的には物理1台に対して1デバイス)に対してdm-cryptデバイスを作成し、dm-cryptデバイスをBtrfsディスクとして使用していた。

今回はRAIDレイヤー及び暗号化レイヤーはブロックデバイスが保証しているものとして取り扱う。 つまり、「このブロックデバイスは冗長化され、暗号化されたブロックデバイスである」という前提が成り立つようにするわけである。

実際にReadyNSAのボリュームはハードウェア的にRAID化され、その上で暗号化もされている。 Linux上で行う場合はmdまたはLVM RAIDデバイスをLUKSで暗号化するのが有力だろう。

この方式をとることで、「冗長化され暗号化されたiSCSIディスク」を用意することができればいくらでもBtrfsを拡張できるようになり、 従来よりも堅牢性、可用性が向上した。

snashotをsendすると壊れる

ところが、実際に使おうとreadonly snapshotをsend/receiveを使って転送すると途中で「読み込み専用ファイルシステム」となってしまい、ファイルシステムが壊れる。

ネットワークデバイスなども疑ったのだが、ログを見る限りiSCSIディスクが応答しなくなって失敗している。 Btrfs的な理由を疑ってMLでも質問したのだが、追求したところどうも「Linuxカーネルの書き込みにネットワークが追いつかず失敗する」ようだった。

この対処方法としては/sys/block/<disk>/queue/max_sectors_kbの値を変更するというものだった。 Manjaro Linuxのデフォルトは8192だが、これを4096とするとトラブルは解消された。 Red Hat Enterprise Linuxでも同様の変更によりトラブルが起きたこともあるようだ。

このディスクについては/dev/diskを使うことができないので自動化が難しい。 やるとしたら次のようなところか。

typeset -a disks
for i in /dev/disk/by-path/*-iscsi-iqn.*
do
  disks+=(${$(readlink -f $i)##*/})
done

sudo tee /sys/block/${disks[@]}/queue/max_sectors_kb <<< 4096

おわりに

レイヤーを分担させることができるようになり、ぐっとわかりやすくなった。 また、パフォーマンス面でもそれなりに向上が見られた。コンピュータ自体も刷新されたため体感としては小さいが、起動するコンピュータを問わず簡単にworldストレージをマウントできるようになった点は大きい。

max_sectors_kbの問題は盲点で発見に苦労したか、無事問題が解消できてよかった。