單一用戶群總覽

單一租戶可專屬存取單一租戶節點,也就是專門用來託管專案 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 可在各種大小的機器類型上執行,包括預先定義的機器類型、自訂機器類型和具備擴充記憶體的機器類型。節點容量已滿時,您無法在該節點上排定其他 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:Default 主機維護政策的動畫。

不支援即時遷移的 VM

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

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

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

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

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

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

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

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

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

動畫:就地重新啟動主機維護政策
圖 3:就地重新啟動主機維護政策的動畫。

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

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

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

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

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

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

下表說明 Compute Engine 會保留多少個預留節點,取決於您為節點群組預留的節點數量。

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

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

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

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

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

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

您無法使用親和性標籤 node-name 將執行個體指派給任何特定節點。只要將執行個體指派為 node-group-name,而非 node-name,即可使用任何執行個體的自訂節點親和性標籤。

維護期間

如果您管理的工作負載 (例如經過微調的資料庫) 可能對即時遷移的效能影響很敏感,那麼您可以在建立節點群組時指定維護時間範圍,決定單一租戶節點群組的維護作業開始時間。節點群組建立後,就無法修改維護期間。

維護期間為 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/projects
    • 值:節點群組所屬專案的專案 ID。

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

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

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

可用性

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

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

  • Compute Engine 支援 n1、g2、g4、a2-highgpu、a2-megagpu、a2-ultragpu、a3-highgpu 和 a3-megagpu 單一租戶節點類型,這些類型位於支援 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 遷移至單一租戶節點。如要將 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 節點類型上。

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

後續步驟