みなさん、こんにちは。
Google Cloud でインフラ周りを担当する Customer Enginner をしている Takao です。
このBlogは、 vExpert Advent Calendar 2022 の12/5分の１つ目として公開しています。 Google Cloud Japan としての Advent Calendar の投稿に混ざり込んでスミマセン。
11/15-16に開催されたVMwareさんの年次イベント VMware Explore Japan で行わせていただいた、このBlogと同タイトルのセッションについて、オトナの事情でイベントサイト内で資料を公開できていないため、ほぼ同じ内容をこちらで公開してしまおいうという投稿となります…。
アカウントの登録が必要となりますが、イベントの動画はVMware Explore Japanのウェブサイトで2022/12/23まで公開されています。
40分のセッション枠であったにもかかわらず、合計で17ものアップデートをまとめて紹介した駆け足セッションでしたので、ご参加頂いただ方も振り返りとしてお読み頂ければ嬉しいです。
TL;DR:
Aパートは仕様に関連するアップデート、Bパートは技術に関連するアップデートをご紹介します。項目も多いので、トグル形式にしておきますので、ご興味のある部分だけをお読みいただくでもOKです。
Aパート（仕様アップデート）
- 提供バージョンとマネージドサービス
- Private Cloud のスケーラビリティ
- 1 ノードクラスタ（PoC用）
- カスタムコア対応
- HCX Enterprise 標準提供
- VMware Cloud Universal 対応
- Microsoft ライセンス（BYOLとSPLA）
- ISMAP 対応予定
Bパート（技術アップデート）
- 自動スケーリングポリシー
- Cloud KMS を用いた vSAN 暗号化
- Cloud Monitoring Standalone Agent
- Traffic Director 連携と Cloud Load Balancing の活用
- Backup and DR Service によるバックアップ
- NetApp CVS, Dell PowerScale 連携
- Migrate to Virtual Machine (M2VM)
- API / CLI と自動化
- ストレッチクラスタ対応（Preview）
GCVE について（おさらい）
GCVEについて
GCVEは、Google Cloudが提供する数多くのComputing Serviceの中で、ESXi用として物理サーバを提供すると共に、VMware vSphere, vSAN, NSX, HCX などのVMwareのSDDC (Software Defined Data Center)スタック一式をマネージドサービスとして提供するサービスとして位置づけられます。
Google Compute Engine (GCE) と同じくVMを利用するサービスではあるのですが、VMそのものを提供するGCEに対して、GCVEはVMそのものではなく実行基盤を提供する形式となっています。
GCVEで提供するVMware vSphere仮想化環境は、多くのお客様がオンプレミスでご利用されているVMware vSphere仮想化環境と同じものです。つまり、オンプレミスで利用されているVMを「そのまま」 Google Cloudに持ち込んで利用することが可能です。これにより、Google Cloudへの移行を迅速に行なってもらえると同時に、運用に携われる皆様がこれまで培ったVMwareに対するスキルや経験、ノウハウなどを引き続き活かせるという点も重要です。
また、GCVEは単にVMware vSphereを用いた仮想化環境を提供するというだけではなく、サービスとしての一連のリソースをマネージドサービスとして提供します。ここは重要なポイントです。
お客様は、この絵の下側の青い部分については Google Cloud に"おまかせ"してしまうことができます。つまり、VMware vSphere環境の構築はもちろん、そのメンテナンスや保守対応、さらにはDCファシリティの準備や契約、ネットワーク機器の調達、物理的な障害対応、VMware vSphereとしてのパッチ適用やアップグレード、資産管理やリプレイス作業などといった部分は全て Google Cloud が対応しますので、お客様は上の緑の部分、仮想マシンとアプリケーションの管理にフォーカスして頂くことができるようになります。
このように、GCVEは「Google Cloudの中で、Google Cloudによって管理されたVMware vSphere仮想化環境を提供するVMware認定のマネージドサービス」です。
Aパート（仕様アップデート）
1. 提供バージョンとマネージドサービス
繰り返しとなりますが、GCVEはマネージドサービスとしてバージョン管理も Google Cloud によって行われます。よって、2022/11時点の提供バージョンは以下のとおりですが、継続的にパッチの適用やマイナーおよびメジャーアップデートの対応がされることとなります。最新の情報はこちらを参照してください。
マネージドサービスとしてパッチの適用やマイナー・メジャーアップデートについては Google Cloud 側によって実施されますが、実施においてはポリシーが定義されており、基本的にお客様に対して事前に通知が行われた上で実施されます。直近の実施内容や、影響範囲、お客様側で必要な対応や推奨事項などについては、こちらに提示されます。
ESXiの再起動を伴うメンテナンス実施時には、一時的に縮退するリソースをカバーするためにメンテナンスノードがクラスタに組み込まれます（vSANデータストアには組み込まれません）。また、メジャーアップデートに際しては事前通知された予定日時に対して実施タイミングをサポートを通じて調整頂くことが可能です。ただし、いつまでもアップデートを実施しないといったことはできず、基本的に数週間程度の範囲で調整頂く必要があります。
2. Private Cloud のスケーラビリティ
まずこれはGCVEに限らず、Google Cloud 全般における基本仕様ですが、Google Cloudの全てのサービスは「APIを有効化」することで利用可能となります。これは明示的にAPIを有効化する操作をすることで、誤って想定外のサービスを利用してしまうことを防ぐ仕組みです。GCVEの場合は、"VMware Engine API"を有効化することで使用できるようになります。
その上で、展開可能なリソース量には「割り当て（Quota）」というリミッタを設定できます。これは仕様上の上限とは関係なく、ユーザとして意図していない量のリソースを誤って展開してしまうことを防止するための仕組みです。たとえば下記の場合、VMware Engine APIは、東京リージョン（asia-northeast1）に対して"8"という割り当てが設定されているため、東京リージョンに対しては最大8台までのESXiノードが展開可能ですが、他のリージョンは割り当てが"0"になっているため、他のリージョンへのESXiノードの展開はできません。これは、GCVEに対する管理者権限を持っていた場合でもできません。
このように、APIの有効化と割り当て（Quota）によって、組織としてサービスの利用を管理することが可能です。
GCVEのスケーラビリティは、主にPrivate CloudとClusterにおける構成可能数の上限です。GCVEにおいて、Private Cloudとは、同じ vCenter Server および NSX Manager で管理される範囲を意味します。リージョンを超えてPrivate Cloudを構成することはできないため、東京リージョンとシンガポールリージョンでGCVEを使う場合には、それぞれでPrivate Cloudを構成する必要があります。
1つのPrivate Cloudの中には複数のClusterを展開できます。ClusterはVMware vSphereにおけるClusterを意味し、vSANやHA/DRSなどの範囲となります。
2022/11現在で、Private Cloudあたりの最大ノード数は64となっていますが、利用者からの要望に基づいて96への拡張をPreview中となっています。つまり、それだけの規模感でGCVEを利用されているお客様がいらっしゃるということですね。
なお、GCVEのSLAについてはこちらを参照してください。
3. 1 ノードクラスタ（PoC用）
GCVEでは1ノードだけでクラスタを構成することが可能となりましたが、こちらは検証や評価を目的としたもので、利用期間も最大で60日までに制限され、SLAの適用も対象外となります。
1ノードクラスタは、GCVE自体の基本機能の評価であったり、GCVEとオンプレミスやGoogle Cloudの他のサービスとの接続や組み合わせ利用の確認などにご利用いただけます。
なお、1ノードクラスタのままでの利用は最大60日までとなりますが、その期間中に3ノード以上のSLA対象となるクラスタサイズに拡張された場合にはそのまま継続してご利用頂くことが可能です。
4. カスタムコア対応
GCVEでは、クラスタ単位でノードのコア数をカスタムで指定するカスタムコア機能を提供しています。
これはGCVEの性能や費用を調整するものではなく、物理サーバの物理コア数をライセンス要件とするアプリケーションへの対応のための機能です。そのため、設定したコア数は事後に変更することはできません。また、特定ノード単位ではなく、クラスタ単位での適用となります（後から当該クラスタに追加するノードにも適用されます）。
物理コア数に基づくライセンス要件を持つアプリケーションを実行するVMだけを、カスタムコアを設定したクラスタにまとめることで、ソフトウェアライセンスコストを最適化することができます。
5. HCX Enterprise 標準提供
2022/5/31のリリースノートにあるとおり、GCVEでは以前提供されていたHCX Advancedに変わり、HCX Enterpriseが標準で提供されるようになりました（従来は申請ベース）。この変更に伴うGCVE提供価格の変更はありません。
なお、既存のPrivate CloudにおいてHCX Enterpriseを利用したい場合には、サポートケースを上げて頂くことで対応が可能です。
6. VMware Cloud Universal 対応
VMwareおよびGoogle Cloudの双方から発表されている通り、GCVEに対してVMware Cloud Universal(VMCU)のクレジットを利用頂くことが可能です。
これにより、お客様はVMwareライセンスに対する投資を無駄にすることなくGCVEを使い始めて頂くことが可能となります。また、Google Cloudのパートナーだけではなく、VMwareのパートナーの皆様にもGCVEをお客様にご提案頂けます。詳細については、VMwareさんもしくはGoogle Cloudの担当営業までお問い合わせください。
7. Microsoft ライセンス（BYOLとSPLA）
Google Cloudを含む主要なPublic Cloudは、MicrosoftによってListed Providerとして指定されており、Windows Server OSの利用においては基本的にはSPLA(Service Provider License Agreement)の利用が必要です。
Google Cloud では Marketplace を通じたプライベートオファーを利用して、GCVEを利用されるお客様に対してESXiホストの物理コア数に基づくWindows ServerのSPLAをご利用いただけます。これにより、お客様はオンプレミスにおいてESXiホストにコア数分のWindows Server Datacenter Editionを購入し、ゲストOSとして無制限の利用を行っていた利用パターンと同様のWindows Serverの利用をGCVEにおいて行って頂くことが可能です。
SPLAについては、Windows Serverの他にSQL Serverについても利用頂くことができますが、SQL Serverについてはライセンスモビリティに基づく持ち込み利用も可能です。
8. ISMAP 対応予定
Google Cloud は、政府共通のクラウドサービス利用環境であるガバメントクラウドにも認定されており、ISMAPにも数多くの Google Cloud のサービスが掲載されていますが、2022/11時点ではGCVEについてはまだ掲載されていません。
現在、GCVEについてもISMAP掲載に向けた対応が進められており、近い将来においてISMAPの認定を取得する予定です。
Bパート（技術アップデート）
9. 自動スケーリングポリシー
GCVEには自動スケーリングポリシーが実装されており、CPUやメモリの使用率、ストレージの容量利用率などに基づいたノードの自動追加もしくは自動削除が可能です。自動スケーリングポリシーによって増減するノード数の範囲は制限することが可能であり、一度増減が行われた場合に一定期間増減を実行しないクールオフ期間の設定も可能です。また、使用率や利用率に基づく自動スケーリング動作においては、瞬発的なリソース増減にセンシティブに反応しすぎてしまわないように、30分以上継続して指定したポリシー要件を満たし場合に発動される仕組みとなっています。
なお、この自動スケーリングポリシーを利用する場合ももちろん割り当て（Quota）の制限は有効であるため、割り当て数を超えたノードの追加はできません。
10. Cloud KMS を用いた vSAN 暗号化
Google Cloudには、Cloud KMSと呼ばれる暗号化のための鍵管理のマネージドサービスがあり、この仕組みを用いてGCVEが利用するvSANデータストアの暗号化を提供しています。これは特別な構成や指定は不要で、既定で有効となっており、追加のコストなどはかかりません。つまり、GCVEにおいてはvSANデータストアに保存したデータはGoogle Cloudの他のサービスと同様に暗号化による安全性が確保されます。
外部のKMSサービスやKMSサーバなどをご利用頂くことも可能ですが、その場合はそれらのKMSサービスとの契約や構成操作が必要となります。
11. Cloud Monitoring Standalone Agent
Google Cloudでは数多く提供されているサービス共通のメトリック収集と分析のマネージドサービスとしてCloud Monitoringを提供していますが、これまでサービスの一部にVMwareのソフトウェアを利用するGCVEはCloud Monitoringに対応できていませんでした。
これを可能とするために、GCVE用のCloud Monitoring Standalone Agentが提供されています。これは、Linuxにインストールして利用する無償のアプリケーションとなっており、vCenter ServerおよびNSX ManagerからSyslogを通じて取得したメトリック情報をAPIを通じてCloud Monitoringに保存する中継エージェントとしての役割を担います。
このCloud Monitoring Stadalone Agentを用いることで、GCVEの管理者はvCenterにログインするこなくGoogle Cloud共通の手法を用いて各種リソースの使用状況を把握し、必要に応じてアラート通知を構成するなどのオペレーションの簡素化が可能となります。
12. Traffic Director 連携と Cloud Load Balancing の活用
Google CloudにはフルマネージドなロードバランスサービスとしてCloud Load Balancingがありますが、2022/11時点ではGCVEとの直接的な組み合わせでの利用は正式サポートされていません。しかし、Cloud Load Balancingとは別に、アプリケーションの通信制御を行う仕組みのコントロールプレーン部分をマネージドサービスとして提供するTraffic Directorと呼ばれるサービスを利用することで、GCVEのVMに対するロードバランスを構成できます。
Traffic Directorは、いわゆるService Meshの仕組みにおけるコントローラの部分をマネージドサービス化したサービスです。Traffic Director自体はマネージドサービスですので導入や構築は不要で利用できます。そして、Envoyが導入されたコンテナやVMインスタンスなどを展開することで、ロードバランスなどの実際の通信制御を行います。なお、Traffic Directorによって制御される、Envoyが導入されたコンテナやVMインスタンスをService Proxyと呼びます。
Service Proxyによって通信制御されるサービス提供リソースはBackend Serviceと呼ばれ、GCEのVMインスタンスの場合はManaged Instance Group (MIG)、それ以外のIPアドレスとポートの組み合わせ等の場合はNetwork Endpoint Group (NEG)と呼ばれる単位でグルーピングされてService Proxyに紐付けられます。
Traffic DirectorのBackend Serviceには、MIGとして紐付けられるGCEインスタンスの他に、NEGとしてGCVEのVMやServerlessのサービス、オンプレミスのサーバなどを紐付けることが可能です。
Service Proxyとして動作するインスタンスには構成情報は保持されず、Traffic Directorを通じて構成情報が展開されます。よって、Service Proxyはトラフィックの負荷や可用性要件に基づいて台数を増減させるスケールアウト構成が可能です。しかしこの場合、ユーザは増減するService Proxyに対してどのように接続すればよいのでしょうか？そこで、Cloud Load Balancingを利用します。
Service Proxyとして展開されたVMインスタンスはそれ自体をMIGとしての管理することが可能であり、このMIGをCloud Load BalancingのBackend Serviceとして登録することが可能です。つまり、ちょっと多段になり分かりづらい部分もありますが、ユーザ→Cloud Load Balancingの単一のVIP宛に通信する→いずれかのService Proxyインスタンスに通信が振り分けられる→実際のサービスを提供するGCVE VMなどに通信がロードバランスされる、という流れを通じてサービスの提供が可能です。
GCVEのためのロードバランサとしてはVMインスタンスベースの仮想アプライアンスを展開して利用頂くことも可能ですが、ここで紹介したCloud Load BalancingとTraffic Directorの多段構成によるロードバランス構成は、多段となっており構成が複雑に見えますが、その全てがマネージドサービスであり、負荷や可用性に基づくリソースの増減や障害時の再作成が用意であることなど、様々なメリットがある組み合わせです。
ここで紹介した構成は、紙芝居方式ではありますが、VMwareさんのHands-on Lab (HOL)でお試し頂けます。また、Medium Blogにおいてももう少し詳細を解説したBlogを書いていますので、合わせて参照ください。
13. Backup and DR Service によるバックアップ
Backup and DR Serviceは、2022/10に行われたGoogle Cloud Nextイベントで発表されたGoogle Cloudの統合バックアップサービスです。GCEおよびGCVEインスタンスを対象としたイメージバックアップとDBやファイルなどのAgentを用いたバックアップに対応しています。
Backup and DR Serviceは永久増分バックアップに対応しており、さらにバックアップデータの保存先として、耐久性とコストパフォーマンスに優れたGoogle CloudのオブジェクトストレージであるCloud Storageを利用できますので、ストレージコストを抑えつつ柔軟なバックアップデータの世代管理制御に対応しています。
GCVEとBackup and DR Serviceとの組み合わせについては、紙芝居方式ではありますが、VMwareさんのHands-on Lab (HOL)でお試し頂けます。
14. NetApp CVS, Dell PowerScale 連携
Google Cloudにはフルマネージドなストレージサービスとして、NetAppさんと連携したCloud Volumes Service (CVS)と、Dell Technologiesさんと連携したCloud PowerScaleが提供されています。これらはいずれもストレージを提供するというよりも、ボリュームを提供するマネージドサービスです。ストレージとしての管理は一切不要となっており、必要なサイズのボリュームを作成し、マウントポイントを通じてマウントして利用します。
NetApp CVSは、NFSとSMBでマウント可能なボリュームを作成・利用できるフルマネージドなクラウドストレージサービスです。GCEのインスタンスからはもちろん、GCVEのVMからのマウント利用がサポートされています。
NetApp CVSは東京および大阪リージョンで利用可能となっています。また、紙芝居方式ではありますが、VMwareさんのHands-on Lab (HOL)でお試し頂けます。
Dell Cloud PowerScaleは、NFSとSMBに加えてHDFSでマウント可能なボリュームを作成・利用できるフルマネージドなクラウドストレージサービスです。GCEのインスタンスおよびGCVEのVMからのマウント利用がサポートされています。
残念ながらDell Cloud PowerScaleについては、国内リージョンでの提供は2022/11時点では開始されていません。
15. Migrate to Virtual Machine (M2VM)
Migrate to Virtual Machine (M2VM)は、その名の通りGoogle Cloudが提供する移行ツールです。2022/11時点では、このツールはVMware環境からGoogle Compute Engineへの移行が可能となっています。
下図では①〜③の3パターンを示していますが、GCVEを利用されるお客さまの多くが、オンプレミスと同じVM形式であったりL2延伸が可能であることなどのGCVEのメリットを活用したスピーディな移行と利用を行いつつも、その一部のVMやサービスについてはGCEへの移行や、さらにはリファクタリングを経てコンテナベースやServerlessへの移行を計画されています。
GCEへの移行は仮想ディスクのインポートや、アプリケーションの導入とデータの移行など、様々な手法で行って頂くことが可能ですが、M2VMを用いると移行元の停止と伴わないデータの継続的な同期や移行テストの実施、最終移行時における短時間での最終同期と切り替え、ゲストOS構成の最適化などの手間のかかる部分を自動化することができ、より短時間でより多くのVMの移行が可能です。
また、M2VMによる移行は上図の①のようにオンプレミス側のVMware vSphere環境からの直接的な移行ももちろん可能ですが、②のように一旦GCVEを経由する、GCVEからGCEへの移行ツールとしても利用いただけます。これにより、クラウド移行のスピードを上げる手段であったり、最終的な移行先が未決定のサーバなどの退避先としてGCVEをホップ・ステップ・ジャンプのホップとしてご利用頂くことが可能です。
16. API / CLI と自動化
GCVEの正式なGoogle Cloud APIおよびCloud SDKの対応については、2022/11にVMware Explore Japanで講演を行った際にはまだPreviewでしたが、その後正式にリリースされました。
まだ最初のリリースとなるため、GCVEのGUIで操作可能な全ての操作がAPI/CLIを通じて実行可能になったわけではありませんが、GCVEが他のGoogle Cloudのサービスと同等に利用頂けるサービスとなるためには重要な一歩であり、そしてこれにより構成管理のスクリプト化や構成管理ツールへの対応がやりやすくなることなど、多くのメリットがある一歩です。
たとえば、クラスタへ新しいESXiノードを追加するオペレーションをコマンド1行で実行することなどができてしまいます!!
17. ストレッチクラスタ対応（Preview）
東京リージョンのGCVEをはまだ未対応ですが、USやオーストラリア、ヨーロッパなどのGCVEを提供している一部のリージョンでは、GCVEをリージョン内で複数のゾーンで提供しており、複数ゾーンをまたいだvSANのストレッチクラスタ構成をPreviewとして対応しています。これにより、ゾーン障害への対応が可能となります。
こちらは2022/11時点でPreviewとしての提供となっています。
まとめ
冒頭のGCVEのおさらいにおいて、VMware vSphere仮想化基盤としてGCVEをご利用頂くことのメリットは、単なるリソースの提供ではなく、マネージドサービスとして下回りの運用管理をGoogle Cloudにまかせてしまえる点だとお伝えさせて頂きましたが、それに加えてもう1つのGCVEをご利用頂く大きなメリットが、このBlogで17ものアップデートをご紹介させて頂いたように、利用を開始した後も継続的に機能の追加や拡張が提供され続ける点です。
オンプレミスでの購入したリソースを用いた利用や、単純にリソースだけを提供するサービスでの利用の場合、利用期間中に利用者側からアクションを取ることなく機能が追加されたり仕様が拡張されたりすることはありません。しかし、GCVEを含むクラウドサービスでは、マネージドサービスとして機能が継続的に開発・改善され続け、今日できなかったことが明日できるようになっていきます。
コストももちろん重要な指標の1つですが、このBlogでご紹介したGCVEを利用する2つのメリット（マネージドサービスである、サービスが追加・拡張され続ける）についても考慮頂き、ぜひ皆様の既存VMware vSphere仮想化環境の次の移行先の候補として、もしくはGoogle Cloudの他のサービスへの移行のステップとして、GCVEをご検討ください。
Discussion