多個網路介面

本頁面提供 Compute Engine 執行個體多個網路介面的總覽。具有多個網路介面的執行個體稱為多 NIC 執行個體。

執行個體網路介面會連線至虛擬私有雲 (VPC) 網路，可以是虛擬網路介面 (vNIC) 或Dynamic NIC，其中 Dynamic NIC 是父項 vNIC 的子項子介面。執行個體的 vNIC 由執行個體所在主機伺服器上的一或多個實體 NIC 支援。詳情請參閱「網路介面類型」。

用途

多 NIC 執行個體適用於下列情況：

  • 連線至不同虛擬私有雲網路中的資源：多 NIC 執行個體可連線至不同虛擬私有雲網路中的資源，這些網路並未透過虛擬私有雲網路對等互連或 NCC 相互連線。

    • 由於多 NIC 執行個體的每個介面都位於不同的虛擬私有雲網路，因此您可以將每個介面用於不同的用途。舉例來說，您可以使用某些介面在傳輸實際工作環境流量的虛擬私有雲網路之間轉送封包，並使用其他介面進行管理或設定。

    • 在每個多 NIC 執行個體的客體 OS 中，您必須設定路由政策和本機路由表。

  • 在虛擬私有雲網路之間轉送封包：多 NIC 執行個體可用做路由的下一個躍點，連線至兩個以上的虛擬私有雲網路。

    • 在多 NIC 執行個體的客體 OS 中執行的軟體，可以執行封包檢查、網路位址轉譯 (NAT) 或其他網路安全功能。

    • 使用多 NIC 執行個體連線虛擬私有雲網路時，建議您設定兩個以上的多 NIC 執行個體，並將這些執行個體做為每個虛擬私有雲網路中內部直通網路負載平衡器的後端。詳情請參閱「以內部直通式網路負載平衡器為下一個躍點」說明文件中的「使用案例」一節。

  • 如要增加執行個體的總網路頻寬：多重 NIC 執行個體支援的頻寬增加幅度如下：

    • 在 Google Cloud中，部分機器類型執行個體是由主機伺服器上的多個實體 NIC 支援。建立具有多個 vNIC 的執行個體，其中每個 vNIC 使用不同的實體 NIC，可增加執行個體的總網路頻寬。詳情請參閱「實體 NIC」和「同一虛擬私有雲網路中的多個網路介面」。

    • 在 Google Cloud中，大多數機器類型的執行個體都是由主機伺服器上的單一實體 NIC 支援，且每個 vNIC 使用的都是同一個實體 NIC。如果 vNIC 共用實體 NIC，新增 vNIC 不會增加網路頻寬。

您也可以使用具備 Private Service Connect 介面的多 NIC 執行個體，連線至不同專案中的服務供應商和用戶網路。

網路介面類型

如要進一步瞭解Google Cloud中的網路介面類型，請參閱下列各節。

執行個體網路介面

Compute Engine 執行個體會使用您設定的網路介面 (可以是 vNIC 或動態 NIC) 連線至 VPC 網路。這些執行個體網路介面會對應至 Compute Engine API 中的 instances.networkInterfaces[] 資源和屬性。

如要進一步瞭解各類執行個體網路介面，請參閱下列內容：

  • 虛擬網路介面 (vNIC)：向執行個體客體 OS 公開的軟體定義網路介面，可讓執行個體連線至虛擬私有雲網路。每個執行個體至少要有一個 vNIC。

    • 您只能在建立執行個體時設定 vNIC。

    • Google Cloud 指派的 vNIC 名稱格式如下：nicN，例如 nic0。對應的客體 OS 指派名稱會因作業系統而異，例如 Ubuntu 的名稱為 ens4。

    • 視相關聯的虛擬私有雲網路而定，vNIC 可以是下列其中一種類型。每種型別都對應到客層 OS 中的特定網路驅動程式：

      如要瞭解哪些機器類型支援哪些 vNIC 類型，請參閱「機器系列比較」。

  • Dynamic NIC：上層 vNIC 的子項，在執行個體的客體作業系統中實作為子介面。

    • 您可以在建立執行個體時設定動態 NIC，也可以稍後再新增。

    • Google Cloud 指派的 Dynamic NIC 名稱格式如下：nicN.VLAN_ID，例如 nic0.2。對應的客體 OS 指派名稱視作業系統而定。舉例來說，如果您使用客體代理程式管理 Ubuntu 中的動態 NIC，名稱可能為 a-gcp.ens4.2。

    • 具有 RDMA 網路設定檔的 VPC 網路不支援動態 NIC。

    詳情請參閱「動態 NIC」。

