VMware Cloud on AWSの構造とハイブリッド管理（2）：詳説VMware Cloud on AWS（3）（2/3 ページ）

[大久光崇，ヴイエムウェア株式会社]

物理ホストの管理

　VMware Cloud on AWSはAWSのベアメタルインスタンスを物理ホストとして利用しているため、必要に応じて任意のタイミング、あるいは自動的に物理ホストの追加／削除が行われる。

　これは運用の効率化だけでなく、コストの面でも有利となる。コンピュートリソースの需要に応じて物理ホスト数を増減させ、コストの最適化が可能である。例えば、最低限利用されるベースのリソースについては、3年サブスクリプションでコストを抑えて物理ホストを確保し、変動分については時間単位のオンデマンドインスタンスで確保することで、トータルのコストを抑えることができる。

　また、VMware Cloud on AWSでは、物理ホスト管理の自動化が進められている。物理ホストが障害を起こした場合、正常な物理ホスト数に回復させるために、自動的に物理ホストの交換が行われる。さらには、現在の物理ホストに適さないコンピュートリソースの需要があった場合に、Elastic DRS機能により自動的に物理ホスト数の増減を行う。

　これらの特徴について、次の点に分けて、もう少し詳しく説明する。

• 物理ホストの追加
• 物理ホストの削除
• Elastic DRS
• 物理ホスト障害時の挙動

物理ホストの追加

　物理ホストの追加は、コンソールUI上またはAPIから、クラスタを選択して行う。クラスタに物理ホストが追加された後、vSphere DRSの配置の推奨が計算され、追加された物理ホストにもワークロードの仮想マシンが分散配置される。

　一度に複数台の物理ホストをクラスタに追加する指定ができるが、現在、物理ホストの追加は逐次的に行われる。物理ホストの追加は、1台当たりおおよそ12分程度かかるため、3台追加するのであればおおよそ30分強かかる計算となる。緩やかなリソースの増強、あるいは、余裕を持ったリソース追加を検討する必要がある。また、vSphere DRSの再配置を利用することはできないものの、必要台数分の物理ホスト数のクラスタを追加で作成すると、1台ずつ追加するよりも早くリソースを追加できる。

　追加分の物理ホストをオンデマンド料金で利用する場合、物理ホストが追加されると、当然ながら利用料が新たに発生する。予算をにらみながら計画的にリソースを運用していただきたい。

物理ホストの削除

　物理ホストの削除もコンソールUIから行う。削除対象の物理ホストがメンテナンスモードとなり、ワークロードの仮想マシンをDRSで全て残りの物理ホストへ移行させ、さらにその物理ホスト上のvSANキャッシュ／キャパシティーディスクから、仮想ディスクのデータを全て残りの物理ホストに移行させる。このため物理ホストの削除の時間は一定とはならず、vSANデータストア上のデータの配置状況に依存してしまう。追加と同様に複数台の物理ホストを削除できるが、削除も逐次的に行われることに注意したい。

Elastic DRS

　前述の物理ホストの追加／削除はUIやAPIを通じて能動的に行う操作だが、この物理ホストの追加／削除をクラスタの負荷の状況によって自動的に行うのが、VMware Cloud on AWS特有の「Elastic DRS」という機能である。クラスタサイズに関する、いわゆるスケールアウト／スケールインの機能となる。

Elastic DRSの動き

　Elastic DRSのスケールアウトは次のような処理になる。正常稼働時から仮想マシンの増加により、クラスタのリソース負荷が上昇する。この負荷が事前に設定されている閾（しきい）値を超えたとSDDC（Software Defined Data Center）が検知すると、自動的に物理ホストを追加してクラスタのキャパシティーを増強する。一定時間経つと、vSphere DRSによって仮想マシンが分散配置され、クラスタ内の物理ホストの負荷は均一となり、正常状態に戻る。

　反対に負荷が下がりクラスタのリソースが余り始めた場合は、Elastic DRSのスケールインが機能する。まず、仮想マシンの減少によりクラスタのリソースが余剰となる。この余剰が事前に設定されている閾値を超えたことをSDDCが検知し、物理ホストをメンテナンスモードに移行した上でクラスタから削除し、AWSに返却する。物理ホストがメンテナンスモードになった際に仮想マシンは、vSphere DRSによって残りの物理ホストに分散配置され、クラスタの負荷が均一となり、正常状態に戻る。

　スケールアウト／スケールインが実行されると、組織のメンバーに通知される。通知は、電子メール、コンソールUIの通知領域、およびコンソールUIのアクティビティログで行われる。

　Elastic DRSの設定はクラスタ単位で行い、顧客は最大物理ホスト数と最小物理ホスト数を設定できる。このスケールアウト／スケールインによって変動する物理ホストの数は、最大物理ホスト数と最小物理ホスト数に収まる。Elastic DRSにおけるリソースとは、CPU、メモリ、ストレージを指す。スケールアウトの場合は、いずれかのリソースが閾値を超えた場合に物理ホストが追加され、スケールインの場合は、全てのリソースが閾値を下回った場合に物理ホストが削除される。閾値の設定には3種類の設定が事前定義されており、いずれかを選択する。ユーザーはその閾値を変更することができない。閾値の設定は以下の通りである。

