單一用戶群總覽

單一租戶可專屬存取單一租戶節點，也就是專門用來託管專案 VM 的實體 Compute Engine 伺服器。使用單一租戶節點，即可將 VM 與其他專案中的 VM 實體隔離，或將 VM 集中在相同的主機硬體上，如下圖所示。您也可以建立單一租戶節點群組，並指定是否要與其他專案或整個組織共用。

多租戶主機與單一租戶節點。
圖 1：多租戶主機與單一租戶節點。

在單一租戶節點上執行的 VM 可以使用與其他 VM 相同的 Compute Engine 功能，包括透明排程和區塊儲存空間，但會增加一層硬體隔離。為了讓您完全掌控實體伺服器上的 VM，每個單一租戶節點都會與支援該節點的實體伺服器維持一對一對應關係。

在單一租戶節點中，您可以佈建多個不同大小的機器類型 VM，有效運用專屬主機硬體的基礎資源。此外，如果您選擇不與其他專案共用主機硬體，就能以實體方式區隔特定工作負載與其他工作負載或 VM，滿足安全或法規遵循需求。如果工作負載只需要暫時使用單一租戶，您可以視需要修改 VM 租戶。

單一租戶節點可協助您滿足自備授權 (BYOL) 情境的專屬硬體需求，這類情境需要每核心或每處理器授權。使用單一租戶節點時，您可以查看基礎硬體，追蹤核心和處理器的使用情形。為追蹤這項用量，Compute Engine 會回報排定 VM 的實體伺服器 ID。接著，您可以使用 Cloud Logging 查看 VM 的伺服器用量記錄。

如要充分運用主機硬體，可以採取下列做法：

您可以透過可設定的主機維護政策，控管單一租戶 VM 在主機維護期間的行為。您可以指定維護時間，以及 VM 是否要與特定實體伺服器保持親和性，或移至節點群組中的其他單一租戶節點。

工作負載考量事項

下列類型的工作負載可能適合使用單一租戶節點：

  • 有效能需求的遊戲工作負載

  • 有安全防護和法規遵循需求的金融或醫療保健工作負載

  • 有授權需求的 Windows 工作負載

  • 機器學習、資料處理或圖片算繪工作負載。對於這類工作負載，建議您預留 GPU。

  • 需要提高每秒 I/O 作業數 (IOPS) 並降低延遲的工作負載，或以快取、處理空間或低價值資料形式使用臨時儲存空間的工作負載。針對這類工作負載，建議預留本機 SSD 磁碟。

節點範本

節點範本是區域性資源，用於定義節點群組中每個節點的屬性。從節點範本建立節點群組時，節點範本的屬性會不可變動地複製到節點群組中的每個節點。

建立節點範本時，必須指定節點類型。建立節點範本時，您可以視需要指定節點相依性標籤。您只能在節點範本上指定節點相依性標籤。您無法在節點群組上指定節點親和性標籤。

節點類型

設定節點範本時，請指定要套用至節點群組中所有節點的節點類型，該節點群組是根據節點範本建立。節點範本參照的單一租戶節點類型，會指定使用該範本的節點群組中，所建立節點的 vCPU 核心總數和記憶體總量。舉例來說，n2-node-80-640 節點類型具備 80 個 vCPU 和 640 GB 記憶體。

新增至單一租戶節點的 VM，必須與您在節點範本中指定的節點類型具有相同的機型。例如，n2 單一租戶節點類型僅與使用 n2 機器類型建立的 VM 相容。只要 vCPU 或記憶體總量未超過節點容量，您就能將 VM 新增至單一租戶節點。

使用節點範本建立節點群組時，節點群組中的每個節點都會沿用節點範本的節點類型規格。節點類型會套用至節點群組中的每個節點，而非群組中的所有節點。因此，如果您建立的節點群組包含兩個節點，且這兩個節點都是 n2-node-80-640 節點類型，則每個節點都會分配到 80 個 vCPU 和 640 GB 記憶體。

視工作負載需求而定，您可以在節點中建立多個小型 VM，並在各種大小的機型上執行，包括預先定義機型、自訂機型和具備擴充記憶體的機型。節點容量已滿時，您無法在該節點上排定其他 VM。

