Azure Operator Nexus-lagringsinstallation

Artikel
10/29/2024

Azure Operator Nexus bygger på grundläggande konstruktioner som beräkningsservrar, lagringsenheter och nätverksinfrastrukturenheter. Azure Operator Nexus-lagringsenheter representerar beständiga lagringsenheter på racket.

Varje lagringsenhet innehåller flera lagringsenheter som aggregeras för att tillhandahålla en enda lagringspool. Den här lagringspoolen delas sedan ut i flera volymer, som presenteras för beräkningsservrarna som blocklagringsenheter. Beräkningsservrarna kan använda dessa blocklagringsenheter som beständig lagring för sina arbetsbelastningar. Varje Azure Operator Nexus-kluster etableras med en enda lagringsenhet som delas mellan alla klientarbetsbelastningar.

Lagringsinstallationen i en Azure Operator Nexus-instans representeras som en Azure-resurs. Operatörer får åtkomst för att visa dess attribut som andra Azure-resurser.

Kubernetes-lagringsklasser

Azure Operator Nexus-programvaran Kubernetes stack erbjuder två typer av lagring. Operatorer väljer dem via Kubernetes StorageClass-mekanismen.

Viktigt!

Azure Operator Nexus stöder inte tillfälliga volymer. Nexus rekommenderar att de beständiga mekanismerna för volymlagring som beskrivs i det här dokumentet används för alla arbetsbelastningsvolymer eftersom de ger högsta prestanda och tillgänglighet. All lagring i Azure Operator Nexus tillhandahålls av lagringsinstallationen. Det finns inget stöd för lagring som tillhandahålls av baremetala datordiskar.

StorageClass: nexus-volume

Standardlagringsmekanismen nexus-volume är det bästa valet för de flesta användare. Den ger högsta möjliga prestanda och tillgänglighet. Volymer kan dock inte delas samtidigt över flera arbetsnoder. Operatörer kan komma åt och hantera dessa volymer med hjälp av Azure API och portalen via volymresursen.

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

I situationer där ett delat filsystem krävs är den nexus-delade lagringsklassen tillgänglig. Den här lagringsklassen ger en delad lagringslösning med hög tillgänglighet genom att flera poddar i samma Nexus Kubernetes-kluster kan komma åt och dela samma volym samtidigt. Den nexus-delade lagringsklassen backas upp av en NFS-lagringstjänst med hög tillgänglighet. Den här NFS-lagringstjänsten (lagringspoolen är för närvarande begränsad till en maximal storlek på 1 TiB) är tillgänglig per Cloud Service Network (CSN). NFS-lagringstjänsten distribueras automatiskt när en CSN-resurs skapas. Alla Nexus Kubernetes-kluster som är anslutna till CSN kan etablera beständiga volymer från den här delade lagringspoolen. Nexus-delad stöder både åtkomstlägena Read Write Once (RWO) och Read Write Many (RWX). Det innebär att arbetsbelastningsprogrammen kan använda något av dessa åtkomstlägen för att få åtkomst till den delade lagringen.

Diagram som visar hur nexus-delad etablerar en volym för en arbetsbelastning i Nexus Kubernetes-kluster

Bild: Delad Nexus-volym

Även om prestanda och tillgänglighet för nexus-delade är tillräckliga för de flesta program rekommenderar vi att arbetsbelastningar med höga I/O-krav använder nexus-volymalternativet för optimal prestanda.

Läs skrivning en gång (RWO)

I läget Skriv en gång (RWO) kan endast en nod eller sökande montera den nexus-delade volymen i taget. ReadWriteOnce-åtkomstläget tillåter fortfarande att flera poddar kommer åt volymen när poddarna körs på samma nod.

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

Läs skriva många (RWX)

I läget Skriv många (RWX) kan flera noder eller sökande montera den nexus-delade volymen samtidigt.

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

Exempel

Läs skrivning en gång (RWO) med nexus-volymlagringsklass

Det här exempelmanifestet skapar en StatefulSet med PersistentVolumeClaimTemplate med hjälp av nexus-volymlagringsklassen i ReadWriteOnce-läge.

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

