Hinweise zur Leistung

Auf dieser Seite finden Sie Anleitungen zum Konfigurieren Ihrer Google Cloud Managed Lustre-Umgebung, um die beste Leistung zu erzielen.

Leistungszahlen für die einzelnen Leistungsstufen finden Sie unter Leistungsstufen.

Leistung nach Erhöhung der Kapazität

Durch Erhöhen der Speicherkapazität einer vorhandenen Instanz werden der maximale Durchsatz und die IOPS sowie möglicherweise die Metadatenleistung erhöht.

Die Leistung des Lesedurchsatzes verbessert sich allmählich, wenn neue Daten geschrieben und auf den zusätzlichen Speicher verteilt werden. Die Leistung des Schreibdurchsatzes steigt sofort.

Hohe Kapazitätsauslastung

Wenn die Speicherkapazitätsauslastung einer Instanz 90 % erreicht, kann die Leistung der Instanz beeinträchtigt werden. Erhöhen Sie unter Umständen die Kapazität Ihrer Managed Lustre-Instanz. Möglicherweise müssen Sie vor der Erweiterung zusätzliches Kontingent anfordern.

Wenn No space left on device-Fehler angezeigt werden, Ihre Instanz aber noch freie Kapazität hat, lesen Sie den Abschnitt No space left on device-Fehler.

Maximale Übertragungseinheit (MTU) des VPC-Netzwerk

Wenn Sie beim Erstellen Ihres VPC-Netzwerk den Wert von mtu (maximale Übertragungseinheit oder Größe des größten IP-Pakets, das in diesem Netzwerk übertragen werden kann) auf den maximal zulässigen Wert von 8.896 festlegen, verbessert sich die Leistung um bis zu 10% im Vergleich zum Standardwert von 1.460 Byte.

Sie können den aktuellen MTU-Wert Ihres Netzwerks mit dem folgenden Befehl aufrufen:

gcloud compute networks describe NETWORK_NAME --format="value(mtu)"

Der MTU-Wert eines Netzwerks kann nach der Erstellung des Netzwerks aktualisiert werden. Dabei sind jedoch wichtige Aspekte zu berücksichtigen. Weitere Informationen finden Sie unter MTU eines Netzwerks ändern.

Compute Engine-Maschinentypen

Der Netzwerkdurchsatz kann durch die Wahl des Maschinentyps beeinflusst werden. Im Allgemeinen gilt für den besten Durchsatz:

  • Die Anzahl der vCPUs erhöhen Die maximale Bandbreite für ausgehenden Traffic beträgt in der Regel 2 Gbit/s pro vCPU, bis zum Maximum des Maschinentyps.
  • Wählen Sie eine Maschinenserie aus, die höhere Ein- und Ausgangslimits unterstützt. C2-Instanzen mit Tier_1-Netzwerk unterstützen beispielsweise eine Bandbreite für ausgehenden Traffic von bis zu 100 Gbit/s. C3-Instanzen mit Tier_1-Netzwerken unterstützen bis zu 200 Gbit/s.
  • Aktivieren Sie die Tier_1-Netzwerkleistung pro VM mit größeren Maschinentypen.
  • Verwenden Sie Google Virtual NIC (gVNIC). gVNIC ist die einzige Option für Maschinentypen der 3. Generation und höher. gVNIC ist erforderlich, wenn Sie Tier_1-Netzwerke verwenden.

Ausführliche Informationen finden Sie unter Netzwerkbandbreite.

Konfiguration für mehrere NICs

Durch die integrierte Multi-Rail-Funktion von Lustre können Clients den Netzwerkverkehr auf mehrere Netzwerkschnittstellenkarten (Multi-NIC) verteilen. Dadurch wird die Bandbreite aggregiert, um Managed Lustre-Instanzen mit hoher Kapazität zu sättigen.

So konfigurieren Sie mehrere NICs:

  • Wählen Sie einen Maschinentyp mit mehreren physischen NICs aus.
  • Erstellen Sie für jede NIC ein Subnetz und weisen Sie jede NIC ihrem Subnetz zu.
  • Folgen Sie der Anleitung für mehrere NICs, wenn Sie eine Verbindung von Compute Engine oder GKE aus herstellen.

Traffic-Ausgleich prüfen

Nachdem Sie mehrere NICs konfiguriert haben, sollten Sie prüfen, ob die Daten richtig verteilt werden.

Compute Engine

Prüfen Sie den Datenausgleich direkt auf der VM, indem Sie die konfigurierten Netzwerkschnittstellen (z. B. eth0 und eth1) mit nload überwachen, während Sie Traffic an das Managed Lustre-Backend senden:

nload -m eth0 eth1

Bei einer erfolgreichen Konfiguration mit mehreren NICs sollten die ausgehenden Bitraten für alle konfigurierten Schnittstellen ungefähr gleich sein.

GKE

