Les pilotes back-end ONTAP sont différenciés par le protocole utilisé et le mode de provisionnement des volumes sur le système de stockage. Par conséquent, réfléchissez bien au choix du conducteur à déployer.

À un niveau plus élevé, si votre application dispose de composants qui nécessitent un stockage partagé (plusieurs modules accédant au même volume de demande de volume persistant), les pilotes NAS seraient la solution par défaut, tandis que les pilotes iSCSI basés sur les blocs répondent aux besoins d'un stockage non partagé. Choisir le protocole en fonction des besoins de l'application et du niveau de confort des équipes chargées du stockage et de l'infrastructure. En règle générale, ces différences sont peu nombreuses pour la plupart des applications. La décision dépend donc souvent de la nécessité d'un stockage partagé (dans lequel plusieurs pods auront besoin d'un accès simultané).

Les pilotes ONTAP backend disponibles sont les suivants :

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

Il est à noter que dans les tableaux ci-dessous, toutes les fonctionnalités ne sont pas exposées par Astra Trident. L'administrateur du stockage doit appliquer une partie après le provisionnement si cette fonctionnalité est souhaitée. Les notes de bas de page en exposant distinguent les fonctionnalités par fonction et pilote.

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

Les fonctionnalités qui ne sont pas granulaires volume persistant sont appliquées à l'ensemble du volume flexible et tous les volumes persistants (qtrees ou LUN inclus dans les volumes FlexVol partagés) partageront une planification commune.

Comme nous le voyons dans les tableaux ci-dessus, la plupart des fonctionnalités entre ontap-nas et ontap-nas-economy sont identiques. Toutefois, comme ontap-nas-economy le pilote limite la capacité à contrôler la planification au niveau de la granularité par volume persistant, cela peut avoir un impact particulier sur la planification de la reprise d'activité et de la sauvegarde. Pour les équipes de développement qui souhaitent exploiter la fonctionnalité de clonage PVC sur le stockage ONTAP, cette fonctionnalité n'est possible que lorsque des pilotes , ontap-san ou ontap-san-economy sont utilisés ontap-nas.

Cloud Volumes ONTAP assure le contrôle des données et des fonctionnalités de stockage haute performance dans divers cas d'utilisation, notamment pour les partages de fichiers et le stockage de niveau bloc qui servent les protocoles NAS et SAN (NFS, SMB/CIFS et iSCSI). Les pilotes compatibles avec Cloud Volume ONTAP sont ontap-nas, ontap-nas-economy ontap-san et ontap-san-economy. Applicable à Cloud Volume ONTAP pour Azure, Cloud Volume ONTAP pour GCP.

Avec Amazon FSX pour NetApp ONTAP, vous exploitez les fonctionnalités, les performances et les capacités d'administration d'NetApp que vous connaissez déjà, tout en profitant 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 de système de fichiers ONTAP et API d'administration. Les pilotes compatibles avec Cloud Volume ONTAP sont ontap-nas, , ontap-nas-economy ontap-nas-flexgroup ontap-san et ontap-san-economy.

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

ASTRA Trident utilise le azure-netapp-files pilote pour gérer le "Azure NetApp Files"service.

Pour plus d'informations sur ce pilote et sur sa configuration"Configuration back-end d'Astra Trident pour Azure NetApp Files", reportez-vous à la section .

ASTRA Trident utilise gcp-cvs le pilote pour établir un lien avec Cloud Volumes Service sur Google Cloud.

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

Pour configurer le back-end Google Cloud sur Astra Trident, vous devez spécifier projectNumber, apiRegion et apiKey dans le fichier back-end. Le numéro de projet est indiqué dans la console Google Cloud. La clé API est utilisée depuis le 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 Cloud Volumes Service sur les types de services et les niveaux de service Google Cloud, reportez-vous à "En savoir plus sur la prise en charge d'Astra Trident pour CVS pour GCP"la section .

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

Le storagePools paramètre permet de limiter le stockage à l'ensemble de pools correspondant à n'importe quel attribut spécifié. Le additionalStoragePools paramètre est utilisé pour étendre l'ensemble de pools qu'Astra Trident utilisera pour le provisionnement, ainsi que l'ensemble de pools sélectionné par les attributs et les 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 paramètre est utilisé pour exclure spécifiquement l'ensemble de pools répertoriés qui correspondent aux attributs.

Si vous souhaitez concevoir des classes de stockage pour émuler des stratégies de qualité de service, créez une classe de stockage avec media l'attribut comme hdd ou ssd. En fonction de l' media`attribut mentionné dans la classe de stockage, Trident sélectionne le back-end approprié qui sert `hdd ou ssd regroupe les agrégats pour correspondre à l'attribut de support, puis dirige le provisionnement des volumes vers l'agrégat spécifique. Nous pouvons donc créer une PRIME DE classe de stockage dont l'attribut aurait media été défini et ssd qui pourrait être classé comme la politique de QoS PREMIUM. Nous pouvons créer une autre NORME de classe de stockage dont l'attribut de support est défini comme `hdd', qui pourrait être classé comme règle de QoS STANDARD. Nous pourrions également utiliser l'attribut « IOPS » de la classe de stockage pour rediriger le provisionnement vers une appliance Element qui peut être définie comme une règle de QoS.

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

Des pools virtuels sont disponibles pour tous les systèmes back-end Astra Trident. Vous pouvez définir des pools virtuels pour tout système back-end, à l'aide de n'importe quel pilote fourni par Astra Trident.

Les pools virtuels permettent à un administrateur de créer un niveau d'abstraction sur les systèmes back-end, qui peut être référencé via des classes de stockage, pour une plus grande flexibilité et un placement efficace des volumes dans les systèmes back-end. Différents systèmes back-end peuvent être définis avec la même classe de service. En outre, il est possible de créer plusieurs pools de stockage sur le même back-end, mais avec des caractéristiques différentes. Lorsqu'une classe de stockage est configurée avec un sélecteur portant les étiquettes spécifiques, Astra Trident choisit un système back-end correspondant à toutes les étiquettes de sélection pour placer le volume. Si les étiquettes de sélection de classe de stockage correspondent à plusieurs pools de stockage, Astra Trident choisira l'un d'entre eux pour provisionner le volume.

Il est possible de concevoir des pools virtuels pour émuler des classes de service. Grâce à l'implémentation du pool virtuel pour Cloud volumes Service pour Azure NetApp Files, examinons comment nous pouvons configurer différentes classes de service. Configurer le back-end Azure NetApp Files avec plusieurs étiquettes représentant différents niveaux de performances. Définissez servicelevel l'aspect sur le niveau de performance approprié et ajoutez d'autres aspects requis sous chaque étiquette. Créez désormais différentes classes de stockage Kubernetes qui seraient mappées sur différents pools virtuels. En utilisant ce parameters.selector champ, chaque classe de stockage indique quels pools virtuels peuvent être utilisés pour héberger un volume.

Il est possible de concevoir plusieurs pools virtuels, dont les aspects sont spécifiques, à partir d'un système back-end unique. Pour ce faire, configurez le back-end avec plusieurs étiquettes et définissez les aspects requis sous chaque étiquette. Créez maintenant différentes classes de stockage Kubernetes à l'aide du parameters.selector champ qui serait mappé sur différents pools virtuels. Les volumes provisionnés sur le back-end possèdent les aspects définis dans le pool virtuel choisi.

Certains paramètres au-delà de la classe de stockage requise peuvent affecter le processus de décision de provisionnement Astra Trident lors de la création d'un volume persistant.

Lors de la demande de stockage via un PVC, l'un des champs obligatoires est le mode d'accès. Le mode désiré peut affecter le back-end sélectionné pour héberger la demande de stockage.

Astra Trident tentera de correspondre au protocole de stockage utilisé avec la méthode d'accès spécifiée dans la matrice suivante. Cette technologie est indépendante de la plateforme de stockage sous-jacente.

Toute demande de volume persistant ReadWriteMany soumise à un déploiement Trident sans système back-end NFS configuré entraînera le provisionnement d'un volume. Pour cette raison, le demandeur doit utiliser le mode d'accès qui convient à son application.

Les volumes persistants sont, à deux exceptions près, des objets immuables dans Kubernetes. Une fois créée, la règle de récupération et la taille peuvent être modifiées. Toutefois, certains aspects du volume ne peuvent pas être modifiés en dehors de Kubernetes. Vous pouvez ainsi personnaliser le volume pour des applications spécifiques, en veillant à ce que la capacité ne soit pas accidentellement consommée ou tout simplement pour déplacer le volume vers un autre contrôleur de stockage pour n'importe quelle raison.

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

Astra Trident prend en charge la création de copies Snapshot de volume à la demande et la création de demandes de volume persistant à partir de copies Snapshot via le framework CSI. Les snapshots constituent une méthode pratique de conservation des copies ponctuelles des données et ont un cycle de vie indépendant du volume persistant source dans Kubernetes. Ces snapshots peuvent être utilisés pour cloner des demandes de volume persistant.

Astra Trident prend également en charge la création de volumes persistant à partir des snapshots de volume. Pour ce faire, il suffit de créer une demande de volume persistant et de mentionner l' datasource comme instantané requis à partir duquel le volume doit être créé. Astra Trident va gérer ce volume de volume persistant en créant un volume dont les données sont présentes sur le snapshot. Grâce à cette fonctionnalité, il est possible de dupliquer des données entre régions, de créer des environnements de test, de remplacer un volume de production endommagé ou corrompu dans son intégralité, ou de récupérer des fichiers et des répertoires spécifiques et de les transférer vers un autre volume attaché.

Les administrateurs du stockage peuvent déplacer des volumes entre les agrégats et les contrôleurs du cluster ONTAP sans interruption pour l'utilisateur du stockage. Cette opération n'affecte pas Astra Trident ou le cluster Kubernetes, tant que l'agrégat de destination est un auquel le SVM utilisé par Astra Trident a accès. Important : si l'agrégat a été récemment ajouté au SVM, le système back-end devra être actualisé en le ajoutant à Astra Trident. Cela déclenchera l'Astra Trident afin de réinventorier la SVM afin que le nouvel agrégat soit reconnu.

Néanmoins, Astra Trident ne prend pas automatiquement en charge le déplacement des volumes entre les systèmes back-end. Il s'agit notamment d'étendre les SVM au sein d'un même cluster, entre plusieurs clusters ou sur une autre plateforme de stockage (même si ce système est un SVM connecté à Astra Trident).

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

Astra Trident prend en charge le redimensionnement des volumes NFS et iSCSI PVS. Les utilisateurs peuvent ainsi 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 systèmes back-end Cloud Volumes Service. Pour autoriser une éventuelle extension ultérieurement, définissez allowVolumeExpansion sur true dans votre classe de stockage associée au volume. Lorsque le volume persistant doit être redimensionné, modifiez l' `spec.resources.requests.storage`annotation de la demande de volume persistant en fonction de la taille de volume requise. Trident s'occupe 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 les ontap-nas pilotes , ontap-nas-flexgroup, solidfire-san, azure-netapp-files et gcp-cvs . Cette fonctionnalité est utile lors du portage d'une application existante sur Kubernetes ou lors de scénarios de reprise après incident.

Lorsque vous utilisez ONTAP et solidfire-san des pilotes, utilisez la commande tridentctl import volume <backend-name> <volume-name> -f /path/pvc.yaml pour importer un volume existant dans Kubernetes et le gérer par Astra Trident. Le fichier PVC YAML ou JSON utilisé dans la commande de volume d'importation pointe vers une classe de stockage qui identifie Astra Trident comme provisionneur. Si vous utilisez un système back-end NetApp HCI/SolidFire, assurez-vous que les noms des volumes sont uniques. Si les noms des volumes sont dupliqués, cloner le volume en un nom unique afin que la fonctionnalité d'importation des volumes puisse les distinguer.

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

À l'exécution de la commande ci-dessus, Astra Trident trouve le volume sur le back-end et lit sa taille. Il ajoute automatiquement (et écrase si nécessaire) la taille du volume de la demande de volume configurée. Astra Trident crée ensuite le nouveau volume persistant, et Kubernetes lie la demande de volume persistant au volume persistant.

Lorsqu'un conteneur a été déployé de façon à ce qu'il ait besoin de la demande de volume persistant importée spécifique, il resterait dans un état 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 liée, le conteneur doit s'installer, à 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 "netapp.io"dans le "Blog".

Comme les autres services OpenShift, le service de journalisation est déployé à l'aide d'Ansible avec les paramètres de configuration fournis par le fichier d'inventaire, également appelé hôtes, fourni avec le PlayBook. Deux méthodes d'installation sont proposées : le déploiement de la journalisation lors de l'installation initiale d'OpenShift et le déploiement de la journalisation une fois OpenShift installé.

Si vous choisissez d'utiliser NFS avec le service de journalisation, vous devez définir la variable Ansible openshift_enable_unsupported_configurations sur true pour empêcher l'échec du programme d'installation.

Déployez le service à l'aide des variables Ansible appropriées définies dans votre fichier hôtes/d'inventaire. Si vous déployez au moment de l'installation d'OpenShift, le volume persistant est créé et utilisé automatiquement. Si vous déployez à l'aide des playbooks des composants après l'installation d'OpenShift, Ansible crée les demandes PVCS requises et, une fois qu'Astra Trident a provisionné le stockage pour eux, déploie le service.

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