今回は、前回作成したiSCSIを使用したミラーボリュームでミラーボリュームの片系がダウンした際の挙動の確認と、復旧方法を確認するため、iSCSIで接続されているOSをシャットダウンしミラーボリュームがどのような状態になるのかを検証していきたいと思います。
免責事項
本手順には、曖昧な検証方法と不確実な復旧方法が記載されています。
本番環境で復旧を試みる際は、必ず検証環境等のテスト環境で手順を確認し、復旧手順に問題がないことを確認してから実行してください。必要に応じて、ハードウェアベンダーやMicrosoft社への問い合わせを行って下さい。
本手順を実行し、発生した損害、その他不測の事態が発生した場合でも責任は取りません。
期待する目標
本記事で期待される目標は以下の通りです。
- ミラーディスクの片系がダウンした際の挙動を理解する
- ミラーディスクの復旧方法を理解する
- ミラーディスクを復旧する
前提条件
前回記事で、iSCSIのディスク構成を列挙したので、その記事をご覧ください。
環境については、変更していません。
また、今回はiSCSIでミラーボリュームを作成していますが、ローカルディスクの場合でも挙動的には同じようになります。
ミラーボリュームを作成しているサーバの情報は以下の通りとなります。
- Server1
- OS : Windows Server 2022
- CPU : 2vCPU
- MEM : 4GB
- DISK1 : 60GB(OS)
- DISK2 : 30GB(Data)
- IP : 192.168.100.182
- Hostname : dev-iscsi01
- ドメイン : 参加済み
- Server2
- OS : Windows Server 2022
- CPU : 2vCPU
- MEM : 4GB
- DISK1 : 60GB(OS)
- DISK2 : 30GB(Data)
- IP : 192.168.100.183
- Hostname : dev-iscsi02
- ドメイン : 参加済み
簡単に捕捉しておくと、Server2はiSCSIのTargetでディスクの提供を行っているサーバです。
Server1についてもiSCSIで自身のローカルvHDDに接続しており、ミラーボリュームを構築しているサーバとなります。
ファイル書き込み中にシャットダウン
今回は、Hyper-V上に構築されたOS+iSCSIのディスクをマウントしているため、意図的にディスクを壊すことができません。(ディスクのアンマウントはできますが・・・)
そのため、ディスク障害を模して、Server2のOSの電源をいきなりぶっちしてみます。
NASからServer1に対してWindows10のISOファイルをコピーします。
ファイルサイズが小さい場合、すぐにコピーが完了してしまうため、操作時間を稼ぐため大き目なファイルをコピーします。
データのコピー中にServer2の電源をオフにします。
こうすることで、iSCSIで接続されているため、ミラーボリュームの片方のディスクへのアクセス性が失われます。
はい、Server2を落としてから極端にコピー速度が落ちました。
スクショだと7MB/s程度の低速での書き込みが入っているように見えますが、実際にはほぼ止まっています。
タスクマネージャーから見ても、NAS→Server1へのコピーも、Server1→Server2へのボリュームのコピーも停止しているように見えます。そのため、この間はファイルサーバ等で利用しているユーザのデータコピーや閲覧なども停止している可能性があります。
少し時間がかかりましたが、データのコピーは再開し始めました。
そのため、瞬断というわけではありませんが、一時的にファイルサーバへのアクセスが重くなるなどの現象が発生します。が、一時的なもののため、問題なく復旧します。
イベントログの確認
コピー中にServer2への接続性が失われたため、イベントログに何か残っているかもしれません。
今回は、ミラーボリュームにiSCSIを使用しているため、エラーが出力されていました。
イベントID 20のiSCSI Targetへの接続性に関するエラーが出ています。
この時点では一時的なネットワーク断によるものであるとWindowsも判断しているようで、再接続を試みています。憶測ですが、コピー中に一時的に転送速度が低下したのは再接続待ちを行っていたからでしょうか。
iSCSIへの再接続の実施後、15秒で再接続がタイムアウトしています。
このため、iSCSIでは15秒以内であれば問題なく再接続ができるみたいです。
再接続失敗後、10秒程度でディスクのエラーが検出されています。
最終的にはディスクが取り外される警告が表示されており、完全にディスクへの接続性が失われました。
ディスクの状態を確認する
ミラーボリュームでディスクの接続性が失われた場合の状態を確認してみます。
ボリューム自体に警告が出ており、状態が[冗長の失敗]と出ています。
また、ボリュームの詳細を見ると、ボリュームが[不足]となっています。
ディスクの削除を実施
現時点の状態でもボリューム自体は利用可能ではありますが、このままではもう1台のディスクに障害が発生した場合、完全にデータが失われてしまうためディスクを削除してみたいと思います。
[不足]のディスクを選択し、[ディスクの削除]を選択します。
[ディスクの管理]で警告が表示されますが、ダイナミックディスクをベーシックディスクへ変換する処理となります。
[パックが、オンラインではありません]と表示され、ディスクの削除が失敗しました。
ミラーボリュームでは、ディスクを削除する前にディスクのミラーを解除する必要があるようです。
今回はiSCSIのディスクを使用しているため、ディスクのミラーを解除する前に、念のためiSCSIイニシエータからターゲットを削除しておきます。
iSCSIで接続しているため、Targetの削除後は、ディスクをリビルドします。
ディスクのリビルドがおわったら、iSCSIのTargetを接続しておきます。
ミラーボリュームの生きているものを右クリックし、[ミラーの削除]を選択します。
[ミラーの削除]より、[不足]のディスクを選択し、[削除]を押下します。
[ミラーを削除しますか？]より、[はい]を選択します。
[削除したディスク]がダイナミックディスクで且つ、異形式になっています。
ディスクを右クリックし、[ベーシックディスクに変換する]を選択します。
[ディスクの管理]よりディスク形式の変換の警告が出るため、[はい]を選択します。
復旧と再同期
ベーシックディスクへ変換後、残っていたディスクを整理しました。
この段階で、1台のミラーディスクの運用となっています。
壊れたディスクはiSCSIで接続しなおし、未割当の状態となっています。
ミラーディスクを右クリックし、[ミラーの追加]を選択します。
追加するディスクを選択し、[ミラーの追加]を選択します。
ミラーのディスクはデフォルトでベーシックディスクのため、ダイナミックディスクに変換が必要です。
ミラーへ追加すると、Resyncが走ります。
データの同期が走るため、本作業は業務時間外に実施するほうが良いと思います。
再同期が完了し、正常な状態に戻りました。
稼働確認
障害が復旧しても気を抜かずに最後に稼働確認を実施します。
ミラーボリュームへ書き込みを行い、正常に書き込みが可能なことを確認しておきます。
NAS→Server1への通信はできていそうです。
また、送信も1.3Gbps程度出ているためiSCSI経由でもデータの転送ができていそうです。
iSCSIのターゲットが側でも900Mbps弱出ているため、しっかりと受信できていそうです。
コピーが問題なく終了しました。
念のため、iSCSIのTarget側のvHDDの容量も見ておきます。
今はServer1に10GB程度のデータが入っているため同じような容量が消費されていれば問題なく同期できています。
まとめ
今回は、ミラーボリュームのディスクが片方お亡くなりになった場合を想定して、実際に故意に障害を起こし、どのような挙動になるのかを確認しました。
実際のサーバでは、ディスク自体にRAIDが組まれていたり、ホットスペアが入っていたりするため、Windows Server上でミラーディスクを作成することは少ないと思います。
ただ、実際にミラーディスクを使用している環境が0ではないため、覚えておいて損はないと思います。
おまけ
本ブログではVMwareやWindows、Linuxのインストール手順等も公開しております。
インフラエンジニアとして有益な記事や無益なコンテンツも作成しておりますので、通勤時間や休憩時間、休日のスキマ時間等に合わせて読んでいただけると幸いです。
また、Youtubeで解説動画も鋭意作成中です。本ブログで記事にしているものも動画にしようと思っておりますので、よろしくお願いいたします。
コメント