Muster für die Verwendung mehrerer Host-NICs

In diesem Dokument werden Konfigurationsmuster und Best Practices für die Verwendung der beiden Host-LAN-Netzwerkschnittstellen (NICs) für Speicher und Verwaltung auf Compute Engine-Instanzen beschrieben.

Übersicht

Einige beschleunigungsoptimierte Maschinenserien, darunter A5X, A4X Max, A4X, A4 und A3 Ultra, haben zwei Host-LAN-Netzwerkschnittstellen für Speicher und Verwaltung, die mit regulären VPC-Netzwerken (Virtual Private Cloud) verbunden sind. Diese Maschinen haben auch MRDMA-Netzwerkschnittstellen, die an ein RoCE-VPC-Netzwerk (Remote Direct Memory Access over Converged Ethernet) angehängt werden müssen.

In diesem Dokument geht es um die Konfiguration der Host-LAN-Schnittstellen (gVNIC oder IDPF) in regulären VPC-Netzwerken, nicht um RDMA-Netzwerkschnittstellen. Die Host-LAN-Schnittstellen sind Titanium-Infrastrukturverarbeitungseinheiten (IPUs), die mit separaten CPU-Sockeln und NUMA-Knoten (Non-Uniform Memory Access) verbunden sind. In der Compute-Instanz werden diese IPUs als Google Virtual NICs (gVNICs) oder IDPF-Netzwerkschnittstellen (Infrastructure Data Path Function) angezeigt. Diese Schnittstellen bieten Netzwerkbandbreite für Speicher- und Verwaltungsaktivitäten wie Prüfpunkte, das Laden von Trainingsdaten und das Laden von Modellen. Die NUMA-Topologie der Maschine, einschließlich der Topologie der Netzwerkschnittstellen, ist für das Gastbetriebssystem sichtbar.

Verwenden Sie die folgenden Konfigurationen, unabhängig davon, welches Muster Sie für mehrere Host-NICs auswählen:

• Netzwerkeinstellungen: Konfigurieren Sie jede gVNIC- oder IDPF-Schnittstelle so, dass sie ein separates VPC-Netzwerk verwendet. Führen Sie für die VPC-Einrichtung die folgenden Konfigurationen aus:
  • Konfigurieren Sie für jedes VPC-Netzwerk eine große maximale Übertragungseinheit (MTU), z. B. 8896 (die maximal unterstützte MTU).
  • Wenn verworfene eingehende Datenpakete auf der Empfängerseite die Leistung des eingehenden Traffics für Ihre Arbeitslast verlangsamen, prüfen Sie mit dem Dienstprogramm ethtool, ob Pakete verworfen wurden. Wenn Sie die Datenzuweisung aus dem Seitencache optimieren möchten, sodass jeder eingehende Layer-2-Frame in zwei 4-KB-Zwischenspeicher passt, passen Sie die maximale TCP-Segmentgröße (MSS), die Schnittstellen-MTU oder die VPC-MTU an.
• Anwendungseinstellungen:
  • Richten Sie Ihre Anwendung NUMA-konform aus, indem Sie CPU-Kerne, Arbeitsspeicherzuweisungen und eine Netzwerkschnittstelle aus demselben NUMA-Knoten verwenden. Wenn Sie eine dedizierte Instanz der Anwendung für einen bestimmten NUMA-Knoten oder eine bestimmte Netzwerkschnittstelle ausführen, binden Sie die CPU- und Arbeitsspeicherressourcen der Anwendung mit einem Tool wie numactl an diesen NUMA-Knoten.
