Skip to main content
È disponibile una versione più recente di questo prodotto.
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

PDF

Scopri i diversi modi per gestire i backend in Trident.

Opzioni per la gestione dei backend

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

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

  • I backend creati utilizzando TridentBackendConfig`possono essere gestiti utilizzando `tridentctl?

Gestisci tridentctl backend utilizzando TridentBackendConfig

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

Questo si applicherà ai seguenti scenari:

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

  • Nuovi backend che sono stati creati con tridentctl, mentre esistono altri oggetti TridentBackendConfig.

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

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

  • Associa i backend creati usando tridentctl a un nuovo TridentBackendConfig oggetto. Così facendo, i backend saranno gestiti usando kubectl e non tridentctl.

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

  1. Crea un segreto Kubernetes. Il segreto contiene le credenziali Trident necessarie per comunicare con il cluster/servizio di storage.

  2. Crea un TridentBackendConfig oggetto. Questo contiene informazioni specifiche sul cluster/servizio di storage e fa riferimento al segreto creato nel passaggio precedente. È necessario prestare attenzione a specificare parametri di configurazione identici (ad esempio, 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 leghi a un backend esistente, è necessario ottenere la configurazione del backend. In questo esempio, supponiamo che un backend sia stato creato 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: crea un Kubernetes Secret

Crea un Secret che contiene 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: crea un TridentBackendConfig CR

Il passaggio successivo consiste nel creare una TridentBackendConfig CR che si associ automaticamente a quella 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 come nel backend originale.

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

In questo caso, il TridentBackendConfig apparirà così:

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 che la TridentBackendConfig è stata creata, 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 utilizzando l' tbc-ontap-nas-backend `TridentBackendConfig`oggetto.

Gestisci TridentBackendConfig backend utilizzando tridentctl

`tridentctl` può essere utilizzato per elencare i backend che sono stati creati usando  `TridentBackendConfig`. Inoltre, gli amministratori possono anche scegliere di gestire completamente tali backend tramite  `tridentctl` eliminando  `TridentBackendConfig` e assicurandosi che  `spec.deletionPolicy` sia 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: confermare deletionPolicy è impostato su retain

Diamo un'occhiata al valore di deletionPolicy. Questo deve essere impostato su retain. Questo 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 non sia impostato su retain.

Passaggio 2: Eliminare il TridentBackendConfig CR

Il passaggio finale consiste nell'eliminare il TridentBackendConfig CR. Dopo aver verificato che deletionPolicy è impostato su retain, è possibile 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 l'eliminazione dell'oggetto TridentBackendConfig, Trident lo rimuove semplicemente senza eliminare effettivamente il backend stesso.