Les machines virtuelles de stockage (SVM) assurent l'isolation et la séparation administrative entre les locataires sur un système ONTAP. L'attribution d'une SVM aux applications permet la délégation de privilèges et l'application des meilleures pratiques pour limiter la consommation de ressources.

Plusieurs options sont disponibles pour la gestion du SVM :

Dans chaque cas, l'interface doit être dans le DNS, et le nom DNS doit être utilisé lors de la configuration de Trident. Cela aide à faciliter certains scénarios de reprise après sinistre, par exemple, SVM-DR sans l'utilisation de la conservation de l'identité réseau.

Il n'y a pas de préférence entre une LIF de gestion dédiée ou partagée pour la SVM, toutefois, vous devez vous assurer que vos politiques de sécurité réseau sont compatibles avec l'approche que vous choisissez. Dans tous les cas, la LIF de gestion doit être accessible via DNS pour offrir une flexibilité maximale si "SVM-DR" est utilisée conjointement avec Trident.

Les systèmes de stockage ONTAP ont un nombre maximal de volumes, qui varie selon la version du logiciel et la plateforme matérielle. Consultez "NetApp Hardware Universe" pour votre plateforme spécifique et votre version d'ONTAP afin de déterminer les limites exactes. Lorsque le nombre de volumes est épuisé, les opérations de provisionnement échouent non seulement pour Trident, mais pour toutes les demandes de stockage.

Les pilotes de Trident ontap-nas et ontap-san provisionnent un FlexVolume pour chaque volume persistant (PV) Kubernetes créé. Le pilote ontap-nas-economy crée environ un FlexVolume pour 200 PV (configurable entre 50 et 300). Le pilote ontap-san-economy crée environ un FlexVolume pour 100 PV (configurable entre 50 et 200). Pour éviter que Trident ne consomme tous les volumes disponibles sur le système de stockage, vous devez définir une limite sur le SVM. Vous pouvez le faire depuis la ligne de commandes :

La valeur pour max-volumes varie en fonction de plusieurs critères spécifiques à votre environnement :

La max-volumes valeur correspond au total des volumes provisionnés sur l'ensemble des nœuds du cluster ONTAP, et non sur un nœud ONTAP individuel. Par conséquent, il se peut qu'un nœud de cluster ONTAP ait beaucoup plus ou beaucoup moins de volumes Trident provisionnés qu'un autre nœud.

Par exemple, un cluster ONTAP à deux nœuds peut héberger un maximum de 2 000 volumes FlexVol. Fixer le nombre maximal de volumes à 1 250 semble très raisonnable. Cependant, si seuls les "agrégats" volumes d’un nœud sont affectés à la SVM, ou si les agrégats affectés d’un nœud ne peuvent pas être provisionnés (par exemple, en raison de la capacité), alors l’autre nœud devient la cible de tous les volumes provisionnés par Trident. Cela signifie que la limite de volumes de ce nœud peut être atteinte avant que la valeur max-volumes ne soit atteinte, ce qui impacte à la fois Trident et les autres opérations de volumes utilisant ce nœud. Vous pouvez éviter cette situation en vous assurant que les agrégats de chaque nœud du cluster sont affectés à la SVM utilisée par Trident en nombre égal.

NetApp Trident prend en charge le clonage de volumes lors de l'utilisation des ontap-nas, ontap-san et solidfire-san pilotes de stockage. Lors de l'utilisation des ontap-nas-flexgroup ou ontap-nas-economy pilotes, le clonage n'est pas pris en charge. La création d'un nouveau volume à partir d'un volume existant entraînera la création d'un nouvel instantané.

Pour configurer la taille maximale des volumes pouvant être créés par Trident, utilisez le limitVolumeSize paramètre dans votre backend.json définition.

En plus de contrôler la taille du volume au niveau de la baie de stockage, vous devriez également tirer parti des capacités de Kubernetes.

Pour configurer la taille maximale pour les FlexVols utilisées comme pools pour les pilotes ontap-san-economy et ontap-nas-economy, utilisez le limitVolumePoolSize paramètre dans votre backend.json définition.

Vous pouvez spécifier les noms d'utilisateur et mots de passe de l'initiateur et de la cible CHAP dans la définition de votre backend et demander à Trident d'activer CHAP sur la SVM. En utilisant le paramètre useCHAP dans la configuration de votre backend, Trident authentifie les connexions iSCSI pour les backends ONTAP avec CHAP.

L'utilisation d'une politique QoS ONTAP, appliquée à la SVM, limite le nombre d'IOPS consommables par les volumes provisionnés Trident. Cela permet d' "empêcher un tyran"éviter qu'un conteneur défaillant ou incontrôlé n'affecte les charges de travail en dehors de la SVM Trident.

