Les pilotes backend ONTAP se différencient par le protocole utilisé et par la manière dont les volumes sont provisionnés sur le système de stockage. Par conséquent, réfléchissez bien avant de choisir le pilote à déployer.

À un niveau supérieur, si votre application comporte des composants nécessitant un stockage partagé (plusieurs pods accédant au même PVC), les pilotes basés sur NAS seraient le choix par défaut, tandis que les pilotes iSCSI basés sur des blocs répondraient aux besoins d'un stockage non partagé. Choisissez le protocole en fonction des exigences de l'application et du niveau de confort des équipes de stockage et d'infrastructure. D'une manière générale, il y a peu de différence entre eux pour la plupart des applications, la décision repose donc souvent sur la nécessité ou non d'un stockage partagé (où plusieurs pods auront besoin d'un accès simultané).

Les pilotes backend ONTAP disponibles sont :

Le choix entre les trois pilotes NAS a des répercussions sur les fonctionnalités mises à la disposition de l'application.

Notez que, dans les tableaux ci-dessous, toutes les fonctionnalités ne sont pas exposées via Trident. Certaines doivent être appliquées par l'administrateur de stockage après la mise en service si cette fonctionnalité est souhaitée. Les notes de bas de page en exposant permettent de distinguer les fonctionnalités par fonction et par pilote.

Trident propose 2 pilotes SAN pour ONTAP, dont les capacités sont présentées ci-dessous.

Les fonctionnalités qui ne sont pas granulaires au niveau du PV sont appliquées à l'ensemble du FlexVolume et tous les PV (c'est-à-dire les qtrees ou les LUN dans les FlexVols partagés) partageront un calendrier commun.

Comme on peut le constater dans les tableaux ci-dessus, une grande partie des fonctionnalités entre les ontap-nas et ontap-nas-economy c'est la même chose. Cependant, parce que le ontap-nas-economy Le pilote limite la capacité de contrôler la planification au niveau de chaque PV, ce qui peut affecter en particulier votre planification de reprise après sinistre et de sauvegarde. Pour les équipes de développement qui souhaitent exploiter la fonctionnalité de clonage PVC sur le stockage ONTAP , cela n'est possible qu'en utilisant le ontap-nas , ontap-san ou ontap-san-economy conducteurs.

Cloud Volumes ONTAP offre un contrôle des données ainsi que des fonctionnalités de stockage de classe entreprise pour divers cas d'utilisation, notamment les partages de fichiers et le stockage au niveau bloc prenant en charge les protocoles NAS et SAN (NFS, SMB / CIFS et iSCSI). Les pilotes compatibles pour Cloud Volume ONTAP sont ontap-nas , ontap-nas-economy , ontap-san et ontap-san-economy . Ces instructions s'appliquent à Cloud Volume ONTAP pour Azure et à Cloud Volume ONTAP pour GCP.

Amazon FSx for NetApp ONTAP vous permet de tirer parti des fonctionnalités, des performances et des capacités d'administration de NetApp que vous connaissez, tout en bénéficiant de la simplicité, de l'agilité, de la sécurité et de l'évolutivité du stockage des données sur AWS. FSx pour ONTAP prend en charge de nombreuses fonctionnalités du système de fichiers ONTAP et des API d'administration. Les pilotes compatibles pour Cloud Volume ONTAP sont ontap-nas , ontap-nas-economy , ontap-nas-flexgroup , ontap-san et ontap-san-economy .

Le solidfire-san Ce pilote, utilisé avec les plateformes NetApp HCI/ SolidFire , aide l'administrateur à configurer un backend Element pour Trident en fonction des limites de QoS. Si vous souhaitez concevoir votre backend pour définir les limites QoS spécifiques sur les volumes provisionnés par Trident, utilisez le type paramètre dans le fichier backend. L'administrateur peut également limiter la taille du volume pouvant être créé sur le stockage à l'aide de limitVolumeSize paramètre. Actuellement, les fonctionnalités de stockage Element telles que le redimensionnement et la réplication de volumes ne sont pas prises en charge via le solidfire-san conducteur. Ces opérations doivent être effectuées manuellement via l'interface utilisateur web d'Element Software.

Trident utilise le azure-netapp-files le conducteur doit gérer le"Azure NetApp Files" service.

