Préparez la configuration d'un système back-end avec les pilotes NAS ONTAP
Suggérer des modifications
PDF
Découvrez comment vous préparer à configurer un back-end ONTAP avec les pilotes NAS ONTAP. Pour tous les systèmes back-end ONTAP, Astra Trident requiert au moins un agrégat affecté à la SVM.
Pour tous les systèmes back-end ONTAP, Astra Trident requiert au moins un agrégat affecté à la SVM.
N'oubliez pas que vous pouvez également exécuter plusieurs pilotes et créer des classes de stockage qui pointent vers l'un ou l'autre. Par exemple, vous pouvez configurer une classe Gold qui utilise le ontap-nas Pilote et une classe Bronze qui utilise le ontap-nas-economy une seule.
Tous vos nœuds workers Kubernetes doivent avoir installé les outils NFS appropriés. Voir "ici" pour en savoir plus.
Authentification
Astra Trident propose deux modes d'authentification d'un système back-end ONTAP.
-
Basé sur les informations d'identification : nom d'utilisateur et mot de passe pour un utilisateur ONTAP disposant des autorisations requises. Il est recommandé d'utiliser un rôle de connexion de sécurité prédéfini, par exemple
adminouvsadminPour garantir une compatibilité maximale avec les versions ONTAP. -
Basé sur des certificats : Astra Trident peut également communiquer avec un cluster ONTAP à l'aide d'un certificat installé sur le système back-end. Dans ce cas, la définition backend doit contenir des valeurs encodées Base64 du certificat client, de la clé et du certificat d'autorité de certification de confiance, le cas échéant (recommandé).
Vous pouvez mettre à jour les systèmes back-end existants pour passer d'une méthode basée sur les identifiants à une méthode basée sur les certificats. Toutefois, une seule méthode d'authentification est prise en charge à la fois. Pour passer à une méthode d'authentification différente, vous devez supprimer la méthode existante de la configuration backend.
|
Si vous tentez de fournir les deux identifiants et les certificats, la création du back-end échoue avec une erreur indiquant que plus d'une méthode d'authentification a été fournie dans le fichier de configuration. |
Activer l'authentification basée sur les informations d'identification
Astra Trident nécessite les identifiants d'un administrateur SVM-scoped/cluster-scoped pour communiquer avec le ONTAP backend. Il est recommandé d'utiliser des rôles standard prédéfinis tels que admin ou vsadmin. Il est ainsi possible d'assurer une compatibilité avec les futures versions d'ONTAP et d'exposer les API de fonctionnalités à utiliser avec les futures versions d'Astra Trident. Un rôle de connexion de sécurité personnalisé peut être créé et utilisé avec Astra Trident, mais il n'est pas recommandé.
Voici un exemple de définition du back-end :
--- version: 1 backendName: ExampleBackend storageDriverName: ontap-nas managementLIF: 10.0.0.1 dataLIF: 10.0.0.2 svm: svm_nfs username: vsadmin password: password
{
"version": 1,
"backendName": "ExampleBackend",
"storageDriverName": "ontap-nas",
"managementLIF": "10.0.0.1",
"dataLIF": "10.0.0.2",
"svm": "svm_nfs",
"username": "vsadmin",
"password": "password"
}
Gardez à l'esprit que la définition du back-end est le seul endroit où les informations d'identification sont stockées en texte brut. Une fois le système backend créé, les noms d'utilisateur/mots de passe sont codés avec Base64 et stockés sous forme de secrets Kubernetes. La création/la conversion d'un back-end est la seule étape qui nécessite la connaissance des informations d'identification. Il s'agit donc d'une opération uniquement administrative, qui doit être effectuée par l'administrateur Kubernetes/du stockage.
Activez l'authentification basée sur les certificats
Les systèmes back-end, nouveaux et existants, peuvent utiliser un certificat et communiquer avec le système back-end ONTAP. Trois paramètres sont requis dans la définition du back-end.
-
ClientCertificate : valeur encodée en Base64 du certificat client.
-
ClientPrivateKey : valeur encodée en Base64 de la clé privée associée.
-
TrustedCACertificate : valeur encodée Base64 du certificat CA de confiance. Si vous utilisez une autorité de certification approuvée, ce paramètre doit être fourni. Ceci peut être ignoré si aucune autorité de certification approuvée n'est utilisée.
Un flux de travail type comprend les étapes suivantes.
-
Générez un certificat client et une clé. Lors de la génération, définissez le nom commun (CN) sur l'utilisateur ONTAP pour qu'il s'authentifie.
openssl req -x509 -nodes -days 1095 -newkey rsa:2048 -keyout k8senv.key -out k8senv.pem -subj "/C=US/ST=NC/L=RTP/O=NetApp/CN=vsadmin"
-
Ajoutez un certificat d'autorité de certification de confiance au cluster ONTAP. Il se peut déjà que l'administrateur de stockage gère cet espace. Ignorer si aucune autorité de certification approuvée n'est utilisée.
security certificate install -type server -cert-name <trusted-ca-cert-name> -vserver <vserver-name> ssl modify -vserver <vserver-name> -server-enabled true -client-enabled true -common-name <common-name> -serial <SN-from-trusted-CA-cert> -ca <cert-authority>
-
Installez le certificat client et la clé (à partir de l'étape 1) sur le cluster ONTAP.
security certificate install -type client-ca -cert-name <certificate-name> -vserver <vserver-name> security ssl modify -vserver <vserver-name> -client-enabled true
-
Vérifiez que le rôle de connexion de sécurité ONTAP est pris en charge
certmethode d'authentification.security login create -user-or-group-name vsadmin -application ontapi -authentication-method cert -vserver <vserver-name> security login create -user-or-group-name vsadmin -application http -authentication-method cert -vserver <vserver-name>
-
Testez l'authentification à l'aide d'un certificat généré. Remplacer <ONTAP Management LIF> et <vserver name> par Management LIF IP et SVM name. Vous devez vous assurer que le LIF a sa politique de service définie sur
default-data-management.curl -X POST -Lk https://<ONTAP-Management-LIF>/servlets/netapp.servlets.admin.XMLrequest_filer --key k8senv.key --cert ~/k8senv.pem -d '<?xml version="1.0" encoding="UTF-8"?><netapp xmlns="http://www.netapp.com/filer/admin" version="1.21" vfiler="<vserver-name>"><vserver-get></vserver-get></netapp>'
-
Encodez le certificat, la clé et le certificat CA de confiance avec Base64.
base64 -w 0 k8senv.pem >> cert_base64 base64 -w 0 k8senv.key >> key_base64 base64 -w 0 trustedca.pem >> trustedca_base64
-
Créez le back-end à l'aide des valeurs obtenues à partir de l'étape précédente.
cat cert-backend-updated.json { "version": 1, "storageDriverName": "ontap-nas", "backendName": "NasBackend", "managementLIF": "1.2.3.4", "dataLIF": "1.2.3.8", "svm": "vserver_test", "clientCertificate": "Faaaakkkkeeee...Vaaalllluuuueeee", "clientPrivateKey": "LS0tFaKE...0VaLuES0tLS0K", "storagePrefix": "myPrefix_" } #Update backend with tridentctl tridentctl update backend NasBackend -f cert-backend-updated.json -n trident +------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +------------+----------------+--------------------------------------+--------+---------+ | NasBackend | ontap-nas | 98e19b74-aec7-4a3d-8dcf-128e5033b214 | online | 9 | +------------+----------------+--------------------------------------+--------+---------+
Mettre à jour les méthodes d'authentification ou faire pivoter les informations d'identification
Vous pouvez mettre à jour un back-end existant pour utiliser une méthode d'authentification différente ou pour faire pivoter leurs informations d'identification. Cela fonctionne de deux manières : les systèmes back-end qui utilisent le nom d'utilisateur/mot de passe peuvent être mis à jour pour utiliser des certificats ; les systèmes back-end qui utilisent des certificats peuvent être mis à jour en fonction du nom d'utilisateur/mot de passe. Pour ce faire, vous devez supprimer la méthode d'authentification existante et ajouter la nouvelle méthode d'authentification. Utilisez ensuite le fichier backend.json mis à jour contenant les paramètres requis à exécuter tridentctl update backend.
cat cert-backend-updated.json
{
"version": 1,
"storageDriverName": "ontap-nas",
"backendName": "NasBackend",
"managementLIF": "1.2.3.4",
"dataLIF": "1.2.3.8",
"svm": "vserver_test",
"username": "vsadmin",
"password": "password",
"storagePrefix": "myPrefix_"
}
#Update backend with tridentctl
tridentctl update backend NasBackend -f cert-backend-updated.json -n trident
+------------+----------------+--------------------------------------+--------+---------+
| NAME | STORAGE DRIVER | UUID | STATE | VOLUMES |
+------------+----------------+--------------------------------------+--------+---------+
| NasBackend | ontap-nas | 98e19b74-aec7-4a3d-8dcf-128e5033b214 | online | 9 |
+------------+----------------+--------------------------------------+--------+---------+
|
Lors de la rotation des mots de passe, l'administrateur du stockage doit d'abord mettre à jour le mot de passe de l'utilisateur sur ONTAP. Cette opération est suivie d'une mise à jour du back-end. Lors de la rotation de certificats, plusieurs certificats peuvent être ajoutés à l'utilisateur. Le back-end est ensuite mis à jour pour utiliser le nouveau certificat, en suivant lequel l'ancien certificat peut être supprimé du cluster ONTAP. |
La mise à jour d'un back-end n'interrompt pas l'accès aux volumes qui ont déjà été créés, et n'a aucun impact sur les connexions de volume effectuées après. Une mise à jour réussie indique qu'Astra Trident peut communiquer avec le système back-end ONTAP et gérer les opérations de volumes à venir.
Gestion des règles d'exportation NFS
Astra Trident utilise les règles d'exportation NFS pour contrôler l'accès aux volumes qu'il provisionne.
Astra Trident propose deux options pour l'utilisation des règles d'exportation :
-
Astra Trident peut gérer la règle d'exportation de manière dynamique. Dans ce mode de fonctionnement, l'administrateur du stockage spécifie une liste de blocs CIDR qui représentent les adresses IP admissibles. Astra Trident ajoute automatiquement des adresses IP de nœud qui font partie de ces plages à la règle d'exportation. En outre, lorsqu'aucun CIDRS n'est spécifié, toute adresse IP unicast globale trouvée sur les nœuds est ajoutée à la règle d'exportation.
-
Les administrateurs du stockage peuvent créer une export-policy et ajouter des règles manuellement. Astra Trident utilise la export policy par défaut, sauf si un nom différent de export policy est spécifié dans la configuration.
Gérez les règles d'exportation de manière dynamique
La version 20.04 de CSI Trident permet de gérer de manière dynamique les règles d'exportation pour les systèmes back-end ONTAP. Cela permet à l'administrateur du stockage de spécifier un espace d'adresse autorisé pour les adresses IP du nœud de travail, au lieu de définir manuellement des règles explicites. Il simplifie considérablement la gestion des export policy ; les modifications apportées à l'export policy ne nécessitent plus d'intervention manuelle sur le cluster de stockage. De plus, cela permet de limiter l'accès au cluster de stockage uniquement aux nœuds workers dont les adresses IP sont comprises dans la plage spécifiée, ce qui prend en charge une gestion automatisée et précise.
|
|
La gestion dynamique des règles d'exportation n'est disponible que pour CSI Trident. Il est important de s'assurer que les nœuds de travail ne sont pas NATed. |
Exemple
Deux options de configuration doivent être utilisées. Voici un exemple de définition du backend :
--- version: 1 storageDriverName: ontap-nas backendName: ontap_nas_auto_export managementLIF: 192.168.0.135 svm: svm1 username: vsadmin password: password autoExportCIDRs: - 192.168.0.0/24 autoExportPolicy: true
|
|
Lorsque vous utilisez cette fonctionnalité, vous devez vous assurer que la jonction root dans votre SVM possède une export policy précédemment créée avec une règle d'exportation qui autorise le bloc CIDR (comme la export policy par défaut) du nœud. Suivez toujours la meilleure pratique recommandée par NetApp pour dédier un SVM à Astra Trident. |
Voici une explication du fonctionnement de cette fonction à l'aide de l'exemple ci-dessus :
-
autoExportPolicyest défini surtrue. Cela signifie qu'Astra Trident va créer une export policy pour lesvm1SVM et gère l'ajout et la suppression de règles à l'aide deautoExportCIDRsblocs d'adresse. Par exemple, un backend avec UUID 403b5326-8482-40db-96d0-d83fb3f4daec etautoExportPolicyréglez surtruecrée une export-policy nomméetrident-403b5326-8482-40db-96d0-d83fb3f4daecSur le SVM. -
autoExportCIDRscontient une liste de blocs d'adresses. Ce champ est facultatif et il prend par défaut la valeur ["0.0.0.0/0", ":/0"]. S'il n'est pas défini, Astra Trident ajoute toutes les adresses de diffusion individuelle à périmètre global présentes sur les nœuds du worker.
Dans cet exemple, le 192.168.0.0/24 l'espace d'adressage est fourni. Cela indique que les adresses IP des nœuds Kubernetes qui appartiennent à cette plage d'adresse seront ajoutées à la règle d'exportation créée par Astra Trident. Lorsque Astra Trident enregistre un nœud sur lequel il s'exécute, il récupère les adresses IP du nœud et les vérifie par rapport aux blocs d'adresse fournis dans autoExportCIDRs. Après avoir filtrage les adresses IP, Astra Trident crée des règles de politique d'exportation pour les adresses IP clientes qu'il détecte, avec une règle pour chaque nœud qu'il identifie.
Vous pouvez mettre à jour autoExportPolicy et autoExportCIDRs pour les systèmes back-end après leur création. Vous pouvez ajouter de nouveaux rapports CIDR pour un back-end qui est géré automatiquement ou supprimé des rapports CIDR existants. Faites preuve de prudence lors de la suppression des CIDR pour vous assurer que les connexions existantes ne sont pas tombées. Vous pouvez également choisir de désactiver autoExportPolicy pour un back-end et revient à une export policy créée manuellement. Pour ce faire, vous devrez définir le exportPolicy dans votre configuration backend.
Après la création ou la mise à jour d'Astra Trident, vous pouvez vérifier le système back-end à l'aide de tridentctl ou le correspondant tridentbackend CRD :
./tridentctl get backends ontap_nas_auto_export -n trident -o yaml
items:
- backendUUID: 403b5326-8482-40db-96d0-d83fb3f4daec
config:
aggregate: ""
autoExportCIDRs:
- 192.168.0.0/24
autoExportPolicy: true
backendName: ontap_nas_auto_export
chapInitiatorSecret: ""
chapTargetInitiatorSecret: ""
chapTargetUsername: ""
chapUsername: ""
dataLIF: 192.168.0.135
debug: false
debugTraceFlags: null
defaults:
encryption: "false"
exportPolicy: <automatic>
fileSystemType: ext4
Lorsque des nœuds sont ajoutés à un cluster Kubernetes et enregistrés avec le contrôleur Trident Astra, les règles d'exportation des systèmes back-end existants sont mises à jour (à condition qu'elles tombent dans la plage d'adresse spécifiée dans la autoExportCIDRs pour le back-end).
Lorsqu'un nœud est retiré, Astra Trident vérifie tous les systèmes back-end en ligne afin de supprimer la règle d'accès du nœud. En supprimant cette IP de nœud des règles d'exportation des systèmes back-end gérés, Astra Trident empêche les montages erratiques, à moins que cette adresse IP soit réutilisée par un nouveau nœud du cluster.
Pour les systèmes back-end existants, mise à jour du système back-end avec tridentctl update backend S'assure qu'Astra Trident gère automatiquement les règles d'exportation. Cela créera une nouvelle export policy nommée après l'UUID et les volumes du backend qui sont présents sur le back-end, utilisera la export policy nouvellement créée lorsqu'ils sont de nouveau montés.
|
|
La suppression d'un back-end avec des règles d'exportation gérées automatiquement supprimera l'export policy créée de manière dynamique. Si le back-end est recréés, il est traité comme un nouveau backend et entraîne la création d'une nouvelle export policy. |
Si l'adresse IP d'un nœud actif est mise à jour, vous devez redémarrer le pod Astra Trident sur le nœud. Astra Trident va ensuite mettre à jour la règle d'exportation pour les systèmes back-end qu'il gère pour tenir compte de ce changement d'IP.