単一テナンシーの概要

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

このドキュメントでは、単一テナントノードについて説明します。単一テナントノードの VM をプロビジョニングする方法については、単一テナントノードでの VM のプロビジョニングをご覧ください。

単一テナンシーを使用すると、単一テナントノードに独占的にアクセスできます。単一テナントノードは、プロジェクトの VM をホストすることに特化した物理 Compute Engine サーバーです。次の図に示すように、単一テナントノードを使用すると、VM を他のプロジェクトの VM から物理的に分離できます。また、同じホスト ハードウェア上で VM をグループ化することもできます。

図 1: マルチテナント ホストと単一テナントノード

単一テナントノードで実行されている VM は、透過性スケジューリングやブロック ストレージなど、他の VM と同じ Compute Engine 機能を使用できますが、ハードウェアが分離されます。物理サーバー上の VM を完全に制御するため、各単一テナントノードは、ノードをサポートする物理サーバーとの 1 対 1 マッピングを維持します。

単一テナントノード内では、さまざまなサイズのマシンタイプに複数の VM をプロビジョニングでき、専用ホスト ハードウェアの基盤となるリソースを効率的に使用できます。また、ホスト ハードウェアを他のプロジェクトと共有しないため、他のワークロードや VM からの物理的な分離が必要なワークロードでセキュリティやコンプライアンスの要件を満たすことができます。ワークロードが必要とするのが一時的な単一テナンシーのみの場合、必要に応じて VM テナントを変更できます。

単一テナントノードは、コアごとまたはプロセッサごとのライセンスが必要なお客様所有ライセンスの使用（BYOL）シナリオでの専用ハードウェア要件を満たすうえで役立ちます。単一テナントノードを使用すると基盤となるハードウェアを可視化できるため、コアとプロセッサの使用状況を追跡できます。使用状況を追跡するため、Compute Engine は VM がスケジュールされている物理サーバーの ID を報告します。これにより、Cloud Logging を使用して、VM の過去のサーバー使用状況を表示できます。ホスト ハードウェアの使用を最適化するには、単一テナント VM の CPU のオーバーコミット、単一テナント ノード グループの共有、手作業による VM のライブ マイグレーションを行えます。

構成可能なホスト メンテナンス ポリシーを使用すると、ホストのメンテナンス中に単一テナント VM の動作を制御できます。メンテナンスの時間、VM が特定の物理サーバーでアフィニティを維持するかどうか、VM をノードグループ内の他の単一テナントノードに移動するかどうかを指定できます。

ワークロードの考慮事項

次のようなタイプのワークロードは、単一テナントノードのメリットを活用できる場合があります。

  • パフォーマンス要件のあるゲーム ワークロード。

  • セキュリティとコンプライアンスの要件がある財務または医療ワークロード。

  • ライセンス要件がある Windows ワークロード。

  • 機械学習、データ処理、画像レンダリングのワークロード。こうしたワークロードについては、GPU の予約を検討してください。

  • 1 秒あたりの入出力オペレーション（IOPS）を増やしてレイテンシを短縮する必要があるワークロードや、キャッシュ、処理空間、価値の低いデータなどの一時的なストレージとして使用するワークロード。こうしたワークロードの場合については、ローカル SSD の予約を検討してください。

ノード テンプレート

ノード テンプレートは、ノードグループの各ノードのプロパティを定義するリージョン リソースです。ノード テンプレートからノードグループを作成すると、ノード テンプレートのプロパティがノードグループの各ノードに不変にコピーされます。

ノード テンプレートを作成するときに、ノードタイプを指定し、必要に応じてノード アフィニティ ラベルを指定します。ノード アフィニティ ラベルはノード テンプレートにのみ指定できます。ノードグループにノード アフィニティ ラベルを指定することはできません。

ノードタイプ

ノード テンプレートを構成するときに、ノード テンプレートに基づいて作成されたノードグループ内のすべてのノードに適用するノードタイプを指定します。ノード テンプレートによって参照される単一テナントノード タイプは、そのテンプレートを使用するノードグループで作成されたノードに対し、vCPU コアとメモリの合計量を指定します。たとえば、n2-node-80-640 ノードタイプには 80 基の vCPU と 640 GB のメモリが指定されています。