• Betriebssystemeinstellungen:
  • Aktivieren Sie TCP Segmentation Offload (TSO) und Large Receive Offload (LRO).
  • Konfigurieren Sie für jede gVNIC- oder IDPF-Schnittstelle die SMP-Affinität (Symmetric Multiprocessing), um Interrupt-Anfragen (IRQs) an denselben NUMA-Knoten wie die Schnittstelle weiterzuleiten und Interrupts auf CPU-Kerne zu verteilen. Wenn Sie ein von Google bereitgestelltes Linux-Image verwenden, führt der Compute Engine-Gast-Agent beim Booten das Skript google_set_multiqueue aus, um diese Konfiguration automatisch anzuwenden. Wenn Sie ein benutzerdefiniertes Image verwenden, installieren Sie die Gastumgebung. Wenn das Script nicht automatisch ausgeführt wird, führen Sie den Befehl sudo /usr/bin/google_set_multiqueue aus.
  • Prüfen Sie die Einstellungen für Receive Flow Steering (RFS), Receive Packet Steering (RPS) und Transmit Packet Steering (XPS), um festzustellen, ob sie für Ihre Arbeitslast von Vorteil sind.
  • Für A4X Max- und A4X-Instanzen empfiehlt NVIDIA, die automatische NUMA-Planung zu deaktivieren.
  • Verwenden Sie auf diesen Maschinen kein Linux-Kernel-Bonding mit den gVNIC- oder IDPF-Schnittstellen, da Kernel-Bonding nicht unterstützt wird.

Muster für die Verwendung mehrerer Host-NICs

In der folgenden Tabelle sind allgemeine Muster für die Verwendung mehrerer Host-NICs inGoogle Cloudaufgeführt:

Allgemeine Muster für die Verwendung mehrerer Host-NICs

Muster	Unterstütztes Prozesslayout	Bereitstellungspfad: Compute Engine	Bereitstellungspfad: Google Kubernetes Engine	Bereitstellungspfad: Slurm	Hinweise
Anwendung so ändern, dass sie eine bestimmte Schnittstelle verwendet	Prozess-Shard pro Schnittstelle	Ja	Ja	Ja	Erfordert Codeänderungen an der Anwendung.
Anwendung so ändern, dass beide Schnittstellen verwendet werden	Prozess mit zwei Schnittstellen	Ja	Ja	Ja	Erfordert Codeänderungen an der Anwendung.
Dedizierten Netzwerk-Namespace für bestimmte Anwendungen verwenden	Prozess-Shard pro Schnittstelle	Ja	Ja (nur privilegierte Container)	Nein	Keine
Traffic eines gesamten Containers einer einzelnen Schnittstelle zuordnen	Der gesamte Container-Traffic wird einer Schnittstelle zugeordnet	Ja	Ja	Nein	Keine
VPC-Peering verwenden und das System die Sitzungen über Schnittstellen hinweg verteilen lassen	Prozess mit zwei Schnittstellen	Ja	Ja	Ja	NUMA-Ausrichtung ist schwierig oder unmöglich. Erfordert Linux-Kernel 6.16 oder höher.
Traffic auf Netzwerke verteilen	Prozess mit zwei Schnittstellen Prozess-Shard pro Schnittstelle	Ja	Ja	Ja	Möglicherweise sind Codeänderungen für die NUMA-Ausrichtung erforderlich, wenn Sie einen Prozess mit zwei Schnittstellen ausführen.
Quellnetzwerkadressübersetzung (SNAT) verwenden, um die Quellschnittstelle auszuwählen	Prozess mit zwei Schnittstellen Prozess-Shard pro Schnittstelle	Ja	Ja (für die Einrichtung sind Administratorberechtigungen erforderlich)	Ja (für die Einrichtung sind Administratorberechtigungen erforderlich)	Die Konfiguration kann schwierig sein.

Hinweise

• Für die Muster VPC-Peering verwenden und das System die Sitzungen über Schnittstellen verteilen lassen und Traffic über Netzwerke verteilen: Diese Optionen werden im Allgemeinen nicht empfohlen, können aber für begrenzte Arbeitslasten auf x86-Plattformen (A4 und A3 Ultra) nützlich sein.

Anwendung so ändern, dass sie eine bestimmte Schnittstelle verwendet

Voraussetzungen:

• Erfordert Codeänderungen an Ihrer Anwendung.
• Erfordert Berechtigungen für eine oder mehrere der folgenden Methoden:
  • bind(): Erfordert nur dann spezielle Berechtigungen, wenn Sie einen privilegierten Quellport verwenden.
  • SO_BINDTODEVICE: Erfordert die Berechtigung CAP_NET_RAW.
• Möglicherweise müssen Sie die Kernel-Routingtabelle ändern, um Routen einzurichten und asymmetrisches Routing zu verhindern.

