【ITニュース解説】Five layers, one migration — what a fabric cutover exposed about storage

ストレージの移行は複雑で、一見計画通りに進んだように見えても予期せぬ問題が発生することがある。この記事では、あるストレージ移行作業中に、ストレージが単一の存在ではなく、複数の層（レイヤー）から成り立っていることが明らかになった事例が紹介されている。各層は独立して機能し、それぞれの健全性を確認する必要があるのだ。一つの層が正常に見えても、その下の層で問題が起きている可能性があるため、各層ごとの詳細な検証が重要となる。この記事で示されたストレージの五つの層と、それぞれの層で発生した具体的な問題、そしてそこから得られた教訓について解説する。

第一の層は「ネットワーク到達性」である。これは物理的なケーブル接続やネットワーク設定が関わる最も基本的な層だ。移行作業では、Windowsサーバーの10Gネットワークアダプターのドライバが未導入で、OSが新しいネットワークインターフェースを認識しなかったケースが発生した。スイッチ側ではリンクアップしていても、サーバー側ではインターフェースが使えない状態だったのだ。また、TrueNASサーバーでは、新しいVLANがLAGG（リンクアグリゲーション）設定に追加されておらず、サーバーが指定されたアドレスで通信できなかった。これらの事例から得られた教訓は、ネットワークの「リンクアップ」状態は、スイッチ側だけでなく、接続先のサーバーOS側からも確認する必要があるということだ。双方のエンドポイントが意図したアドレスで通信できるかを確認することが、この層の健全性検証では不可欠となる。

第二の層は「サービス到達性」である。ネットワークが機能していることを前提に、特定のサービス（例えばSMB共有）が利用できるかに関わる層だ。移行作業では、SMB共有リストには表示されるものの、実際には「ネットワーク名が見つかりません」というエラーでアクセスできない共有が発生した。これは共有がTrueNASの設定上は存在しているが、その裏付けとなるZFSデータセットがマウントされていなかったためだ。実際には、データセットが置かれたJBOD（Just a Bunch Of Disks）ストレージ筐体の電源が入っていなかったことが原因だった。この層の教訓は、サービスが「存在すること」と「利用可能であること」は全く異なるということだ。共有リストに表示されるだけでなく、実際にデータにアクセスできるかまで確認する必要がある。

第三の層は「ミドルウェアの認識とZFSの現実」である。これはストレージ管理ソフトウェア（ミドルウェア）が持つ状態情報と、実際にカーネル（OSの核心部分）が認識するストレージの状態との間にずれが生じる層だ。問題事例として、JBODの電源が復旧し、OSレベルでのZFSコマンドではプールが「ONLINE」と認識されていても、TrueNASのGUI（ミドルウェア）では依然として「OFFLINE」と表示され続ける状況があった。これはミドルウェアがストレージの状態をキャッシュしているため、外部で発生した変更を自動的に反映しないためである。この層の教訓は、ミドルウェアのキャッシュは現実と乖離することがあり、カーネル（ZFS）の情報を常に信頼すべきだということだ。このような場合、TrueNASのGUIからプールの「エクスポート/切断」を行った後、「インポート」し直すことで、ミドルウェアの認識を更新できる。

第四の層は「SASパス中断下のZFS状態」である。これはZFSファイルシステム自体の状態と、それが利用する物理ディスクへのパスの一部が一時的に中断された場合の振る舞いに関わる層だ。移行中に、ZFSプールが「UNAVAIL」となり、すべてのディスクメンバーが「REMOVED」と表示されたケースがあった。これは一見すると壊滅的なディスク障害に見えるが、実際には物理パスの一時的な問題で、ディスク自体は健全だった。ZFSコマンドの「zpool clear」でプールの状態を復旧できたが、その後もSMBアクセスが機能しなかった。この層の教訓は、ZFSプール全体が突然利用不可になった場合、それはディスク故障よりもパスの問題である可能性が高いことである。ディスクの物理的な健全性とZFSラベルを確認し、「zpool clear」コマンドで復旧できることが多い。また、ZFSプールが復旧しても、そのプールを利用していたサービス（Sambaなど）は古い情報を保持している可能性があるため、サービスの再起動が必要になる場合がある。

第五の層は「物理ストレージパスの状態」である。これはZFSよりもさらに下位の、SASコントローラー、ケーブル、JBODのバックプレーン、ドライブインターフェースといった物理的な接続パスに関わる最も根本的な層だ。移行作業の最後に発生した問題では、他のZFSコマンドが全く効かず、カーネルログに「CAM Periph destroyed」や「SCSI transport errors」といった低レベルのエラーが大量に発生し、システム全体が応答不能になる事態が発生した。これはZFSが利用するデバイスを認識できなくなったためで、ZFSコマンドでは解決できない状態だった。この層の教訓は、ZFSコマンドが全く機能しなくなり、カーネルログで低レベルのストレージパスエラーが確認される場合、問題はZFSより下の物理層にあるということだ。この場合、サーバーのストレージホストバスアダプター（HBA）から外部のJBODまで、ストレージパス全体を完全に電源再投入する「ハードパワーサイクル」が唯一の解決策となることがある。

今回の経験から得られた最も重要な教訓は、ストレージシステムが単一の健全性シグナルでは判断できない多層構造であるという点だ。それぞれの層が独立した検証ステップを必要とし、上位層の「グリーン」信号が下位層の健全性を保証するものではない。ストレージ移行の計画やトラブルシューティングでは、各層の特性と、それぞれの層で発生しうる問題、そしてその検証・解決策を深く理解しておくことが、スムーズな運用には不可欠である。