Vous trouverez plus d'informations sur ce pilote et sa configuration dans"Configuration du backend Trident pour Azure NetApp Files" .

Trident utilise le gcp-cvs Pilote permettant de se connecter au Cloud Volumes Service sur Google Cloud.

Le gcp-cvs Le pilote utilise des pools virtuels pour abstraire le backend et permettre à Trident de déterminer l'emplacement des volumes. L'administrateur définit les pools virtuels dans le backend.json fichiers. Les classes de stockage utilisent des sélecteurs pour identifier les pools virtuels par étiquette.

Pour configurer le backend Google Cloud sur Trident, vous devez spécifier projectNumber , apiRegion , et apiKey dans le fichier backend. Vous trouverez le numéro de projet dans la console Google Cloud. La clé API est extraite du fichier de clé privée du compte de service que vous avez créé lors de la configuration de l'accès API pour Cloud Volumes Service sur Google Cloud.

Pour plus d'informations sur les types de services et les niveaux de service de Cloud Volumes Service sur Google Cloud, veuillez consulter la documentation."Découvrez la prise en charge de CVS pour GCP par Trident" .

Le filtrage peut être utilisé au sein d'un objet de classe de stockage spécifique pour déterminer quel pool de stockage ou ensemble de pools doit être utilisé avec cette classe de stockage spécifique. Trois ensembles de filtres peuvent être définis dans la classe de stockage : storagePools , additionalStoragePools et/ou excludeStoragePools .

Le storagePools Ce paramètre permet de limiter le stockage à l'ensemble des pools correspondant aux attributs spécifiés. Le additionalStoragePools Ce paramètre permet d'étendre l'ensemble des pools que Trident utilise pour le provisionnement, en plus de l'ensemble des pools sélectionnés par les attributs et storagePools paramètres. Vous pouvez utiliser l'un ou l'autre paramètre seul ou les deux ensemble pour vous assurer que l'ensemble approprié de pools de stockage est sélectionné.

Le excludeStoragePools Ce paramètre permet d'exclure spécifiquement l'ensemble de pools listés qui correspondent aux attributs.

Si vous souhaitez concevoir des classes de stockage pour émuler des politiques de qualité de service, créez une classe de stockage avec le media attribut comme hdd ou ssd . Basé sur le media L'attribut mentionné dans la classe de stockage permettra à Trident de sélectionner le backend approprié qui sert hdd ou ssd regroupe les données pour correspondre à l'attribut média, puis dirige la mise à disposition des volumes vers l'agrégat spécifique. Nous pouvons donc créer une classe de stockage PREMIUM qui aurait media attribut défini comme ssd qui pourrait être classée comme la politique QoS PREMIUM. Nous pouvons créer une autre classe de stockage STANDARD dont l'attribut média serait défini sur hdd, ce qui pourrait être classé comme la politique QoS STANDARD. Nous pourrions également utiliser l'attribut « IOPS » dans la classe de stockage pour rediriger le provisionnement vers un dispositif Element qui peut être défini comme une politique QoS.

Les classes de stockage peuvent être conçues pour diriger le provisionnement des volumes sur un backend spécifique où des fonctionnalités telles que le provisionnement fin et épais, les instantanés, les clones et le chiffrement sont activées. Pour spécifier le stockage à utiliser, créez des classes de stockage qui définissent le système de stockage approprié avec la fonctionnalité requise activée.

Des pools virtuelles sont disponibles pour tous les backends Trident . Vous pouvez définir des pools virtuels pour n'importe quel backend, en utilisant n'importe quel pilote fourni par Trident .

Les pools virtuels permettent à un administrateur de créer un niveau d'abstraction sur les backends, qui peut être référencé via les classes de stockage, pour une plus grande flexibilité et un placement efficace des volumes sur les backends. Différents systèmes d'arrière-plan peuvent être définis avec la même classe de service. De plus, plusieurs pools de stockage peuvent être créés sur le même système dorsal, mais avec des caractéristiques différentes. Lorsqu'une classe de stockage est configurée avec un sélecteur comportant des étiquettes spécifiques, Trident choisit un backend correspondant à toutes les étiquettes du sélecteur pour placer le volume. Si les étiquettes du sélecteur de classe de stockage correspondent à plusieurs pools de stockage, Trident en choisira un pour provisionner le volume.

