SupportConsoleDéveloppeursCommencer un essaiContact

4.12. Stockage persistant à l'aide du stockage local

4.12.1. Stockage persistant à l'aide de volumes locaux

OpenShift Container Platform peut être approvisionné avec un stockage persistant en utilisant des volumes locaux. Les volumes persistants locaux vous permettent d'accéder aux périphériques de stockage locaux, tels qu'un disque ou une partition, en utilisant l'interface standard de demande de volume persistant.

Les volumes locaux peuvent être utilisés sans qu'il soit nécessaire de planifier manuellement les pods sur les nœuds, car le système est conscient des contraintes liées aux nœuds de volume. Toutefois, les volumes locaux restent soumis à la disponibilité du nœud sous-jacent et ne conviennent pas à toutes les applications.

Note

Les volumes locaux ne peuvent être utilisés que comme volumes persistants créés de manière statique.

4.12.1.1. Installation de l'opérateur de stockage local

L'opérateur de stockage local n'est pas installé par défaut dans OpenShift Container Platform. Utilisez la procédure suivante pour installer et configurer cet opérateur afin d'activer les volumes locaux dans votre cluster.

Conditions préalables

  • Accès à la console web ou à l'interface de ligne de commande (CLI) d'OpenShift Container Platform.

Procédure

  1. Créez le projet openshift-local-storage: 

    $ oc adm new-project openshift-local-storage

  2. Facultatif : Autoriser la création de stockage local sur les nœuds d'infrastructure.

    Vous pouvez utiliser l'opérateur de stockage local pour créer des volumes sur les nœuds d'infrastructure afin de prendre en charge des composants tels que la journalisation et la surveillance.

    Vous devez ajuster le sélecteur de nœuds par défaut afin que l'opérateur de stockage local inclue les nœuds d'infrastructure, et pas seulement les nœuds de travail.

    Pour empêcher l'opérateur de stockage local d'hériter du sélecteur par défaut de l'ensemble du cluster, entrez la commande suivante : 

    $ oc annotate project openshift-local-storage openshift.io/node-selector=''

Depuis l'interface utilisateur

Pour installer l'Opérateur de stockage local à partir de la console web, procédez comme suit :

  1. Connectez-vous à la console web de OpenShift Container Platform.
  2. Naviguez jusqu'à Operators OperatorHub.
  3. Tapez Local Storage dans le champ de filtre pour localiser l'opérateur de stockage local.
  4. Cliquez sur Install.
  5. Sur la page Install Operator, sélectionnez A specific namespace on the cluster. Sélectionnez openshift-local-storage dans le menu déroulant.
  6. Ajustez les valeurs de Update Channel et Approval Strategy aux valeurs que vous souhaitez.
  7. Cliquez sur Install.

Une fois cette opération terminée, l'opérateur de stockage local sera répertorié dans la section Installed Operators de la console web.

À partir de l'interface de programmation (CLI)

  1. Installez l'opérateur de stockage local à partir de l'interface de gestion.

    1. Exécutez la commande suivante pour obtenir la version majeure et mineure d'OpenShift Container Platform. Cette information est nécessaire pour la valeur channel dans l'étape suivante. 

      $ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
    grep -o '[0-9]*[.][0-9]*' | head -1)

    2. Créer un fichier objet YAML pour définir un groupe d'opérateurs et un abonnement pour l'opérateur de stockage local, tel que openshift-local-storage.yaml:

      Exemple openshift-local-storage.yaml

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: local-operator-group
  namespace: openshift-local-storage
spec:
  targetNamespaces:
    - openshift-local-storage
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: local-storage-operator
  namespace: openshift-local-storage
spec:
  channel: "${OC_VERSION}"
  installPlanApproval: Automatic 1
  name: local-storage-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

      1
      La politique d'approbation des utilisateurs pour un plan d'installation.

  2. Créez l'objet Opérateur de stockage local en entrant la commande suivante : 

    $ oc apply -f openshift-local-storage.yaml

    À ce stade, le gestionnaire du cycle de vie de l'opérateur (OLM) est maintenant au courant de l'existence de l'opérateur de stockage local. Une ClusterServiceVersion (CSV) pour l'opérateur devrait apparaître dans l'espace de noms cible, et les API fournies par l'opérateur devraient être disponibles pour la création.

  3. Vérifier l'installation du stockage local en contrôlant que tous les pods et l'opérateur de stockage local ont été créés :

    1. Vérifier que tous les pods nécessaires ont été créés : 

      $ oc -n openshift-local-storage get pods

      Exemple de sortie

      NAME                                      READY   STATUS    RESTARTS   AGE
local-storage-operator-746bf599c9-vlt5t   1/1     Running   0          19m

    2. Vérifiez le manifeste YAML ClusterServiceVersion (CSV) pour voir si l'opérateur de stockage local est disponible dans le projet openshift-local-storage: 

      $ oc get csvs -n openshift-local-storage

      Exemple de sortie

      NAME                                         DISPLAY         VERSION               REPLACES   PHASE
local-storage-operator.4.2.26-202003230335   Local Storage   4.2.26-202003230335              Succeeded

Lorsque toutes les vérifications ont été effectuées, l'opérateur de stockage local est installé avec succès.

4.12.1.2. Approvisionnement de volumes locaux à l'aide de l'Opérateur de stockage local

Les volumes locaux ne peuvent pas être créés par provisionnement dynamique. En revanche, des volumes persistants peuvent être créés par l'opérateur de stockage local. L'opérateur de stockage local recherche des périphériques de système de fichiers ou de volumes de blocs aux chemins d'accès spécifiés dans la ressource définie.

Conditions préalables

  • L'opérateur de stockage local est installé.

  • Vous disposez d'un disque local qui répond aux conditions suivantes :

    • Il est rattaché à un nœud.
    • Il n'est pas monté.
    • Il ne contient pas de partitions.

Procédure

  1. Créer la ressource volume local. Cette ressource doit définir les nœuds et les chemins d'accès aux volumes locaux.

    Note

    N'utilisez pas différents noms de classe de stockage pour le même périphérique. Cela entraînerait la création de plusieurs volumes persistants (PV).

    Exemple : Système de fichiers

    apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
  name: "local-disks"
  namespace: "openshift-local-storage" 1
spec:
  nodeSelector: 2
    nodeSelectorTerms:
    - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - ip-10-0-140-183
          - ip-10-0-158-139
          - ip-10-0-164-33
  storageClassDevices:
    - storageClassName: "local-sc" 3
      volumeMode: Filesystem 4
      fsType: xfs 5
      devicePaths: 6
        - /path/to/device 7

    1
    L'espace de noms dans lequel l'Opérateur de stockage local est installé.
    2
    Facultatif : Un sélecteur de nœud contenant une liste de nœuds auxquels les volumes de stockage local sont attachés. Cet exemple utilise les noms d'hôtes des nœuds, obtenus à partir de oc get node. Si aucune valeur n'est définie, l'opérateur de stockage local tentera de trouver les disques correspondants sur tous les nœuds disponibles.
    3
    Le nom de la classe de stockage à utiliser lors de la création d'objets de volumes persistants. L'Opérateur de stockage local crée automatiquement la classe de stockage si elle n'existe pas. Veillez à utiliser une classe de stockage qui identifie de manière unique cet ensemble de volumes locaux.
    4
    Le mode de volume, soit Filesystem ou Block, qui définit le type de volumes locaux.
    Note

    Un volume de blocs bruts (volumeMode: Block) n'est pas formaté avec un système de fichiers. N'utilisez ce mode que si une application fonctionnant sur le pod peut utiliser des périphériques de blocs bruts.

    5
    Système de fichiers créé lorsque le volume local est monté pour la première fois.
    6
    Chemin d'accès contenant une liste de périphériques de stockage locaux à sélectionner.
    7
    Remplacez cette valeur par le chemin d'accès de vos disques locaux à la ressource LocalVolume by-id , par exemple /dev/disk/by-id/wwn. Les PV sont créés pour ces disques locaux lorsque le provisionneur est déployé avec succès.
    Note

    Si vous exécutez OpenShift Container Platform sur des zSystems IBM avec RHEL KVM, vous devez attribuer un numéro de série à votre disque VM. Sinon, le disque VM ne peut pas être identifié après le redémarrage. Vous pouvez utiliser la commande virsh edit <VM> pour ajouter la définition <serial>mydisk</serial>.

    Exemple : Bloc

    apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
  name: "local-disks"
  namespace: "openshift-local-storage" 1
spec:
  nodeSelector: 2
    nodeSelectorTerms:
    - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - ip-10-0-136-143
          - ip-10-0-140-255
          - ip-10-0-144-180
  storageClassDevices:
    - storageClassName: "localblock-sc" 3
      volumeMode: Block 4
      devicePaths: 5
        - /path/to/device 6

    1
    L'espace de noms dans lequel l'Opérateur de stockage local est installé.
    2
    Facultatif : Un sélecteur de nœud contenant une liste de nœuds auxquels les volumes de stockage local sont attachés. Cet exemple utilise les noms d'hôtes des nœuds, obtenus à partir de oc get node. Si aucune valeur n'est définie, l'opérateur de stockage local tentera de trouver les disques correspondants sur tous les nœuds disponibles.
    3
    Le nom de la classe de stockage à utiliser lors de la création d'objets de volumes persistants.
    4
    Le mode de volume, soit Filesystem ou Block, qui définit le type de volumes locaux.
    5
    Chemin d'accès contenant une liste de périphériques de stockage locaux à sélectionner.
    6
    Remplacez cette valeur par le chemin d'accès de vos disques locaux à la ressource LocalVolume by-id , par exemple dev/disk/by-id/wwn. Les PV sont créés pour ces disques locaux lorsque le provisionneur est déployé avec succès.
    Note

    Si vous exécutez OpenShift Container Platform sur des zSystems IBM avec RHEL KVM, vous devez attribuer un numéro de série à votre disque VM. Sinon, le disque VM ne peut pas être identifié après le redémarrage. Vous pouvez utiliser la commande virsh edit <VM> pour ajouter la définition <serial>mydisk</serial>.

  2. Créez la ressource de volume local dans votre cluster OpenShift Container Platform. Spécifiez le fichier que vous venez de créer : 

    oc create -f <local-volume>.yaml

  3. Vérifiez que le provisionneur a été créé et que les ensembles de démons correspondants ont été créés : 

    $ oc get all -n openshift-local-storage

    Exemple de sortie

    NAME                                          READY   STATUS    RESTARTS   AGE
