CSI-Treiber für Cloud Storage FUSE manuell für die Leistung optimieren

In dieser Anleitung erfahren Sie, wie Sie die Leistung des Cloud Storage FUSE-CSI-Treibers in Google Kubernetes Engine (GKE) optimieren. Eine vereinfachte, automatisierte Möglichkeit zur Optimierung der Cloud Storage FUSE-Leistung für KI/ML-Arbeitslasten finden Sie unter Leistungsoptimierung mit Cloud Storage FUSE-Profilen automatisieren. Die manuellen Schritte in diesem Dokument sind für fortgeschrittene Nutzer oder für benutzerdefinierte Anforderungen gedacht, die nicht von den Profilen abgedeckt werden.

Cloud Storage FUSE bietet zwar Flexibilität und Skalierbarkeit, aber eine sorgfältige Konfiguration und Optimierung sind entscheidend, um eine optimale Leistung zu erzielen. Die Leistung von Cloud Storage FUSE kann sich in Bezug auf Latenz, Durchsatz und Konsistenz von einem POSIX-Dateisystem unterscheiden. Ziel der Optimierung ist es, den Aufwand für Metadatenvorgänge zu minimieren und die Effizienz des Datenzugriffs zu maximieren. Wenn Sie KI-/ML-Anwendungen ausführen, die Daten in Cloud Storage-Buckets verwenden, kann die Optimierung des CSI-Treibers zu schnelleren Trainings- und Inferenzzeiten für Ihre KI-/ML-Anwendungen führen.

Dieser Leitfaden richtet sich an Entwickler und Machine-Learning-Ingenieure, die die Leistung ihrer Anwendungen verbessern möchten, die auf Daten zugreifen, die in Cloud Storage-Buckets gespeichert sind.

Bevor Sie diese Seite lesen, sollten Sie sich mit den Grundlagen von Cloud Storage, Kubernetes und dem CSI-Treiber für Cloud Storage FUSE vertraut machen. Prüfen Sie auch die GKE-Versionsanforderungen für bestimmte Funktionen, die Sie verwenden möchten.

Bereitstellungsoptionen konfigurieren

Der Cloud Storage FUSE CSI-Treiber unterstützt Bereitstellungsoptionen, um zu konfigurieren, wie Cloud Storage-Buckets in Ihrem lokalen Dateisystem bereitgestellt werden.

Je nach Art des verwendeten Volumes können Sie die Bereitstellungsoptionen auf folgende Weise angeben:

Sitzungsspezifisches CSI-Volume

Wenn Sie sitzungsspezifische CSI-Volumes verwenden, geben Sie die Bereitstellungsoptionen im Feld spec.volumes[n].csi.volumeAttributes.mountOptions Ihres Pod-Manifests an.

Sie müssen die Mount-Optionen als String angeben, wobei die Flags durch Kommas getrennt und ohne Leerzeichen angegeben werden müssen. Beispiel:

  mountOptions: "implicit-dirs,file-cache:enable-parallel-downloads:true,file-cache:download-chunk-size-mb:3"

Nichtflüchtiges Volume

Wenn Sie nichtflüchtige Volumes verwenden, geben Sie die Bereitstellungsoptionen im Feld spec.mountOptions in Ihrem PersistentVolume-Manifest an.

Sie müssen die Mount-Optionen als Liste angeben. Beispiel:

  mountOptions:
    - implicit-dirs
    - file-cache:enable-parallel-downloads:true
    - file-cache:download-chunk-size-mb:3

Überlegungen zur Montage

Beachten Sie beim Konfigurieren von Bereitstellungen mit dem CSI-Treiber die folgenden Hinweise:

Allgemeines

  • Die folgenden Flags sind nicht zulässig: app-name, temp-dir, foreground, log-file, log-format, key-file, token-url und reuse-token-from-url.
  • Cloud Storage FUSE macht die impliziten Verzeichnisse nicht standardmäßig sichtbar.
  • Wenn Sie nur ein Verzeichnis im Bucket und nicht den gesamten Bucket bereitstellen möchten, übergeben Sie das Verzeichnis mit dem relativen Pfad mit dem Flag only-dir=relative/path/to/the/bucket/root.

Sicherheit und Berechtigungen

  • Wenn Sie einen Sicherheitskontext für Ihren Pod oder Container verwenden oder wenn Ihr Container-Image einen Nicht-Root-Nutzer oder eine Gruppe verwendet, müssen Sie die Bereitstellungs-Flags uid und gid festlegen. Außerdem müssen Sie die Bereitstellungs-Flags file-mode und dir-mode verwenden, um die Dateisystemberechtigungen festzulegen. Beachten Sie, dass Sie die Befehle chmod, chown oder chgrp nicht für ein Cloud Storage FUSE-Dateisystem ausführen können. Verwenden Sie daher die Bereitstellungs-Flags uid, gid, file-mode und dir-mode, um Zugriff für einen Nutzer oder eine Gruppe von Root-Nutzern zu gewähren.

