【VMware認定資格】VCAPへの道【VCAP6.5-DCV Deploy Section 4対策編】

VMware

【VMware認定資格】VCAPへの道【VCAP6.5-DCV Deploy Section 4対策編】

まえがき

本記事は、VMware認定資格 VCAP-Deployの試験対策記事です。(対象vSphere バージョンは6.5)
本記事は、記事投稿者が当該試験を受験前に自己学習のまとめとして掲載しているものですので、記事作成時点では投稿者は試験で実際に問われる設問を一切把握しておりません。

記事の内容は、当該試験の公式出題範囲から出題される可能性が高そうなものを独自に予測したものですので、その点をご留意の上お読みいただけますと幸いです。

なお、本記事の親記事はこちらですので、他のSectionについても同様の情報を参照されたい場合は以下のリンクも是非ご覧ください。

【VMware認定資格】VCAPへの道【VCAP6.5-DCV Deploy 対策編】

vSphere HAの機能概要/有効化/初期設定

vSphere HAは、Essentials Plusで利用可能なフェイルオーバークラスターですね。共有ストレージを用いて、仮想マシンの停止イベントが発生した場合に、コンピュートノードを切り替える事でフェイルオーバーを実装している機能です。(本機能のコンセプトは、自動化された迅速な仮想マシンの復帰にあります)

私も大好きな機能で、VMware Storage & Availabirity Business Unit のCTOであるDuncan Epping氏がリードされているテクノロジーです。世界的にも有名な、”Yellow-Bricks“を読めばvSphere HAのDeepな情報が得られますから是非オススメです。

vSphere HAに関する記事も、素晴らしいものがありますので、基礎の確認はこちらでお願いします。
押さえておきたいvSphereの基本-可用性編 vSphere HA/FT(VMware Blog)

vSphereの可用性(VMware Docs)

今回は試験対策という事で、本機能の有効化と初期設定について確認をしていきます。今回も、VMware Hands On Labの”HOL-1910-01-SDC – Virtualization 101: Introduction to vSphere“を利用します。同じ操作を行いたい方は、こちらのラボをレンタルの上下記手順に従い練習が可能です。

まずは機能の有効化からです。該当のクラスターを左のツリー上で選択後、設定用タブをクリックし、”vSphere Availability”というメニュー内の”Edit”をクリックしましょう。

上図はグレーアウト状態ですし、中を見てみると”vSphere HA is Turned Off”の記載がありますね。
次の画面では、本機能を有効化します。”Turn On vSphere HA”を選択しましょう。
もう1つ下にある”Proactive HA”は、”vSphere HA”とは異なる機能ですので、注意しましょう。

機能有効化のチェック後は、デフォルトの障害に対応する振る舞いは次の通りとなっています。
ホスト障害へは仮想マシンを再起動して復帰するようになっていますが、それ以外の障害シナリオにも対応する必要がある場合は、こちらのプルダウンでそれらを指定しましょう。

フェイルオーバー用のCPU/メモリリソースを予約しておきたい場合には”アドミッション コントロール”を使いましょう。デフォルトでこちらの機能は無効(Disabled)ですが、3つのリソース確保手法がありますので、違いを抑えて状況ごとに使い分けましょう。

アドミッションコントロールの基本的な考え方を復習したい方は、こちらのページを参照ください。
vSphere HAのアドミッション コントロール(VMware Docs) 

無事にvSphere HAが設定されると、次のようにTurn Onと表示されます。
有効化の際には、各ESXiホストにvSphere HA用のソフトウェアである”Fault Domain Manager”がvCenter Serverよりプッシュインストールされますので、”最近のタスク”ではそのインストールの進捗を確認することが出来ます。体感では1分少々でこの作業は完了します。

vSphere FTの機能概要/有効化/初期設定


vSphere FTは、完全ダウンタイム無しのクラスタリング機能です。

この機能は、vSphere HAが有効化されたクラスター上にてのみ構成が可能です。

本機能の有効化は、保護対象の仮想マシンを右クリックすることで機能の有効化が可能です。

クラスター機能で有りながら、クラスターが操作対象ではない点は少しトリッキーです。また、vSphere HAが無効な状態でこの操作を試した場合は、vSphere FTの項目はグレーアウトしているので、混乱しないように気をつけましょう。