實體 NIC

實體 NIC 是直接安裝在主機伺服器上的硬體元件，執行個體會在該伺服器上執行。視執行個體的機型而定，執行個體的 vNIC 會對應至主機伺服器上的一或多個實體 NIC，如下所示：

  • 由一個實體 NIC 支援的執行個體：對於大多數機器類型，執行個體會在具有單一實體 NIC 的主機伺服器上執行。以特定執行個體來說，所有執行個體的 vNIC 都會對應至單一實體 NIC。

  • 由多個實體 NIC 支援的執行個體：對於一組有限的機器類型 (例如 C4N 機器類型和 GPU 機器類型)，執行個體會在具有多個實體 NIC 的主機伺服器上執行。針對特定執行個體，Compute Engine 會將執行個體的 vNIC 對應至不同的實體 NIC。

    • 由多個實體 NIC 支援的執行個體，可支援增加網路頻寬和透過 RoCE 虛擬私有雲網路進行 GPU 對 GPU 通訊等用途。詳情請參閱「C4N 執行個體的網路支援」和「網路和 GPU 電腦」。

    • 建立執行個體時，Compute Engine 會將每個虛擬 NIC 對應至一個實體 NIC，最多可對應至執行個體機型的實體 NIC 總數。

    • 如要瞭解多個實體 NIC 的支援情形，請參閱特定機器系列的說明文件。如果適用，機型表格會包含名為「實體 NIC 數量」的資料欄。舉例來說，請參閱 C4N 機型。

此外，對於大多數機器類型，執行個體會與其他執行個體共用主機伺服器。共用主機伺服器的執行個體也會共用實體 NIC 或一組實體 NIC。不過，對於某些機器類型 (例如裸機機器類型或 H3 和 H4D 機器類型)，單一執行個體會佔用整個主機伺服器。

規格

下列規格適用於具有多個網路介面的執行個體：

  • 執行個體和網路介面：每個執行個體都有 nic0 介面。網路介面數量上限會因執行個體的機型而異。

    • 每個介面都有相關聯的堆疊類型，決定支援的子網路堆疊類型和 IP 位址版本。詳情請參閱「堆疊類型和 IP 位址」。

  • 網路和子網路需求：每個網路介面都必須使用虛擬私有雲網路中的不重複子網路。

    • 系統支援將網路介面附加至不同虛擬私有雲網路中的子網路。

    • 在相同虛擬私有雲網路中，將網路介面附加至不同子網路，適用於下列情境：

    • 如果是使用 RDMA 網路設定檔建立的虛擬私有雲網路，多個 RDMA NIC 可以使用相同的虛擬私有雲網路。詳情請參閱「支援與不支援的功能」一文，瞭解各個網路設定檔的表格。

    • 您必須先建立虛擬私有雲網路和子網路，才能建立網路介面使用該網路和子網路的執行個體。如要進一步瞭解如何建立網路和子網路，請參閱「建立及管理虛擬私有雲網路」。

  • 執行個體和子網路的專案：在獨立專案中，多個 NIC 執行個體的每個網路介面都必須使用與執行個體位於相同專案的子網路。

  • IP 轉送、MTU 和路徑注意事項：多 NIC 執行個體需要仔細規劃下列執行個體和介面專屬的設定選項：

    • IP 轉送選項可針對每個執行個體設定，並套用至所有網路介面。詳情請參閱「為執行個體啟用 IP 轉送功能」。

    • 每個網路介面都可以使用不重複的最大傳輸單元 (MTU)，與相關聯的 VPC 網路 MTU 相符。詳情請參閱「最大傳輸單位」。

    • 每個執行個體都會收到預設路徑，方法是使用 RFC 3442 定義的 DHCP 選項 121。預設路徑與 nic0 相關聯。除非您手動設定，否則流量從執行個體傳送至直接連線的子網路以外的任何目的地時，都會透過 nic0 的預設路徑傳出執行個體。

      在 Linux 系統上，您可以使用 /etc/iproute2/rt_tables 檔案和 ip rule 與 ip route 指令，在客體 OS 中設定自訂規則和路徑。詳情請參閱客體 OS 說明文件。如需範例，請參閱「為額外介面設定路由」教學課程。

