Hochleistungs-Blockspeicher aktivieren

Google Distributed Cloud (GDC) mit Air Gap bietet eine leistungsstarke Speicherebene, die für anspruchsvolle Arbeitslasten entwickelt wurde. Diese Stufe bietet eine Leistungsskalierung von bis zu 30 IOPS pro GB, was eine Steigerung gegenüber der Standard-Blockspeicherstufe mit bis zu 3 IOPS pro GB darstellt. In diesem Dokument wird beschrieben, wie Sie leistungsstarken Blockspeicher aktivieren und die zugehörigen Messwerte, Benachrichtigungen und Abrechnungsdetails überwachen. Sie richtet sich an Zielgruppen in der Gruppe der Plattformadministratoren (z. B. IT-Administratoren) oder der Gruppe der Anwendungsoperatoren (z. B. Anwendungsentwickler).

Die Hochleistungsspeicherklasse performance-rwo ist für den Kubernetes-Cluster verfügbar.

Mit der Einführung der leistungsstarken SKU ähnelt der Prozess für Volume-Snapshots und das Wiederherstellen von Volumes mit performance-*-Speicherklassen dem Prozess für standard-*-Speicherklassen. Sie können einen Volume-Snapshot erstellen und einen ähnlichen PVC ohne Änderungen an der Speicherklasse oder den zugrunde liegenden QoS-Werten (Quality of Standard) wiederherstellen. Die performance volumesnapshotclass erfasst den Typ des Volumes. Mit dieser volumesnapshot können Sie das Volume mit derselben Speicherklasse wiederherstellen.

Hinweise

Bevor Sie beginnen, sollten Sie prüfen, ob die folgenden Voraussetzungen erfüllt sind:

GDC-Umgebung und ‑Version
- Eine aktive GDC-Instanz, die auf Version 1.15.1 oder höher aktualisiert wurde.
Projekt
- Ein GDC-Projekt in einer Organisation, in dem Sie leistungsstarke Volumes bereitstellen möchten.
Zugriff und Berechtigungen
- Ausreichende Kubernetes-Berechtigungen zum Erstellen, Verwalten und Verwenden von PersistentVolumeClaim-Ressourcen (PVC) für Containerarbeitslasten oder VirtualMachineDisk-Ressourcen für virtuelle Maschinen im Zielprojekt-Namespace. Häufig benötigte Rollen sind:
  - project-vm-admin zum Verwalten von VMs und VM-Laufwerken.
  - Rollen, die die Verwaltung von persistenten Volumes ermöglichen und häufig in Bearbeitungs- oder benutzerdefinierten Rollen enthalten sind.
  - Für einen Endnutzer sind in der Regel keine speziellen Rollen auf Organisationsebene erforderlich, um den Speicher zu nutzen, wenn die leistungsstarken Speicherklassen bereits im Cluster des Projekts verfügbar sind. Die Einrichtung und Bereitstellung dieser Klassen liegt in der Verantwortung des Infrastructure Operator (IO) oder des PA.
Informationen zu Speicherklassen
- Sie sind mit dem Konzept von Kubernetes-StorageClass-Objekten vertraut. Leistungsstarke Stufen sind über bestimmte Speicherklassen verfügbar.
- Sie müssen beim Erstellen eines PVC oder einer VM-Festplatte eine leistungsstarke Speicherklasse angeben.
Kapazität und Kontingente
- Prüfen Sie, ob für die Organisation und das Projekt ausreichend Speicherkontingente für die leistungsstarke Stufe zugewiesen sind.
- Achten Sie auf Kapazitätsbeschränkungen oder Leistungsgrenzen für die jeweilige GDC-Umgebung und ‑Hardware.

Wenden Sie `subcomponentOverride` auf die erforderlichen Cluster an.

Standardmäßig ist FeatureGate für die leistungsstarke SKU auf State: TEST festgelegt. Damit performance-*-Speicherklassen aktiviert werden können, muss der Plattformadministrator (PA) oder Anwendungsoperator (AO) eine subcomponentOverride auf die erforderlichen Cluster mit einem höheren FileHighPerformanceStorageClassStage-Wert als dem Standardwert value anwenden. Im folgenden Beispiel wird der höhere Wert von production verwendet.