単一テナントノードに追加する VM は、ノード テンプレートで指定するノードと同じマシンタイプである必要があります。たとえば、n2 タイプの単一テナントノードは、n2 マシンタイプで作成された VM とのみ互換性があります。vCPU またはメモリの合計がノードの容量を超過するまで、単一テナントノードに VM を追加できます。

ノード テンプレートを使用してノードグループを作成すると、ノードグループ内の各ノードはノード テンプレートのノードタイプの仕様を継承します。ノードタイプは、ノードグループ全体に一律に適用されるのではなく、ノードグループ内のノードに個別に適用されます。したがって、ノードタイプがいずれも n2-node-80-640 のノードを 2 つ含むノードグループを作成すると、各ノードに 80 基の vCPU と 640 GB のメモリが割り当てられます。

ワークロードの要件に応じて、さまざまなサイズのマシンタイプで実行される複数のより小さな VM をノードに配置することもできます。そのようなマシンタイプには、事前定義されたマシンタイプ、カスタム マシンタイプ、拡張メモリを持つマシンタイプがあります。ノードがインスタンスでいっぱいの場合、そのノードでは追加のインスタンスはスケジュールできません。

次の表に、使用可能なすべてのノードタイプを示します。プロジェクトで使用可能なノードタイプのリストを表示するには、gcloud compute sole-tenancy node-types list コマンドまたは nodeTypes.list REST リクエストを実行します。これらのノードタイプの料金については、単一テナントノードの料金をご覧ください。

ノードタイプ プロセッサ vCPU GB vCPU:GB ソケット コア:ソケット 合計コア数
c2-node-60-240 Cascade Lake 60 240 1:4 2 18 36
m1-node-96-1433 Skylake 96 1433 1:14.9 2 28 56
m1-node-160-3844 Broadwell E7 160 3844 1:24 4 22 88
m2-node-416-11776 Cascade Lake 416 11776 1:28.3 8 28 224
m3-node-128-1952 Ice Lake 128 1952 1:15.25 2 36 72
m3-node-128-3904 Ice Lake 128 3904 1:30.5 2 36 72
n1-node-96-624 Skylake 96 624 1:6.5 2 28 56
n2-node-80-640 Cascade Lake 80 640 1:8 2 24 48
n2-node-128-864 Ice Lake 128 864 1:6.75 2 36 72
n2d-node-224-896 AMD EPYC Rome 224 896 1:4 2 64 128

どのノードでも、異なるシェイプの VM をスケジュールできます。タイプ n のノードは汎用ノードであり、カスタム マシンタイプのインスタンスをスケジュールできます。おすすめのノードタイプについては、マシンタイプに関する推奨事項をご覧ください。パフォーマンスについて詳しくは、CPU プラットフォームをご覧ください。

Compute Engine が古いノードタイプを新しいノードタイプに置き換えることがあります。Compute Engine がノードタイプを置き換えた場合、置き換えられたノードタイプを指定するテンプレートから追加のノードグループを作成することはできません。Compute Engine がノードタイプを置き換える際には、使用できなくなったノードタイプを指定する既存のノード テンプレートをレビューして修正する必要があります。

ノードグループと VM のプロビジョニング

単一テナントノード テンプレートは、ノードグループのプロパティを定義します。Google Cloud ゾーンにノードグループを作成する前に、ノード テンプレートを作成する必要があります。グループを作成するときに、ノードグループの VM インスタンスのホスト メンテナンス ポリシー、ノードグループのノード数、ノードグループを他のプロジェクトや組織全体と共有するかどうかを指定します。

ノードグループには 0 以上のノードを含めることができます。たとえば、ノードグループ内のノードで VM インスタンスを実行する必要がない場合、ノードグループのノード数を 0 に減らすか、ノードグループ オートスケーラーを有効にしてノードグループのサイズを自動で管理します。

