virtual-oji’s diary

SIerに勤務するインフラエンジニアのブログ

VMware Cloud on AWSの障害時の挙動

今回はVMware Cloud on AWS(vmc on aws)の障害時の挙動について記載します。

 

vmc on awsクラウドで稼動していますが、実際はi3.metalやr5.metal(東京リージョンでは未リリース)の物理サーバで稼動しています。

 

どんなに安定したシステムでも、結局は物理サーバで動いていますので障害をなくすことはできません。

そのため、フォールトトレランスに優れたシステムを選択することは非常に重要です。

 

結論から言うとvmc on awsの復旧フローは非常に優れています。

暫定復旧までのフローが特に優れていますので、自動ですぐに業務復旧することが可能です。

それでは具体的な復旧フローについて記載していきます。

 

まずホスト障害が発生した場合、自動で障害を検知します。

※オンプレのvSphere環境と同様に、障害ホスト上で稼動していた仮想マシンが他の物理ホストにHAで再起動されます

f:id:virtual-oji:20190930134543p:plain

1台物理ホストが利用できなくなったことで、クラスタ内の利用可能なホスト台数が減少します。

サイジングにもよりますが基本的にはクラスタ内で過負荷が発生します。

過負荷を緩和するため、新しく新規物理ホストが自動で追加されます。

この時点で仮想マシンが新規ホストにDRS(vMotion)で自動的に移動しすることで負荷が分散され、「暫定復旧」します。すばらしい挙動。

f:id:virtual-oji:20190930134705p:plain

そして障害が発生したホストの修復されるとクラスタに復帰してきます。

f:id:virtual-oji:20190930135027p:plain

暫定で利用されていたホスト上の仮想マシンがDRSで移動し、クラスタから離脱します。これで完全復旧となります。

f:id:virtual-oji:20190930135136p:plain

いかがでしたでしょうか。

非常にシンプルですがオンプレでこれを実現しようとすると独自の仕組みを構築する必要があり、かなりコストがかかると思います。

 

vmc on awsでは標準でこの復旧プロセスが提供されていますので耐障害性は非常に高いです。

 

障害は必ず起こると考えて、耐障害性の高いシステムを選択しましょう!