Dispositivo de armazenamento do Nexus do Operador do Azure

Artigo
11/01/2024

O Nexus do Operador do Azure foi criado com base em constructos básicos, como servidores de computação, dispositivos de armazenamento e dispositivos de malha de rede. Os dispositivos de armazenamento do Nexus do Operador do Azure representam dispositivos de armazenamento persistentes no rack.

Cada dispositivo de armazenamento contém vários dispositivos de armazenamento, que são agregados para fornecer um único pool de armazenamento. Esse pool de armazenamento é então dividido em vários volumes, que são apresentados aos servidores de computação como dispositivos de armazenamento de bloco. Os servidores de computação podem usar esses dispositivos de armazenamento de bloco como armazenamento persistente para suas cargas de trabalho. Cada cluster do Nexus do Operador do Azure é provisionado com um único dispositivo de armazenamento que é compartilhado por todas as cargas de trabalho do locatário.

O dispositivo de armazenamento em uma instância do Nexus do Operador do Azure é representado como um recurso do Azure. Os operadores têm acesso à exibição de seus atributos como qualquer outro recurso do Azure.

Classes de armazenamento do Kubernetes

A pilha Kubernetes do software do Nexus do Operador do Azure oferece dois tipos de armazenamento. Os operadores os selecionam por meio do mecanismo StorageClass do Kubernetes.

Importante

O Nexus do Operador do Azure não dá suporte para volumes efêmeros. O Nexus recomenda que os mecanismos de armazenamento de volumes persistentes descritos nesse documento sejam usados para todos os volumes de carga de trabalho, pois eles fornecem os mais altos níveis de desempenho e disponibilidade. Todo o armazenamento no Nexus do Operador do Azure é fornecido pelo dispositivo de armazenamento. Não há suporte para armazenamento fornecido por discos de computadores baremetal.

StorageClass: nexus-volume

O mecanismo de armazenamento padrão, nexus-volume, é a escolha preferida da maioria dos usuários. Ele oferece os mais altos níveis de desempenho e disponibilidade. Entretanto, os volumes não podem ser compartilhados simultaneamente em vários nós de trabalho. Os operadores podem acessar e gerenciar esses volumes usando a API e o portal do Azure, por meio do recurso 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

Em situações em que um sistema de arquivos compartilhado é necessário, a classe de armazenamento nexus-shared está disponível. Essa classe de armazenamento fornece uma solução de armazenamento compartilhado altamente disponível, permitindo que vários pods no mesmo cluster de Kubernetes do Nexus acessem e compartilhem o mesmo volume simultaneamente. A classe de armazenamento nexus-shared tem o suporte de um serviço de armazenamento NFS altamente disponível. Esse serviço de armazenamento NFS (o pool de armazenamento atualmente é limitado a um tamanho máximo de 1 TiB) está disponível pela CSN (Rede de Serviço de Nuvem). O serviço de armazenamento NFS é implantado automaticamente na criação de um recurso CSN. Qualquer cluster do Kubernetes do Nexus anexado à CSN pode provisionar os volumes persistentes desse pool de armazenamento compartilhado. O nexus-shared dá suporte aos modos de acesso Read Write Once (RWO) e Read Write Many (RWX). Isso significa que os aplicativos de carga de trabalho podem usar um desses modos de acesso para acessar o armazenamento compartilhado.

Diagrama mostrando como o nexus-shared provisiona um volume para uma carga de trabalho no Cluster do Kubernetes do Nexus

Figura: Volume Compartilhado do Nexus

Embora o desempenho e a disponibilidade do nexus-shared sejam suficientes para a maioria dos aplicativos, recomendamos que as cargas de trabalho com requisitos intensivos de E/S utilizem a opção nexus-volume para obter o desempenho ideal.

Read Write Once (RWO)

No modo RWO (Read Write Once), apenas um nó ou reclamante pode montar o volume nexus-shared de cada vez. O modo de acesso ReadWriteOnce ainda permite que vários pods acessem o volume quando os pods estão sendo executados no mesmo nó.

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)

No modo RWX (Read Write Many), vários nós ou reclamantes podem montar o volume nexus-shared ao mesmo tempo.

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

Exemplos

Read Write Once (RWO) com classe de armazenamento nexus-volume