相同虛擬私有雲網路中的多個網路介面

您可以將執行個體的其他 vNIC 連接至與執行個體 nic0 vNIC 相同的虛擬私有雲網路。

您可能會想將多個 vNIC 連結至同一個虛擬私有雲網路，以提高虛擬私有雲網路中執行個體的頻寬：

  • 在 Google Cloud中，部分機器類型的執行個體是由主機伺服器上的多個實體 NIC 支援，如「實體 NIC」一節所述。

    建立具有多個 vNIC 的執行個體，且每個 vNIC 使用不同的實體 NIC，可提高 vNIC 所連虛擬私有雲網路的執行個體網路頻寬。

  • 在 Google Cloud中，大多數機器類型執行個體都由一個實體 NIC 支援。對於這些機型，建議您將每個虛擬 NIC 連接至個別的虛擬私有雲網路。

同一虛擬私有雲網路中多個網路介面的限制

將執行個體的多個網路介面連結至相同虛擬私有雲網路時，請注意下列限制：

  • 額外網路介面必須連結至與 nic0 介面相同的網路。
  • 如要為非 nic0 介面取得額外網路頻寬，您必須使用由多個實體 NIC 支援的機型。
  • 不支援下列項目：
    • Dynamic NIC。
    • Private Service Connect 介面。
    • 對於 Cloud Load Balancing，您可以將附加至相同虛擬私有雲網路的多個 vNIC 執行個體，新增至執行個體群組或區域網路端點群組 (NEG) 後端。不過，從附加至相同虛擬私有雲網路的一組虛擬 NIC，流量只能分配至 nic0。
    • 如果是靜態路徑，您無法使用名稱和區域 (next-hop-instance) 指定下一個躍點執行個體，將封包傳送至非 nic0 介面。請改用位址 (next-hop-address) 指定下一個躍點執行個體。詳情請參閱「下一個躍點和功能」。
    • 透過連結匯總進行網路介面綁定。

Dynamic NIC

如果您的用途需要下列任一功能，請使用動態 NIC。 請務必一併查看動態 NIC 的屬性和限制。

  • 您需要為現有執行個體新增或移除網路介面。 新增或移除 Dynamic NIC 時，不需要重新啟動或重新建立執行個體。

  • 您需要更多網路介面。大多數機器類型在 Google Cloud 中的 vNIC 數量上限為 10 個，但您可以使用動態 NIC 設定最多 16 個介面。詳情請參閱「網路介面數量上限」。

  • 您需要設定多 NIC Compute Engine 裸機執行個體，這類執行個體只有一個 vNIC。

Dynamic NIC 的屬性

請參閱下列動態 NIC 屬性相關資訊：

  • 動態 NIC 是使用 IEEE 802.1Q 標準封包格式的 VLAN 介面。請參閱下列注意事項：

    • Dynamic NIC 的 VLAN ID 必須是介於 2 至 255 之間的整數。
    • Dynamic NIC 的 VLAN ID 在上層 vNIC 中不得重複。不過，屬於不同上層 vNIC 的 Dynamic NIC 可以使用相同的 VLAN ID。

  • Google Cloud Dynamic NIC 的名稱採用下列格式： nicNUMBER.VLAN_ID，其中

    • nicNUMBER 是父項 vNIC 的名稱，例如 nic0。
    • VLAN_ID 是您設定的 VLAN ID，例如 4。

    動態 NIC 名稱範例為 nic0.4。

  • 建立使用 Dynamic NIC 的執行個體，或為現有執行個體新增 Dynamic NIC 時，需要額外步驟，才能在客體 OS 中安裝及管理對應的 VLAN 介面。你可以使用下列任一方法：

    • 使用客體代理程式，設定動態 NIC 的自動管理功能。

    • 手動設定客體 OS。

    詳情請參閱「設定動態 NIC 的客體 OS」。

  • Dynamic NIC 會共用上層 vNIC 的頻寬。 為避免任何網路介面耗用所有頻寬，您必須在客體 OS 中建立應用程式專屬的流量政策，以優先處理或分配流量，例如使用 Linux 流量控制 (TC)。

  • Dynamic NIC 與上層 vNIC 共用相同的接收和傳輸佇列。如要設定網路介面，使用不同的接收和傳輸佇列，請使用 vNIC，而非動態 NIC。

  • Dynamic NIC 的堆疊類型可以與上層 vNIC 相同或不同。舉例來說，您可以在僅限 IPv4 的上層 vNIC 下方，建立僅限 IPv6 和雙堆疊的 Dynamic NIC。

