ネットワーク帯域幅

Google Cloud では、仮想ネットワーク インターフェース（vNIC）や IP アドレスではなく、仮想マシン（VM）インスタンスごとの帯域幅が考慮されます。VM のマシンタイプにより、許容される最大下り（外向き）レートが定義されていますが、最大下り（外向き）レートに達するのは特定の状況に限られます。

このページでは、デプロイ計画に役立つ想定値について説明します。帯域幅は、次の 2 つの基準で分類されます。

  • 下り（外向き）または上り（内向き）: このページで使われているように、下り（外向き）と上り（内向き）とは常に Google Cloud VM からの観点です。
    • Google Cloud VM から送信されるパケットは下り（外向き）トラフィックになります。
    • Google Cloud VM に送信されたパケットは上り（内向き）トラフィックになります。
  • パケットのルーティング方法: パケットは、ネクストホップが VPC ネットワーク内にあるルートまたは VPC ネットワーク外のルートを使用し、送信側の VM からルーティングするか、または受信側の VM へとルーティングできます。

仮想ネットワーク インターフェース（vNIC）や vNIC ごとの IP アドレスを追加しても、VM の上り（内向き）または下り（外向き）の帯域幅は増加しません。たとえば、22 個の vCPU を備えた C3 VM では、下り（外向き）帯域幅の合計が 23 Gbps に制限されます。2 つの vNIC を使用して C3 VM を構成した場合、VM の合計下り（外向き）帯域幅は vNIC あたり 23 Gbps ではなく、23 Gbps に制限されます。

このページの説明は、Compute Engine VM と、Compute Engine VM に依存するプロダクトを対象としています。たとえば、Google Kubernetes Engine ノードは Compute Engine VM です。

帯域幅の概要

次の表は、パケットが VM から送信されたもの（下り）かあるいは VM が受信したもの（上り）か、およびパケット ルーティングの方法に基づいて、帯域幅の想定値を示したものです。

下り（外向き）

帯域幅の想定値
VPC ネットワーク内のルーティング

  • 主に送信側の VM のマシンタイプと Tier_1 ネットワーキングが有効かどうかに基づいて、VM あたりの最大下り（外向き）帯域幅によって定義されます。

    • Tier_1 ネットワーキングを備えた N2、N2D、C2、C2D VM では、下り（外向き）帯域幅は最大 100 Gbps がサポートされます。
    • H3 VM では、VM 間の下り（外向き）帯域幅は最大 200 Gbps がサポートされます。
    • A2 VM と G2 VM では、下り（外向き）帯域幅は最大 100 Gbps がサポートされます。
    • A3 VM では、下り（外向き）帯域幅は最大 1,000 Gbps がサポートされます。
    • C3、C3D、Z3（プレビュー）VM では、下り（外向き）帯域幅は Tier_1 ネットワーキングと併せて最大 200 Gbps がサポートされます。
  • その他の要因、定義、シナリオについては、VPC ネットワーク内でルーティング可能な宛先への下り（外向き）をご覧ください。
VPC ネットワーク外のルーティング

  • 主に送信側の VM のマシンタイプと Tier_1 ネットワーキングが有効かどうかに基づいて、VM あたりの最大下り（外向き）帯域幅によって定義されます。H3 VM を除き、VPC ネットワーク外の宛先への送信側の VM の下り（外向き）最大値は、以下を超えることはできません。

    • Tier_1 ネットワーキングが有効でない場合は合計 7 Gbps
    • Tier_1 ネットワーキングが有効な場合は合計 25 Gbps
    • フローごとに 3 Gbps
  • その他の要因、定義、注意点については、VPC ネットワーク外の宛先への下り（外向き）をご覧ください。

上り（内向き）

帯域幅の想定値
VPC ネットワーク内のルーティング
  • 通常、上り（内向き）レートはマシンタイプに対する下り（外向き）レートに似ています。
  • VM のサイズ、サーバー NIC の容量、同じホスト ハードウェアで実行されている他のゲスト VM へのトラフィック、ゲスト OS ネットワークの構成、VM で実行されているディスク読み取り数は、すべて上り（内向き）レートに影響する可能性があります。
  • Google Cloud では、VPC ネットワーク内の上り（内向き）レートにそのほかの制限はありません。
  • その他の要因、定義、シナリオについては、VPC ネットワーク内でルーティング可能な宛先への上り（内向き）をご覧ください。