そしてもう1つ重要な点があります。
それは各ホストが、”vSphere FT用のVMkernel アダプター”を設定されていることです。vSphere FTでは、常に2つのホスト間でメモリ状態を同期します。このためネットワーク設定がこちらです。


設定そのものは、ただチェックを入れるだけですので、操作自体は簡単です。
VMware HOL上では、管理用VMkernel アダプターに対して設定を入れる事が出来ますので是非試してみてください。

vSphere FTを有効化する際には、次の2つの設定を入力します。 1つ目は、2台目の仮想マシンの保存先を指定します。
この際、VMDKや仮想マシンの構成ファイルやスプリットブレイン回避用のファイルを保存する先を個別に指定したい場合は、下図のように指定が可能です

2つ目は、2台目の仮想マシンを動作させるホストを指定します。今回は警告メッセージとして、”1台目と2台目の仮想マシンがデータストアに保存されており、非推奨な構成”であるという事が記述されています。(あくまでも今回はvSphere FTの設定手順を確認しているだけですので無視をします)

実際に有効化した後、該当の仮想マシンは少し青色が濃いアイコンに変わります。またFault Toleranceの項目が追加されました。

仮想マシンを起動すると、保護状態が”Protected”に変化しました。

以上で、vSphere FTによる保護が完了したと言えます。

vSphere DRSの機能概要/有効化/初期設定

vSphere DRSは、vSphere Enterprise Plusライセンスでのみ利用が可能なワークロード分散機能ですね。

仮想マシンの起動時には、リソースの利用状況の観点から仮想マシン自体が快適に動作が出来る箇所に配置されます。

稼働中の仮想マシンに対しても、vMotionのネットワーク構成が実装されている場合は、一定のトリガーと条件を持って、”自動的に”または”ユーザーの承認”を持って、vMotionが自動実行されます

DRSについても機能が登場してから多くの記事が出ていますので、いくつかご紹介します。

押さえておきたいvSphereの基本-可用性編 vSphere DRS
vSphereのリソース管理(VMware Docs)

機能自体の有効化はvSphere HAやFTと似たような操作となります。なお、上述しているvMotionによる稼働中の仮想マシンの移行のためには、vMotionネットワークがホストに対して構成されている必要があります。
DRS クラスタのvMotion要件(VMware Docs)

まずは機能の有効化からです。該当のクラスターを左のツリー上で選択後、設定用タブをクリックし、”vSphere DRS”というメニュー内の”Edit”をクリックしましょう。

Editをクリック後は、”Turn On vSphere DRS”にチェックを入れます。DRSによるvMotionの実行頻度や上述しています仮想マシンの配置についてを、全てvCenter Serverに任せるのか、ユーザーの承認をもって行うかなどの、細かな設定は下図内の各種オプションによって選択が出来ます。

今回は試験対策ということで、画面の様子をお見せすることに特化をしていますので、各種メニューの詳細については、公式ドキュメントや他のブログ記事を参照頂くようお願い致します。

DRSが無事有効になると、下図のように”シーソー”のアイコンがクラスターに付帯されます。(バランスを取るという意味合いでしょう)
また画面内右下にも、”vSphere DRS”のウィンドウが追加されました。

なお、DRSと言えば、vSphereにおける機能として、”リソース プール”や”vApp”と呼ばれる、仮想マシンのためのリソース調整機能の前提条件となっています。今回はDRSが有効になったので、試しにそれらの2種類を作成してみました。(上図内、Practice-RPとPractice-vApp)

FTの有効化のためには、まずはvSphere HAが有効でなければならないように、DRSもリソースプールなどの機能については同様の振る舞いとなるため、この点は対策のために是非とも抑えておきたいと言えます。

vSphere HAにおけるフェイルオーバーリソースの確保及びフェイルーオーバー順序の制御

フェイルオーバーリソースの確保については、既に上記の項目の”アドミッション コントロール”方式でお話をしましたが、3通りのリソース確保手法があります。事前に違いを把握しておきましょう。

クラスタ リソースの割合アドミッション コントロール(VMware Docs)

スロット ポリシー アドミッション コントロール(VMware Docs)