下表列出可用的節點類型。如要查看專案可用的節點類型清單，請執行 gcloud compute sole-tenancy node-types list 指令，或建立 nodeTypes.list REST 要求。

節點類型 處理器 vCPU GB vCPU:GB 通訊端 核心：通訊端 核心總數 VM 數量上限
a2-highgpu-node-96-680 Cascade Lake 96 680 1:7.08 2 24 48 8
a2-megagpu-node-96-1360 Cascade Lake 96 1360 1:14.17 2 24 48 1
a2-ultragpu-node-96-1360-lssd 1 Cascade Lake 96 1360 1:14.17 2 24 48 1
a3-highgpu-node-208-1872-lssd 1 Sapphire Rapids 208 1872 1:9 2 56 112 8
a3-megagpu-node-208-1872-lssd 1 Sapphire Rapids 208 1872 1:9 2 56 112 1
c2-node-60-240 Cascade Lake 60 240 1:4 2 18 36 15
c3-node-176-352 Sapphire Rapids 176 352 1:2 2 48 96 44
c3-node-176-704 Sapphire Rapids 176 704 1:4 2 48 96 44
c3-node-176-704-lssd Sapphire Rapids 176 704 1:4 2 48 96 40
c3-node-176-1408 Sapphire Rapids 176 1408 1:8 2 48 96 44
c3d-node-360-708 AMD EPYC Genoa 360 708 1:2 2 96 192 34
c3d-node-360-1440 AMD EPYC Genoa 360 1440 1:4 2 96 192 40
c3d-node-360-2880 AMD EPYC Genoa 360 2880 1:8 2 96 192 40
c4-node-192-384 Emerald Rapids 192 384 1:2 2 60 120 26
c4-node-192-720 Emerald Rapids 192 720 1:3.75 2 60 120 26
c4-node-192-1488 Emerald Rapids 192 1,488 1:7.75 2 60 120 26
c4a-node-72-144 Google Axion 72 144 1:2 1 80 80 22
c4a-node-72-288 Google Axion 72 288 1:4 1 80 80 22
c4a-node-72-576 Google Axion 72 576 1:8 1 80 80 36
c4d-node-384-720 AMD EPYC Turin 384 720 1:2 2 128 256 24
c4d-node-384-1488 AMD EPYC Turin 384 1488 1:4 2 128 256 25
c4d-node-384-3024 AMD EPYC Turin 384 3024 1:8 2 128 256 25
c4n-node-192-384 Emerald Rapids 192 384 1:2 2 60 120 26
c4n-node-192-720 Emerald Rapids 192 720 1:3.75 2 60 120 26
c4n-node-192-1488 Emerald Rapids 192 1,488 1:7.75 2 60 120 26
g2-node-96-384 Cascade Lake 96 384 1:4 2 28 56 8
g4-node-384-1440 AMD EPYC Turin 384 1440 1:3.75 2 96 192 64
g2-node-96-432 Cascade Lake 96 432 1:4.5 2 28 56 8
h3-node-88-352 Sapphire Rapids 88 352 1:4 2 48 96 1
h4d-node-192-720 AMD EPYC Turin 192 720 1:4 2 128 256 1
h4d-node-192-1488 AMD EPYC Turin 192 1488 1:8 2 128 256 1
h4d-node-192-3024 AMD EPYC Turin 192 3024 1:16 2 128 256 1
h4d-node-192-3024-lssd AMD EPYC Turin 192 3024 1:16 2 128 256 1
m1-node-96-1433 Skylake 96 1433 1:14.93 2 28 56 1
m1-node-160-3844 Broadwell E7 160 3844 1:24 4 22 88 4
m2-node-416-8832 Cascade Lake 416 8832 1:21.23 8 28 224 1
m2-node-416-11776 Cascade Lake 416 11776 1:28.31 8 28 224 2
m3-node-128-1952 Ice Lake 128 1952 1:15.25 2 36 72 2
m3-node-128-3904 Ice Lake 128 3904 1:30.5 2 36 72 2
m4-node-224-2976 Emerald Rapids 224 2976 1:13.3 2 60 120 12
m4-node-224-5952 Emerald Rapids 224 5952 1:26.7 2 60 120 1
n1-node-96-624 Skylake 96 624 1:6.5 2 28 56 96
n2-node-80-640 Cascade Lake 80 640 1:8 2 24 48 80
n2-node-128-864 Ice Lake 128 864 1:6.75 2 36 72 128
n2d-node-224-896 AMD EPYC Milan 224 896 1:4 2 64 128 108
n2d-node-224-1792 AMD EPYC Milan 224 1792 1:8 2 64 128 112
n4-node-224-1372 Emerald Rapids 224 1372 1:6 2 60 120 90
n4a-node-96-624 Google Axion 96 624 1:6.5 1 96 96 72