VPC ネットワーク外のルーティング

  • Google Cloud では、VPC ネットワークの外部でルーティングされる上り（内向き）トラフィックを制限することで、VM を保護しています。トラフィック量は次のいずれかのレート（最初に到達したほう）で制限されます。

    • 1,800,000 pps（パケット/秒）
    • 30 Gbps
  • 複数の物理 NIC（A3 など）をサポートするマシンシリーズの場合、トラフィック量は次のいずれかのレート（最初に到達したほう）で制限されます。
    • 物理 NIC あたり 1,800,000 pps（パケット/秒）
    • 物理 NIC あたり 30 Gbps
  • 他の要因、定義、シナリオについては、VPC ネットワーク外の宛先への上り（内向き）トラフィックをご覧ください。

下り（外向き）帯域幅

Google Cloud は、パケットを送信する VM のマシンタイプと、パケットの宛先へのアクセスが VPC ネットワーク内のルートを使用して可能なのかまたは VPC ネットワーク外のルートを使用して可能なのかに基づいて、VM ごとの下り（外向き）レートを使用し、送信（外向き）帯域幅を制限します。送信帯域幅には、VM のすべての NIC から送信されたパケットと、VM に接続している永続ディスクに転送されるすべてのデータが含まれます。

VM あたりの最大下り（外向き）帯域幅

VM あたりの最大下り（外向き）帯域幅は、通常、vCPU あたり 2 Gbps ですが、マシンシリーズによっては違いと例外がいくつかあります。次の表は、VPC ネットワーク内でルーティングされるトラフィックの最大下り（外向き）帯域幅の上限を示したものです。これは標準ネットワーキング ティアのみに対するもので、VM ごとの Tier_1 ネットワーキングのパフォーマンスではありません。

マシンシリーズ Tier_1 ネットワーキングを使用しない場合の VM あたりの最大下り（外向き）の上限の最小値 Tier_1 ネットワーキングを使用しない場合の VM あたりの最大下り（外向き）上限の最大値
E2 1 Gbps 16 Gbps
C3 23 Gbps 100 Gbps
C3D 20 Gbps 100 Gbps
T2D 10 Gbps 32 Gbps
N2、C2、N2D、C2D 10 Gbps 32 Gbps
H3 該当なし 200 Gbps
Z3（プレビュー） 23 Gbps 100 Gbps
N1（vCPU が 1 個の VM を除く） 10 Gbps Intel Skylake CPU プラットフォームでは 32 Gbps
Intel Skylake より前の CPU プラットフォームでは 16 Gbps
1 個の vCPU、f1-micro、g1-small を備えた N1 マシンタイプ 2 Gbps 2 Gbps
A3、A2、G2 該当なし GPU のタイプに基づく

すべてのマシンタイプの VM ごとの最大下り（外向き）帯域幅の一覧は、次のそれぞれのマシン ファミリーのページで確認できます。

VM あたりの下り（外向き）帯域幅の最大値は必ずしも保証されません。実際の下り（外向き）帯域幅は、さまざまな要因によって減少する場合があります。次にその例の一部を挙げます。

  • ゲスト イーサネット ドライバ。gVNIC は VirtIO ネットワーク インターフェースよりも優れたパフォーマンスを提供します。
  • パケットサイズ
  • プロトコルのオーバーヘッド
  • フロー数
  • VM のゲスト OS でのイーサネット ドライバの設定。たとえば、チェックサム オフロード、TCP セグメンテーション オフロード（TSO）など。
  • ネットワークの輻輳
  • 永続ディスクが他の下り（外向き）ネットワーク トラフィックと競合する状況では、最大ネットワーク帯域幅の 60% が Persistent Disk の書き込みに割り当てられ、残りの 40% が他の下り（外向き）ネットワーク トラフィックに割り当てられます。詳細については、Persistent Disk に関するドキュメントのディスクのパフォーマンスに影響する要因をご覧ください。

VM ごとの下り（外向き）の最大帯域幅は、次の方法で可能な限り最大にすることができます。

  • より大きな汎用マシンタイプやコンピューティング最適化マシンタイプでは、VM ごとの Tier_1 ネットワーキング パフォーマンスを有効にすることが可能です。
  • ネットワーク トポロジでサポートされている最大の VPC ネットワーク最大伝送単位（MTU）を使用します。MTU を大きくすると、パケット ヘッダーのオーバーヘッドが削減され、ペイロード データのスループットが向上します。

VPC ネットワーク内でルーティング可能な宛先への下り（外向き）

送信側の VM から見て、VPC ネットワーク内のルートを使用してアクセス可能な宛先 IP アドレスについては、Google Cloud は次のルールを使用して送信トラフィックを制限します。

  • VM あたりの最大下り（外向き）帯域幅: VM あたりの最大下り（外向き）帯域幅セクションをご覧ください。
  • プロジェクトごとのリージョン間の下り（外向き）帯域幅: 送信側の VM と、内部宛先またはそのネクストホップが異なるリージョンにある場合、Google Cloud はリージョン間の下り（外向き）帯域幅の上限を適用します。ほとんどのお客様は、この上限に達することはありません。この上限についてご不明な点がある場合は、サポートケースを登録してください。
  • Cloud VPN と Cloud Interconnect の上限: VM から、ネクストホップの Cloud VPN トンネルまたは Cloud Interconnect VLAN アタッチメントによってルーティング可能な内部 IP アドレスを宛先にしてトラフィックを送信すると、下り（外向き）帯域幅は次の要素により制限されます。

