Provisionnement des demandes de volume persistant sur le stockage de fichiers avec le service Lustre

Pour provisionner dynamiquement une demande de volume persistant sur un nouveau système de fichiers Lustre créé dynamiquement par le module d'extension de volume CSI dans le service File Storage with Lustre, procédez comme suit :

1. Créez des règles de sécurité dans un groupe de sécurité 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 processus actif du cluster.

   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 processus actif qui agissent en tant que client, selon les scénarios suivants :

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

   Ces scénarios, les règles de sécurité à créer et l'emplacement où les créer, sont entièrement décrits dans la documentation du service File Storage with Lustre (reportez-vous à Règles de sécurité VCN requises).

2. Définissez une nouvelle classe de stockage qui utilise le provisionnateur lustre.csi.oraclecloud.com :
   1. Créez un fichier manifeste (par exemple, dans un fichier nommé lustre-dyn-st-class.yaml), indiquez le nom de la nouvelle classe de stockage et indiquez les valeurs des 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> : requis. Nom de votre choix pour la classe de stockage.
      • availabilityDomain: <ad-name> : requis. Nom du domaine de disponibilité dans lequel créer le nouveau système de fichiers Lustre. Par exemple, availabilityDomain: US-ASHBURN-AD-1. Pour connaître le nom de domaine de disponibilité à utiliser, exécutez la commande d'interface de ligne de commande oci iam availability-domain list (ou utilisez l'opération ListAvailabilityDomains). Pour plus d'informations, reportez-vous à 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. Si aucune valeur n'est indiquée, le compartiment par défaut est le même que celui du cluster. Par exemple, compartmentId: ocid1.compartment.oc1..aaa______t6q
      • subnetId: <subnet-ocid> : requis. 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> : requis. Niveau de performances 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 indiqué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 cryptage maître que vous gérez, avec laquelle crypter les données inactives. Si aucune valeur n'est indiquée, les données sont cryptées au repos à l'aide de clés de cryptage 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é réseau à associer au système de fichiers Lustre. Par exemple, nsgIds: '["ocid1.nsg.oc1.iad.aab______fea"]'
      • rootSquashEnabled: "<true | false>" : facultatif. Définissez la valeur sur true pour restreindre l'accès root aux clients. La valeur par défaut est false.
      • rootSquashUid: "<value>" : facultatif. Lorsque le squash root est activé, les opérations root sont mappées avec cet UID. La valeur par défaut est 65534.
      • rootSquashGid: "<value>" : facultatif. Lorsque le squash root est activé, les opérations root sont mises en correspondance avec ce GID. Par défaut, 65534 est utilisé.
      • rootSquashClientExceptions: '["<ip-address>"]' : facultatif. Tableau JSON d'adresses IP ou de blocs CIDR qui ne sont pas soumis à la courbure racine (10 entrées maximum). Par exemple, rootSquashClientExceptions: '["10.0.2.4"]'.
      • oci.oraclecloud.com/initial-defined-tags-override: '{"<tag-namespace>": {"<tag-key>": "<tag-value>"}}' Facultatif. Spécifie une balise définie pour le nouveau système de fichiers. Par exemple, oci.oraclecloud.com/initial-defined-tags-override: '{"Org": {"CostCenter": "AI"}}'

        Pour appliquer des balises définies à partir d'un espace de noms de balise appartenant à un compartiment à une ressource de système de fichiers appartenant à un autre compartiment, vous devez inclure une instruction de stratégie afin de permettre au cluster d'utiliser l'espace de noms de balise. Reportez-vous à Stratégie IAM supplémentaire lorsqu'un cluster et un espace de noms de balise se trouvent dans différents compartiments.

      • oci.oraclecloud.com/initial-freeform-tags-override: '{"<tag-key>": "<tag-value>"}' Facultatif. Spécifie une balise à format libre pour le nouveau système de fichiers. Par exemple, oci.oraclecloud.com/initial-freeform-tags-override: '{"Project": "ML"}'
      • setupLnet: "<true | false>" : facultatif. Définissez la valeur sur 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 sur "true".
      • lustreSubnetCidr: "<cidr-block>" : facultatif. Définissez la plage de réseau source du noeud de processus actif utilisée pour le trafic Lustre :
        • Quand utiliser : spécifiez uniquement une plage de réseau si les noeuds de processus actif utilisent une carte d'interface réseau virtuelle secondaire pour se connecter au système de fichiers Lustre. Ce CIDR doit correspondre au bloc de sous-réseau de cette carte d'interface réseau virtuelle secondaire (par exemple, 10.0.2.0/24).
        • A quel moment omettre : n'indiquez pas de plage réseau si les noeuds de processus actif utilisent leur carte d'interface réseau virtuelle 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 saisissant la commande suivante :

      kubectl create -f <filename>

      Par exemple :

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

