Dispositivo de almacenamiento de Azure Operator Nexus

Artículo
10/31/2024

Azure Operator Nexus se basa en construcciones básicas como servidores de proceso, dispositivos de almacenamiento y dispositivos del tejido de red. Los dispositivos de almacenamiento de Azure Operator Nexus representan dispositivos de almacenamiento persistentes en el bastidor.

Cada dispositivo de almacenamiento contiene varios dispositivos de almacenamiento, que se agregan para proporcionar un solo bloque de almacenamiento. A continuación, dicho bloque de almacenamiento se divide en varios volúmenes, que se presentan a los servidores de proceso como dispositivos de almacenamiento en bloque. Los servidores de proceso pueden usar estos dispositivos de almacenamiento en bloque como almacenamiento persistente para sus cargas de trabajo. Cada clúster de Azure Operator Nexus se aprovisiona con un solo dispositivo de almacenamiento que se comparte en todas las cargas de trabajo del inquilino.

El dispositivo de almacenamiento de una instancia de Azure Operator Nexus se representa como un recurso de Azure. Los operadores obtienen acceso para ver sus atributos como cualquier otro recurso de Azure.

Clases de almacenamiento de Kubernetes

La pila de Kubernetes de software de Azure Operator Nexus ofrece dos tipos de almacenamiento. Los operadores los seleccionan a través del mecanismo StorageClass de Kubernetes.

Importante

Azure Operator Nexus no admite volúmenes efímeros. Nexus recomienda que los mecanismos de almacenamiento de volúmenes persistentes descritos en este documento se usen para todos los volúmenes de cargas de trabajo, ya que proporcionan los niveles más altos de rendimiento y disponibilidad. El dispositivo de almacenamiento proporciona todo el almacenamiento de Azure Operator Nexus. No hay compatibilidad con el almacenamiento proporcionado por discos de máquina sin sistema operativo.

StorageClass: nexus-volume

El mecanismo de almacenamiento predeterminado, nexus-volume, es la opción preferida para la mayoría de los usuarios. Proporciona los niveles más altos de rendimiento y disponibilidad. Sin embargo, los volúmenes no se pueden compartir simultáneamente entre varios nodos de trabajo. Los operadores pueden acceder a estos volúmenes y administrarlos mediante el portal y la API de Azure, a través del recurso de volumen.

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

En situaciones en las que se requiere un sistema de archivos compartido, la clase de almacenamiento nexus-shared está disponible. Esta clase de almacenamiento proporciona una solución de almacenamiento compartido de alta disponibilidad al permitir que varios pods del mismo clúster de Nexus Kubernetes accedan simultáneamente al mismo volumen y lo compartan. La clase de almacenamiento nexus-shared está respaldada por un servicio de almacenamiento NFS de alta disponibilidad. Este servicio de almacenamiento NFS (bloque de almacenamiento limitado actualmente a un tamaño máximo de 1TiB) está disponible por red de servicio en la nube (CSN). El servicio de almacenamiento NFS se implementa automáticamente al crear un recurso de CSN. Cualquier clúster de Nexus Kubernetes conectado a la CSN puede aprovisionar el volumen persistente desde este bloque de almacenamiento compartido. Nexus-shared admite los modos de acceso Read Write Once (RWO) y Read Write Many (RWX). Eso significa que las aplicaciones de carga de trabajo pueden usar cualquiera de estos modos de acceso para acceder al almacenamiento compartido.

Diagrama en el que se muestra cómo nexus-shared aprovisiona un volumen para una carga de trabajo en el clúster de Kubernetes de Nexus

Ilustración: volumen compartido de Nexus

Aunque el rendimiento y la disponibilidad de nexus-shared son suficientes para la mayoría de las aplicaciones, se recomienda que las cargas de trabajo con requisitos de E/S intensiva usen la opción nexus-volume para lograr un rendimiento óptimo.

Read Write Once (RWO)

En el modo Read Write Once (RWO), solo un nodo o demandante puede montar el volumen nexus-shared a la vez. El modo de acceso ReadWriteOnce todavía permite que varios pods accedan al volumen cuando los pods se ejecutan en el mismo nodo.

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)

En el modo Read Write Many (RWX), varios nodos o demandantes pueden montar el volumen nexus-shared al mismo tiempo.

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

Ejemplos

Read Write Once (RWO) con la clase de almacenamiento nexus-volume

