VMware Cloud on AWSの障害時の挙動
今回はVMware Cloud on AWS(vmc on aws)の障害時の挙動について記載します。
vmc on awsはクラウドで稼動していますが、実際はi3.metalやr5.metal(東京リージョンでは未リリース)の物理サーバで稼動しています。
どんなに安定したシステムでも、結局は物理サーバで動いていますので障害をなくすことはできません。
そのため、フォールトトレランスに優れたシステムを選択することは非常に重要です。
結論から言うとvmc on awsの復旧フローは非常に優れています。
暫定復旧までのフローが特に優れていますので、自動ですぐに業務復旧することが可能です。
それでは具体的な復旧フローについて記載していきます。
まずホスト障害が発生した場合、自動で障害を検知します。
※オンプレのvSphere環境と同様に、障害ホスト上で稼動していた仮想マシンが他の物理ホストにHAで再起動されます
1台物理ホストが利用できなくなったことで、クラスタ内の利用可能なホスト台数が減少します。
サイジングにもよりますが基本的にはクラスタ内で過負荷が発生します。
過負荷を緩和するため、新しく新規物理ホストが自動で追加されます。
この時点で仮想マシンが新規ホストにDRS(vMotion)で自動的に移動しすることで負荷が分散され、「暫定復旧」します。すばらしい挙動。
そして障害が発生したホストの修復されるとクラスタに復帰してきます。
暫定で利用されていたホスト上の仮想マシンがDRSで移動し、クラスタから離脱します。これで完全復旧となります。
いかがでしたでしょうか。
非常にシンプルですがオンプレでこれを実現しようとすると独自の仕組みを構築する必要があり、かなりコストがかかると思います。
vmc on awsでは標準でこの復旧プロセスが提供されていますので耐障害性は非常に高いです。
障害は必ず起こると考えて、耐障害性の高いシステムを選択しましょう！
AWS Backupの設定と通知方法
今回はAWS Backupの設定とバックアップ時の成功・失敗の通知方法について記載します。
AWS Backupを利用するとEC2上のインスタンスをスケジュール及び世代管理しながら自動でバックアップを取得することが可能です。
通知についてはCloudWatch EventとSimple Notification Service（SNS)を利用してEメールにて通知を行います。
では早速設定方法について記載していきます。
AWSコンソールにてAWS Backupを検索して設定画面に遷移します。
バックアッププランからプランを選択して新規作成します。
新しくスケジューリングなど設定したいため新規でプランを作成します
プラン名は任意の名前を設定します
バクアップウインドウを指定すると指定した時間内の中でAWS基盤の負荷が低いタイミングでバックアップが実施されます。
また、費用を抑えたい場合は安価なコールドストレージへ移行することも可能です。
有効期限切れの部分でローテーションを指定することができます。指定した日数が経過すると古いバックアップから削除されていきます。
ちなみにAWS Backupで取得されたバックアップは手動で削除することができません。
バックアップリソースとプランを削除することで暫くすると削除されます。（自分は数時間削除されるのにかかりました。）
プランを作成します。
スケジュールの作成が完了したので次はバックアップの対象を指定します
リソース割り当て名に任意の名前を入力します。
予めバックアップ対象のインスタンスにタグを指定しておくと複数台のインスタンスを一気に対象とすることが可能です。
以上でバックアップ設定は完了です。ダッシュボードで進行状況を確認できます。
完了すると表記が変わります。
以上でバックアップの設定は終了です。
続いて通知の設定を行います。
通知はCloudWatch Eventから設定します。
イベントルールを作成します。
AWS BackupはEBSスナップショットが裏で動いているので、EBS スナップショットのイベント発生時に通知を行います。
特定のイベントにcreate snapshotを選択します。
特定の結果にsuccessed,falsedを選択します。失敗したときだけ通知したい場合はfalsedだけ選択します。
最後に通知先を設定します。
ターゲットにSNSを設定します。※SNSの設定方法は割愛します。
設定の詳細を選択し、ルール詳細設定画面で名前に任意の文字列を入力します。
以上で通知の設定も完了です。
これ以降スケジューリングに沿ってバックアップが取得され、Eメールにて通知されるようになります。
すぐできる！VMCとネイティブAWSの統合ログ管理！
今回はVMware Cloud on AWSのログ管理についての続きです。
VMware Cloud on AWSを利用する場合、ネイティブAWSも利用することが多いのではないでしょうか
今回はそんなVMCとネイティブAWSのログの統合管理方法をご紹介します。
前回、VMCのログをLog Intelligence(LINT)で収集する方法を記載しましたが、
LINTではネイティブAWS環境のログを取得することができません。
そのため、VMCはLINTでログ管理・ネイティブAWSはCloudWatch Logsなどの別サービスを利用したログ管理となり、ログを一元的に管理することができません。
そこで今回はLINTで収集したログをAWS CloudWatch Logに転送して一元管理する方法をご紹介します。
イメージはこんな感じ
LINTのログをLambdaにPOSTしてCloudWatch Logsに書き込む形です。
では早速やり方を見てみましょう。
まず、Lambdaで新しい関数を作成します。
関数名は任意の値を入力し、ランタイムはpython3.6以降を選択します。
LINT側で設定するURLを取得するため、トリガーを追加します。
作成されるとこんな画面になります。
続いて画面下のAPI Gatewayの名前をクリックします。
アクションからメソッドを作成します。
POSTを選択し、先ほど作成したLambda関数を指定して保存します。
Lambda画面に戻り関数コードに以下のコードを記入します。
貼り付け用------------------
import json
import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)
def lambda_handler(event, context):
body = json.loads(event['body'])
for index, item in enumerate(body):
logging.info("VMC : " + json.dumps(item))
return {
'statusCode': 200,
'body': json.dumps({'Messsage':'Successfully received Webhook from VMC'})
}
貼り付け用------------------
関数を記入後は右上の保存を押下します。
Lambdaのホーム画面のAPI gateway APIエンドポイントのURLをコピーします。
（検証環境ですが念のため、https以降を白塗りにしてます）
続いてLINT画面のLog Managemnt→Log Forwardingへ遷移します。
※ちなみに有償版のLINTでないとLogを転送できませんので注意
Destination:Cloud
EndpointURLに先ほどのコピーしたAPI Gatewayのアドレスを入力します。
右上でログにフィルターをかけられますが今回は全てのログを転送します。
入力し終わったらsaveします。
CLoudWatchLogを見るとロググループが作成されています。
グループをクリックするとログストリームが表示されます。
ログストリームをクリックするとログの詳細を表示できます。
NSX Controllerのログがきてますね～
例によって白塗りしています。
フィルタをかけることで特定のログを表示させることができます。
以上のように簡単にログをCloudWatch Logsに集めることができました。
また、LINTのWebhockを利用するとアラームを検知した場合だけログを送信することもできます。
ほとんど同じ手順ですが詳細は以下のサイトで詳しく紹介されてます
ではまた～
