Mit BlobFuse2 einen verteilten Beschleuniger für Cloud-Speicher verteilen (Vorschau)

Verwenden Sie BlobFuse2 mit einem verteilten Beschleuniger für Cloud-Speicher (DACS), um Azure-Blob-Daten über Linux-Dateisystempfade zu lesen. Anwendungen behalten ihren bestehenden Dateilesecode, während BlobFuse2 zwischengespeicherte Daten über DACS bedient und fehlende Daten aus Blob Storage abruft.

Der Azure Blob Container Storage Interface (CSI)-Treiber bindet den Container über ein persistentes Volume (PV) und einen PersistentVolumeClaim (PVC) ein. Azure Blob Storage bleibt die dauerhafte maßgebliche Datenquelle.

Dieser Artikel behandelt Konfiguration, Lesepfadverifikation und Ergebnisse des Standardspeicher-Benchmarks.

Prerequisites

• Ein AKS-Cluster, der die Anforderungen der Azure-Region und der Kubernetes-Version im DACS-Quickstart erfüllt.
• Linux-Cache-Knoten mit lokalen NVMe-Festplatten, die für DACS dediziert sind.
• Ubuntu-Linux-Workload-Knoten für Anwendungspods, die BlobFuse2 mounten.
• Ein Azure Blob-Container, der Ihre Anwendungsdaten enthält.
• Eine bestehende, vom Benutzer zugewiesene verwaltete Identität für die Blob-Authentifizierung.
• Azure CLI und kubectl.
• Berechtigung, DACS und den verwalteten Azure Blob CSI-Treiber zu aktivieren, Kubernetes-Ressourcen zu erstellen, die föderierten Zugangsdaten der Identität zu verwalten und die erforderliche Blob-Datenzugriffsrolle zuzuweisen.
• BlobFuse2 2.5.6 oder höher, installiert auf jedem geeigneten Linux-Workload-Knoten. Für Unterstützung für verteilten Cache und Einschränkungen siehe die BlobFuse2 2.5.6 Release Notes.
• Ein vom AKS verwalteter Azure Blob CSI-Treiber ab Version v1.27.11, wobei der AKS OIDC-Aussteller und die Microsoft Entra Workload ID für die reine Tokenauthentifizierung aktiviert sein müssen.

Festlegen von Variablen

Führe die Befehle in derselben Bash-Sitzung aus. Ersetzen Sie die Platzhalter durch Ihren Cluster, Speichercontainer und bestehende, vom Benutzer zugewiesene verwaltete Identität:

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)

Installieren Sie einen verteilten Accelerator für Cloud-Speicher

Um DACS zu installieren, bereiten Sie dedizierte Cache-Festplatten vor, erstellen Sie eine Cache-Ressource und überprüfen Sie die Bereitschaft, siehe Get started with distributed accelerator for cloud storage on AKS.

Rufen Sie den Discovery-Hostnamen für Ihren einsatzbereiten Cache ab:

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

test -n "$CACHE_DISCOVERY_HOST"

Verwenden Sie den von Ihrer Cache-Ressource veröffentlichten Hostnamen und den dafür konfigurierten Port. Der Quickstart verwendet Port 9065.

Enable the Azure Blob CSI driver and verify BlobFuse2

Benutze den von AKS verwalteten Treiber. Folgen Sie Aktivieren des Azure Blob CSI-Treibers in AKS.

Nutze AKS, um CSI-Treiber-Upgrades zu verwalten. Stellen Sie sicher, dass auf jedem berechtigten Workload-Knoten BlobFuse2 2.5.6 oder höher ausgeführt wird, und koordinieren Sie Paketupdates mit Volume-Unmounts.

Überprüfen Sie den installierten Einhängeprozess

Überprüfen Sie die CSI-Bereitschaft über das Knoten-DaemonSet.

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}'

Bestätigen Sie, dass das blob Container-Image Version v1.27.11 oder später ist.

Die CSI-Treiber-Image-Version identifiziert die auf dem Host installierte BlobFuse2-Version nicht. Wählen Sie für jeden berechtigten Ubuntu-Knoten seinen csi-blob-node Pod aus der vorherigen Ausgabe aus und überprüfen Sie die vom CSI-Proxy verwendete Host-Binärdatei:

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

Bestätigen Sie Version 2.5.6 oder höher sowie die --distributed-cache-* Optionen, die in der Volume-Konfiguration verwendet werden, im folgenden Abschnitt.

Aktualisieren Sie BlobFuse2, wenn das Node-Image eine ältere Version hat

