日本ヒューレット・パッカード株式会社の中川明美です。
今回は、vSphere 6.5でアップデートされたvSphere HAの次の3つの機能についてご紹介します。
- Proactive HAの構成
- ホスト障害への応答
- 仮想マシンで許容するパフォーマンス低下
vSphere HAはvSphere基盤の可用性を提供する重要な機能です。運用に関わるエンドユーザー様を対象にトレーニングを実施してきた私には、追加された3つの機能はエンドユーザー様の声を反映したアップデートではないかという印象を受けます。
Enterprise Plusで提供されるDRSやサーバーのPluginが前提となる機能もありますから、ご提案時にはこれらの機能もふまえ、ご紹介いただけたらと思います。
#1: vCenter Sever Appliance_1 (コンポーネントおよびサービス / スケーラビリティ)
#2: vCenter Sever Appliance_2 (高可用性 / バックアップとリストア)
#3: 仮想ハードウェア Version 13 / VMware Tools Version 10.1
#4: 3つの管理ツール (vSphere Host Client / vSphere Client / vSphere Web Client)
#5: vSphere HA (Proactive HA / ホスト障害への応答 / 仮想マシンで許容するパフォーマンス低下)
#6: vSphere DRS (Predictive DRS / その他のオプション)
◆Proactive HAの構成◆
ホストを構成するハードウェアの障害により健全性が低下した時、どのように仮想マシンを保護するかを構成する機能がProactive HAです。
詳細には、ハードウェア障害の情報をProactive HAプロバイダからvCenter Serverが受け取り、vCenter ServerはProactive HAの構成内容をDRSへ知らせ、仮想マシンを移行します。
たとえばファンに障害が発生し健全性が低下した場合、仮想マシンの移行によって可用性が提供されます。Proactive HAプロバイダは、サーバーベンダーから提供されます。
<Proactive HAの有効化>
Proactive HAはvSphere HAの編集画面で、「Proactive HAをオンにする」を選択します。仮想マシンの移行(vMotion)により仮想マシンを保護するため、DRSの有効が前提となります。
<Proactive HAの構成>
構成には、「自動化レベル」と「修正」の2つがあります。「自動化レベル」では仮想マシンの移行方法を、「修正」では健全性が低下したホストの使用可否を指定します。
<自動化レベル>
「手動」と「自動化」があります。
- 手動：DRSと同様に仮想マシンの移行先が推奨されます。
- 自動化：仮想マシンは健全なホストに移行され、健全性が低下したホストは検疫モードまたはメンテナンス モードにしたがい使用の可否が決まります。
![]()
<修正>
「検疫モード」「混合モード」「メンテナスモード」があります。
- 検疫モード：一部のハードウェア(メモリ/ネットワーク/ストレージ等)の障害にともない、性能が低下したホストを使用しません。ただし、仮想マシンのパフォーマンスに影響がない範囲においてです。
- 混合モード：検疫モードの状態に加え、重大な障害が発生したホストは使用しません。
- メンテナンスモード：一部のハードウェアに障害が発生したホストは使用しません。
<Proactive HAプロバイダ>
ホストの健全性をチェックするには、サーバーベンダーが提供するProactive HAプロバイダが必要です。Proactive HAプロバイダに対応する vSphere Web Client プラグインをインストールすると、Proactive HAプロバイダが表示されます。プロバイダを選択後、Proactive HAプロバイダは有効になります。
※Proactive HAプロバイダ
HPEサーバーは、「OneView for VMware vCenter」を導入します。Proactive HAに対応するOneViewは2017年11月提供予定です。
Dellサーバーは、「OpenManage Integration for VMware vCenter」を導入します。
Proactive HAプロバイダの詳細については、各サーバーベンダーへお問い合わせください。
◆ホスト障害への対応◆
vSphere 6.5では、vSphere HAによる再起動のオーケストレーション(Orchestration)を設定することができます。再起動の優先順位と仮想マシン間の依存関係を構成することによって、より詳細な再起動の順序を指定することができます。
下図はクラスタの設定画面です。
仮想マシンは、次の条件を満たすと他のホストへの配置や再起動の準備が整います。
- 他のホストに仮想マシンのリソースが予約されている
- 仮想マシンはパワーオンしている
- VMware Toolsのハートビートが検出される
- VMware Toolsアプリケーションのハートビートが検出される
各仮想マシンの設定は、「設定」の「仮想マシンのオーバーライド」を使用します。設定対象の仮想マシンを追加します。
<仮想マシン再起動の優先順位>
優先順位は5つのレベルがあります。優先順位が高い仮想マシンを再起動後、次に優先順位が高い仮想マシンを再起動します。
ただし、次の場合は異なります。
- エージェント仮想マシンは最初に起動する
- vSphere FTのセカンダリ仮想マシンは、他の仮想マシンより優先される
<優先度が次に高い仮想マシンを次の場合に起動/遅延時間の追加>
依存関係は、再起動の優先順位と特定の条件に一致した場合の遅延時間で指定します。
「割り当てられたリソース」「パワーオン」「検出されたゲストのハートビート」「検出されたアプリケーションのハートビート」のいずれかの条件を満たした後、指定された遅延時間を待って、次に優先順位の高い仮想マシンを再起動します。
<または次におけるタイムアウトの発生後>
指定した条件が満たされない場合はタイムアウトになります。指定したタイムアウト値までに条件が満たされなければ、vSphere HAは次に優先順位の高い仮想マシンの再起動へ進みます。
<仮想マシングループ間アフィニティルールを利用した依存関係の構成>
依存関係を構成するには、仮想マシングループ間のルールを利用することもできます。
特定の順序で再起動しなければ正常に復旧しない複数層のアプリケーションには有効です。一般的な例として、DB>>App>>Webの3階層システムがあります。
たとえば、障害があったホスト上にDB仮想マシンとWeb仮想マシンが稼働し、障害のないホスト上でApp仮想マシンが稼働していたとします。vSphere HAはDBとWebの仮想マシンはフェイルオーバーしますが、Appの仮想マシンは再起動しません。このような状況を回避する方法として、仮想マシングループ間のルールを利用します。
ただし、このルールには、DBが再起動しなければAppは再起動しないという課題があります。その場合は、手動でDBの仮想マシンを起動します。
vSphere HAはホスト障害に対する可用性を提供する機能のため、このような課題は発生します。今後のさらなる改善が期待されます。
◆仮想マシンで許容するパフォーマンス低下◆
本題に入る前に、アドミッション コントロールの選択方法がわかりやすくなりましたね。
許容するホスト障害の台数を指定し、その後はフェイルオーバー時のリソース予約をするか否か、するのであれば3つのうちのどの方法で予約するのかという流れになっています。
さらに、クラスタのリソース使用率がフェイルオーバー キャパシティの割合を超えた場合、警告を表示する機能が追加されました。この機能は、クラスタリソースの使用状況を取得するために、DRSを有効にする必要があります。
下図のvSphere HAクラスタはESXiホスト2台で構成し、「クラスタで許容するホスト障害」を1台に設定しています。
フェイルオーバー リソースの自動計算により、CPU50%/メモリ50%がフェイルオーバーキャパシティとして予約されています。
「仮想マシンで許容するパフォーマンス低下」でしきい値を「0」%に設定すると、クラスタのリソース使用率がフェイルオーバーキャパシティを超えた時、クラスタの「サマリ」タブに下図の警告が表示されます。この警告によって、リソース不足によって仮想マシンが再起動されない状況を回避することができそうですね。
◆まとめ◆
vSphere HA 6.5で追加された機能は、「ESXiホストの障害時にあわてなくても大丈夫。追加機能を活用して可用性を高めましょう。」と言われたような気がしました。「備えあれば患いなし」という言葉が浮かびます！
「Proactive HA」および「仮想マシンで許容するパフォーマンス低下」はDRS機能を前提とするため、Enterprise Plusのライセンスが必要です。vSphere 6.5へUpgradeを検討されていらっしゃるエンドユーザー様は、運用の効率性も見据えてご検討いただければと思います。
次回は、vSphere DRSでアップデートされた機能をご紹介します。個人的にはvRealize Operations Managerと連携する「Predictive DRS」にとても興味があります。
予算が許されるなら、「vSphere with Operations Management (vSOM)」を検討したいですね！
The post ここが変わった！ VMware vSphere 6.5 Part5 appeared first on Japan Cloud Infrastructure Blog.