La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Configuration de stockage sous-jacente

Contributeurs

Chaque plateforme de stockage du portefeuille NetApp dispose de fonctionnalités uniques qui bénéficient aux applications, conteneurisées ou non. Trident fonctionne avec ONTAP et Element. Il n’existe pas de plate-forme mieux adaptée à toutes les applications et tous les scénarios qu’une autre. Cependant, les besoins de l’application et l’équipe chargée de l’administration du périphérique doivent être pris en compte lors du choix d’une plate-forme.

Vous devez suivre les meilleures pratiques de base du système d’exploitation hôte avec le protocole utilisé. Vous pouvez éventuellement envisager d’intégrer les meilleures pratiques des applications, le cas échéant, avec des paramètres de back-end, de classe de stockage et de volume persistant afin d’optimiser le stockage pour certaines applications.

Meilleures pratiques pour ONTAP et Cloud Volumes ONTAP

Découvrez les bonnes pratiques pour la configuration d’ONTAP et de Cloud Volumes ONTAP pour Trident.

Les recommandations suivantes sont des instructions de configuration de ONTAP pour les workloads conteneurisés, qui consomment des volumes provisionnés dynamiquement par Trident. Chaque élément doit être pris en compte et évalué en fonction de la pertinence dans votre environnement.

Utilisation de SVM(s) dédié(s) à Trident

Les machines virtuelles de stockage (SVM) assurent l’isolation et la séparation administrative entre les locataires sur un système ONTAP. La dédier un SVM aux applications permet de déléguer des privilèges et d’appliquer les meilleures pratiques en matière de limitation de la consommation des ressources.

Plusieurs options sont disponibles pour la gestion de la SVM :

  • Fournir l’interface de gestion du cluster en configuration back-end avec les identifiants appropriés et spécifier le nom du SVM

  • Créer une interface de gestion dédiée pour le SVM via ONTAP System Manager ou l’interface de ligne de commande.

  • Partage du rôle de gestion avec une interface de données NFS

Dans chaque cas, l’interface doit être dans DNS et le nom DNS doit être utilisé lors de la configuration de Trident. Ainsi, certaines scénarios de reprise après incident, par exemple SVM-DR, sans conservation des identités de réseau.

Il n’existe aucune préférence entre une LIF de gestion dédiée ou partagée pour le SVM, cependant, vous devez vous assurer que vos stratégies de sécurité réseau sont en adéquation avec l’approche de votre choix. Indépendamment de la situation, le LIF de gestion doit être accessible via DNS pour faciliter une flexibilité maximale "SVM-DR" Utilisation en association avec Trident.

Limitez le nombre maximal de volumes

Les systèmes de stockage ONTAP disposent d’un nombre maximal de volumes, qui varie selon la version logicielle et la plateforme matérielle. Voir "NetApp Hardware Universe" Pour votre plateforme et votre version 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 l’ensemble des requêtes de stockage.

Trident ontap-nas et ontap-san Des pilotes provisionnent un volume flexible pour chaque volume persistant Kubernetes créé. Le ontap-nas-economy Le pilote crée environ un FlexVolume pour chaque 200 PVS (configurable entre 50 et 300). Le ontap-san-economy Le pilote crée environ un FlexVolume pour chaque 100 PVS (configurable entre 50 et 200). Pour empêcher Trident de consommer tous les volumes disponibles sur le système de stockage, vous devez définir une limite sur la SVM. Vous pouvez le faire à partir de la ligne de commande :

vserver modify -vserver <svm_name> -max-volumes <num_of_volumes>

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

  • Le nombre de volumes existants dans le cluster ONTAP

  • Le nombre de volumes que vous prévoyez de provisionner en dehors de Trident pour d’autres applications

  • Nombre de volumes persistants que les applications Kubernetes devraient consommer

Le max-volumes Valeur est le volume total provisionné sur tous les nœuds du cluster ONTAP et non sur un nœud ONTAP individuel. Par conséquent, vous pouvez rencontrer des situations où un nœud de cluster ONTAP peut avoir plus ou moins de volumes provisionnés Trident qu’un autre nœud.

Par exemple, un cluster ONTAP à deux nœuds peut héberger un maximum de 2000 volumes flexibles. Avoir le volume maximum réglé sur 1250 semble très raisonnable. Cependant, si seulement "64 bits" Depuis un nœud est attribué à la SVM, ou les agrégats attribués à partir d’un nœud ne peuvent pas être provisionnés sur (par exemple, en raison de la capacité). L’autre nœud devient alors la cible de tous les volumes provisionnés par Trident. Cela signifie que le volume peut être atteint en limite pour ce nœud avant le max-volumes La valeur est atteinte, ce qui affecte Trident et les autres opérations de volume utilisant ce nœud. Vous pouvez éviter cette situation en vous assurant que les agrégats de chaque nœud du cluster sont attribués à la SVM utilisée par Trident en chiffres égaux.

