Provisioning dei PVC nello storage di file con Lustre Service

Per eseguire dinamicamente il provisioning di un PVC su un nuovo file system Lustre creato dinamicamente dal plugin volume CSI nel servizio di storage di file con Lustre:

1. Creare regole di sicurezza in un gruppo di sicurezza di rete (consigliato) o in una lista di sicurezza sia per il file system Lustre che per la subnet dei nodi di lavoro del cluster.

   Le regole di sicurezza da creare dipendono dalle posizioni di rete relative del file system Lustre e dai nodi di lavoro che fungono da client, in base agli scenari riportati di seguito.

   • Opzione 1: Client e Lustre in subnet diverse
   • Opzione 2: Client e Lustre nella stessa subnet

   Questi scenari, le regole di sicurezza da creare e la posizione in cui crearli, sono descritti completamente nella documentazione del servizio Storage di file con Lustre (vedere Regole di sicurezza VCN obbligatorie).

2. Definire una nuova classe di storage che utilizza il provisioning lustre.csi.oraclecloud.com:
   1. Creare un file manifesto (ad esempio, in un file denominato lustre-dyn-st-class.yaml), specificare un nome per la nuova classe di memorizzazione e specificare i valori per i parametri obbligatori e facoltativi:

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
        name: <storage-class-name>
      provisioner: lustre.csi.oraclecloud.com
      parameters:
        availabilityDomain: <ad-name>
        compartmentId: <compartment-ocid>   # optional
        subnetId: <subnet-ocid>
        performanceTier: <value>
        fileSystemName: <name>               # optional
        kmsKeyId: <key-ocid>                 # optional
        nsgIds: '["<nsg-ocid>"]'             # optional
        rootSquashEnabled: "<true | false>"  # optional
        rootSquashUid: "<value>"             # optional
        rootSquashGid: "<value>"             # optional
        rootSquashClientExceptions: '["<ip-address>"]'   # optional
        oci.oraclecloud.com/initial-defined-tags-override: '{"<tag-namespace>": {"<tag-key>": "<tag-value>"}}'
        oci.oraclecloud.com/initial-freeform-tags-override: '{"<tag-key>": "<tag-value>"}'
        setupLnet: "<true | false>"                    # optional
        lustreSubnetCidr: "<cidr-block>"      # optional
        lustrePostMountParameters: '[{"<parameter1>": <value>},{"<parameter2>": <value>}]' # optional

      Dove:

      • name: <storage-class-name>: obbligatorio. Nome scelto per la classe di storage.
      • availabilityDomain: <ad-name>: obbligatorio. Nome del dominio di disponibilità in cui creare il nuovo file system Lustre. Ad esempio, availabilityDomain: US-ASHBURN-AD-1. Per individuare il nome del dominio di disponibilità da utilizzare, eseguire il comando CLI oci iam availability-domain list oppure utilizzare l'operazione ListAvailabilityDomains. Per ulteriori informazioni, vedere Nomi di dominio di disponibilità della tenancy.
      • compartmentId: <compartment-ocid>: facoltativo. OCID del compartimento a cui deve appartenere il nuovo file system Lustre. Se non specificato, per impostazione predefinita viene utilizzato lo stesso compartimento del cluster. Ad esempio, compartmentId: ocid1.compartment.oc1..aaa______t6q
      • subnetId: <subnet-ocid>: obbligatorio. OCID della subnet in cui attivare il nuovo file system Lustre. Ad esempio, subnetId: ocid1.subnet.oc1.iad.aaaa______kfa
      • performanceTier: <value>: obbligatorio. Livello di prestazioni del file system Lustre. Valori consentiti:
        • MBPS_PER_TB_125
        • MBPS_PER_TB_250
        • MBPS_PER_TB_500
        • MBPS_PER_TB_1000
      • fileSystemName: <name>: facoltativo. Il nome del file system Lustre, fino a 8 caratteri. Se non specificato, verrà generato e utilizzato in modo casuale un valore predefinito. Ad esempio, fileSystemName: aiworkfs
      • kmsKeyId: <key-ocid>: facoltativo. OCID di una chiave di cifratura master gestita dall'utente, con cui cifrare i dati archiviati. Se non specificato, i dati vengono cifrati in archivio utilizzando chiavi di cifratura gestite da Oracle. Ad esempio, kmsKeyId: ocid1.key.oc1.iad.ann______usj
      • nsgIds: '["<nsg-ocid>"]': facoltativo. Array JSON di un massimo di cinque OCID del gruppo di sicurezza di rete da associare al file system Lustre. Ad esempio, nsgIds: '["ocid1.nsg.oc1.iad.aab______fea"]'
      • rootSquashEnabled: "<true | false>": facoltativo. Impostare su true per limitare l'accesso root ai client. L'impostazione predefinita è false.
      • rootSquashUid: "<value>": facoltativo. Quando l'opzione Squash radice è abilitata, le operazioni radice vengono mappate a questo UID. L'impostazione predefinita è 65534.
      • rootSquashGid: "<value>": facoltativo. Quando l'opzione Squash radice è abilitata, le operazioni radice vengono mappate a questo GID. L'impostazione predefinita è 65534.
      • rootSquashClientExceptions: '["<ip-address>"]': facoltativo. Array JSON di indirizzi IP o blocchi CIDR non soggetti a zucca radice (massimo 10 voci). Ad esempio, rootSquashClientExceptions: '["10.0.2.4"]'.
      • oci.oraclecloud.com/initial-defined-tags-override: '{"<tag-namespace>": {"<tag-key>": "<tag-value>"}}' Facoltativo. Specifica una tag definita per il nuovo file system. Ad esempio, oci.oraclecloud.com/initial-defined-tags-override: '{"Org": {"CostCenter": "AI"}}'

        Tenere presente che per applicare tag definite da uno spazio di nomi tag appartenente a un compartimento a una risorsa del file system appartenente a un compartimento diverso, è necessario includere un'istruzione criterio per consentire al cluster di utilizzare lo spazio di nomi tag. Vedere Criteri IAM aggiuntivi quando un cluster e uno spazio di nomi tag si trovano in compartimenti diversi.

      • oci.oraclecloud.com/initial-freeform-tags-override: '{"<tag-key>": "<tag-value>"}' Facoltativo. Specifica un tag in formato libero per il nuovo file system. Ad esempio, oci.oraclecloud.com/initial-freeform-tags-override: '{"Project": "ML"}'
      • setupLnet: "<true | false>": facoltativo. Impostare su true se il driver Lustre CSI deve eseguire l'impostazione della rete Lustre (LNet) prima dell'attivazione. Si consiglia di includere il parametro setupLnet e impostarlo su "true".
      • lustreSubnetCidr: "<cidr-block>": facoltativo. Impostare l'intervallo di rete di origine del nodo di lavoro utilizzato per il traffico Lustre:
        • Quando utilizzare: specificare un intervallo di rete solo se i nodi di lavoro utilizzano una VNIC secondaria per connettersi al file system Lustre. Questo CIDR deve corrispondere al blocco della subnet di tale VNIC secondaria (ad esempio, 10.0.2.0/24).
        • Quando omettere: non specificare un intervallo di rete se i nodi di lavoro utilizzano la VNIC primaria (l'interfaccia predefinita) per la connettività Lustre.
        • Importante: questo parametro è diverso dal parametro subnetId del file system Lustre, che definisce la posizione del file system Lustre stesso.
      • lustrePostMountParameters: '[{"<parameter1>": <value>},{"<parameter2>": <value>}]': facoltativo. Array JSON di parametri client Lustre avanzati da impostare dopo il MOUNT. Ad esempio, lustrePostMountParameters: '[{"*.*.*MDT*.lru_size": 11200},{"at_history": 600}]'

      Ad esempio:

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
        name: lustre-dyn-storage
      provisioner: lustre.csi.oraclecloud.com
      parameters:
        availabilityDomain: US-ASHBURN-AD-1
        compartmentId: ocid1.compartment.oc1..aaa______t6q # optional
        subnetId: ocid1.subnet.oc1.iad.aaaa______kfa
        performanceTier: MBPS_PER_TB_250
        fileSystemName: aiworkfs                           # optional
        kmsKeyId: ocid1.key.oc1.iad.ann______usj           # optional
        nsgIds: '["ocid1.nsg.oc1.iad.aab______fea"]'       # optional
        oci.oraclecloud.com/initial-defined-tags-override: '{"Org": {"CostCenter": "AI"}}'
        oci.oraclecloud.com/initial-freeform-tags-override: '{"Project": "ML"}'
        setupLnet: "true"                    # optional

   2. Creare la classe di memorizzazione dal file manifesto immettendo:

      kubectl create -f <filename>

      Ad esempio:

      kubectl create -f lustre-dyn-st-class.yaml

3. Creare un PVC di cui eseguire il provisioning dal nuovo file system nello storage di file con il servizio Lustre, come indicato di seguito.
   1. Creare un file manifesto per definire il PVC:

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: <pvc-name>
      spec:
        accessModes:
          - <ReadWriteMany|ReadOnlyOncePod>
        storageClassName: "<storage-class-name>"
        resources:
          requests:
            storage: <capacity>

      dove:

      • name: <pvc-name>: obbligatorio. Ad esempio, lustre-dynamic-claim
      • storageClassName: "<storage-class-name>": obbligatorio. Nome della classe di storage definita in precedenza. Ad esempio, lustre-dyn-storage.
      • accessModes: - <ReadWriteMany|ReadOnlyOncePod>: obbligatorio. Specifica la modalità di attivazione e condivisione del file system da parte dei pod. Attualmente sono supportati ReadWriteMany e ReadOnlyOncePod. Ad esempio, ReadWriteMany.
      • storage: <capacity>: obbligatorio. Questo valore deve essere almeno 31.2T (o 31200G). È possibile specificare una capacità maggiore, ma è necessario utilizzare incrementi particolari che dipendono dalla capacità (vedere Aumento della capacità del file system). Ad esempio, 31.2T.

      Ad esempio, il file manifesto seguente (denominato lustre-dyn-claim.yaml) definisce un PVC denominato lustre-dynamic-claim di cui viene eseguito il provisioning dal file system definito nella classe di memorizzazione lustre-dyn-storage:

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: lustre-dynamic-claim
      spec:
        accessModes:
          - ReadWriteMany
        storageClassName: "lustre-dyn-storage"
        resources:
          requests:
            storage: 31.2T

   2. Creare il PVC dal file manifesto inserendo:

      kubectl create -f <filename> 

      Ad esempio:

      kubectl create -f lustre-dyn-claim.yaml

   Viene creato un nuovo PVC. Il plugin volume CSI crea un nuovo volume persistente (PV) e un nuovo file system nello storage di file con il servizio Lustre. Si noti che la creazione di un nuovo file system Lustre richiede almeno 10 minuti e può richiedere più tempo, a seconda delle dimensioni del file system. Utilizzare la console o l'interfaccia CLI per confermare la creazione del nuovo file system Lustre (vedere Elenco dei file system).

   Il nuovo PVC è legato al nuovo PV. I dati vengono cifrati al momento dell'archiviazione, utilizzando chiavi di cifratura gestite personalmente da Oracle o da Voi.

4. Verificare che il PVC sia stato legato al nuovo volume persistente inserendo:

   kubectl get pvc

   Output di esempio:

   			
   NAME                   STATUS    VOLUME                    CAPACITY         ACCESSMODES   STORAGECLASS         AGE
   lustre-dynamic-claim   Bound     csi-lustre-<unique_ID>    30468750000Ki    RWX           lustre-dyn-storage   4m

5. Utilizzare il nuovo PVC quando si creano altri oggetti, ad esempio i pod. Ad esempio, è possibile creare un nuovo pod dalla seguente definizione di pod:

   apiVersion: v1
   kind: Pod
   metadata:
     name: lustre-dynamic-app
   spec:
     containers:
       - name: aiworkload
         image: busybox:latest
         command: ["sleep", "3600"]
         volumeMounts:
           - name: lustre-vol
             mountPath: /mnt/lustre
     volumes:
       - name: lustre-vol
         persistentVolumeClaim:
           claimName: lustre-dynamic-claim

6. Dopo aver creato un nuovo pod come descritto nell'esempio nel passo precedente, è possibile verificare che il pod stia utilizzando il nuovo PVC inserendo:

   kubectl describe pod lustre-dynamic-app

Per creare un PVC su un file system esistente nello storage di file con il servizio Lustre (utilizzando chiavi di cifratura gestite da Oracle per cifrare i dati in archivio):

1. Creare un file system nello storage di file con il servizio Lustre, selezionando l'opzione di cifratura Encrypt using Oracle-managed keys. Vedere Creating a Lustre File System.
2. Creare regole di sicurezza in un gruppo di sicurezza di rete (consigliato) o in una lista di sicurezza sia per il file system Lustre che per la subnet dei nodi di lavoro del cluster.
   Le regole di sicurezza da creare dipendono dalle posizioni di rete relative del file system Lustre e dai nodi di lavoro che fungono da client, secondo i seguenti scenari:

   • Opzione 1: Client e Lustre in diverse sottoreti
   • Opzione 2: Client e Lustre nella stessa sottorete

   Questi scenari, le regole di sicurezza da creare e dove crearle, sono descritti nella documentazione del servizio Lustre relativa allo storage di file (vedere Regole di sicurezza VCN obbligatorie).

3. Creare un PV supportato dal file system nello storage di file con il servizio Lustre come indicato di seguito.

   1. Creare un file manifesto per definire un PV e, nella sezione csi:, impostare:

      • Da driver a lustre.csi.oraclecloud.com
      • Da volumeHandle a <MGSAddress>@<LNetName>:/<MountName>

        dove:

        • <MGSAddress> è l'indirizzo del servizio di gestione per il file system nello storage di file con il servizio Lustre
        • <LNetName> è il nome di rete LNet per il file system nello storage di file con il servizio Lustre.
        • <MountName> è il nome di accesso utilizzato durante la creazione del file system nello storage di file con il servizio Lustre.

        Ad esempio: 10.0.2.6@tcp:/testlustrefs

      • Da fsType a lustre
      • (facoltativo, ma consigliato) da volumeAttributes.setupLnet a "true" se si desidera che il driver Lustre CSI esegua l'impostazione lnet (Lustre Network) prima di eseguire il MOUNT del file system.
      • (facoltativo) volumeAttributes.lustreSubnetCidr nell'intervallo di rete di origine del nodo di lavoro utilizzato per il traffico Lustre:
        • Quando utilizzare: specificare un intervallo di rete solo se i nodi di lavoro utilizzano una VNIC secondaria per connettersi al file system Lustre. Questo CIDR deve corrispondere al blocco della subnet di tale VNIC secondaria (ad esempio, 10.0.2.0/24).
        • Quando omettere: non specificare un intervallo di rete se i nodi di lavoro utilizzano la VNIC primaria (l'interfaccia predefinita) per la connettività Lustre.
        • Importante: questo parametro è diverso dal parametro subnetId del file system Lustre, che definisce la posizione del file system Lustre stesso.
      • (facoltativo) volumeAttributes.lustrePostMountParameters per impostare i parametri di Lustre. Ad esempio:

        ...
            volumeAttributes:
              lustrePostMountParameters: '[{"*.*.*MDT*.lru_size": 11200},{"at_history" :
            600}]'

      Ad esempio, il seguente file manifesto (denominato lustre-PV-example.yaml) definisce un PV denominato lustre-pv-example supportato da un file system Lustre:

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: lustre-pv-example
      spec:
        capacity:
          storage: 31.2T
        volumeMode: Filesystem
        accessModes:
          - ReadWriteMany
        persistentVolumeReclaimPolicy: Retain
        csi:
          driver: lustre.csi.oraclecloud.com
          volumeHandle: "10.0.2.6@tcp:/testlustrefs"
          fsType: lustre
          volumeAttributes:
            setupLnet: "true"

   2. Creare il PV dal file manifesto immettendo:

      kubectl apply -f <filename>

      Ad esempio:

      kubectl apply -f lustre-pv-example.yaml

   3. Verificare che il PV sia stato creato correttamente immettendo:

      kubectl get pv <pv-name>

      Ad esempio:

      kubectl get pv lustre-pv-example

      Output di esempio:

      
      NAME                CAPACITY        ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM   STORAGECLASS   REASON   AGE
      lustre-pv-example   30468750000Ki   RWX            Retain           Bound                                    56m
      

