Appliance de stockage Azure Operator Nexus

Article
10/30/2024

Azure Operator Nexus repose sur des constructions de base comme des serveurs de calcul, des appliances de stockage et des appareils de structure réseau. Les appliances de stockage Azure Operator Nexus représentent les appliances de stockage persistantes sur le rack.

Chaque appliance de stockage contient plusieurs dispositifs de stockage, qui sont agrégés pour fournir un seul pool de stockage. Ce pool de stockage est ensuite découpé en plusieurs volumes, qui sont présentés aux serveurs de calcul comme des dispositifs de stockage de blocs. Les serveurs de calcul peuvent utiliser ces dispositifs de stockage de blocs comme stockage persistant pour leurs charges de travail. Chaque cluster Azure Operator Nexus est provisionné avec une seule appliance de stockage partagée entre toutes les charges de travail du locataire.

L’appliance de stockage dans une instance Azure Operator Nexus est représentée comme une ressource Azure. Les opérateurs peuvent voir ses attributs comme n’importe quelle autre ressource Azure.

Classes de stockage Kubernetes

La pile Kubernetes du logiciel Azure Operator Nexus offre deux types de stockage. Les opérateurs les sélectionnent avec le mécanisme Kubernetes StorageClass.

Important

Azure Operator Nexus ne prend pas en charge les volumes éphémères. Nexus recommande que les mécanismes de stockage de volumes persistants décrits dans ce document soient utilisés pour tous les volumes de charge de travail, car ils fournissent les niveaux de performances et de disponibilité les plus élevés. Tout le stockage dans Azure Operator Nexus est fourni par l’appliance de stockage. Il n’existe aucune prise en charge du stockage fourni par les disques de machine nue.

StorageClass : nexus-volume

Le mécanisme de stockage par défaut, nexus-volume, est préféré par la plupart des utilisateurs. Il fournit les plus hauts niveaux de performances et de disponibilité. Toutefois, les volumes ne peuvent pas être partagés simultanément entre plusieurs nœuds worker. Les opérateurs peuvent accéder à ces volumes et les gérer en utilisant l’API et le portail Azure, à travers la ressource de volume.

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

Quand un système de fichiers partagé est nécessaire, la classe de stockage nexus-shared est disponible. Cette classe de stockage fournit une solution de stockage partagé hautement disponible en permettant à plusieurs pods du même cluster Nexus Kubernetes d’accéder simultanément au même volume et de le partager. La classe de stockage nexus-shared s’appuie sur un service de stockage NFS hautement disponible. Ce service de stockage NFS (pool de stockage actuellement limité à une taille maximale de 1 Tio) est disponible par CSN (Cloud Service Network). Le service de stockage NFS est déployé automatiquement lors de la création d’une ressource CSN. Tout cluster Nexus Kubernetes attaché au CSN peut provisionner des volumes persistants à partir de ce pool de stockage partagé. Nexus-shared prend en charge les modes d’accès Lecture/écriture une fois (RWO) et Lecture/écriture plusieurs fois (RWX). Cela signifie que les applications de charge de travail peuvent utiliser l’un ou l’autre de ces modes d’accès pour accéder au stockage partagé.

Diagramme illustrant la façon dont nexus-shared approvisionne un volume pour une charge de travail dans le cluster Kubernetes Nexus

Figure : volume partagé Nexus

Bien que les performances et la disponibilité de nexus-shared soient suffisantes pour la plupart des applications, notre recommandation est que les charges de travail qui ont des exigences d’E/S intensives utilisent l’option nexus-volume pour des performances optimales.

Lecture/écriture une fois (RWO)

En mode lecture-écriture unique (RWO), un seul nœud ou demandeur peut monter le volume nexus-shared à la fois. Le mode d’accès ReadWriteOnce permet toujours à plusieurs pods d’accéder au volume quand ils s’exécutent sur le même nœud.

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

Lecture/écriture plusieurs fois (RWX)

En mode RWX (Read Write Many), plusieurs nœuds ou demandeurs peuvent monter le volume nexus-shared en même temps.

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

Exemples

Lecture/écriture une fois (RWO) avec la classe de stockage nexus-volume