pod/diskmaker-manager-9wzms                   1/1     Running   0          5m43s
pod/diskmaker-manager-jgvjp                   1/1     Running   0          5m43s
pod/diskmaker-manager-tbdsj                   1/1     Running   0          5m43s
pod/local-storage-operator-7db4bd9f79-t6k87   1/1     Running   0          14m

NAME                                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
service/local-storage-operator-metrics   ClusterIP   172.30.135.36   <none>        8383/TCP,8686/TCP   14m

NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/diskmaker-manager   3         3         3       3            3           <none>          5m43s

NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/local-storage-operator   1/1     1            1           14m

NAME                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/local-storage-operator-7db4bd9f79   1         1         1       14m

    Notez le nombre souhaité et le nombre actuel de processus du jeu de démons. Un nombre souhaité de 0 indique que les sélecteurs d'étiquettes n'étaient pas valides.

  4. Vérifiez que les volumes persistants ont été créés : 

    $ oc get pv

    Exemple de sortie

    NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
local-pv-1cec77cf   100Gi      RWO            Delete           Available           local-sc                88m
local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           local-sc                82m
local-pv-3fa1c73    100Gi      RWO            Delete           Available           local-sc                48m

Important

La modification de l'objet LocalVolume ne modifie pas les objets fsType ou volumeMode des volumes persistants existants, car cela pourrait entraîner une opération destructive.

4.12.1.3. Approvisionnement de volumes locaux sans l'Opérateur de stockage local

Les volumes locaux ne peuvent pas être créés par provisionnement dynamique. En revanche, des volumes persistants peuvent être créés en définissant le volume persistant (PV) dans une définition d'objet. Le provisionneur de volumes locaux recherche tous les périphériques de système de fichiers ou de volumes de blocs aux chemins d'accès spécifiés dans la ressource définie.

Important

Le provisionnement manuel des PV comporte le risque de fuites de données potentielles à travers la réutilisation des PV lorsque les PVC sont supprimés. L'opérateur de stockage local est recommandé pour automatiser le cycle de vie des dispositifs lors de l'approvisionnement des PV locaux.

Conditions préalables

  • Les disques locaux sont attachés aux nœuds d'OpenShift Container Platform.

Procédure

  1. Définir le PV. Créez un fichier, tel que example-pv-filesystem.yaml ou example-pv-block.yaml, avec la définition de l'objet PersistentVolume. Cette ressource doit définir les nœuds et les chemins d'accès aux volumes locaux.

    Note

    N'utilisez pas différents noms de classe de stockage pour le même appareil. Cela entraînerait la création de plusieurs PV.

    exemple-pv-filesystem.yaml

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv-filesystem
spec:
  capacity:
    storage: 100Gi
  volumeMode: Filesystem 1
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage 2
  local:
    path: /dev/xvdf 3
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - example-node

    1
    Le mode de volume, soit Filesystem ou Block, qui définit le type de PV.
    2
    Nom de la classe de stockage à utiliser lors de la création de ressources PV. Utiliser une classe de stockage qui identifie de manière unique cet ensemble de PV.
    3
    Le chemin d'accès contenant une liste de périphériques de stockage locaux à choisir, ou un répertoire. Vous ne pouvez spécifier un répertoire qu'avec Filesystem volumeMode .
    Note

    Un volume de blocs bruts (volumeMode: block) n'est pas formaté avec un système de fichiers. N'utilisez ce mode que si une application fonctionnant sur le pod peut utiliser des périphériques de blocs bruts.

    exemple-pv-block.yaml

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv-block
spec:
  capacity:
    storage: 100Gi
  volumeMode: Block 1
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage 2
  local:
    path: /dev/xvdf 3
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - example-node

    1
    Le mode de volume, soit Filesystem ou Block, qui définit le type de PV.
    2
    Nom de la classe de stockage à utiliser lors de la création de ressources PV. Veillez à utiliser une classe de stockage qui identifie de manière unique cet ensemble de PV.
    3
    Chemin d'accès contenant une liste de périphériques de stockage locaux à sélectionner.

  2. Créez la ressource PV dans votre cluster OpenShift Container Platform. Spécifiez le fichier que vous venez de créer : 

    oc create -f <example-pv>.yaml

  3. Vérifier que le PV local a été créé : 

    $ oc get pv

    Exemple de sortie

    NAME                    CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                STORAGECLASS    REASON   AGE
example-pv-filesystem   100Gi      RWO            Delete           Available                        local-storage            3m47s
example-pv1             1Gi        RWO            Delete           Bound       local-storage/pvc1   local-storage            12h
example-pv2             1Gi        RWO            Delete           Bound       local-storage/pvc2   local-storage            12h
example-pv3             1Gi        RWO            Delete           Bound       local-storage/pvc3   local-storage            12h

4.12.1.4. Création de la revendication de volume persistant du volume local

Les volumes locaux doivent être créés de manière statique en tant que revendication de volume persistant (PVC) pour être accessibles par le pod.

Conditions préalables

  • Des volumes persistants ont été créés à l'aide du provisionneur de volumes local.

Procédure

  1. Créer le PVC en utilisant la classe de stockage correspondante : 

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: local-pvc-name 1
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem 2
  resources:
    requests:
      storage: 100Gi 3
  storageClassName: local-sc 4
    1
    Nom du PVC.
    2
    Le type de PVC. La valeur par défaut est Filesystem.
    3
    La quantité de stockage disponible pour le PVC.
    4
    Nom de la classe de stockage requise par la demande.

  2. Créez le PVC dans le cluster OpenShift Container Platform, en spécifiant le fichier que vous venez de créer : 

    oc create -f <local-pvc>.yaml

4.12.1.5. Joindre la demande locale

Une fois qu'un volume local a été mis en correspondance avec une demande de volume persistant, il peut être spécifié à l'intérieur d'une ressource.

Conditions préalables

  • Une demande de volume persistant existe dans le même espace de noms.

Procédure

  1. Inclure la revendication définie dans la spécification de la ressource. L'exemple suivant déclare la revendication de volume persistant à l'intérieur d'un pod : 

    apiVersion: v1
kind: Pod
spec:
  ...
  containers:
    volumeMounts:
    - name: local-disks 1
      mountPath: /data 2
  volumes:
  - name: localpvc
    persistentVolumeClaim:
      claimName: local-pvc-name 3
    1
    Le nom du volume à monter.
    2
    Le chemin à l'intérieur du module où le volume est monté. Ne montez pas le volume sur la racine du conteneur, /, ou sur un chemin identique dans l'hôte et dans le conteneur. Cela peut corrompre votre système hôte si le conteneur est suffisamment privilégié, comme l'hôte /dev/pts files. Vous pouvez monter l'hôte en toute sécurité en utilisant /host.
    3
    Le nom de la revendication de volume persistant existante à utiliser.

  2. Créez la ressource dans le cluster OpenShift Container Platform, en spécifiant le fichier que vous venez de créer : 

    oc create -f <local-pod>.yaml

4.12.1.6. Automatisation de la découverte et de l'approvisionnement des périphériques de stockage locaux

L'opérateur de stockage local automatise la découverte et le provisionnement du stockage local. Grâce à cette fonctionnalité, vous pouvez simplifier l'installation lorsque le provisionnement dynamique n'est pas disponible lors du déploiement, comme dans le cas d'instances de stockage bare metal, VMware ou AWS avec des périphériques connectés.

Important

La découverte et le provisionnement automatiques sont des fonctionnalités de l'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

La procédure suivante permet de découvrir automatiquement les périphériques locaux et d'approvisionner automatiquement les volumes locaux pour les périphériques sélectionnés.

Avertissement

Utilisez l'objet LocalVolumeSet avec prudence. Lorsque vous provisionnez automatiquement des volumes persistants (PV) à partir de disques locaux, les PV locaux peuvent réclamer tous les périphériques qui correspondent. Si vous utilisez un objet LocalVolumeSet, assurez-vous que l'opérateur de stockage local est la seule entité à gérer les périphériques locaux sur le nœud.

Conditions préalables

  • Vous avez des droits d'administrateur de cluster.
  • Vous avez installé l'Opérateur de stockage local.
  • Vous avez attaché des disques locaux aux nœuds d'OpenShift Container Platform.
  • Vous avez accès à la console web d'OpenShift Container Platform et à l'interface de ligne de commande (CLI) oc.

Procédure

  1. Pour activer la découverte automatique des appareils locaux à partir de la console web :

    1. Dans la perspective Administrator, naviguez vers Operators Installed Operators et cliquez sur l'onglet Local Volume Discovery.
    2. Cliquez sur Create Local Volume Discovery.

    3. Sélectionnez All nodes ou Select nodes, selon que vous souhaitez découvrir les disques disponibles sur tous les nœuds ou sur des nœuds spécifiques.

      Note

      Seuls les nœuds de travail sont disponibles, que vous filtriez à l'aide de All nodes ou de Select nodes.

    4. Cliquez sur Create.