VPC ネットワーク内でルーティング可能な宛先には、次のすべての宛先が含まれます。これらの宛先には、送信側の VM から見て、ネクストホップがデフォルトのインターネット ゲートウェイではないルートによってアクセスできます。

  • サブネット プライマリ IPv4 アドレス範囲とサブネット セカンダリ IPv4 アドレス範囲のリージョン内部 IPv4 アドレス。これらの宛先リソースで使用される、プライベート IPv4 アドレス範囲およびプライベートで使用されるパブリック IPv4 アドレス範囲がこれに含まれます。
    • 受信側の VM のネットワーク インターフェース（vNIC）のプライマリ内部 IPv4 アドレス。（送信側の VM が別の VM の vNIC 外部 IPv4 アドレスに接続すると、パケットはネクストホップのデフォルト インターネット ゲートウェイを使用してルーティングされるため、VPC ネットワーク外の宛先への下り（外向き）が適用されます）。
    • 受信側の VM の vNIC のエイリアス IP 範囲の内部 IPv4 アドレス。
    • プロトコル転送または内部パススルー ネットワーク ロードバランサの内部転送ルールの内部 IPv4 アドレス。
  • 次に示す宛先リソースのグローバル内部 IPv4 アドレス。
  • 次に示す宛先リソースで使用される内部 IPv6 サブネット アドレス範囲。
    • デュアルスタックの受信側の VM の vNIC に割り当てられた /96 IPv6 アドレス範囲の IPv6 アドレス。
    • プロトコル転送または内部パススルー ネットワーク ロードバランサの内部転送ルールの /96 IPv6 アドレス範囲の IPv6 アドレス。
  • 次に示す宛先リソースで使用される外部 IPv6 サブネット アドレス範囲。ただし、パケットがサブネット ルートを使用してルーティングされる場合、または、VPC ネットワーク内のピアリング サブネット ルートかデフォルトのインターネット ゲートウェイのネクストホップを使用しない VPC ネットワーク内のカスタムルートを使用してルーティングされる場合。
    • デュアルスタックの受信側の VM の vNIC に割り当てられた /96 IPv6 アドレス範囲の IPv6 アドレス。
    • プロトコル転送または外部パススルー ネットワーク ロードバランサの外部転送ルールの /96 IPv6 アドレス範囲の IPv6 アドレス。
  • 次の VPC ネットワーク ルートを使用してアクセスできるその他の宛先。

次のリストは、VM の内部宛先へのトラフィックの最大可能帯域幅が大きい順に並べたものです。

VPC ネットワーク外の宛先への下り（外向き）

送信側の VM から見て VPC ネットワーク外の宛先 IP アドレスについては、Google Cloud は最初に次のいずれかのレートに到達した送信トラフィックを制限します。

  • VM あたりの下り（外向き）帯域幅: VM から VPC ネットワーク外の宛先へのすべての接続の最大帯域幅は、VM あたりの最大下り（外向き）帯域幅と次のいずれかのうち小さい方になります。

    • 25 Gbps（Tier_1 ネットワーキングが有効な場合）
    • 7 Gbps（Tier_1 ネットワーキングが有効でない場合）
    • 1 Gbps（H3 VM の場合）
    • 物理 NIC あたり 7 Gbps（A3 などの複数の物理 NIC をサポートするマシンシリーズの場合）

    たとえば、n2-standard-16 インスタンスの VM ごとの下り（外向き）帯域幅の最大値は 32 Gbps ですが、n2-standard-16 インスタンスから外部宛先への接続の VM あたりの下り（外向き）帯域幅は、Tier_1 ネットワーキングが有効になっているかどうかに応じて、25 Gbps または 7 Gbps のいずれかになります。

  • フローあたりの下り（外向き）最大レート: VM から VPC ネットワーク外の宛先への一意の各 5 タプル接続の最大帯域幅は 3 Gbps です（ただし、H3 は 1 Gbps）。

  • プロジェクトあたりのインターネット下り（外向き）帯域幅: プロジェクトの各リージョンの VM から VPC ネットワーク外の宛先へのすべての接続の最大帯域幅は、プロジェクトのインターネット下り（外向き）帯域幅の割り当てに基づいて定義されます。

