単一テナントノード

Linux VMs Windows VMs

このドキュメントでは、単一テナントノードについて説明します。単一テナントノードの 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）について学習する。