Une instance de découverte de volume local nommée auto-discover-devices est affichée.

  1. Pour afficher une liste continue des dispositifs disponibles sur un nœud :

    1. Connectez-vous à la console web de OpenShift Container Platform.
    2. Naviguez jusqu'à Compute Nodes.
    3. Cliquez sur le nom du nœud que vous souhaitez ouvrir. La page "Détails du nœud" s'affiche.

    4. Sélectionnez l'onglet Disks pour afficher la liste des appareils sélectionnés.

      La liste des périphériques est mise à jour en permanence au fur et à mesure que des disques locaux sont ajoutés ou supprimés. Vous pouvez filtrer les périphériques par nom, état, type, modèle, capacité et mode.

  2. Pour provisionner automatiquement des volumes locaux pour les appareils découverts à partir de la console web :

    1. Naviguez jusqu'à Operators Installed Operators et sélectionnez Local Storage dans la liste des opérateurs.
    2. Sélectionnez Local Volume Set Create Local Volume Set.
    3. Saisissez un nom d'ensemble de volumes et un nom de classe de stockage.

    4. Choisissez All nodes ou Select nodes pour appliquer des filtres en conséquence.

      Note

      Seuls les nœuds de travail sont disponibles, que vous filtriez à l'aide de All nodes ou de Select nodes.

    5. Sélectionnez le type de disque, le mode, la taille et la limite que vous souhaitez appliquer à l'ensemble de volumes locaux, puis cliquez sur Create.

      Un message s'affiche au bout de quelques minutes, indiquant que l'opérateur s'est réconcilié avec succès

  1. Il est également possible de provisionner des volumes locaux pour les appareils découverts à partir de la CLI :

    1. Créez un fichier objet YAML pour définir l'ensemble de volumes locaux, tel que local-volume-set.yaml, comme indiqué dans l'exemple suivant : 

      apiVersion: local.storage.openshift.io/v1alpha1
kind: LocalVolumeSet
metadata:
  name: example-autodetect
spec:
  nodeSelector:
    nodeSelectorTerms:
      - matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
              - worker-0
              - worker-1
  storageClassName: example-storageclass 1
  volumeMode: Filesystem
  fsType: ext4
  maxDeviceCount: 10
  deviceInclusionSpec:
    deviceTypes: 2
      - disk
      - part
    deviceMechanicalProperties:
      - NonRotational
    minSize: 10G
    maxSize: 100G
    models:
      - SAMSUNG
      - Crucial_CT525MX3
    vendors:
      - ATA
      - ST2000LM
      1
      Détermine la classe de stockage qui est créée pour les volumes persistants provisionnés à partir de périphériques découverts. L'Opérateur de stockage local crée automatiquement la classe de stockage si elle n'existe pas. Veillez à utiliser une classe de stockage qui identifie de manière unique cet ensemble de volumes locaux.
      2
      Lors de l'utilisation de la fonction de jeu de volumes locaux, l'Opérateur de stockage local ne prend pas en charge l'utilisation de périphériques de gestion de volumes logiques (LVM).

    2. Créer l'objet jeu de volume local : 

      $ oc apply -f local-volume-set.yaml

    3. Vérifiez que les volumes persistants locaux ont été provisionnés dynamiquement en fonction de la classe de stockage : 

      $ oc get pv

      Exemple de sortie

      NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS           REASON   AGE
local-pv-1cec77cf   100Gi      RWO            Delete           Available           example-storageclass            88m
local-pv-2ef7cd2a   100Gi      RWO            Delete           Available           example-storageclass            82m
local-pv-3fa1c73    100Gi      RWO            Delete           Available           example-storageclass            48m

Note

Les résultats sont supprimés après avoir été retirés du nœud. Les liens symboliques doivent être supprimés manuellement.

4.12.1.7. Utilisation des tolérances avec les pods de l'opérateur de stockage local

Il est possible d'appliquer des restrictions aux nœuds pour les empêcher d'exécuter des charges de travail générales. Pour permettre à l'opérateur de stockage local d'utiliser des nœuds altérés, vous devez ajouter des tolérances à la définition de Pod ou DaemonSet. Cela permet aux ressources créées de s'exécuter sur ces nœuds altérés.

Vous appliquez des tolérances au pod de l'opérateur de stockage local via la ressource LocalVolume et vous appliquez des altérations à un nœud via la spécification de nœud. Une tare sur un nœud indique au nœud de repousser tous les modules qui ne tolèrent pas la tare. L'utilisation d'une tare spécifique qui n'est pas présente sur d'autres modules garantit que le module de l'opérateur de stockage local peut également fonctionner sur ce nœud.

Important

Les plaintes et les tolérances se composent d'une clé, d'une valeur et d'un effet. En tant qu'argument, il est exprimé sous la forme key=value:effect. Un opérateur permet de laisser l'un de ces paramètres vide.

Conditions préalables

  • L'opérateur de stockage local est installé.
  • Les disques locaux sont attachés aux nœuds d'OpenShift Container Platform avec un taint.
  • Les nœuds altérés sont censés fournir un stockage local.

Procédure

Pour configurer les volumes locaux en vue de leur ordonnancement sur les nœuds altérés :

  1. Modifiez le fichier YAML qui définit le site Pod et ajoutez la spécification LocalVolume, comme indiqué dans l'exemple suivant : 

      apiVersion: "local.storage.openshift.io/v1"
  kind: "LocalVolume"
  metadata:
    name: "local-disks"
    namespace: "openshift-local-storage"
  spec:
    tolerations:
      - key: localstorage 1
        operator: Equal 2
        value: "localstorage" 3
    storageClassDevices:
        - storageClassName: "localblock-sc"
          volumeMode: Block 4
          devicePaths: 5
            - /dev/xvdg
    1
    Spécifiez la clé que vous avez ajoutée au nœud.
    2
    Indiquez l'opérateur Equal pour exiger que les paramètres key/value correspondent. Si l'opérateur est Exists, le système vérifie que la clé existe et ignore la valeur. Si l'opérateur est Equal, la clé et la valeur doivent correspondre.
    3
    Indiquer la valeur local du nœud altéré.
    4
    Le mode de volume, soit Filesystem ou Block, définissant le type de volumes locaux.
    5
    Chemin d'accès contenant une liste de périphériques de stockage locaux à sélectionner.

  2. Facultatif : Pour créer des volumes persistants locaux uniquement sur les nœuds altérés, modifiez le fichier YAML et ajoutez la spécification LocalVolume, comme indiqué dans l'exemple suivant : 

    spec:
  tolerations:
    - key: node-role.kubernetes.io/master
      operator: Exists

Les tolérances définies seront transmises aux ensembles de démons résultants, ce qui permettra de créer des pods de disquaire et de provisionneur pour les nœuds qui contiennent les taches spécifiées.

4.12.1.8. Paramètres de l'opérateur de stockage local

OpenShift Container Platform fournit les mesures suivantes pour l'opérateur de stockage local :

  • lso_discovery_disk_countnombre total de dispositifs découverts sur chaque nœud
  • lso_lvset_provisioned_PV_countnombre total de PV créés par les objets LocalVolumeSet
  • lso_lvset_unmatched_disk_countnombre total de disques que l'opérateur de stockage local n'a pas sélectionnés pour le provisionnement en raison de critères non concordants
  • lso_lvset_orphaned_symlink_countnombre d'appareils dont les PV ne correspondent plus aux critères de l'objet LocalVolumeSet
  • lso_lv_orphaned_symlink_countnombre d'appareils dont les PV ne correspondent plus aux critères de l'objet LocalVolume
  • lso_lv_provisioned_PV_countnombre total de PV provisionnées pour LocalVolume

Pour utiliser ces mesures, veillez à.. :

  • Activer la prise en charge de la surveillance lors de l'installation de l'Opérateur de stockage local.
  • Lors de la mise à jour vers OpenShift Container Platform 4.9 ou une version ultérieure, activez le support métrique manuellement en ajoutant le label operator-metering=true à l'espace de noms.

Pour plus d'informations sur les métriques, voir Gestion des métriques.

4.12.1.9. Suppression des ressources de l'opérateur de stockage local

4.12.1.9.1. Suppression d'un volume local ou d'un ensemble de volumes locaux

Il arrive que des volumes locaux et des ensembles de volumes locaux doivent être supprimés. Bien que la suppression de l'entrée dans la ressource et la suppression du volume persistant suffisent généralement, si vous souhaitez réutiliser le même chemin d'accès au périphérique ou le faire gérer par une classe de stockage différente, des étapes supplémentaires sont nécessaires.

Note

La procédure suivante présente un exemple de suppression d'un volume local. La même procédure peut également être utilisée pour supprimer les liens symboliques d'une ressource personnalisée d'un ensemble de volumes locaux.

Conditions préalables

  • Le volume persistant doit être dans un état Released ou Available.

    Avertissement

    La suppression d'un volume persistant encore en cours d'utilisation peut entraîner la perte ou la corruption de données.

Procédure

  1. Modifiez le volume local précédemment créé pour supprimer les disques indésirables.

    1. Modifiez la ressource du cluster : 

      oc edit localvolume <name> -n openshift-local-storage
    2. Naviguez jusqu'aux lignes sous devicePaths, et supprimez tous les disques non désirés.

  2. Supprimer tous les volumes persistants créés. 

    oc delete pv <pv-name> $ oc delete pv <pv-name>

  3. Supprimer tous les liens symboliques sur le nœud.

    Avertissement

    L'étape suivante consiste à accéder à un nœud en tant qu'utilisateur racine. La modification de l'état du nœud au-delà des étapes de cette procédure peut entraîner une instabilité de la grappe.

    1. Créer un pod de débogage sur le nœud : 

      $ oc debug node/<node-name>

    2. Changez votre répertoire racine en /host: 

      $ chroot /host

    3. Naviguez jusqu'au répertoire contenant les liens symboliques du volume local. 

      $ cd /mnt/openshift-local-storage/<sc-name> 1
      1
      Le nom de la classe de stockage utilisée pour créer les volumes locaux.

    4. Supprimer le lien symbolique appartenant à l'appareil supprimé. 

      $ rm <symlink>
4.12.1.9.2. Désinstallation de l'opérateur de stockage local

Pour désinstaller l'Opérateur de stockage local, vous devez supprimer l'Opérateur et toutes les ressources créées dans le projet openshift-local-storage.

Avertissement

Il n'est pas recommandé de désinstaller l'Opérateur de stockage local lorsque des PV de stockage local sont encore utilisés. Bien que les PV soient conservées après la suppression de l'opérateur, il peut y avoir un comportement indéterminé si l'opérateur est désinstallé et réinstallé sans supprimer les PV et les ressources de stockage local.

Conditions préalables

  • Accès à la console web d'OpenShift Container Platform.

Procédure

  1. Supprimez toutes les ressources de volume local installées dans le projet, telles que localvolume, localvolumeset, et localvolumediscovery: 

    $ oc delete localvolume --all --all-namespaces