1具有本機 SSD 的節點類型：-lssd 後置字串表示本機 SSD 磁碟已連接至節點。如果是 A3 High、A3 Mega 和 A2 Ultra 節點類型，未指定後置字串時，系統預設也會連接本機 SSD 磁碟。如要佈建這些節點類型，但不使用本機 SSD 磁碟，請使用 -nolssd 後置字串 (例如 a3-megagpu-node-208-1872-nolssd 或 a2-ultragpu-node-96-1360-nolssd)。

如要瞭解這些節點類型的價格，請參閱單一租戶節點定價。

所有節點都可讓您排定不同形狀的 VM。節點 n 類型為一般用途節點，您可以在其中排定自訂機型執行個體。如需節點類型選擇建議，請參閱「機型建議」。如要瞭解效能，請參閱「CPU 平台」。

節點群組和 VM 佈建

如要在單一租戶節點上佈建 VM，請依序完成下列工作：

  1. 建立單一租戶節點範本。
  2. 建立單一租戶節點群組。
  3. 在單一租戶節點上佈建 VM。

節點群組是特定可用區中同質的單一租戶節點集合。節點群組會沿用所依據節點範本的屬性，且可包含多個來自相同機器系列的 VM，這些 VM 可以在各種大小的機型上執行，只要機型有 2 個以上的 vCPU 即可。

建立節點群組時，您可以指定主機維護政策、共用設定和大小。節點群組可以有零或多個節點。您可以手動管理節點群組的大小，也可以啟用自動調度資源功能，根據工作負載自動調整大小。

建立節點群組後，您可以在該群組內的特定節點上佈建 VM。使用節點親和性標籤，精細控管 VM 放置位置。佈建完成後，您也可以使用資源標籤整理及管理 VM，以便用於計費或盤點等用途。

主機維護政策

視授權情境和工作負載而定，您可能需要限制 VM 使用的實體核心數量。您選擇的主機維護政策可能取決於授權或法規遵循要求，或者您可能想選擇可限制實體伺服器用量的政策。無論使用哪種政策，VM 都會保留在專屬硬體上。

在單一租戶節點上排定 VM 時，您可以從下列三種不同的主機維護政策選項中選擇，決定 Compute Engine 在主機事件 (大約每 4 到 6 週發生一次) 期間，是否要即時遷移 VM，以及遷移方式。在維護作業期間，Compute Engine 會將主機上的所有 VM 以群組形式即時遷移至其他單一租戶節點，但有時 Compute Engine 可能會將 VM 分成較小的群組，並將每個較小的 VM 群組即時遷移至不同的單一租戶節點。

預設主機維護政策

這是預設的主機維護政策，如果節點群組設定了這項政策，群組中的 VM 會遵循非單一用戶群 VM 的傳統維護行為。也就是說，視 VM 主機的主機維護設定而定，VM 會在主機維護事件發生前即時遷移至節點群組中的新單一租戶節點，且這個新的單一租戶節點只會執行客戶的 VM。

這項政策最適合用於每位使用者或每部裝置的授權，這些授權需要在主機事件期間進行即時遷移。這項設定不會限制 VM 只能遷移至固定的實體伺服器集區，建議用於沒有實體伺服器需求，且不需要現有授權的一般工作負載。

由於 VM 會即時遷移至任何伺服器，而不考慮現有伺服器與這項政策的相似性，因此這項政策不適用於需要在主機事件期間盡量減少使用實體核心的情境。

下圖為「預設」主機維護政策的動畫。

預設主機維護政策的動畫。
圖 2：「預設」主機維護政策的動畫。

