Skip to main content
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Passez d'une option de gestion back-end à une autre

Contributeurs netapp-aruldeepa
PDF

Découvrez les différentes méthodes de gestion des systèmes back-end dans Trident.

Options de gestion des systèmes back-end

Avec l'introduction de TridentBackendConfig, les administrateurs disposent désormais de deux méthodes uniques de gestion des systèmes back-end. Ceci pose les questions suivantes :

  • Les systèmes back-end créés à l'aide de peuvent-ils tridentctl être gérés avec TridentBackendConfig?

  • Les systèmes back-end créés à l'aide de peuvent-ils TridentBackendConfig être gérés à tridentctl

Gestion des tridentctl systèmes back-end avec TridentBackendConfig

Cette section décrit les étapes requises pour gérer les systèmes back-end créés tridentctl directement via l'interface Kubernetes en créant TridentBackendConfig des objets.

Cela s'applique aux scénarios suivants :

  • Systèmes back-end existants, qui n'ont pas de système TridentBackendConfig parce qu'ils ont été créés avec tridentctl.

  • Nouveaux systèmes back-end créés avec tridentctl, alors que d'autres TridentBackendConfig objets existent.

Dans les deux scénarios, les systèmes back-end continueront d'être présents, avec Trident qui planifie les volumes et les exécute. Les administrateurs peuvent choisir l'une des deux options suivantes :

  • Continuez à utiliser tridentctl pour gérer les systèmes back-end créés à l'aide de celui-ci.

  • Lier les systèmes back-end créés à l'aide d' tridentctl`un nouvel `TridentBackendConfig objet. Cela signifie que les systèmes back-end seront gérés sans utilisation kubectl tridentctl .

Pour gérer un back-end pré-existant à l'aide de kubectl, vous devez créer un TridentBackendConfig qui se lie au back-end existant. Voici un aperçu du fonctionnement de ces éléments :

  1. Créez un code secret Kubernetes. La clé secrète contient les informations d'identification dont Trident a besoin pour communiquer avec le cluster/service de stockage.

  2. Créer un TridentBackendConfig objet. Elle contient des informations spécifiques sur le cluster/service de stockage et fait référence au secret créé à l'étape précédente. Veillez à spécifier des paramètres de configuration identiques (tels que spec.backendName, , , spec.storagePrefix spec.storageDriverName etc.). spec.backendName doit être défini sur le nom du back-end existant.

Étape 0 : identifier le back-end

Pour créer un TridentBackendConfig qui se lie à un back-end existant, vous devez obtenir la configuration back-end. Dans cet exemple, supposons qu'un back-end a été créé à l'aide de la définition JSON suivante :

tridentctl get backend ontap-nas-backend -n trident
+---------------------+----------------+--------------------------------------+--------+---------+
|          NAME       | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
+---------------------+----------------+--------------------------------------+--------+---------+
| ontap-nas-backend   | ontap-nas      | 52f2eb10-e4c6-4160-99fc-96b3be5ab5d7 | online |      25 |
+---------------------+----------------+--------------------------------------+--------+---------+
cat ontap-nas-backend.json
{
  "version": 1,
  "storageDriverName": "ontap-nas",
  "managementLIF": "10.10.10.1",
  "dataLIF": "10.10.10.2",
  "backendName": "ontap-nas-backend",
  "svm": "trident_svm",
  "username": "cluster-admin",
  "password": "admin-password",
  "defaults": {
    "spaceReserve": "none",
    "encryption": "false"
  },
  "labels": {
    "store": "nas_store"
  },
  "region": "us_east_1",
  "storage": [
    {
      "labels": {
        "app": "msoffice",
        "cost": "100"
      },
      "zone": "us_east_1a",
      "defaults": {
        "spaceReserve": "volume",
        "encryption": "true",
        "unixPermissions": "0755"
      }
    },
    {
      "labels": {
        "app": "mysqldb",
        "cost": "25"
      },
      "zone": "us_east_1d",
      "defaults": {
        "spaceReserve": "volume",
        "encryption": "false",
        "unixPermissions": "0775"
      }
    }
  ]
}

Étape 1 : créez un code secret Kubernetes

Créez un secret qui contient les informations d'identification du back-end, comme indiqué dans cet exemple :

cat tbc-ontap-nas-backend-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: ontap-nas-backend-secret
type: Opaque
stringData:
  username: cluster-admin
  password: admin-password
kubectl create -f tbc-ontap-nas-backend-secret.yaml -n trident
secret/backend-tbc-ontap-san-secret created

Étape 2 : créer une TridentBackendConfig demande de modification

L'étape suivante consiste à créer une TridentBackendConfig demande de modification qui sera automatiquement lié au pré-existant ontap-nas-backend (comme dans cet exemple). Assurez-vous que les exigences suivantes sont respectées :

  • Le même nom de back-end est défini dans spec.backendName.

  • Les paramètres de configuration sont identiques au back-end d'origine.

  • Les pools virtuels (le cas échéant) doivent conserver le même ordre que dans le back-end d'origine.

  • Les identifiants sont fournis via un code secret Kubernetes et non en texte brut.

Dans ce cas, le se TridentBackendConfig présente comme suit :

cat backend-tbc-ontap-nas.yaml
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-ontap-nas-backend
spec:
  version: 1
  storageDriverName: ontap-nas
  managementLIF: 10.10.10.1
  dataLIF: 10.10.10.2
  backendName: ontap-nas-backend
  svm: trident_svm
  credentials:
    name: mysecret
  defaults:
    spaceReserve: none
    encryption: 'false'
  labels:
    store: nas_store
  region: us_east_1
  storage:
  - labels:
      app: msoffice
      cost: '100'
    zone: us_east_1a
    defaults:
      spaceReserve: volume
      encryption: 'true'
      unixPermissions: '0755'
  - labels:
      app: mysqldb
      cost: '25'
    zone: us_east_1d
    defaults:
      spaceReserve: volume
      encryption: 'false'
      unixPermissions: '0775'