Gesamtübersicht

Hinweis: Einige Anwendungen und Bibliotheken unterstützen bereits Multi-NUMA- oder Multi-Socket-Topologien mit mehreren Netzwerkschnittstellen. Wenn Sie Software von Drittanbietern oder Open-Source-Software verwenden, lesen Sie die Dokumentation für diese Software.

Führen Sie die folgenden Schritte aus, um Ihre Anwendung für die Verwendung einer bestimmten Netzwerkschnittstelle zu konfigurieren:

1. Fügen Sie dem Quellcode Ihrer Anwendung eine Bindung für eine Netzwerkschnittstelle hinzu. Verwenden Sie dazu eine der folgenden Optionen:
   • Verwenden Sie den Systemaufruf bind(), um einen Socket an eine bestimmte Quell-IP-Adresse zu binden.
   • Verwenden Sie die Socket-Option SO_BINDTODEVICE, um einen Socket an eine bestimmte Netzwerkschnittstelle zu binden.
2. Ändern Sie die Kernel-Routingtabelle nach Bedarf, um sicherzustellen, dass eine Route von der Quellnetzwerkschnittstelle zur Zieladresse vorhanden ist. Um asymmetrisches Routing zu verhindern, konfigurieren Sie das Richtlinienrouting wie unter Routing für eine zusätzliche Netzwerkschnittstelle konfigurieren beschrieben.
3. Optional: Führen Sie Ihre Anwendung auf dem Arbeitsspeicher und den CPUs aus, die denselben NUMA-Knoten wie die ausgewählte Netzwerkschnittstelle verwenden. Verwenden Sie dazu den Befehl numactl.

Nachdem Sie diese Schritte ausgeführt haben, verwendet Ihre Anwendung die angegebene Netzwerkschnittstelle.

Anwendung so ändern, dass beide Schnittstellen verwendet werden

Voraussetzungen:

• Erfordert Codeänderungen an Ihrer Anwendung.
• Erfordert Berechtigungen für eine oder mehrere der folgenden Methoden:
  • bind(): Erfordert nur dann spezielle Berechtigungen, wenn Sie einen privilegierten Quellport verwenden.
  • SO_BINDTODEVICE: Erfordert die Berechtigung CAP_NET_RAW.
• Möglicherweise müssen Sie die Kernel-Routingtabelle ändern, um Routen einzurichten und asymmetrisches Routing zu verhindern.

Gesamtübersicht

Hinweis: Einige Anwendungen und Bibliotheken unterstützen bereits Multi-NUMA- oder Multi-Socket-Topologien mit mehreren Netzwerkschnittstellen. Wenn Sie Software von Drittanbietern oder Open-Source-Software verwenden, lesen Sie die Dokumentation für diese Software.

Führen Sie die folgenden Schritte aus, um Ihre Anwendung so zu konfigurieren, dass beide Netzwerkschnittstellen verwendet werden:

1. Fügen Sie dem Quellcode Ihrer Anwendung für jede Netzwerkschnittstelle eine Bindung hinzu. Verwenden Sie dazu eine der folgenden Optionen:
   • Verwenden Sie den Systemaufruf bind(), um jeden Socket an die Quell-IP-Adresse der entsprechenden Netzwerkschnittstelle zu binden.
   • Verwenden Sie die Socket-Option SO_BINDTODEVICE, um jeden Socket an eine bestimmte Netzwerkschnittstelle zu binden.
2. Wenn Ihre Anwendung als Client fungiert, erstellen Sie für jede Quellnetzwerkschnittstelle einen separaten Client-Socket.
3. Ändern Sie die Kernel-Routingtabelle nach Bedarf, um sicherzustellen, dass eine Route von jeder Quellnetzwerkschnittstelle zur Zieladresse vorhanden ist. Um asymmetrisches Routing zu verhindern, konfigurieren Sie das Richtlinienrouting wie unter Routing für eine zusätzliche Netzwerkschnittstelle konfigurieren beschrieben.
4. Partitionieren Sie die Netzwerkaktivität in Threads, die auf demselben NUMA-Knoten wie die entsprechende gVNIC- oder IDPF-Schnittstelle ausgeführt werden, z. B. durch Aufrufen von pthread_setaffinity_np. Da die Anwendung Ressourcen über mehrere NUMA-Knoten hinweg verwendet, sollten Sie numactl vermeiden oder dafür sorgen, dass der Befehl numactl die NUMA-Knoten aller Netzwerkschnittstellen enthält, die Ihre Anwendung verwendet.

