Provisionnement de PVC sur le stockage de fichiers avec le service Lustre

Pour provisionner dynamiquement une revendication de volume persistant sur un nouveau système de fichiers Lustre créé dynamiquement par le plugiciel de volume CSI dans le service File Storage with Lustre :

1. Créez des règles de sécurité dans un groupe de sécurité de réseau (recommandé) ou une liste de sécurité pour le système de fichiers Lustre et pour le sous-réseau de noeuds de travail de la grappe.

   Les règles de sécurité à créer dépendent des emplacements réseau relatifs du système de fichiers Lustre et des noeuds de travail qui agissent en tant que client, selon les scénarios suivants :

   • Option 1 : Client et Lustre dans différents sous-réseaux
   • Option 2 : Client et Lustre dans le même sous-réseau

   Ces scénarios, les règles de sécurité à créer et l'endroit où les créer sont décrits en détail dans la documentation du service File Storage with Lustre (voir Règles de sécurité de réseau VCN requises).

2. Définissez une nouvelle classe de stockage qui utilise le provisionneur lustre.csi.oraclecloud.com :
   1. Créez un fichier manifeste (par exemple, dans un fichier nommé lustre-dyn-st-class.yaml), spécifiez un nom pour la nouvelle classe de stockage et spécifiez des valeurs pour les paramètres obligatoires et facultatifs :

      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

      où :

      • name: <storage-class-name> : Obligatoire. Nom de votre choix pour la classe de stockage.
      • availabilityDomain: <ad-name> : Obligatoire. Nom du domaine de disponibilité dans lequel créer le système de fichiers Lustre. Par exemple, availabilityDomain: US-ASHBURN-AD-1. Pour connaître le nom du domaine de disponibilité à utiliser, exécutez la commande de l'interface de ligne de commande oci iam availability-domain list (ou utilisez l'opération ListAvailabilityDomains). Pour plus d'informations, voir Noms de domaine de disponibilité de votre location.
      • compartmentId: <compartment-ocid> : Facultatif. OCID du compartiment auquel le nouveau système de fichiers Lustre doit appartenir. S'il n'est pas spécifié, la valeur par défaut est le même compartiment que la grappe. Par exemple, compartmentId: ocid1.compartment.oc1..aaa______t6q
      • subnetId: <subnet-ocid> : Obligatoire. OCID du sous-réseau dans lequel monter le nouveau système de fichiers Lustre. Par exemple, subnetId: ocid1.subnet.oc1.iad.aaaa______kfa
      • performanceTier: <value> : Obligatoire. Niveau de performance du système de fichiers Lustre. Valeurs autorisées :
        • MBPS_PER_TB_125
        • MBPS_PER_TB_250
        • MBPS_PER_TB_500
        • MBPS_PER_TB_1000
      • fileSystemName: <name> : Facultatif. Nom du système de fichiers Lustre, jusqu'à 8 caractères. Si aucune valeur n'est spécifiée, une valeur par défaut est générée et utilisée de manière aléatoire. Par exemple, fileSystemName: aiworkfs
      • kmsKeyId: <key-ocid> : Facultatif. OCID d'une clé de chiffrement principale que vous gérez, avec laquelle chiffrer les données au repos. Si aucune valeur n'est indiquée, les données sont chiffrées au repos à l'aide de clés de chiffrement gérées par Oracle. Par exemple, kmsKeyId: ocid1.key.oc1.iad.ann______usj
      • nsgIds: '["<nsg-ocid>"]' : Facultatif. Tableau JSON comprenant jusqu'à cinq OCID de groupe de sécurité de réseau à associer au système de fichiers Lustre. Par exemple, nsgIds: '["ocid1.nsg.oc1.iad.aab______fea"]'
      • rootSquashEnabled: "<true | false>" : Facultatif. Réglez à true pour restreindre l'accès racine des clients. La valeur par défaut est false.
      • rootSquashUid: "<value>" : Facultatif. Lorsque le carré racine est activé, les opérations racine sont mappées à cet UID. Par défaut : 65534.
      • rootSquashGid: "<value>" : Facultatif. Lorsque le carré racine est activé, les opérations racine sont mappées à cet IDG. Par défaut : 65534.
      • rootSquashClientExceptions: '["<ip-address>"]' : Facultatif. Tableau JSON d'adresses IP ou de blocs CIDR qui ne sont pas soumis au carré racine (10 entrées au maximum). Par exemple, rootSquashClientExceptions: '["10.0.2.4"]'.
      • oci.oraclecloud.com/initial-defined-tags-override: '{"<tag-namespace>": {"<tag-key>": "<tag-value>"}}' Facultatif. Spécifie un marqueur défini pour le nouveau système de fichiers. Par exemple, oci.oraclecloud.com/initial-defined-tags-override: '{"Org": {"CostCenter": "AI"}}'

        Notez que pour appliquer des marqueurs définis d'un espace de noms de marqueur appartenant à un compartiment à une ressource de système de fichiers appartenant à un autre compartiment, vous devez inclure un énoncé de politique pour permettre à la grappe d'utiliser l'espace de noms de marqueur. Voir Politique IAM supplémentaire lorsqu'une grappe et un espace de noms de marqueur se trouvent dans des compartiments différents.

      • oci.oraclecloud.com/initial-freeform-tags-override: '{"<tag-key>": "<tag-value>"}' Facultatif. Spécifie un marqueur à structure libre pour le nouveau système de fichiers. Par exemple, oci.oraclecloud.com/initial-freeform-tags-override: '{"Project": "ML"}'
      • setupLnet: "<true | false>" : Facultatif. Réglez à true si le pilote CSI Lustre doit effectuer la configuration du réseau Lustre (LNet) avant le montage. Nous vous recommandons vivement d'inclure le paramètre setupLnet et de le définir "true".
      • lustreSubnetCidr: "<cidr-block>" : Facultatif. Régler à l'intervalle de réseau source du noeud de travail utilisé pour le trafic Lustre :
        • Quand utiliser : Spécifiez un intervalle de réseau uniquement si les noeuds de travail utilisent une carte VNIC secondaire pour se connecter au système de fichiers Lustre. Ce bloc CIDR doit correspondre au bloc de sous-réseau de cette carte VNIC secondaire (par exemple, 10.0.2.0/24).
        • Quand omettre : Ne spécifiez pas d'intervalle de réseau si les noeuds de travail utilisent leur carte VNIC principale (interface par défaut) pour la connectivité Lustre.
        • Important : Ce paramètre est différent du paramètre subnetId du système de fichiers Lustre, qui définit l'emplacement du système de fichiers Lustre lui-même.
      • lustrePostMountParameters: '[{"<parameter1>": <value>},{"<parameter2>": <value>}]' : Facultatif. Tableau JSON de paramètres client Lustre avancés à définir après le montage. Par exemple, lustrePostMountParameters: '[{"*.*.*MDT*.lru_size": 11200},{"at_history": 600}]'

      Par exemple :

      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. Créez la classe de stockage à partir du fichier manifeste en entrant :

      kubectl create -f <filename>

      Par exemple :

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

