iSCSIが切断された時どうなるか検証（ESXi）

iSCSIが切断された時どうなるか検証した記録（ESXi）

最初に

ESXi機にHDDを積んで使っていればハードにトラブルあれば
大体はESXiもろともダウンしパープルスクリーンや再起動になります

iSCSIは同一機ではないのでデータストア切断のリスクも通常より高いですし
iSCSIの場合はESXiは稼働したままなのでVMがどうなるのかなど導入前に気になるところ

それを事前に確認するためいろいろ検証してみました

念のため言っておくと今回はあくまで切断した状態を検証するのが目的なので
マルチパスを使った経路２重化を紹介したりする次元の話じゃないです

iSCSI先と通信できなくなった時にESXiやVMはどうなるのかという点だけ

検証機

VMware ESXi 6.5d

FreeNAS-11.0-RC (ad90a865b)

NAS4Free 11.0.0.4.4249

FreeNASとNAS4Free両方同じ条件で確認したものの
差はなかったので以下で紹介するのは両OS共通です

ESXi 6.5ですがイベントログ監視はC#版のクライアント使ってます

iSCSIのExtentはファイルタイプで
iSCSI上に作成したデータストアのファイルシステムはvmfs6
検証用VMの仮想マシン ハードウェアバージョンは13

ESXi本体

当然ながらデータストア切断ぐらいじゃESXi本体には影響ありません

NAS機の方でiSCSIを停止したりOS再起動をすると即座に検知し
イベントログに記録されます

そしてNAS側のiSCSIが復帰次第、自動で回復します

上記の例はiSCSIサービスを停止した状態でのログで
LAN直結のiSCSI機を再起動したりしてネットワーク自体が切れた場合は
NICのリンク状態などもログに出ます

最初のアクセスが失われて回復処理進行中の後140秒後に
「すべてのパスがダウンしています」状態から
「すべてのパスがダウンしてタイムアウトしました」状態になりますが
この140秒はMisc.APDTimeoutで設定できます

C#版

HTML5版

ということでESXi自体は当然ながらパープルスクリーンになったりせず
iSCSI機との通信が復帰できた時点で自動で回復します
回復も数秒で検知されるので復帰におけるタイムラグはほとんどありません

VM（Windows 10）

次にiSCSIで接続しているデータストア内にWindows10のVMを作成して
VMが起動中にiSCSIを切断するとどうなるかを確認

使用したのはWindows 10 64bit バージョン1703 OSビルド15063.296
電源とスリープの設定でスリープは解除していて
デスクトップにタスクマネージャを表示したまま放置

iSCSI機を停止させるとすぐにディスクのアクティブな時間が100%に張り付きます
要はビジー状態の扱い

もちろんディスクにアクセスできないのでフォルダを開こうとしたりはできませんし
iSCSIが切断している状態でRDP接続を開始すると反応できないので当然繋がりません
切断前にRDP接続していれば接続も維持されたままで
タスクマネージャも画像の通り切断中も動きます
これはオンメモリでカバーできる分はディスクなしでも動くからでしょうね

iSCSI機を回復させるとディスク状態も通常値にすぐ戻りました

このように短時間ならVMもダウンせず正常に回復しますが
毎回ちゃんと回復するのかと言われると答えはNOです

正常に復帰しない場合はどうなるかというと
iSCSI切断中は画面もデスクトップのままでしたが
iSCSIが回復した直後にブルースクリーンへ切り替わります
停止コードはCRITICAL PROCESS DIED

この後はディスクチェックが開始される

そして自動修復が開始

この後は普通に起動しますが再起動された状態ですので
起動中のアプリなどは当然データ保存されずに強制終了されます

デスクトップ画面にタスクマネージャを起動した状態の場合
２０分ほどiSCSIが切断されるとブルスク率は上がる模様
15分以内での回復だとブルスクはなかったです

切断時に処理していたデータは保存されないのは仕方ないですが
OSやVMが破損しなかったのは安心です

VM（CentOS7）

次にiSCSIで接続しているデータストア内にCentOSのVMを作成して
VMが起動中にiSCSIを切断するとどうなるかを確認

使用したのはCentOS 7.3 (1611)

SSHでログインしている状態で放置

iSCSIを切断してもWindowsと同じくオンメモリでの動作は問題ないので
SSH接続は切れたりしません
しかしディスクはアクセスできないのでコマンド打ったところでレスポンスが返ってきません

その後OS的にタイムアウトになるとエラーを表示

[root@VM ~]# ls -al
ls: cannot open directory .: Input/output error

こういう状態になるとiSCSIを回復させてもエラーのままでした

[root@VM /]# yum update
-bash: /usr/bin/yum: Input/output error
[root@VM ~]# ls -al
-bash: /usr/bin/ls: Input/output error

結局再起動しないとまともに動かないので再起動することになります
Windowsと違ってブルスク的なのはでませんでしたが
CentOSの場合Input/output errorが出るまでの時間が数分ですので
猶予はWindowsより短いです

iSCSI切断中にVMをパワーオフ

VM起動中にiSCSIを切断・回復するとどうなるかを確認した後は
iSCSI機がダウンしたままの状態を考慮して
VMのあるデータストアが切断状態でもパワーオフして問題はないのかを確認する

HTML5版 vSphere Clientでパワーオフしたところ
データストアにアクセスできないのでVM情報も取得できずに各データが表示できなくなり
VM画面もパワーオフする直前の画面で停止

iSCSI機を回復させるとすぐに元に戻る

この後はいつも通りVM起動可能だったのでVMファイルの破損もなく問題なし

最後に

全体的に期待通りの結果でとりあえず安心。

検証作業中には何度も何度もiSCSIの停止を繰り返したものの
一度もVM・vmfsの破損はなく
ファイルエクステント形式だったiSCSI側のファイルも問題なかったです

検証は何も処理を走らせてない状態が多かったですが
処理を走らせていても結果は変わらずディスクをアクセスするタイミングで停止するだけ

普通のPCを使用中にHDDが壊れた時と同じ感じで
ESXi側はiSCSIが切れたところでVMをどうこうするわけでもなく
切れたら回復するまでひたすら待機して回復すれば何もなかったように処理を続ける

なので結果的にはiSCSIが切断した場合にどうVMに影響するかはVMのゲストOS次第
ゲストOS側のタイムアウト処理などが大きく影響することになります

CentOSの例もあるのでWindows機も長時間の停止を経験した場合は
再起動した方が安全だと思いますがLANケーブル抜き差しするぐらいは余裕です
遅いHDDならビジーで数十秒アクセスできないとかありますから
OS側もそこまでシビアには設定してないようです

なので前記事に記載したようにFreeNAS機で確認できた負荷状態で一瞬切断される現象も
10秒もあれば復帰するのでVMにはすぐ影響するような問題ではありません