Verwalten des verteilten Beschleunigers für Cloud-Speicher (Vorschau)

Nutzen Sie diesen Artikel, um den Zustand des verteilten Beschleunigers für Cloud-Speicher (DACS) zu überprüfen, die Kapazität zu planen, Modelldaten vorzuladen, Cache-Server zu skalieren und die Wartung vorzubereiten. DACS beschleunigt hauptsächlich das Laden des Modells zur Inferenz und kann auch wiederholte Datensatzlesungen für das Training beschleunigen.

Bevor Sie anfangen

Richte DACS und eine Cache-Ressource ein, indem du Get Started with Distributed Accelerator für Cloud-Speicher auf AKS folgst. Führen Sie die folgenden Befehle in einer Bash-Shell aus, wobei kubectl für Ihren AKS-Cluster konfiguriert ist.

Setze den Namensraum und den Namen des Caches, den du verwalten möchtest:

CACHE_NAMESPACE=<cache-namespace>
CACHE_NAME=<cache-name>

Überprüfen der DACS-Integrität

Liste der Cache-Ressourcen und ihres Status:

kubectl get cache -A -o wide

Eine gesunde Cache-Ressource weist folgende Eigenschaften auf:

• The Ready-Bedingung ist True.
• Die aktuelle Serveranzahl entspricht der gewünschten Serveranzahl.
• Die Discovery-URL ist eingetragen.
• Jeder Cache-Server-Pod ist bereit und auf einem geeigneten NVMe-Knoten geplant.

Inspizieren Sie eine Cache-Ressource und verwandte Ereignisse:

kubectl get cache "$CACHE_NAME" \
  --namespace "$CACHE_NAMESPACE" \
  -o yaml

kubectl get pods \
  --namespace "$CACHE_NAMESPACE" \
  --selector app=cacheserver \
  -o wide

kubectl get events \
  --namespace "$CACHE_NAMESPACE" \
  --sort-by='.lastTimestamp'

Kapazität planen

Dimensionieren Sie den Cache für das aktive Arbeitsset, nicht die Gesamtgröße jedes Modells oder Datensatzes in Azure Blob Storage. Für die Inferenz berücksichtigen Sie Modelle, die während des Starts und der Skalierung geladen werden. Für das Training berücksichtigen Sie Datensatzabschnitte, die Worker wiederholt über Epochen oder Aufträge hinweg lesen. Beziehen Sie Spielraum für neue Modellversionen, Datensatzänderungen und Verdrängung ein.

Betrachten Sie diese Eingaben:

• Die Bytes des aktiven Modells oder Datensatzes überschneiden sich mit der erwarteten Version.
• Anzahl und Größe der lokalen NVMe-Datenträger pro Cache-Knoten.
• Anzahl der Cache-Knoten und deren Netzwerk-Ausgangsbandbreite.
• Anzahl der gleichzeitigen Inferenzleser oder Trainings-Worker.
• Erwartetes Warm-Hit-Verhältnis und Blob-Fallbackrate.
• Fehlertoleranz, wenn ein Cache-Knoten ersetzt wird.

Der verteilte Beschleuniger für Cloud-Speicher unterstützt bis zu 100 Knoten. Mehr Cache-Server erhöhen die aggregierte Kapazität und können die Fan-in-Bandbreite für einen Reader erhöhen. Der Client und das Cluster-Netzwerk können zu den begrenzenden Faktoren werden, bevor der NVMe-Durchsatz erschöpft ist.

Plan für Cold-Cache-Lesungen

Neue Cache-Server starten ohne zwischengespeicherte Daten. Ersetzen von Knoten, Verdrängung und Wartung können ebenfalls dazu führen, dass zuvor zwischengespeicherte Daten erneut aus Azure Blob Storage gelesen werden. Planen Sie Bereitstellungen und skalieren Sie Ereignisse so, dass gleichzeitige Cold-Reads das Speicherkonto oder Netzwerk nicht überlasten.