Limitez la taille maximale des volumes créés par Trident

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

Vous devez aussi exploiter les fonctionnalités Kubernetes pour contrôler la taille du volume au niveau de la baie de stockage.

Configurez Trident pour utiliser le protocole CHAP bidirectionnel

Vous pouvez spécifier l’initiateur CHAP et les noms d’utilisateur et mots de passe cibles dans votre définition du système back-end et activer Trident sur la SVM. À l’aide du useCHAP Paramètre dans votre configuration back-end, Trident authentifie les connexions iSCSI pour les systèmes back-end ONTAP avec CHAP. La prise en charge CHAP bidirectionnelle est disponible avec Trident 20.04 et versions ultérieures.

Création et utilisation d’une politique de QoS de SVM

L’utilisation d’une politique de QoS de ONTAP appliquée au SVM limite le nombre de consommables d’IOPS par les volumes provisionnés par Trident. Cela permet de "évitez un tyran" Ou un conteneur hors contrôle de affectant les charges de travail en dehors du SVM Trident.

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

# create the policy group for the SVM
qos policy-group create -policy-group <policy_name> -vserver <svm_name> -max-throughput 5000iops

# assign the policy group to the SVM, note this will not work
# if volumes or files in the SVM have existing QoS policies
vserver modify -vserver <svm_name> -qos-policy-group <policy_name>

Si votre version d’ONTAP la prend en charge, il est également possible d’utiliser un minimum de QoS pour garantir un débit minimum pour les workloads conteneurisés. La QoS adaptative n’est pas compatible avec une règle de niveau SVM.

Le nombre d’IOPS dédiées aux workloads conteneurisés dépend de plusieurs aspects. Entre autres choses :

  • Autres charges de travail qui utilisent la baie de stockage. Si certaines charges de travail, autres que celles liées au déploiement Kubernetes avec les ressources de stockage, veillez à ne pas affecter accidentellement ces charges de travail.

  • Workloads attendus s’exécutant dans des conteneurs. Si des charges de travail qui exigent des IOPS élevées s’exécutent dans des conteneurs, une faible politique de QoS entraîne une mauvaise expérience.

Il est important de rappeler qu’une politique de QoS attribuée au niveau du SVM entraîne tous les volumes provisionnés sur la SVM et partageant le même pool d’IOPS. Si l’une des applications conteneurisées a une exigence d’IOPS élevées, elle pourrait devenir une force dominante pour les autres workloads conteneurisés. Dans ce cas, vous pourriez envisager d’utiliser l’automatisation externe pour attribuer des règles de QoS par volume.

Important Vous devez affecter la « policy group » QoS à la SVM Only si la version de votre ONTAP est antérieure à 9.8.

Création de groupes de règles de QoS pour Trident

La qualité de service (QoS) garantit que les performances des workloads stratégiques ne sont pas dégradées par des charges de travail concurrentes. Les groupes de règles de QoS de ONTAP proposent 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, voir "Débit garanti avec la QoS". Vous pouvez spécifier des groupes de règles de QoS dans le back-end ou dans un pool de stockage, et ils sont appliqués à chaque volume créé dans ce pool ou back-end.

ONTAP propose deux types de groupes de règles de QoS : classiques et évolutifs. Les groupes de règles classiques fournissent un débit minimal (ou minimal, dans les versions ultérieures) plat en IOPS. La QoS adaptative ajuste automatiquement le débit en fonction de la taille du workload. Elle maintient le rapport entre les IOPS et les To|Go en fonction de l’évolution de la taille du workload. Vous pouvez ainsi gérer des centaines, voire des milliers de charges de travail dans le cadre d’un déploiement à grande échelle.