VPC ネットワークの外部にある宛先には、次のすべての宛先が含まれます。これらの宛先には、ネクストホップがデフォルトのインターネット ゲートウェイである送信側の VM の VPC ネットワークのルートによってアクセスできます。

  • 外部プロキシ ネットワーク ロードバランサと外部アプリケーション ロードバランサのグローバル外部 IPv4 アドレスと IPv6 アドレス
  • Google Cloud リソースのリージョン外部 IPv4 アドレス（VM vNIC 外部 IPv4 アドレス、外部プロトコル転送用の外部 IPv4 アドレス、外部パススルー ネットワーク ロードバランサ、Cloud NAT ゲートウェイへのレスポンス パケットなど）。
  • 外部 IPv6 アドレス範囲を持つデュアルスタック サブネット内にあるリージョン外部 IPv6 アドレスで、デュアルスタック VM の外部 IPv6 アドレス、外部プロトコル転送、外部パススルー ネットワーク ロードバランサで使用されるもの。ただし、サブネットがピアリングされていない個別の VPC ネットワークにあり、宛先 IPv6 アドレスが、ネクストホップがデフォルトのインターネット ゲートウェイである送信側の VM の VPC ネットワーク内のルートを使用してアクセスできる範囲にある場合に限ります。外部 IPv6 アドレス範囲を持つデュアル スタック サブネットが同じ VPC ネットワークまたはピアリングした VPC ネットワーク内にある場合は、VPC ネットワーク内でルーティング可能な宛先への下り（外向き）をご覧ください。
  • 送信側の VM の VPC ネットワークで静的ルートを使用してアクセス可能なその他の外部の宛先。ただし、ルートのネクストホップがデフォルトのインターネット ゲートウェイの場合。

どの Google Cloud リソースがどのタイプの外部 IP アドレスを使用するかの詳細については、外部 IP アドレスをご覧ください。

上り（内向き）帯域幅

Google Cloud は、受信パケットが受信側 VM にルーティングされる方法に応じて、上り（内向き）帯域幅を処理します。

VPC ネットワーク内でルーティング可能な宛先への上り（内向き）

受信側の VM が処理できるパケット数は、マシンタイプ、オペレーティング システム、その他のネットワーク条件で許容される数になります。Google Cloud では、受信パケットが VPC ネットワーク内のルートを使用して配信される場合、VM に配信される受信パケットに帯域幅の上限を設けていません。

  • 受信側の VM の VPC ネットワーク内のサブネット ルート
  • ピアリングされた VPC ネットワーク内のピアリング サブネット ルート
  • 別のネットワーク内のルートで、ネクストホップが Cloud VPN トンネル、Cloud Interconnect（VLAN）アタッチメント、または受信側 VM の VPC ネットワークにあるルーター アプライアンス VM であるもの

VPC ネットワーク内でルーティングされるパケットの宛先は次のとおりです。

  • 受信側の VM のネットワーク インターフェース（vNIC）のプライマリ内部 IPv4 アドレスプライマリ内部 IPv4 アドレスは、サブネットのプライマリ IPv4 アドレス範囲から取得されるリージョン内部 IPv4 アドレスです。
  • 受信側 VM の vNIC のエイリアス IP 範囲からの内部 IPv4 アドレス。エイリアス IP 範囲は、サブネットのプライマリ IPv4 アドレス範囲またはセカンダリ IPv4 アドレス範囲のいずれかから取得されます。
  • デュアルスタックの受信側の VM の vNIC に割り当てられた /96 IPv6 アドレス範囲の IPv6 アドレス。VM の IPv6 範囲は、次のサブネット IPv6 範囲から取得されます。
  • 受信側の VM への内部プロトコル転送に使用される転送ルール、または受信側の VM がロードバランサのバックエンドである内部パススルー ネットワーク ロードバランサへの内部プロトコル転送に使用される転送ルールの内部 IPv4 アドレス。内部転送ルールの IPv4 アドレスは、サブネットのプライマリ IPv4 アドレス範囲から取得されます。
  • /96 IPv6 範囲からの内部 IPv6 アドレスで、転送ルールが受信側の VM への内部プロトコル転送または受信側の VM がロードバランサのバックエンドである内部パススルー ネットワーク ロードバランサへの内部プロトコル転送で使用されるもの。内部転送ルールの IPv6 アドレスは、サブネットの内部 IPv6 アドレス範囲から取得されます。
  • このセクションの中ですでに一覧表示されている VPC ネットワーク ルートのいずれかを使用して、受信パケットが内部で受信側の VM にルーティングされる場合で、/96 IPv6 範囲からの外部 IPv6 アドレスで、転送ルールが受信側の VM への外部プロトコル転送または受信側の VM がロードバランサのバックエンドである外部パススルー ネットワーク ロードバランサへの外部プロトコル転送で使用されるもの。外部転送ルールの IPv6 アドレスは、サブネットの外部 IPv6 アドレス範囲から取得されます。
  • 受信側の VM をネクストホップ VM（next-hop-instance または next-hop-address）として使用するカスタム静的ルートの送信先範囲内の IP アドレス。
  • 受信側の VM が内部パススルー ネットワーク ロードバランサのバックエンドの場合、そのロードバランサ（next-hop-ilb）のネクストホップを使用する、カスタム静的ルートの送信先範囲内の IP アドレス。

