Gestire l'acceleratore distribuito per l'archiviazione cloud (anteprima)

Usa questo articolo per verificare l'integrità di Distributed Accelerator for Cloud Storage (DACS), pianificare la capacità, precaricare i dati del modello, scalare i server cache e prepararsi alla manutenzione. DACS accelera principalmente il caricamento dei modelli per l'inferenza e può anche accelerare la lettura ripetuta del dataset per l'addestramento.

Prima di iniziare

Configurare una risorsa DACS e della cache seguendo Attività iniziali dell'acceleratore distribuito per l'archiviazione cloud nel servizio Azure Kubernetes. Esegui i seguenti comandi in una shell Bash con kubectl configurato per il tuo cluster AKS.

Imposta il namespace e il nome della cache da gestire:

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

Verifica lo stato di integrità di DACS

Elencare le risorse della cache e il loro stato:

kubectl get cache -A -o wide

Una risorsa Cache sana possiede queste caratteristiche:

• La Ready condizione è True.
• Il numero attuale di server corrisponde a quello desiderato.
• L'URL di individuazione viene popolato.
• Ogni pod cache-server è pronto e pianificato su un nodo NVMe idoneo.

Ispeziona una risorsa della cache e gli eventi correlati:

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'

Pianificare la capacità

Dimensiona la cache per il set di lavoro attivo, non la dimensione totale di ogni modello o dataset in Archiviazione BLOB di Azure. Per l'inferenza, considera i modelli caricati durante l'avvio e il scale-out. Per l'addestramento, considera le parti del dataset che i lavoratori leggono ripetutamente tra epoche o lavori. Includere la capacità per nuove versioni di modello, modifiche al set di dati e rimozioni.

Considera questi input:

• I byte attivi del modello o del set di dati e la versione prevista si sovrappongono.
• Numero e dimensione dei dischi NVMe locali per ogni nodo della cache.
• Numero di nodi cache e la loro larghezza di banda di uscita di rete.
• Numero di lettori di inferenza o worker di addestramento contemporanei.
• Rapporto di riscontri a caldo e tasso di fallback di BLOB previsti.
• Tolleranza al guasto quando un nodo della cache viene sostituito.

Acceleratore distribuito per l'archiviazione cloud supporta fino a 100 nodi. Più server di cache aumentano la capacità aggregata e possono aumentare la larghezza di banda in ingresso verso un lettore. Il client e la rete cluster possono diventare i fattori limitanti prima che il throughput NVMe venga esaurito.

Piano per le letture da cache fredda

I nuovi server di cache si avviano senza dati memorizzati nella cache. La sostituzione, l'espulsione e la manutenzione dei nodi possono anche causare la lettura nuovamente di dati precedentemente memorizzati nella cache da Archiviazione BLOB di Azure. Pianifica le implementazioni e gli eventi di scalabilità in modo che le letture a freddo contemporanee non sovraccarichino l'account di archiviazione o la rete.

Dopo aver avviato i carichi di lavoro, utilizzare le metriche client cache-hit e aumenti riusciti del contatore delle richieste del server cache per verificare che le letture utilizzino DACS. Letture riuscite o più rapide da sole non sono la prova della cache perché il client può tornare a Archiviazione BLOB di Azure. Per i passaggi di verifica, vedi Verifica il percorso di richiesta DACS. Per la telemetria in corso, vedere Monitorare un acceleratore distribuito per l'archiviazione cloud.

Precarica i dati del modello prima della distribuzione

Il Prefetch è un'ottimizzazione opzionale per avviamenti a freddo e aggiornamenti dei modelli. Leggi i dati del modello tramite DACS prima di avviare le repliche di inferenza, così che le prime letture possano utilizzare la cache condivisa. Le applicazioni possono comunque leggere da Archiviazione BLOB di Azure quando la cache è fredda; il prefetch non è necessario per la correttezza.

Il seguente esempio utilizza il riscaldamento guidato dal client: un processo Python legge ogni blob di modello tramite il client DACS. Non richiede un comando CLI separato di prefetch.

Preparare il carico di lavoro di riscaldamento

