Azure Operator Nexus-Speicherappliance

  • Artikel

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.

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, indem mehrere Pods gleichzeitig auf dasselbe Volume zugreifen und gemeinsam genutzt werden können. Diese Volumes sind vom Typ NFS Storage (derzeit auf eine maximale Größe von 1 TB begrenzt), auf die die Kubernetes-Knoten als persistentes Volume zugreifen. Nexus-shared unterstützt die beiden Zugriffsmodi „Read Write Once (RWO)“ und „Read Write Many (RWX)“. Das bedeutet, dass die Workloadanwendungen einen dieser beiden Zugriffsmodi für den Zugriff auf den Speicher nutzen können.

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 das „nexus-shared“-Volume jeweils nur von einem Knoten oder Anforder gemountet werden. 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) kann das „nexus-shared“-Volume von mehreren Knoten oder Anforderern gleichzeitig gemountet werden.

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“

Das folgende Manifest erstellt ein StatefulSet mit PersistentVolumeClaimTemplate unter Verwendung der Speicherklasse „nexus-volume“ im ReadWriteOnce-Modus.

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

Jeder Pod des StatefulSets hat 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 teilen.

# 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 folgenden 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

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.