Bereitstellungsoptionen für den Linux-Kernel

  • Wenn Sie die Linux-Kernel-Bereitstellungsoptionen konfigurieren müssen, können Sie die Optionen über das Flag o übergeben. Wenn Sie beispielsweise keine direkte Ausführung von Binärdateien im bereitgestellten Dateisystem zulassen, legen Sie das Flag o=noexec fest. Für jede Option ist ein separates Flag erforderlich, z. B. o=noexec,o=noatime. Nur die folgenden Optionen sind zulässig: exec, noexec, atime, noatime, sync, async und dirsync.

Caching konfigurieren

In diesem Abschnitt finden Sie einen Überblick über die Caching-Optionen, die mit dem CSI-Treiber für Cloud Storage FUSE verfügbar sind, um die Leistung zu verbessern.

Datei-Caching

Sie können den Cloud Storage FUSE-CSI-Treiber mit Datei-Caching verwenden, um die Leseleistung von Anwendungen zu verbessern, die kleine Dateien aus Cloud Storage-Buckets verarbeiten. Das Datei-Cache-Feature von Cloud Storage FUSE ist ein clientbasierter Lese-Cache, mit dem Dateilesevorgänge wiederholt werden können, um sie schneller von einem Cache-Speicher Ihrer Wahl bereitzustellen.

Je nach Ihren Preis-Leistungs-Anforderungen können Sie aus einer Reihe von Speicheroptionen für den Lese-Cache auswählen, darunter lokale SSD, langlebiger Blockspeicher wie Google Cloud Hyperdisk oder Persistent Disk und RAM-Laufwerk (Arbeitsspeicher).

Datei-Caching aktivieren und verwenden

Standardmäßig ist das Datei-Caching in GKE deaktiviert. Sie müssen das Datei-Caching-Opt-in mit dem CSI-Treiber für Cloud Storage FUSE auswählen.

Um das Datei-Caching zu aktivieren und zu steuern, legen Sie das Volume-Attribut fileCacheCapacity fest oder verwenden Sie die Mount-Option file-cache:max-size-mb.

GKE verwendet standardmäßig ein emptyDir-Volume für das Dateicaching von Cloud Storage FUSE, das durch den auf dem Knoten konfigurierten sitzungsspezifischen Speicher unterstützt wird. Das kann das Bootlaufwerk sein, das an den Knoten angehängt ist, oder eine lokale SSD auf dem Knoten. Wenn Sie Lokale SSD auf dem Knoten aktivieren, verwendet GKE die lokale SSD zur Unterstützung des emptyDir-Volumes.

Sie können ein benutzerdefiniertes Lese-Cache-Volume für den Sidecar-Container konfigurieren, um das Standard-Volume emptyDir für das Datei-Caching bei Lesevorgängen zu ersetzen.

Weitere Informationen zu Best Practices für das Datei-Caching finden Sie unter Cloud Storage FUSE-Leistung.

Speicher zum Sichern des Dateicaches auswählen

Beachten Sie bei der Auswahl des Speichers für das Sichern Ihres Dateicaches Folgendes:

  • Für GPU- und CPU-VM-Familien, die lokale SSD unterstützen (z. B. A3-VMs), empfehlen wir die Verwendung lokaler SSDs.

    • Bei A3+-VMs richtet GKE automatisch lokale SSDs ein, die von Ihren Pods verwendet werden können.
    • Wenn Ihre VM-Familie keine lokalen SSDs unterstützt, verwendet GKE das Bootlaufwerk für das Caching. Der Standardlaufwerkstyp für das Bootlaufwerk in GKE ist pd-balanced.

    • Wenn Ihre VM-Familie lokale SSDs unterstützt, der sitzungsspezifische Speicher auf lokalen SSDs aber nicht standardmäßig aktiviert ist, können Sie lokale SSDs in Ihrem Knotenpool aktivieren. Dies gilt für Maschinenfamilien der ersten und zweiten Generation wie N1- und N2-Maschinen. Weitere Informationen finden Sie unter Cluster mit lokaler SSD erstellen.

      Führen Sie den folgenden Befehl aus, um zu prüfen, ob auf Ihrem Knoten sitzungsspezifischer Speicher auf lokaler SSD aktiviert ist:

      kubectl describe node <code><var>NODE_NAME</var></code> | grep "cloud.google.com/gke-ephemeral-storage-local-ssd"

  • Für TPU-VM-Familien, insbesondere v6+, empfehlen wir, RAM als Dateicache zu verwenden, um die beste Leistung zu erzielen, da diese VM-Instanzen über einen größeren RAM verfügen.

    • Achten Sie bei der Verwendung von RAM auf Fehler aufgrund von unzureichendem Arbeitsspeicher, da diese zu Pod-Unterbrechungen führen. Cloud Storage FUSE verbraucht Arbeitsspeicher. Wenn Sie also einen Dateicache einrichten, der den Sidecar-Container nutzt, kann dies zu OOM-Fehlern führen. Um solche Szenarien zu vermeiden, passen Sie das Feld file-cache:max-size-mb in der Konfiguration des Dateicaches auf einen kleineren Wert an.
    • Für andere TPU-Familien empfehlen wir die Verwendung von pd-balanced oder pd-ssd. Der Standardlaufwerkstyp für das Bootlaufwerk in GKE ist pd-balanced.

  • Vermeiden Sie die Verwendung des Bootlaufwerks für das Caching, da dies zu einer geringeren Leistung und unerwarteten Beendigungen führen kann. Verwenden Sie stattdessen ein PersistentVolume, das auf langlebigem Blockspeicher basiert.

