コンテンツに移動
コンピューティング

専用ハードウェアでの運用がもっと柔軟に

2020年3月3日
https://storage.googleapis.com/gweb-cloudblog-publish/images/Compute_workload.max-2600x2600.jpg
Google Cloud Japan Team

※この投稿は米国時間 2020 年 2 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud では、柔軟性、オープン性、選択の幅があることが、クラウドの移行とモダナイゼーションには重要であるというご要望を数多くいただいています。パフォーマンスの分離(ゲーム業界)、物理的な隔離(金融、医療業界)、ライセンス コンプライアンス(Windows ワークロード)などの要件から専用ハードウェアを必要とする企業の皆様のために、これまでも単一テナントノードでは分離、セキュリティ、コンプライアンスのニーズに合わせた柔軟性を強化してきました。 

単一テナントノードではすでに、各ノードで異なる VM 構成の混合、マッチング、サイズ調整が可能です。また、ノードのアフィニティ ラベルを使って、特定のノード、ノードグループ、ノードのグループでインスタンスを自動的にスケジュール設定するだけでなく、メンテナンス イベントのためにライブ マイグレーションを利用することもできます。さらにこのたび、単一テナントノードの 3 つの新機能が利用可能になりました。 

  • 固定ノードプール内でのライブ マイグレーションによる BYOL(お客様所有ライセンスの使用)(ベータ版)

  • ノードグループのオートスケーラー(ベータ版)

  • 単一テナントノードとマルチ テナントノード間の移行(GA) 

これらの新機能により、Google Cloud の専用ハードウェア上でワークロードのデプロイ、管理、実行が容易になり、費用対効果が高まります。

Windows BYOL のメンテナンスの粒度を向上

ライセンス Windows ワークロードを Google Cloud で実行するには、オンデマンド ライセンスを購入する、Microsoft アプリケーション用のライセンス モビリティを利用する、既存のサーバーにバインドされた適格なライセンスを単一テナントノードで使用できるようにする、といった方法があります。単一テナントノードを使用すると、ワークロード専用の物理的な Compute Engine サーバー上でインスタンスを起動して、専用ハードウェアの要件に準拠できます。また同時に、単一テナントノードによって、基盤となるホストのハードウェアの可視化が実現し、BigQuery との統合を通じてライセンス レポートがサポートされます。

今では、新しいノードグループのメンテナンス ポリシーのもとで、単一テナントノードによって専用機の拡張制御が可能になっています。この設定により、ホストでのメンテナンス イベント中に、単一テナントノードのインスタンスの動作を指定できます。ライセンスの追加費用がかかるのを避け、コアごとまたはプロセッサごとのライセンスをサポートしながら最新のカーネルとセキュリティ更新を提供するには、新しい「ノードグループ内で移行」メンテナンス ポリシーの設定を使用して、VM のダウンタイムなしで、お客様固有の物理コアの使用を最小限に抑えながらカーネル更新を透過的にインストールします。

https://storage.googleapis.com/gweb-cloudblog-publish/original_images/migrate_with_node_group.gif

この設定で構成されたノードグループは、ホストでのメンテナンス イベント中に単一テナントノード(専用サーバー)の固定プール内のインスタンスをライブ マイグレーションします。ホストの固定プールへの移行を制限することにより、すでにライセンスを付与されたサーバー間で仮想マシンを動的に移動し、ライセンス汚染を回避できます。また、パフォーマンスとセキュリティを向上させるために最新のカーネル更新で実行し続けるのにも役立ち、自動移行によって継続的な稼働時間が可能になります。これで、サーバーにバインドされた BYOL を持ったワークロードが、ライセンス費用、ワークロードの稼働時間、プラットフォームのセキュリティのバランスを改善できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/autoscale.max-900x900.png

「ノードグループ内で移行」の設定に加えて、ノードグループを「デフォルト」設定に構成して、メンテナンス イベント中にインスタンスを新しいホストに移動したり(サーバー アフィニティの要件がないワークロードの最適化案)、「再起動」設定に構成して、インスタンスを終了してホストでのメンテナンス イベント後に同じ物理サーバー上で再起動したりすることもできます。

ノードグループ メンテナンス ポリシーの詳細については、BYOL のドキュメントをご覧ください。

ノードグループのオートスケーラー

動的な容量の要件がある場合は、単一テナントノード グループのオートスケーラーによって単一テナントノードのプールを自動的に管理できるので、ノードグループを別個にスケールすることを気にせずにワークロードをスケールできます。新しいインスタンスを格納するのに十分な容量がない場合、単一テナントノード グループのオートスケーラーによって、ノードグループのサイズが増加します。また、空のノードの存在を検出すると、ノードグループのサイズが自動的に減少します。これにより、スケジューリングのオーバーヘッドが軽減され、リソース使用率が改善し、インフラストラクチャの費用を抑えることができます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/node_group_autoscaler.max-2000x2000.png
読み込んでいます...

オートスケーラーを使用すると、変化するワークロードに対応するために、ノードグループ サイズの最小限度と最大限度を設定し、バックグラウンドでスケールできます。さらに柔軟性を高めるために、自動スケーリングではスケールアウト(増加のみ)モードも利用できます。このモードでは、単調に増加するワークロードや、物理コアまたは物理プロセッサにライセンスが関連付けられているワークロードがサポートされます。 

単一テナンシーへの移行

最終的に、ワークロードにさらなる俊敏性が必要な場合、インスタンスを単一テナントノードへ移動することも、単一テナントノード間を移動することも、単一テナントノードから外に移動することもできるようになっています。これにより、変化するセキュリティ、コンプライアンス、パフォーマンスの分離のニーズに基づいて、既存の VM インスタンスのハードウェアの分離を実現できます。
オンライン ビッグセールの日、ゲームの発売、最大のパフォーマンスと最高レベルの制御が必要なときなどの特別イベントのために、インスタンスを単一テナントノードへ移動するといいでしょう。
下記の例は、インスタンスを単一テナントノードに移行する手順を示しています。
読み込んでいます...

専用ハードウェアでインスタンスのスケジュールを再設定する方法の詳細については、ドキュメントをご覧ください。

料金と利用可能な地域

単一テナントノードの料金設定はシンプルなままです。使用するノードに対してだけ 1 秒単位(最小で 1 分間の課金)でお支払いいただけます。継続利用割引は、新規または既存の確約利用割引と同様に自動的に適用されます。単一テナントノードの詳細については、料金ページにアクセスし、ご利用のリージョンで使用できるかどうかを確認するには、ご利用可能なリージョンにアクセスしてください。

- プロダクト マネージャー David Cheng、スタッフ ソフトウェア エンジニア Kevan Miller

投稿先