3. Créez une revendication de volume persistant à provisionner par le nouveau système de fichiers dans le service File Storage with Lustre, comme suit :
   1. Créez un fichier manifeste pour définir la revendication de volume persistant :

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

      où :

      • name: <pvc-name> : Obligatoire. Par exemple, lustre-dynamic-claim
      • storageClassName: "<storage-class-name>" : Obligatoire. Nom de la classe de stockage que vous avez définie précédemment. Par exemple, lustre-dyn-storage.
      • accessModes: - <ReadWriteMany|ReadOnlyOncePod> : Obligatoire. Spécifie comment le système de fichiers doit être monté et partagé par les pods. Actuellement, ReadWriteMany et ReadOnlyOncePod sont pris en charge. Par exemple : ReadWriteMany.
      • storage: <capacity> : Obligatoire. Cette valeur doit être au moins 31.2T (ou 31200G). Vous pouvez spécifier une capacité plus grande, mais vous devez utiliser des incréments particuliers qui dépendent de la capacité (voir Augmentation de la capacité du système de fichiers). Par exemple, 31.2T.

      Par exemple, le fichier manifeste suivant (nommé lustre-dyn-claim.yaml) définit une revendication de volume persistant nommée lustre-dynamic-claim qui est provisionnée par le système de fichiers défini dans la classe de stockage 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. Créez la revendication de volume persistant à partir du fichier manifeste en entrant :

      kubectl create -f <filename> 

      Par exemple :

      kubectl create -f lustre-dyn-claim.yaml

   Un nouveau PVC est créé. Le plugiciel de volume CSI crée un nouveau volume persistant et un nouveau système de fichiers dans le service File Storage with Lustre. Notez que la création d'un nouveau système de fichiers Lustre prend au moins 10 minutes et peut prendre plus de temps, selon la taille du système de fichiers. Utilisez la console ou l'interface de ligne de commande pour confirmer que le nouveau système de fichiers Lustre a été créé (voir Liste des systèmes de fichiers).

   Le nouveau PVC est lié au nouveau PV. Les données sont chiffrées au repos à l'aide de clés de chiffrement gérées par Oracle ou par vous.