RAM-Laufwerkbasiertes Datei-Caching verwenden

Sie können eine RAM-Disk für das Zwischenspeichern von Dateien oder für parallele Downloads verwenden, um den Overhead der Verwendung eines Bootlaufwerks zu reduzieren, wenn Sie eine TPU-VM mit ausreichend großem RAM verwenden.

Wenn Sie eine RAM-Festplatte mit dem Cloud Storage FUSE-CSI-Treiber verwenden möchten, fügen Sie Ihrem Manifest Folgendes hinzu:

volumes:
  - name: gke-gcsfuse-cache
    emptyDir:
      medium: Memory

Statistik-Cache

Der CSI-Treiber von Cloud Storage FUSE verbessert die Leistung durch das Caching von Dateimetadaten wie Größe und Änderungszeit. Der CSI-Treiber aktiviert diesen Stat-Cache standardmäßig und reduziert die Latenz, indem er Informationen lokal speichert, anstatt sie wiederholt von Cloud Storage anzufordern. Sie können die maximale Größe (Standard: 32 MB) und die Dauer, für die die Daten im Cache verbleiben (Standard: 60 Sekunden), konfigurieren. Durch die Feinabstimmung des Metadatencaches können Sie API-Aufrufe an Cloud Storage reduzieren und so die Anwendungsleistung und ‑effizienz verbessern, indem Sie Netzwerkverkehr und Latenz minimieren.

Weitere Informationen zu Best Practices für das Statistik-Caching finden Sie in der Übersicht zum Cloud Storage FUSE-Caching.

Metadaten-Prefetching verwenden, um den Metadaten-Cache vorab zu füllen

Mit der Funktion zum Vorabrufen von Metadaten kann der CSI-Treiber für Cloud Storage FUSE proaktiv relevante Metadaten zu den Objekten in Ihrem Cloud Storage-Bucket in Cloud Storage FUSE-Caches laden. Dieser Ansatz reduziert die Aufrufe von Cloud Storage und ist besonders vorteilhaft für Anwendungen, die auf große Datasets mit vielen Dateien zugreifen, z. B. KI-/ML-Trainingsarbeitslasten.

Für dieses Feature ist die GKE-Version 1.32.1-gke.1357001 oder höher erforderlich. Diese Funktion wird nicht für die dynamische Bereitstellung unterstützt, bei der Sie einen Unterstrich (_) angeben, um alle Buckets bereitzustellen, auf die das Kubernetes-Dienstkonto zugreifen kann. Wenn Sie dynamisches Einbinden verwenden, wird kein Metadaten-Prefetching durchgeführt.

Damit Sie von der Vorabruf-Funktion für Metadaten profitieren, müssen Sie den TTL-Wert (Time to Live, Gültigkeitsdauer) von Metadaten-Cache-Elementen auf „unbegrenzt“ festlegen. Normalerweise wird durch das Festlegen einer TTL verhindert, dass zwischengespeicherte Inhalte veralten. Wenn Sie die TTL auf „unbegrenzt“ festlegen, müssen Sie darauf achten, dass der Inhalt des Buckets nicht außerhalb des Bandes geändert wird. Das bedeutet, dass keine andere Arbeitslast oder kein anderer Akteur die Arbeitslast ändern darf. Out-of-Band-Änderungen sind lokal nicht sichtbar und können zu Inkonsistenzen führen.

Wenn Sie den Metadaten-Prefetch aktivieren möchten, nehmen Sie die folgenden Änderungen an der Konfiguration vor. Wir empfehlen, diese Funktion für Volumes zu aktivieren, die häufig gelesen werden.

  • Stelle das Attribut „volume“ (Lautstärke) gcsfuseMetadataPrefetchOnMount: true ein.
  • Aktualisieren Sie die folgenden Mount-Optionen:
  • Um Unterbrechungen der Arbeitslast zu vermeiden, sollten Sie das Arbeitsspeicherlimit des gke-gcsfuse-metadata-prefetch-Sidecars erhöhen.
    • Erhöhen Sie die Limits, indem Sie die Pod-Annotation gke-gcsfuse/metadata-prefetch-memory-limit auf "512Mi" oder höher festlegen. Weitere Informationen finden Sie unter Ressourcen für Sidecar-Container konfigurieren.
    • Alternativ können Sie das Arbeitsspeicherlimit aufheben, indem Sie die Pod-Annotation gke-gcsfuse/metadata-prefetch-memory-limit auf "0" festlegen (wird nur für Standardcluster unterstützt).