不支援即時遷移的 VM

對於不支援即時遷移的 VM (例如部分機密 VM)，在主機維護事件期間，Compute Engine 會分配新的專屬節點、終止舊節點上的 VM，然後自動在新的節點上重新啟動這些 VM。VM 中斷的情況與標準重新啟動類似。

如果單一主機上同時執行可即時遷移的 VM 和不支援即時遷移的 VM，在維護事件期間，支援即時遷移的 VM 會遷移至新主機，其他 VM 則會終止並重新啟動。

如要盡量減少停機時間，請將單一租戶節點維護政策設為「Default」(預設)，並將 VM 設定為在主機維護期間終止，然後自動重新啟動 (onHostMaintenance=TERMINATE 和 automaticRestart=true)。

就地重新啟動主機維護政策

使用這項主機維護政策時，Compute Engine 會在主機事件期間停止 VM，並在主機事件結束後，於同一部實體伺服器上重新啟動 VM。使用這項政策時，您必須將 VM 的「在主機維護期間」設定設為 TERMINATE。

這項政策最適合容錯工作負載，且在主機事件期間可承受約一小時的停機時間、必須保留在同一部實體伺服器上的工作負載、不需要即時遷移的工作負載，或授權是按照實體核心或處理器數量計算。

透過這項政策，執行個體可使用 node-name、node-group-name 或節點親和性標籤指派給節點群組。

如果 VM 不支援即時遷移，請僅在需要實體伺服器親和性時，才使用「Restart in place」(就地重新啟動) 政策。否則，請使用「預設」政策，盡量減少停機時間。

下圖顯示「就地重新啟動」維護政策的動畫。

動畫：就地重新啟動主機維護政策
圖 3：「Restart in place」(就地重新啟動) 主機維護政策的動畫。

在節點群組內遷移主機維護政策

使用這項主機維護政策時，Compute Engine 會在主機事件期間，將固定大小實體伺服器群組中的 VM 即時遷移，有助於限制 VM 使用的實體伺服器數量。

這項政策最適合高可用性工作負載，且這類工作負載的授權是按照實體核心或處理器數量計算。這是因為在這項主機維護政策下，群組中的每個單一租戶節點都會固定在一組實體伺服器上，與預設政策不同，後者允許 VM 遷移至任何伺服器。

這項政策會透過即時遷移功能，將 VM 移至保留節點，因此不支援即時遷移的 VM 無法使用這項政策。如果 VM 無法即時遷移，且您沒有需要節點群組內實體伺服器相依性的軟體授權 (例如 Windows Server BYOL)，則使用這項政策並無好處，而且會產生預留保留節點的費用。

使用這項政策時，您無法使用 node-name 親和性標籤，將 VM 指派或手動即時遷移至特定節點。您可以使用任何自訂節點親和性標籤，只要同時指定 node-group-name 親和性標籤，而非 node-name 即可。

為確保即時遷移容量，每預留 20 個節點，Compute Engine 就會預留 1 個保留節點。下圖顯示「在節點群組中遷移」主機維護政策的動畫。

動畫：在節點群組內遷移的主機維護政策。
圖 4：在節點群組內遷移主機維護政策的動畫。

下表列出 Compute Engine 根據您為節點群組預留的節點數量，預留的保留節點數量。

群組中的節點總數 保留用於即時遷移的保留節點
1 不適用。至少須預留 2 個節點。
2 至 20 1
21 到 40 2
41 到 60 3
61 至 80 4
81 至 100 5

這項政策規定，必須隨時保留至少一個空的保留節點，以便進行即時遷移。如果嘗試刪除群組中唯一的空白節點，作業會失敗並顯示 insufficient holdback 錯誤。如要將 VM 整合至較少的節點，並刪除多餘的空白節點，請停止並重新啟動稀疏節點上的 VM，或手動將 VM 即時遷移至節點群組。

將執行個體固定至多個節點群組

在下列情況下，您可以使用 node-group-name 親和性標籤，將執行個體固定至多個節點群組：

  • 您要釘選的執行個體使用預設主機維護政策 (「遷移 VM 執行個體」)。
  • 您要固定執行個體的所有節點群組，其主機維護政策都是「在節點群組內遷移」。如果嘗試將執行個體固定至主機維護政策不同的節點群組，作業會失敗並顯示錯誤。