Varje podd i StatefulSet har en PersistentVolumeClaim skapad.

# 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

Läs skriva många (RWX) med nexus-delad lagringsklass

Manifestet nedan skapar en distribution med en PersistentVolumeClaim (PVC) med hjälp av nexus-delad lagringsklass i ReadWriteMany-läge. DEN PVC som skapats delas av alla poddar i distributionen och kan användas för att läsa och skriva av dem alla samtidigt.

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

När den har tillämpats finns det tre repliker av distributionen som delar samma 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>

Det kan observeras från nedanstående utdata att alla poddar skriver till samma 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

Volymstorleksgränser och kapacitetshantering

Datorer som skapats med nexus-volym och nexus-shared har minsta och högsta anspråksstorlekar.

Lagringsklass	Minsta PVC-storlek	Maximal PVC-storlek
nexus-volym	1 MiB	12 TiB
nexus-delad	Ingen	1 TiB

Viktigt!

Volymer som når sin förbrukningsgräns orsakar fel om diskutrymme på de arbetsbelastningar som använder dem. Du måste se till att du etablerar lämpliga volymstorlekar för dina arbetsbelastningskrav. Du måste övervaka både lagringsinstallationen och alla NFS-servrar för deras procentuella lagringsförbrukning. Du kan göra detta med hjälp av de mått som beskrivs i listan över tillgängliga mått.

Både nexus-volume och nexus-shared PVCs har sin begärda lagringskapacitet framtvingas som en förbrukningsgräns. En volym kan inte förbruka mer lagringsutrymme än den associerade PVC-begäran.
Alla fysiska volymer är tunnetablerade. Du måste övervaka den totala lagringsförbrukningen på lagringsinstallationen och utföra underhållsåtgärder för att frigöra lagringsutrymme om det behövs.
En pvc-etableringsbegäran för nexus-volym misslyckas om den begärda storleken är mindre än den minsta eller mer än den maximala volymstorlek som stöds.
Nexus-delade volymer är logiskt tunnetablerade på den säkerhetskopierade NFS-servern. Den här NFS-servern har en fast kapacitet på 1 TiB.
- En nexus-delad PVC kan etableras trots att du begär mer än 1 TiB lagring, men endast 1 TiB kan användas.
- Det är möjligt att etablera en uppsättning datorer där summan av kapacitetsbegäranden är större än 1 TiB. Förbrukningsgränsen på 1 TiB gäller dock. uppsättningen med associerade PV:er får inte förbruka mer än 1 TiB lagringsutrymme.

Status för lagringsinstallation

Följande egenskaper återspeglar drifttillståndet för en lagringsenhet:

Status anger tillståndet som härlett från lagringsinstallationen. Tillståndet kan vara Available, Erroreller Provisioning.
Provisioning State tillhandahåller lagringsinstallationens aktuella etableringstillstånd. Etableringstillståndet kan vara Succeeded, Failedeller InProgress.
Capacity ger den totala och använda kapaciteten för lagringsinstallationen.
Remote Vendor Management anger om fjärrleverantörshantering är aktiverat eller inaktiverat för lagringsinstallationen.

Åtgärder för lagringsinstallation

Lista Lagringsenheter: Lista lagringsenheter i den angivna resursgruppen eller prenumerationen.
Visa lagringsinstallation: Hämta egenskaper för den angivna lagringsinstallationen.
Uppdatera lagringsinstallation: Uppdatera egenskaper eller taggar för den angivna lagringsinstallationen.
Aktivera/inaktivera hantering av fjärrleverantörer för lagringsinstallation: Aktivera eller inaktivera fjärrleverantörshantering för den angivna lagringsinstallationen.

Kommentar

Kunder kan inte skapa eller ta bort lagringsenheter direkt. Dessa resurser skapas endast som förverkligande av klusterlivscykeln. Implementeringen blockerar skapande- eller borttagningsbegäranden från alla användare och tillåter endast interna/programdrivna skapande- eller borttagningsåtgärder.

Dela via