Vous pouvez créer une politique QoS pour la SVM en quelques étapes. Consultez la documentation de votre version de ONTAP pour obtenir les informations les plus précises. L'exemple ci-dessous crée une politique QoS qui limite le nombre total d'IOPS disponibles pour la SVM à 5000.

De plus, si votre version d'ONTAP le permet, vous pouvez envisager d'utiliser un minimum de QoS pour garantir un certain débit aux charges de travail conteneurisées. La QoS adaptative n'est pas compatible avec une politique au niveau SVM.

Le nombre d'IOPS dédiés aux charges de travail conteneurisées dépend de nombreux aspects. Parmi ceux-ci, on trouve notamment :

Il est important de noter qu'une politique QoS définie au niveau de la SVM implique que tous les volumes provisionnés sur la SVM partagent le même pool d'IOPS. Si une application conteneurisée, ou un petit nombre d'applications conteneurisées, a des besoins élevés en IOPS, elle risque de pénaliser les autres charges de travail conteneurisées. Si tel est le cas, vous pouvez envisager d'utiliser une automatisation externe pour attribuer des politiques QoS par volume.

La qualité de service (QoS) garantit que les performances des charges de travail critiques ne sont pas dégradées par des charges de travail concurrentes. Les groupes de règles QoS d'ONTAP offrent des options de QoS pour les volumes et permettent aux utilisateurs de définir le plafond de débit pour une ou plusieurs charges de travail. Pour plus d'informations sur la QoS, consultez "Garantir le débit avec QoS". Vous pouvez spécifier des groupes de règles QoS dans le backend ou dans un pool de stockage, et ils sont appliqués à chaque volume créé dans ce pool ou backend.

ONTAP propose deux types de groupes de stratégies QoS : traditionnels et adaptatifs. Les groupes de stratégies traditionnels offrent un débit maximal (ou minimal, dans les versions plus récentes) fixe en IOPS. La QoS adaptative ajuste automatiquement le débit à la taille de la charge de travail, en maintenant le ratio IOPS à To|Go à mesure que la taille de la charge de travail évolue. Cela représente un avantage considérable lorsque vous gérez des centaines ou des milliers de charges de travail dans un déploiement de grande envergure.

Tenez compte des points suivants lors de la création de groupes de règles QoS :

Pour plus d'informations sur les groupes de politiques QoS, consultez "Référence des commandes ONTAP".

Limiter l'accès aux volumes NFS, aux LUN iSCSI et aux LUN FC créés par Trident est un élément essentiel de la posture de sécurité de votre déploiement Kubernetes. Cela empêche les hôtes qui ne font pas partie du cluster Kubernetes d'accéder aux volumes et de modifier potentiellement les données de manière inattendue.

Il est important de comprendre que les espaces de noms constituent la limite logique des ressources dans Kubernetes. On suppose que les ressources dans le même espace de noms peuvent être partagées, cependant, il est important de noter qu'il n'existe aucune capacité inter-espaces de noms. Cela signifie que même si les PV sont des objets globaux, lorsqu'ils sont liés à un PVC, ils ne sont accessibles que par les pods qui sont dans le même espace de noms. Il est essentiel de veiller à utiliser les espaces de noms pour assurer la séparation lorsque cela est approprié.

La principale préoccupation de la plupart des organisations concernant la sécurité des données dans un contexte Kubernetes est qu'un processus exécuté dans un conteneur puisse accéder à un stockage monté sur l'hôte, mais qui n'est pas destiné au conteneur. "Espaces de noms" sont conçus pour empêcher ce type de compromission. Il existe cependant une exception : les conteneurs privilégiés.

Un conteneur privilégié est un conteneur exécuté avec des permissions au niveau de l'hôte nettement supérieures à la normale. Celles-ci ne sont pas refusées par défaut, alors assurez-vous de désactiver la capacité en utilisant "politiques de sécurité des pods".

Pour les volumes nécessitant un accès depuis Kubernetes et des hôtes externes, le stockage doit être géré de manière traditionnelle, avec la création du PV par l'administrateur et non géré par Trident. Cela garantit que le volume de stockage n'est détruit que lorsque Kubernetes et les hôtes externes sont déconnectés et n'utilisent plus le volume. De plus, une règle d'export peut être appliquée, ce qui permet l'accès depuis les nœuds du cluster Kubernetes et les serveurs cibles situés en dehors du cluster Kubernetes.