Avant de créer des groupes de règles de QoS, tenez compte des points suivants :

  • Vous devez définir le qosPolicy saisissez le defaults bloc de la configuration back-end. Voir l’exemple de configuration back-end suivant :

  {
    "version": 1,
    "storageDriverName": "ontap-nas",
    "managementLIF": "0.0.0.0",
    "dataLIF": "0.0.0.0",
    "svm": "svm0",
    "username": "user",
    "password": "pass",
    "defaults": {
      "qosPolicy": "standard-pg"
    },
    "storage": [
      {
        "labels": {"performance": "extreme"},
        "defaults": {
          "adaptiveQosPolicy": "extremely-adaptive-pg"
        }
      },
      {
        "labels": {"performance": "premium"},
        "defaults": {
          "qosPolicy": "premium-pg"
        }
      }
    ]
  }
  • Vous devez appliquer les « policy groups » par volume pour que chaque volume bénéficie de l’intégralité du débit spécifié par le « policy group ». Les groupes de stratégies partagés ne sont pas pris en charge.

Pour plus d’informations sur les « policy Groups » de QoS, reportez-vous à la section "Commandes QoS de ONTAP 9.8".

Limitez l’accès aux ressources de stockage aux membres du cluster Kubernetes

La limitation de l’accès aux volumes NFS et aux LUN iSCSI créés par Trident est un composant stratégique du niveau de sécurité pour votre déploiement Kubernetes. En effet, les hôtes qui ne font pas partie du cluster Kubernetes n’accèdent pas aux volumes et peuvent modifier les données de façon inattendue.

Il est important de comprendre que les espaces de noms sont la limite logique des ressources dans Kubernetes. L’hypothèse est que les ressources dans un même espace de noms peuvent être partagées, mais, surtout, il n’existe aucune fonctionnalité de multi-espace de noms. Même si les volumes persistants sont des objets globaux, lorsqu’ils sont liés à une demande de volume persistant, ils ne sont accessibles que par des pods qui se trouvent dans le même espace de noms. Il est essentiel de s’assurer que les espaces de noms sont utilisés pour fournir la séparation, le cas échéant.

La préoccupation principale de la plupart des entreprises en ce qui concerne la sécurité des données dans un contexte Kubernetes est qu’un processus dans un conteneur peut accéder au stockage monté sur l’hôte, mais qui n’est pas destiné au conteneur. "Espaces de noms" sont conçus pour éviter ce type de compromis. Toutefois, il y a une exception : les conteneurs privilégiés.

Un conteneur privilégié est un conteneur exécuté avec beaucoup plus d’autorisations au niveau de l’hôte que la normale. Par défaut, ces dernières ne sont pas refusées. Veillez donc à désactiver cette fonctionnalité en utilisant "stratégies de sécurité des pods".

Pour les volumes pour lesquels l’accès est demandé depuis Kubernetes et des hôtes externes, le stockage doit être géré de manière classique, avec le volume persistant introduit par l’administrateur et non géré par Trident. Cela garantit que le volume de stockage est détruit uniquement lorsque les hôtes Kubernetes et externes sont déconnectés et qu’ils n’utilisent plus le volume. En outre, il est possible d’appliquer une export policy personnalisée qui permet l’accès depuis les nœuds de cluster Kubernetes et les serveurs ciblés à l’extérieur du cluster Kubernetes.

Pour les déploiements qui disposent de nœuds d’infrastructure dédiés (OpenShift, par exemple) ou d’autres nœuds ne pouvant pas être planificateurs pour les applications utilisateur, il est recommandé d’utiliser des règles d’exportation distinctes pour limiter davantage l’accès aux ressources de stockage. Cela inclut la création d’une export policy pour les services qui sont déployés sur ces nœuds d’infrastructure (par exemple les services OpenShift Metrics et Logging Services), ainsi que pour les applications standard déployées sur des nœuds non liés à l’infrastructure.

Utiliser une export policy dédiée

Vous devez vous assurer qu’il existe une export policy pour chaque backend qui autorise 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’exportation depuis la version 20.04. Trident limite ainsi l’accès aux volumes qu’il provisionne aux nœuds du cluster Kubernetes et simplifie l’ajout et la suppression des nœuds.

Vous pouvez également créer une export policy manuellement et la remplir à l’aide d’une ou plusieurs règles d’exportation qui traitent chaque demande d’accès de nœud :

  • Utilisez le vserver export-policy create Commande CLI ONTAP pour créer l’export policy.

  • Ajoutez des règles à la export policy à l’aide de vserver export-policy rule create Commande CLI ONTAP.

L’exécution de ces commandes vous permet de limiter l’accès aux données aux nœuds Kubernetes.

Désactiver showmount Pour le SVM applicatif