Le manifeste de cet exemple crée un StatefulSet avec PersistentVolumeClaimTemplate à l’aide de la classe de stockage nexus-volume en mode ReadWriteOnce.

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

Un PersistentVolumeClaim est créé pour chaque pod du StatefulSet.

# 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

Lecture/écriture plusieurs fois (RWX) avec la classe de stockage nexus-shared

Le manifeste ci-dessous crée un déploiement avec un PersistentVolumeClaim (PVC) en utilisant la classe de stockage nexus-shared en mode ReadWriteMany. Le PVC créé est partagé par tous les pods du déploiement et qui peuvent lire et écrire dedans simultanément.

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

Une fois appliqué, il y a trois répliques du déploiement qui partagent le même PVC.

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

Nous pouvons observer dans la sortie ci-dessous que tous les pods écrivent dans le même PVC.

# 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

Limitation de la taille des volumes et gestion de la capacité

Les PVC créés à l’aide de nexus-volume et de nexus-shared ont des tailles de revendication minimales et maximales.

Classe de stockage	Taille minimale du PVC	Taille maximale du PVC
nexus-volume	1 Mio	12 Tio
nexus-shared	Aucune	1 Tio

Important

Les volumes qui atteignent leur limite de consommation entraînent des erreurs d’espace disque sur les charges de travail qui les consomment. Vous devez vous assurer que vous approvisionnez des tailles de volume appropriées pour vos besoins en charge de travail. Vous devez surveiller à la fois l’appliance de stockage et tous les serveurs NFS pour leur consommation de stockage en pourcentage. Pour ce faire, utilisez les métriques documentées dans la liste des métriques disponibles.

La capacité de stockage demandée par les PVC de nexus-volume et de nexus-partagé est appliquée en tant que limite de consommation. Un volume ne peut pas consommer plus d’espace de stockage que la demande de PVC associée.
Tous les volumes physiques sont alloués dynamiquement. Vous devez surveiller la consommation totale de l’espace de stockage sur votre appliance de stockage et effectuer des opérations de maintenance pour libérer de l’espace de stockage si nécessaire.
Une demande d’approvisionnement en PVC nexus-volume échoue si la taille demandée est inférieure à la taille minimale ou supérieure à la taille maximale du volume pris en charge.
Les volumes nexus-shared sont logiquement configurés de manière dynamique sur le serveur NFS de stockage. Ce serveur NFS a une capacité fixe de 1 Tio.
- Un PVC nexus-shared peut être approvisionné même s’il demande plus de 1 Tio de stockage, mais seul 1 Tio peut être consommé.
- Il est possible d’approvisionner un ensemble de PVC dont la somme des demandes de capacité est supérieure à 1 Tio. Toutefois, la limite de consommation de 1 Tio s’applique ; l’ensemble des PV associées ne peut pas consommer plus de 1 Tio de stockage.

État de l’appliance de stockage

Les propriétés suivantes reflètent l’état opérationnel d’une appliance de stockage :

Status indique l’état dérivé de l’appliance de stockage. L’état peut être Available, Error ou Provisioning.
Provisioning State fournit l’état de provisionnement actuel de l’appliance de stockage. L’état de provisionnement peut être Succeeded, Failed ou InProgress.
Capacity fournit la capacité totale et utilisée de l’appliance de stockage.
Remote Vendor Management indique si la gestion à distance des fournisseurs est activée ou désactivée pour l’appliance de stockage.

Opérations de l’appliance de stockage

Lister les appliances de stockage : listez les appliances de stockage dans le groupe de ressources ou l’abonnement fourni.
Afficher l’appliance de stockage : obtenez les propriétés de l’appliance de stockage fournie.
Mettre à jour l’appliance de stockage : mettez à jour les propriétés ou les étiquettes de l’appliance de stockage fournie.
Activer/désactiver la gestion à distance des fournisseurs pour l’appliance de stockage : activez ou désactivez la gestion à distance des fournisseurs pour l’appliance de stockage fournie.

Remarque

Les clients ne peuvent pas créer ou supprimer directement des appliances de stockage. Ces ressources sont créées uniquement dans le cadre du cycle de vie du cluster. L’implémentation bloque les demandes de création ou de suppression de tous les utilisateurs, et autorise uniquement les opérations de création ou de suppression internes ou pilotées par l’application.

Partager via