4. Vérifiez que la PVC a été liée au nouveau volume persistant en entrant :

   kubectl get pvc

   Exemple de sortie :

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

5. Utilisez la nouvelle revendication de volume persistant lors de la création d'autres objets, tels que des pods. Par exemple, vous pouvez créer un nouveau pod à partir de la définition de pod suivante :

   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. Après avoir créé un nouveau pod, comme décrit dans l'exemple de l'étape précédente, vous pouvez vérifier que le pod utilise la nouvelle revendication de volume persistant en entrant :

   kubectl describe pod lustre-dynamic-app

Pour créer une revendication de volume persistant sur un système de fichiers existant dans le service de stockage de fichiers avec Lustre (à l'aide de clés de chiffrement gérées par Oracle pour chiffrer les données au repos) :

1. Créez un système de fichiers dans le service File Storage avec Lustre, en sélectionnant l'option de chiffrement Chiffrer à l'aide des clés gérées par Oracle. Voir Création d'un système de fichiers Lustre File System.
2. Créez des règles de sécurité dans un groupe de sécurité de réseau (recommandé) ou une liste de sécurité pour le système de fichiers Lustre et pour le sous-réseau de noeuds de travail de la grappe.
   Les règles de sécurité à créer dépendent des emplacements réseau relatifs du système de fichiers Lustre et des noeuds de travail qui agissent en tant que client, selon les scénarios suivants :

   • Option 1 : Client et Lustre dans différents sous-réseaux
   • Option 2 : Client et Lustre dans le même sous-réseau

   Ces scénarios, les règles de sécurité à créer et l'endroit où les créer sont décrits en détail dans la documentation du service File Storage with Lustre (voir Règles de sécurité de réseau VCN requises).

3. Créez une valeur actualisée soutenue par le système de fichiers dans le service de stockage de fichiers avec Lustre comme suit :

   1. Créez un fichier manifeste pour définir une valeur actualisée et, dans la section csi:, définissez les éléments suivants :

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

        où :

        • <MGSAddress> est l'adresse du service de gestion pour le système de fichiers du service de stockage de fichiers avec Lustre
        • <LNetName> est le nom de réseau LNet pour le système de fichiers dans le service de stockage de fichiers avec Lustre.
        • <MountName> est le nom de montage utilisé lors de la création du système de fichiers dans le service de stockage de fichiers avec Lustre.

        Par exemple : 10.0.2.6@tcp:/testlustrefs

      • fsType à lustre
      • (facultatif, mais recommandé) volumeAttributes.setupLnet à "true" si vous voulez que le pilote CSI Lustre effectue la configuration lnet (Lustre Network) avant de monter le système de fichiers.
      • (facultatif) volumeAttributes.lustreSubnetCidr pour l'intervalle de réseau source du noeud de travail utilisé pour le trafic Lustre :
        • Quand utiliser : Spécifiez un intervalle de réseau uniquement si les noeuds de travail utilisent une carte VNIC secondaire pour se connecter au système de fichiers Lustre. Ce bloc CIDR doit correspondre au bloc de sous-réseau de cette carte VNIC secondaire (par exemple, 10.0.2.0/24).
        • Quand omettre : Ne spécifiez pas d'intervalle de réseau si les noeuds de travail utilisent leur carte VNIC principale (interface par défaut) pour la connectivité Lustre.
        • Important : Ce paramètre est différent du paramètre subnetId du système de fichiers Lustre, qui définit l'emplacement du système de fichiers Lustre lui-même.
      • (Facultatif) volumeAttributes.lustrePostMountParameters pour définir les paramètres Lustre. Par exemple :

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

      Par exemple, le fichier manifeste suivant (nommé lustre-PV-example.yaml) définit un PV appelé lustre-pv-example soutenu par un système de fichiers 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. Créez le PV à partir du fichier manifeste en entrant :

      kubectl apply -f <filename>

      Par exemple :

      kubectl apply -f lustre-pv-example.yaml

   3. Vérifiez que le PV a été créé avec succès en entrant :

      kubectl get pv <pv-name>

      Par exemple :

      kubectl get pv lustre-pv-example

      Exemple de sortie :

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

4. Créez une revendication de volume persistant provisionnée par la revendication de volume persistant que vous avez créée, comme suit :
   1. Créez un fichier manifeste pour définir la revendication de volume persistant et définissez les éléments suivants :
      • storageClassName à "" Notez que vous devez spécifier une valeur vide pour storageClassName, même si la classe de stockage n'est pas applicable dans le cas du provisionnement statique du stockage persistant. Si vous ne spécifiez pas de valeur vide pour storageClassName, la classe de stockage par défaut (oci-bv) est utilisée, ce qui entraîne une erreur.
      • volumeName au nom de la valeur actualisée que vous avez créée (par exemple, lustre-pv-example)

      Par exemple, le fichier manifeste suivant (nommé lustre-PVC-example.yaml) définit une revendication de volume persistant nommée lustre-pvc-example qui sera liée à une revendication de volume persistant nommée 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

      Notez que l'élément requests: storage: doit être présent dans le fichier manifeste de la revendication de volume persistant et que sa valeur doit correspondre à la valeur spécifiée pour l'élément capacity: storage: dans le fichier manifeste de la revendication de volume persistant. En dehors de cela, la valeur de l'élément requests: storage: est ignorée.

   2. Créez la revendication de volume persistant à partir du fichier manifeste en entrant :

      kubectl apply -f <filename>

      Par exemple :

      kubectl apply -f lustre-pvc-example.yaml

   3. Vérifiez que la PVC a bien été créée et liée au PV en entrant :

      kubectl get pvc <pvc-name>

      Par exemple :

      kubectl get pvc lustre-pvc-example

      Exemple de sortie :

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

   La revendication de volume persistant est liée à la valeur actualisée soutenue par le stockage de fichiers avec le système de fichiers du service Lustre. Les données sont chiffrées au repos à l'aide de clés de chiffrement gérées par Oracle.

5. Utilisez la nouvelle revendication de volume persistant lors de la création d'autres objets, tels que des déploiements. Par exemple :
   1. Créez un manifeste nommé lustre-app-example-deployment.yaml pour définir un déploiement nommé lustre-app-example-deployment qui utilise la revendication de volume persistant lustre-pvc-example, comme suit :

      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. Créez le déploiement à partir du fichier manifeste en entrant :

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

   3. Vérifiez que les pods de déploiement ont été créés et s'exécutent en entrant :

      kubectl get pods

      Exemple de sortie :

      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