Usa l'acceleratore distribuito per lo storage cloud con BlobFuse2 (anteprima)

Usa BlobFuse2 con acceleratore distribuito per lo storage cloud (DACS) per leggere i dati Azure Blob attraverso i percorsi del file system Linux. Le applicazioni mantengono il loro codice di lettura dei file esistente, mentre BlobFuse2 serve i dati memorizzati in cache tramite DACS e recupera i dati mancanti da gestione rete virtuale di Azure.

Il driver Azure Blob Container Storage Interface (CSI) monta il container tramite un volume persistente (PV) e una richiesta di volume persistente (PVC). Archiviazione BLOB di Azure rimane la fonte autorevole e persistente.

Questo articolo tratta la configurazione, la verifica del percorso di lettura e i risultati del benchmark di storage standard.

Prerequisites

• Un cluster AKS che soddisfi i requisiti della regione Azure e della versione Kubernetes nel DACS quickstart.
• Nodi cache Linux con dischi NVMe locali dedicati ai DACS.
• Nodi di carico di lavoro Ubuntu Linux per i pod applicativi che montano BlobFuse2.
• Un container Azure Blob contenente i dati della tua applicazione.
• Un'identità gestita assegnata dall'utente esistente per l'autenticazione Blob.
• interfaccia della riga di comando di Azure e kubectl.
• Permesso di abilitare DACS e il driver CSI Azure Blob gestito, creare risorse Kubernetes, gestire le credenziali federate dell'identità e assegnare il ruolo richiesto di accesso ai dati Blob.
• BlobFuse2 2.5.6 o successivo installato su ogni nodo di carico di lavoro Linux idoneo. Per il supporto e le limitazioni della cache distribuita, si vedano le note di rilascio di BlobFuse2 2.5.6.
• Driver v1.27.11 CSI BLOB di Azure gestito dal servizio Azure Kubernetes o versione successiva, con l'autorità di certificazione OIDC del servizio Azure Kubernetes e ID dei carichi di lavoro di Microsoft Entra abilitati per l'autenticazione solo con token.

Impostare variabili

Esegui i comandi nella stessa sessione di Bash. Sostituisci i segnaposto con il cluster, il contenitore di archiviazione e l'identità gestita esistente assegnata dall'utente:

SUBSCRIPTION_ID="<subscription-id>"
RESOURCE_GROUP="<aks-resource-group>"
CLUSTER_NAME="<aks-cluster-name>"
WORKLOAD_NODE_POOL="<blobfuse-ready-node-pool>"
STORAGE_RESOURCE_GROUP="<storage-resource-group>"
STORAGE_ACCOUNT="<storage-account-name>"
STORAGE_CONTAINER="<existing-container-name>"
IDENTITY_RESOURCE_GROUP="<managed-identity-resource-group>"
IDENTITY_NAME="<managed-identity-name>"
CACHE_NAMESPACE=dacs-cache-system
CACHE_NAME=cache-sample
WORKLOAD_NAMESPACE=blobfuse-dacs
SERVICE_ACCOUNT=blobfuse-reader

az account set --subscription "$SUBSCRIPTION_ID"
az aks get-credentials --resource-group "$RESOURCE_GROUP" --name "$CLUSTER_NAME"

BLOBFUSE_CLIENT_ID=$(az identity show \
  --resource-group "$IDENTITY_RESOURCE_GROUP" \
  --name "$IDENTITY_NAME" \
  --query clientId --output tsv)

Installa un acceleratore distribuito per lo storage cloud

Per installare DACS, preparare dischi di cache dedicati, creare una risorsa di cache e verificare la prontezza, vedi Get started with distributed accelerator for cloud storage on AKS.

Recupera l'hostname di individuazione per la tua Ready Cache:

CACHE_DISCOVERY_HOST=$(kubectl get cache "$CACHE_NAME" \
  --namespace "$CACHE_NAMESPACE" \
  -o jsonpath='{.status.discoveryURL}')