舉例來說，如要將執行個體 test-node 固定至兩個節點群組 node-group1 和 node-group2，請確認下列事項：

  • test-node 的主機維護政策為「遷移 VM 執行個體」。
  • node-group1 和 node-group2 的主機維護政策是在節點群組內遷移。

維護期間

如果您管理的工作負載 (例如經過微調的資料庫) 可能會受到即時遷移的效能影響，則可以在建立節點群組時指定維護時段，決定單一租戶節點群組的維護開始時間。節點群組建立後，就無法修改維護期間。

維護期間為 4 小時，您可指定 Google 在這段時間內對單一租戶節點執行維護作業。維護期間定義了節點維護作業的開始時間，這會觸發 VM 層級的即時遷移或終止並重新啟動動作。維護事件大約每 4 到 6 週發生一次。

維護期間會套用至單一租戶節點群組中的所有 VM，且只會指定維護作業的開始時間。我們不保證維護作業會在維護期間內完成，也不保證維護作業的頻率。如果節點群組的主機維護政策為「在節點群組內遷移」，則不支援維護期間。

模擬主機維護事件

您可以模擬主機維護事件，測試在單一租戶節點上執行的工作負載，在主機維護事件期間的行為。這樣一來，您就能瞭解單一租戶 VM 的主機維護政策，對 VM 上執行的應用程式有何影響。

主機錯誤

如果主機 (單一或多租戶) 發生罕見的重大硬體故障，Compute Engine 會執行下列操作：

  1. 淘汰實體伺服器及其專屬 ID。

  2. 撤銷專案的實體伺服器存取權。

  3. 以具有新專屬 ID 的新實體伺服器，取代故障的硬體。

  4. 將 VM 從故障硬體移至替代節點。

  5. 如果您已將受影響的 VM 設為自動重新啟動，系統會重新啟動這些 VM。

節點相依性和反相依性

單一租戶節點可確保 VM 不會與其他專案的 VM 共用主機，除非您使用共用的單一租戶節點群組。透過共用單一租戶節點群組，機構內的其他專案可以在同一部主機上佈建 VM。不過，您可能仍想在同一個單一租戶節點上將多個工作負載分組，或在不同節點上彼此隔離工作負載。舉例來說，為符合某些法規遵循要求，您可能需要使用親和性標籤，將敏感工作負載與非敏感工作負載分開。

建立 VM 時，請指定節點親和性或反親和性，並參照一或多個節點親和性標籤，藉此要求專屬租戶。建立節點範本時，您可以指定自訂節點親和性標籤，而 Compute Engine 會自動在每個節點上加入一些預設親和性標籤。建立 VM 時，您可以指定親和性，將 VM 一併排定在節點群組中的特定節點上。建立 VM 時指定反相依性，即可確保特定 VM 不會排定在同一節點或節點群組的節點上。

節點相依性標籤是指派給節點的鍵/值組合，且會從節點範本繼承。相依性標籤可讓您：

  • 控管個別 VM 執行個體指派至節點的方式。
  • 控管如何將透過範本建立的 VM 執行個體 (例如由代管執行個體群組建立的執行個體) 指派給節點。
  • 將機密 VM 執行個體分組至特定節點或節點群組，與其他 VM 分開。

預設相依性標籤

Compute Engine 會為每個節點指派下列預設親和性標籤：

  • 節點群組名稱的標籤：
    • 鍵：compute.googleapis.com/node-group-name
    • 值：節點群組名稱。
  • 節點名稱的標籤：
    • 鍵：compute.googleapis.com/node-name
    • 值：個別節點的名稱。
  • 節點群組共用專案的標籤：
    • 鍵：compute.googleapis.com/project
    • 值：節點群組所屬專案的專案 ID。

自訂興趣相似目標對象標籤

建立節點範本時，可以建立自訂節點相似度標籤。這些親和性標籤會指派給依據節點範本建立的節點群組中的所有節點。節點群組建立後，您就無法在節點群組的節點中新增更多自訂親和性標籤。