単一テナントノードに VM をプロビジョニングする前に、単一テナントノード グループを作成する必要があります。ノードグループは、特定のゾーン内の単一テナントノードの同種のセットです。マシンタイプに 2 つ以上の vCPU があれば、ノードグループには、さまざまなサイズのマシンタイプで実行される複数の VM を含めることができます。

ワークロードの要件に合わせてグループのサイズが自動的に調整されるよう、ノードグループの作成時に自動スケーリングを有効にします。ワークロードの要件が静的な場合は、ノードグループのサイズを手動で指定できます。

ノードグループを作成した後に、グループまたはグループ内の特定のノードに VM をプロビジョニングできます。ノード アフィニティ ラベルを使用すると、アフィニティ ラベルが一致する任意のノードで VM をスケジュールできます。

ノードグループに VM をプロビジョニングし、必要に応じてアフィニティ ラベルを割り当てて特定のノードグループまたはノードに VM をプロビジョニングしたら、VM の管理に役立つようリソースのラベル付けを検討します。ラベルは VM を分類する Key-Value ペアであり、VM を集約して表示できるため料金の把握などに役立ちます。たとえば、ラベルを使用して、VM の役割、テナンシー、ライセンス タイプ、ロケーションをマークできます。

ホスト メンテナンス ポリシー

ライセンスのシナリオとワークロードに応じて、VM によって使用される物理コアの数を制限できます。選択するホスト メンテナンス ポリシーは、ライセンスやコンプライアンスの要件などによって異なります。また、物理サーバーの使用を制限できるポリシーも選択できます。これらすべてのポリシーを使用しても、VM は専用のハードウェア上に残ります。

単一テナントノードで VM をスケジュールする場合、ホスト メンテナンス ポリシー オプションを次の 3 つから選択できます。これにより、ホスト イベント中に Compute Engine が VM をライブ マイグレーションする方法と、ライブ マイグレーションするかどうかを決定できます。これは、約 4～6 週間ごとに発生します。メンテナンス中、Compute Engine はホスト上のすべての VM を 1 つのグループとして異なる単一テナントノードにライブ マイグレーションします。ただし、場合によっては Compute Engine が VM を小規模なグループに分割し、その各グループを個別の単一テナントノードにライブ マイグレーションすることもあります。

デフォルトのホスト メンテナンス ポリシー

これはデフォルトのホスト メンテナンス ポリシーです。このポリシーで構成されたノードグループの VM は、非単一テナント VM の従来のメンテナンス動作に従います。すなわち、VM のホストの [ホスト メンテナンス時] 設定に応じて、VM はホスト メンテナンス イベント前にノードグループの新しい単一テナントノードにライブ マイグレーションされ、この新しい単一テナントノードはお客様の VM のみを実行します。

このポリシーは、ホスト イベント中にライブ マイグレーションが必要な、ユーザー単位またはデバイス単位のライセンスに最適です。この設定は、VM の移行を物理サーバーの固定プール内に制限するものではありません。この設定は、物理サーバーの要件がなく既存のライセンスを必要としない一般的なワークロードにおすすめします。

このポリシーでは、既存サーバーのアフィニティを考慮せずに VM が任意のサーバーにライブ マイグレーションされるため、このポリシーはホスト イベント中に物理コアの使用量を最小限に抑える必要があるシナリオには適していません。

次の図に、デフォルト ホスト メンテナンス ポリシーのアニメーションを示します。

図 2: デフォルトのホスト メンテナンス ポリシーのアニメーション
。

ホスト メンテナンス ポリシーの再起動

このホスト メンテナンス ポリシーを使用すると、Compute Engine はホスト イベント中に VM を停止し、ホスト イベント後に同じ物理サーバー上で VM を再起動します。このポリシーを使用する場合、VM の [ホスト メンテナンス時] 設定を「TERMINATE」に設定する必要があります。

