Azure Operator Nexus-Speicherappliance

Artikel
10/30/2024

Azure Operator Nexus basiert auf grundlegenden Konstrukten wie Computeservern, Speicherappliances und Netzwerk-Fabric-Geräten. Azure Operator Nexus-Speicherappliances stellen persistente Speicherappliances auf dem Rack dar.

Jede Speicherappliance enthält mehrere Speichergeräte, die aggregiert werden, um einen einzelnen Speicherpool bereitzustellen. Dieser Speicherpool wird dann in mehrere Volumes geschnitzt, die den Computeservern als Blockspeichergeräte angezeigt werden. Die Computeserver können diese Blockspeichergeräte als beständigen Speicher für ihre Workloads verwenden. Jeder Azure Operator Nexus-Cluster wird mit einer einzigen Speicherappliance bereitgestellt, die für alle Mandantenworkloads freigegeben ist.

Die Speicherappliance in einer Azure Operator Nexus-Instanz wird als Azure-Ressource dargestellt. Operatoren können die Attribute wie bei jeder anderen Azure-Ressource einsehen.

Kubernetes-Speicherklassen

Der Software-Kubernetes-Stack von Azure Operator Nexus bietet zwei Arten von Speicher. Operatoren wählen sie über den Kubernetes StorageClass-Mechanismus aus.

Wichtig

Azure Operator Nexus unterstützt keine kurzlebigen Volumes. Nexus empfiehlt, dass die in diesem Dokument beschriebenen Speichermechanismen für persistente Volumes für alle Workloadvolumes verwendet werden, da diese die höchsten Leistungs- und Verfügbarkeitsstufen bieten. Der gesamte Speicher in Azure Operator Nexus wird von der Speicher-Appliance bereitgestellt. Es gibt keine Unterstützung für Speicher, der von Bare-Metal-Computerdatenträgern bereitgestellt wird.

StorageClass: Nexus-Volume

Der Standardspeichermechanismus – Nexus-Volume – ist die bevorzugte Wahl für die meisten benutzenden Personen. Sie bietet ein Höchstmaß an Leistung und Verfügbarkeit. Volumes können jedoch nicht gleichzeitig für mehrere Arbeitsknoten freigegeben werden. Operatoren können über die Volumeressource über die Azure-API und das Portal auf diese Volumes zugreifen und diese verwalten.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: testPvc
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 107Mi
  storageClassName: nexus-volume
  volumeMode: Block
  volumeName: testVolume
status:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 107Mi
  phase: Bound

StorageClass: nexus-shared

In Situationen, in denen ein freigegebenes Dateisystem erforderlich ist, ist die nexus-shared-Speicherklasse verfügbar. Diese Speicherklasse bietet eine freigegebene Speicherlösung mit Hochverfügbarkeit, indem mehrere Pods im selben Nexus-Kubernetes-Cluster gleichzeitig auf dasselbe Volume zugreifen und dieses nutzen können. Die nexus-shared-Speicherklasse verwendet einen NFS-Speicherdienst mit Hochverfügbarkeit. Dieser NFS-Speicherdienst (Speicherpool ist derzeit auf eine maximale Größe von 1 TiB beschränkt) ist pro CSN (Cloud Service Network) verfügbar. Der NFS-Speicherdienst wird automatisch beim Erstellen einer CSN-Ressource bereitgestellt. Jeder Nexus-Kubernetes-Cluster, der an das CSN angefügt ist, kann persistente Volumes aus diesem freigegebenen Speicherpool bereitstellen. Nexus-shared unterstützt die beiden Zugriffsmodi „Read Write Once (RWO)“ und „Read Write Many (RWX)“. Das bedeutet, dass Workloadanwendungen einen dieser beiden Zugriffsmodi für den Zugriff auf den freigegebenen Speicher nutzen können.

Diagramm der Bereitstellung eines Volumes für eine Workload in Nexus Kubernetes Cluster durch nexus-shared

Abbildung: Nexus Shared Volume

Obwohl die Leistung und Verfügbarkeit von nexus-shared für die meisten Anwendungen ausreichend sind, empfehlen wir, dass Workloads mit hohen E/A-Anforderungen die Option nexus-volume verwenden, um eine optimale Leistung zu erzielen.