Prüfen Sie, ob der Netzwerkverkehr Ihrer Arbeitslast auf mehrere NICs verteilt ist. Stellen Sie dazu einen temporären Netzwerk-Debugger-Pod auf dem Knoten bereit, auf dem Ihre Arbeitslast geplant ist:

  1. Ermitteln Sie den Knoten, auf dem Ihre Arbeitslast geplant ist:

    kubectl get pod POD_NAME -o wide

    Ersetzen Sie POD_NAME durch den Namen Ihres Clusters. Notieren Sie sich in der Befehlsausgabe den Namen in der Spalte NODE.

  2. Starten Sie den Netzwerk-Debugger auf diesem Knoten:

    kubectl run multi-nic-debug --rm -i --tty --image=nicolaka/netshoot \
  --overrides='{"spec": {"hostNetwork": true, "nodeSelector": {"kubernetes.io/hostname": "NODE_NAME"}, "tolerations": [{"key": "nvidia.com/gpu", "operator": "Exists", "effect": "NoSchedule"}]}}' \
  -- /bin/bash -c "apk update && apk add nload && nload -m eth0 eth1"

    Ersetzen Sie NODE_NAME durch den Knotennamen aus dem vorherigen Schritt.

  3. Analysieren Sie in der Ausgabe die Bitraten der Spalte Outgoing für eth0 und eth1. Wenn die Konfiguration erfolgreich ist, sind die Bitraten in etwa gleich. Die Ausgabe sieht etwa so aus:

    Device eth0 [10.1.0.50] (1/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.63 MBit/s                       Curr: 1.46 GBit/s
Avg: 1.60 MBit/s                        Avg: 1.44 GBit/s
Min: 1.40 MBit/s                        Min: 1.25 GBit/s
Max: 1.64 MBit/s                        Max: 1.47 GBit/s
Ttl: 590.94 GByte                       Ttl: 405.19 GByte

Device eth1 [172.16.15.5] (2/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.64 MBit/s                       Curr: 1.47 GBit/s
Avg: 1.62 MBit/s                        Avg: 1.44 GBit/s
Min: 1.42 MBit/s                        Min: 1.26 GBit/s
Max: 1.66 MBit/s                        Max: 1.47 GBit/s
Ttl: 587.68 GByte                       Ttl: 406.36 GByte

  4. Beenden Sie den Debugger durch Drücken von Strg+C.

Häufige Engpässe beheben

Wenn die Leistung Ihrer Arbeitslast deutlich niedriger ist als erwartet für Ihre Managed Lustre-Leistungsstufe, prüfen Sie, ob eines der folgenden häufigen Probleme vorliegt:

  • Unzureichende Anzahl von Clientcomputern:Ein einzelner Clientcomputer ist durch seine eigene virtuelle CPU (vCPU) und die Verarbeitungslimits für Single-Link-Netzwerke begrenzt. Um Tarife mit hohem Durchsatz zu sättigen, müssen Sie die Last verteilen. Um beispielsweise ein Managed Lustre-Dateisystem mit 100.000 MBps zu sättigen, benötigen Sie in der Regel mindestens 60 Standardclientcomputer (oder 12 Clientcomputer,die für die Verwendung von Tier 1-Netzwerken mit hoher Bandbreite konfiguriert sind), die parallel schreiben. Für die maximale Instanzgröße einer beliebigen Leistungsstufe benötigen Sie möglicherweise mehr als 2.500 Clientcomputer, die für die Verwendung von Tier 1-Netzwerken mit hoher Bandbreite konfiguriert sind.

  • Nicht ideale MTU für Virtual Private Cloud (VPC):VPC-Netzwerke verwenden standardmäßig eine MTU von 1460 (Standard-Ethernet-Frames). Für leistungsstarken Speicher wie Managed Lustre müssen Sie Jumbo-Frames mit einer MTU von 8896 konfigurieren. Bei Verwendung einer Standard-1460-MTU muss die CPU mehr als doppelt so viele Netzwerkpakete verarbeiten, was zu einem höheren CPU-Overhead und einer Begrenzung der maximalen Bandbreite führt.

  • Fehlende Konfiguration der Tier 1-Netzwerkbandbreite:Bei vielen leistungsstarken Maschinentypen müssen Sie die Tier 1-Netzwerkbandbreite explizit aktivieren.

    • Verwenden Sie in Compute Engine und GKE-Standardknotenpools das Flag --network-performance-configs=total-egress-bandwidth-tier=TIER_1 beim Erstellen. Ohne dieses Flag kann für eine VM oder einen Knoten ein niedrigeres Standardlimit für den ausgehenden Traffic gelten.
    • Bei GKE Autopilot geben Sie dieses Flag nicht direkt an. Wählen Sie stattdessen eine Maschinenreihe aus, die eine höhere Bandbreite unterstützt (z. B. c3), indem Sie Knotenselektoren in Ihren Pod-Spezifikationen verwenden.

    Weitere Informationen finden Sie unter Compute Engine-Maschinentypen.

  • Ungleichmäßige Nutzung von Lustre-Objektspeicherzielen (OSTs):Managed Lustre teilt Dateidaten auf mehrere Objektspeicherziele (OSTs) auf. Wenn Ihr Test oder Ihre Arbeitslast in eine einzelne, nicht gestripte Datei schreibt oder Clientaufgaben Muster schreiben, die einen einzelnen OST überlasten, wird dieser OST zu einem Engpass, während der Rest des Dateisystems im Leerlauf ist. Um dies zu vermeiden, sollten Sie die Schreibnutzlast gleichmäßig auf alle verfügbaren OSTs verteilen, z. B. durch Verwendung des Modus „Datei pro Prozess“ in Benchmarks.

  • Konflikte bei der freigegebenen Netzwerkbandbreite:Die Bandbreite für ausgehenden Traffic auf Clientcomputern (Compute Engine-VMs oder GKE-Knoten) wird für alle Netzwerkoperationen auf dem Computer freigegeben. Wenn auf Ihren Clientcomputern oder in Ihren Pods gleichzeitig große Pakete heruntergeladen werden, umfangreiche Logging-Vorgänge ausgeführt werden oder häufig mit anderen Clusterknoten kommuniziert wird, ist die Speicherleistung auf die verbleibende Netzwerkbandbreite beschränkt.