Nach dem Start der Workloads verwenden Sie Client-Cache-Hit-Metriken und Erhöhungen des Zählers für erfolgreiche Cache-Server-Anfragen, um zu überprüfen, ob Lesezugriffe DACS verwenden. Erfolgreiche oder schnellere Reads allein sind kein Beweis für Caching, da der Client auf Azure Blob Storage zurückgreifen kann. Weitere Informationen zu Verifikationsschritten finden Sie unter DACS-Anfragepfad verifizieren. Siehe Verteilten Beschleuniger für Cloud-Speicher-Fragen überwachen für fortlaufende Telemetrie.

Modelldaten vor der Bereitstellung vorab abrufen

Prefetch ist eine optionale Optimierung für Kaltstarts und Modell-Upgrades. Lesen Sie die Modelldaten über DACS, bevor Sie Inferenz-Replikate starten, damit deren erste Lesezugriffe den gemeinsamen Cache nutzen können. Anwendungen können weiterhin aus Azure Blob Storage lesen, wenn der Cache kalt ist; Prefetch ist für die Korrektheit nicht erforderlich.

Das folgende Beispiel verwendet clientgesteuertes Aufwärmen: Ein Python-Prozess liest jeden Modellblob durch den DACS-Client. Es erfordert keinen separaten Prefetch-CLI-Befehl.

Bereite den Aufwärm-Workload vor

1. Bestätigen Sie, dass die Cache-Ressource bereit ist und genügend Kapazität für die ausgewählten Modelldateien hat. Für ein Modell-Upgrade sollten Sie während der Einführung sicherstellen, dass ausreichend Kapazität für sowohl die aktuelle als auch die neue Version vorhanden ist.
2. Lade das neue Modell auf einen eigenen, versionierten Blob-Pfad hoch, wie zum Beispiel models/my-model/v2/. Halten Sie die aktuelle Version verfügbar, bis die Rollout- und Rollback-Zeitfenster abgeschlossen sind.
3. Erstellen und pushen Sie das Client-Image und gewähren Sie der Kubelet-Identität Lesezugriff auf Blob, wie im Quickstart beschrieben. Der dedizierte Pod im folgenden Abschnitt verwendet dieses Bild und diese Identität; er verwendet nicht den fertiggestellten Testpod des Quickstart.
4. Verwenden Sie dieselbe Cache-Chunk-Konfiguration im Warm-up-Client und in den Inferenzlesern, auch SI_streamingChunkSize wenn Sie sie überschreiben. Unterschiedliche Chunk-Größen erzeugen unterschiedliche Cache-Einträge, sodass das Vorwärmen eines Layouts kein anderes vorwärmt. Siehe Cache-Chunk-Größe konfigurieren.
5. Wählen Sie jeden benötigten Blob aus, um das Modell zu laden, einschließlich aller Gewichts-Shards. Verwenden Sie zunächst eine kleine Anzahl von Warm-up-Arbeitern, um den Blob-Verkehr zu begrenzen.

Erstellen Sie einen dedizierten Prefetch-Pod

Legen Sie in derselben Shell-Sitzung das im Quickstart erstellte Image und die Client-ID der vom Kubelet verwalteten Identität fest. Der Cluster muss in der Lage sein, das Image herunterzuladen. Der Pod bleibt eine Stunde lang verfügbar, damit du Warm-up-Reads durchführen und überprüfen kannst; lösche ihn früher, wenn du fertig bist.

WORKLOAD_IMAGE=<registry-name>.azurecr.io/dacs-test:0.1.0
KUBELET_CLIENT_ID=<kubelet-managed-identity-client-id>
CLIENT_POD=dacs-prefetch
CACHE_DISCOVERY_URL=$(kubectl get cache "$CACHE_NAME" \
  --namespace "$CACHE_NAMESPACE" -o jsonpath='{.status.discoveryURL}')
CACHE_SERVER_PORT=$(kubectl get cache "$CACHE_NAME" \
  --namespace "$CACHE_NAMESPACE" -o jsonpath='{.spec.port}')

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: $CLIENT_POD
  namespace: $CACHE_NAMESPACE