1. Conferma che la risorsa Cache sia pronta e abbia sufficiente capacità per i file di modello selezionati. Per un aggiornamento del modello, assicurati che ci sia capacità sia per la versione attuale che per quella nuova durante il lancio.
2. Carica il nuovo modello su un percorso Blob distinto e versionato, come models/my-model/v2/. Mantieni disponibile la versione attuale fino al completamento delle finestre di rollout e rollback.
3. Compila e spingi l'immagine client e concedi all'identità Kubelet l'accesso alla lettura del Blob come descritto nel quickstart. Il pod dedicato nella sezione seguente usa quell'immagine e quell'identità; non utilizza il pod di test completato del quickstart.
4. Usa la stessa configurazione di cache chunk nel client di riscaldamento e nei lettori di inferenza, compreso SI_streamingChunkSize se lo sovrascrivi. Dimensioni diverse dei chunk producono voci della cache differenti, quindi precaricare un layout non precarica un altro. Vedi Configura dimensione del blocco della cache.
5. Seleziona ogni blob necessario per caricare il modello, inclusi tutti i shard di peso. Inizialmente usa un piccolo numero di worker di warm-up per limitare il traffico di Blob.

Crea un pod di prefetch dedicato

Nella stessa sessione shell, imposta l'immagine costruita nel quickstart e l'ID client dell'identità gestita di kubelet. Il cluster deve essere in grado di eseguire il pull dell'immagine. Il pod rimane disponibile per un'ora così puoi eseguire e verificare le letture di warm-up; eliminalo prima, quando hai finito.

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

Se i lettori di inferenza sovrascrivono la dimensione del blocco della cache, aggiungi la stessa impostazione a questo pod prima di crearlo. Per i modelli che richiedono più di un'ora per riscaldarsi ed essere verificati, aumenta sia la durata del sonno sia activeDeadlineSeconds prima del dispiegamento.

Leggere i BLOB del modello selezionato

Impostare i percorsi completi dei BLOB nel livello a caldo. Sostituisci i percorsi di esempio con i tuoi file modello:

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

Questo processo legge ogni blob elencato per intero con buffer limitati. A differenza del campione del quickstart, non si ferma dopo i primi 4 MiB. Ripeti il comando per altri gruppi di file secondo necessità.

Verificare il riscaldamento e distribuire il modello

1. Controlla che il comando termini con successo per ogni blob selezionato. Un errore di lettura interrompe l'esempio; risolvi errori di autenticazione, connettività o percorso Blob prima di riprovare.
2. Ripeti le letture e conferma gli hit della cache usando Verifica il percorso di richiesta DACS. Le letture riuscite da sole non dimostrano che i dati sono archiviati in cache, e il popolamento della cache potrebbe essere ancora in corso quando una lettura termina.
3. Avvia un piccolo numero di repliche di inferenza utilizzando gli stessi percorsi Blob versionati. Conferma che il caricamento del modello abbia successo e che le letture utilizzino la cache prima di scalare orizzontalmente.
4. Per un aggiornamento, sposta il traffico al nuovo modello solo dopo aver superato i controlli di salute dell'applicazione. Tieni disponibile il modello vecchio per il rollback.

La prelettura non blocca i dati nella cache né garantisce che rimangano memorizzati nella cache. L'eliminazione, la sostituzione dei nodi o modifiche alla topologia della cache possono richiedere un altro warm-up. Monitorare la capacità della cache e il traffico Blob durante il lancio.

Dopo la verifica, elimina il pod dedicato. Questa azione non rimuove i dati memorizzati nella cache sui server DACS.

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

L'esempio di Python viene eseguito tramite kubectl exec, quindi cattura l'output del terminale per gli errori di lettura e le metriche di shutdown. Il processo principale sleep del pod non emette quei messaggi.

Controlla la configurazione dello storage della cache

La risorsa Cache specifica il numero di server cache, la capacità per server, i limiti delle risorse, il selettore dei nodi e il percorso dati della cache. Ispezionare la configurazione attuale prima di cambiare capacità:

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

Per la configurazione host-path utilizzata nel quickstart, spec.storage.hostPath.nodeCacheFolderPath deve corrispondere al punto di montaggio verificato durante la verifica della preparazione NVMe. Il percorso deve puntare a memoria NVMe locale dedicata, non al disco del sistema operativo. Per l'esempio di configurazione, vedi Provisionare la cache.