VPC ネットワーク外の宛先への上り（内向き）

Google Cloud では、VPC ネットワークの外部のルートを使用して受信側の VM に配信される受信パケットに対して、次の帯域幅制限を適用します。ロード バランシングが含まれる場合、帯域幅の上限は受信側の各 VM に個別に適用されます。

複数の物理 NIC をサポートしていないマシンシリーズの場合、該当するインバウンド帯域幅の制限は、すべての仮想 NIC にまとめて適用されます。トラフィック量は次のいずれかのレート（最初に到達したほう）で制限されます。

  • 1 秒あたり 1,800,000 パケット
  • 30 Gbps

複数の物理 NIC（A3 など）をサポートするマシンシリーズの場合、該当するインバウンド帯域幅の制限が各物理 NIC に個別に適用されます。トラフィック量は次のいずれかのレート（最初に到達したほう）で制限されます。

  • 物理 NIC あたり 1,800,000 パケット/秒
  • 物理 NIC あたり 30 Gbps

VPC ネットワーク外のルートを使用してルーティングされるパケットの宛先は次のとおりです。

  • 受信側の VM のネットワーク インターフェース（NIC）のいずれかに対して 1 対 1 の NAT アクセス構成で割り当てられた外部 IPv4 アドレス。
  • デュアルスタックの受信側の VM の vNIC に割り当てられた /96 IPv6 アドレス範囲の外部 IPv6 アドレスで、受信パケットが、受信側の VM の VPC ネットワーク外のルートを使用してルーティングされた場合。
  • 外部 IPv4 アドレスで、転送ルールが受信側の VM への外部プロトコル転送に使用されるもの、または受信側の VM がロードバランサのバックエンドである外部パススルー ネットワーク ロードバランサへの外部プロトコル転送に使用されるもの。
  • /96 IPv6 範囲からの外部 IPv6 アドレスで、転送ルールが受信側の VM への外部プロトコル転送または受信側の VM がロードバランサのバックエンドである外部パススルー ネットワーク ロードバランサへの外部プロトコル転送で使用されるもの。ただし、受信パケットが、受信側の VM の VPC ネットワーク外のルートを使用してルーティングされた場合。
  • Cloud NAT によって処理される確立済みの受信レスポンス

ジャンボ フレーム

ジャンボ フレームを送受信するには、VM で使用される VPC ネットワークを構成します。最大伝送単位（MTU）をより大きい値（最大 8,896）に設定します。

MTU 値を大きくすると、パケットサイズが大きくなり、パケット ヘッダーのオーバーヘッドが減少するため、ペイロードのデータ スループットが向上します。

gVNIC ドライバでジャンボ フレームを使用するには、バージョン 1.3 以降のドライバを使用する必要があります。すべての Google Cloud の公開イメージに、このドライバのバージョンが含まれているわけではありません。ジャンボ フレームのオペレーティング システムのサポートの詳細については、オペレーティング システムの詳細ページのネットワーク機能タブをご覧ください。ジャンボ フレームの完全なサポートを示すイメージ バージョンには、ゲスト OS が gve ドライバのバージョンを 1.0.0 と示している場合でも、更新された gVNIC ドライバが含まれています。

ジャンボ フレームを完全にサポートしていない OS イメージを使用している場合は、gVNIC ドライバ バージョン v1.3.0 以降を手動でインストールできます。追加の機能とバグ修正を利用するには、Latest とマークされた gVNIC ドライバのバージョンをインストールすることをおすすめします。gVNIC ドライバは GitHub からダウンロードできます。

ゲスト OS で gVNIC ドライバのバージョンを手動で更新する方法については、サポートされていないオペレーティング システムでの使用をご覧ください。

受信キューと送信キュー

各 VM vNIC には、ネットワークからパケットを処理するいくつかの受信キューと送信キューが割り当てられます。

  • 受信キュー（RX）: パケットを受信するキュー。vNIC がネットワークからパケットを受信すると、キューから受信パケットの記述子を選択して処理し、割り込みにより、vCPU コアに接続されたパケットキューを介してゲスト OS にパケットを渡します。RX キューがいっぱいで、パケットの配置に利用できるバッファがない場合、パケットは破棄されます。これは通常、選択したパケットキューに接続されている vCPU コアをアプリケーションが過剰に使用している場合に発生することがあります。
  • 送信キュー（TX）: パケットを送信するためのキュー。ゲスト OS がパケットを送信すると、記述子が割り当てられて TX キューに配置されます。vNIC は記述子を処理し、パケットを送信します。