test -n "$CACHE_DISCOVERY_HOST"

Usa il nome host pubblicato dalla tua risorsa Cache e la sua porta configurata. L'avvio rapido utilizza la porta 9065.

Abilita il driver CSI di Azure Blob e verifica BlobFuse2

Usa il driver gestito da AKS. Segui Abilita il driver CSI Azure Blob su AKS.

Usa AKS per gestire gli aggiornamenti dei driver CSI. Assicurarsi che ogni nodo di carico di lavoro idoneo eseguisca BlobFuse2 2.5.6 o successivo e coordinare gli aggiornamenti dei pacchetti con lo smontaggio dei volumi.

Verificare il processo del montaggio installato

Controllare la preparazione di CSI tramite il DaemonSet del nodo.

kubectl get csidriver blob.csi.azure.com
kubectl rollout status daemonset/csi-blob-node \
  --namespace kube-system --timeout=10m
kubectl get pods --namespace kube-system \
  --selector app=csi-blob-node --output wide
kubectl get daemonset csi-blob-node --namespace kube-system \
  --output jsonpath='{range .spec.template.spec.containers[*]}{.name}{": "}{.image}{"\n"}{end}'

Conferma che l'immagine blob del contenitore sia versione v1.27.11 o successiva.

La versione dell'immagine del driver CSI non identifica la versione BlobFuse2 installata sull'host. Per ogni nodo Ubuntu idoneo, seleziona il suo csi-blob-node pod dall'output precedente e verifica il binario host usato dal proxy CSI:

BLOB_CSI_POD="<csi-blob-node-pod-name>"

kubectl exec --namespace kube-system "$BLOB_CSI_POD" --container blob -- \
  nsenter --mount=/proc/1/ns/mnt -- /usr/bin/blobfuse2 --version

kubectl exec --namespace kube-system "$BLOB_CSI_POD" --container blob -- \
  nsenter --mount=/proc/1/ns/mnt -- /usr/bin/blobfuse2 mount --help

Confermare che la versione 2.5.6 o successiva e che le opzioni --distributed-cache-* utilizzate nella configurazione dei volumi siano quelle indicate nella sezione seguente.

Aggiorna BlobFuse2 quando l'immagine del nodo ha una versione precedente

Se manca il binario host o è precedente alla 2.5.6, configura il container init del install-blobfuse-proxy driver CSI gestito per installare il pacchetto BlobFuse2 richiesto. Salta questo passaggio quando tutti i nodi idonei hanno già la versione 2.5.6 o successiva.

Questo aggiornamento utilizza l'installer dei pacchetti sui nodi Ubuntu, che necessitano di accesso ai repository di pacchetti Ubuntu e Microsoft configurati. Non sostituisce l'immagine del driver CSI gestito né installa un driver separato.

Salva il DaemonSet attuale e crea la patch:

kubectl get daemonset csi-blob-node --namespace kube-system \
  --output yaml > csi-blob-node-before.yaml

BLOBFUSE2_VERSION=2.5.6

cat <<EOF > csi-blob-proxy-patch.yaml
spec:
  template:
    spec:
      initContainers:
        - name: install-blobfuse-proxy
          env:
            - name: INSTALL_BLOBFUSE
              value: "false"
            - name: INSTALL_BLOBFUSE2
              value: "true"
            - name: BLOBFUSE2_VERSION
              value: "$BLOBFUSE2_VERSION"
            - name: INSTALL_BLOBFUSE_PROXY
              value: "true"
            - name: ALLOW_PACKAGE_INSTALL_DOWNGRADE
              value: "false"
EOF

kubectl patch daemonset csi-blob-node --namespace kube-system \
  --type strategic --patch-file csi-blob-proxy-patch.yaml

kubectl rollout status daemonset/csi-blob-node \
  --namespace kube-system --timeout=15m