Ein Beispiel finden Sie im Codebeispiel unter Leseleistung großer Dateien mit parallelen Downloads verbessern.

Cache auflisten

Um die Verzeichnisauflistung für Anwendungen zu beschleunigen, können Sie das Listen-Caching aktivieren. Bei dieser Funktion werden Verzeichnislisten im Arbeitsspeicher gespeichert, damit wiederholte Anfragen schneller beantwortet werden können. Der Listen-Cache ist standardmäßig deaktiviert. Sie können ihn aktivieren, indem Sie den Parameter kernel-list-cache-ttl-secs in Ihren Mount-Optionen festlegen. Damit wird festgelegt, wie lange Einträge im Cache gespeichert werden.

Sequenzielle Lesevorgänge großer Dateien durch Verwendung von gepuffertem Lesen verbessern

Gepufferte Lesevorgänge können die Leistung bei sequenziellen Lesevorgängen für große Dateien verbessern, indem Teile eines Cloud Storage-Objekts asynchron in einen Arbeitsspeicherpuffer vorgeholt werden. Durch das Puffern können nachfolgende Lesevorgänge aus dem Puffer bedient werden, ohne dass Netzwerkaufrufe erforderlich sind.

Beachten Sie Folgendes, bevor Sie gepufferte Lesevorgänge aktivieren:

  • Gepufferte Lesevorgänge sind nicht mit dem Dateicaching kompatibel. Wenn sowohl gepufferte Lesevorgänge als auch das Zwischenspeichern von Dateien aktiviert sind, hat das Zwischenspeichern von Dateien Vorrang und gepufferte Lesevorgänge werden ignoriert.

  • Gepufferte Lesevorgänge können erhebliche Speicher- und Rechenressourcen beanspruchen.

Wenn Sie gepufferte Lesevorgänge aktivieren möchten, konfigurieren Sie diese zusätzliche Einstellung in Ihrem Manifest mit Bereitstellungsoptionen: enable-buffered-read.

Wir empfehlen, die Mount-Optionen read-global-max-blocks zu verwenden, um die maximale Anzahl an Blöcken anzugeben, die für gepufferte Lesevorgänge für alle Datei-Handles verfügbar sind.

Leseleistung großer Dateien mit parallelen Downloads verbessern

Mit dem parallelen Download von Cloud Storage FUSE können Sie das Lesen großer Dateien aus Cloud Storage für Downloads mit mehreren Threads beschleunigen. Der parallele Download mit Cloud Storage FUSE kann sich besonders bei Anwendungsfällen mit Lesevorgängen von mehr als 1 GB auszahlen.

Für parallele Downloads muss der Dateicache aktiviert sein. Ab GKE-Version 1.32.0-gke.1795000 erzwingt Cloud Storage FUSE diese Anforderung strikt und gibt den folgenden Fehler aus, wenn Sie versuchen, parallele Downloads ohne den Datei-Cache zu verwenden, wodurch verhindert wird, dass Ihr Pod gestartet wird: MountVolume.SetUp failed for volume "gcs-fuse-csi-pv" : rpc error: code = Internal desc = gcsfuse failed with error: Error: error while parsing config: error parsing parallel download config: file cache should be enabled for parallel download support.

Beispiele:

  • Modellbereitstellung, bei der ein großer Prefetch-Zwischenspeicher erforderlich ist, um den Modelldownload beim Starten der Instanz zu beschleunigen.
  • Prüfpunktwiederherstellungen, bei denen Sie einen schreibgeschützten Datencache benötigen, um den einmaligen Zugriff auf mehrere große Dateien zu verbessern.
Best Practice:

Verwenden Sie parallele Downloads für Anwendungen, die große Dateien mit nur einem Thread lesen. Bei Anwendungen mit hoher Leseparallelität (mit mehr als acht Threads) kann es bei Verwendung dieser Funktion zu einer geringeren Leistung kommen.

So verwenden Sie den parallelen Download mit dem Cloud Storage FUSE CSI-Treiber:

  1. Erstellen Sie einen Cluster mit aktiviertem Datei-Caching, wie unter Datei-Caching aktivieren und verwenden beschrieben.

  2. Konfigurieren Sie in Ihrem Manifest diese zusätzlichen Einstellungen mit mount options, um den parallelen Download zu aktivieren:

    1. Legen Sie file-cache:enable-parallel-downloads:true fest.
    2. Passen Sie file-cache:parallel-downloads-per-file, file-cache:parallel-downloads-per-file, file-cache:max-parallel-downloads und file-cache:download-chunk-size-mb nach Bedarf an.

  3. Optional: Passen Sie bei Bedarf die folgenden Lautstärkeattribute an:

Kontingentverbrauch durch Zugriffssteuerungsprüfungen reduzieren