kubectl create -f backend-tbc-ontap-nas.yaml -n trident
tridentbackendconfig.trident.netapp.io/tbc-ontap-nas-backend created

Étape 3 : vérifier l'état du TridentBackendConfig CR

Une fois le TridentBackendConfig créé, sa phase doit être Bound. Il devrait également refléter le même nom de back-end et UUID que celui du back-end existant.

kubectl get tbc tbc-ontap-nas-backend -n trident
NAME                   BACKEND NAME          BACKEND UUID                           PHASE   STATUS
tbc-ontap-nas-backend  ontap-nas-backend     52f2eb10-e4c6-4160-99fc-96b3be5ab5d7   Bound   Success

#confirm that no new backends were created (i.e., TridentBackendConfig did not end up creating a new backend)
tridentctl get backend -n trident
+---------------------+----------------+--------------------------------------+--------+---------+
|          NAME       | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
+---------------------+----------------+--------------------------------------+--------+---------+
| ontap-nas-backend   | ontap-nas      | 52f2eb10-e4c6-4160-99fc-96b3be5ab5d7 | online |      25 |
+---------------------+----------------+--------------------------------------+--------+---------+

Le back-end sera désormais entièrement géré à l'aide de l' tbc-ontap-nas-backend `TridentBackendConfig`objet.

Gestion des TridentBackendConfig systèmes back-end avec tridentctl

`tridentctl` elle peut être utilisée pour lister les systèmes back-end créés à l'aide de `TridentBackendConfig`. En outre, les administrateurs peuvent choisir de gérer intégralement ces systèmes back-end `tridentctl` en supprimant et en `TridentBackendConfig` veillant à ce que `spec.deletionPolicy` soit défini sur `retain`.

Étape 0 : identifier le back-end

Supposons, par exemple, que le backend suivant a été créé à l'aide de TridentBackendConfig:

kubectl get tbc backend-tbc-ontap-san -n trident -o wide
NAME                    BACKEND NAME        BACKEND UUID                           PHASE   STATUS    STORAGE DRIVER   DELETION POLICY
backend-tbc-ontap-san   ontap-san-backend   81abcb27-ea63-49bb-b606-0a5315ac5f82   Bound   Success   ontap-san        delete

tridentctl get backend ontap-san-backend -n trident
+-------------------+----------------+--------------------------------------+--------+---------+
|       NAME        | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
+-------------------+----------------+--------------------------------------+--------+---------+
| ontap-san-backend | ontap-san      | 81abcb27-ea63-49bb-b606-0a5315ac5f82 | online |      33 |
+-------------------+----------------+--------------------------------------+--------+---------+

A partir de la sortie, il est vu que TridentBackendConfig a été créé avec succès et est lié à un backend [observer l'UUID du backend].

Étape 1 : confirmer deletionPolicy est défini sur retain

Examinons la valeur de deletionPolicy. Ce paramètre doit être défini sur retain. Cela garantit que lorsqu'une TridentBackendConfig demande de modification est supprimée, la définition du back-end est toujours présente et peut être gérée avec tridentctl.

kubectl get tbc backend-tbc-ontap-san -n trident -o wide
NAME                    BACKEND NAME        BACKEND UUID                           PHASE   STATUS    STORAGE DRIVER   DELETION POLICY
backend-tbc-ontap-san   ontap-san-backend   81abcb27-ea63-49bb-b606-0a5315ac5f82   Bound   Success   ontap-san        delete

# Patch value of deletionPolicy to retain
kubectl patch tbc backend-tbc-ontap-san --type=merge -p '{"spec":{"deletionPolicy":"retain"}}' -n trident
tridentbackendconfig.trident.netapp.io/backend-tbc-ontap-san patched

#Confirm the value of deletionPolicy
kubectl get tbc backend-tbc-ontap-san -n trident -o wide
NAME                    BACKEND NAME        BACKEND UUID                           PHASE   STATUS    STORAGE DRIVER   DELETION POLICY
backend-tbc-ontap-san   ontap-san-backend   81abcb27-ea63-49bb-b606-0a5315ac5f82   Bound   Success   ontap-san        retain
Remarque Ne passez pas à l'étape suivante, sauf si deletionPolicy est défini sur retain.

Étape 2 : supprimez la TridentBackendConfig CR

La dernière étape consiste à supprimer la TridentBackendConfig demande de modification. Après avoir confirmé que deletionPolicy est défini sur retain, vous pouvez procéder à la suppression :

kubectl delete tbc backend-tbc-ontap-san -n trident
tridentbackendconfig.trident.netapp.io "backend-tbc-ontap-san" deleted

tridentctl get backend ontap-san-backend -n trident
+-------------------+----------------+--------------------------------------+--------+---------+
|       NAME        | STORAGE DRIVER |                 UUID                 | STATE  | VOLUMES |
+-------------------+----------------+--------------------------------------+--------+---------+
| ontap-san-backend | ontap-san      | 81abcb27-ea63-49bb-b606-0a5315ac5f82 | online |      33 |
+-------------------+----------------+--------------------------------------+--------+---------+

Lors de la suppression de TridentBackendConfig l'objet, Trident le supprime simplement sans réellement supprimer le back-end lui-même.