La patch di unione aggiorna le voci denominate del contenitore init e dell'ambiente preservando l'immagine e altre impostazioni. Per i controlli di selezione del pacchetto, vedere Programma di installazione del proxy CSI BLOB.

Dopo l'implementazione, elencare di nuovo i pod CSI e ripetere la verifica binaria dell'host su ogni nodo di carico di lavoro idoneo. Verificare la versione 2.5.6 o successiva e le opzioni di distribuzione della cache prima di montare il volume. I processi di montaggio BlobFuse2 esistenti non cambiano versione quando il pacchetto cambia; ricreare i montaggi per utilizzare il binario aggiornato.

Se l'implementazione non riesce, controllare i log del programma di installazione per il pod interessato:

kubectl logs --namespace kube-system "<csi-blob-node-pod-name>" \
  --container install-blobfuse-proxy

Gli aggiornamenti del servizio Azure Kubernetes possono riconciliare il DaemonSet gestito. Ricontrolla le impostazioni binarie host e dell'installer dopo gli aggiornamenti del driver CSI o dell'immagine del nodo. Una volta che l'immagine del nodo fornisce la versione richiesta di BlobFuse2, rimuovi l'override temporaneo della versione package come parte di quell'aggiornamento.

Configurare l'autenticazione BLOB

Usa l'identità del carico di lavoro AKS federata con autenticazione Blob solo per token. La configurazione del volume abilita questa modalità con mountWithWorkloadIdentityToken: "true".

Segui Abilita OIDC e ID dei carichi di lavoro di Microsoft Entra, poi crea il Workload ServiceAccount:

kubectl create namespace "$WORKLOAD_NAMESPACE"

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: $SERVICE_ACCOUNT
  namespace: $WORKLOAD_NAMESPACE
  annotations:
    azure.workload.identity/client-id: "$BLOBFUSE_CLIENT_ID"
EOF

Collega il ServiceAccount alla tua identità gestita e concedi l'accesso con ambito container:

OIDC_ISSUER=$(az aks show \
  --resource-group "$RESOURCE_GROUP" \
  --name "$CLUSTER_NAME" \
  --query oidcIssuerProfile.issuerUrl --output tsv)

az identity federated-credential create \
  --name blobfuse-dacs-reader \
  --identity-name "$IDENTITY_NAME" \
  --resource-group "$IDENTITY_RESOURCE_GROUP" \
  --issuer "$OIDC_ISSUER" \
  --subject "system:serviceaccount:$WORKLOAD_NAMESPACE:$SERVICE_ACCOUNT" \
  --audiences api://AzureADTokenExchange

IDENTITY_PRINCIPAL_ID=$(az identity show \
  --resource-group "$IDENTITY_RESOURCE_GROUP" \
  --name "$IDENTITY_NAME" \
  --query principalId --output tsv)

STORAGE_ID=$(az storage account show \
  --resource-group "$STORAGE_RESOURCE_GROUP" \
  --name "$STORAGE_ACCOUNT" \
  --query id --output tsv)

az role assignment create \
  --assignee-object-id "$IDENTITY_PRINCIPAL_ID" \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Contributor" \
  --scope "$STORAGE_ID/blobServices/default/containers/$STORAGE_CONTAINER"

L'assegnazione del ruolo segue la guida per il montaggio solo token CSI. Lascia che si propaghi prima di testare. Il carico di lavoro accede a gestione rete virtuale di Azure tramite l'identità federata e un mount di sola lettura.

Configura un volume BlobFuse2 in sola lettura

Recupera l'IP del servizio DNS del cluster per il nome host locale del cluster della Cache:

CLUSTER_DNS_IP=$(az aks show \
  --resource-group "$RESOURCE_GROUP" \
  --name "$CLUSTER_NAME" \
  --query networkProfile.dnsServiceIp --output tsv)

test -n "$CLUSTER_DNS_IP"

Consentire ai nodi del carico di lavoro di raggiungere il cluster DNS, gli endpoint DACS e Archiviazione BLOB di Azure per cache miss e fallback.