Dedizierten Netzwerk-Namespace für bestimmte Anwendungen verwenden

Voraussetzungen:

• Erfordert die Funktion CAP_SYS_ADMIN.
• Nicht mit GKE Autopilot kompatibel.
• Wenn Sie GKE verwenden, müssen Sie einen privilegierten Container verwenden.

In diesem Abschnitt werden Muster beschrieben, mit denen Sie einen Netzwerk-Namespace für eine sekundäre Netzwerkschnittstelle erstellen können. Das beste Muster für Ihre Arbeitslast hängt von Ihrem Szenario ab. Ansätze, die einen virtuellen Switch oder IPvlan verwenden, funktionieren am besten, wenn mehrere Anwendungen die sekundäre Schnittstelle aus verschiedenen Netzwerk-Namespaces gemeinsam nutzen müssen.

Sekundäre Schnittstelle in einen dedizierten Netzwerk-Namespace verschieben

Bei diesem Muster erstellen Sie einen Netzwerk-Namespace, verschieben die sekundäre gVNIC- oder IDPF-Schnittstelle in den neuen Namespace und führen die Anwendung dann aus diesem Namespace aus. Dieses Muster ist im Vergleich zu einem virtuellen Switch einfacher einzurichten und zu optimieren, aber Anwendungen außerhalb des neuen Netzwerk-Namespace können nicht auf die sekundäre Netzwerkschnittstelle zugreifen.

Führen Sie die folgenden Befehle aus, um die Schnittstelle eth1 in einen Netzwerk-Namespace namens app-net zu verschieben und einen Befehl in diesem Namespace auszuführen:

ip netns add app-net
ip link set eth1 netns app-net
ip netns exec app-net ip addr add ETH1_IP/PREFIX dev eth1
ip netns exec app-net ip link set dev eth1 up
ip netns exec app-net ip route add default via GATEWAY_IP dev eth1
ip netns exec app-net COMMAND

Ersetzen Sie Folgendes:

• ETH1_IP: die interne IP-Adresse der eth1-Schnittstelle.
• PREFIX: die Subnetzpräfixlänge für die Schnittstelle eth1.
• GATEWAY_IP: die Standard-Gateway-IP-Adresse für das Subnetz eth1.
• COMMAND: der Befehl, der im Netzwerk-Namespace app-net ausgeführt werden soll.

Wenn Sie diese Befehle ausführen, wird COMMAND im Netzwerk-Namespace app-net ausgeführt und die Schnittstelle eth1 verwendet.

Anwendungen, die im neuen Netzwerk-Namespace ausgeführt werden, verwenden die sekundäre gVNIC- oder IDPF-Schnittstelle. Sie können auch den Befehl numactl verwenden, um Ihre Anwendung mit dem Arbeitsspeicher und den CPUs auf demselben NUMA-Knoten wie die ausgewählte Netzwerkschnittstelle auszuführen.

Virtuellen Switch und Netzwerk-Namespace für eine sekundäre Schnittstelle verwenden

Bei diesem Muster konfigurieren Sie einen virtuellen Switch, um über einen Netzwerk-Namespace auf die sekundäre gVNIC- oder IDPF-Schnittstelle zuzugreifen:

1. Öffnen Sie eine SSH-Verbindung zur Compute-Instanz. Weitere Informationen finden Sie unter Verbindung zu Linux-VMs herstellen.
2. Erstellen Sie mit dem Befehl ip link add ein virtuelles Ethernet-Gerätepaar (veth), z. B. ip link add veth0 type veth peer name veth1.

3. Passen Sie die MTU auf jedem Gerät mit dem Befehl ip link set an die MTU der sekundären Schnittstelle an:

   ip link set dev veth0 mtu MTU
   ip link set dev veth1 mtu MTU
   

   Ersetzen Sie MTU durch die MTU der sekundären Schnittstelle, z. B. 8896.