Pour les déploiements comportant des nœuds d'infrastructure dédiés (par exemple, OpenShift) ou d'autres nœuds incapables de planifier des applications utilisateur, des règles d'export distinctes doivent être utilisées afin de limiter davantage l'accès aux ressources de stockage. Cela inclut la création d'une règle d'export pour les services déployés sur ces nœuds d'infrastructure (par exemple, les services de métriques et de journalisation OpenShift), ainsi que pour les applications standard déployées sur des nœuds non dédiés à l'infrastructure.

Vous devez vous assurer qu'une règle d'export existe pour chaque backend, autorisant uniquement l'accès aux nœuds présents dans le cluster Kubernetes. Trident peut créer et gérer automatiquement des règles d'export. Ainsi, Trident limite l'accès aux volumes qu'il provisionne aux nœuds du cluster Kubernetes et simplifie l'ajout et la suppression de nœuds.

Vous pouvez également créer une règle d'export manuellement et la remplir avec une ou plusieurs règles d'export qui traitent chaque demande d'accès au nœud :

L'exécution de ces commandes vous permet de restreindre quels nœuds Kubernetes ont accès aux données.

La fonctionnalité showmount permet à un client NFS d'interroger le SVM pour obtenir une liste des exports NFS disponibles. Un pod déployé sur le cluster Kubernetes peut exécuter la commande showmount -e contre le SVM et recevoir une liste des montages disponibles, y compris ceux auxquels il n'a pas accès. Bien que cela, en soi, ne constitue pas une compromission de la sécurité, cela fournit des informations inutiles susceptibles d'aider un utilisateur non autorisé à se connecter à un export NFS.

Vous devez désactiver showmount en utilisant la commande ONTAP CLI au niveau SVM :

Chaque compte SolidFire représente un propriétaire de volume unique et reçoit ses propres identifiants Challenge-Handshake Authentication Protocol (CHAP). Vous pouvez accéder aux volumes associés à un compte soit en utilisant le nom du compte et les identifiants CHAP correspondants, soit via un groupe d'accès aux volumes. Un compte peut avoir jusqu'à deux mille volumes qui lui sont attribués, mais un volume ne peut appartenir qu'à un seul compte.

Utilisez les politiques de qualité de service (QoS) SolidFire si vous souhaitez créer et enregistrer un paramètre de qualité de service standardisé qui peut être appliqué à de nombreux volumes.

Vous pouvez configurer les paramètres QoS volume par volume. Les performances de chaque volume peuvent être garanties en définissant trois paramètres configurables qui définissent la QoS : Min IOPS, Max IOPS et Burst IOPS.

Voici les valeurs minimales, maximales et en rafale d'IOPS possibles pour la taille de bloc 4Kb.

La taille des blocs et la bande passante influent directement sur le nombre d'IOPS. Lorsque la taille des blocs augmente, le système accroît la bande passante jusqu'au niveau nécessaire pour traiter les blocs plus volumineux. Lorsque la bande passante augmente, le nombre d'IOPS que le système peut atteindre diminue. Consultez "Qualité de service SolidFire" pour plus d'informations sur la QoS et les performances.

Element prend en charge deux méthodes d'authentification : CHAP et les groupes d'accès aux volumes (VAG). CHAP utilise le protocole CHAP pour authentifier l'hôte auprès du backend. Les groupes d'accès aux volumes contrôlent l'accès aux volumes qu'ils provisionnent. NetApp recommande d'utiliser CHAP pour l'authentification, car c'est plus simple et il n'y a pas de limites de mise à l'échelle.

L'authentification CHAP (vérification que l'initiateur est bien l'utilisateur du volume) est prise en charge uniquement avec le contrôle d'accès basé sur les comptes. Si vous utilisez CHAP pour l'authentification, deux options sont disponibles : CHAP unidirectionnel et CHAP bidirectionnel. CHAP unidirectionnel authentifie l'accès au volume à l'aide du nom de compte SolidFire et du secret de l'initiateur. L'option CHAP bidirectionnel offre la méthode d'authentification la plus sécurisée, car le volume authentifie l'hôte via le nom de compte et le secret de l'initiateur, puis l'hôte authentifie le volume via le nom de compte et le secret de la cible.

Toutefois, si CHAP ne peut être activé et que des groupes d'accès aux volumes (VAG) sont requis, créez le groupe d'accès et ajoutez les initiateurs hôtes et les volumes au groupe d'accès. Chaque IQN que vous ajoutez à un groupe d'accès peut accéder à chaque volume du groupe avec ou sans authentification CHAP. Si l'initiateur iSCSI est configuré pour utiliser l'authentification CHAP, le contrôle d'accès basé sur le compte est utilisé. Si l'initiateur iSCSI n'est pas configuré pour utiliser l'authentification CHAP, alors le contrôle d'accès du Volume Access Group est utilisé.