3. Créez une demande 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 demande 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> : requis. Par exemple, lustre-dynamic-claim
      • storageClassName: "<storage-class-name>" : requis. Nom de la classe de stockage que vous avez définie précédemment. Par exemple, lustre-dyn-storage.
      • accessModes: - <ReadWriteMany|ReadOnlyOncePod> : requis. Indique 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> : requis. Cette valeur doit être au moins égale à 31.2T (ou 31200G). Vous pouvez spécifier une capacité plus importante, mais vous devez utiliser des incréments particuliers qui dépendent de la capacité (reportez-vous à 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 demande 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 demande de volume persistant à partir du fichier manifeste en saisissant ce qui suit :

      kubectl create -f <filename> 

      Par exemple :

      kubectl create -f lustre-dyn-claim.yaml

   Un nouveau PVC est créé. Le module d'extension de volume CSI crée un volume persistant (PV) 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 la CLI pour vérifier que le nouveau système de fichiers Lustre a été créé (reportez-vous à Liste des systèmes de fichiers).

   Le nouveau PVC est lié au nouveau PV. Les données sont cryptées lorsqu'elles sont inactives, à l'aide de clés de cryptage gérées par Oracle ou par vous.

4. Vérifiez que la demande de volume persistante a été liée àun nouveau volume persistant en saisissant cette commande :

   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 demande de volume persistant lors de la création d'autres objets, tels que des pods. Par exemple, vous pouvez créer un 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 pod comme décrit dans l'exemple de l'étape précédente, vous pouvez vérifier qu'il utilise la nouvelle demande de volume persistant en saisissant ce qui suit :

   kubectl describe pod lustre-dynamic-app

Pour créer une demande de volume persistant sur un système de fichiers existant dans le service File Storage avec Lustre (à l'aide de clés de cryptage gérées par Oracle pour crypter les données inactives), procédez comme suit :

1. Créez un système de fichiers dans File Storage avec le service Lustre, en sélectionnant l'option de cryptage Crypter à l'aide de clés gérées par Oracle. See Creating a Lustre File System.
2. Créez des règles de sécurité dans un groupe de sécurité 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 processus actif du cluster.
   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 processus actif 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'emplacement où les créer, sont entièrement décrits dans la documentation du service File Storage with Lustre (reportez-vous à Règles de sécurité VCN requises).

3. Créez un PV soutenu par le système de fichiers dans File Storage avec le service Lustre comme suit :

   1. Créez un fichier manifeste pour définir une valeur PV et, dans la section csi:, définissez :

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

        où :

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

        Par exemple : 10.0.2.6@tcp:/testlustrefs

      • fsType à lustre
      • (facultatif, mais recommandé) volumeAttributes.setupLnet à "true" si vous souhaitez que le pilote CSI Lustre effectue la configuration lnet (réseau Lustre) avant de monter le système de fichiers.
      • (Facultatif) volumeAttributes.lustreSubnetCidr à la plage de réseau source du noeud de processus actif utilisée pour le trafic Lustre :
        • Quand utiliser : spécifiez uniquement une plage de réseau si les noeuds de processus actif utilisent une carte d'interface réseau virtuelle secondaire pour se connecter au système de fichiers Lustre. Ce CIDR doit correspondre au bloc de sous-réseau de cette carte d'interface réseau virtuelle secondaire (par exemple, 10.0.2.0/24).
        • A quel moment omettre : n'indiquez pas de plage réseau si les noeuds de processus actif utilisent leur carte d'interface réseau virtuelle 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 fichier PV à partir du fichier manifeste en saisissant la commande suivante :

      kubectl apply -f <filename>

      Par exemple :

      kubectl apply -f lustre-pv-example.yaml

   3. Vérifiez que le PV a bien été créé en saisissant la commande suivante :

      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 demande de volume persistant provisionnée par la demande de modification que vous avez créée, comme suit :
   1. Créez un fichier manifeste pour définir la demande de volume persistant et définissez les éléments suivants :
      • storageClassName à "". Vous devez indiquer 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 n'indiquez 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 indique le nom de la valeur de modification que vous avez créée (par exemple, lustre-pv-example).

      Par exemple, le fichier manifeste suivant (nommé lustre-PVC-example.yaml) définit une PVC nommée lustre-pvc-example qui sera liée à une PV 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 demande 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 demande de volume persistant. En dehors de cela, la valeur de l'élément requests: storage: est ignorée.

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

      kubectl apply -f <filename>

      Par exemple :

      kubectl apply -f lustre-pvc-example.yaml

   3. Vérifiez que la PVC a été créée et liée à la PV en saisissant ce qui suit :

      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

   Le PVC est lié au PV soutenu par le système de fichiers File Storage avec service Lustre. Les données sont cryptées lorsqu'elles sont inactives à l'aide de clés de cryptage gérées par Oracle.

5. Utilisez la nouvelle demande 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 demande 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 saisissant la commande suivante :

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

   3. Vérifiez que les pods de déploiement ont été créés et sont en cours d'exécution en saisissant ce qui suit :

      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