このポリシーは、ホスト イベント中に約 1 時間のダウンタイムが発生する可能性があるフォールト トレラントなワークロード、同じ物理サーバーに残す必要があるワークロード、ライブ マイグレーションを必要としないワークロード、または物理コア数やプロセッサ数に基づくライセンスを所有している場合に最適です。

このポリシーでは、node-name、node-group-name、またはノード アフィニティ ラベルを使用してノードグループにインスタンスを割り当てることができます。

次の図に、インプレース再起動のメンテナンス ポリシーのアニメーションを示します。

図 3: インプレース再起動のホスト メンテナンス ポリシーのアニメーション

ノードグループのメンテナンス ポリシー内での移行

このホスト メンテナンス ポリシーを使用すると、Compute Engine はホスト イベント中に固定サイズの物理サーバー グループ内の VM をライブ マイグレーションします。これにより、VM が使用する一意の物理サーバーの数を制限できます。

このホスト メンテナンス ポリシーでは、グループ内の各単一テナントノードが一定のセットの物理サーバーに固定されます。そのため、このポリシーは、物理コア数またはプロセッサ数に基づくライセンスを持つ、高可用性ワークロードに最適です。これは、VM を任意のサーバーに移行できるデフォルトのポリシーとは異なります。

ライブ マイグレーション用の容量を確保するため、Compute Engine は予約した 20 ノードごとに 1 つのホールドバック ノードを予約します。次の表に、ノードグループ用に予約するノード数に応じて Compute Engine が予約するホールドバック ノードの数を示します。

グループ内の総ノード数 ライブ マイグレーション用に予約されたホールドバック ノード
1 該当なし。少なくとも 2 つのノードを予約する必要があります。
2～20 1
21～40 2
41～60 3
61～80 4
81～100 5

このポリシーでは、各インスタンスが node-group-name アフィニティ ラベルを使用して単一のノードグループをターゲットにする必要があります。特定のノード node-name に割り当てることはできません。これは、ホスト イベントの発生時に Compute Engine が VM をホールドバック ノードにライブ マイグレーションする場合に必要になります。node-name ではなく node-group-name が割り当てられている限り、VM は任意のカスタム ノード アフィニティ ラベルを使用できます。

次の図に、ノードグループ内での移行のホスト メンテナンス ポリシーのアニメーションを示します。

図 4: ノードグループ内での移行のホスト メンテナンス ポリシーのアニメーション

メンテナンスの時間枠

ワークロード（精密に調整されたデータベースなど）を管理しているときに、ライブ マイグレーションのパフォーマンスに対する影響が問題になることがあります。この場合、ノードグループの作成時にメンテナンスの時間枠を指定すると、単一テナントノード グループでメンテナンスが開始する時間を確認できます。ノードグループを作成した後に、メンテナンスの時間枠を変更することはできません。

メンテナンスの時間枠は 4 時間単位です。これにより、Google が単一テナント VM にメンテナンスを実行するタイミングを指定できます。メンテナンス イベントは、4～6 週間に 1 回程度発生します。

メンテナンスの時間枠は単一テナントノードのすべての VM に適用されます。これは、メンテナンスの開始時のみ指定します。メンテナンスの時間枠内にメンテナンスが完了する保証はありません。また、メンテナンスが頻繁に発生することを保証されません。ノードグループ内で移行のホスト メンテナンス ポリシーが使用されているノードグループでは、メンテナンスの時間枠は使用できません。

ホストエラー

ホスト（単一テナントまたはマルチテナント）で重大なハードウェア障害が発生すると、Compute Engine は次の処理を行います。

  1. 物理サーバーとその一意の識別子を廃止します。

  2. プロジェクトの物理サーバーへのアクセスを取り消します。

  3. 障害が発生したハードウェアを、新しい一意の識別子を持つ新しい物理サーバーに置き換えます。

  4. 障害が発生したハードウェアから置換先のノードに VM を移動します。

  5. 影響を受ける VM を自動的に再起動するように構成した場合は、再起動します。

ノード アフィニティとアンチアフィニティ