Creare un PV e un PVC statico per il contenitore esistente. Il criterio Retain conserva i dati quando l'attestazione viene rimossa:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolume
metadata:
  name: blobfuse-dacs-pv
spec:
  capacity:
    storage: 1Ti
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: ""
  mountOptions:
    - --read-only=true
    - --allow-other=true
    - --disable-kernel-cache=true
    - --block-cache=false
    - --streaming=false
    - --preload=false
    - --distributed-cache-discovery-endpoint=$CACHE_DISCOVERY_HOST:9065
    - --distributed-cache-dns-server=$CLUSTER_DNS_IP
    - --distributed-cache-block-size=16
    - --distributed-cache-node-memory=1024
    - --distributed-cache-prefetch=16
    - --distributed-cache-parallelism=16
  csi:
    driver: blob.csi.azure.com
    readOnly: true
    volumeHandle: "$STORAGE_RESOURCE_GROUP#$STORAGE_ACCOUNT#$STORAGE_CONTAINER#blobfuse-dacs"
    volumeAttributes:
      protocol: fuse2
      resourceGroup: "$STORAGE_RESOURCE_GROUP"
      storageAccount: "$STORAGE_ACCOUNT"
      containerName: "$STORAGE_CONTAINER"
      clientID: "$BLOBFUSE_CLIENT_ID"
      mountWithWorkloadIdentityToken: "true"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: blobfuse-dacs-pvc
  namespace: $WORKLOAD_NAMESPACE
spec:
  accessModes:
    - ReadOnlyMany
  storageClassName: ""
  volumeName: blobfuse-dacs-pv
  resources:
    requests:
      storage: 1Ti
EOF

Usa un nome PV univoco e volumeHandle per ciascun volume. La dichiarazione 1Ti fornisce il valore di capacità per l'associazione PV/PVC.

Configurare la cache tramite le opzioni --distributed-cache-*. Il componente di cache distribuita gestisce il suo livello locale di cache a blocchi.

L'esempio alloca 1.024 MiB alla cache locale e pre-recupera 16 blocchi. Allocare la memoria separatamente per i pod applicativi, i mount BlobFuse2 lato host e i server DACS co-locati.

Montare il volume in un carico di lavoro

Impostare DATA_FILE su un percorso di file relativo alla radice del contenitore. Questo carico di lavoro Python legge due volte i primi 4 MiB e confronta i checksum:

DATA_FILE="<existing-file-path>"
WORKLOAD_IMAGE="python:3.12-slim-bookworm"

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: blobfuse-dacs-reader
  namespace: $WORKLOAD_NAMESPACE
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: $SERVICE_ACCOUNT
  restartPolicy: Never
  nodeSelector:
    kubernetes.io/os: linux
    agentpool: "$WORKLOAD_NODE_POOL"
  containers:
    - name: reader
      image: $WORKLOAD_IMAGE
      command:
        - python3
        - -c
        - |
          import hashlib
          import os
          import time
          from pathlib import Path

          path = Path("/mnt/blob") / os.environ["DATA_FILE"]
          previous = None
          for attempt in range(2):
              with path.open("rb") as stream:
                  data = stream.read(4 * 1024 * 1024)
              if not data:
                  raise RuntimeError("The selected file returned no data")
              digest = hashlib.sha256(data).hexdigest()
              if previous is not None and digest != previous:
                  raise RuntimeError("Repeated reads returned different bytes")
              print(f"read={attempt + 1} bytes={len(data)} sha256={digest}", flush=True)
              previous = digest
              time.sleep(5)
      env:
        - name: DATA_FILE
          value: "$DATA_FILE"
      resources:
        requests:
          cpu: "1"
          memory: 128Mi
        limits:
          cpu: "1"
          memory: 256Mi
      volumeMounts:
        - name: blob
          mountPath: /mnt/blob
          readOnly: true
  volumes:
    - name: blob
      persistentVolumeClaim:
        claimName: blobfuse-dacs-pvc
        readOnly: true