Standardmäßig führt der CSI-Treiber Zugriffssteuerungsprüfungen durch, um sicherzustellen, dass das Dienstkonto des Pods Zugriff auf Ihre Cloud Storage-Buckets hat. Dies führt zu zusätzlichem Overhead in Form von Kubernetes Service API-, Security Token Service- und IAM-Aufrufen. Ab der GKE-Version 1.29.9-gke.1251000 können Sie das Volume-Attribut skipCSIBucketAccessCheck verwenden, um solche redundanten Prüfungen zu überspringen und die Kontingentnutzung zu reduzieren.

Beispiel für die Inferenzbereitstellung

Das folgende Beispiel zeigt, wie Sie den parallelen Download für die Inferenzbereitstellung aktivieren:

  1. Erstellen Sie ein Manifest für PersistentVolume und PersistentVolumeClaim mit der folgenden Spezifikation:

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: serving-bucket-pv
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 64Gi
  persistentVolumeReclaimPolicy: Retain
  storageClassName: example-storage-class
  claimRef:
    namespace: NAMESPACE
    name: serving-bucket-pvc
  mountOptions:
    - implicit-dirs #avoid if list cache enabled and doing metadata prefetch
    - metadata-cache:ttl-secs:-1
    - metadata-cache:stat-cache-max-size-mb:-1
    - metadata-cache:type-cache-max-size-mb:-1
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-system:kernel-list-cache-ttl-secs:-1
    - file-cache:enable-parallel-downloads:true
    - read_ahead_kb=1024
  csi:
    driver: gcsfuse.csi.storage.gke.io
    volumeHandle: BUCKET_NAME
    volumeAttributes:
      skipCSIBucketAccessCheck: "true"
      gcsfuseMetadataPrefetchOnMount: "true"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: serving-bucket-pvc
  namespace: NAMESPACE
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 64Gi
  volumeName: serving-bucket-pv
  storageClassName: example-storage-class

    Ersetzen Sie die folgenden Werte:

    • NAMESPACE: der Kubernetes-Namespace, in dem Sie Ihren Pod bereitstellen möchten.
    • BUCKET_NAME: Der Name des Cloud Storage-Bucket, den Sie beim Konfigurieren des Zugriffs auf die Cloud Storage-Buckets angegeben haben. Sie können einen Unterstrich (_) angeben, um alle Buckets bereitzustellen, auf die das Kubernetes-Dienstkonto zugreifen kann. Weitere Informationen finden Sie unter Dynamische Bereitstellung in der Dokumentation zu Cloud Storage FUSE.

  2. Wenden Sie das Manifest auf den Cluster an:

    kubectl apply -f PV_FILE_PATH

    Ersetzen Sie PV_FILE_PATH durch den Pfad zu Ihrer YAML-Datei.

  3. Erstellen Sie ein Pod-Manifest mit der folgenden Spezifikation, um den PersistentVolumeClaim zu nutzen. Das hängt davon ab, ob Sie Dateicaching mit lokalen SSDs oder mit RAM-Laufwerken verwenden:

    Lokale SSD

    apiVersion: v1
kind: Pod
metadata:
  name: gcs-fuse-csi-example-pod
  namespace: NAMESPACE
  annotations:
    gke-gcsfuse/volumes: "true"
    gke-gcsfuse/cpu-limit: "0"
    gke-gcsfuse/memory-limit: "0"
    gke-gcsfuse/ephemeral-storage-limit: "0"
spec:
  containers:
    # Your workload container spec
    ...
    volumeMounts:
    - name: serving-bucket-vol
      mountPath: /serving-data
      readOnly: true
  serviceAccountName: KSA_NAME
  volumes:
  - name: serving-bucket-vol
    persistentVolumeClaim:
      claimName: serving-bucket-pvc

    RAM-Laufwerk

    apiVersion: v1
kind: Pod
metadata:
  name: gcs-fuse-csi-example-pod
  namespace: NAMESPACE
  annotations:
    gke-gcsfuse/volumes: "true"
    gke-gcsfuse/cpu-limit: "0"
    gke-gcsfuse/memory-limit: "0"
    gke-gcsfuse/ephemeral-storage-limit: "0"
spec:
  containers:
    # Your workload container spec
    ...
    volumeMounts:
    - name: serving-bucket-vol
      mountPath: /serving-data
      readOnly: true
  serviceAccountName: KSA_NAME 
  volumes:
    - name: gke-gcsfuse-cache # gcsfuse file cache backed by RAM Disk
      emptyDir:
        medium: Memory 
  - name: serving-bucket-vol
    persistentVolumeClaim:
      claimName: serving-bucket-pvc

  4. Wenden Sie das Manifest auf den Cluster an:

    kubectl apply -f POD_FILE_PATH

    Ersetzen Sie POD_FILE_PATH durch den Pfad zu Ihrer YAML-Datei.

DNS-Lookups mit NodeLocal DNSCache in GKE optimieren

In GKE-Versionen vor 1.34.1-gke.3899000 kann die häufige Herstellung neuer Verbindungen zu einer großen Anzahl von DNS-Lookups führen, wenn Sie Cloud Storage FUSE mit dem HTTP/1.1-Protokoll verwenden. Dieses Verhalten kann sich auf die Leistung auswirken, insbesondere in GKE-Umgebungen.