Wenn die Host-Binärdatei fehlt oder älter ist als 2.5.6, konfigurieren Sie den install-blobfuse-proxy Init-Container des verwalteten CSI-Treibers, um das erforderliche BlobFuse2-Paket zu installieren. Überspringe diesen Schritt, wenn alle berechtigten Knoten bereits Version 2.5.6 oder später haben.

Dieses Update verwendet den Paket-Installer auf Ubuntu-Knoten, die Zugriff auf die konfigurierten Ubuntu- und Microsoft-Paket-Repositorien benötigen. Es ersetzt nicht das verwaltete CSI-Treiber-Image und installiert auch keinen separaten Treiber.

Speichern Sie das aktuelle DaemonSet und erstellen Sie den 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

Der Merge-Patch aktualisiert den benannten Init-Container und die Umgebungseinträge, wobei sein Image und andere Einstellungen erhalten bleiben. Für die Paketauswahl-Steuerungen siehe den Blob CSI Proxy-Installer.

Nach dem Rollout listen Sie die CSI-Pods erneut auf und wiederholen Sie die Host-Binärverifizierung auf jedem geeigneten Workload-Knoten. Überprüfen Sie 2.5.6 oder höher sowie die Optionen für verteilten Cache, bevor Sie das Volume mounten. Bestehende BlobFuse2-Mount-Prozesse wechseln nicht die Version, wenn sich das Paket ändert; Mounts neu erstellen, um die aktualisierte Binärdatei zu verwenden.

Wenn der Rollout fehlschlägt, prüfen Sie die Installationsprotokolle für den betroffenen Pod:

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

AKS-Updates können das verwaltete DaemonSet abgleichen. Überprüfe nach CSI-Treiber- oder Node-Image-Upgrades erneut die Host-Binär- und Installer-Einstellungen. Sobald das Node-Image die erforderliche BlobFuse2-Version bereitgestellt hat, entferne im Rahmen dieses Upgrades die temporäre Paket-Version-Übersteuerung.

Blob-Authentifizierung konfigurieren

Verwenden Sie die föderierte AKS-Workload-Identität für die ausschließlich tokenbasierte Blobauthentifizierung. Die Volume-Konfiguration ermöglicht diesen Modus mit mountWithWorkloadIdentityToken: "true".

Befolgen Sie Enable OIDC and Microsoft Entra Workload ID und erstellen Sie dann das 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

Verknüpfen Sie den ServiceAccount mit Ihrer verwalteten Identität und gewähren Sie container-scoped Zugriff:

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"

Die Rollenzuweisung folgt der CSI-Token-only-Mount-Richtlinie. Lassen Sie es sich vor dem Test ausbreiten. Die Arbeitslast greift über die föderierte Identität und eine schreibgeschützte Einbindung auf Blob Storage zu.

Konfigurieren Sie ein schreibgeschütztes BlobFuse2-Volume

Rufen Sie die Cluster-DNS-Service-IP für den clusterlokalen Hostnamen des Caches ab:

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

test -n "$CLUSTER_DNS_IP"

Erlauben Sie Workload-Knoten, Cluster-DNS, die DACS-Endpunkte und Azure Blob Storage für Cache-Misses und Fallbacks zu erreichen.

Erstelle ein statisches PV und PVC für deinen bestehenden Container. Die Richtlinie Retain bewahrt die Daten, wenn die Anspruchsberechtigung aufgehoben wird:

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

Verwenden Sie einen eindeutigen PV-Namen und volumeHandle für jede Ausgabe. Die Deklaration 1Ti gibt den Kapazitätswert für die PV/PVC-Bindung an.

Konfigurieren Sie das Caching über die --distributed-cache-*Optionen. Die verteilte Cache-Komponente verwaltet ihre lokale Block-Cache-Schicht.

Das Beispiel weist 1.024 MiB dem lokalen Cache zu und holt 16 Blöcke vor. Planen Sie den Speicher separat für Anwendungspods, hostseitige BlobFuse2-Mounts und kolokierte DACS-Server ein.

Ein Volume in einen Workload einbinden

Setzen Sie DATA_FILE auf einen Dateipfad relativ zur Containerwurzel. Diese Python-Workload liest die ersten 4 MiB zweimal und vergleicht Prüfsummen:

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

Die Anwendung liest /mnt/blob/<path>. Der Node Selector weist sie einem Pool mit der verifizierten BlobFuse2-Installation zu.

Überprüfen Sie den DACS-Lesepfad

Konfigurieren Sie das Scraping für jeden Cache-Server-Pod, indem Sie Verteilten Beschleuniger für Cloud-Speicher überwachen folgen.