専用フェイルオーバー ホストのアドミッション コントロール(VMware Docs)

私の経験上は、最も利用されているなと感じるのは、”クラスタ リソースの割合アドミッション コントロール”です。

次に、仮想マシンのフェイルオーバーの順番についてです。こちらについては、現在では5段階のプライオリティがあります。(Highest → High → Medium → Low → Lowest)
もちろんですが、左から順に起動が実行されていきます。下図内では赤枠の箇所がそれを示します。

問題は、緑の箇所です。これは何を示すのか?
例えば、”Highest”の仮想マシンを全て起動し終えた後、次は”High”の仮想マシンの起動に移行するわけですが、何を持って次の層に移行するのか、という条件していがこちらです。

  1. Resource Allocated リソースがアサイン出来たら、(次のプライオリティの起動へ移行する)
  2. Power ON 電源ステータスがONになったら、(次のプライオリティの起動へ移行する)
  3. Guest Hertbeats detected ゲストOS内のVMware Toolsが起動し、そこからのハートビートが確認されたら、(次のプライオリティの起動へ移行する)
  4. App Heartbeats detected ゲストOS内の指定のアプリケーションが起動し、そこからのハートビートが確認されたら、(次のプライオリティの起動へ移行する)

1と2ですが、これらには殆ど差がないのに加え、起動プライオリティの層間でのタイムギャップはほぼ0になることが殆どです。ですから、HighestとHighが同時に起動したように見えてしまいます。

ドメインコントローラーやDNSなどのように、インフラストラクチャの根幹を担うような仮想マシンは、確実に他の仮想マシンよりも先に起動しているべきです。この点を考えますと、確実にそれらのサービスがOS内で振る舞うことを保証するためにも、上記の1~4の中では、3または4が現場では活躍する可能性が高いです。

という、同じことを、Duncan Epping氏も次の記事で記述されております。
vSphere HA Restart Priority(Yellow Bricks.com)

なお、実際の仮想マシン個別に、起動優先度を設ける場合は、次のように、”仮想マシンのオーバーライド”メニューを利用します。
今回は、仮想マシン”linux-micro-01a”を”Highest”として設定しました。

次の起動順序への移行トリガーは”クラスターレベルでの設定に従う”としておりますので、クラスター”Cluster Site A”自体が持つ設定を利用する形になります。

是非このメニューは試験だけではなく、実際の現場でも大変重要ですので使いこなしましょう!

vSphere FTの制限事項

vSphere FTを構成する際には、いくつかの制限があります。こちらについてはナレッジもまとめられていますので事前にこちらを確認ください。
Fault Tolerance の要件、制限、およびライセンス(VMware Docs)

FAQ: VMware Fault Tolerance (1013428)

アフィニティルールとアンチアフィニティルールに基づく仮想マシンの制御

アフィニティ ルールは、仮想マシンが動作するホストについてユーザーが構成したルールにより定義が可能です。設定入力箇所は次の赤枠内から行います。

この機能を使うと、次のような事が出来るようになります。

  • ある仮想マシンとある仮想マシンは、同じホスト上で動作する必要がある
  • ある仮想マシンとある仮想マシンは、同じホスト上で動作してはいけない
  • ある仮想マシンは、特定のホスト上で動くようにする
  • ある仮想マシンは、特定のホスト上で動かないようにする

以下の図内では、仮想マシングループ”CRM-VMs”というグループ内の2台の仮想マシン(App-VMとDB-VM)は、ホストグループ”Servers”内の2台のホスト(esx-01a.crop.localとesx-02a.crop.local)上で動作をするように設定しています。基本的にはこれらのホスト上で動作し、障害などに伴い条件を満たせない場合はここに記述がないホストにもフェイルオーバーする設定です。(Shouldルール)

より強制度を高くする場合は、Mustルールを利用します。
これにより確実に指定されたホスト以外で動作することがなくなります。(これによりHAのフェイルオーバーでも、指定されたホスト以外をフェイルオーバー先とは出来なくなりますのでご注意ください)

試験においても、フェイルオーバー時の挙動を制御するためにこれらの設定で、ShouldまたはMustのルールを使い分けられるか?を問われる可能性がありますので、是非抑えておきましょう!

コメント