Appliance di archiviazione Nexus dell'operatore di Azure

Articolo
10/29/2024

Operatore Nexus di Azure è basato su costrutti di base come server di calcolo, appliance di archiviazione e dispositivi di infrastruttura di rete. Le appliance di archiviazione Nexus dell'operatore di Azure rappresentano appliance di archiviazione permanenti nel rack.

Ogni appliance di archiviazione contiene più dispositivi di archiviazione, aggregati per fornire un singolo pool di archiviazione. Questo pool di archiviazione viene quindi ritagliato in più volumi, che vengono presentati ai server di calcolo come dispositivi di archiviazione a blocchi. I server di calcolo possono usare questi dispositivi di archiviazione a blocchi come risorsa di archiviazione permanente per i carichi di lavoro. Viene effettuato il provisioning di ogni cluster Nexus dell'operatore di Azure con un'unica appliance di archiviazione condivisa tra tutti i carichi di lavoro del tenant.

L’appliance di archiviazione in un'istanza di Operatore Nexus di Azure è rappresentata come risorsa di Azure. Gli operatori ottengono l'accesso per visualizzare i relativi attributi come qualsiasi altra risorsa di Azure.

Classi di archiviazione Kubernetes

Lo stack Kubernetes del software Nexus dell'operatore di Azure offre due tipi di archiviazione. Gli operatori li selezionano tramite il meccanismo Kubernetes StorageClass.

Importante

Operatore Nexus di Azure non supporta volumi temporanei. Nexus consiglia di usare i meccanismi di archiviazione dei volumi persistenti descritti in questo documento per tutti i volumi di carico di lavoro, in quanto forniscono i livelli più elevati di prestazioni e disponibilità. Tutte le risorse di archiviazione in Operatore Nexus di Azure vengono fornite dall'appliance di archiviazione. Non è disponibile alcun supporto per l'archiviazione fornita di dischi dei computer bare metal.

StorageClass: nexus-volume

Il meccanismo di archiviazione predefinito, nexus-volume, è la scelta preferita per la maggior parte degli utenti. Offre i livelli più elevati di prestazioni e disponibilità. Tuttavia, i volumi non possono essere condivisi simultaneamente tra più nodi di lavoro. Gli operatori possono accedere e gestire questi volumi usando l'API e il portale di Azure tramite la risorsa 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

In situazioni in cui è necessario un file system condiviso, è disponibile la classe di archiviazione nexus-shared. Questa classe di archiviazione offre una soluzione di archiviazione condivisa a disponibilità elevata consentendo a più pod nello stesso cluster Nexus Kubernetes di accedere simultaneamente e condividere lo stesso volume. La classe di archiviazione nexus-shared è supportata da un servizio di archiviazione NFS a disponibilità elevata. Questo servizio di archiviazione NFS (pool di archiviazione attualmente limitato a una dimensione massima di 1 TiB) è disponibile per ogni rete di servizi cloud (CSN). Il servizio di archiviazione NFS viene distribuito automaticamente alla creazione di una risorsa CSN. Qualsiasi cluster Nexus Kubernetes collegato al csn può effettuare il provisioning di volumi permanenti da questo pool di archiviazione condiviso. Nexus-shared supporta entrambe le modalità di accesso RWO (Read Write Once) e RWX (Read Write Many). Ciò significa che le applicazioni del carico di lavoro possono usare una di queste modalità di accesso per accedere all'archiviazione condivisa.

Diagramma che illustra come nexus-shared effettua il provisioning di un volume per un carico di lavoro nel cluster Nexus Kubernetes

Figura: Volume condiviso di Nexus

Sebbene le prestazioni e la disponibilità di nexus-shared siano sufficienti per la maggior parte delle applicazioni, è consigliabile che i carichi di lavoro con requisiti di I/O elevati usino l'opzione nexus-volume per ottenere prestazioni ottimali.

Read Write Once (RWO)

In modalità Read Write Once (RWO) un solo nodo o richiedente può montare il volume nexus-shared alla volta. La modalità di accesso ReadWriteOnce consente comunque a più pod di accedere al volume quando i pod sono in esecuzione nello stesso 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)

Nella modalità Read Write Many (RWX) più nodi o attestazioni possono montare contemporaneamente il volume nexus-shared.

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

Esempi

Read Write Once (RWO) con classe di archiviazione nexus-volume