4. Creare un PVC fornito dal PV creato, come segue:
   1. Creare un file manifesto per definire il PVC e impostare:
      • Da storageClassName a "" Si noti che è necessario specificare un valore vuoto per storageClassName, anche se la classe di memorizzazione non è applicabile in caso di provisioning statico dello storage persistente. Se non si specifica un valore vuoto per storageClassName, viene utilizzata la classe di memorizzazione predefinita (oci-bv), che causa un errore.
      • volumeName al nome del PV creato (ad esempio, lustre-pv-example)

      Ad esempio, il seguente file manifesto (denominato lustre-PVC-example.yaml) definisce un PVC denominato lustre-pvc-example che verrà associato a un PV denominato lustre-pv-example:

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: lustre-pvc-example
      spec:
        accessModes:
          - ReadWriteMany
        storageClassName: ""
        volumeName: lustre-pv-example
        resources:
          requests:
            storage:  31.2T

      Si noti che l'elemento requests: storage: deve essere presente nel file manifesto del PVC e che il relativo valore deve corrispondere al valore specificato per l'elemento capacity: storage: nel file manifesto del PV. A parte questo, il valore dell'elemento requests: storage: viene ignorato.

   2. Creare il PVC dal file manifesto immettendo:

      kubectl apply -f <filename>

      Ad esempio:

      kubectl apply -f lustre-pvc-example.yaml

   3. Verificare che il PVC sia stato creato e associato al PV inserendo:

      kubectl get pvc <pvc-name>

      Ad esempio:

      kubectl get pvc lustre-pvc-example

      Output di esempio:

      
      NAME                    STATUS   VOLUME              CAPACITY         ACCESS MODES   STORAGECLASS   AGE
      lustre-pvc-example      Bound    lustre-pv-example   30468750000Ki    RWX                           57m

   Il PVC è legato al PV supportato dallo storage di file con il file system di servizio Lustre. I dati vengono cifrati in archivio utilizzando le chiavi di cifratura gestite da Oracle.

