[Virtualization][VMware] 分散スイッチに障害が起きたとき

オンプレミス-技術のお話し-日々徒然

またやらかしたストレージ障害

もう、これまでに何度も我が家の環境では甚大な障害がおきまして、そのたびにいろいろ四苦八苦して復旧させてまいりました。一番最近でかかったものとしては、昨年6月末に発生した「間違えて稼働中のNASをVMとして丸っと削除した」という素敵な話だったのですが、今回も負け時劣らずえらいことになっております。

というのも、仮想ストレージである、EMC UnityVSAでFAST/VPと呼ばれる自動階層化機能を利用していました。この中でExtreme Performance階層として使用していたNVMe SSDがご臨終召されたのです。

お亡くなりになったSAMSUNG MZVPV256HDGL2D

使っていたSSDはSamsung製の256GB SSDでして、初めてNVMeとして触れたものでした。おそらく2016年ごろから使っていて、4年経過しようとしたところじゃないかなーと思います。

わかっちゃー居るんだけど、単一構成のSSDをFAST/VPに構成するのはそれなりの自殺行為ではあるなーと感じてはいて、大体ストレージは別途構成中の状態でした。が、それを構成してじゃぁ移行しようかと思った矢先に今回の事象に遭遇しました。

なんだかなー、いつもこういう地雷ばっかり踏むんだなー・・私。

vCenterが消滅しました・・

さて、この影響範囲は非常にでかく。というのも、EMC UnityVSAってファイルシステムがオフラインになった場合に再度オンライン化することはRAID復旧でもできない限りできないんです。今回の場合、構成しているストレージが複数本あるわけですが、取り付けたストレージの可用性はサーバ側のRAID構成などにより担保されることを前提にしています。

キャッシュ破損とかのレベルで済めばいいんですが、今回FAST/VPで階層化をさせてるもんだから、そのSSDに蓄積されたデータは紛れもなく本番データであり、その分が丸々欠損します。欠損データが発生するとUnityVSAはそのプールを即時オフライン化します。仮想ディスクが丸のまま復旧すればプールも復帰するんですが、今回完全にSSDがお亡くなりになったのでまぁ復活することはないという話で。3.9TB中256GBの破損でそのプール自体が全滅したことになります。

ストレージ死亡確認

dvSwitchはどーなるんかしら

そもそもバックアップとかどーしたんじゃい!とかいろいろ突っ込みどころが満載な今回の障害ですが、まぁまぁせっかくだしこういう障害が起きた時だからこそ確認できることというのについてまとめてみることにしました。その中の一つが「分散仮想スイッチ」であります。

分散仮想スイッチについて

上手についてはご存じの方も多いかと思うのですが、今回見事にvCenterがご逝去あそばされたこともあり、設定情報の大本は欠損した状態になります。果たしてこの状況下で残されたESXiサーバ上のごみ(?)はどうなるんでしょうか?というお話です。

通信はできる

ぶっちゃけ残された分散仮想スイッチの残骸は「構成さえ変えなければ今まで通りに動く」というのが実際の結果になります。
残された残骸の機能上の制約としては以下の通りになります。

  • 謎の仮想スイッチとしてオブジェクトは残っている
  • 分散仮想スイッチに対する設定は行えない
  • 新規VMに対して分散ポートグループは指定できなくなる(名前としては情報は残っている)
  • 既存VMに対して分散ポートグループに既に設定されている場合、その通信はこれまで通り行える
  • VMKernelに対しても既存VMと同じような対応になる

よって、今後設定変更が必要な場合は同様の標準仮想スイッチを構成し、そこにさっさとポートグループを変更するという対応が必要になると思われます。

新たなvCenter ServerにESXiサーバを参加させた場合

当然復旧する過程で、バックアップデータが無かったり分散仮想スイッチのエクスポートデータが存在しない場合、いったんまっさらなvCenter Serverに参加させる必要があったりしますが、その場合分散仮想スイッチの残骸はどのように扱われるのか?という話について。

以下の通りになります。

  • 既存分散ポートグループはvCenterから見えない
  • 既存分散スイッチ自体はvCenterから見える
  • 既存分散スイッチは以下条件を満たした場合に「削除」することはできる
    • 既存分散スイッチに対してすべての仮想マシンが接続してないこと
    • 既存分散スイッチに対してすべてのVMKernelポートが接続していないこと

既存分散ポートグループはvCenterから見えない・・とありますが、ずばりポートグループ名は「」、つまり空欄として表示されます。故に仮想マシンの設定変更をする際は注意が必要です(設定が通らなくなる場合がある)。既存分散スイッチの存在自体が正確にvCenterサーバからは認識できない状態になっているということです。

ただ、分散仮想スイッチそれ自体は参照することができるため、分散仮想スイッチにおける「ホストの追加と管理」にてポートグループの移行やアップリンクポートを手軽に移行させることが可能です。特にVMKernelポートを移行対象として処理してもらえるというのは非常にありがたいポイントで、手で頑張って移行するぐらいならそうした移行機能を使うほうが通信断も起きにくいため、より安全に問題となる状況を回避できるのではないかと思います。

ホストの追加と管理
ホストの追加もしくはホストネットワークの管理を選択

変更画面は以下のような感じで、ホストごとに設定が並んでいます。

割り当て変更画面

上記画面では物理アダプタの割り当て変更、次の画面ではVMKernelポートの割り当て変更、そのさらに次の画面では仮想マシンの仮想NICが接続するポートグループの割り当て変更がそれぞれ指定できます。

これを使用して分散ポートグループの割り当て変更が一通り済んだ後、既存分散仮想スイッチは何も接続してない状況になるので、ESXiサーバ毎の設定画面から削除していくという流れになります。

まだまだ復旧作業は続きます

とりあえず四苦八苦しながら復旧は進めてまして、何とかActive Directory/DNS、インターネット接続系、クライアント無線LAN系はある程度復旧できました。ほかに復旧が必要な超重要サーバとして

  • 集合リバースプロキシ
  • Ceph中継サーバ兼RADOS Gatewayサーバ
  • コンテナ基盤

が挙げられまして、これを全力で復旧中です。道のりはまだまだ長い・・

Tags:

Comments are closed

PAGE TOP