Dynamic NIC 的限制

動態 NIC 有下列限制：

堆疊類型和 IP 位址

建立網路介面時，請指定下列其中一種介面堆疊類型：

  • 僅限 IPv4
  • 雙堆疊
  • 僅限 IPv6

VM 執行個體可以有多個網路介面，且這些介面可有不同的堆疊類型。

下表說明支援的子網路堆疊類型，以及各介面堆疊類型的 IP 位址詳細資料：

介面 僅支援 IPv4 的子網路 雙堆疊子網路 僅限 IPv6 的子網路 IP 位址詳細資料
僅限 IPv4 (單一堆疊) 僅限 IPv4 位址。請參閱 IPv4 位址詳細資料。
IPv4 和 IPv6 (雙重堆疊) IPv4 和 IPv6 位址。請參閱 IPv4 位址詳細資料和 IPv6 位址詳細資料
僅限 IPv6 (單一堆疊) 僅限 IPv6 位址。請參閱 IPv6 位址詳細資料。

變更網路介面堆疊類型

您可以按照下列方式變更網路介面的堆疊類型：

  • 如果介面的子網路是雙重堆疊子網路，或是您停止執行個體並將介面指派給雙重堆疊子網路，就可以將僅支援 IPv4 的介面轉換為雙重堆疊。

  • 您可以將雙重堆疊介面轉換為僅限 IPv4。

您無法變更僅限 IPv6 介面的堆疊類型。建立執行個體時，系統僅支援僅限 IPv6 的介面。

IPv4 位址詳細資料

每個僅限 IPv4 或雙重堆疊的網路介面都會收到主要內部 IPv4 位址。每個介面可選擇支援別名 IP 範圍和外部 IPv4 位址。以下是 IPv4 的規格和規定：

  • 主要內部 IPv4 位址：Compute Engine 會從介面子網路的主要 IPv4 位址範圍，為網路介面指派主要內部 IPv4 位址。主要內部 IPv4 位址是由 DHCP 分配。

    • 您可以設定靜態內部 IPv4 位址，或指定自訂的臨時內部 IPv4 位址，控管要指派哪個主要內部 IPv4 位址。

    • 在虛擬私有雲網路中，每個 VM 網路介面的主要內部 IPv4 位址都是唯一的。

  • 別名 IP 範圍：您可以選擇為介面指派一或多個別名 IP 範圍。每個別名 IP 範圍可來自介面子網路的主要 IPv4 位址範圍或次要 IPv4 位址範圍。

    • 在虛擬私有雲網路中，每個介面的別名 IP 範圍必須不重複。

  • 外部 IPv4 位址：您可以視需要為介面指派臨時或保留的外部 IPv4 位址。 Google Cloud 可確保每個外部 IPv4 位址都是唯一的。

IPv6 位址詳細資料

Compute Engine 會為每個雙重堆疊或僅限 IPv6 的網路介面，指派介面子網路 IPv6 位址範圍中的 /96 IPv6 位址範圍：/64

  • /96 IPv6 位址範圍是內部或外部，取決於介面子網路的 IPv6 存取權類型。 Google Cloud 可確保每個內部和外部 IPv6 位址範圍的獨特性。詳情請參閱 IPv6 規格。

    • 如果執行個體需要內部 IPv6 位址範圍和外部 IPv6 位址範圍，則必須設定兩個雙重堆疊介面、兩個僅限 IPv6 的介面，或是一個雙重堆疊介面和一個僅限 IPv6 的介面。一個介面使用的子網路必須有外部 IPv6 位址範圍，另一個介面使用的子網路則必須有內部 IPv6 位址範圍。

  • 第一個 IPv6 位址 (/128) 是由 DHCP 在介面上設定。 詳情請參閱「IPv6 位址指派」。

  • 您可以設定靜態內部或外部 IPv6 位址範圍，控管指派的 /96 IPv6 位址範圍。如果是內部 IPv6 位址，您可以指定自訂的臨時內部 IPv6 位址。