$ oc delete localvolumeset --all --all-namespaces
$ oc delete localvolumediscovery --all --all-namespaces

  2. Désinstallez l'Opérateur de stockage local à partir de la console web.

    1. Connectez-vous à la console web de OpenShift Container Platform.
    2. Naviguez jusqu'à Operators Installed Operators.
    3. Tapez Local Storage dans le champ de filtre pour localiser l'opérateur de stockage local.
    4. Cliquez sur le menu Options kebab à la fin de l'opérateur de stockage local.
    5. Cliquez sur Uninstall Operator.
    6. Cliquez sur Remove dans la fenêtre qui s'affiche.

  3. Les PV créés par l'Opérateur de stockage local resteront dans le cluster jusqu'à ce qu'ils soient supprimés. Une fois que ces volumes ne sont plus utilisés, supprimez-les en exécutant la commande suivante : 

    oc delete pv <pv-name> $ oc delete pv <pv-name>

  4. Supprimer le projet openshift-local-storage: 

    $ oc delete project openshift-local-storage

4.12.2. Stockage persistant à l'aide de hostPath

Un volume hostPath dans un cluster OpenShift Container Platform monte un fichier ou un répertoire du système de fichiers du nœud hôte dans votre pod. La plupart des pods n'auront pas besoin d'un volume hostPath, mais il offre une option rapide pour les tests si une application le nécessite.

Important

L'administrateur du cluster doit configurer les pods pour qu'ils fonctionnent de manière privilégiée. Cela permet d'accéder aux pods du même nœud.

4.12.2.1. Vue d'ensemble

OpenShift Container Platform prend en charge le montage hostPath pour le développement et les tests sur un cluster à nœud unique.

Dans un cluster de production, vous n'utiliserez pas hostPath. Au lieu de cela, un administrateur de cluster provisionnerait une ressource réseau, telle qu'un volume GCE Persistent Disk, un partage NFS ou un volume Amazon EBS. Les ressources réseau prennent en charge l'utilisation des classes de stockage pour configurer le provisionnement dynamique.

Un volume hostPath doit être provisionné de manière statique.

Important

Ne montez pas sur la racine du conteneur, /, ou tout autre chemin identique sur l'hôte et le conteneur. Cela peut corrompre votre système hôte si le conteneur est suffisamment privilégié. Il est prudent de monter l'hôte en utilisant /host. L'exemple suivant montre que le répertoire / de l'hôte est monté dans le conteneur à l'adresse /host. 

apiVersion: v1
kind: Pod
metadata:
  name: test-host-mount
spec:
  containers:
  - image: registry.access.redhat.com/ubi8/ubi
    name: test-container
    command: ['sh', '-c', 'sleep 3600']
    volumeMounts:
    - mountPath: /host
      name: host-slash
  volumes:
   - name: host-slash
     hostPath:
       path: /
       type: ''

4.12.2.2. Approvisionnement statique des volumes hostPath

Un pod qui utilise un volume hostPath doit être référencé par un provisionnement manuel (statique).

Procédure

  1. Définir le volume persistant (PV). Créer un fichier, pv.yaml, avec la définition de l'objet PersistentVolume: 

      apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: task-pv-volume 1
    labels:
      type: local
  spec:
    storageClassName: manual 2
    capacity:
      storage: 5Gi
    accessModes:
      - ReadWriteOnce 3
    persistentVolumeReclaimPolicy: Retain
    hostPath:
      path: "/mnt/data" 4
    1
    Le nom du volume. Ce nom est la façon dont il est identifié par les réclamations de volumes persistants ou les pods.
    2
    Utilisé pour lier les demandes de réclamation de volume persistant à ce volume persistant.
    3
    Le volume peut être monté comme read-write par un seul nœud.
    4
    Le fichier de configuration spécifie que le volume se trouve à /mnt/data sur le nœud du cluster. Ne montez pas sur la racine du conteneur, /, ou tout autre chemin identique sur l'hôte et le conteneur. Cela peut corrompre votre système hôte. Vous pouvez monter l'hôte en toute sécurité en utilisant /host.

  2. Créer le PV à partir du fichier : 

    $ oc create -f pv.yaml

  3. Définir la revendication de volume persistant (PVC). Créez un fichier, pvc.yaml, avec la définition de l'objet PersistentVolumeClaim: 

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pvc-volume
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: manual

  4. Créer le PVC à partir du fichier : 

    $ oc create -f pvc.yaml

4.12.2.3. Montage du partage hostPath dans un pod privilégié

Une fois que la demande de volume persistant a été créée, elle peut être utilisée à l'intérieur par une application. L'exemple suivant montre le montage de ce partage à l'intérieur d'un pod.

Conditions préalables

  • Il existe une revendication de volume persistant qui est mappée au partage hostPath sous-jacent.

Procédure

  • Créer un pod privilégié qui monte la revendication de volume persistant existante : 

    apiVersion: v1
kind: Pod
metadata:
  name: pod-name 1
spec:
  containers:
    ...
    securityContext:
      privileged: true 2
    volumeMounts:
    - mountPath: /data 3
      name: hostpath-privileged
  ...
  securityContext: {}
  volumes:
    - name: hostpath-privileged
      persistentVolumeClaim:
        claimName: task-pvc-volume 4
    1
    Le nom du pod.
    2
    Le pod doit être exécuté en tant que privilégié pour accéder au stockage du nœud.
    3
    Le chemin pour monter le partage du chemin de l'hôte à l'intérieur du pod privilégié. Ne montez pas sur la racine du conteneur, /, ou tout autre chemin qui est le même dans l'hôte et le conteneur. Cela peut corrompre votre système hôte si le conteneur est suffisamment privilégié, comme les fichiers de l'hôte /dev/pts. Vous pouvez monter l'hôte en toute sécurité en utilisant /host.
    4
    Le nom de l'objet PersistentVolumeClaim qui a été créé précédemment.

4.12.3. Stockage persistant à l'aide du gestionnaire de volume logique

Logical volume manager storage (LVM Storage) utilise le pilote TopoLVM CSI pour provisionner dynamiquement le stockage local sur les clusters OpenShift à nœud unique.

LVM Storage crée des volumes à provisionnement fin à l'aide de Logical Volume Manager et fournit un provisionnement dynamique du stockage en bloc sur un cluster OpenShift à nœud unique aux ressources limitées.

4.12.3.1. Déployer le stockage LVM sur des clusters OpenShift à nœud unique

Vous pouvez déployer LVM Storage sur un nœud unique d'OpenShift bare-metal ou sur un cluster d'infrastructure fourni par l'utilisateur et le configurer pour provisionner dynamiquement le stockage pour vos charges de travail.

Le stockage LVM crée un groupe de volumes utilisant tous les disques inutilisés disponibles et crée un thin pool unique d'une taille correspondant à 90 % du groupe de volumes. Les 10 % restants du groupe de volumes sont laissés libres pour permettre la récupération des données en élargissant le thin pool en cas de besoin. Il se peut que vous deviez effectuer manuellement cette récupération.

Vous pouvez utiliser les réclamations de volumes persistants (PVC) et les instantanés de volumes fournis par le stockage LVM pour demander de l'espace de stockage et créer des instantanés de volumes.

LVM Storage configure une limite d'overprovisioning par défaut de 10 pour tirer parti de la fonction de thin-provisioning. La taille totale des volumes et des instantanés de volume qui peuvent être créés sur les clusters OpenShift à nœud unique est 10 fois supérieure à la taille du thin pool.

Vous pouvez déployer le stockage LVM sur des clusters OpenShift à nœud unique en utilisant l'une des méthodes suivantes :

  • Red Hat Advanced Cluster Management (RHACM)
  • Console Web de la plateforme OpenShift Container
4.12.3.1.1. Requirements

Avant de commencer à déployer le stockage LVM sur des clusters OpenShift à nœud unique, assurez-vous que les conditions suivantes sont remplies :

  • Vous avez installé Red Hat Advanced Cluster Management (RHACM) sur un cluster OpenShift Container Platform.
  • Chaque cluster OpenShift géré à un seul nœud dispose de disques dédiés qui sont utilisés pour provisionner le stockage.

Avant de déployer le stockage LVM sur des clusters OpenShift à nœud unique, soyez conscient des limitations suivantes :

  • Vous ne pouvez créer qu'une seule instance de la ressource personnalisée (CR) LVMCluster sur un cluster OpenShift Container Platform.
  • Vous ne pouvez effectuer qu'une seule entrée deviceClass dans le CR LVMCluster.
  • Lorsqu'un dispositif est intégré dans le CR LVMCluster, il ne peut plus être supprimé.
4.12.3.1.2. Limites

Pour le déploiement d'OpenShift à nœud unique, le stockage LVM présente les limitations suivantes :

  • La taille totale du stockage est limitée par la taille du thin pool sous-jacent du Logical Volume Manager (LVM) et par le facteur de surprovisionnement.

  • La taille du volume logique dépend de la taille de l'étendue physique (PE) et de l'étendue logique (LE).

    • Il est possible de définir la taille des PE et LE lors de la création des dispositifs physiques et logiques.
    • La taille par défaut des PE et LE est de 4 Mo.
    • Si la taille du PE est augmentée, la taille maximale du LVM est déterminée par les limites du noyau et votre espace disque.
Tableau 4.1. Limites de taille pour différentes architectures en utilisant la taille par défaut des PE et LE
ArchitectureRHEL 5RHEL 6RHEL 7RHEL 8

32 bits

16 TB

16 TB

-

-

64 bits

8 EB [1]

8 EB [1]

100 TB [2]

8 EB [1]

500 TB [2]

8 EB

  1. Taille théorique.
  2. Taille testée.

Ressources supplémentaires

4.12.3.1.3. Installation du stockage LVM à l'aide de la console Web d'OpenShift Container Platform

Vous pouvez installer LVM Storage à l'aide de Red Hat OpenShift Container Platform OperatorHub.

Conditions préalables

  • Vous avez accès au cluster OpenShift à nœud unique.
  • Vous utilisez un compte disposant des autorisations d'installation cluster-admin et Operator.