Um DNS-Lookups zu optimieren und die Latenz in früheren GKE-Versionen zu reduzieren, sollten Sie NodeLocal DNSCache bereitstellen.

  • Standard-Pods: Wenn Sie NodeLocal DNSCache bereitstellen, werden DNS-Lookups für die meisten Standard-Pods in Ihrem Cluster automatisch optimiert.

  • Hostnetzwerk-Pods: Für Pods, die die Einstellung hostNetwork: true verwenden, ist eine zusätzliche Konfigurationsänderung erforderlich, um den NodeLocal DNSCache zu verwenden. Sie müssen dnsPolicy in der Spezifikation des Pods explizit auf ClusterFirstWithHostNet überschreiben.

In den folgenden Szenarien ist in der Regel kein separater DNS-Cache erforderlich, da das Caching intern erfolgt:

  • Compute Engine-VMs: Der Betriebssystemkernel der VM speichert DNS-Lookups in der Regel effektiv im Cache, sodass keine zusätzliche Caching-Ebene erforderlich ist.

  • GKE 1.34.1-gke.3899000 und höher: Cloud Storage FUSE, das mit diesen Versionen ausgeliefert wird, bietet einen integrierten DNS-Cache, der das Problem mit der hohen Lookup-Frequenz intern behebt.

Volume-Attribute konfigurieren

Mit Volume-Attributen können Sie das spezifische Verhalten des CSI-Treibers für Cloud Storage FUSE konfigurieren.

Mit dem Cloud Storage FUSE CSI-Treiber können Sie die Cloud Storage FUSE-Konfigurationsdatei nicht direkt angeben. Sie können einige der Felder in der Konfigurationsdatei mit den Cloud Storage FUSE CSI-Volume-Attributen konfigurieren. Der CSI-Treiber übersetzt die Werte der Volume-Attribute in die Felder der Konfigurationsdatei.

Eine vollständige Liste der unterstützten Lautstärkeattribute finden Sie in der Referenz zu Lautstärkeattributen.

Sie können die Volume-Attribute auf folgende Weise angeben:

  • Im Feld spec.csi.volumeAttributes für ein PersistentVolume-Manifest, wenn Sie PersistentVolumes verwenden.
  • Im Feld spec.volumes[n].csi.volumeAttributes, wenn Sie sitzungsspezifische CSI-Volumes verwenden.

Im Manifest können die Lautstärkeattribute als Schlüssel/Wert-Paare angegeben werden. Beispiel:

volumeAttributes:
  mountOptions: "implicit-dirs"
  fileCacheCapacity: "-1"
  gcsfuseLoggingSeverity: warning

Cloud Storage FUSE-Messwerte

Die folgenden Cloud Storage FUSE-Messwerte sind jetzt über die GKE Monitoring API verfügbar. Details zu Cloud Storage FUSE-Messwerten wie Labels, Typ und Einheit finden Sie unter GKE-Systemmesswerte. Diese Messwerte sind für jeden Pod verfügbar, der Cloud Storage FUSE verwendet. Sie können sie verwenden, um Statistiken pro Volume und Bucket zu konfigurieren.

Messwerte sind ab der GKE-Version 1.33.0-gke.2248000 oder höher standardmäßig aktiviert. Wenn Sie sie deaktivieren möchten, setzen Sie das Volume-Attribut disableMetrics auf „true“.

Dateisystemmesswerte

Dateisystemmesswerte geben Aufschluss über die Leistung und den Zustand Ihres Dateisystems, einschließlich der Anzahl der Vorgänge, Fehler und der Geschwindigkeit von Vorgängen. Mithilfe dieser Messwerte können Sie Engpässe identifizieren und die Leistung optimieren.

  • gcsfusecsi/fs_ops_count
  • gcsfusecsi/fs_ops_error_count
  • gcsfusecsi/fs_ops_latency

Cloud Storage-Messwerte

Sie können Cloud Storage-Messwerte wie Datenvolumen, Geschwindigkeit und Anfrageaktivität im Blick behalten, um zu sehen, wie Ihre Anwendungen mit Cloud Storage-Buckets interagieren. Anhand dieser Daten können Sie Bereiche für die Optimierung identifizieren, z. B. Lesemuster verbessern oder die Anzahl der Anfragen reduzieren.

  • gcsfusecsi/gcs_download_bytes_count
  • gcsfusecsi/gcs_read_count
  • gcsfusecsi/gcs_read_bytes_count
  • gcsfusecsi/gcs_reader_count
  • gcsfusecsi/gcs_request_count
  • gcsfusecsi/gcs_request_latencies

Messwerte für den Dateicache

Sie können Messwerte für den Dateicache überwachen, z. B. das gelesene Datenvolumen, die Geschwindigkeit und die Cache-Trefferrate, um die Leistung von Cloud Storage FUSE und Anwendungen zu optimieren. Anhand dieser Messwerte können Sie Ihre Caching-Strategie optimieren und die Anzahl der Cache-Treffer maximieren.

  • gcsfusecsi/file_cache_read_bytes_count
  • gcsfusecsi/file_cache_read_latencies
  • gcsfusecsi/file_cache_read_count

