本投稿はvExperts Advent Calendar 2016への寄稿も兼ねて、

あまり一般的には使われていないvSAN Stretched Clusterがどんなものか、実際に2台のVxRailを利用してクラスタを組む際のポイントをまとめてみました。

画面キャプチャ多用していますので、こういう導入手順なんだ、と眺めていただければ幸いです。

 

今回はデータセンターを跨いでRTT 5ms以下で10Gbpsの帯域を持つネットワークはとても用意できないので、隣のラック、別のTop Of Rack スイッチに接続された2セットのVxRailアプライアンスを利用しました。

 

ラックやサーバールーム、建屋を跨いだVSANの可用性担保をFault Domainの機能を用いて実装するのですが、

通常のFault Domainではなく、Stretched Cluster用のVSAN Witnessを利用することで、2セットのアプライアンスでもFault Domainが構成可能となります。

 

※今回はvSAN 2Node Clusterを組む要領で、VxRail 2アプライアンス Stretched Clusterを組んでみたのでそのレポートです。

 

※実際に本番環境でVxRailでStretched Clusterを組む際にはDELL EMCにRPQ(Request Per Qualification)を申請し、サポート承認を得る必要がありますのでご注意ください。

 

VxRailでのStretched Clusterに関しては以下のWhite Paper、Tech Bookを参照にしました。

今回はラック跨ぎのStretched Clusterとしたため、本来必要となるデータセンター間、Witnessサイト間とのネットワーク遅延やL3 スタティックルートの設計など、細かな要件を端折っています。それぞれの要件についてはドキュメントを参照願います。

 

【DELL EMC VxRAIL PLANNING GUIDE FOR VIRTUAL SAN STRETCHED CLUSTER 】

https://www.emc.com/collateral/white-papers/h15275-vxrail-planning-guide-virtual-san-stretched-cluster.pdf

 

【VMware Virtual SAN 6.2 Stretched Cluster & 2 Node Guide】

http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vsan/vmware-virtual-san-6.2-stretched-cluster-guide.pdf

 

【VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance】

https://www.vmware.com/files/pdf/products/vsan/vmware-virtual-san-6.1-stretched-cluster-bandwidth-sizing.pdf

 

 

 

■ VxRail 2Appliance vSAN Stretched Cluster の概要図

vsansc02.png

 

 

■ vSAN Stretched Clusterを組む前の事前準備

通常、VxRailはデフォルトでバンドルされている(出荷時にデプロイされている)vCenter Server Applianceを利用してクラスタをセットアップしますが、

vSAN Stretched Clusterの場合は、2セットのVxRailはデータと仮想マシンの格納場所として利用し、

vCenterは既設の管理クラスタ上に、vSAN Witness Applianceとともに設置したものを利用します。

 

※VxRail 3.5以降では外部vCenter(External vCenter)構成も正式にサポートされているので、既存で利用しているvCenter配下にVxRailのvSANクラスタを組み込むことも可能になりました。

 

FILESV01_VxRail4.0_StretchCluster_20161218_001a.png

今回はこのvCSAとPSCを別の管理クラスタ上に作成し、VxRailを格納する空のDetaCenter 「DataCenter-A」と「DataCenter-B」を作成しておきます。

 


■ vSAN Witness Appliance のデプロイ

vSAN Witness Appliance は所謂 Nested ESXiの様な形をしたvSAN Witness機能専用の軽量ESXiとして、vSphere上にデプロイします。

予めMy Vmwareから利用するvSANと同じバージョンのvSAN Witness Appliance のOVAファイルをダウンロードしておきます。

FILESV01_VxRail4.0_StretchCluster_20161218_037.png

OVAテンプレートのデプロイは通常の仮想アプライアンスの導入と変わりありません。


FILESV01_VxRail4.0_StretchCluster_20161218_046.png

サイズや配置先データストアは用途によって異なりますので割愛しますが、

vSAN Witness Appliance はvCenterとの通信、vSANの通信が必要となるためデプロイ先のクラスタのネットワークには、

予めvSANネットワークとの疎通のあるポートグループを作成しておきます。

※リモートサイトに置く場合など、L3でのルーティングが必要な場合はStatic Routeを設定しておきます。

 

FILESV01_VxRail4.0_StretchCluster_20161219_009.png

デプロイしたvSAN Witness Appliance を起動すると、見た目は普通のESXiのコンソールが立ち上がります。

通常のESXiを初期設定するように、IP、ホスト名、DNSなどの設定を投入します。

ここではSSHを有効にしておくと後々の設定変更に便利です。

 

FILESV01_VxRail4.0_StretchCluster_20161219_017a.png

初期設定が終わったvSAN Witness Appliance は外部vCenterとなるvCSAとPSCと同じ環境に設置しました。

 