apiVersion: lcm.private.gdc.goog/v1
kind: SubcomponentOverride
metadata:
  name: file-common
  namespace: NAMESPACE
spec:
  features:
    operableParameters:
      FileHighPerformanceStorageClassStage: production
  subComponentRef: file-common

Der Namespace in SubcomponentOverride gibt den Clusternamespace (z. B. cluster-1) an, in dem das Flag festgelegt wird. Ersetzen Sie NAMESPACE durch die entsprechenden Namespaces der Cluster und erstellen Sie die SubcomponentOverride-Dateien. Wenden Sie diese Änderung mit dem folgenden Befehl an:

kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG_PATH apply -f SUBOVERRIDE_USER_FILE

Ersetzen Sie Folgendes:

MANAGEMENT_API_SERVER_KUBECONFIG_PATH: der Pfad zur kubeconfig-Datei des Management API-Serverclusters.
SUBOVERRIDE_USER_FILE: Der Pfad zur SubcomponentOverride-YAML-Datei für den Kubernetes-Cluster.

Wenn Sie die Hochleistungs-SKU für Kubernetes-Cluster aktivieren möchten, wenden Sie subcomponentOverride auf den Management API-Servercluster an.

Leistungsmesswerte und Benachrichtigungen überwachen

Hochleistungsspeicher umfasst auch zusätzliche Messwerte wie QOSPolicy-Details. Mit dieser Funktion können Messwerte basierend auf dem QOSPolicy in ONTAP gefiltert und aggregiert werden. So lassen sich leistungsstarke Volumes von Standard-Volumes unterscheiden.

Messwerte beobachten

Die folgenden leistungsstarken Messwerte sind für den File Observability Stack verfügbar:

metering_storage_allocated_capacity_bytes
metering_storage_used_capacity_bytes

Beide Messwerte wurden mit qos_policy-Informationen aus ONTAP angereichert.

Dashboards beobachten

Aufbauend auf den vorherigen Verbesserungen bei den Messwerten sind Benachrichtigungen sowohl für Standard- als auch für Hochleistungsspeicher verfügbar. So können Sie die Leistungsklasse gezielt überwachen und Probleme schneller erkennen. Zur Visualisierung dieser Daten stehen leistungsstarke Dashboards zur Verfügung, die die angereicherten Messwerte verwenden, um Einblicke in die Leistung und Nutzung von Hochleistungsvolumes zu geben.

Wenn Sie sich diese Dashboards ansehen möchten, rufen Sie Grafana auf und gehen Sie zu Dashboards> FILE and Dashboards> FILE/ONTAP.

Die folgenden leistungsstarken Dashboards sind verfügbar:

Dashboard „Leistungsbalance für Blockspeicher für Organisationsdateien“
Die FILE/ONTAP-Dashboards sind Dashboards, in denen Harvest-Daten erfasst werden. So können Sie die ONTAP-Leistung direkt in Grafana überwachen.

Hinweise beachten

Neben den Messwerten und Dashboards sind auch Benachrichtigungen zu hoher Leistung verfügbar. Diese Benachrichtigungen helfen, Probleme im Speicher zu erkennen, und verweisen Nutzer auf die Runbooks mit Anleitungen zur Behebung der Benachrichtigungen. Wenn eine Benachrichtigung ausgelöst wird, enthält sie einen Runbook-Code, der im Servicehandbuch aufgerufen werden kann. PAs sollten diese Runbooks verwenden, um die Benachrichtigung zu beheben. Diese Benachrichtigungen können in Grafana im Bereich Alert Rules (Benachrichtigungsregeln) unter infra-obs > file-block-storage-perf-monitoring-rules (Regeln für die Leistungsüberwachung von Dateiblockspeicher) aufgerufen werden.

Die folgenden leistungsstarken Benachrichtigungen sind verfügbar:

