このドキュメントでは、単一テナントノードについて説明します。単一テナントノードの VM をプロビジョニングする方法については、単一テナントノードでの VM のプロビジョニングをご覧ください。
単一テナンシーを使用すると、単一テナントノードに独占的にアクセスできます。単一テナントノードは、プロジェクトの VM をホストすることに特化した物理 Compute Engine サーバーです。次の図に示すように、単一テナントノードを使用すると、VM を他のプロジェクトの VM から物理的に分離できます。また、同じホスト ハードウェア上で VM をグループ化することもできます。

単一テナントノードで実行されている VM は、透過性スケジューリングやブロック ストレージなど、他の VM と同じ Compute Engine 機能を使用できますが、ハードウェアが分離されます。物理サーバー上の VM を完全に制御するため、各単一テナントノードは、ノードをサポートする物理サーバーとの 1 対 1 マッピングを維持します。
単一テナンシーは特定のタイプのワークロードに適しています。たとえば、パフォーマンス要件があるゲーム ワークロードは、独自のハードウェア上に分離されているという点でメリットが得られます。また、セキュリティおよびコンプライアンス上の要件がある金融やヘルスケアのワークロードや、ライセンスに関する要件が伴う Windows のワークロードにも適しています。
単一テナントノード内では、さまざまなサイズのマシンタイプに複数の VM をプロビジョニングでき、専用ホスト ハードウェアの基盤となるリソースを効率的に使用できます。また、ホスト ハードウェアを他のプロジェクトと共有しないため、他のワークロードや VM からの物理的な分離が必要なワークロードでセキュリティやコンプライアンスの要件を満たすことができます。ワークロードが必要とするのが一時的な単一テナンシーのみの場合、必要に応じて VM テナントを変更できます。
単一テナントノードは、コアごとまたはプロセッサごとのライセンスが必要なお客様所有ライセンスの使用(BYOL)シナリオでの専用ハードウェア要件を満たすうえで役立ちます。単一テナントノードを使用すると基盤となるハードウェアを可視化できるため、コアとプロセッサの使用状況を追跡できます。使用状況を追跡するため、Compute Engine は VM がスケジュールされている物理サーバーの ID を報告します。これにより、Cloud Logging を使用して、VM の過去のサーバー使用状況を表示できます。ホスト ハードウェアの使用を最適化するために、単一テナント VM の CPU をオーバーコミットできます。
単一テナントノードでは、メンテナンス ポリシーを構成することでホスト メンテナンス イベント中の VM の動作を制御できます。メンテナンス ポリシーにより、単一テナントノードにプロビジョニングされた VM が特定の物理サーバーとアフィニティを維持するか、または VM を物理サーバーの固定グループ内に移動するかを指定できます。
単一テナントノードのプレビュー機能
- GPU
- グラフィック プロセッシング ユニット(GPU)の単一テナントノードのサポートは、プレビューにあります。ワークロードで機械学習、データ処理、またはイメージ レンダリングが必要な場合は、単一テナントノードで GPU を予約できます。
- ローカル SSD
- ローカル ソリッド ステート ドライブ(SSD)の単一テナントノードのサポートは、プレビューにあります。ワークロードで 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 |
Skylake | 416 | 11776 | 1:28.3 | 8 | 28 | 224 |
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 |
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 が任意のサーバーにライブ マイグレーションされるため、このポリシーはメンテナンス イベント中に物理コアの使用量を最小限に抑える必要があるシナリオには適していません。
再起動: このメンテナンス ポリシーを使用すると、Compute Engine はメンテナンス イベント中に VM を停止し、メンテナンス イベント後に同じ物理サーバー上で VM を再起動します。このポリシーを使用する場合、VM の [ホスト メンテナンス時] 設定を「
TERMINATE
」に設定する必要があります。次の特長があります。このポリシーは、ホスト メンテナンス イベント中に約 1 時間のダウンタイムが発生する可能性があるフォールト トレラントなワークロード、同じ物理サーバーに残す必要があるワークロード、ライブ マイグレーションを必要としないワークロード、または物理コア数やプロセッサ数に基づくライセンスを所有している場合に最適です。
このポリシーでは、インスタンスに
node-group-name
アフィニティ ラベルのみを割り当てる必要があります。このラベルは直接指定するか、ノードグループの名前を使用してノードグループ上で VM をスケジュールすることで指定できます。
ノードグループ内で移行: このメンテナンス ポリシーを使用すると、Compute Engine はメンテナンス イベント中に固定サイズの物理サーバー グループ内の VM をライブ マイグレーションします。これにより、VM が使用する一意の物理サーバーの数を制限できます。次の特長があります。
このメンテナンス ポリシーでは、グループ内の各単一テナントノードが一定のセットの物理サーバーに固定されます。そのため、このポリシーは、物理コア数またはプロセッサ数に基づくライセンスを持つ、高可用性ワークロードに最適です。これは、VM を任意のサーバーに移行できるデフォルトのポリシーとは異なります。
ライブ マイグレーション用の容量を確保するために、20 ノードをプロビジョニングするごとに、そのうちの 1 ノードが Compute Engine によって予約されます。
このポリシーでは、インスタンスに
node-group-name
アフィニティ ラベルのみを割り当てる必要があります。このラベルは直接指定するか、ノードグループの名前を使用してノードグループ上で VM をスケジュールすることで指定できます。
臨時メンテナンス
まれに重大なハードウェア障害が発生した場合、Compute Engine は次の処理を行います。
物理サーバーとその一意の識別子を廃止します。
プロジェクトの物理サーバーへのアクセスを取り消します。
障害が発生したハードウェアを、新しい一意の識別子を持つ新しい物理サーバーに置き換えます。
障害が発生したハードウェアから置換先のノードに VM を移動します。
影響を受ける VM を自動的に再起動するように構成した場合は、再起動します。
ノード アフィニティとアンチアフィニティ
単一テナントノードでは、VM が他のプロジェクトの VM とホスト ハードウェアを共有することはありません。ただし、同じ単一テナントノード上で複数のワークロードをグループ化することや、ワークロードを互いに異なるノードに分離する必要が生じることも考えられます。たとえば、コンプライアンス要件を満たすため、アフィニティ ラベルを使用して機密性の高いワークロードを機密性の低いワークロードから分離する場合です。
VM の作成時に、1 つ以上のノード アフィニティ ラベルを参照し、ノード アフィニティまたはアンチアフィニティを指定して単一テナンシーをリクエストします。ノード テンプレートの作成時にカスタム ノード アフィニティ ラベルを指定すると、Compute Engine は各ノードに複数のデフォルト アフィニティ ラベルを自動的に追加します。VM の作成時にアフィニティを指定すると、ノードグループ内の特定のノードで複数の VM を同時にスケジュールできます。VM の作成時にアンチアフィニティを指定すると、特定の VM がノードグループ内の同じノードまたは複数のノードで同時にスケジュールされないようにできます。
ノード アフィニティ ラベルは、ノードに割り当てられた Key-Value ペアであり、ノード テンプレートから継承されます。アフィニティ ラベルを使用すると、次のことができます。
- 個々の VM インスタンスをノードに割り当てる方法を制御する。
- テンプレートから作成された VM インスタンス(マネージド インスタンス グループによって作成されたものなど)をノードに割り当てる方法を制御する。
- 機密性の高い VM インスタンスを特定のノードまたはノードグループにグループ化し、他の VM から分離する。
デフォルト アフィニティ ラベル
Compute Engine は、各ノードに 2 つのデフォルト アフィニティ ラベルを割り当てます。
- ノードグループ名のラベル:
- キー:
compute.googleapis.com/node-group-name
- 値: ノードグループの名前。
- キー:
- ノード名のラベル:
- キー:
compute.googleapis.com/node-name
- 値: 個々のノードの名前
- キー:
カスタム アフィニティ ラベル
ノード テンプレートを作成するときに、カスタムのノード アフィニティ ラベルを作成できます。これらのアフィニティ ラベルは、ノード テンプレートから作成されたノードグループ内のすべてのノードに割り当てられます。ノードグループを作成した後に、ノードグループ内のノードにカスタム アフィニティ ラベルを追加することはできません。
アフィニティ ラベルの使用方法については、ノード アフィニティの構成をご覧ください。
料金
- 単一テナントノードのコストを最小限に抑えるため、Compute Engine では確約利用割引と継続利用割引を提供しています。また、単一テナントノードの vCPU とメモリについてはすでに課金されているため、単一テナントノードの VM に追加料金はかかりません。
プレビューの機能の料金
- GPU とローカル SSD の単一テナントノードのサポートについては、プレビューをご覧ください。 単一テナントノードで GPU またはローカル SSD を予約した場合、リソースを予約したノードごとに、すべての GPU またはローカル SSD が課金されます。
対象
単一テナントノードは、一部のゾーンでのみ使用可能です。高可用性を確保するため、異なるゾーンの単一テナントノードで VM をスケジュールします。
単一テナントノードで GPU またはローカル SSD を使用する前に、リソースを予約するゾーンに十分な GPU またはローカル SSD の割り当てがあることを確認してください。
Compute Engine は、GPU をサポートするゾーンの
n1
単一テナントノード タイプで GPU をサポートします。Compute Engine は、ローカル SSD をサポートするゾーンにある
n1
、n2
、n2d
単一テナントノード タイプでローカル SSD をサポートします。
制限事項
単一テナント VM は、2 つ以上の vCPU を持つマシンタイプを使用する必要があります。
単一テナント VM は、最小 CPU プラットフォームを指定できません。
VM が最小 CPU プラットフォームを指定している場合、VM を単一テナントノードに移行することはできません。VM を単一テナントノードに移行するには、VM のノード アフィニティ ラベルを更新する前に、最小 CPU プラットフォームの指定を「自動」に設定し、最小 CPU プラットフォームの指定を削除します。
単一テナントノードは、プリエンプティブル VM インスタンスをサポートしていません。
次のステップ
単一テナント VM の CPU をオーバーコミットする方法を学習する。
お客様所有ライセンスの使用(BYOL)について学習する。