序

さすがに無理をさせすぎたのだろうか。 マスター系ディスクに故障が相次ぎ、縮退運用となった。

従来であれば縮退運用中はなにもできないところであるが、今回は40万円近く出費しなければ置き換えられないこともあり、長期化は避けられない。 そこで、縮退運用について柔軟性をもたせた。これは以前のディスク故障からP720導入で行ったローカルシステムとグローバルストレージの併用を強化したもので、これが功を奏した形である。

ここまでの構成変化の歴史を振り返ろう。 なお、一時期運用されたがunstableで廃止されたものは除外する。

また、セキュリティ上の理由からマウントポイント等のファイル名はフェイクはフェイクである。

構成変化の歴史

最初期

SSD 64GB + HDD 500GB*4(LUKS, LVM Mirrored, XFS)であった。

SSDはルートファイルシステムなわけだが、として64GBと少ないため余裕が全くなかった。 そこで、500*4 (LVM mirror 1TB)のディスクを/homeにマウントする方式をとった。

システムとディスクは別々にLUKSで暗号化されており、データの集約はこのときから始まっていた。

問題は、データに関しては冗長性が保たれているためディスク故障にはある程度強いのだが、それでもこのストレージがマウントできないとほぼ使うことができないということだ。初期は/varもHDDにあったのだが、問題が多かったため廃止された。

まだこの時はシンプルな構成だった。

このときから3TBの初期に至るまでは、「LUKSが突然解除できなくなる」というトラブルに見舞われ、かなりのデータを失った。

3TBの導入

SSD 128GB + HDD 3TB*8。

単純に容量を拡大したようだが、大きな変更としてLVMをやめ、Btrfsに変更した。 実際はこの構成になってからかなり長い間従来と同じ運用をしていたのだが、LVMだとディスクは偏って使われることから分散して使ってくれるBtrfsに変更した。 ミラーレッグの追加がBtrfsのほうが簡単という理由もあった…のだが、実際はBtrfsのミラーレッグ追加はうまくいかないことが多く、理屈通りにはいかなかった。

また、LUKSで突然解除できなくなるトラブルを踏まえて、LUKSからdm-crypt plain(keyfile)に変更した。

従来は/homeにマウントする方式だったが、このときから~/.localにサブボリュームをマウントするように変更した。 この名前だけはフェイクではなく、~/.localというディレクトリがシステム的に使われるようになったときに困ってしまった。

定期snapshotもこのときから始まった。

2系統へ発展

( SSD 128GB + HDD 3TB * 8 ) + (HDD 500GB + HDD 3TB * 4)

Btrfs mirroredなマスター系に加え、Btrfs singleのスレーブ系が追加された。 この時期にはもっと台数の多い構成で様々なクラスタストレージを試したのだが、結局は内蔵しておくのが一番使いやすいという結論に達した。 そのため、かなり無茶な方法でケース内に、多いときは13台ものディスクを搭載していた。

この時期に様々な理由で内蔵できない時期があり、その場合SSHFSを使っていたのだが、低速であること、変なタイミングでI/Oが詰まること、rootがファイルを扱えないことなどから「いまいちである」という結論に達している。 また、ネットワーク不調などにより暗に切断されてしまうとファイルにアクセスしようとしたプロセスが固まるという問題もある。

スレーブ系統に対してはBtrfs sendを使ってデータを転送していたのだが、Btrfs send/receiveが途中で固まってしまうという問題に遭遇し、途中からrsyncによる運用に切り替えていた。 結局、これは「ATAエラーが出るとBtrfsはファイルシステムをreadonlyにする」という挙動に起因し、ディスク不調が原因だったのだが、Btrfsがディスク不調に非常に弱く、かつ適切なレポートをしないという問題は現在に至るまで解決されていない。Btrfsが変な挙動を示したらBtrfsの言うことではなくカーネルログを確認するというのが基本的手法と化している。

同期手法はクラスタファイルシステムのミラー機能なども試したのだが、最も「シャットダウンしやすく、家庭が使うには柔軟な方法」は任意のタイミングで転送を行うことだった。

マウントポイントは~/globalに変更された。

NAS導入

( SSD 256GB + HDD 3TB * N1 + HDD 3TB * N2…) : (x + HDD 4TB * N1 + HDD 4TB * N2…)