spec:
  restartPolicy: Never
  activeDeadlineSeconds: 3600
  containers:
    - name: prefetch
      image: $WORKLOAD_IMAGE
      command: ["sleep", "3600"]
      env:
        - name: CACHE_DISCOVERY_URL
          value: "$CACHE_DISCOVERY_URL"
        - name: CACHE_SERVER_PORT
          value: "$CACHE_SERVER_PORT"
        - name: AZURE_CLIENT_ID
          value: "$KUBELET_CLIENT_ID"
        - name: MSI_ENDPOINT
          value: "http://169.254.169.254/metadata/identity/oauth2/token"
        - name: MSI_SECRET
          value: "required-nonempty-value"
        - name: DACS_CPU_CORES
          value: "2"
        - name: DACS_MEMORY_MB
          value: "512"
      resources:
        requests:
          cpu: "1"
          memory: 512Mi
        limits:
          cpu: "2"
          memory: 1Gi
EOF

kubectl wait --namespace "$CACHE_NAMESPACE" \
  --for=condition=Ready "pod/$CLIENT_POD" --timeout=5m

Wenn Inference-Reader die Cache-Chunk-Größe überschreiben, fügen Sie diese Einstellung auch diesem Pod hinzu, bevor Sie ihn erstellen. Für Modelle, die länger als eine Stunde zum Erwärmen und Verifizieren benötigen, erhöhen Sie sowohl die Schlafdauer als auch activeDeadlineSeconds vor der Bereitstellung.

Lesen Sie die ausgewählten Modellblobs

Lege die vollständigen Pfade der Blobs zum Vorwärmen fest. Ersetzen Sie die Beispielpfade durch Ihre Modelldateien:

MODEL_BLOBS=(
  "az://<storage-account>.blob.core.windows.net/<container>/models/my-model/v2/model-00001.safetensors"
  "az://<storage-account>.blob.core.windows.net/<container>/models/my-model/v2/model-00002.safetensors"
)

kubectl exec --namespace "$CACHE_NAMESPACE" -i "$CLIENT_POD" -- \
  python3 - "${MODEL_BLOBS[@]}" <<'PY'
import asyncio
import os
import sys

from py_dacs_client.dacs_client import DACSCacheClient
from py_dacs_client.dacs_utils import BoundedBufferManager


async def main():
    for name in ("CACHE_DISCOVERY_URL", "CACHE_SERVER_PORT"):
        if not os.environ.get(name):
            raise RuntimeError(f"Set {name} in the client pod before warming data")
    client = DACSCacheClient()
    buffers = BoundedBufferManager(max_memory_limit=64 * 1024 * 1024)
    try:
        for path in sys.argv[1:]:
            size = await client.get_file_size(path)
            offset = 0
            while offset < size:
                length = min(4 * 1024 * 1024, size - offset)
                buffer = await buffers.acquire_buffer(length)
                try:
                    count = await client.read_blob(path, buffer, length, offset)
                    if count != length:
                        raise RuntimeError(
                            f"{path}: expected {length} bytes at {offset}, got {count}"
                        )
                finally:
                    await buffers.release_buffer(buffer)
                offset += count
            print(f"Read complete: {path} ({size} bytes)", flush=True)
    finally:
        await client.shutdown()


asyncio.run(main())
PY

Dieser Prozess liest jeden aufgeführten Blob vollständig mit beschränkten Puffern. Im Gegensatz zum Quickstart-Sample hört es nach den ersten 4 MiB nicht auf. Wiederholen Sie den Befehl für zusätzliche Dateigruppen bei Bedarf.

Überprüfen Sie die Warnung und führen Sie das Modell ein

1. Überprüfen Sie, ob der Befehl für jeden ausgewählten Blob erfolgreich abgeschlossen wird. Ein Lesefehler stoppt das Beispiel; beheben Sie Authentifizierungs-, Konnektivitäts- oder Blob-Pfadfehler vor einem erneuten Versuch.
2. Wiederholen Sie die Lesevorgänge und bestätigen Sie die Cache-Treffer, indem Sie den DACS-Anfragepfad überprüfen. Erfolgreiche Lesevorgänge allein beweisen nicht, dass die Daten zwischengespeichert sind, und die Cache-Population kann noch im Gange sein, wenn ein Lesevorgang abgeschlossen ist.
3. Starten Sie eine kleine Anzahl von Inferenzrepliken, indem Sie dieselben versionierten Blob-Pfade verwenden. Bestätigen Sie, dass das Laden des Modells erfolgreich ist und die Lesevorgänge den Cache verwenden, bevor horizontal skaliert wird.
4. Für ein Upgrade wird der Datenverkehr erst nach Abschluss der Gesundheitsprüfungen der Anwendung auf das neue Modell umgestellt. Halte das alte Modell zum Rollback verfügbar.