■ Stretched Cluster プライマリサイト側VxRail のセットアップ

 

今回は前項で事前に用意したExternal vCenter環境配下にVxRailを展開します。

FILESV01_VxRail4.0_StretchCluster_20161218_073.png

お馴染み(?)のようこそ画面からいつも通りVxRailをセットアップします。


FILESV01_VxRail4.0_StretchCluster_20161218_077.png

今回は最新のVxRail 4.0を利用したので、初期セットアップ時にどのアプライアンス、どのノードに対してセットアップを行うかがスキャンされるようになりました。

最小は3ノードから構成可能です。

 

FILESV01_VxRail4.0_StretchCluster_20161218_081a.png

いつもと違うセットアップ項目は以下の画面で「既存のvCenter Serverの結合」「外部 Platform Service Controller」にチェックを入れ、

既存環境のFQDN、vCenterの認証情報を投入しておく事です。

今回は予め作成済みの「DataCenter-A」 配下に「vSAN StretchCluster」を作成してVxRailが組み込まれるようにします。

 

FILESV01_VxRail4.0_StretchCluster_20161218_089.png

設定内容に問題がなくValidationが通ればVxRailのセットアップが始まります。

※ここでValidationが失敗する例として、DNSでのFQDNでの名前解決が通らない事や、VxRailのアップリンクの10Gスイッチの設定漏れ、特にvSANが利用するマルチキャストの設定漏れなどがありますので、エラーが出たらメッセージに従ってネットワーク周りを重点的に確認しましょう。

 

FILESV01_VxRail4.0_StretchCluster_20161218_099.png

External vCenterを利用する場合、vCSAのFirst boot scriptなど時間がかかる処理がないので、それこそ10分もあればVxRailのセットアップはあっという間に完了してしまいます。

 

FILESV01_VxRail4.0_StretchCluster_20161218_118.png

セットアップが完了すると、External vCenterでは以下のようにクラスタに格納されます。

 

FILESV01_VxRail4.0_StretchCluster_20161219_004.png



■ 次にvSAN Witness Appliance を「DataCenter-B」にESXiホストとして追加します。

FILESV01_VxRail4.0_StretchCluster_20161219_023.png

追加方法はいたって簡単。

 

FILESV01_VxRail4.0_StretchCluster_20161219_027.png

デプロイ後、VMkernel アダプタの設定を確認するとvSAN用ポートが設定されていないので、IPを割り当てます。

FILESV01_VxRail4.0_StretchCluster_20161219_032.png

 

vSAN VMkernelにIPを割り当てた後は、

vSAN Witness Appliance にSSHでログインし、それぞれのVxRailノードのvSANカーネルに対してvmkpingでIP疎通があることを確認しておきましょう。

 


■ Stretched Cluster セカンダリサイト側のVxRailのセットアップ(既存へのノード追加)

FILESV01_VxRail4.0_StretchCluster_20161219_034a.png

VxRailのノード追加は非常に簡単で、既存VxRailと管理ネットワークの疎通がある状態で追加ノードの電源を投入すると自動検知され「ノードが検出されました」と追加ウィザードのボタンが有効になります。


FILESV01_VxRail4.0_StretchCluster_20161219_035.png

追加ノードに必要なパラメータは各ノードのVMkernelに割り当てるIP(管理・vMotion・vSAN)と、既存のESXi、vCenterのパスワードのみです。

ここで4ノード追加するので予め4つ分まとめてレンジでIPを投入しました。

 

FILESV01_VxRail4.0_StretchCluster_20161219_041.png

追加は初期導入よりもっとスピーディで、1ノードあたり3分~4分で完了します。

スケールアウトの簡単さはHCIのメリットですね。


FILESV01_VxRail4.0_StretchCluster_20161219_045.png

4ノードすべて正常に拡張が完了しました。

 

 

■ vSAN Stretched Clusterの有効化

 

今回のメイン、vSAN Stretched Clusterを有効化します。

FILESV01_VxRail4.0_StretchCluster_20161219_051a.png

前項までに初期セットアップが完了したVxRailノード合計8台があります。

ここではStretched Cluster(拡張クラスタ)もFault Domainもまだ設定されていません。

 

まずはStretched Clusterを有効化します。


FILESV01_VxRail4.0_StretchCluster_20161219_054.png

まず8台のノードを、プライマリサイトの4台と、セカンダリサイトの4台で分けます。

※今回は同一サイト内・別ラックで構成しているのでラック全断障害などを想定した構成です。

 

FILESV01_VxRail4.0_StretchCluster_20161219_056.png

監視ホスト(vSAN Witness)の設定は「DataCenter-B」に配置したvSAN Witness Appliance を選択します。

 

FILESV01_VxRail4.0_StretchCluster_20161219_061.png

設定はすぐに反映されます。