Este manifiesto de ejemplo crea un objeto StatefulSet con PersistentVolumeClaimTemplate mediante la clase de almacenamiento nexus-volume en modo 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

Cada pod del objeto StatefulSet tiene una notificación PersistentVolumeClaim creada.

# 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) con la clase de almacenamiento nexus-shared

El manifiesto siguiente crea una implementación con una notificación PersistentVolumeClaim (PVC) mediante la clase de almacenamiento nexus-shared en modo ReadWriteMany. Todos los pods de la implementación comparten la notificación PVC creada y pueden usarla para leer y escribir de forma simultánea.

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

Después de aplicarse, hay tres réplicas de la implementación que comparten la misma notificación 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>

En el resultado siguiente se puede observar que todos los pods escriben en la misma notificación 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

Límites de tamaño de volumen y administración de capacidad

Las PVC creadas con nexus-volume y nexus-shared tienen tamaños de notificación mínimos y máximos.

Clase de almacenamiento	Tamaño mínimo de PVC	Tamaño máximo de PVC
nexus-volume	1 MiB	12 TiB
nexus-shared	Ninguno	1 TiB

Importante

Los volúmenes que alcanzan su límite de consumo provocarán errores de falta de espacio en disco en las cargas de trabajo que los consumen. Debe asegurarse de aprovisionar los tamaños de volumen adecuados para los requisitos de carga de trabajo. Debe supervisar tanto en el dispositivo de almacenamiento como en todos los servidores NFS su consumo de almacenamiento porcentual. Puede hacerlo con las métricas documentadas en la lista de métricas disponibles.

Las PVC de nexus-volume y de nexus-shared tienen su capacidad de almacenamiento solicitada impuesta como un límite de consumo. Un volumen no puede consumir más almacenamiento que la solicitud de la PVC asociada.
Todos los volúmenes físicos tienen un aprovisionamiento fino. Debe supervisar el consumo total de almacenamiento en su dispositivo de almacenamiento y realizar operaciones de mantenimiento para liberar espacio de almacenamiento si es necesario.
Se produce un error en una solicitud de aprovisionamiento de PVC de nexus-volume si el tamaño solicitado es inferior al mínimo o superior al tamaño máximo de volumen admitido.
Los volúmenes nexus-shared tienen lógicamente un aprovisionamiento fino en el servidor NFS de respaldo. Este servidor NFS tiene una capacidad fija de 1 TiB.
- Una PVC de nexus-shared se puede aprovisionar a pesar de solicitar más de 1 TiB de almacenamiento, pero solo se puede consumir 1 TiB.
- Es posible aprovisionar un conjunto de PVC en el que la suma de las solicitudes de capacidad es mayor que 1 TiB. Sin embargo, se aplica el límite de consumo de 1 TiB; es posible que el conjunto de PVC asociadas no consuma más de 1 TiB de almacenamiento.

Estado del dispositivo de almacenamiento

Las siguientes propiedades reflejan el estado operativo de un dispositivo de almacenamiento:

Status indica el estado como derivado del dispositivo de almacenamiento. El estado puede ser Available, Error o Provisioning.
Provisioning State proporciona el estado de aprovisionamiento actual del dispositivo de almacenamiento. El estado de aprovisionamiento puede ser Succeeded, Failed o InProgress.
Capacity proporciona la capacidad total y usada del dispositivo de almacenamiento.
Remote Vendor Management indica si la administración de proveedores de carácter remoto está habilitada o deshabilitada para el dispositivo de almacenamiento.

Operaciones del dispositivo de almacenamiento

Enumerar los dispositivos de almacenamiento: enumere los dispositivos de almacenamiento en el grupo de recursos o la suscripción proporcionados.
Mostrar el dispositivo de almacenamiento: obtenga las propiedades del dispositivo de almacenamiento proporcionado.
Actualizar el dispositivo de almacenamiento: actualice las propiedades o etiquetas del dispositivo de almacenamiento proporcionado.
Habilitar/deshabilitar la administración de proveedores de carácter remoto para el dispositivo de almacenamiento: habilite o deshabilite la administración de proveedores de carácter remoto para el dispositivo de almacenamiento proporcionado.

Nota:

Los clientes no pueden crear ni eliminar los dispositivos de almacenamiento directamente. Estos recursos solo se crean como la realización del ciclo de vida del clúster. La implementación bloquea las solicitudes de creación o eliminación de cualquier usuario y solo permite operaciones de creación o eliminación internas o controladas por la aplicación.

Compartir a través de