Prefetch fixiert keine Daten und garantiert nicht, dass sie zwischengespeichert bleiben. Verdrängung, Ersetzen eines Knotens oder Änderungen an der Cache-Topologie können ein weiteres Aufwärmen erfordern. Überwachen Sie die Cachekapazität und den Blob-Verkehr während des Rollouts.

Nach der Überprüfung löschen Sie den dedizierten Pod. Diese Aktion entfernt nicht die auf DACS-Servern zwischengespeicherten Daten.

kubectl delete pod "$CLIENT_POD" --namespace "$CACHE_NAMESPACE"

Das Python-Beispiel läuft durch kubectl exec, erfassen Sie daher seine Terminalausgabe für Lesefehler und Abschaltmetriken. Der Hauptprozess sleep des Pods gibt diese Nachrichten nicht aus.

Überprüfen Sie die Konfiguration des Cache-Speichers

Die Cache-Ressource spezifiziert die Anzahl der Cache-Server, die Kapazität pro Server, die Ressourcenbegrenzungen, den Knotenselektor und den Cache-Datenpfad. Überprüfen Sie die aktuelle Konfiguration, bevor Sie die Kapazität ändern:

kubectl get cache "$CACHE_NAME" \
  --namespace "$CACHE_NAMESPACE" \
  -o yaml

Für die im Quickstart verwendete Host-Path-Konfiguration muss spec.storage.hostPath.nodeCacheFolderPath mit dem während der NVMe-Vorbereitungsverifikation überprüften Mount-Punkt übereinstimmen. Der Pfad muss auf dedizierten lokalen NVMe-Speicher verweisen, nicht auf die Betriebssystem-Festplatte. Für das Konfigurationsbeispiel siehe Cache bereitstellen.

Skalieren des Caches

Für die statische Skalierungskonfiguration, die im Quickstart verwendet wird, ändern Sie spec.scaling.static.numServers an der Cache-Ressource, nicht an der Erweiterung.

Bevor die Anzahl erhöht wird, fügen Sie genügend berechtigte NVMe-Knoten zum Cache-Node-Pool hinzu. Stellen Sie sicher, dass neue Knoten das erforderliche Node-Pool-Label haben und dass ihre verfügbare CPU-, Speicher- und Festplattenkapazität der Cache-Spezifikation entspricht. Das verwaltete dacs-prereq DaemonSet bereitet NVMe automatisch auf übereinstimmenden Knoten vor. Installieren Sie kein weiteres Voraussetzungsdiagramm.

Überprüfen Sie, dass der DaemonSet auf jedem neuen Cache-Knoten einen Ready-Pod hat, bevor Sie die Serveranzahl erhöhen:

kubectl rollout status daemonset/dacs-prereq --namespace kube-system --timeout=10m
kubectl get pods --namespace kube-system \
  --selector app.kubernetes.io/name=dacs-prereq --output wide

Kennzeichnen Sie nur Knoten, deren lokale NVMe-Laufwerke für DACS dediziert sind: Die Voraussetzungseinrichtung kann diese Laufwerke formatieren. Behalten Sie die Labels in der Node-Pool-Konfiguration, damit sie den Knotenaustausch überstehen.

Stellen Sie die gewünschte Serveranzahl ein und aktualisieren Sie die Cache-Ressource. Verwenden Sie eine positive ganze Zahl, die zum geeigneten Knotenpool passt:

DESIRED_SERVERS=3

kubectl patch cache "$CACHE_NAME" \
  --namespace "$CACHE_NAMESPACE" \
  --type merge \
  --patch "{\"spec\":{\"scaling\":{\"static\":{\"numServers\":$DESIRED_SERVERS}}}}"