4. Aktivieren Sie die IPv4-Paketweiterleitung:

   sysctl -w net.ipv4.ip_forward=1
   

5. Verschieben Sie ein Ende des veth-Paars in einen neuen Netzwerk-Namespace und belassen Sie das andere Ende im Root-Namespace.

6. Ordnen Sie den Traffic vom veth-Gerät der sekundären Schnittstelle zu. Wenn Sie diese Zuordnung konfigurieren möchten, erstellen Sie einen Alias-IP-Bereich für die sekundäre Schnittstelle der Compute-Instanz und weisen Sie der untergeordneten Schnittstelle im Namespace eine IP-Adresse aus diesem Bereich zu.

7. Führen Sie die Anwendung im neuen Netzwerk-Namespace aus. Mit dem Befehl numactl können Sie Ihre Anwendung mit dem Arbeitsspeicher und den CPUs auf demselben NUMA-Knoten wie die ausgewählte Netzwerkschnittstelle ausführen.

Alternativ können Sie je nach Gastbetriebssystem und Arbeitslastkonfiguration eine IPvlan-Schnittstelle mit der sekundären gVNIC- oder IDPF-Schnittstelle verknüpfen, anstatt veth-Geräte zu erstellen.

Den gesamten Traffic eines Containers einer einzelnen Schnittstelle zuordnen

Voraussetzungen:

• Ihre Anwendung muss in einem Container ausgeführt werden, der einen Netzwerk-Namespace für das Container-Netzwerk verwendet, z. B. GKE, Docker oder Podman. Sie können das Hostnetzwerk nicht verwenden.

Containerlaufzeiten wie GKE, Docker und Podman verwenden für jeden Container einen dedizierten Netzwerk-Namespace, um den Traffic zu isolieren. Sie können diesen Netzwerk-Namespace entweder direkt oder mithilfe der Tools der Containerlaufzeit ändern, um Traffic einer anderen Netzwerkschnittstelle zuzuordnen.

Die GKE benötigt die primäre Schnittstelle für die interne Kubernetes-Kommunikation. Sie können jedoch die Standardroute im Pod so ändern, dass die sekundäre Schnittstelle verwendet wird, wie im folgenden GKE-Pod-Manifest gezeigt:

metadata:
  # ...
  annotations:
    networking.gke.io/default-interface: 'eth1'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth1","network":"secondary-network"}
      ]

Bei diesem Ansatz wird die NUMA-Ausrichtung zwischen der Standardnetzwerkschnittstelle und den zugewiesenen CPUs oder dem zugewiesenen Arbeitsspeicher nicht garantiert.

VPC-Peering verwenden und das System die Sitzungen über Schnittstellen hinweg verteilen lassen

Voraussetzungen:

• Sie müssen ein VPC-Netzwerk-Peering zwischen den VPC-Netzwerken der primären und sekundären Host-NICs einrichten.
• Sie müssen die Linux-Kernel-Version 6.16 oder höher verwenden, um TCP-Sitzungen über Quellschnittstellen hinweg zu verteilen, wenn Sie Traffic an eine einzelne Ziel-IP-Adresse und einen einzelnen Port senden.
• Ihre Arbeitslast muss sockelübergreifende Arbeitsspeicherübertragungen tolerieren, ohne dass die Leistungsziele verfehlt werden.

Gesamtübersicht

Wenn Sie Netzwerkverbindungen innerhalb einer Anwendung oder über Anwendungsinstanzen hinweg nicht einfach fragmentieren können und Ihre Arbeitslast auf A4- oder A3 Ultra-Compute-Instanzen ausgeführt wird, die nicht empfindlich auf NUMA- oder Socket-übergreifende Übertragungen reagieren, können Sie die beiden Schnittstellen als austauschbar behandeln.

Wenn Sie dieses Verhalten konfigurieren möchten, aktivieren Sie den sysctl-Parameter fib_multipath_hash_policy und fügen Sie eine Multipath-Route hinzu:

PRIMARY_GW=192.168.1.1  # Gateway of nic0
SECONDARY_GW=192.168.2.1  # Gateway of nic1
PRIMARY_IP=192.168.1.15  # Internal IP address for nic0
SECONDARY_IP=192.168.2.27  # Internal IP address for nic1

# Enable L4 5-tuple equal-cost multipath (ECMP) hashing
sysctl -w net.ipv4.fib_multipath_hash_policy=1
ip route add DESTINATION_NETWORK/SUBNET_MASK \
    nexthop via ${PRIMARY_GW} \
    nexthop via ${SECONDARY_GW}

Ersetzen Sie Folgendes:

• DESTINATION_NETWORK: der interne IP-Adressbereich des Ziels.
• SUBNET_MASK: die Subnetzpräfixlänge für das Zielnetzwerk.

Traffic auf Netzwerke aufteilen

Voraussetzungen:

• nic0 und nic1 auf der Compute-Instanz müssen mit separaten VPC-Netzwerken und Subnetzen verbunden sein und die Ziel-IP-Adressen müssen auf die beiden VPC-Netzwerke aufgeteilt werden.

Gesamtübersicht

Standardmäßig erstellt der Linux-Kernel Routen für das Subnetz nic0 und das Subnetz nic1, die Traffic nach Ziel-IP-Adresse über die entsprechende Netzwerkschnittstelle weiterleiten.

Angenommen, nic0 verwendet das VPC-Netzwerk net1 mit dem Subnetz subnet-a und nic1 verwendet das VPC-Netzwerk net2 mit dem Subnetz subnet-b. Standardmäßig wird für Traffic an Peer-IP-Adressen in subnet-a nic0 und für Traffic an Peer-IP-Adressen in subnet-b nic1 verwendet. Diese Konfiguration wird häufig verwendet, wenn eine Gruppe von Compute-Instanzen mit einer einzelnen NIC eine Verbindung zu net1 und eine zweite Gruppe eine Verbindung zu net2 herstellt.

Tipp: Wenn Sie zwei Instanzen Ihrer Anwendung ausführen (eine pro VPC-Netzwerk), können Sie mit dem Dienstprogramm numactl die Speicher- und Rechenressourcen jeder Anwendung NUMA-konform mit ihrer Netzwerkschnittstelle ausrichten, um socketübergreifende Übertragungen zu minimieren.

SNAT zum Auswählen der Quellschnittstelle verwenden

Warnung: Dieses Muster ist komplex und besteht aus mehreren voneinander abhängigen Teilen. Achten Sie darauf, diese Regeln im Kontext anderer Netzwerkkonfigurationen auf Ihrem Computer zu bewerten. Wenn Sie die Regeln falsch konfigurieren, kann es passieren, dass das System systemweiten Traffic falsch weiterleitet oder verwirft.

Voraussetzungen:

• Erfordert die Funktion CAP_NET_ADMIN, um die ersten iptables-Regeln einzurichten, aber nicht, um die Anwendung auszuführen.
• Erfordert eine sorgfältige Prüfung, wenn sie mit anderen nicht trivialen iptables-Regeln oder Routingkonfigurationen kombiniert wird.

Hinweis: Die NIC-Bindung gilt nur, wenn eine Verbindung erstellt wird. Wenn ein Thread zu einer CPU auf einem anderen NUMA-Knoten wechselt, fallen für die Verbindung NUMA-übergreifende Strafen an. Binden Sie Threads an bestimmte CPU-Sets, wenn Sie dieses Muster verwenden. Nur ausgehende Verbindungen, die von der Instanz stammen, werden an eine bestimmte NIC gebunden. Eingehende Verbindungen verwenden die NIC, die ihrer Ziel-IP-Adresse entspricht.

Gesamtübersicht

Wenn Sie keine Netzwerk-Namespaces verwenden oder Ihre Anwendung nicht ändern können, können Sie SNAT verwenden, um eine Quellschnittstelle auszuwählen. Mit einem Tool wie iptables können Sie die Quell-IP-Adresse eines Flows so umschreiben, dass sie mit der IP-Adresse einer bestimmten Schnittstelle übereinstimmt. Dies geschieht anhand eines Attributs der sendenden Anwendung, z. B. cgroup, Nutzer oder CPU.

