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.

Passare da un'opzione di gestione back-end all'altra

Collaboratori
PDF

Scopri i diversi modi di gestire i backend in Astra Trident. Con l'introduzione di TridentBackendConfig, gli amministratori dispongono ora di due metodi unici per gestire i back-end. Questo pone le seguenti domande:

  • È possibile creare backend utilizzando tridentctl essere gestito con TridentBackendConfig?

  • È possibile creare backend utilizzando TridentBackendConfig essere gestito con tridentctl?

Gestire tridentctl backend con TridentBackendConfig

In questa sezione vengono descritte le procedure necessarie per gestire i backend creati con tridentctl Direttamente attraverso l'interfaccia Kubernetes creando TridentBackendConfig oggetti.

Questo si applica ai seguenti scenari:

  • Backend preesistenti, che non dispongono di TridentBackendConfig perché sono stati creati con tridentctl.

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

In entrambi gli scenari, i backend continueranno a essere presenti, con Astra Trident che pianifica i volumi e li gestisce. Gli amministratori possono scegliere tra due opzioni:

  • Continuare a utilizzare tridentctl per gestire i back-end creati utilizzando l'it.

  • Collegare i backend creati con tridentctl a un nuovo TridentBackendConfig oggetto. In questo modo, i backend verranno gestiti utilizzando kubectl e non tridentctl.

Per gestire un backend preesistente utilizzando kubectl, sarà necessario creare un TridentBackendConfig che si collega al back-end esistente. Ecco una panoramica sul funzionamento di questo sistema:

  1. Crea un Kubernetes Secret. Il segreto contiene le credenziali che Astra Trident deve comunicare con il cluster/servizio di storage.

  2. Creare un TridentBackendConfig oggetto. Contiene specifiche relative al cluster/servizio di storage e fa riferimento al segreto creato nel passaggio precedente. È necessario 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.

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

Fase 1: Creare un Kubernetes Secret

Creare un Segreto contenente le credenziali per il backend, come illustrato 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

Fase 2: Creare un TridentBackendConfig CR

Il passaggio successivo consiste nella creazione di un TridentBackendConfig CR che si associerà automaticamente al preesistente ontap-nas-backend (come in questo esempio). Assicurarsi che siano soddisfatti i seguenti requisiti:

  • Lo stesso nome backend viene definito in spec.backendName.

  • I parametri di configurazione sono identici al backend originale.

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

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

In questo caso, il TridentBackendConfig avrà un aspetto simile al seguente:

$ 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 di TridentBackendConfig CR

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

$ kubectl -n trident 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 back-end verrà ora completamente gestito utilizzando tbc-ontap-nas-backend TridentBackendConfig oggetto.

Gestire TridentBackendConfig backend con tridentctl

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

Fase 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].

Fase 1: Confermare deletionPolicy è impostato su retain

Diamo un'occhiata al valore di deletionPolicy. Questo valore deve essere impostato su retain. In questo modo si garantisce che quando si verifica un TridentBackendConfig La CR viene eliminata, la definizione di back-end rimane presente e può 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 passare alla fase successiva a meno che deletionPolicy è impostato su retain.

Fase 2: Eliminare TridentBackendConfig CR

Il passaggio finale consiste nell'eliminare TridentBackendConfig CR. Dopo la conferma di 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 |
+-------------------+----------------+--------------------------------------+--------+---------+

Al momento dell'eliminazione di TridentBackendConfig Astra Trident lo rimuove senza eliminare il backend stesso.