如要使用 IPv6 位址將執行個體連線至多個網路，請安裝 google-guest-agent 版本 20220603.00 以上版本。詳情請參閱我無法連線至次要介面的 IPv6 位址。

網路介面數量上限

對於大多數機型，您可以附加至執行個體的網路介面數量上限，會隨著 vCPU 數量而調整，如下表所示。

以下是機器專屬的例外狀況：

  • Compute Engine Bare Metal 執行個體支援單一 vNIC。

  • 部分加速器最佳化機型 (例如 A3、A4 和 A4X) 的 vNIC 數量上限有所不同。 詳情請參閱「加速器最佳化機器家族」。

介面數量上限

如要瞭解可連接至執行個體的網路介面數量，請參閱下表。

vCPU 數量 虛擬 NIC 數量上限 動態 NIC 數量上限 網路介面數量上限
(vNIC + Dynamic NIC)
最多 2 個 2 1 2
4 4 3 4
6 6 5 6
8 8 7 8
10 10 9 10
12 10 10 11
14 10 11 12
16 10 12 13
18 10 13 14
20 10 14 15
22 個以上 10 15 16

參考公式

下表提供用於計算執行個體網路介面數上限的公式。公式取決於 vCPU 數量。

vCPU 數量 (X) 虛擬 NIC 數量上限 動態 NIC 數量上限 網路介面數量上限
(vNIC + Dynamic NIC)
X=1 2 1 2
2 ≤ X ≤ 10 X (X-1) X
X ≥ 12 10 min(15, (X-10)/2 + 9) min(16, (X-10)/2 + 10)

動態 NIC 的分配範例

您不必在 vNIC 間平均分配動態 NIC。不過，您可能希望平均分配，因為動態 NIC 會共用父項 vNIC 的頻寬。

執行個體至少要有一個 vNIC。舉例來說，具有 2 個 vCPU 的執行個體可以有下列其中一種設定：

  • 1 個 vNIC
  • 2 個 vNIC
  • 1 個 vNIC 和 1 個 Dynamic NIC

下表提供範例設定，可在使用指定 vCPU 數量上限的網路介面時，將動態 NIC 平均分配到 vNIC。

2 個 vCPU、2 個 NIC

下表提供 2 個 vCPU 的執行個體範例，說明特定數量的虛擬 NIC 可擁有的動態 NIC 數量。

vCPU 數量 虛擬 NIC 數量 每個 vNIC 的 Dynamic NIC 數量 網路介面總數 (vNIC + Dynamic NIC)
2 1 1 2
2 0

4 個 vCPU、4 個 NIC

下表提供 4 個 vCPU 的執行個體範例，說明特定數量的 vNIC 可擁有的動態 NIC 數量。

vCPU 數量 虛擬 NIC 數量 每個 vNIC 的 Dynamic NIC 數量 網路介面總數 (vNIC + Dynamic NIC)
4 1 3 4
2 1
4 0

8 個 vCPU、8 個 NIC

下表提供 8 個 vCPU 的執行個體範例，說明特定數量的 vNIC 可擁有的動態 NIC 數量。

vCPU 數量 虛擬 NIC 數量 每個 vNIC 的 Dynamic NIC 數量 網路介面總數 (vNIC + Dynamic NIC)
8 1 7 8
2 3
4 1
8 0

14 個 vCPU、12 個 NIC

下表提供 12 個 vCPU 的執行個體範例，說明特定數量的 vNIC 可擁有的動態 NIC 數量。

vCPU 數量 虛擬 NIC 數量 每個 vNIC 的 Dynamic NIC 數量 網路介面總數 (vNIC + Dynamic NIC)
14 1 11 12
2 5
4 2
6 1

22 個 vCPU、16 個 NIC

下表提供 22 個 vCPU 的執行個體範例，說明特定數量的 vNIC 可擁有的動態 NIC 數量。