Mit fb_high_org_volume_latency und fb_high_org_avg_volume_latency können Sie die durchschnittliche Lautstärkenlatenz in einer Organisation bzw. für einzelne Nutzer verfolgen.
fb_storage_node_too_busy, um die CPU-Auslastung eines Knotens zu verfolgen und Benachrichtigungen zu erhalten, wenn die CPU-Auslastung zu hoch ist.
fb_current_ops_higher_than_expected, um eine Benachrichtigung zu erhalten, wenn die Anzahl der Vorgänge auf einem aktuellen Knoten höher als erwartet ist.

Abrechnung für Hochleistungs-Computing abfragen

Die SKU für leistungsstarken Blockspeicher ist C008-4FF2-45E7. Die Abrechnung für diese SKU erfolgt mit der folgenden Prometheus-Abfrage:


sum_over_time(metering_storage_allocated_capacity_bytes{sku_id='c008-4ff2-45e7'}[{{.RangeHalfOpen}}:1m]) / 2^30 / 60 / {{.Hours}}

Bei Verwendung von metering_storage_allocated_capacity_bytes erfolgt die Abrechnung auf Grundlage der zugewiesenen Byte und nicht der tatsächlich verwendeten Byte.

Die Speicherklasse und die QoS-Richtlinie für Volumes werden bei der ersten Bereitstellung festgelegt. Da die QoS-Richtlinie eine Variable ist, die direkt in ONTAP geändert werden kann, legen wir sku_id in Messwerten basierend auf qos_policy fest und rechnen dann nach sku_id ab.

Beispiel-Workflows

Sie können die leistungsstarke SKU in Ihren Workflows über verschiedene Arten von Volumendeklarationen verwenden. Der zugrunde liegende Mechanismus bleibt jedoch derselbe, z. B. eine PVC, die von performance-* unterstützt wird. Die folgenden Beispiele zeigen die verschiedenen Möglichkeiten, ein neues Volumen-Tier zu erstellen.

Wenden Sie die folgenden YAML-Konfigurationen auf den entsprechenden Cluster an, indem Sie auf den korrekten Namen der StorageClass performance-* verweisen.

Leistungsstarke PVCs und Pod-Mounts:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: PVC_NAME
spec:
  storageClassName: performance-rwo
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

---

apiVersion: v1
kind: Pod
metadata:
  name: POD_NAME
spec:
  volumes:
    - name: VOLUME_NAME
      persistentVolumeClaim:
        claimName: PVC_NAME
  containers:
    - name: CONTAINER_NAME
      image: gcr.io/GKE_RELEASE/asm/proxyv2:1.23.6-asm.14
      ports:
        - containerPort: 80
      volumeMounts:
        - name: VOLUME_NAME
          mountPath: "/data"

Leistungsstarke VM-Laufwerke und VMs:

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: BOOT_DISK_NAME
  namespace: NAMESPACE
spec:
  source:
    image:
      name: ubuntu-24.04-v20250809-gdch
      namespace: vm-system
  size: 25Gi
  type: Performance

---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: DATA_DISK_NAME
  namespace: NAMESPACE
spec:
  size: 2Gi
  type: Performance
---

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
  namespace: NAMESPACE
spec:
  compute:
    virtualMachineType: n3-standard-2-gdc
  disks:
  - virtualMachineDiskRef:
      name: BOOT_DISK_NAME
    boot: true
    autoDelete: true
  - virtualMachineDiskRef:
      name: DATA_DISK_NAME
    autoDelete: true

Hochleistungs-Volume-Snapshots und ‑Wiederherstellungen:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: SOURCE_PVC_NAME
spec:
  storageClassName: performance-rwo
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: VOLUME_SNAPSHOT_NAME
  namespace: NAMESPACE
spec:
  volumeSnapshotClassName: performance
  source:
    persistentVolumeClaimName: SOURCE_PVC_NAME

---


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: RESTORED_PVC_NAME
  namespace: NAMESPACE
spec:
  dataSource:
    name: VOLUME_SNAPSHOT_NAME
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  storageClassName: performance-rwo
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5i