如要瞭解如何使用親和性標籤，請參閱「設定節點親和性」。

定價

  • 為協助您盡量減少單一租戶節點的成本，Compute Engine 提供承諾使用折扣 (CUD) 和續用折扣 (SUD)。請注意，單一租戶溢價費用只能享有彈性 CUD 和 SUD，不適用依資源計算的 CUD。

  • 由於您已支付單一租戶節點的 vCPU 和記憶體費用，因此在這些節點上建立 VM 時，不會產生額外費用。

  • 如果您使用 GPU 或本機 SSD 磁碟佈建專屬節點，系統會針對您佈建的每個節點上的所有 GPU 或本機 SSD 磁碟收費。單一租戶附加費只會根據您用於單一租戶節點的 vCPU 和記憶體計算，不含 GPU 或本機 SSD 磁碟。

詳情請參閱「單一租戶節點定價」。

可用性

  • 單一租戶節點僅適用於特定可用區。如要驗證高可用性，請在不同可用區的單一租戶節點上排定 VM。

  • 在單一租戶節點上使用 GPU 或本機 SSD 磁碟前，請確認您在預留資源的可用區中，有足夠的 GPU 或本機 SSD 配額。

  • Compute Engine 支援 n1、g2、g4、a2-highgpu、a2-megagpu、a2-ultragpu、a3-highgpu 和 a3-megagpu 單一租戶節點類型的 GPU，這些節點類型位於支援 GPU 的可用區。下表列出可附加至 n1、g2、g4、a2 和 a3 節點的 GPU 類型，以及建立節點範本時必須附加的 GPU 數量。

    GPU 類型 GPU 數量 單一租戶節點類型
    NVIDIA A100 40GB 8 a2-highgpu
    NVIDIA A100 40GB 16 a2-megagpu
    NVIDIA A100 80GB 8 a2-ultragpu
    NVIDIA H100 8 a3-highgpu
    NVIDIA H100 8 a3-megagpu
    NVIDIA L4 8 g2
    NVIDIA RTX PRO 6000 8 g4
    NVIDIA P4 4 n1
    NVIDIA T4 4 n1
    NVIDIA V100 8 n1

  • Compute Engine 支援支援這些機器系列的可用區中使用的 n1、n2、n2d、g2、g4、a2-ultragpu、a3-highgpu 和 a3-megagpu 單一租戶節點類型上的本機 SSD 磁碟。

限制

  • 您無法將下列機器系列和類型與單一租戶 VM 搭配使用： T2D、 T2A、 E2、 C2D、 A3 Ultra、 A3 Edge、 A4、 A4X 或 裸機執行個體。

  • 單一租戶 VM 無法指定最低 CPU 平台。

  • 如果 VM 指定了最低 CPU 平台，就無法遷移至單一租戶節點。如要將 VM 遷移至單一租戶節點，請將最低 CPU 平台規格設為自動，藉此移除該規格，然後更新 VM 的節點親和性標籤。

  • 單一租戶節點不支援先占 VM 執行個體。

  • 如要瞭解在單一租戶節點上使用本機 SSD 磁碟的限制，請參閱「本機 SSD 資料持續性」。

  • 如要瞭解使用 GPU 對即時遷移的影響，請參閱即時遷移的限制。

  • 不支援即時遷移的機密 VM，在三種單一租戶節點維護政策中，有不同的行為和限制。詳情請參閱「主機維護政策」和「排解 Confidential VM 的即時遷移問題」。

  • 搭載 GPU 的單一租戶節點不支援沒有 GPU 的 VM。

  • 只有 N1、N2、N2D 和 N4 單一租戶節點支援超額配置 CPU。

  • C3、C3D、C4、C4A、C4D、G4、N4 和 M4 VM 的排程會配合單一租戶節點的基礎 NUMA 架構。在同一個節點上排定完整和子 NUMA VM 形態，可能會導致分割，也就是無法執行較大的形態，但可以執行多個資源需求總和相同的較小形態。

  • C3 和 C4 單一租戶節點要求 VM 的 vCPU 與記憶體比率與節點類型相同，例如，您無法將 c3-standard VM 放在 -highmem 節點類型上。

  • 您無法更新運作中節點群組的維護政策。

後續步驟