Read Write Once (RWO)

Im RWO-Modus (Read Write Once) kann jeweils nur ein Knoten oder Anforderer das nexus-shared-Volume einbinden. Im ReadWriteOnce-Zugriffsmodus können immer noch mehrere Pods auf das Volume zugreifen, wenn die Pods auf demselben Knoten ausgeführt werden.

apiVersion: v1
items:
- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: test-pvc
    namespace: default
  spec:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 5Gi
    storageClassName: nexus-shared
    volumeMode: Filesystem
    volumeName: TestVolume
  status:
    accessModes:
    - ReadWriteOnce
    capacity:
      storage: 5Gi
    phase: Bound

Read Write Many (RWX)

Im RWX-Modus (Read Write Many) können mehrere Knoten oder Anforderer das nexus-shared-Volume gleichzeitig einbinden.

apiVersion: v1
items:
- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: test-pvc
    namespace: default
  spec:
    accessModes:
    - ReadWriteMany
    resources:
      requests:
        storage: 5Gi
    storageClassName: nexus-shared
    volumeMode: Filesystem
    volumeName: TestVolume
  status:
    accessModes:
    - ReadWriteMany
    capacity:
      storage: 5Gi
    phase: Bound

Beispiele

Read Write Once (RWO) mit der Speicherklasse „nexus-volume“

Mit diesem Beispielmanifest wird ein StatefulSet mit PersistentVolumeClaimTemplate unter Verwendung der nexus-volume-Speicherklasse im ReadWriteOnce-Modus erstellt.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: test-sts-rwo
  labels:
    app: test-sts-rwo
spec:
  serviceName: test-sts-rwo-svc
  replicas: 3
  selector:
    matchLabels:
      app: test-sts-rwo
  template:
    metadata:
      labels:
        app: test-sts-rwo
    spec:
      containers:
      - name: busybox
        command:
        - "/bin/sh"
        - "-c"
        - while true; do echo "$(date) -- $(hostname)" >> /mnt/hostname.txt; sleep 1; done
        image: busybox
        volumeMounts:
        - name: test-volume-rwo
          mountPath: /mnt/
  volumeClaimTemplates:
    - metadata:
        name: test-volume-rwo
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi
        storageClassName: nexus-volume

Für jeden Pod des StatefulSets wird ein PersistentVolumeClaim erstellt.

# kubectl get pvc
NAME                             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-volume-rwo-test-sts-rwo-0   Bound    pvc-e41fec47-cc43-4cd5-8547-5a4457cbdced   10Gi       RWO            nexus-volume   8m17s
test-volume-rwo-test-sts-rwo-1   Bound    pvc-1589dc79-59d2-4a1d-8043-b6a883b7881d   10Gi       RWO            nexus-volume   7m58s
test-volume-rwo-test-sts-rwo-2   Bound    pvc-82e3beac-fe67-4676-9c61-e982022d443f   10Gi       RWO            nexus-volume   12s

# kubectl get pods -o wide -w
NAME             READY   STATUS    RESTARTS   AGE     IP              NODE                                         NOMINATED NODE   READINESS GATES
test-sts-rwo-0   1/1     Running   0          8m31s   10.245.231.74   nexus-cluster-6a8c4018-agentpool2-md-vhhv6   <none>           <none>
test-sts-rwo-1   1/1     Running   0          8m12s   10.245.126.73   nexus-cluster-6a8c4018-agentpool1-md-27nw4   <none>           <none>
test-sts-rwo-2   1/1     Running   0          26s     10.245.183.9    nexus-cluster-6a8c4018-agentpool1-md-4jprt   <none>           <none>

# kubectl exec test-sts-rwo-0 -- cat /mnt/hostname.txt
Thu Nov  9 21:57:25 UTC 2023 -- test-sts-rwo-0
Thu Nov  9 21:57:26 UTC 2023 -- test-sts-rwo-0
Thu Nov  9 21:57:27 UTC 2023 -- test-sts-rwo-0