1. Bestätigen Sie, dass das PVC mit dem PV verbunden ist und dass die Einbindung die erwarteten Discovery-, DNS- und Read-only-Optionen verwendet.
2. Überprüfen Sie die CSI- und BlobFuse2-Protokolle für die installierte Version und die Verbindungen zu den erwarteten Cache-Servern.
3. Trage eine Basislinie für cache_server_request_counter{request_type="Download",status="Success"} auf, nur über die Server-Pods aggregiert, die deinem Cache gehören.
4. Lassen Sie die Hintergrundbefüllung abschließen und wiederholen Sie dann die Lesevorgänge über Workload-Knoten hinweg. Korrelieren Sie erfolgreiche Server-Download-Aktivitäten mit BlobFuse2-Logs und Blob-Telemetrie, um verteilte Wiederverwendung zu bestätigen.

Verwenden Sie Prüfsummen zur Überprüfung der Datenintegrität und Anforderungszähler zur Überprüfung des Cache-Pfads. Für detaillierte Befehle siehe Überprüfen des DACS-Anforderungspfads.

Überprüfen Sie die Wiederverwendung über zwei Knoten hinweg

Die einführende Workload liest zweimal von einem Knoten, die ihren lokalen Cache wiederverwenden kann. Um die verteilte Wiederverwendung zu überprüfen, verwenden Sie zwei einsatzbereite Knoten aus dem verifizierten Workload-Pool und eine Testdatei, die nicht über diesen Cache gelesen wurde. Wählen Sie eine Datei, die klein genug ist, um in den Cache zu passen, und beziehen Sie den erwarteten SHA-256-Wert von der Originalquelle oder aus einem vertrauenswürdigen Manifest.

Verwenden Sie einen eigenen Cache für diesen Test, damit andere, nicht zugehörige Workloads seine Anfragezähler nicht beeinflussen.

Liste geeignete Knoten auf und setze dann die Hostname-Labels, den Dateipfad relativ zur Containerwurzel und dessen erwartete Prüfsumme:

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>"

Erstellen Sie zwei Leser, die ihre Mounts aktiv halten, während Sie die Prüfungen durchführen und auf die Befüllung im Hintergrund warten:

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

Bestätigen Sie, dass beide Lesegeräte auf verschiedenen Knoten bereit sind. Lesen Sie die Datei vom Warm Node noch nicht.

Lesen und überprüfen Sie die gesamte Datei vom Cold Node:

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"

Hören Sie auf, wenn die Kontrollsummenprüfung fehlschlägt. Lass den Cold-Reader laufen und verwende die Cache-Server-Metriken, um zu bestätigen, dass die Befüllung im Hintergrund vollständig ist. Unmittelbar vor dem Warm-Read notieren Sie den Basiswert des erfolgreichen Download-Zählers auf den Servern, die Ihrem Cache gehören.

Lesen und überprüfen Sie die gleiche Datei auf dem zweiten Knoten:

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"

Beide Prüfsummenprüfungen müssen OK melden, und der erfolgreiche Download-Zähler des Caches muss beim zweiten Lesen steigen. Allein das Abgleichen von Prüfsummen beweist keine verteilte Wiederverwendung. Wenn der Zähler nicht steigt, folgen Sie den alternativen Diagnoseschritten in Fehlerbehebung der Integration, anstatt von Erfolg auszugehen.

Leseleistung optimieren

Optimieren Sie die Anwendungs-I/O separat von den BlobFuse2-Cache-Einstellungen:

Messen Sie sequentiellen und wahlfreien Zugriff getrennt. Blockgröße, Prefetch und Nebenläufigkeit gleichzeitig anpassen, während Sie Durchsatz, Speicher und Ursprungsverkehr überwachen.

Für Colocation-Bereitstellungen werden CPU-, Speicher-, Netzwerkbandbreite und lokale Festplattenkapazität sowohl für Anwendungs-Worker als auch für Cache-Server reserviert.

Wenden Sie die geänderten Mount-Optionen durch ein koordiniertes Aushängen und erneutes Einhängen für alle Pods an, die das Volumen teilen. Überprüfen Sie die neuen Optionen in den CSI-Protokollen.

Standard-Speicher-Benchmark-Ergebnisse

Die Benchmarks vergleichen BlobFuse2 allein mit dedizierten und kolokalisierten DACS auf einem Standard_LRS, Hot-tier StorageV2-Konto. Jedes Profil deckt fünf Thread-Größen über die drei Konfigurationen hinweg ab.

Bereitstellungsszenarien

• Dedizierte DACS: Anwendungs-Worker und DACS-Cache-Server laufen auf separaten Knotenpools.
• Ko-lokalisierte DACS: Anwendungs-Worker und DACS-Cacheserver teilen sich dieselben Knoten.

Allein BlobFuse2 liefert die Grundlage für beide Szenarien.