Procédure

  1. Connectez-vous à la console Web de OpenShift Container Platform.
  2. Cliquez sur Operators OperatorHub.
  3. Faites défiler ou tapez LVM Storage dans la boîte Filter by keyword pour trouver LVM Storage.
  4. Cliquez sur Install.

  5. Définissez les options suivantes sur la page Install Operator:

    1. Update Channel comme stable-4.12.
    2. Installation Mode comme A specific namespace on the cluster.
    3. Installed Namespace comme Operator recommended namespace openshift-storage. Si l'espace de noms openshift-storage n'existe pas, il est créé lors de l'installation de l'opérateur.

    4. Approval Strategy comme Automatic ou Manual.

      Si vous sélectionnez Automatic updates, l'Operator Lifecycle Manager (OLM) met automatiquement à jour l'instance en cours d'exécution de votre opérateur sans aucune intervention.

      Si vous sélectionnez Manual updates, l'OLM crée une demande de mise à jour. En tant qu'administrateur de cluster, vous devez ensuite approuver manuellement cette demande de mise à jour pour que l'opérateur passe à une version plus récente.

  6. Cliquez sur Install.

Verification steps

  • Vérifiez que LVM Storage affiche une coche verte, ce qui indique que l'installation a réussi.
4.12.3.1.4. Désinstallation du stockage LVM installé à l'aide de la console Web OpenShift

Vous pouvez désinstaller le stockage LVM à l'aide de la console Web de Red Hat OpenShift Container Platform.

Conditions préalables

  • Vous avez supprimé toutes les applications sur les clusters qui utilisent le stockage provisionné par LVM Storage.
  • Vous avez supprimé les réclamations de volumes persistants (PVC) et les volumes persistants (PV) provisionnés à l'aide de LVM Storage.
  • Vous avez supprimé tous les instantanés de volume fournis par LVM Storage.
  • Vous avez vérifié qu'il n'existe aucune ressource de volume logique en utilisant la commande oc get logicalvolume.
  • Vous avez accès au cluster OpenShift à nœud unique en utilisant un compte avec les permissions cluster-admin.

Procédure

  1. À partir de la page Operators Installed Operators, faites défiler jusqu'à LVM Storage ou tapez LVM Storage dans Filter by name pour le trouver et cliquez dessus.
  2. Cliquez sur l'onglet LVMCluster.
  3. Dans la partie droite de la page LVMCluster, sélectionnez Delete LVMCluster dans le menu déroulant Actions.
  4. Cliquez sur l'onglet Details.
  5. Dans la partie droite de la page Operator Details, sélectionnez Uninstall Operator dans le menu déroulant Actions.
  6. Sélectionnez Remove. LVM Storage cesse de fonctionner et est complètement supprimé.
4.12.3.1.5. Installation du stockage LVM à l'aide de RHACM

Le stockage LVM est déployé sur des clusters OpenShift à nœud unique à l'aide de Red Hat Advanced Cluster Management (RHACM). Vous créez un objet Policy sur RHACM qui déploie et configure l'opérateur lorsqu'il est appliqué aux clusters gérés qui correspondent au sélecteur spécifié dans la ressource PlacementRule. La politique est également appliquée aux clusters importés ultérieurement et qui satisfont à la règle de placement.

Conditions préalables

  • Accès au cluster RHACM à l'aide d'un compte disposant des autorisations d'installation cluster-admin et Operator.
  • Disques dédiés sur chaque cluster OpenShift à nœud unique à utiliser par le stockage LVM.
  • Le cluster OpenShift à nœud unique doit être géré par RHACM, soit importé, soit créé.

Procédure

  1. Connectez-vous au CLI RHACM en utilisant vos identifiants OpenShift Container Platform.

  2. Créez un espace de noms dans lequel vous créerez des politiques. 

    # oc create ns lvms-policy-ns

  3. Pour créer une politique, enregistrez le fichier YAML suivant dans un fichier portant un nom tel que policy-lvms-operator.yaml: 

    apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-install-lvms
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector: 1
    matchExpressions:
    - key: mykey
      operator: In
      values:
      - myvalue
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-install-lvms
placementRef:
  apiGroup: apps.open-cluster-management.io
  kind: PlacementRule
  name: placement-install-lvms
subjects:
- apiGroup: policy.open-cluster-management.io
  kind: Policy
  name: install-lvms
---
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  annotations:
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    policy.open-cluster-management.io/standards: NIST SP 800-53
  name: install-lvms
spec:
  disabled: false
  remediationAction: enforce
  policy-templates:
  - objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name: install-lvms
      spec:
        object-templates:
        - complianceType: musthave
          objectDefinition:
            apiVersion: v1
            kind: Namespace
            metadata:
              labels:
                openshift.io/cluster-monitoring: "true"
                pod-security.kubernetes.io/enforce: privileged
                pod-security.kubernetes.io/audit: privileged
                pod-security.kubernetes.io/warn: privileged
              name: openshift-storage
        - complianceType: musthave
          objectDefinition:
            apiVersion: operators.coreos.com/v1
            kind: OperatorGroup
            metadata:
              name: openshift-storage-operatorgroup
              namespace: openshift-storage
            spec:
              targetNamespaces:
              - openshift-storage
        - complianceType: musthave
          objectDefinition:
            apiVersion: operators.coreos.com/v1alpha1
            kind: Subscription
            metadata:
              name: lvms
              namespace: openshift-storage
            spec:
              installPlanApproval: Automatic
              name: lvms-operator
              source: redhat-operators
              sourceNamespace: openshift-marketplace
        remediationAction: enforce
        severity: low
  - objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name: lvms
      spec:
        object-templates:
           - complianceType: musthave
             objectDefinition:
               apiVersion: lvm.topolvm.io/v1alpha1
               kind: LVMCluster
               metadata:
                 name: my-lvmcluster
                 namespace: openshift-storage
               spec:
                 storage:
                   deviceClasses:
                   - name: vg1
                     deviceSelector: 2
                       paths:
                       - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
                       - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
                     thinPoolConfig:
                       name: thin-pool-1
                       sizePercent: 90
                       overprovisionRatio: 10
                     nodeSelector: 3
                       nodeSelectorTerms:
                       - matchExpressions:
                           - key: app
                             operator: In
                             values:
                             - test1
        remediationAction: enforce
        severity: low
    1
    Remplacez la clé et la valeur dans PlacementRule.spec.clusterSelector pour correspondre aux étiquettes définies sur les clusters OpenShift à nœud unique sur lesquels vous souhaitez installer LVM Storage.
    2
    Pour contrôler ou restreindre le groupe de volumes à vos disques préférés, vous pouvez spécifier manuellement les chemins d'accès locaux des disques dans la section deviceSelector du fichier YAML LVMCluster.
    3
    Pour ajouter un filtre de nœuds, qui est un sous-ensemble de nœuds de travail supplémentaires, spécifiez le filtre requis dans la section nodeSelector. LVM Storage détecte et utilise les nœuds de travail supplémentaires lorsqu'ils apparaissent.
    Important

    Cette correspondance de filtre de nœud nodeSelector n'est pas la même que la correspondance d'étiquette de pod.

  4. Créez la politique dans l'espace de noms en exécutant la commande suivante : 

    # oc create -f policy-lvms-operator.yaml -n lvms-policy-ns 1
    1
    L'adresse policy-lvms-operator.yaml est le nom du fichier dans lequel la politique est enregistrée.

    Cela crée un objet Policy, un objet PlacementRule et un objet PlacementBinding dans l'espace de noms lvms-policy-ns. La politique crée une ressource Namespace, OperatorGroup, Subscription, et LVMCluster sur les clusters qui correspondent à la règle de placement. Cela déploie l'Opérateur sur les clusters OpenShift à nœud unique qui correspondent aux critères de sélection et le configure pour mettre en place les ressources requises pour provisionner le stockage. L'opérateur utilise tous les disques spécifiés dans le CR LVMCluster. Si aucun disque n'est spécifié, l'opérateur utilise tous les disques inutilisés sur le nœud unique OpenShift.

    Important

    Une fois qu'un dispositif a été ajouté au site LVMCluster, il ne peut plus être supprimé.

Ressources supplémentaires

4.12.3.1.6. Désinstallation du stockage LVM installé à l'aide de RHACM

Pour désinstaller le stockage LVM que vous avez installé à l'aide de RHACM, vous devez supprimer la stratégie RHACM que vous avez créée pour déployer et configurer l'opérateur.

Lorsque vous supprimez la stratégie RHACM, les ressources créées par cette stratégie ne sont pas supprimées. Vous devez créer d'autres politiques pour supprimer les ressources.

Comme les ressources créées ne sont pas supprimées lorsque vous supprimez la politique, vous devez effectuer les étapes suivantes :

  1. Supprimez toutes les réclamations de volumes persistants (PVC) et les instantanés de volumes fournis par LVM Storage.
  2. Supprimez les ressources LVMCluster pour nettoyer les ressources du Logical Volume Manager créées sur les disques.
  3. Créer une politique supplémentaire pour désinstaller l'opérateur.

Conditions préalables

  • Assurez-vous que les éléments suivants sont supprimés avant de supprimer la politique :

    • Toutes les applications sur les clusters gérés qui utilisent le stockage provisionné par LVM Storage.
    • PVC et volumes persistants (PV) provisionnés à l'aide de LVM Storage.
    • Tous les instantanés de volume fournis par LVM Storage.
  • Assurez-vous que vous avez accès au cluster RHACM en utilisant un compte avec un rôle cluster-admin.

Procédure

  1. Dans le CLI OpenShift (oc), supprimez la politique RHACM que vous avez créée pour déployer et configurer le stockage LVM sur le cluster hub en utilisant la commande suivante : 

    # oc delete -f policy-lvms-operator.yaml -n lvms-policy-ns 1
    1
    Le site policy-lvms-operator.yaml est le nom du fichier dans lequel la politique a été enregistrée.

  2. Pour créer une politique de suppression de la ressource LVMCluster, enregistrez le fichier YAML suivant dans un fichier portant un nom tel que lvms-remove-policy.yaml. Cela permet à l'opérateur de nettoyer toutes les ressources Logical Volume Manager qu'il a créées sur le cluster. 

    apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-lvmcluster-delete
  annotations:
    policy.open-cluster-management.io/standards: NIST SP 800-53
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
spec:
  remediationAction: enforce
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-lvmcluster-removal
        spec:
          remediationAction: enforce 1
          severity: low
          object-templates:
            - complianceType: mustnothave
              objectDefinition:
                kind: LVMCluster
                apiVersion: lvm.topolvm.io/v1alpha1
                metadata:
                  name: my-lvmcluster
                  namespace: openshift-storage 2
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-lvmcluster-delete
placementRef:
  apiGroup: apps.open-cluster-management.io
  kind: PlacementRule
  name: placement-policy-lvmcluster-delete