vCPU 數量 虛擬 NIC 數量 每個 vNIC 的 Dynamic NIC 數量 網路介面總數 (vNIC + Dynamic NIC)
22 1 15 16
2 7
4 3
8 1

產品互動

本節說明多 NIC 執行個體與 Google Cloud中其他產品和功能之間的互動。

Shared VPC

除了 Private Service Connect 介面，共用虛擬私有雲主專案或服務專案中多 NIC 執行個體的子網路和專案關係如下：

  • 位於 Shared VPC 主專案中的多 NIC 執行個體，其每個網路介面都必須使用主專案中共用虛擬私有雲網路的子網路。

  • 位於 Shared VPC 服務專案中的多 NIC 執行個體，其每個網路介面都可以使用下列任一項目：

    • 服務專案中虛擬私有雲網路的子網路。
    • 主專案中共用虛擬私有雲網路的子網路。

如要進一步瞭解 Shared VPC，請參閱：

Compute Engine 內部 DNS

Compute Engine 只會為執行個體 nic0 網路介面的主要內部 IPv4 位址，建立內部 DNS 名稱 A 和 PTR 記錄。Compute Engine 不會為與 nic0 不同的網路介面相關聯的任何 IPv4 或 IPv6 位址，建立內部 DNS 記錄。

詳情請參閱「Compute Engine 內部 DNS」。

靜態路徑

靜態路徑可使用網路標記，將範圍限定在特定執行個體。網路標記與執行個體建立關聯後，該標記會套用至執行個體的所有網路介面。因此，在執行個體中新增或移除網路標記，可能會變更適用於執行個體任何網路介面的靜態路徑。

負載平衡器

執行個體群組後端和區域性 NEG 後端各自有相關聯的虛擬私有雲網路，如下所示：

  • 如果是代管執行個體群組 (MIG)，執行個體群組的虛擬私有雲網路，就是指派給執行個體範本中介面的虛擬私有雲網路。nic0

  • 對於非代管執行個體群組，執行個體群組的虛擬私有雲網路，是您新增至非代管執行個體群組的第一個執行個體所使用的 nic0 網路介面虛擬私有雲網路。

下表列出哪些後端支援將連線或要求分配至任何網路介面。

負載平衡器 執行個體群組 GCE_VM_IP NEG GCE_VM_IP_PORT NEG
以後端服務為基礎的區域外部直通式網路負載平衡器
後端服務不會與虛擬私有雲網路建立關聯。詳情請參閱「 後端服務和虛擬私有雲網路」。		 僅使用 nic0 任何 NIC1 不適用
內部直通式網路負載平衡器
後端服務會與虛擬私有雲網路建立關聯。 詳情請參閱「 後端服務網路規格」和「 後端服務網路規則」。		 任何 NIC 任何 NIC 不適用
外部 Proxy 網路負載平衡器
如要進一步瞭解後端服務和網路需求，請參閱「後端和虛擬私有雲網路」。 		僅使用 nic0 不適用 任何 NIC
內部 Proxy 網路負載平衡器
如要進一步瞭解後端服務和網路需求，請參閱「 後端和虛擬私有雲網路」。 		僅使用 nic0 不適用 任何 NIC
外部應用程式負載平衡器
如要進一步瞭解後端服務和網路需求，請參閱「後端」和「虛擬私有雲網路」。 		僅使用 nic0 不適用 任何 NIC
內部應用程式負載平衡器
如要進一步瞭解後端服務和網路需求，請參閱「後端」和「虛擬私有雲網路」。 		僅使用 nic0 不適用 任何 NIC

1在整個表格中，如果執行個體的多個網路介面位於同一個虛擬私有雲網路 (預先發布版)，則不適用「任何 NIC」。詳情請參閱同一虛擬私有雲網路中多個網路介面的限制。

以目標集區為基礎的區域性外部直通式網路負載平衡器不會使用執行個體群組或 NEG，且僅支援負載平衡至nic0網路介面。

防火牆規則

防火牆規則集 (來自階層式防火牆政策、全域網路防火牆政策、區域網路防火牆政策和 VPC 防火牆規則) 適用於每個網路介面。確認每個網路都有適當的防火牆規則，允許您要允許進出多 NIC 執行個體的流量。如要判斷哪些防火牆規則套用至網路介面，以及每項規則的來源，請參閱「取得 VM 介面的有效防火牆規則」。