EOF

kubectl get pvc blobfuse-dacs-pvc --namespace "$WORKLOAD_NAMESPACE"
kubectl logs --namespace "$WORKLOAD_NAMESPACE" \
  blobfuse-dacs-reader --follow --pod-running-timeout=5m

L'applicazione legge /mnt/blob/<path>. Il selettore di nodi lo pianifica sul pool con l'installazione verificata di BlobFuse2.

Verifica il percorso di lettura del DACS

Configura lo scraping per ogni pod di cache-server seguendo Monitorare l'acceleratore distribuito per lo storage cloud.

1. Conferma che il PVC sia legato al PV e che il mount utilizzi le opzioni di scoperta, DNS e sola lettura attese.
2. Controlla i log CSI e BlobFuse2 per la versione installata e le connessioni ai server di cache attesi.
3. Registrare una base per cache_server_request_counter{request_type="Download",status="Success"}, sommata solo tra i server di pod di proprietà della cache.
4. Consentire il completamento del popolamento in background, quindi ripetere le letture in tutti i nodi del carico di lavoro. Correla l'attività di download del server riuscita con i log di BlobFuse2 e la telemetria Blob per confermare il riutilizzo distribuito.

Usare i checksum per verificare l'integrità dei dati e i contatori delle richieste per verificare il percorso della cache. Per comandi dettagliati, vedi Verifica il percorso della richiesta DACS.

Verifica il riutilizzo tra due nodi

Il carico di lavoro introduttivo legge due volte da un singolo nodo, che può riutilizzare la propria cache locale. Per verificare il riutilizzo distribuito, usare due nodi pronti dal pool di carico di lavoro verificato e un file di test che non è stato letto da questa cache. Scegli un file abbastanza piccolo da entrare nella cache e ottieni il SHA-256 atteso dalla sorgente originale o da un manifest affidabile.

Usare una cache dedicata per questo test così i carichi di lavoro non correlati non influenzino i contatori delle richieste.

Elenca i nodi idonei, poi imposta le etichette del nome host, il percorso del file rispetto alla radice del container e il checksum atteso:

kubectl get nodes --selector "agentpool=$WORKLOAD_NODE_POOL" \
  --output wide --label-columns kubernetes.io/hostname

COLD_NODE="<first-node-hostname-label>"
WARM_NODE="<different-node-hostname-label>"
VALIDATION_FILE="<existing-uncached-file-path>"
EXPECTED_SHA256="<expected-full-file-sha256>"

Creare due lettori che mantengano i montaggi attivi mentre si eseguono i controlli e si aspetta la popolazione in background:

create_validation_reader() {
  local name="$1" node="$2"
  if [ -z "$COLD_NODE" ] || [ -z "$WARM_NODE" ] || [ "$COLD_NODE" = "$WARM_NODE" ]; then
    echo "ERROR: choose two different workload nodes." >&2
    return 1
  fi

  cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: $name
  namespace: $WORKLOAD_NAMESPACE
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: $SERVICE_ACCOUNT
  restartPolicy: Never
  nodeSelector:
    kubernetes.io/os: linux
    agentpool: "$WORKLOAD_NODE_POOL"
    kubernetes.io/hostname: "$node"
  containers:
    - name: reader
      image: $WORKLOAD_IMAGE
      command: ["sleep", "86400"]
      resources:
        requests:
          cpu: "1"
          memory: 128Mi
        limits:
          cpu: "1"
          memory: 256Mi
      volumeMounts:
        - name: blob
          mountPath: /mnt/blob
          readOnly: true
  volumes:
    - name: blob
      persistentVolumeClaim:
        claimName: blobfuse-dacs-pvc
        readOnly: true
EOF
}