Questo manifesto di esempio crea un oggetto StatefulSet con PersistentVolumeClaimTemplate usando la classe di archiviazione nexus-volume in modalità 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

Per ogni pod di StatefulSet è stato creato un oggetto PersistentVolumeClaim.

# 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 classe di archiviazione nexus-shared

Il manifesto seguente crea una distribuzione con PersistentVolumeClaim (PVC) usando la classe di archiviazione nexus-shared in modalità ReadWriteMany. Il PVC creato è condiviso da tutti i pod della distribuzione e può essere usato per leggere e scrivere contemporaneamente da tutti.

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

Una volta applicata, ci sono tre repliche della distribuzione che condividono lo stesso 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>

Si può osservare dall'output seguente che tutti i pod scrivono nello stesso 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

Limiti di dimensioni del volume e gestione della capacità

Le schede virtuali create usando nexus-volume e nexus-shared hanno dimensioni minime e massime delle attestazioni.

Classe di archiviazione	Dimensioni minime del PVC	Dimensioni massime del PVC
nexus-volume	1 MiB	12 TiB
nexus-shared	None	1 TiB

Importante

I volumi che raggiungono il limite di consumo causeranno errori di spazio su disco nei carichi di lavoro che li utilizzano. È necessario assicurarsi di effettuare il provisioning di dimensioni del volume appropriate per i requisiti del carico di lavoro. È necessario monitorare sia l'appliance di archiviazione che tutti i server NFS per il consumo di spazio di archiviazione percentuale. A tale scopo, è possibile usare le metriche documentate nell'elenco delle metriche disponibili.

Sia i PVC nexus-volume che nexus-shared hanno la capacità di archiviazione richiesta applicata come limite di consumo. Un volume non può utilizzare più spazio di archiviazione rispetto alla richiesta DI PVC associata.
Tutti i volumi fisici sono con thin provisioning. È necessario monitorare il consumo totale di archiviazione nell'appliance di archiviazione ed eseguire operazioni di manutenzione per liberare spazio di archiviazione, se necessario.
Una richiesta di provisioning PVC del volume nexus ha esito negativo se le dimensioni richieste sono inferiori o superiori alle dimensioni massime supportate del volume.
I volumi condivisi Nexus sono con thin provisioning logico nel server NFS di backup. Questo server NFS ha una capacità fissa di 1 TiB.
- È possibile effettuare il provisioning di un PVC condiviso nexus nonostante la richiesta di più di 1 TiB di spazio di archiviazione, ma solo 1 TiB può essere utilizzato.
- È possibile effettuare il provisioning di un set di pvc in cui la somma delle richieste di capacità è maggiore di 1 TiB. Tuttavia, si applica il limite di consumo di 1 TiB; il set di TELEVISORi associati non può utilizzare più di 1 TiB di archiviazione.

Stato dell'appliance di archiviazione

Le proprietà seguenti riflettono lo stato operativo di un'appliance di archiviazione:

Status indica lo stato derivato dall'appliance di archiviazione. Lo stato può essere Available, Error o Provisioning.
Provisioning State fornisce lo stato di provisioning corrente dell'appliance di archiviazione. Lo stato di provisioning può essere Succeeded, Failed o InProgress.
Capacity fornisce la capacità totale e usata dell'appliance di archiviazione.
Remote Vendor Management indica se la gestione remota del fornitore è abilitata o disabilitata per l'appliance di archiviazione.

Operazioni dell'appliance di archiviazione

Elencare le appliance di archiviazione: elencare le appliance di archiviazione nel gruppo di risorse o nella sottoscrizione fornita.
Mostrare appliance di archiviazione: ottenere le proprietà dell'appliance di archiviazione fornita.
Aggiornare l'appliance di archiviazione: aggiornare le proprietà o i tag dell'appliance di archiviazione fornita.
Abilitare/disabilitare la gestione remota del fornitore per l'appliance di archiviazione: abilitare o disabilitare la gestione remota del fornitore per l'appliance di archiviazione fornita.

Nota

I clienti non possono creare o eliminare direttamente l’appliance di archiviazione. Queste risorse vengono create solo come realizzazione del ciclo di vita del cluster. L'implementazione blocca le richieste di creazione o eliminazione da qualsiasi utente e consente solo operazioni di creazione o eliminazione interne o guidate dall'applicazione.

Condividi tramite