デフォルト キューの割り当て

明示的に NIC のキュー数を割り当てていない限り、vNIC ごとに固定数の RX キューと TX キューを割り当てる Google Cloud のアルゴリズムをモデル化できます。

  1. ネットワーク インターフェースのタイプに応じて、次のいずれかの方法を使用します。

    • VirtIO: vCPU の数を NIC の数で割り、余りの [number of vCPUs/number of NICs] を破棄します。
    • gVNIC: vCPU の数を NIC の数で割り、次に結果を 2 で割り、余りの [number of vCPUs/number of NICs/2] を破棄します。

    この計算結果は小数ではなく、必ず整数になります。

  2. 計算された数値が 1 未満の場合は、それぞれの vNIC に 1 個のキューが割り当てられます。

  3. 計算された数が各 vNIC の最大キュー数より大きいことを確認します。vNIC の最大キュー数はドライバの種類によって異なります。

    • virtIO またはカスタム ドライバを使用する場合、vNIC あたりの最大キュー数は 32 になります。計算された数値が 32 より大きい場合: 計算結果の数値は無視され、それぞれの vNIC に 32 個のキューが割り当てられます。
    • gVNIC を使用する場合、vNIC あたりのキューの最大数は 16 です。計算された数値が 16 より大きい場合: 計算結果の数値は無視され、それぞれの vNIC に 16 個のキューが割り当てられます。

次の例は、デフォルトのキュー数を計算する方法を示しています。

  • VM が VirtIO を使用していて、16 個の vCPU と 4 個の NIC を使用している場合、計算される数値は [16/4] = 4 です。Google Cloud は、各 vNIC に 4 つのキューを割り当てます。

  • gVNIC を使用し、vCPU が 128 個と NIC が 2 つある VM の場合、計算される数値は [128/2/2] = 32 です。Google Cloud では、vNIC あたりの最大数に到達するまで、vNIC ごとに最大数を割り当てます。Google Cloud では、vNIC ごとに 16 個のキューを割り当てます。

Linux システムでは、ethtool を使用して、Google Cloud によって vNIC ごとに割り当てられるキューの数より少ない vNIC を構成できます。

カスタムキューの割り当て

デフォルトのキュー割り当ての代わりに、Compute Engine API を使用して新しい VM を作成するときに、各 vNIC にカスタムキュー数（RX と TX の合計）を割り当てることができます。

指定するカスタムキューの数は、次のルールに従う必要があります。

  • vNIC ごとに割り当て可能な最小キュー数は 1 です。

  • 各 vNIC に割り当て可能な最大キュー数は、ドライバタイプに応じて、vCPU 数または vNIC ごとの最大キュー数のうち少ない方になります。

    • virtIO またはカスタム ドライバを使用する場合、最大キュー数は 32 です。
    • gVNIC を使用する場合、最大キュー数は 16 です。

  • カスタムキューの数を VM のすべての NIC に割り当てる場合、キューの数の割り当て合計は、VM インスタンスに割り当てられた vCPU の数以下であることが必要です。

NIC のカスタムキュー数をオーバーサブスクライブできます。つまり、VM のすべての NIC に割り当てられたキュー数の合計が、VM の vCPU 数を超えることが可能です。カスタムキュー数をオーバーサブスクライブするには、次の条件を満たす必要があります。

  • VM に構成されるすべての NIC の vNIC タイプとして、gVNIC を使用します。
  • VM では、N2、N2D、C2、C2D マシンシリーズのマシンタイプを使用します。
  • VM の Tier_1 ネットワーキングを有効にしました。
  • VM に構成されるすべての NIC にカスタムキュー数を指定しました。

キューのオーバーサブスクリプションにより、VM の最大キュー数は NIC 数の 16 倍になります。したがって、30 個の vCPU を持つ VM に 6 つの NIC が構成されている場合、VM には最大 96（16 * 6）個のカスタムキューを構成できます。

例

  • VM に 8 個の vCPU と 3 個の NIC がある場合、VM の最大キュー数は vCPU の数、8 になります。たとえば、nic0 に 1 つのキュー、nic1 に 4 つのキュー、nic2 に 3 つのキューを割り当てたとします。この場合、他の 2 つの vNIC キューの割り当てを維持しながら、その後で nic2 に 4 つのキューを割り当てることはできません。割り当てられたキューの合計が vCPU の数（8 つ）を超えることはできないためです。

  • VM に 96 個の vCPU と 2 つの NIC があるときに、virtIO ドライバを使用すると、それぞれの NIC に最大 32 個のキューを割り当てることができます。また、gVNIC ドライバを使用する場合は、それぞれに最大 16 個のキューが割り当てられます。この例では、割り当てられているキューの合計は常に vCPU の数より少なくなります。