create_validation_reader blobfuse-dacs-cold "$COLD_NODE" &&
create_validation_reader blobfuse-dacs-warm "$WARM_NODE" &&
kubectl wait pod/blobfuse-dacs-cold pod/blobfuse-dacs-warm \
  --namespace "$WORKLOAD_NAMESPACE" --for=condition=Ready --timeout=5m &&
kubectl get pods blobfuse-dacs-cold blobfuse-dacs-warm \
  --namespace "$WORKLOAD_NAMESPACE" --output wide

Conferma che entrambi i lettori siano pronti su nodi diversi. Non leggere ancora il file dal nodo warm.

Leggi e verifica l'intero file dal nodo freddo:

kubectl exec --namespace "$WORKLOAD_NAMESPACE" blobfuse-dacs-cold -- \
  sh -c 'set -eu; cd /mnt/blob; printf "%s  %s\n" "$1" "$2" | sha256sum --check' \
  sh "$EXPECTED_SHA256" "$VALIDATION_FILE"

Fermati se il controllo del checksum fallisce. Mantieni attivo il cold reader e usa le metriche del server di cache per confermare che la popolazione in background sia completa. Immediatamente prima della warm read, registra il valore di base del contatore dei download riusciti sui server di proprietà della tua Cache.

Leggi e verifica lo stesso file dal secondo nodo:

kubectl exec --namespace "$WORKLOAD_NAMESPACE" blobfuse-dacs-warm -- \
  sh -c 'set -eu; cd /mnt/blob; printf "%s  %s\n" "$1" "$2" | sha256sum --check' \
  sh "$EXPECTED_SHA256" "$VALIDATION_FILE"

Entrambi i controlli di checksum devono segnalare OK, e il contatore Download riuscito della Cache deve aumentare durante la seconda lettura. Checksum corrispondenti da soli non dimostrano il riutilizzo distribuito. Se il contatore non aumenta, segui le procedure di diagnostica alternative in Risolvere i problemi di integrazione invece di dichiarare il successo.

Ottimizza le prestazioni di lettura

Regola l'I/O delle applicazioni separatamente dalle impostazioni della cache di BlobFuse2:

Misura separatamente l'accesso sequenziale e quello casuale. Regolare insieme dimensione del blocco, prefetch e concorrenza monitorando throughput, memoria e traffico di origine.

Per le implementazioni colocalizzate, riservare CPU, memoria, larghezza di banda di rete e capacità disco locale sia per gli application worker che per i server di cache.

Applica le opzioni di montaggio modificate tramite un smontaggio e rimontaggio coordinati per tutti i pod che condividono il volume. Verifica le nuove opzioni nei log CSI.

Risultati standard dei benchmark di storage

I benchmark mettono a confronto BlobFuse2 da solo con DACS dedicati e co-locati su un account StorageV2 di livello caldo Standard_LRS. Ogni profilo copre cinque conteggi di thread per le tre configurazioni.

Scenari di distribuzione

• DACS dedicati: Gli application worker e i server cache DACS funzionano su pool di nodi separati.
• DACS co-locato: i worker dell'applicazione e i server di cache DACS condividono gli stessi nodi.

BlobFuse2 da solo fornisce la base di riferimento per entrambi gli scenari.

configurazione di test

Ogni caso utilizzava risorse dedicate di worker e cache. I risultati sono misurazioni aggregate, con il numero di thread riportato per worker.

Letture sequenziali

I test sequenziali utilizzano I/O da 16 MiB e cinque iterazioni di lettura per ogni caso. Il cold throughput è la prima iterazione. Il throughput a caldo e la baseline con il solo BlobFuse sono le medie delle iterazioni da 2 a 5. I valori sono complessivi GB/s.

Con 16 thread per worker, il throughput warm colocato era 84% superiore rispetto a BlobFuse-only e 10,9% superiore al throughput warm dedicato.

Risparmio stimato di larghezza di banda di origine