subjects:
  - apiGroup: policy.open-cluster-management.io
    kind: Policy
    name: policy-lvmcluster-delete
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-lvmcluster-delete
spec:
  clusterConditions:
    - status: "True"
      type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      - key: mykey
        operator: In
        values:
          - myvalue
    1
    La valeur du paramètre policy-template spec.remediationAction est remplacée par la valeur du paramètre spec.remediationAction qui précède.
    2
    Ce champ namespace doit avoir la valeur openshift-storage.
  3. Définissez la valeur du champ PlacementRule.spec.clusterSelector pour sélectionner les clusters à partir desquels désinstaller le stockage LVM.

  4. Créez la politique en exécutant la commande suivante : 

    # oc create -f lvms-remove-policy.yaml -n lvms-policy-ns

  5. Pour créer une politique permettant de vérifier si le CR LVMCluster a été supprimé, enregistrez le fichier YAML suivant dans un fichier portant un nom tel que check-lvms-remove-policy.yaml: 

    apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-lvmcluster-inform
  annotations:
    policy.open-cluster-management.io/standards: NIST SP 800-53
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
spec:
  remediationAction: inform
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-lvmcluster-removal-inform
        spec:
          remediationAction: inform 1
          severity: low
          object-templates:
            - complianceType: mustnothave
              objectDefinition:
                kind: LVMCluster
                apiVersion: lvm.topolvm.io/v1alpha1
                metadata:
                  name: my-lvmcluster
                  namespace: openshift-storage 2
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-policy-lvmcluster-check
placementRef:
  apiGroup: apps.open-cluster-management.io
  kind: PlacementRule
  name: placement-policy-lvmcluster-check
subjects:
  - apiGroup: policy.open-cluster-management.io
    kind: Policy
    name: policy-lvmcluster-inform
---
apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-lvmcluster-check
spec:
  clusterConditions:
    - status: "True"
      type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      - key: mykey
        operator: In
        values:
          - myvalue
    1
    La valeur du paramètre policy-template spec.remediationAction est remplacée par la valeur du paramètre spec.remediationAction qui précède.
    2
    Le champ namespace doit avoir la valeur openshift-storage.

  6. Créez la politique en exécutant la commande suivante : 

    # oc create -f check-lvms-remove-policy.yaml -n lvms-policy-ns

  7. Vérifiez l'état de la politique en exécutant la commande suivante : 

    # oc get policy -n lvms-policy-ns

    Exemple de sortie

    NAME                       REMEDIATION ACTION   COMPLIANCE STATE   AGE
policy-lvmcluster-delete   enforce              Compliant          15m
policy-lvmcluster-inform   inform               Compliant          15m

  8. Une fois que les deux politiques sont conformes, enregistrez le YAML suivant dans un fichier portant un nom tel que lvms-uninstall-policy.yaml pour créer une politique de désinstallation du stockage LVM. 

    apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-uninstall-lvms
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
    - key: mykey
      operator: In
      values:
      - myvalue
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-uninstall-lvms
placementRef:
  apiGroup: apps.open-cluster-management.io
  kind: PlacementRule
  name: placement-uninstall-lvms
subjects:
- apiGroup: policy.open-cluster-management.io
  kind: Policy
  name: uninstall-lvms
---
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  annotations:
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    policy.open-cluster-management.io/standards: NIST SP 800-53
  name: uninstall-lvms
spec:
  disabled: false
  policy-templates:
  - objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name: uninstall-lvms
      spec:
        object-templates:
        - complianceType: mustnothave
          objectDefinition:
            apiVersion: v1
            kind: Namespace
            metadata:
              name: openshift-storage
        - complianceType: mustnothave
          objectDefinition:
            apiVersion: operators.coreos.com/v1
            kind: OperatorGroup
            metadata:
              name: openshift-storage-operatorgroup
              namespace: openshift-storage
            spec:
              targetNamespaces:
              - openshift-storage
        - complianceType: mustnothave
          objectDefinition:
            apiVersion: operators.coreos.com/v1alpha1
            kind: Subscription
            metadata:
              name: lvms-operator
              namespace: openshift-storage
        remediationAction: enforce
        severity: low
  - objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name: policy-remove-lvms-crds
      spec:
        object-templates:
        - complianceType: mustnothave
          objectDefinition:
            apiVersion: apiextensions.k8s.io/v1
            kind: CustomResourceDefinition
            metadata:
              name: logicalvolumes.topolvm.io
        - complianceType: mustnothave
          objectDefinition:
            apiVersion: apiextensions.k8s.io/v1
            kind: CustomResourceDefinition
            metadata:
              name: lvmclusters.lvm.topolvm.io
        - complianceType: mustnothave
          objectDefinition:
            apiVersion: apiextensions.k8s.io/v1
            kind: CustomResourceDefinition
            metadata:
              name: lvmvolumegroupnodestatuses.lvm.topolvm.io
        - complianceType: mustnothave
          objectDefinition:
            apiVersion: apiextensions.k8s.io/v1
            kind: CustomResourceDefinition
            metadata:
              name: lvmvolumegroups.lvm.topolvm.io
        remediationAction: enforce
        severity: high

  9. Créez la politique en exécutant la commande suivante : 

    # oc create -f lvms-uninstall-policy.yaml -ns lvms-policy-ns

Ressources supplémentaires

4.12.3.2. Création d'un cluster de Logical Volume Manager

Vous pouvez créer un cluster de Logical Volume Manager après avoir installé LVM Storage.

OpenShift Container Platform prend en charge des nœuds de travail supplémentaires pour les clusters OpenShift à nœud unique sur une infrastructure bare-metal fournie par l'utilisateur. LVM Storage détecte et utilise les nœuds de travail supplémentaires lorsqu'ils apparaissent. Si vous avez besoin de définir un filtre de nœuds pour les nœuds de travail supplémentaires, vous pouvez utiliser la vue YAML lors de la création du cluster.

Important

Cette correspondance de filtre de nœud n'est pas la même que la correspondance d'étiquette de pod.

Conditions préalables

  • Vous avez installé LVM Storage à partir de l'OperatorHub.

Procédure

  1. Dans la console Web de OpenShift Container Platform, cliquez sur Operators Installed Operators pour afficher tous les opérateurs installés.

    Assurez-vous que le site Project sélectionné est openshift-storage.

  2. Cliquez sur LVM Storage, puis sur Create LVMCluster sous LVMCluster.
  3. Dans la page Create LVMCluster, sélectionnez Form view ou YAML view.
  4. Entrez un nom pour le cluster.
  5. Cliquez sur Create.

  6. Facultatif : Pour ajouter un filtre de nœud, cliquez sur YAML view et spécifiez le filtre dans la section nodeSelector: 

    apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
  name: my-lvmcluster
spec:
  storage:
    deviceClasses:
      - name: vg1
        thinPoolConfig:
          name: thin-pool-1
          sizePercent: 90
          overprovisionRatio: 10
        nodeSelector:
          nodeSelectorTerms:
            - matchExpressions:
                - key: app
              operator: In
              Values:
                - test1

  7. Facultatif : Pour modifier le chemin d'accès local des disques, cliquez sur YAML view et indiquez le chemin d'accès dans la section deviceSelector: 

    spec:
  storage:
    deviceClasses:
      - name: vg1
        deviceSelector:
          paths:
          - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
          - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
        thinPoolConfig:
          name: thin-pool-1
          sizePercent: 90
          overprovisionRatio: 10

Étapes de la vérification

  1. Cliquez sur Storage Storage Classes dans le volet gauche de la console Web OpenShift Container Platform.
  2. Vérifiez que la classe de stockage lvms-<device-class-name> est créée avec la création de LVMCluster. Par défaut, vg1 est la classe de stockage device-class-name.

Ressources supplémentaires

4.12.3.3. Provisionnement du stockage à l'aide de LVM Storage

Vous pouvez provisionner des réclamations de volumes persistants (PVC) en utilisant la classe de stockage créée lors de l'installation de l'Opérateur. Vous pouvez provisionner des PVC de blocs et de fichiers, mais le stockage n'est alloué que lorsqu'un pod utilisant le PVC est créé.

Note

LVM Storage provisionne les PVC par unités de 1 GiB. L'espace de stockage demandé est arrondi au gigaoctet le plus proche.

Procédure

  1. Identifiez le site StorageClass qui est créé lorsque le stockage LVM est déployé.

    Le nom StorageClass est au format lvms-<device-class-name>. device-class-name est le nom de la classe d'appareil que vous avez fourni dans LVMCluster de Policy YAML. Par exemple, si le site deviceClass s'appelle vg1, le nom storageClass est lvms-vg1.

    Le site volumeBindingMode de la classe de stockage est défini sur WaitForFirstConsumer.

  2. Pour créer un PVC dans lequel l'application a besoin de stockage, enregistrez le fichier YAML suivant dans un fichier portant un nom tel que pvc.yaml.

    Exemple de YAML pour créer un PVC

    # block pvc
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: lvm-block-1
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  resources:
    requests:
      storage: 10Gi
  storageClassName: lvms-vg1
---
# file pvc
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: lvm-file-1
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 10Gi
  storageClassName: lvms-vg1

  3. Créez le PVC en exécutant la commande suivante : 

    # oc create -f pvc.yaml -ns <application_namespace>

    Les PVC créés restent à l'état pending jusqu'à ce que vous déployiez les pods qui les utilisent.

4.12.3.4. Surveillance du stockage LVM