# kubectl exec test-sts-rwo-1 -- cat /mnt/hostname.txt
Thu Nov  9 21:57:19 UTC 2023 -- test-sts-rwo-1
Thu Nov  9 21:57:20 UTC 2023 -- test-sts-rwo-1
Thu Nov  9 21:57:21 UTC 2023 -- test-sts-rwo-1

# kubectl exec test-sts-rwo-s -- cat /mnt/hostname.txt
Thu Nov  9 21:58:32 UTC 2023 -- test-sts-rwo-2
Thu Nov  9 21:58:33 UTC 2023 -- test-sts-rwo-2
Thu Nov  9 21:58:34 UTC 2023 -- test-sts-rwo-2

Read Write Many (RWX) mit „nexus-shared“-Speicherklasse

Das folgende Manifest erstellt eine Bereitstellung mit PersistentVolumeClaim (PVC) unter Verwendung der Speicherklasse nexus-volume im ReadWriteMany-Modus. Der erstellte PVC wird von allen Pods der Bereitstellung gemeinsam genutzt und kann von allen gleichzeitig zum Lesen und Schreiben verwendet werden.

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-volume-rwx
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 3Gi
  storageClassName: nexus-shared
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: test-deploy-rwx
  name: test-deploy-rwx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: test-deploy-rwx
  template:
    metadata:
      labels:
        app: test-deploy-rwx
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: kubernetes.azure.com/agentpool
                operator: Exists
                values: []
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: busybox
        command:
        - "/bin/sh"
        - "-c"
        - while true; do echo "$(date) -- $(hostname)" >> /mnt/hostname.txt; sleep 1; done
        image: busybox
        volumeMounts:
        - name: test-volume-rwx
          mountPath: /mnt/
      volumes:
      - name: test-volume-rwx
        persistentVolumeClaim:
          claimName: test-volume-rwx
...

Nach der Anwendung gibt es drei Replikate der Bereitstellung, die sich denselben PVC gemeinsam verwenden.

# kubectl get pvc
NAME                             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-volume-rwx                  Bound    pvc-32f0717e-6b63-4d64-a458-5be4ffe21d37   3Gi        RWX            nexus-shared   6s

# kubectl get pods -o wide -w
NAME                             READY   STATUS    RESTARTS   AGE     IP               NODE                                         NOMINATED NODE   READINESS GATES
test-deploy-rwx-fdb8f49c-86pv4   1/1     Running   0          18s     10.245.224.140   nexus-cluster-6a8c4018-agentpool1-md-s2dh7   <none>           <none>
test-deploy-rwx-fdb8f49c-9zsjf   1/1     Running   0          18s     10.245.126.74    nexus-cluster-6a8c4018-agentpool1-md-27nw4   <none>           <none>
test-deploy-rwx-fdb8f49c-wdgw7   1/1     Running   0          18s     10.245.231.75    nexus-cluster-6a8c4018-agentpool2-md-vhhv6   <none>           <none>

Aus der nachstehenden Ausgabe ist ersichtlich, dass alle Pods in denselben PVC schreiben.

# kubectl exec test-deploy-rwx-fdb8f49c-86pv4 -- cat /mnt/hostname.txt
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-86pv4
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-9zsjf
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-wdgw7
Thu Nov  9 21:51:42 UTC 2023 -- test-deploy-rwx-fdb8f49c-86pv4

# kubectl exec test-deploy-rwx-fdb8f49c-9zsjf -- cat /mnt/hostname.txt
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-86pv4
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-9zsjf
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-wdgw7
Thu Nov  9 21:51:42 UTC 2023 -- test-deploy-rwx-fdb8f49c-86pv4

# kubectl exec test-deploy-rwx-fdb8f49c-wdgw7 -- cat /mnt/hostname.txt
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-86pv4
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-9zsjf
Thu Nov  9 21:51:41 UTC 2023 -- test-deploy-rwx-fdb8f49c-wdgw7
Thu Nov  9 21:51:42 UTC 2023 -- test-deploy-rwx-fdb8f49c-86pv4

Volumengrößenbeschränkungen und Kapazitätsverwaltung