I dati di telemetria raccolti indicano una larghezza di banda media di origine Blob inferiore di circa il 70% per i DACS dedicati e colocati rispetto a solo con BlobFuse nei test sequenziali abbinati, inclusa la popolazione iniziale della cold cache.

Letture casuali 4 KiB

I test random utilizzano I/O da 4 KiB con -i 1 --rand --infloop e una durata di 300 secondi. Ogni caso riporta una misurazione aggregata di IOPS, incluso il popolamento della cache.

Entrambi gli scenari DACS raggiungono il picco di otto thread per worker. Il DACS colocato raggiunge 2.046 IOPS, ovvero 4,57 volte il risultato solo di BlobFuse allo stesso numero di thread.

Risolvere i problemi di integrazione

Per la risoluzione dei problemi con montaggio di storage, consulta Troubleshoot BlobFuse2 e la guida al debug dei driver CSI di Blob.

Identificare la cache locale o il fallback dell'origine

Un montaggio o una lettura riusciti non dimostrano che DACS stia fornendo dati:

• Se i log CSI segnalano BlobFuse2 distributed-cache support could not be verified, il driver rimuove le opzioni di cache distribuita e seleziona la cache a blocchi locale. Verifica la versione e le capacità di montaggio dell'host di BlobFuse2, poi coordina uno smontaggio e un rimontaggio.
• Se BlobFuse2 non scopre server cache, il mount può comunque avere successo e le letture vanno direttamente a gestione rete virtuale di Azure. Controlla il servizio di scoperta, l'indirizzo DNS, i punti finali e la connettività nodo-cache.

Trova il pod CSI che gira sul nodo lettore interessato e ispeziona il suo blob contenitore:

kubectl get pods --namespace "$WORKLOAD_NAMESPACE" --output wide
kubectl get pods --namespace kube-system \
  --selector app=csi-blob-node --output wide

CSI_POD="<csi-blob-node-pod-on-affected-reader-node>"
kubectl logs "$CSI_POD" --namespace kube-system --container blob --since=15m

I log dei container CSI non sono log host BlobFuse2. Sul nodo di carico di lavoro interessato, usa il tuo metodo di accesso approvato al nodo per ispezionare il journal di BlobFuse2:

journalctl --identifier=blobfuse2 --since "15 minutes ago" --no-pager

Se BlobFuse2 è configurato per scrivere invece in un file, ispezionare il suo percorso di log configurato. Dopo aver corretto il problema, coordina uno smontaggio e un rimontaggio per tutti i pod che condividono il volume, poi ripeti la verifica del percorso della cache.

Pulire il carico di lavoro di test

Elimina solo le risorse create per questo articolo. Arrestare i pod lettore prima di eliminare l'attestazione e il PV:

kubectl delete pod blobfuse-dacs-reader blobfuse-dacs-cold blobfuse-dacs-warm \
  --namespace "$WORKLOAD_NAMESPACE" --ignore-not-found
kubectl delete pvc blobfuse-dacs-pvc \
  --namespace "$WORKLOAD_NAMESPACE" --ignore-not-found
kubectl delete pv blobfuse-dacs-pv --ignore-not-found

Il criterio Retain preserva il contenitore e i BLOB. Non cancellare i dati applicativi esistenti o l'identità gestita. Rimuovere la credenziale federata, l'assegnazione dei ruoli o lo spazio dei nomi del carico di lavoro solo se è stato creato per questo test e nessun altro carico di lavoro ne ha bisogno.

Lascia abilitati il driver CSI Blob gestito e le risorse DACS condivise. Se DACS è stato abilitato solo per questa valutazione e nessun altro carico di lavoro lo richiede, seguire Rimuovere l'acceleratore distribuito per l'archiviazione cloud.

Passaggi successivi

• Gestisci un acceleratore distribuito per lo storage cloud.
• Monitorare un acceleratore distribuito per l'archiviazione cloud.
• Risoluzione dei problemi con acceleratore distribuito per lo storage cloud.