Lorsque le stockage LVM est installé à l'aide de la console Web OpenShift Container Platform, vous pouvez surveiller le cluster en utilisant le tableau de bord Block and File dans la console par défaut. Cependant, lorsque vous utilisez RHACM pour installer le stockage LVM, vous devez configurer RHACM Observability pour surveiller tous les clusters OpenShift à nœud unique à partir d'un seul endroit.

4.12.3.4.1. Metrics

Vous pouvez surveiller le stockage LVM en consultant les métriques exportées par l'opérateur sur les tableaux de bord RHACM et les alertes qui sont déclenchées.

  • Ajouter les métriques topolvm suivantes à la liste allow: 

    topolvm_thinpool_data_percent
topolvm_thinpool_metadata_percent
topolvm_thinpool_size_bytes
Note

Les mesures sont mises à jour toutes les 10 minutes ou lorsqu'il y a un changement dans le thin pool, comme la création d'un nouveau volume logique.

4.12.3.4.2. Alertes

Lorsque le thin pool et le groupe de volumes sont remplis, les opérations ultérieures échouent et peuvent entraîner une perte de données. LVM Storage envoie les alertes suivantes sur l'utilisation du thin pool et du groupe de volumes lorsque l'utilisation dépasse une certaine valeur :

Alertes pour le cluster Logical Volume Manager dans RHACM

AlerteDescription

VolumeGroupUsageAtThresholdNearFull

Cette alerte est déclenchée lorsque l'utilisation du groupe de volumes et du thin pool dépasse 75 % sur les nœuds. La suppression de données ou l'extension du groupe de volumes est nécessaire.

VolumeGroupUsageAtThresholdCritical

Cette alerte est déclenchée lorsque l'utilisation du groupe de volumes et du thin pool dépasse 85 % sur les nœuds. VolumeGroup est saturé. La suppression de données ou l'extension du groupe de volumes est nécessaire.

ThinPoolDataUsageAtThresholdNearFull

Cette alerte est déclenchée lorsque l'utilisation des données du thin pool dans le groupe de volumes dépasse 75 % sur les nœuds. La suppression de données ou l'extension du thin pool est nécessaire.

ThinPoolDataUsageAtThresholdCritical

Cette alerte est déclenchée lorsque l'utilisation des données du thin pool dans le groupe de volumes dépasse 85 % sur les nœuds. La suppression de données ou l'extension du thin pool est nécessaire.

ThinPoolMetaDataUsageAtThresholdNearFull

Cette alerte est déclenchée lorsque l'utilisation des métadonnées du thin pool dans le groupe de volumes dépasse 75 % sur les nœuds. La suppression des données ou l'extension du thin pool est nécessaire.

ThinPoolMetaDataUsageAtThresholdCritical

Cette alerte est déclenchée lorsque l'utilisation des métadonnées du thin pool dans le groupe de volumes dépasse 85 % sur les nœuds. La suppression de données ou l'extension du thin pool est nécessaire.

Ressources supplémentaires

4.12.3.5. Mise à l'échelle du stockage des clusters OpenShift à nœud unique

OpenShift Container Platform prend en charge des nœuds de travail supplémentaires pour les clusters OpenShift à nœud unique sur une infrastructure bare-metal fournie par l'utilisateur. LVM Storage détecte et utilise les nouveaux nœuds de travail supplémentaires lorsqu'ils apparaissent.

Ressources supplémentaires

4.12.3.5.1. Augmenter le stockage en ajoutant de la capacité à votre cluster OpenShift à nœud unique

Pour faire évoluer la capacité de stockage de vos nœuds de travail configurés sur un cluster OpenShift à nœud unique, vous pouvez augmenter la capacité en ajoutant des disques.

Conditions préalables

  • Vous disposez de disques supplémentaires inutilisés sur chaque cluster OpenShift à nœud unique à utiliser par LVM Storage.

Procédure

  1. Connectez-vous à la console OpenShift Container Platform du cluster OpenShift à nœud unique.
  2. À partir de la page Operators Installed Operators, cliquez sur LVM Storage Operator dans l'espace de noms openshift-storage.
  3. Cliquez sur l'onglet LVMCluster pour afficher la liste des LVMCluster CR créés sur le cluster.
  4. Sélectionnez Edit LVMCluster dans le menu déroulant Actions.
  5. Cliquez sur l'onglet YAML.

  6. Modifiez le fichier YAML de LVMCluster CR pour ajouter le nouveau chemin d'accès au périphérique dans la section deviceSelector:

    Note

    Si le champ deviceSelector n'est pas inclus lors de la création de LVMCluster, il n'est pas possible d'ajouter la section deviceSelector au CR. Vous devez supprimer le champ LVMCluster et créer un nouveau CR. 

    apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
  name: my-lvmcluster
spec:
  storage:
    deviceClasses:
    - name: vg1
      deviceSelector:
        paths:
        - /dev/disk/by-path/pci-0000:87:00.0-nvme-1 1
        - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
        - /dev/disk/by-path/pci-0000:89:00.0-nvme-1 2
      thinPoolConfig:
        name: thin-pool-1
        sizePercent: 90
        overprovisionRatio: 10
    1
    Le chemin peut être ajouté par nom (/dev/sdb) ou par chemin.
    2
    Un nouveau disque est ajouté.

Ressources supplémentaires

4.12.3.5.2. Augmenter le stockage en ajoutant de la capacité à votre cluster OpenShift à nœud unique à l'aide de RHACM

Vous pouvez faire évoluer la capacité de stockage de vos nœuds de travail configurés sur un cluster OpenShift à nœud unique à l'aide de RHACM.

Conditions préalables

  • Vous avez accès au cluster RHACM en utilisant un compte avec les privilèges cluster-admin.
  • Vous disposez de disques supplémentaires inutilisés sur chaque cluster OpenShift à nœud unique à utiliser par LVM Storage.

Procédure

  1. Connectez-vous au CLI RHACM en utilisant vos identifiants OpenShift Container Platform.
  2. Recherchez le disque que vous souhaitez ajouter. Le disque à ajouter doit correspondre au nom de périphérique et au chemin d'accès des disques existants.

  3. Pour ajouter de la capacité au cluster OpenShift à nœud unique, modifiez la section deviceSelector de la politique YAML existante, par exemple, policy-lvms-operator.yaml.

    Note

    Si le champ deviceSelector n'est pas inclus lors de la création de LVMCluster, il n'est pas possible d'ajouter la section deviceSelector au CR. Vous devez supprimer la section LVMCluster et la recréer à partir du nouveau CR. 

    apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-install-lvms
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
    - key: mykey
      operator: In
      values:
      - myvalue
---
apiVersion: policy.open-cluster-management.io/v1
kind: PlacementBinding
metadata:
  name: binding-install-lvms
placementRef:
  apiGroup: apps.open-cluster-management.io
  kind: PlacementRule
  name: placement-install-lvms
subjects:
- apiGroup: policy.open-cluster-management.io
  kind: Policy
  name: install-lvms
---
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  annotations:
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    policy.open-cluster-management.io/standards: NIST SP 800-53
  name: install-lvms
spec:
  disabled: false
  remediationAction: enforce
  policy-templates:
  - objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name: install-lvms
      spec:
        object-templates:
        - complianceType: musthave
          objectDefinition:
            apiVersion: v1
            kind: Namespace
            metadata:
              labels:
                openshift.io/cluster-monitoring: "true"
                pod-security.kubernetes.io/enforce: privileged
                pod-security.kubernetes.io/audit: privileged
                pod-security.kubernetes.io/warn: privileged
              name: openshift-storage
        - complianceType: musthave
          objectDefinition:
            apiVersion: operators.coreos.com/v1
            kind: OperatorGroup
            metadata:
              name: openshift-storage-operatorgroup
              namespace: openshift-storage
            spec:
              targetNamespaces:
              - openshift-storage
        - complianceType: musthave
          objectDefinition:
            apiVersion: operators.coreos.com/v1alpha1
            kind: Subscription
            metadata:
              name: lvms
              namespace: openshift-storage
            spec:
              installPlanApproval: Automatic
              name: lvms-operator
              source: redhat-operators
              sourceNamespace: openshift-marketplace
        remediationAction: enforce
        severity: low
  - objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name: lvms
      spec:
        object-templates:
           - complianceType: musthave
             objectDefinition:
               apiVersion: lvm.topolvm.io/v1alpha1
               kind: LVMCluster
               metadata:
                 name: my-lvmcluster
                 namespace: openshift-storage
               spec:
                 storage:
                   deviceClasses:
                   - name: vg1
                     deviceSelector:
                       paths:
                       - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
                       - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
                       - /dev/disk/by-path/pci-0000:89:00.0-nvme-1 # new disk is added
                     thinPoolConfig:
                       name: thin-pool-1
                       sizePercent: 90
                       overprovisionRatio: 10
                     nodeSelector:
                       nodeSelectorTerms:
                       - matchExpressions:
                           - key: app
                             operator: In
                             values:
                             - test1
        remediationAction: enforce
        severity: low

  4. Modifiez la politique en exécutant la commande suivante : 

    # oc edit -f policy-lvms-operator.yaml -ns lvms-policy-ns 1
    1
    policy-lvms-operator.yaml est le nom de la politique existante.

    Cette opération utilise le nouveau disque spécifié dans le CR LVMCluster pour approvisionner le stockage.

Ressources supplémentaires

4.12.3.5.3. Expansion des PVC

Pour tirer parti du nouveau stockage après l'ajout de capacité supplémentaire, vous pouvez étendre les réclamations de volumes persistants (PVC) existantes avec le stockage LVM.

Conditions préalables

  • Le provisionnement dynamique est utilisé.
  • L'objet contrôlant StorageClass a pour valeur allowVolumeExpansion et pour valeur true.

Procédure

  1. Modifiez le champ .spec.resources.requests.storage de la ressource PVC souhaitée en fonction de la nouvelle taille en exécutant la commande suivante : 

    oc patch <pvc_name> -n <application_namespace> -p '{ "spec" : { \N- "resources\N" : { \N- "requests\N" : { \N- "storage\N" : \N- "<desired_size>\N" }}}}'
  2. Surveillez le champ status.conditions du PVC pour voir si le redimensionnement est terminé. OpenShift Container Platform ajoute la condition Resizing au PVC pendant l'expansion, qui est supprimée une fois l'expansion terminée.