Für alle PVCs, die mit „nexus-volume“ und „nexus-shared“ erstellt wurden, gilt eine minimale und maximale Anspruchsgröße.

Speicherklasse	Minimale PVC-Größe	Maximale PVC-Größe
nexus-volume	1 MiB	12 TiB
nexus-shared	Keine	1 TiB

Wichtig

Volumes, die ihr Verbrauchslimit erreichen, führen zum Fehler „Nicht genügend Speicherplatz“ für die Workloads, die sie verbrauchen. Sie müssen sicherstellen, dass Sie geeignete Volumengrößen für Ihre Workloadanforderungen bereitstellen. Sie müssen sowohl die Speicherappliance als auch alle NFS-Server auf ihren prozentualen Speicherverbrauch überwachen. Dazu können Sie die Metriken verwenden, die in der Liste der verfügbaren Metriken dokumentiert sind.

Sowohl für nexus-volume- als auch für nexus-shared-PVCs wird die angeforderte Speicherkapazität als Verbrauchsgrenzwert erzwungen. Ein Volume kann nicht mehr Speicher verbrauchen als die zugeordnete PVC-Anforderung.
Alle physischen Volumes verfügen über eine schlanke Speicherzuweisung. Sie müssen den gesamten Speicherverbrauch auf Ihrer Speicherappliance überwachen und bei Bedarf Wartungsvorgänge durchführen, um Speicherplatz freizugeben.
Eine Bereitstellungsanforderung für einen nexus-volume-PVC führt zu einem Fehler, wenn die angeforderte Größe niedriger als die minimale oder höher als die maximale unterstützte Volumengröße ist.
nexus-shared-Volumes werden auf dem zugrunde liegenden NFS-Server logisch mit einer schlanken Speicherzuweisung bereitgestellt. Dieser NFS-Server verfügt über eine feste Kapazität von 1 TiB.
- Ein nexus-shared-PVC kann auch dann bereitgestellt werden, wenn mehr als 1 TiB Speicher angefordert wird, er kann aber nur 1 TiB verbrauchen.
- Es ist möglich, mehrere PVCs bereitzustellen, bei denen die Summe der Kapazitätsanforderungen größer als 1 TiB ist. Der Verbrauchsgrenzwert von 1 TiB gilt jedoch trotzdem. Die zugeordneten PVs dürfen nicht mehr als 1 TiB Speicher verbrauchen.

Status der Speicherappliance

Die folgenden Eigenschaften spiegeln den Betriebszustand einer Speicherappliance wider:

Status gibt den Zustand an, der von der Speicherappliance abgeleitet wurde. Der Zustand kann Available, Error oder Provisioning sein.
Provisioning State gibt den aktuellen Bereitstellungsstatus der Speicherappliance. Der Bereitstellungsstatus kann Succeeded, Failed oder InProgress sein.
Capacity stellt die gesamte und verwendete Kapazität der Speicherappliance bereit.
Remote Vendor Management gibt an, ob die Remoteanbieterverwaltung für die Speicherappliance aktiviert oder deaktiviert ist.

Speicherappliancevorgänge

Auflisten von Speicherappliances: Auflisten von Speicherappliances in der bereitgestellten Ressourcengruppe oder dem bereitgestellten Abonnement.
Speicherappliance anzeigen: Abrufen von Eigenschaften der bereitgestellten Speicherappliance.
Speicherappliance aktualisieren: Aktualisieren von Eigenschaften oder Tags der bereitgestellten Speicherappliance.
Aktivieren/Deaktivieren der Remoteanbieterverwaltung für die Speicheranwendungappliance: Aktivieren oder deaktivieren Sie die Remoteanbieterverwaltung für die bereitgestellte Speicherappliance.

Hinweis

Die Kundschaft kann keine Speicherappliances direkt erstellen oder löschen. Diese Ressourcen werden nur als Realisierung des Clusterlebenszyklus erstellt. Die Implementierung blockiert Anforderungen zur Erstellung oder Löschung von benutzenden Personen und erlaubt nur interne/anwendungsgesteuerte Erstellungs- oder Löschvorgänge.

Freigeben über