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 netapp-aruldeepa
PDF

Scopri i diversi modi di gestire i backend in Astra Trident.

Opzioni per la gestione dei backend

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

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

  • I backend possono essere creati TridentBackendConfig usando essere gestiti usando tridentctl?

Gestire i tridentctl backend utilizzando TridentBackendConfig

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

Questo si applica ai seguenti scenari:

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

  • Nuovi backend creati con tridentctl, mentre esistono altri TridentBackendConfig 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 backend che sono stati creati utilizzando.

  • Associa 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, è necessario creare un che si TridentBackendConfig colleghi al backend 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. Occorre prestare 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.

Fase 0: Identificare il backend

Per creare un TridentBackendConfig che si colleghi a un backend esistente, è necessario ottenere la configurazione 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 una TridentBackendConfig CR

Il passaggio successivo consiste nel creare un TridentBackendConfig CR che si associa automaticamente al pre-esistente ontap-nas-backend (come in questo esempio). Assicurarsi che siano soddisfatti i seguenti requisiti:

  • Lo stesso nome di backend viene 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 attraverso un Kubernetes Secret e non in testo normale.

In questo caso, il sarà simile al TridentBackendConfig 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 della TridentBackendConfig CR

Una volta TridentBackendConfig creato, la sua fase deve essere Bound. Deve inoltre riflettere lo stesso nome 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 verrà ora completamente gestito utilizzando l' tbc-ontap-nas-backend `TridentBackendConfig`oggetto.

Gestire i TridentBackendConfig backend utilizzando tridentctl

`tridentctl` può essere utilizzato per elencare i backend creati mediante `TridentBackendConfig`. Inoltre, gli amministratori possono anche scegliere di gestire completamente tali backend tramite `tridentctl` eliminando `TridentBackendConfig` e accertandosi che `spec.deletionPolicy` sia 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 l' deletionPolicy`impostazione su `retain

Diamo un'occhiata al valore di deletionPolicy. Questo deve essere impostato su retain. In questo modo, quando si elimina una TridentBackendConfig CR, la definizione di 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 passare alla fase successiva a meno che non deletionPolicy sia impostato su retain.

Fase 2: Eliminare la TridentBackendConfig CR

Il passaggio finale consiste nell'eliminare la TridentBackendConfig CR. Dopo aver confermato che il 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 dell' `TridentBackendConfig`oggetto, Astra Trident lo rimuove semplicemente senza eliminare il backend stesso.