Ressources supplémentaires

4.12.3.6. Mise à jour du stockage LVM sur les clusters OpenShift à nœud unique

Actuellement, il n'est pas possible de mettre à niveau OpenShift Data Foundation Logical Volume Manager Operator 4.11 vers LVM Storage 4.12 sur les clusters OpenShift à nœud unique.

Important

Les données ne seront pas conservées pendant ce processus.

Procédure

  1. Sauvegardez toutes les données que vous souhaitez conserver sur les réclamations de volumes persistants (PVC).
  2. Supprimer tous les PVC provisionnés par l'opérateur du gestionnaire de volume logique d'OpenShift Data Foundation et leurs pods.
  3. Réinstaller le stockage LVM sur OpenShift Container Platform 4.12.
  4. Recréer les charges de travail.
  5. Copiez les données de sauvegarde sur les PVC créés après la mise à niveau vers la version 4.12.

4.12.3.7. Instantanés de volume pour OpenShift à nœud unique

Vous pouvez prendre des instantanés de volumes persistants (PV) provisionnés par le stockage LVM. Vous pouvez également créer des instantanés de volume des volumes clonés. Les instantanés de volume vous permettent d'effectuer les opérations suivantes :

  • Sauvegardez les données de votre application.

    Important

    Les instantanés de volume sont situés sur les mêmes périphériques que les données d'origine. Pour utiliser les instantanés de volume comme sauvegardes, vous devez déplacer les instantanés vers un emplacement sécurisé. Vous pouvez utiliser les solutions de sauvegarde et de restauration d'OpenShift API for Data Protection.

  • Revenir à l'état dans lequel l'instantané du volume a été pris.

Ressources supplémentaires

4.12.3.7.1. Création d'instantanés de volume dans OpenShift à nœud unique

Vous pouvez créer des instantanés de volume en fonction de la capacité disponible du thin pool et des limites de surprovisionnement. LVM Storage crée un site VolumeSnapshotClass avec le nom lvms-<deviceclass-name>.

Conditions préalables

  • Vous vous êtes assuré que la revendication de volume persistant (PVC) est dans l'état Bound. Cela est nécessaire pour obtenir un instantané cohérent.
  • Vous avez arrêté toutes les entrées/sorties vers le PVC avant de prendre l'instantané.

Procédure

  1. Connectez-vous à l'OpenShift à nœud unique pour lequel vous devez exécuter la commande oc.

  2. Enregistrez le fichier YAML suivant dans un fichier portant un nom tel que lvms-vol-snapshot.yaml.

    Exemple de YAML pour créer un instantané de volume

    apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
    name: lvm-block-1-snap
spec:
    volumeSnapshotClassName: lvms-vg1
    source:
        persistentVolumeClaimName: lvm-block-1

  3. Créez l'instantané en exécutant la commande suivante dans le même espace de noms que le PVC : 

    # oc create -f lvms-vol-snapshot.yaml

Une copie en lecture seule du PVC est créée sous la forme d'un instantané de volume.

4.12.3.7.2. Restauration d'instantanés de volumes dans OpenShift à nœud unique

Lorsque vous restaurez un instantané de volume, une nouvelle revendication de volume persistante (PVC) est créée. Le PVC restauré est indépendant de l'instantané de volume et du PVC source.

Conditions préalables

  • La classe de stockage doit être la même que celle du PVC source.

  • La taille du PVC demandé doit être la même que celle du volume source de l'instantané.

    Important

    Un instantané doit être restauré sur un PVC de la même taille que le volume source de l'instantané. Si un PVC plus grand est nécessaire, vous pouvez redimensionner le PVC après la restauration réussie de l'instantané.

Procédure

  1. Identifiez le nom de la classe de stockage du PVC source et le nom de l'instantané du volume.

  2. Enregistrez le fichier YAML suivant dans un fichier portant un nom tel que lvms-vol-restore.yaml pour restaurer l'instantané.

    Exemple YAML pour restaurer un PVC.

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: lvm-block-1-restore
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Block
  Resources:
    Requests:
      storage: 2Gi
  storageClassName: lvms-vg1
  dataSource:
    name: lvm-block-1-snap
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

  3. Créez la politique en exécutant la commande suivante dans le même espace de noms que l'instantané : 

    # oc create -f lvms-vol-restore.yaml
4.12.3.7.3. Suppression d'instantanés de volumes dans OpenShift à nœud unique

Vous pouvez supprimer les ressources des instantanés de volume et les réclamations de volumes persistants (PVC).

Procédure

  1. Supprimez la ressource de cliché de volume en exécutant la commande suivante : 

    # oc delete volumesnapshot <volume_snapshot_name> -n <namespace>
    Note

    Lorsque vous supprimez une revendication de volume persistant (PVC), les instantanés du PVC ne sont pas supprimés.

  2. Pour supprimer l'instantané de volume restauré, supprimez le PVC créé pour restaurer l'instantané de volume en exécutant la commande suivante : 

    # oc delete pvc <pvc_name> -n <namespace>

4.12.3.8. Clonage de volume pour OpenShift à nœud unique

Un clone est une copie d'un volume de stockage existant qui peut être utilisé comme n'importe quel volume standard.

4.12.3.8.1. Créer des clones de volume dans OpenShift à nœud unique

Vous créez un clone d'un volume pour faire une copie ponctuelle des données. Une revendication de volume persistant (PVC) ne peut pas être clonée avec une taille différente.

Important

Le PVC cloné a un accès en écriture.

Conditions préalables

  • Vous vous êtes assuré que le PVC est dans l'état Bound. Cela est nécessaire pour obtenir un instantané cohérent.
  • Vous vous êtes assuré que le StorageClass est le même que celui du PVC source.

Procédure

  1. Identifier la classe de stockage du PVC source.

  2. Pour créer un clone de volume, enregistrez le fichier YAML suivant dans un fichier portant un nom tel que lvms-vol-clone.yaml:

    Exemple de YAML pour cloner un volume

    apiVersion: v1
kind: PersistentVolumeClaim
Metadata:
  name: lvm-block-1-clone
Spec:
  storageClassName: lvms-vg1
  dataSource:
    name: lvm-block-1
    kind: PersistentVolumeClaim
  accessModes:
   - ReadWriteOnce
  volumeMode: Block
  Resources:
    Requests:
      storage: 2Gi

  3. Créez la stratégie dans le même espace de noms que le PVC source en exécutant la commande suivante : 

    # oc create -f lvms-vol-clone.yaml
4.12.3.8.2. Suppression des volumes clonés dans OpenShift à nœud unique

Vous pouvez supprimer les volumes clonés.

Procédure

  • Pour supprimer le volume cloné, supprimez le PVC cloné en exécutant la commande suivante : 

    # oc delete pvc <clone_pvc_name> -n <namespace>

4.12.3.9. Téléchargement de fichiers journaux et d'informations de diagnostic à l'aide de la collecte obligatoire

Lorsque LVM Storage n'est pas en mesure de résoudre automatiquement un problème, utilisez l'outil must-gather pour collecter les fichiers journaux et les informations de diagnostic afin que vous ou l'assistance Red Hat puissiez examiner le problème et déterminer une solution.

  • Exécutez la commande must-gather à partir du client connecté au cluster de stockage LVM en exécutant la commande suivante : 

    oc adm must-gather --image=registry.redhat.io/lvms4/lvms-must-gather-rhel8:v4.12 --dest-dir=<directory-name>

Ressources supplémentaires

4.12.3.10. Fichier YAML de référence du stockage LVM

L'exemple de ressource personnalisée (CR) LVMCluster décrit tous les champs du fichier YAML.

Exemple LVMCluster CR

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
  name: my-lvmcluster
spec:
  tolerations:
  - effect: NoSchedule
    key: xyz
    operator: Equal
    value: "true"
  storage:
    deviceClasses: 1
    - name: vg1  2
      nodeSelector: 3
        nodeSelectorTerms: 4
        - matchExpressions:
          - key: mykey
            operator: In
            values:
            - ssd
      deviceSelector: 5
        paths:
        - /dev/disk/by-path/pci-0000:87:00.0-nvme-1
        - /dev/disk/by-path/pci-0000:88:00.0-nvme-1
        - /dev/disk/by-path/pci-0000:89:00.0-nvme-1
      thinPoolConfig: 6
        name: thin-pool-1 7
        sizePercent: 90 8
        overprovisionRatio: 10 9
status:
    deviceClassStatuses: 10
    - name: vg1
      nodeStatus: 11
      - devices: 12
        - /dev/nvme0n1
        - /dev/nvme1n1
        - /dev/nvme2n1
        node: my-node.example.com 13
        status: Ready 14
    ready: true 15
    state: Ready 16

1
Les groupes de volumes LVM à créer sur le cluster. Actuellement, une seule adresse deviceClass est prise en charge.
2
Le nom du groupe de volumes LVM à créer sur les nœuds.
3
Les nœuds sur lesquels créer le groupe de volumes LVM. Si le champ est vide, tous les nœuds sont pris en compte.
4
Liste des exigences relatives aux sélecteurs de nœuds.
5
Liste des chemins d'accès aux périphériques utilisés pour créer le groupe de volumes LVM. Si ce champ est vide, tous les disques inutilisés du nœud seront utilisés.
6
La configuration du thin pool LVM.
7
Le nom du thin pool à créer dans le groupe de volumes LVM.
8
Le pourcentage d'espace restant dans le groupe de volumes LVM qui doit être utilisé pour créer le thin pool.
9
Le facteur par lequel le stockage supplémentaire peut être provisionné par rapport au stockage disponible dans le thin pool.
10
Le statut du site deviceClass.
11
État du groupe de volumes LVM sur chaque nœud.
12
Liste des périphériques utilisés pour créer le groupe de volumes LVM.
13
Le nœud sur lequel le site deviceClass a été créé.
14
État du groupe de volumes LVM sur le nœud.
15
Ce champ est obsolète.
16
Le statut du site LVMCluster.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.