5. Utilizzare il nuovo PVC quando si creano altri oggetti, ad esempio le distribuzioni. Ad esempio:
   1. Creare un file manifesto denominato lustre-app-example-deployment.yaml per definire una distribuzione denominata lustre-app-example-deployment che utilizza il PVC lustre-pvc-example, come indicato di seguito.

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: lustre-app-example-deployment
      spec:
        selector:
          matchLabels:
            app: lustre-app-example
        replicas: 2
        template:
          metadata:
            labels:
              app: lustre-app-example
          spec:
            containers:
            - args:
              - -c
              - while true; do echo $(date -u) >> /lustre/data/out.txt; sleep 60; done
              command:
              - /bin/sh
              image: busybox:latest
              imagePullPolicy: Always
              name: lustre-app-example
              volumeMounts:
              - mountPath: /lustre/data
                name: lustre-volume
            restartPolicy: Always
            volumes:
            - name: lustre-volume
              persistentVolumeClaim:
                claimName: lustre-pvc-example

   2. Creare la distribuzione dal file manifest immettendo:

      kubectl apply -f lustre-app-example-deployment.yaml

   3. Verificare che i pod di distribuzione siano stati creati correttamente e siano in esecuzione immettendo:

      kubectl get pods

      Output di esempio:

      NAME                                             READY   STATUS              RESTARTS   AGE
      lustre-app-example-deployment-7767fdff86-nd75n   1/1     Running             0          8h
      lustre-app-example-deployment-7767fdff86-wmxlh   1/1     Running             0          8h