VMware + SAN上にいくつかのLinux VMがあります。
SAN(失敗したパス)で問題が発生したため、しばらくの間、Linux VMドライブでI/Oエラーが発生しました。パスのフェイルオーバーが完了したとき、それは遅すぎました: すべてのLinuxマシンは、ほとんどのドライブを「信頼できる」ものではないと見なし、読み取り専用デバイスとして設定しました。ルートファイルシステムのドライブも影響を受けました。
mount -o rw,remount /
成功せず、echo running > /sys/block/sda/device/state
成功せず、/sys
成功せずに解決策を見つける。blockdev --setrw /dev/sda
すべてのLinux VMを再起動する必要がありました。 Windows VMは問題ありませんでした...
問題は ここ で説明されています。 VMwareは、Linux scsiタイムアウトを増やして、この問題の発生をpreventすることを推奨しています。
ただし、問題が最終的に発生したとき、ドライブを読み取り/書き込みモードに戻す方法はありますか?(SANが通常に戻ったら)
この問題はここで2、3回発生しました。通常、ネットワークが長期間ダウンしていることが原因です。問題は、ファイルシステムが読み取り専用ではなく、ディスクデバイス自体が読み取り専用としてマークされていることです。再起動以外のオプションはありません。 scsiタイムアウトの値を大きくすると、パスのフェイルオーバーなどの一時的な不具合が発生します。 15分間のネットワーク停止ではうまく機能しません。
mount
の男から:
errors={continue|remount-ro|panic}
Define the behavior when an error is encountered. (Either
ignore errors and just mark the filesystem erroneous and con‐
tinue, or remount the filesystem read-only, or panic and halt
the system.) The default is set in the filesystem superblock,
and can be changed using tune2fs(8).
したがって、remount-ro
の代わりにcontinue
オプションを使用してVMをマウントする必要があります。
mount -o errors=continue
mount -o remount
接続されたSANを再起動/再構成するときに、RHELシステムでこれが発生しました。私にとってうまくいったのは、ボリュームグループとLVMを非アクティブにしてから、再度アクティブにすることでした。
vgchange -a n /vg_group_name
lvchange -a n /lvm_group_name
次に、それらを再アクティブ化する必要があります。
vgchange -a y /vg_group_name
lvchange -a y /lvm_group_name
次に、mount -a
を使用してすべてを再マウントします。
テストを使用してテストケースを実行したところ、VM意図的に無効にしたNFSデータストアで実行しているため、機能するものが見つかりませんでした。blockdevコマンドは動作しません。vg/ lvコマンドは、マウントされたルートでの動作を拒否します/
システム。
この時点で、最良のオプションはerrors=panic
in / etc/fstab so VMただハードに失敗します。