スケールアップの閾値

ポリシー	ストレージのみスケールアップ	パフォーマンスを最大にするための最適化	コストを最小にするための最適化
CPU	N/A	90%	90%
メモリ	N/A	80%	80%
ストレージ	75%	70%	70%

スケールインの閾値

ポリシー	ストレージのみスケールアップ	パフォーマンスを最大にするための最適化	コストを最小にするための最適化
CPU	N/A	50%	60%
メモリ	N/A	50%	60%
ストレージ	N/A	20%	20%

　デフォルトのElastic DRSポリシーでは、「ストレージのみスケールアップ」が選択されている。このポリシーでは最大／最小物理ホスト数を設定することはできず、ストレージの利用率が75%を超えるとElastic DRSが発動し物理ホストが追加される。SDDCのストレージであるvSANを安定的に稼働させるためには25%のスラックスペース（空きスペース）が必要なためである。スケールインは自動的に行われないため、必要な場合は手動でスケールイン、すなわち物理ホストの削除を行う。

　「パフォーマンスを最大にするための最適化」「コストを最小にするための最適化」のポリシーで異なるのは、CPU／メモリのスケールインの閾値のみである。コストが掛かってもパフォーマンスを確保しつつスケールインをより慎重に行うか、コスト効率を優先して積極的にスケールインを行うかの違いとなる。

　いずれのポリシーも、ストレージのスケールインに、20%という保守的な値が設定されている。分散ストレージの特性上、物理ホストを削除する際には保持する全てのデータを残りの物理ホストに転送する必要があるため、物理ホストの削除は時間が掛かるのが理由である。

　Elastic DRSは5分間隔でCPU／メモリ／ストレージの利用率を確認する。これはvCenter Serverが仮想マシンの分散配置を提供するvSphere DRSと同じ間隔である。リソースの利用率が閾値近辺を変動する場合、そのままではスケールアウト、スケールインを頻繁に繰り返すことになってしまう。これを避けるために、閾値の判定は利用率のスパイクとランダム性を考慮して行われる。また、スケールアウトを実施した後は30分、スケールインを実施した後は3時間のクーリング時間を確保し、連続してスケールアウト／スケールインが行われないようにしている。Elastic DRSのスケーリングは1物理ホストずつ行われるため、物理ホストのサイズが大きいとはいえ、比較的緩やかな負荷変動に適しているといえる。

　一方で、より迅速にスケールアウト／スケールインをさせたい代表的なケースとして仮想デスクトップ環境がある。仮想デスクトップ環境では、勤務時間前に大量の仮想デスクトップを確保するために物理ホストを増やし、勤務時間後に不要になった仮想デスクトップの削除に併せて物理ホストも削除することが望まれる。現時点では上記仕様により、この用途にElastic DRSは適していない。迅速なクラスタサイズの伸縮性を実現するにはスクリプトでの物理ホストの増減に頼ることになる。より迅速なElastic DRSが必要となる場合には、VMwareまでフィードバックをいただけると幸いである。

物理ホスト障害時の挙動

　物理ホストの障害発生時には、物理ホストの交換が自動的に行われる。この自動的な物理ホストの交換は、SDDCソフトウェアの継続的な自動アップデートと並び、VMware Cloud on AWSの運用を効率化する特徴的な機能である。

物理ホストの障害検知から代替、仮想マシン再起動までのプロセス全体が自動化されている

　物理ホストの障害が発生すると、vSphere HAが障害を検知する。これを受けて、障害が発生した物理ホスト上で稼働していた仮想マシンを、残りの物理ホストでvSphere HAが再起動する。

　これと同時にSDDCが物理ホストに障害が発生したことを検知し、代替となる物理ホストをクラスタに追加する。これでクラスタのキャパシティーが元通りとなるため、一時的に過負荷となっていた物理ホストから仮想マシンがvSphere DRSにより負荷分散されるよう再配置される。

　最後に、故障した物理ホストはクラスタから削除され、AWSに返却される。これで物理ホストの障害対応は完了となる。オンプレミスで行っていたハードウェア保守への連絡、新旧物理ホストのラックへの積み替え、その後の動作確認といった作業は不要である。

　スクリプティングによる自動化を行っている場合には、同一の物理ホストを修理して戻すのではなく、交換となる点に注意が必要である。障害発生時に物理ホストが交換される可能性があるため、物理ホストのホスト名、IPアドレスやUUIDなど固有の物理ホスト情報に依存したスクリプトとしてはいけない。実際のスクリプトの要件にもよるが、クラスタオブジェクトから物理ホストの配列を取得するのが妥当だろう。

　なお、実際の障害だけでなく、ホストリタイアメントなど、AWSによってスケジュールされたイベントが発生した場合にも、同様の処理が行われる。