Le showmount Cette fonctionnalité permet à un client NFS d’interroger le SVM pour obtenir la liste des exportations NFS disponibles. Un pod déployé sur le cluster Kubernetes peut lancer le showmount -e Commande au niveau de la LIF de données et reçoit la liste des montages disponibles, y compris ceux auxquels elle n’a pas accès. Bien qu’il ne s’agisse pas d’un compromis sur la sécurité, cette solution fournit des informations inutiles susceptibles d’aider un utilisateur non autorisé à se connecter à une exportation NFS.

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

vserver nfs modify -vserver <svm_name> -showmount disabled

Les meilleures pratiques pour SolidFire

Découvrez les bonnes pratiques pour la configuration du stockage SolidFire pour Trident.

Créer un compte SolidFire

Chaque compte SolidFire représente un propriétaire de volume unique et reçoit ses propres informations d’identification CHAP (Challenge-Handshake Authentication Protocol). Vous pouvez accéder aux volumes affectés à un compte en utilisant le nom du compte et les informations d’identification CHAP relatives ou par le biais d’un groupe d’accès de volume. Un compte peut comporter jusqu’à deux milliers de volumes qui lui sont attribués, mais un volume ne peut appartenir qu’à un seul compte.

Création d’une règle de QoS

Utilisez les règles de QoS SolidFire pour créer et enregistrer des paramètres de qualité de service standardisés qui peuvent être appliqués à de nombreux volumes.

Vous pouvez définir des paramètres de QoS par volume. Les performances de chaque volume peuvent être garanties en définissant trois paramètres configurables pour définir les QoS : IOPS min, IOPS max et IOPS en rafale.

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

Paramètre IOPS Définition Minimum valeur Valeur par défaut Capacité Valeur (4 Ko)

IOPS min

Niveau de performance garanti pour un volume.

50

50

15000

IOPS max

La performance ne dépassera pas cette limite.

50

15000

200,000

IOPS en rafale

IOPS maximales autorisées en rafale,

50

15000

200,000

Remarque Même si les IOPS maximales et en rafale peuvent être définies jusqu’à 200,000, les performances maximales réelles d’un volume sont limitées par l’utilisation du cluster et les performances par nœud.

La taille et la bande passante des blocs influencent directement le nombre d’opérations d’entrée/sortie par seconde. Lorsque la taille de bloc augmente, le système augmente la bande passante jusqu’au niveau nécessaire pour traiter les tailles de bloc de taille supérieure. Lorsque la bande passante augmente, le nombre d’IOPS augmente, le système peut atteindre une baisse. Voir "Qualité de service SolidFire" Pour plus d’informations sur la qualité de service et les performances.

Authentification SolidFire

Element prend en charge deux méthodes d’authentification : CHAP et VAG (Volume Access Groups). CHAP utilise le protocole CHAP pour authentifier l’hôte au back-end. Les groupes d’accès de volume contrôlent l’accès aux volumes qu’ils provisionne. NetApp recommande d’utiliser le protocole CHAP pour l’authentification, car il est plus simple et ne comporte pas de limites d’évolutivité.

Remarque Trident avec le mécanisme de provisionnement CSI amélioré prend en charge l’authentification CHAP. Les VAGs ne doivent être utilisés que dans le mode de fonctionnement traditionnel non CSI.

L’authentification CHAP (vérification que l’initiateur est l’utilisateur de volume prévu) n’est prise en charge qu’avec un contrôle d’accès basé sur le compte. Si vous utilisez CHAP pour l’authentification, deux options sont disponibles : CHAP unidirectionnel et CHAP bidirectionnel. L’authentification CHAP unidirectionnelle authentifie l’accès au volume à l’aide du nom du compte SolidFire et du secret de l’initiateur. L’option CHAP bidirectionnelle fournit le moyen le plus sûr d’authentifier le volume car le volume authentifie l’hôte via le nom du compte et le secret de l’initiateur, puis l’hôte authentifie le volume via le nom du compte et le secret cible.

Toutefois, si CHAP ne peut pas être activé et que VAGs 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, un contrôle d’accès basé sur les comptes est utilisé. Si l’initiateur iSCSI n’est pas configuré pour utiliser l’authentification CHAP, le contrôle d’accès au groupe d’accès de volume est utilisé.

Où trouver plus d’informations ?

Une partie de la documentation sur les meilleures pratiques est présentée ci-dessous. Rechercher dans le "Bibliothèque NetApp" pour les versions les plus récentes.

ONTAP

Logiciel Element

NetApp HCI

Information sur les pratiques exemplaires des applications

Toutes les applications ne disposent pas d’instructions spécifiques, il est important de collaborer avec votre équipe NetApp et d’utiliser le "Bibliothèque NetApp" pour trouver la documentation la plus récente.