単一テナントノードでは、VM が他のプロジェクトの VM とホスト ハードウェアを共有することはありません。ただし、同じ単一テナントノード上で複数のワークロードをグループ化することや、ワークロードを互いに異なるノードに分離する必要が生じることも考えられます。たとえば、コンプライアンス要件を満たすため、アフィニティ ラベルを使用して機密性の高いワークロードを機密性の低いワークロードから分離する場合です。

VM の作成時に、1 つ以上のノード アフィニティ ラベルを参照し、ノード アフィニティまたはアンチアフィニティを指定して単一テナンシーをリクエストします。ノード テンプレートの作成時にカスタム ノード アフィニティ ラベルを指定すると、Compute Engine は各ノードに複数のデフォルト アフィニティ ラベルを自動的に追加します。VM の作成時にアフィニティを指定すると、ノードグループ内の特定のノードで複数の VM を同時にスケジュールできます。VM の作成時にアンチアフィニティを指定すると、特定の VM がノードグループ内の同じノードまたは複数のノードで同時にスケジュールされないようにできます。

ノード アフィニティ ラベルは、ノードに割り当てられた Key-Value ペアであり、ノード テンプレートから継承されます。アフィニティ ラベルを使用すると、次のことができます。

  • 個々の VM インスタンスをノードに割り当てる方法を制御する。
  • テンプレートから作成された VM インスタンス（マネージド インスタンス グループによって作成されたものなど）をノードに割り当てる方法を制御する。
  • 機密性の高い VM インスタンスを特定のノードまたはノードグループにグループ化し、他の VM から分離する。

デフォルト アフィニティ ラベル

Compute Engine は、各ノードに次のデフォルト アフィニティ ラベルを割り当てます。

  • ノードグループ名のラベル:
    • キー: compute.googleapis.com/node-group-name
    • 値: ノードグループの名前。
  • ノード名のラベル:
    • キー: compute.googleapis.com/node-name
    • 値: 個々のノードの名前
  • ノードグループが共有されるプロジェクトのラベル。
    • キー: compute.googleapis.com/projects
    • 値: ノードグループを含むプロジェクトのプロジェクト ID。

カスタム アフィニティ ラベル

ノード テンプレートを作成するときに、カスタムのノード アフィニティ ラベルを作成できます。これらのアフィニティ ラベルは、ノード テンプレートから作成されたノードグループ内のすべてのノードに割り当てられます。ノードグループを作成した後に、ノードグループ内のノードにカスタム アフィニティ ラベルを追加することはできません。

アフィニティ ラベルの使用方法については、ノード アフィニティの構成をご覧ください。

料金

  • 単一テナントノードのコストを最小限に抑えるため、Compute Engine では確約利用割引と継続利用割引を提供しています。また、単一テナントノードの vCPU とメモリについてはすでに課金されているため、単一テナントノードの VM に追加料金はかかりません。

  • GPU またはローカル SSD を持つ単一テナントノードをプロビジョニングする場合、プロビジョニングした各ノードのすべての GPU またはローカル SSD に対して課金されます。単一テナンシーのプレミアム料金は、GPU またはローカル SSD に適用されません。

利用状況

  • 単一テナントノードは、一部のゾーンでのみ使用可能です。高可用性を確保するため、異なるゾーンの単一テナントノードで VM をスケジュールします。

  • 単一テナントノードで GPU またはローカル SSD を使用する前に、リソースを予約するゾーンに十分な GPU またはローカル SSD の割り当てがあることを確認してください。

  • Compute Engine は、GPU をサポートするゾーンの n1 単一テナントノード タイプで GPU をサポートします。次の表に、n1 ノードに接続できる GPU のタイプと、ノード テンプレートの作成時に接続する必要がある GPU の数を示します。

    GPU のタイプ GPU 数
    NVIDIA® P100 4
    NVIDIA® P4 4
    NVIDIA® T4 4
    NVIDIA® V100 8

  • Compute Engine は、ローカル SSD をサポートするゾーンにある n1、n2、n2d 単一テナントノード タイプでローカル SSD をサポートします。

制限事項

次のステップ