Testkonfiguration

Jeder Fall nutzte frische Worker- und Cache-Ressourcen. Die Ergebnisse sind aggregierte Messungen, wobei die Thread-Anzahl pro Worker gemeldet wird.

Sequenzielle Lesevorgänge

Sequentielle Tests verwenden 16-MiB I/O und fünf Leseiterationen pro Fall. Cold Throughput ist die erste Iteration. Warmdurchsatz und die BlobFuse-Only-Baseline sind die Durchschnittswerte der Iterationen 2 bis 5. Werte sind aggregierte GB/s.

Mit 16 Threads pro Arbeiter lag der Warmdurchsatz bei Kolokation 84 % höher als bei BlobFuse-only und 10,9 % höher als der dedizierte warme Durchsatz.

Geschätzte Ursprungsbandbreiteneinsparungen

Die erfassten Telemetriedaten zeigen etwa 70 % niedrigere durchschnittliche vom Blob-Ursprung stammende Bandbreite für dedizierte und colokierte DACS im Vergleich zu BlobFuse-only in den abgestimmten sequenziellen Tests, einschließlich der initialen Cold-Cache-Population.

Zufällige 4-KiB-Lesevorgänge

Zufällige Tests verwenden 4-KiB I/O mit -i 1 --rand --infloop und eine 300-Sekunden-Laufzeit. Jeder Fall weist eine aggregierte IOPS-Messung aus, einschließlich Cache-Population.

Beide DACS-Szenarien erreichen ihren Höhepunkt bei acht Threads pro Worker. Kolokalisierte DACS erreichen 2.046 IOPS, also das 4,57-fache des BlobFuse-only-Ergebnisses bei derselben Threadanzahl.

Fehler bei der Integration beheben

Für Storage-Mount-Fehlerbehebung, siehe Troubleshoot BlobFuse2 und den Blob CSI-Treiber-Debugging-Leitfaden.

Lokal-Cache oder Ursprungs-Fallback identifizieren

Ein erfolgreiches Mounten oder Lesen beweist nicht, dass DACS Daten bereitstellt:

• Wenn CSI-Protokolle melden BlobFuse2 distributed-cache support could not be verified, entfernt der Treiber die Distributed-Cache-Optionen und wählt den lokalen Blockcache. Überprüfe die Host-Version von BlobFuse2 und die Mount-Fähigkeiten, koordiniere dann ein Unmount und Remount.
• Wenn BlobFuse2 keine Cache-Server entdeckt, kann das Einbinden trotzdem erfolgreich sein, und Lesevorgänge erfolgen direkt aus Blob Storage. Überprüfen Sie den Discovery-Service, die DNS-Adresse, Endpunkte und die Verbindung zwischen Knoten und Cache.

Suche den CSI-Pod, der auf dem betroffenen Reader-Knoten läuft, und überprüfe seinen blob-Container:

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

CSI-Container-Logs sind keine Host-BlobFuse2-Logs. Auf dem betroffenen Arbeitslastknoten verwenden Sie Ihre genehmigte Node-Zugriffsmethode, um das Journal von BlobFuse2 zu inspizieren:

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

Wenn BlobFuse2 so konfiguriert ist, dass er stattdessen in eine Datei schreibt, inspizieren Sie den konfigurierten Logpfad. Nach Behebung des Problems koordinieren Sie ein Unmount- und Remount-System für alle Pods, die das Volumen teilen, und wiederholen Sie dann die Cache-Path-Verifikation.

Bereinigen Sie den Test-Workload

Löschen Sie nur Ressourcen, die für diesen Artikel erstellt wurden. Stoppt die Lesepods, bevor ihr den Claim und den PV löscht:

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

Die Richtlinie Retain schützt deinen Container und deine Blobs. Lösche keine bestehenden Anwendungsdaten oder die verwaltete Identität. Entfernen Sie die Verbundanmeldeinformationen, Rollenzuweisung oder den Workload-Namensraum nur, wenn Sie sie ausschließlich für diesen Test erstellt haben und keine andere Arbeitslast sie benötigt.

Lassen Sie den verwalteten Blob-CSI-Treiber und die gemeinsamen DACS-Ressourcen aktiviert. Wenn DACS nur für diese Bewertung aktiviert ist und keine andere Arbeitslast es benötigt, folge Verteilten Beschleuniger für Cloud-Speicher entfernen.

Nächste Schritte

• Verwalten Sie den verteilten Accelerator für Cloud-Speicher.
• Überwachen Sie den verteilten Accelerator für Cloud-Speicher.
• Fehlerbehebung eines verteilten Beschleunigers für Cloud-Speicher.