また、一部の NIC にのみカスタムキュー数を割り当てて、Google Cloud が残りの NIC にキューを割り当てることもできます。vNIC ごとに割り当て可能なキューの数には、引き続き前述のルールが適用されます。構成の実現可能性をモデル化できます。構成が可能な場合は、このプロセスで Google Cloud が残りの NIC に割り当てるキューの数も設定できます。

  1. カスタムキューの割り当てを使用して、NIC のキューの合計を計算します。20 個の vCPU と 6 個の NIC を持つ VM を例にすると、nic0 に 5 つのキュー、nic1 に 6 つのキュー、nic2 に 4 つのキューを割り当て、Google Cloud で nic3、nic4、nic5 のキューを割り当てるとします。この例では、カスタム割り当てキューの合計は 5+6+4 = 15 になります。

  2. vCPU の数からカスタム割り当てキューの合計を引きます。Google Cloud が残りの NIC に割り当てるキューの数が、この差以下になっていない場合、Google Cloud はエラーを返します。20 個の vCPU と合計 15 のカスタム割り当てキューという VM の例では、Google Cloud が残りの NIC（nic3、nic4、nic5）に割り当てられるキューは、20-15 = 5 個ということになります。

  3. 前の手順との整合性を取るため、この差を前の手順で残った NIC の数で割り、余りの ⌊(number of vCPUs - sum of assigned queues)/(number of remaining NICs)⌋ を破棄します。この計算の結果は常に小数ではなく、整数になります。Google Cloud は、計算した数が vNIC ごとの最大キュー数を超えない限り、計算した数に一致する数を残りの NIC に割り当てます。vNIC の最大キュー数はドライバの種類によって異なります。

    • virtIO またはカスタム ドライバを使用して、残りの vNIC ごとに計算されたキューの数が 32 より大きい場合、Google Cloud は残りの vNIC のそれぞれに 32 キューを割り当てます。
    • gVNIC を使用して、残りの vNIC ごとに計算されたキューの数が 16 より大きい場合、Google Cloud は残りの vNIC のそれぞれに 16 キューを割り当てます。

カスタムキュー数を構成する

1 つ以上の vNIC にカスタムキュー数を使用する VM を作成するには、次の手順を行います。

gcloud

  1. 構成する vNIC インターフェースごとにサブネットを持つ VPC ネットワークがまだない場合は、作成します。
  2. gcloud compute instances create コマンドを使用して、VM を作成します。VM に構成する vNIC ごとに --network-interface フラグを繰り返し、queue-count オプションを含めます。
    gcloud compute instances create VM_NAME \
        --zone=ZONE \
        --machine-type=MACHINE_TYPE \
        --network-performance-configs=total-egress-bandwidth-tier=TIER_1  \
        --network-interface=network=NETWORK_NAME_1,subnet=SUBNET_1,nic-type=GVNIC,queue-count=QUEUE_SIZE_1 \
        --network-interface=network=NETWORK_NAME_2,subnet=SUBNET_2,nic-type=GVNIC,queue-count=QUEUE_SIZE_2

次のように置き換えます。

  • VM_NAME: 新しい VM の名前
  • ZONE: VM を作成するゾーン
  • MACHINE_TYPE: 新しい VM のマシンタイプ。指定するマシンタイプは、gVNIC と Tier_1 ネットワーキングをサポートしている必要があります。
  • NETWORK_NAME: 以前に作成したネットワークの名前
  • SUBNET_*: 以前に作成したサブネットのいずれかの名前
  • QUEUE_SIZE: カスタムキューの割り当てで説明されているルールに従う vNIC のキュー数

Terraform

  1. 構成する vNIC インターフェースごとにサブネットを持つ VPC ネットワークがまだない場合は、作成します。

  2. google_compute_instance リソースを使用して、vNIC の特定のキュー数を持つ VM を作成します。VM に構成する vNIC ごとに --network-interface パラメータを繰り返し、queue-count パラメータを含めます。

    # Queue oversubscription instance
