vSphereのバージョンが上がるにつれて、VMware社がVCSAを重要視していることが分かります。vSphere 5.1で初めてVCSAが披露された時は、殆どの管理者が見向きもしなかったかもしれませんが、現在は大分変わったんじゃないでしょうか。
まず、Windows版vCenterと同じ土俵に立つようになりましたね。5.5まではサポートするホスト数も仮想マシンの数もWindows版に劣ってましたが、6.0になりWindows版同様クラスタあたり最大64ノード、最大8,000 仮想マシンを管理できるようになりました。6.5では更に強化されUpdate Managerも統合されましたし、OSもSLESからPhoton OSに代わりより軽量化されました。今度は逆にWindows版にはない機能も追加されました。それがネイティブバックアップ機能とvCenetr HA（VCHA）機能です。
vCenter High Availability Performance and Best Practice
上図のようにVCHAは、vCenterをフェイルオーバーする機能です。一旦仮想マシンの停止が発生するvSphere HAとは異なり、VCHAはActive-Passive構成です。ActiveとPassive間ではDBではsync、その他のファイルに対してはasync同期が行われます。よってVCHAを構成するためにはPassive用VCSAとWintness用VCSAを導入する必要があります。
VCHAの構成は至って簡単で構成方法は2つあります。
●Basic
VCSAがHAを構成するクラスタ上に存在する場合、Basicオプションで構成します。この方法はハートビート用ネットワークの用意以外の事前準備はありません。HA構成ウィザードに従い進めて完了です。
●Advanced
Basicとは違って、VCSAがHAを構成するクラスタ外にある場合のオプションです。例えばVCSAが管理するクラスタと別れている場合になります。このオプションではハートビート用ネットワークの用意と手動によるVCSAへのネットワークアダプター追加が必要です。
検証環境にて、VCHAを構成してみました。小職の検証環境はVCSAが別のホスト上で稼働中のため、Advancedオプションで構成します。
① まず、Active用VCSA(vc65-ha-a)にハートビート用ネットワークアダプターを追加します。
② VCSAの管理ページより、追加したハートビート用ネットワークアダプターにIPアドレスを手動で指定します。
③ Web Clientより、VCSAを選択し、[設定]→[vCenter HA]→[構成]を選択します。
④ 構成ウィザードが表示されるので、[Advanced]を選択、[次へ]をクリックします。 
⑤ PassiveとWitnessのハートビート用IPアドレスとサブネットを設定し[次へ]をクリックします。 
⑥ この段階で一旦、構成ウィザードの操作は止めます。ウィザードは閉じないでそのままにしておき、別のウェブブラウザを起動PassiveとWitness用VCSAのクローンを作成します。 
⑦ Web ClientよりVCSAを選択し、まずはPassive VCSA用クローンを作成します。
※ クローン作成方法は割愛しますが、クローン作成用”カスタマイズ仕様”を定義する必要があります。定義の際には以下の項目設定に注意が必要です。
- ホスト名：Active VCSAのホスト名
- タイムゾーン：Active VCSAと同じタイムゾーン
- NIC#1：Active VCSAのIPアドレス(管理ネットワーク)
- NIC#2：手順②で設定したPassive VCSAのハートビート用IPアドレス(デフォルトゲートウェイは設定しません)
上記の項目以外はVCHA特有の設定はありません。すべて設定したらクローンを作成し、正常に起動するまで待ちます。
⑧ 今度はWintness用VCSAのクローンを作成します。
基本、Passive VCSA用クローン作成と同じですが、こちらも”カスタマイズ仕様”を定義する必要があります。定義の際には以下の項目設定に注意が必要です。
- ホスト名：Active VCSAのホスト名
- タイムゾーン：Active VCSAと同じタイムゾーン
- NIC#1：DHCP
- NIC#2：手順②で設定したWitness VCSAのハートビート用IPアドレス(デフォルトゲートウェイは設定しません)
上記の項目以外はVCHA特有の設定はありません。すべて設定したらクローンを作成し、正常に起動するまで待ちます。
⑨ 再度、VCHA構成ウィザードのページに切り替え[完了]をクリックします。 
⑩ HAクラスタの構成が始まります。 
⑪ 構成はすぐ終わります。VCHAが構成が完了すると画面中央に各ノードのロールと状態が表示されます。VCHA構成直後はActiveの情報がPassive側にレプリケーションされるため警告が表示されます。 
⑫ 正常にActive側のDBとファイルが複製されたら”正常”状態になります。 
⑬ [監視]タブより、HAの健全性が”良好”であることが確認できます。 
VCHA構成後、failoverを試してみました。
① Active VCSAを停止します。 
② Web Clientのページを更新すると”failover”が進行中であることが分かります。failoverが完了するまで一時的にWeb Clientはエラー画面が表示されますが、数分でfailoverは完了されます。検証環境では6分ほどかかりました。 
③ Web Clientにログインし、VCHAの状態を確認するとActiveノードは切断され、Passiveノードに変更されていることが確認できます。 
④ [監視]タブからもHAの健全性が”警告”になっています。ちゃんと機能してますね。:) 
構成してみたところ、意外とfailoverに時間が必要であることが分かりました。VMware社のドキュメントではvCenterの構成とインベントリのサイズによって時間は異なるが、UIクライアントで4分でfailoverされるとしています。となると… 正直シングルクラスタ環境ではvSphere HAでfailoverされた方が早いかもです。
しかし複数のクラスタをシングルVCSAで管理する場合は、vSphere HAに加えてVCHAも構成しておけば更に強固なvCenterの冗長性が確保できるのではないでしょうか。:)
VCHA構成に伴うパフォーマンスとベストプラクティスは下記のドキュメントをご参照ください。
vCenter High Availability Performance and Best Practice
※ご覧ください！このシンプルでキレイなUIデザイン！
※パフォーマンスのトラブルシューティングダッシュボードではプロダクトの種類と関係なく、仮想マシンを始めvSAN、クラスタ、データストアなどカテゴリでその状態が確認できます。
※ No more MPSD for vSAN! 🙂
※パフォーマンスだけではなくコンプライアンス準拠状態も確認できます。
