"HCI" はじめました。

vSAN担当小佐野舞です。VMwareのHCIを広めるため日々活動していきます。

vSAN 7 Update 3 詳細編⑤ 2ノードクラスタ/ストレッチクラスタの2サイト障害時の対応

vSphere / vSAN 7.0U3 ダウンロード/公式情報はこちらから

vSphere / vSAN 7.0 Update 3 ダウンロード

VMware vSAN 7.0 Update 3 リリース ノート

vSAN 7 Update 3 - What's New 

 

 

 

2ノード・ストレッチクラスタ、それぞれのトポロジ詳細

vSAN ストレッチクラスタ/2ノードクラスタの場合は、ウィットネスホストを使用してサイト間やノード間のどちらが生きているかを判断しています。

まずストレッチクラスタや2ノードクラスタの基本から設定までの記事は下記を参照ください。

ストレッチクラスタの情報はこちらから!

vSAN ストレッチクラスタ①:ストレッチクラスタとは?

2ノードクラスタの情報はこちらから!

2ノードクラスタ その1

 

 

何が変わったのか?

ストレッチクラスタ、2ノード構成において一つのサイトまたはまたは1ホストのみが残っている状態で仮想マシンを稼働し続けることができるようになりました。

サイト(ストレッチ)/ホスト(2ノード)のメンテナンス時において予期せぬウィットネス障害にも対応できるようになった!と言い換えるとわかりやすいですね。

ただ注意点としては障害がどのような順序で発生したのかは重要になります。

セカンダリサイトに続いて、ウィットネスサイトの障害が発生した場合、残ったサイト/ホストで仮想マシンを稼働させることができます。

(もちろん残ったサイト/ホストが健全な状態で!)

障害復旧後はポリシーに準拠するよう再同期が行われます。

 

 

前提条件

きちんとストレッチクラスタ/2ノードクラスタの設定が行われていること、が条件になるのですが、設定項目としてのストレージポリシーを見ていきましょう。

ストレッチクラスタ

サイトの耐障害性がサイトミラーリングと設定されていること

 

2ノードクラスタ

サイトの耐障害性はホストミラーリングと設定されていること

 

 

障害のタイミング

どんな状況でも1サイト/1ホストが健全な状態で残っていたら、仮想マシンの継続稼働可能というわけではありません。

セカンダリサイトのサイト全障害またはサイト全体のメンテナンス

↓ この間、数分は必要

ウィットネスアプライアンスの障害

この順番でないとこの新しい保護機能は発動されません。

この機能のアップデートが行われた背景としては、メンテナンス時にウィットネスが止まってしまった場合、従来のバージョンでは残っているサイト/ホストに配置されている仮想マシンが稼働できなくなってしまうことでした。

 

セカンダリサイトのメンテナンス中にウィットネスアプライアンスの障害が発生するとどうなるのか?

ストレッチクラスタの例を挙げると。

Before 

プライマリサイトで稼働していた仮想マシンが止まってしまう。

サイト内の健全性がOKであってもポリシーでサイトミラーリングが適用されている場合はウィットネスアプライアンスがいない場合、止まってしまいます。

 

 

After

プライマリサイトの仮想マシンは稼働し続けることができるようになりました!

 

 

 

 

中身をもっと詳しく!

今回のアップデートのアーキテクチャの中心はAdaptive Quorum Controlによるサイト監視です。

まず可用性を担保するためvSAN の各コンポーネントはvoteを持っています。

過半数以上のvoteがある場合、仮想マシンが起動可能・継続稼働可能となります。

そのため、ウィットネスコンポーネントが存在します。(FTT=1ミラーリング)

これは通常のvSANクラスタ、ストレッチクラスタ、2ノードクラスタ、全てに共通しています。

 

今回、サイト/ホスト メンテナンス中の予期せぬウィットネスアプライアンスの障害が発生しても残りのサイト/ホストで仮想マシンを稼働し続けるためにAdaptive Quorum Control という機能が追加されました。

https://images.core.vmware.com/sites/default/files/GIF_SC_resilience_v2_0.gif

公式サイトのGIF動画がわかりやすいのでまずこれを見てみましょう。

ストレッチクラスタの構成は下記で設定されています。

仮想マシンのストレージポリシー

 サイトミラーリング

 許容する障害の数(ローカル保護)=1

 

障害が発生する前のvote数を見ると合計5 votesあります。

 プライマリサイト 1

 セカンダリサイト 1

 ウィットネスアプライアンス 3

 

ストレッチクラスタセカンダリサイトの障害が発生すると、自動的にウィットネスが持っていたvoteが3から0になり、プライマリサイトが3votesとなります。

 プライマリサイト 3

 セカンダリサイト 1

 ウィットネスアプライアンス 0

 

これにより、ウィットネスアプライアンスがいなくなっても3/4の過半数を持っているプライマリサイトのみで仮想マシンを稼働し続けることができます。

障害復旧後は自動的にvotesの移行が行われます。

 

 

 

ストレッチクラスタの例ばかりあげていますが、避けて通れないメンテナンス時の保護という点では2ノードクラスタにもとても嬉しいエンハンスメントです。

 

2ノードで試してみたら、本当に止まらなかった...!は次回更新します。

 

 

 

vSAN 7.0 Update3

vSAN 7 Update 3 GAしました...!(サマリ編)

vSAN 7 Update 3 詳細編① 2ノードクラスタにおける可用性の向上 その1

vSAN 7 Update 3 詳細編② 2ノードクラスタにおける可用性の向上 その2

vSAN 7 Update 3 詳細編③ クラスタ一括シャットダウン

vSAN 7 Update 3 詳細編④ vLCM を使用したクラスタのアップグレード