Überprüfen Sie die gewünschten und aktuellen Serveranzahl, bis sie übereinstimmen, und überprüfen Sie dann die Einsatzbereitschaft und die Platzierung der Pods:

kubectl get cache "$CACHE_NAME" --namespace "$CACHE_NAMESPACE" -o wide

kubectl wait \
  --namespace "$CACHE_NAMESPACE" \
  --for=condition=Ready \
  "cache/$CACHE_NAME" \
  --timeout=10m

kubectl get pods \
  --namespace "$CACHE_NAMESPACE" \
  --selector app=cacheserver \
  -o wide

Die Pod-Liste enthält alle Cache-Server im Namespace. Wenn der Namespace mehrere Cache-Ressourcen enthält, nutze Pod-Owner-Referenzen, um die Server für den Cache zu identifizieren, den du änderst. Bestätigen Sie, dass die Serveranzahl mit der angeforderten Anzahl übereinstimmt und dass alle Server auf berechtigten NVMe-Knoten bereit sind, bevor Sie fortfahren.

Um herunterzuskalieren, reduzieren Sie die Anzahl der Cache-Server und warten Sie auf die Rekonziliierung, bevor Sie berechtigte Knoten entfernen. Planen Sie Cache-Misses und zusätzlichen Blob-Datenverkehr ein, wenn zwischengespeicherte Chunks verloren gehen.

Für Upgrades vorbereiten

Vor dem Versionswechsel:

1. Überprüfen Sie die Kompatibilitätsanforderungen der Zielversion und den unterstützten Upgrade-Pfad. Gehen Sie nicht davon aus, dass beliebige Vorschauversionen In-Place-Upgrades unterstützen.
2. Speichern Sie den Cache-Status, die Anzahl der Server, die Kapazität, die currentVersion der verwalteten Erweiterung und die Versionen des Workload-Clients. Rufen Sie Erweiterungsdetails ab, indem Sie Erweiterung überprüfen auswählen.
3. Überprüfen Sie die Kompatibilität zwischen der Version der installierten Erweiterung, den NVMe-Voraussetzungen, der Cache-Konfiguration und den Clients. Ein neueres öffentliches Chart oder Client-Paket heißt nicht, dass die verwaltete Erweiterung aktualisiert wurde.
4. Bestätigen Sie, dass autoritative Modelldateien und Datensätze in Azure Blob Storage verfügbar sind.
5. Planen Sie das Upgrade in einen Zeitraum, in dem die Cache-Befüllung das Blob-Konto nicht überlastet.

Verwalten Sie den Controller-Lebenszyklus über die DACS-Erweiterung und folgen Sie dem unterstützten Upgrade-Verfahren für die Zielversion. Aktualisieren Sie nicht direkt das zugrunde liegende Helm-Release der Erweiterung, installieren Sie keinen weiteren Controller parallel dazu oder wenden Sie keine Anweisungen zum Upgrade des Persistent-Volume-Treibers auf DACS an. Planen Sie jede Migration von einer bestehenden manuellen Installation separat.

Nach der Wartung bestätigen Sie die Bereitschaft der Erweiterung und des Controllers, indem Sie die Erweiterung überprüfen, und wiederholen Sie dann die in diesem Artikel beschriebenen Cache-Gesundheitsprüfungen.

Verlassen Sie sich nicht darauf, dass zwischengespeicherte Daten ein Upgrade überleben. Erlauben Sie eine Neubefüllung aus Azure Blob Storage bei nachfolgenden Lesevorgängen.

DACS entfernen

Das Entfernen des Caches löscht keine Quellmodelldateien oder Datensätze in Azure Blob Storage. Stoppen Sie oder konfigurieren Sie Workloads, die vom Cache abhängen, bevor Sie ihn entfernen.

Für die Reihenfolge der Bereinigungsschritte und Befehle siehe Verteilten Beschleuniger für Cloud-Speicher entfernen.

Nächste Schritte

• Überwachen Sie den verteilten Accelerator für Cloud-Speicher.
• Fehlerbehebung eines verteilten Beschleunigers für Cloud-Speicher.
• Verwende Distributed Accelerator für Cloud-Speicher mit dem Python-Client.