Il est possible de concevoir des pools virtuels pour émuler des classes de services. En utilisant l'implémentation de pool virtuel pour Cloud Volume Service pour Azure NetApp Files, examinons comment configurer différentes classes de service. Configurez le backend Azure NetApp Files avec plusieurs étiquettes, représentant différents niveaux de performance. Ensemble servicelevel ajouter les aspects au niveau de performance approprié et ajouter les autres aspects requis sous chaque étiquette. Créez maintenant différentes classes de stockage Kubernetes qui correspondront à différents pools virtuels. En utilisant le parameters.selector Dans ce champ, chaque StorageClass indique quels pools virtuels peuvent être utilisés pour héberger un volume.

Il est possible de concevoir plusieurs pools virtuelles présentant des caractéristiques spécifiques à partir d'un seul système de stockage dorsal. Pour ce faire, configurez le backend avec plusieurs étiquettes et définissez les aspects requis sous chaque étiquette. Créez maintenant différentes classes de stockage Kubernetes en utilisant parameters.selector champ qui correspondrait à différents pools virtuels. Les volumes provisionnés sur le système dorsal auront les caractéristiques définies dans le pool virtuel choisi.

Certains paramètres autres que la classe de stockage demandée peuvent affecter le processus de décision de provisionnement Trident lors de la création d'un PVC.

Lors d'une demande de stockage via une PVC, l'un des champs obligatoires est le mode d'accès. Le mode souhaité peut affecter le serveur dorsal sélectionné pour héberger la requête de stockage.

Trident tentera de faire correspondre le protocole de stockage utilisé avec la méthode d'accès spécifiée selon la matrice suivante. Ceci est indépendant de la plateforme de stockage sous-jacente.

Une demande de volume persistant ReadWriteMany soumise à un déploiement Trident sans backend NFS configuré n'entraînera la création d'aucun volume. Pour cette raison, le demandeur doit utiliser le mode d'accès approprié à son application.

Les volumes persistants sont, à deux exceptions près, des objets immuables dans Kubernetes. Une fois créée, la politique de récupération et la taille peuvent être modifiées. Cependant, cela n'empêche pas certains aspects du volume d'être modifiés en dehors de Kubernetes. Cela peut s'avérer utile pour personnaliser le volume en fonction d'applications spécifiques, pour éviter toute consommation accidentelle de capacité, ou simplement pour déplacer le volume vers un autre contrôleur de stockage pour quelque raison que ce soit.

Les détails de connexion du PV ne peuvent pas être modifiés après sa création.

Trident prend en charge la création d'instantanés de volumes à la demande et la création de PVC à partir d'instantanés à l'aide du framework CSI. Les snapshots offrent une méthode pratique pour conserver des copies ponctuelles des données et ont un cycle de vie indépendant du PV source dans Kubernetes. Ces instantanés peuvent être utilisés pour cloner des PVC.

Trident prend également en charge la création de PersistentVolumes à partir d'instantanés de volumes. Pour ce faire, il suffit de créer un PersistentVolumeClaim et de mentionner le datasource comme instantané requis à partir duquel le volume doit être créé. Trident gérera ce PVC en créant un volume contenant les données présentes sur l'instantané. Grâce à cette fonctionnalité, il est possible de dupliquer des données entre régions, de créer des environnements de test, de remplacer intégralement un volume de production endommagé ou corrompu, ou de récupérer des fichiers et répertoires spécifiques et de les transférer vers un autre volume connecté.

Les administrateurs de stockage ont la possibilité de déplacer des volumes entre les agrégats et les contrôleurs du cluster ONTAP sans perturber le consommateur de stockage. Cette opération n'affecte ni Trident ni le cluster Kubernetes, tant que l'agrégat de destination est un agrégat auquel le SVM utilisé par Trident a accès. Il est important de noter que si l'agrégat a été récemment ajouté au SVM, le backend devra être actualisé en le réajoutant à Trident. Cela déclenchera une nouvelle inventaire du SVM par Trident afin que le nouvel agrégat soit reconnu.

Cependant, le déplacement de volumes entre les systèmes backend n'est pas pris en charge automatiquement par Trident. Cela inclut entre les SVM du même cluster, entre les clusters ou sur une plateforme de stockage différente (même si ce système de stockage est connecté à Trident).