Im folgenden Beispiel werden CPU-basierte Regeln verwendet, sodass jeder Datenfluss, der von einem Thread auf einer bestimmten CPU stammt, über die gVNIC- oder IDPF-Schnittstelle ausgeht, die an den NUMA-Knoten dieser CPU angehängt ist:

# --- Begin Configuration ---
OUTPUT_INTERFACE_0="enp0s19"        # CHANGEME: NIC0
OUTPUT_INTERFACE_1="enp192s20"      # CHANGEME: NIC1

CPUS_0=($(seq 0 55; seq 112 167))   # CHANGEME: CPU IDs for NIC0
GATEWAY_0="10.0.0.1"                # CHANGEME: Gateway for NIC0
SNAT_IP_0="10.0.0.2"                # CHANGEME: SNAT IP for NIC0
CONNMARK_0="0x1"
RT_TABLE_0="100"

CPUS_1=($(seq 56 111; seq 168 223)) # CHANGEME: CPU IDs for NIC1
GATEWAY_1="10.0.1.1"                # CHANGEME: Gateway for NIC1
SNAT_IP_1="10.0.1.2"                # CHANGEME: SNAT IP for NIC1
CONNMARK_1="0x2"
RT_TABLE_1="101"
# --- End Configuration ---

# Specify which interface to use for packets in each routing table.
ip route add default via "$GATEWAY_0" dev "$OUTPUT_INTERFACE_0" table "$RT_TABLE_0"
ip route add default via "$GATEWAY_1" dev "$OUTPUT_INTERFACE_1" table "$RT_TABLE_1"

# Route replies to connections from peers through the matching egress interface.
# Add these rules before the fwmark rules so that fwmark takes precedence.
ip rule add from "$SNAT_IP_0" table "$RT_TABLE_0"
ip rule add from "$SNAT_IP_1" table "$RT_TABLE_1"

# Select the routing table based on the packet mark set in OUTPUT.
ip rule add fwmark "$CONNMARK_0" table "$RT_TABLE_0"
ip rule add fwmark "$CONNMARK_1" table "$RT_TABLE_1"

# Relax reverse path filtering so that the kernel doesn't drop legitimate
# replies to the SNAT IP addresses.
sysctl -w net.ipv4.conf."$OUTPUT_INTERFACE_0".rp_filter=2
sysctl -w net.ipv4.conf."$OUTPUT_INTERFACE_1".rp_filter=2

# Mark packets and connections with a per-NIC mark based on the source CPU.
# The fwmark rules then select the corresponding routing table for this traffic.
for cpu_id in "${CPUS_0[@]}"; do
    iptables -t mangle -A OUTPUT -m state --state NEW -m cpu --cpu "$cpu_id" -j CONNMARK --set-mark "$CONNMARK_0"
    iptables -t mangle -A OUTPUT -m state --state NEW -m cpu --cpu "$cpu_id" -j MARK --set-mark "$CONNMARK_0"
done
for cpu_id in "${CPUS_1[@]}"; do
    iptables -t mangle -A OUTPUT -m state --state NEW -m cpu --cpu "$cpu_id" -j CONNMARK --set-mark "$CONNMARK_1"
    iptables -t mangle -A OUTPUT -m state --state NEW -m cpu --cpu "$cpu_id" -j MARK --set-mark "$CONNMARK_1"
done

# Restore the connection mark for established connections so that packets use
# the same NIC regardless of other routing rules.
iptables -t mangle -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j CONNMARK --restore-mark

# Rewrite the source address after the packet is routed to the target interface
# so that replies return to the same NIC and pass VPC network validation.
iptables -t nat -A POSTROUTING -m mark --mark "$CONNMARK_0" -j SNAT --to-source "$SNAT_IP_0"
iptables -t nat -A POSTROUTING -m mark --mark "$CONNMARK_1" -j SNAT --to-source "$SNAT_IP_1"

Nächste Schritte

• Informationen zu Netzwerken und GPU-Maschinentypen
• Höhere Netzwerkbandbreite auf GPU-Instanzen verwenden
• Mehrere Netzwerkschnittstellen konfigurieren