みんな大好きストレッチクラスタ !
最近も構成に関して質問をいただくことが多いです。
ブログ記事もプレビュー数がだんとつ1位です。
ストレッチクラスタ が出た時は、ネットワーク要件はあれどサーバだけでこんなこと実現できるんだ!と感動しました。
ストレッチクラスタ の基本はこちらから(⑨まであるよ)
vSAN 7 でのアップデートはこちらから
vSAN 7 アップデート!詳細編 ⑩ ストレッチクラスタ のエンハンスメント
さて本題です。
vSAN 7.0 U2 の機能強化により、ストレッチクラスタのさらなる活用ができるようになりました!
vSAN 7.0 Updete 2 をストレッチクラスタ の観点からご紹介します。
- 構成ホスト数の拡張
- ファイルサービス
- サイト障害時の再同期中のDRS
構成ホスト数の拡張
vSAN のストレッチクラスタ はプライマリ/セカンダリサイト、ウィットネスサイトの3サイトから構成されます。
ウィットネスサイトは字の通り、ウィットネスホストを配置するためのサイトで、データを保持せず、ウィットネスコンポーネント*を保管するための仮想アプライアンスを稼働させるサイトです。
プライマリ/セカンダリサイトは仮想マシンを稼働させ、データを配置するサイトです。
vSAN 7.0U2から各サイトの最大ホスト数が20まで拡張されました!
プライマリサイト:20台
セカンダリサイト:20台
ウィットネスサイト:仮想アプライアンス1台(vSphere 環境にデプロイ)
合計40台+ウィットネスホストから構成されます。
従来はサイトあたり15台まででしたので、クラスタあたり10台増やせることになりました。
ファイルサービス
vSAN 7.0 から追加された機能であるファイルサービス。
現在、NFSとSMBのプロトコル、AD連携やKerberos認証に対応しています。
vSAN 7.0 U2ではストレッチクラスタ でも使用可能になりました!
ストレッチクラスタだけでなく2ノード構成のvSAN 環境でもサポートされます。
ファイルサービス、ちょっとあると便利が通常のクラスタだけでなくストレッチクラスタ でも使えるのが嬉しいですね。
DRS連携
vSAN 7.0U2でのアップデートは、
vSAN の再同期を待ってからDRSが行われるようになりました!
メリットとしてはサイト間ネットワークを優先的にストレージの再同期に使用させることで、復旧時間の短縮となります。
ローカルからの読み取りとなり、サイトをまたいだデータの読み取りも行われないので、再同期中の読み取り遅延も縮小することができます。
サーバはサーバ、ストレージはストレージとアクティブアクティブなデータセンタを構成するときはそれぞれに役割があります。
サーバ部分はvSphere のHA クラスタとしてサイトアフィニティや仮想マシンのアフィニティグループの定義をすることによって、クラスタは1つだけれども明示的にサイトを意識させます。
ストレージ部分は主にデータのサイト間保護、2つのサイトに同期されたデータを保管する役割があります。
では、ストレッチクラスタ の動きを見ていきましょう。
正常時、各サイトに配置された仮想マシンはローカルから読み取りを行い、書き込みは完全同期のサイト間ミラーリングとなります。
サイト間ネットワークの障害発生時にはvSphere HAにより切り替わり、仮想マシンが優先サイトで再起動されます。
データがきちんと別サイトに同期されているので、通常のHA と同様に切り替わります。
ネットワークが復旧すると再同期が始まります。
ネットワークが切断されていた時間に応じて差分の再同期となるので、かかる時間は構成や稼働状況により異なります。
vSAN 7.0 U1 まではこの復旧後にDRSが発動していました。
先にDRSが始まってしまうと再同期完了前だった場合、読み取るデータが優先サイト、仮想マシンはセカンダリサイトに配置されている可能性があります。
そうすると、サイト間ネットワークを再同期のためのIOと読み取りのためのIO、通常の書き込みのIOが通ることになります。
vSAN 7.0 U2 からは再同期の完了を待ってからDRSが開始されます。
これにより再同期が優先され、ストレージも含めた完全復旧時間の短縮となります。
再同期を待ってからのDRSについては自動的に行われるので、設定は不要(設定変更も不可)となります。
vSAN 7.0 U2シリーズはこちら
vSphere / vSAN 7.0 Update 2 GA !!!
vSAN 7.0 Update 2 詳細編① vLCM の進化!
vSAN 7.0 Update 2 詳細編② 障害時の挙動ってどう変わったの?