Si un volume est copié vers un autre emplacement, la fonction d'importation de volumes peut être utilisée pour importer les volumes actuels dans Trident.

Trident prend en charge le redimensionnement des volumes persistants NFS, iSCSI et FC. Cela permet aux utilisateurs de redimensionner leurs volumes directement via la couche Kubernetes. L'extension de volume est possible pour toutes les principales plateformes de stockage NetApp , y compris ONTAP, SolidFire/ NetApp HCI et les backends Cloud Volumes Service . Pour permettre une éventuelle extension ultérieure, définissez allowVolumeExpansion à true dans votre StorageClass associée au volume. Lorsque le volume persistant doit être redimensionné, modifiez le spec.resources.requests.storage annotation dans la revendication de volume persistant à la taille de volume requise. Trident se chargera automatiquement du redimensionnement du volume sur le cluster de stockage.

L'importation de volumes permet d'importer un volume de stockage existant dans un environnement Kubernetes. Ceci est actuellement pris en charge par le ontap-nas , ontap-nas-flexgroup , solidfire-san , azure-netapp-files , et gcp-cvs conducteurs. Cette fonctionnalité est utile lors du portage d'une application existante vers Kubernetes ou lors de scénarios de reprise après sinistre.

Lors de l'utilisation d' ONTAP et solidfire-san conducteurs, utilisez la commande tridentctl import volume <backend-name> <volume-name> -f /path/pvc.yaml importer un volume existant dans Kubernetes pour qu'il soit géré par Trident. Le fichier YAML ou JSON du PVC utilisé dans la commande d'importation de volume pointe vers une classe de stockage qui identifie Trident comme le provisionneur. Lors de l'utilisation d'un système dorsal NetApp HCI/ SolidFire , assurez-vous que les noms de volumes sont uniques. Si les noms de volumes sont dupliqués, clonez le volume sous un nom unique afin que la fonction d'importation de volumes puisse les distinguer.

Si le azure-netapp-files ou gcp-cvs Le pilote est utilisé, utilisez la commande tridentctl import volume <backend-name> <volume path> -f /path/pvc.yaml pour importer le volume dans Kubernetes afin qu'il soit géré par Trident. Cela garantit une référence de volume unique.

Lorsque la commande ci-dessus est exécutée, Trident trouvera le volume sur le serveur et lira sa taille. Il ajoutera automatiquement (et écrasera si nécessaire) la taille du volume configurée du PVC. Trident crée ensuite le nouveau PV et Kubernetes lie le PVC au PV.

Si un conteneur était déployé de manière à nécessiter le PVC importé spécifique, il resterait en attente jusqu'à ce que la paire PVC/PV soit liée via le processus d'importation de volume. Une fois la paire PVC/PV assemblée, le conteneur devrait remonter, à condition qu'il n'y ait pas d'autres problèmes.

Le déploiement et la gestion du stockage pour le registre ont été documentés sur"netapp.io" dans le"blog" .

Comme les autres services OpenShift, le service de journalisation est déployé à l'aide d'Ansible avec des paramètres de configuration fournis par le fichier d'inventaire, également appelé hosts, fourni au playbook. Deux méthodes d'installation seront abordées : le déploiement de la journalisation lors de l'installation initiale d'OpenShift et le déploiement de la journalisation après l'installation d'OpenShift.

Si vous choisissez d'utiliser NFS avec le service de journalisation, vous devrez définir la variable Ansible. openshift_enable_unsupported_configurations à true pour éviter que l'installation ne tombe en panne.

Une fois les variables Ansible appropriées définies dans votre fichier hosts/inventory, déployez le service à l'aide d'Ansible. Si vous effectuez le déploiement lors de l'installation d'OpenShift, le PV sera créé et utilisé automatiquement. Si vous déployez à l'aide des playbooks de composants, après l'installation d'OpenShift, Ansible crée les PVC nécessaires et, une fois que Trident a provisionné le stockage pour ceux-ci, déploie le service.

Les variables ci-dessus, ainsi que le processus de déploiement, peuvent changer avec chaque version d'OpenShift. Assurez-vous de consulter et de suivre"Guide de déploiement OpenShift de Red Hat" pour votre version afin qu'elle soit configurée pour votre environnement.