Standardeinstellungen für die Leistung von Cloud Storage FUSE aktivieren

Ab Version 1.33.2-gke.4655000 aktiviert GKE automatisch eine Reihe von Leistungsstandardeinstellungen für Cloud Storage FUSE, das auf Knoten ausgeführt wird, die von leistungsstarken Maschinentypen unterstützt werden. Diese Leistungsstandardeinstellungen werden aufgrund eines bekannten Problems nicht in den Versionen 1.34.1-gke.1431000 bis 1.34.1-gke.3403001 unterstützt.

Bei der Volume-Bereitstellung ruft der Cloud Storage FUSE CSI-Treiber den Knoteninstanztyp des Ziels ab und übergibt ihn über eine neue Bereitstellungsoption machine-type an Cloud Storage FUSE.

Wenn ein leistungsstarker Maschinentyp übergeben wird, legt Cloud Storage FUSE automatisch die folgenden Standardbereitstellungsoptionen fest:

  • metadata-cache:negative-ttl-secs:0
  • metadata-cache:ttl-secs:-1
  • metadata-cache:stat-cache-max-size-mb:1024
  • metadata-cache:type-cache-max-size-mb:128
  • implicit-dirs:true
  • file-system:rename-dir-limit:200000
  • write:global-max-blocks:1600

Wenn eine dieser Mount-Optionen explizit angegeben wird, wird sie nicht durch die automatischen Standardeinstellungen überschrieben.

Sie können die Funktion deaktivieren, indem Sie disable-autoconfig in die Bereitstellungsoptionen einfügen. Beispiel:

mountOptions: "implicit-dirs,disable-autoconfig"

Best Practices für die Leistungsoptimierung