ホスト数1では対応しきれなくなったことから、複数ホストでストレージを構成することになった。 これに伴って、従来は中核ホストが全ブロックデバイスをまとめてBtrfsにしていたのだが、この構成となってから各ストレージターゲットは自身で「暗号化され、冗長化されたiSCSターゲットを提供する」という方式に変更された。暗号化処理がホストに分散されるようになったため、少し軽くなった。

また、基本的にはストレージをRAID5で提供するということにしたので、容量が稼ぎやすくもなった。非常に大きくなったディスクをカバーするため、ディスク単位以外にユニット単位での置き換えも可能になった。これは、イニシエータホストから見れば1ユニット(ホスト)で1台のディスクに見えるからだ。

一方、Btrfs RAIDはmeta mirror, data singleに変更した。これは、data mirrorであっても復元があまり現実味がないという事実を踏まえてのことだ。 実際に最もうまくいったケースですら、btrfs balanceの最中にディスクが故障して失敗したし、btrfs balanceは非常に時間がかかる。 もちろん、scrubによる修復も効かなくなるのだが、scrubで修復するようなケースで問題が解消したことがないので、素直に下層のRAIDに任せたほうがうまくいくという結論に達したのだ。

つまり、

• ターゲットは冗長性とセキュリティ(ディスクの暗号化)を保証する
• イニシエータはネットワーク経由で提供されるブロックデバイス(普通はiSCSI。AOEだと問題が出るケースがある)をBtrfsデバイスとしてmeta mirror. data singleで編成する

というルールである。

SSDが256GBになったこともあり、ある程度データをSSDに置くことができるようになった。 そこで、新たに~/intを追加し、ここに運用に必要なデータを置くように変更した。

この変更はかなり大きい。従来の方式だとグローバルストレージがマウントできない状態だと何もできない。 そもそも、XDGディレクトリがシンボリックリンクであり、そのポイント先がグローバルストレージにある場合、マウントしない状態でログインするとXDGユーザーディレクトリの設定自体がリセットされてしまう。 また、Clutter launcher(Cinnamonのアプレットとして標準のアイコンランチャ)は.desktopファイル自体が有効でない場合はlauncherの設定自体を破棄してしまうし、.desktopファイルで指定されたコマンドが実行できない場合はランチャから一時的に除外する。

このことから、~/intには日常的に作業で利用するXDG DOCUMENTSディレクトリ、~/binディレクトリ、自分のリポジトリ(~/devel)、フォント(~/.fonts)をはじめとするリソースファイル、ブラウザプロファイル¹、メール(~/Mail)などが含まれている。

つまり、~/intがあることによってログインに支障が出たり、基本的な作業すらできなくなるという問題が解消され、ほとんどのデータにはアクセスできないが最低限ログインして作業はできる状態が保たれるようになった。

実はこのことはかなり大きく、グローバルストレージになんらかの問題が発生し、データにアクセスできない状況が発生するのは全く珍しいことではなかった。その間本当に「なにもできない」状態になっていたのだが、これを解消したのである。

果たしてその状況は現実に訪れた。複数ディスク故障により縮退運用に至り、これが長期化する見通しとなったが、もしこの作業をしていなかったらまるで仕事にならない状態が継続していたことになる。

Btrfs RAID5について

結論から言えば使い物にならない。

現状、Btrfs RAID5はbtrfs device replaceがうまくいく保証がない。btrfs device removeに関してはほぼうまくいかない。 完全にexperimentalである。

では気休め程度に使えるかというと、そんなことは全く無くて、Godavariマシン(A10-7870K)ではCPUが100%に張り付き、極めて不安定なI/Oを見せる。 連続で転送していると調子がいいときは2時間で200GB程度を転送できるが、調子が悪いときは17時間で20GBしか転送できない。 これは 書き込みだけでなく、読み込みでも発生する。

ダメだ、ダメだと言っているばかりで誰も実用しないので実態がわからないから勇者になってみたのだが、まぁ、ひどい。

AOEとBtrfsについて

詳細はよくわからないのだが、まずAOEでmkfs.btrfsしたBtrfsボリュームはローカルにはマウントできないし、逆にローカルでmkfs.btrfsしたBtrfsボリュームはAOE経由ではマウントできない。

だけならいいのだが、マシンに複数あるブロックデバイスをAOEデバイスとして登録し、これをそれぞれAOEデバイスにした場合、そのBtrfsは再起動後マウント不能になる。