您可以使用網路標記或安全標記，將防火牆規則的適用範圍限定在特定 VM 執行個體，這兩種標記都會套用至執行個體的所有網路介面。詳情請參閱「安全代碼與網路代碼比較」。

已知問題

本節說明在 Google Cloud中使用多個網路介面的相關已知問題。

使用動態 NIC 和 GPU 執行個體時發生建立錯誤和效能降低

動態 NIC 不支援搭配 GPU 執行個體使用。如果您使用動態 NIC 建立 GPU 執行個體，或將動態 NIC 新增至現有 GPU 執行個體，可能會發生下列問題：

  • 作業失敗，並顯示下列錯誤：

    Internal error. Please try again or contact Google Support. (Code: 'CODE')

  • 作業成功，但執行個體效能下降，例如網路頻寬大幅降低。

發生這些問題的原因是，當 Compute Engine 嘗試將執行個體的虛擬 NIC 分散到主機伺服器上的實體 NIC 時，Dynamic NIC 設定會導致錯誤。

使用動態 NIC 時，封包會因別名 IP 範圍、通訊協定轉送或直通式網路負載平衡器而遭到捨棄

在下列情況下，客體代理程式會自動為 vNIC 新增本機路徑，但不會為動態 NIC 新增：

  • 設定別名 IP 範圍時，客層代理程式會為別名 IP 範圍建立本機路由。
  • 建立參照通訊協定轉送的運算執行個體時，客體代理程式會為相關聯的轉送規則 IP 位址建立本機路徑。目標執行個體
  • 將後端新增至直通式網路負載平衡器時，客體代理程式會為相關聯的轉送規則 IP 位址建立本機路徑。

由於系統不會為 Dynamic NIC 新增本機路由，Dynamic NIC 可能會捨棄封包。

如要解決這個問題，請按照下列步驟手動新增 IP 位址：

  1. 使用 SSH 連線至執行個體。

  2. 如要設定別名 IP 範圍，請按照下列步驟操作。 您也可以略過這個步驟。

    1. 在 /etc/default/instance_configs.cfg 中，確認 ip_aliases 設定已設為 true。

    2. 如果 ip_aliases 設定設為 false，請修改檔案將其變更為 true，然後重新啟動訪客代理程式：

      systemctl restart google-guest-agent

  3. 使用下列指令，為別名 IP 範圍或轉送規則 IP 位址設定本機路由：

    ip route add to local IP_ADDRESS dev DYNAMIC_NIC_DEVICE_NAME proto 66

    更改下列內容：

    • IP_ADDRESS：您要新增本機路徑的別名 IP 範圍或轉送規則 IP 位址。
    • DYNAMIC_NIC_DEVICE_NAME：要新增本機路由的 Dynamic NIC 裝置名稱。例如：a-gcp.ens4.3。

訪客代理程式版本 20250901.00 至 20251120.01 的動態 NIC 安裝和管理問題

如果您設定自動管理動態 NIC，且執行個體執行的客體代理程式版本介於 20250901.00 到 20251120.01 之間，可能會遇到下列問題：

  • 訪客代理程式無法在執行個體的訪客作業系統中安裝及管理動態 NIC。

    在參照動態 NIC 的訪客 OS 中執行指令時，您可能會收到包含 Cannot find device 的錯誤訊息。

  • 刪除多個動態 NIC 會導致無法存取中繼資料伺服器。

根本原因

自 20250901.00 版起，客體代理程式已遷移至新的外掛程式架構，以提升模組化程度。新架構最初不支援自動安裝及管理動態 NIC。

解析度

如要解決這些問題，請更新執行個體，使用訪客代理程式 20251205.00 以上版本：

  1. 如要將訪客代理程式更新至最新版本，請參閱「更新訪客環境」一文。
  2. 如要確認執行個體執行的客體代理程式版本，請參閱「依作業系統版本查看已安裝的套件」。

如有必要，您可以暫時解決執行客體代理程式版本 20250901.00 至 20251120.01 的執行個體問題，方法是按照「向後相容性」一文中的操作說明，還原至先前的客體代理程式架構。

後續步驟