In diesem Abschnitt werden einige empfohlene Techniken zur Leistungsoptimierung und -abstimmung für den Cloud Storage FUSE-CSI-Treiber aufgeführt.

  • Buckets mit hierarchischem Namespace (HNS) nutzen:Wählen Sie HNS-Buckets aus, um die anfänglichen Abfragen pro Sekunde (Queries Per Second, QPS) um das Achtfache zu steigern. Diese Auswahl erleichtert auch schnelle und atomare Verzeichnisumbenennungen, eine wichtige Voraussetzung für effizientes Checkpointing mit Cloud Storage FUSE. HNS-Buckets bieten eine bessere Dateinutzung, da sie 40.000 Lesevorgänge und 8.000 Schreibvorgänge pro Sekunde unterstützen. Das ist eine deutliche Verbesserung gegenüber den 8.000 Lesevorgängen und 1.000 Schreibvorgängen pro Sekunde, die von Flat-Buckets unterstützt werden.

  • Nach Möglichkeit bestimmte Verzeichnisse bereitstellen:Wenn Ihre Arbeitslast den Zugriff auf ein bestimmtes Verzeichnis in einem Bucket umfasst, verwenden Sie beim Bereitstellen das Flag --only-dir. Dieser fokussierte Ansatz beschleunigt Listenaufrufe, da er den Umfang von LookUpInode-Aufrufen einschränkt, die einen list+stat-Aufruf für jede Datei oder jedes Verzeichnis im angegebenen Pfad umfassen. Wenn Sie den Mount auf das erforderliche Unterverzeichnis beschränken, minimieren Sie diese Aufrufe und erzielen so eine bessere Leistung.

  • Metadaten-Caching optimieren:Konfigurieren Sie Ihre Metadaten-Caches so, dass ihre Kapazität maximiert wird, und legen Sie eine unendliche Gültigkeitsdauer (TTL) fest. Dadurch werden alle aufgerufenen Metadaten für die Dauer Ihres Jobs im Cache gespeichert. So werden Metadatenzugriffsanfragen an Cloud Storage minimiert. Diese Konfiguration ist besonders für schreibgeschützte Volumes von Vorteil, da sie wiederholte Cloud Storage-Metadaten-Lookups überflüssig macht. Prüfen Sie jedoch, ob der mit diesen großen Metadatencaches verbundene Speicherverbrauch den Möglichkeiten Ihres Systems entspricht.

  • GKE-Sidecar-Ressourcen maximieren:Cloud Storage FUSE wird in einem Sidecar-Container in einer GKE-Umgebung ausgeführt. Entfernen Sie Einschränkungen für den CPU- und Arbeitsspeicherverbrauch des Sidecar-Containers, um Ressourcenengpässe zu vermeiden. So kann Cloud Storage FUSE die Ressourcennutzung basierend auf den Anforderungen der Arbeitslast skalieren und Drosselung verhindern, was zu einem optimalen Durchsatz beiträgt.

  • Metadaten-Cache proaktiv füllen:Aktivieren Sie das Vorabrufen von Metadaten für den CSI-Treiber. Dadurch werden die Metadaten- und Listencaches effizient gefüllt, wodurch Metadatenaufrufe an Cloud Storage minimiert und die erste Ausführung beschleunigt werden. Viele ML-Frameworks führen diesen Schritt automatisch aus. Bei benutzerdefiniertem Trainingscode ist es jedoch wichtig, dass Sie ihn selbst ausführen. Weitere Informationen finden Sie unter Metadaten-Prefetch verwenden, um den Metadaten-Cache vorab zu füllen.

  • Dateicache und parallele Downloads verwenden:Aktivieren Sie die Dateicache-Funktion, insbesondere für Trainingsarbeitslasten mit mehreren Epochen, bei denen Daten wiederholt gelesen werden. Im Datei-Cache werden Daten mit häufigen Zugriffen im lokalen Speicher (SSD bei A3-Maschinen) gespeichert, wodurch die Leseleistung verbessert wird. Ergänzen Sie dies mit der Funktion für parallele Downloads, insbesondere für Bereitstellungsarbeitslasten, um das Herunterladen großer Dateien zu beschleunigen, indem Sie sie in kleinere Blöcke aufteilen und gleichzeitig herunterladen.

  • Gepufferte Lesevorgänge aktivieren:Gepufferte Lesevorgänge können die Leistung sequenzieller Lesevorgänge für große Dateien verbessern, indem Teile eines Cloud Storage-Objekts asynchron in einen Arbeitsspeicherpuffer vorgeholt werden. Durch das Puffern können nachfolgende Lesevorgänge aus dem Puffer bedient werden, ohne dass Netzwerkaufrufe erforderlich sind. Weitere Informationen finden Sie unter Sequenzielle Lesevorgänge großer Dateien mit gepuffertem Lesen verbessern.

  • Checkpoints optimieren:Für Checkpointing mit Cloud Storage FUSE empfehlen wir dringend, einen HNS-Bucket zu verwenden. Wenn Sie einen Bucket verwenden, der nicht HNS-fähig ist, legen Sie den Parameter rename-dir-limit auf einen hohen Wert fest, um die Verzeichnisumbenennungen zu berücksichtigen, die von ML-Frameworks häufig während der Prüfpunkterstellung verwendet werden. Beachten Sie jedoch, dass das Umbenennen von Verzeichnissen in Nicht-HNS-Buckets möglicherweise nicht atomar ist und länger dauern kann.

  • Listen-Caching aktivieren:Aktivieren Sie das Listen-Caching mit dem Flag --kernel-list-cache-ttl-secs, um die Leistung weiter zu verbessern. Bei dieser Funktion werden Verzeichnis- und Dateilisten im Cache gespeichert, wodurch die Geschwindigkeit von ls-Vorgängen verbessert wird. Das Caching von Listen ist besonders nützlich für Arbeitslasten, die im Rahmen der Ausführung vollständige Verzeichniseinträge wiederholen, z. B. KI/ML-Trainingsläufe. Es empfiehlt sich, das Listen-Caching mit schreibgeschützten Bereitstellungen zu verwenden, um die Datenkonsistenz aufrechtzuerhalten.

  • Kernel-Read-Ahead erhöhen:Bei Arbeitslasten, die hauptsächlich sequenzielle Lesevorgänge großer Dateien umfassen, z. B. Bereitstellung und Prüfpunktwiederherstellung, kann eine Erhöhung der Read-Ahead-Größe die Leistung erheblich verbessern. Wenn Sie den Cloud Storage FUSE-Read-Ahead-Wert erhöhen möchten, geben Sie das Flag read_ahead_kb in mountOptions an und legen Sie es auf 1 MB fest (z.B. read_ahead_kb=1024). Für diese Funktion ist die GKE-Version 1.32.2-gke.1297001 oder höher erforderlich. Bei zonalen Buckets wird der Kernelparameter read_ahead_kb in GKE-Version 1.35.0-gke.3047001 oder höher automatisch von Cloud Storage FUSE verwaltet. Daher ist die Mount-Option read_ahead_kb nicht anwendbar und jeder dafür angegebene Wert wird ignoriert.

  • Streaming-Schreibvorgänge aktivieren:Streaming-Schreibvorgänge sind ein neuer Schreibpfad, bei dem Daten während des Schreibens direkt in Cloud Storage hochgeladen werden. Dieser Ansatz unterscheidet sich von der standardmäßigen Schreibmethode, bei der der gesamte Schreibvorgang vorübergehend in einem lokalen Verzeichnis bereitgestellt und dann bei einem close- oder fsync-Vorgang in Cloud Storage hochgeladen wird. Streaming-Schreibvorgänge reduzieren sowohl die Latenz als auch die Festplattenspeichernutzung. Das ist besonders bei großen, sequenziellen Schreibvorgängen wie Checkpoints von Vorteil. Geben Sie das Befehlszeilen-Flag enable-streaming-writes in mountOptions an, um Streaming-Schreibvorgänge zu aktivieren.

Probleme beheben

Weitere Informationen zur Fehlerbehebung finden Sie hier:

Nächste Schritte