resource "google_compute_instance" "VM_NAME" {
project      = "PROJECT_ID"
boot_disk {
  auto_delete = true
  device_name = "DEVICE_NAME"
  initialize_params {
     image="IMAGE_NAME"
     size = DISK_SIZE
     type = "DISK_TYPE"
  }
}
machine_type = "MACHINE_TYPE"
name         = "VM_NAME"
zone = "ZONE"

network_performance_config {
    total_egress_bandwidth_tier = "TIER_1"
}

network_interface {
    nic_type = "GVNIC"
    queue_count = QUEUE_COUNT_1
    subnetwork_project = "PROJECT_ID"
    subnetwork = "SUBNET_1"
 }

network_interface {
    nic_type = "GVNIC"
    queue_count = QUEUE_COUNT_2
    subnetwork_project = "PROJECT_ID"
    subnetwork = "SUBNET_2"
}

network_interface {
    nic_type = "GVNIC"
    queue_count = QUEUE_COUNT_3
    subnetwork_project = "PROJECT_ID"
    subnetwork = "SUBNET_3""
}

network_interface {
    nic_type = "GVNIC"
    queue_count = QUEUE_COUNT_4
    subnetwork_project = "PROJECT_ID"
    subnetwork = "SUBNET_4""
}

}

次のように置き換えます。

  • VM_NAME: 新しい VM の名前
  • PROJECT_ID: VM を作成するプロジェクトの ID。共有 VPC ネットワークを使用している場合を除き、すべてのサブネットとネットワークが作成されたプロジェクトと同じプロジェクトを指定する必要があります。
  • DEVICE_NAME: ゲスト OS のブートディスクに関連付ける名前
  • IMAGE_NAME: イメージの名前（例: "projects/debian-cloud/global/images/debian-11-bullseye-v20231010"）
  • DISK_SIZE: ブートディスクのサイズ（GiB）
  • DISK_TYPE: ブートディスクに使用するディスクのタイプ（例: pd-standard）
  • MACHINE_TYPE: 新しい VM のマシンタイプ。指定するマシンタイプは、gVNIC と Tier_1 ネットワーキングをサポートしている必要があります。
  • ZONE: VM を作成するゾーン
  • QUEUE_COUNT: カスタムキューの割り当てで説明されているルールに従う vNIC のキュー数
  • SUBNET_*: ネットワーク インターフェースが接続するサブネットの名前

REST

  1. 構成する vNIC インターフェースごとにサブネットを持つ VPC ネットワークがまだない場合は、作成します。

  2. instances.insert メソッドを使用して、NIC の特定のキュー数を持つ VM を作成します。複数のネットワーク インターフェースを構成するには、networkInterfaces プロパティを繰り返します。

    POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances
{
"name": "VM_NAME",
"machineType": "machineTypes/MACHINE_TYPE",
"networkPerformanceConfig": {
    "totalEgressBandwidthTier": TIER_1
},
"networkInterfaces": [
    {
      "nicType": gVNIC,
      "subnetwork":"regions/region/subnetworks/SUBNET_1",
      "queueCount": "QUEUE_COUNT_1"
    } ],
"networkInterfaces": [
    {
      "nicType": gVNIC,
      "subnetwork":"regions/region/subnetworks/SUBNET_2",
      "queueCount": "QUEUE_COUNT_2"
    } ],
}

    次のように置き換えます。

    • PROJECT_ID: VM を作成するプロジェクトの ID。
    • ZONE: VM を作成するゾーン。
    • VM_NAME: 新しい VM の名前
    • MACHINE_TYPE: 新しい VM のマシンタイプ（事前定義またはカスタム）
    • SUBNET_*: ネットワーク インターフェースが接続するサブネットの名前
    • QUEUE_COUNT: カスタムキューの割り当てで説明されているルールに従う vNIC のキュー数

キューの割り当てとマシンタイプの変更

VM はデフォルトのキュー割り当てで作成されます。または、Compute Engine API を使用して新しい VM を作成するときに、各仮想ネットワーク インターフェース カード（vNIC）にカスタムキュー数を割り当てることができます。デフォルトまたはカスタム vNIC キューの割り当ては、VM を作成する場合にのみ設定されます。デフォルトのキュー数を使用する vNIC が VM にある場合、そのマシンタイプを変更できます。変更先のマシンタイプの vCPU 数が異なる場合は、VM のデフォルトのキュー数が新しいマシンタイプに基づいて再計算されます。

VM にデフォルト以外のカスタムキュー数を使用する vNIC がある場合は、Google Cloud CLI または Compute Engine API を使用して、インスタンス プロパティを更新してマシンタイプを変更できます。結果として作成された VM が元の VM と同じ vNIC ごとのキュー数をサポートしている場合、変換は成功します。VirtIO-Net インターフェースを使用し、vNIC ごとに 16 を超えるカスタムキュー数を持つ VM の場合、マシンタイプを gVNIC のみを使用する第 3 世代のマシンタイプに変更することはできません。代わりに、既存の VM から新しい VM にワークロードを移動するの手順に沿って、VM を第 3 世代のマシンタイプに移行できます。

次のステップ