Skip to main content
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Spostarsi tra le opzioni di gestione del backend

Collaboratori netapp-aruldeepa
PDF

Scopri i diversi modi di gestire i backend in Trident.

Opzioni per la gestione dei backend

Con l'introduzione di TridentBackendConfig , gli amministratori ora hanno due modi unici per gestire i backend. Ciò solleva le seguenti domande:

  • I backend possono essere creati utilizzando tridentctl essere gestito con TridentBackendConfig ?

  • I backend possono essere creati utilizzando TridentBackendConfig essere gestito utilizzando tridentctl ?

Maneggio tridentctl backend utilizzando TridentBackendConfig

Questa sezione illustra i passaggi necessari per gestire i backend creati utilizzando tridentctl direttamente tramite l'interfaccia Kubernetes creando TridentBackendConfig oggetti.

Ciò si applicherà ai seguenti scenari:

  • Backend preesistenti, che non hanno un TridentBackendConfig perché sono stati creati con tridentctl .

  • Nuovi backend creati con tridentctl , mentre altri TridentBackendConfig gli oggetti esistono.

In entrambi gli scenari, i backend continueranno a essere presenti, con Trident che pianifica i volumi e opera su di essi. In questo caso gli amministratori hanno due possibilità:

  • Continua a usare tridentctl per gestire i backend creati utilizzandolo.

  • Associa i backend creati utilizzando tridentctl a un nuovo TridentBackendConfig oggetto. Ciò significherebbe che i backend saranno gestiti utilizzando kubectl e non tridentctl .

Per gestire un backend preesistente utilizzando kubectl , dovrai creare un TridentBackendConfig che si collega al backend esistente. Ecco una panoramica di come funziona:

  1. Crea un segreto Kubernetes. Il segreto contiene le credenziali di cui Trident ha bisogno per comunicare con il cluster/servizio di archiviazione.

  2. Crea un TridentBackendConfig oggetto. Contiene informazioni specifiche sul cluster/servizio di archiviazione e fa riferimento al segreto creato nel passaggio precedente. Bisogna fare attenzione a specificare parametri di configurazione identici (come spec.backendName , spec.storagePrefix , spec.storageDriverName , e così via). spec.backendName deve essere impostato sul nome del backend esistente.

Passaggio 0: identificare il backend

Per creare un TridentBackendConfig che si collega a un backend esistente, sarà necessario ottenere la configurazione del backend. In questo esempio, supponiamo che sia stato creato un backend utilizzando la seguente definizione JSON:

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"
      }
    }
  ]
}

Passaggio 1: creare un segreto Kubernetes

Crea un segreto che contenga le credenziali per il backend, come mostrato in questo esempio:

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

Passaggio 2: creare un TridentBackendConfig CR

Il passo successivo è creare un TridentBackendConfig CR che si collegherà automaticamente al preesistente ontap-nas-backend (come in questo esempio). Assicurarsi che siano soddisfatti i seguenti requisiti:

  • Lo stesso nome del backend è definito in spec.backendName .

  • I parametri di configurazione sono identici al backend originale.

  • I pool virtuali (se presenti) devono mantenere lo stesso ordine del backend originale.

  • Le credenziali vengono fornite tramite un segreto Kubernetes e non in testo normale.

In questo caso, il TridentBackendConfig sarà simile a questo:

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

Fase 3: Verificare lo stato del TridentBackendConfig CR

Dopo il TridentBackendConfig è stato creato, la sua fase deve essere Bound . Dovrebbe inoltre riflettere lo stesso nome backend e UUID del backend esistente.

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 |
+---------------------+----------------+--------------------------------------+--------+---------+

Il backend sarà ora completamente gestito tramite tbc-ontap-nas-backend TridentBackendConfig oggetto.

Maneggio TridentBackendConfig backend utilizzando tridentctl

`tridentctl`può essere utilizzato per elencare i backend creati utilizzando `TridentBackendConfig` .  Inoltre, gli amministratori possono anche scegliere di gestire completamente tali backend tramite `tridentctl` eliminando `TridentBackendConfig` e assicurandosi `spec.deletionPolicy` è impostato su `retain` .

Passaggio 0: identificare il backend

Ad esempio, supponiamo che il seguente backend sia stato creato utilizzando 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 |
+-------------------+----------------+--------------------------------------+--------+---------+

Dall'output si vede che TridentBackendConfig è stato creato correttamente ed è associato a un backend [osservare l'UUID del backend].

Passaggio 1: conferma deletionPolicy è impostato su retain

Diamo un'occhiata al valore di deletionPolicy . Questo deve essere impostato su retain . Ciò garantisce che quando un TridentBackendConfig CR viene eliminato, la definizione del backend sarà ancora presente e potrà essere gestita con 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
Nota Non procedere al passaggio successivo a meno che deletionPolicy è impostato su retain .

Passaggio 2: Eliminare il TridentBackendConfig CR

Il passaggio finale è quello di eliminare il TridentBackendConfig CR. Dopo aver confermato il deletionPolicy è impostato su retain , puoi procedere con l'eliminazione:

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 |
+-------------------+----------------+--------------------------------------+--------+---------+

Dopo la cancellazione del TridentBackendConfig oggetto, Trident lo rimuove semplicemente senza eliminare effettivamente il backend stesso.