メインの作業はこれだけです。拍子抜けするほど簡単ですね。

 

■ vSAN Health Checkでエラーがないか確認

見た目なにもエラーがなくても油断しないでHealth Checkを確認しましょう。

vSphere 6.0 u1からはvCenterにデフォルトで組み込まれたHealth Check (以前はpluginで配布されていた)は

vSANの構成、データの同期状態など細かく状態確認が可能です。

FILESV01_VxRail4.0_StretchCluster_20161219_064a.png

ここではvSANを構成する8台のノードと、vSAN Witnessで詳細設定(ノード拡張上限、ネットワークヒープ値)が異なると指摘されているので、vSAN WitnessにSSHでログインしてさくっと直してしまいます。

 

[root@rgm-96x:~] esxcli system settings advanced set -o /VSAN/goto11 -i 1

[root@rgm-96x:~] esxcli system settings advanced set -o /Net/TcpipHeapMax -i 1024

 

変更したらvSAN Witnessを再起動し、警告が消えたことを確認します。


 

■ その他の健全なクラスタ運用のための諸設定

ここまででだいたいvSAN Stretched Clusterの設定は完了しましたが、

通常のHAクラスタの冗長性で考慮するN+1の構成ではなく、今回は1+1の構成なので、サイト障害時(片系アプライアンス全断)時には

リソースの負荷が残った方にすべてフェイルオーバーしてくるので、HAのアドミッションコントロールの予約値を50%に設定しておきます。

 

FILESV01_VxRail4.0_StretchCluster_20161219_070a.png

Active - Active のStretched Clusterを組むからには太っ腹であることが重要ですね。

 

また、仮想マシンを作成する際にも、どの仮想マシンが通常時どちらのサイトで稼働するかを指定しておいた方が

負荷のバランスと管理が行いやすくなります。


FILESV01_VxRail4.0_StretchCluster_20161219_077a.png

ここではDRSのアフィニティルール 「仮想マシンからホストへ」を利用して、仮想マシンが稼働するサイトを指定します。


FILESV01_VxRail4.0_StretchCluster_20161219_078.png FILESV01_VxRail4.0_StretchCluster_20161219_079.png

プライマリサイトのホストと仮想マシン、セカンダリサイトのホストと仮想マシンをそれぞれ

「グループ内のホスト上で実行してください」という英語表記では「Shuld」でルールを作成します。

※ここで「グループ内のホスト上で実行する必要があります」という英語表記での「Must」でルールを作成すると仮想マシンがフェイルオーバーできなくなってしまうので注意してください。

 

ここまで作成すれば、正常な状態時には仮想マシンの配置と、データの配置がきれいに管理でき、vSAN Health Checkの以下の画面で仮想マシンのデータの配置場所(どのホストのどのドライブに格納されているか)が簡単に確認できます。

FILESV01_VxRail4.0_StretchCluster_20161219_080.png

 


■ vSAN Stretched Clusterでの障害試験、HA挙動

 

最後に、組みあがったvSAN Stretched Clusterで障害(片系アプライアンス全断)の挙動を確認してみます。

以下の画面はIPMIでセカンダリサイトの全ノードを強制電源Offにした直後の画面です。

FILESV01_VxRail4.0_StretchCluster_20161219_082.png

きれいに半分にアラートが上がっています。

上で動いていた仮想マシン、今回はMS-07 ~ MS-09までが稼働していましたが、無事にHAが働き、プライマリサイトのノード上で再起動されたようです。


FILESV01_VxRail4.0_StretchCluster_20161219_085a.png

片系アプライアンス全断時には各仮想マシンのミラーされたデータの片方へのアクセスが出来ないので、

vSAN Health Check 上では以下のようにコンプライアンスエラー状態となります。


FILESV01_VxRail4.0_StretchCluster_20161219_086.pngFILESV01_VxRail4.0_StretchCluster_20161219_090.png

このエラー状態も、全断していたアプライアンスが起動してくれば元通りになります(デフォルトでは1時間以内の復旧時は差分データの同期のみで完了)。


■ まとめ

今回はデータセンター跨ぎではなく、ラック跨ぎのvSAN Stretched Clusterの作成でしたので、WitnessサイトへのL3ルーティングの設定や、サイト間遅延時間の考慮などは特にせず簡単に作り上げることが出来ました。

アプライアンス筐体障害やラック電源障害などによる全断を回避するための構成として度々Fault Domain構成は提案する事があるのですが、最低3ドメイン必要となるためなかなかハードルが高かったところを、vSAN Witnessを代用する事でシンプルに組むことが出来ました。

 

VxRailとして本番利用するためにはRPQを通してサポート承認が必要となりますが、

vSANとしてはこのように簡単に組むことが出来るので、ぜひ皆さんも一度試してみていただければと思います。