Ridimensionare la cache

Per la configurazione di scaling statico usata nel quickstart, cambia spec.scaling.static.numServers sulla risorsa Cache, non sull'estensione.

Prima di aumentare il conteggio, aggiungi un numero sufficiente di nodi NVMe idonei al pool di nodi della cache. Assicurarsi che i nuovi nodi abbiano l'etichetta del node-pool richiesta e che la CPU, la memoria e la capacità del disco disponibili rispettino la specifica della Cache. Il DaemonSet gestito dacs-prereq prepara automaticamente NVMe sui nodi corrispondenti ai criteri. Non installare un altro grafico dei prerequisiti.

Verifica che il DaemonSet abbia un pod Ready su ogni nuovo nodo della cache prima di aumentare il numero di server:

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

Etichetta solo i nodi i cui dischi NVMe locali sono dedicati a DACS: la configurazione prerequisita può formattare quei dischi. Tieni le etichette nella configurazione node-pool così sopravvivano alla sostituzione dei nodi.

Imposta il numero di server desiderato e aggiorna la risorsa Cache. Usa un intero positivo che si adatti al pool di nodi idonei:

DESIRED_SERVERS=3

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

Controlla il numero di server desiderati e attuali finché non corrispondono, poi verifica la prontezza e la posizione dei pod:

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

L'elenco dei pod include tutti i server cache presenti nello spazio dei nomi. Se il namespace contiene più risorse Cache, usa i riferimenti al proprietario del pod per identificare i server della cache che stai modificando. Conferma che il numero di server corrisponda a quello richiesto e che tutti i server siano pronti sui nodi NVMe idonei prima di continuare.

Per ridurre il numero di istanze, riduci il numero di server cache e attendi la riconciliazione prima di rimuovere i nodi idonei. Pianificare i mancati riscontri della cache e il traffico BLOB aggiuntivo quando i blocchi memorizzati nella cache vengono persi.

Prepararsi per gli aggiornamenti

Prima di cambiare versioni:

1. Controlla i requisiti di compatibilità della versione target e il percorso di aggiornamento supportato. Non dare per scontato che le versioni di anteprima arbitrarie supportino aggiornamenti sul posto.
2. Registrare lo stato della cache, il numero di server, la capacità, il currentVersion dell'estensione gestita e le versioni del client del carico di lavoro. Recupera i dettagli dell'estensione seguendo Verifica l'estensione.
3. Controlla la compatibilità tra il rilascio dell'estensione installato, i prerequisiti NVMe, la configurazione della cache e i client. Un grafico pubblico o un pacchetto client più recente non significa che l'estensione gestita sia stata aggiornata.
4. Conferma che i file modello autorevoli e i dataset siano disponibili in Archiviazione BLOB di Azure.
5. Programma l'aggiornamento in un periodo in cui il ripopolamento della cache non sovraccaricherà l'account Blob.

Gestisci il ciclo di vita del controller tramite l'estensione DACS e segui la procedura di aggiornamento supportata per il rilascio target. Non aggiornare direttamente la release Helm sottostante dell'estensione, non installare un altro controller insieme ad essa, né applicare a DACS le istruzioni di aggiornamento del driver del volume persistente. Pianifica separatamente qualsiasi migrazione da un'installazione manuale esistente.

Dopo la manutenzione, conferma la prontezza dell'estensione e del controller seguendo Verifica l'estensione, poi ripeti i controlli di salute della cache in questo articolo.

Non fare affidamento sul fatto che i dati memorizzati in cache sopravvivano a un aggiornamento. Consentire il ripopolamento da Archiviazione BLOB di Azure nelle letture successive.

Rimuovere DACS

Rimuovere la cache non elimina i file di modello sorgente o i dataset in Archiviazione BLOB di Azure. Ferma o riconfigura i carichi di lavoro che dipendono dalla cache prima di rimuoverla.

Per l'ordine di pulizia e i comandi, vedi Rimuovere acceleratore distribuito per lo storage cloud.

Passaggi successivi

• Monitorare un acceleratore distribuito per l'archiviazione cloud.
• Risoluzione dei problemi con acceleratore distribuito per lo storage cloud.
• Usa un acceleratore distribuito per lo storage cloud con il client Python.