Este exemplo cria um StatefulSet com PersistentVolumeClaimTemplate usando a classe de armazenamento nexus-volume no 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 StatefulSet tem um PersistentVolumeClaim criado.

# 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) com classe de armazenamento nexus-shared

O manifesto abaixo cria uma implantação com um PersistentVolumeClaim (PVC) usando a classe de armazenamento nexus-shared no modo ReadWriteMany. O PVC criado é compartilhado por todos os pods da implantação e pode ser utilizado para leitura e gravação por todos eles simultaneamente.

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

Uma vez aplicado, há três réplicas da implantação compartilhando o mesmo 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>

Pode-se observar na saída abaixo que todos os pods estão gravando no mesmo 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

Limites de tamanho do volume e gerenciamento de capacidade

Os PVCs criados usando o nexus-volume e o nexus-shared têm tamanhos mínimos e máximos de declaração.

Classe de armazenamento	Tamanho mínimo do PVC	Tamanho máximo do PVC
nexus-volume	1 MiB	12 TiB
nexus-shared	Nenhum	1 TiB

Importante

Volumes que atingem o limite de consumo causarão erros de espaço em disco nas cargas de trabalho que os consomem. Você deve verificar se provisiona tamanhos de volume adequados para seus requisitos de carga de trabalho. Você deve monitorar o dispositivo de armazenamento e todos os servidores NFS para seu consumo de armazenamento percentual. Você pode fazer isso usando as métricas documentadas na lista de métricas disponíveis.

Os PVCs nexus-volume e nexus-shared têm a capacidade de armazenamento solicitada imposta como um limite de consumo. Um volume não pode consumir mais armazenamento do que a solicitação PVC associada.
Todos os volumes físicos são provisionados de maneira fina. Você deve monitorar o consumo total de armazenamento em seu dispositivo de armazenamento e executar operações de manutenção para liberar espaço de armazenamento, se necessário.
Uma solicitação de provisionamento PVC de nexus-volume falhará se o tamanho solicitado for menor que o mínimo ou mais do que o tamanho máximo de volume com suporte.
Os volumes nexus-shared são provisionados logicamente no servidor NFS de suporte. Esse servidor NFS tem uma capacidade fixa de 1 TiB.
- Um PVC nexus-shared pode ser provisionado apesar de solicitar mais de 1 TiB de armazenamento, no entanto, apenas 1 TiB pode ser consumido.
- É possível provisionar um conjunto de PVCs em que a soma das solicitações de capacidade é maior que 1 TiB. No entanto, o limite de consumo de 1 TiB se aplica; o conjunto de PVs associadas pode não consumir mais de 1 TiB de armazenamento.

Status do dispositivo de armazenamento

As propriedades a seguir refletem o estado operacional de um dispositivo de armazenamento:

Status indica o estado conforme derivado do dispositivo de armazenamento. O estado pode ser Available, Error ou Provisioning.
Provisioning State fornece o estado de provisionamento atual do dispositivo de armazenamento. O estado de provisionamento pode ser Succeeded, Failed ou InProgress.
Capacity fornece a capacidade total e a capacidade usada do dispositivo de armazenamento.
Remote Vendor Management indica se o gerenciamento remoto do fornecedor está habilitado ou desabilitado para o dispositivo de armazenamento.

Operações do dispositivo de armazenamento

Listar Dispositivos de Armazenamento: lista os dispositivos de armazenamento no grupo de recursos ou na assinatura fornecida.
Mostrar dispositivo de armazenamento: obtêm as propriedades do dispositivo de armazenamento fornecido.
Atualizar dispositivo de armazenamento: atualiza as propriedades ou rótulos do dispositivo de armazenamento fornecido.
Habilitar/Desabilitar o gerenciamento remoto de fornecedores para o dispositivo de armazenamento: habilita ou desabilita o gerenciamento remoto do fornecedor para o dispositivo de armazenamento fornecido.

Observação

Os clientes não podem criar ou excluir dispositivos de armazenamento diretamente. Esses recursos são criados apenas como a realização do ciclo de vida do cluster. A implementação bloqueia as solicitações de criação ou exclusão de qualquer usuário e permite apenas operações de criação ou exclusão internas/controladas por aplicativos.

Compartilhar via