Les versions prises en charge d'ONTAP, d'ESXi et de vCenter Server varient selon la version d'ONTAP tools. L'hôte ESXi et vCenter Server utilisés pour déployer la machine virtuelle ONTAP tools peuvent également avoir des exigences distinctes et plus restrictives que les versions que ONTAP tools peut gérer après le déploiement. Les versions prises en charge changent d'une version à l'autre ; vérifiez donc toujours les "Matrice d'interopérabilité NetApp" et "Exigences et limites de configuration des outils ONTAP pour VMware vSphere"pour la version que vous utilisez.

La plupart des environnements bénéficient du passage à la dernière version 10.x de ONTAP tools. Par rapport à ONTAP tools 9.13, elle ajoute la prise en charge de NVMe-oF pour VMFS, est compatible avec des versions plus récentes de ONTAP et de VMware vSphere, et prend en charge plusieurs instances de serveur vCenter par appliance au lieu d'une seule. Il est judicieux de rester sur ONTAP tools 9.x uniquement si votre environnement présente une dépendance spécifique que la dernière version 10.x ne prend pas encore en charge, et il vaut la peine de planifier la migration sans tarder, car ONTAP tools 9.x approche de sa fin de support. Consultez la page "NetApp Site d'assistance - Prise en charge des versions logicielles" pour connaître les dates de fin de support actuelles. Consultez le "Comparaison des fonctionnalités des outils ONTAP pour VMware vSphere par version" et le "Matrice d'interopérabilité NetApp" pour confirmer quelle version correspond à vos versions de ONTAP, ESXi et vSphere.

ONTAP tools se déploie toujours initialement comme une appliance extra-small (XS) à nœud unique, fournissant les services de base pour les datastores NFS et VMFS. Si vous avez ensuite besoin de davantage de ressources, d'une résilience plus élevée ou de vVols et de la haute disponibilité (HA), vous pouvez passer à une taille small, medium ou large, ou étendre le déploiement vers HA ; les déploiements HA sont multinœuds, utilisent trois nœuds et nécessitent une bibliothèque de contenu, et les déploiements large ne sont pris en charge qu'avec HA. Pour prendre en charge l'extension HA, déployez l'appliance dans un cluster ESXi ou un pool de ressources, et assurez-vous que l'ajout à chaud du processeur et l'ajout à chaud de la mémoire sont activés ; à partir de ONTAP tools 10.6, les nouveaux déploiements activent ces paramètres par défaut. Les ressources de processeur, de mémoire et de disque pour chaque taille sont répertoriées dans "Exigences et limites de configuration des outils ONTAP pour VMware vSphere", il est donc prudent de commencer avec la valeur XS par défaut et d'étendre à mesure que vos besoins augmentent. ONTAP tools prend uniquement en charge la mise à l'échelle vers le haut : vous pouvez seulement augmenter la taille des nœuds, pas la réduire, et après avoir activé HA, vous ne pouvez pas revenir à une configuration non HA à nœud unique. Pour les étapes de déploiement, de dimensionnement et d'extension, consultez "Démarrage rapide des outils ONTAP pour VMware vSphere", "Flux de travail de déploiement à haute disponibilité pour ONTAP tools" et "Augmentez l'échelle des ONTAP tools et activez la haute disponibilité".

La solution HA est conçue pour assurer la reprise après une panne d’hôte sur un nœud unique, une panne réseau, une panne du système d’exploitation invité ou une erreur sur une application ONTAP tools. Les déploiements HA utilisent trois nœuds, qui doivent se trouver sur le même sous-réseau pour permettre la communication entre les nœuds. L’ajout à chaud du processeur et le branchement à chaud de la mémoire doivent être activés ; le workflow HA requiert également VASA Provider pour les banques de données vVols. Consultez "Flux de travail de déploiement à haute disponibilité pour ONTAP tools" pour connaître la procédure d’installation.

La haute disponibilité (HA) n'est pas requise si vous utilisez uniquement des datastores NFS ou VMFS sans vVols, mais elle offre une résilience plus large face aux pannes d'un hôte à nœud unique, du réseau, du système d'exploitation invité ou de l'application ONTAP tools. La haute disponibilité (HA) est requise pour assurer la disponibilité continue du service VASA Provider pour les datastores vVols. Utilisez donc un déploiement HA si vous utilisez des vVols, ou si vous avez besoin d'une résilience de service plus élevée et d'un plus grand nombre de conteneurs par service que n'en offre un déploiement sur un seul nœud.

Oui. Contrairement à ONTAP tools 9.x, qui ne prend en charge qu’un seul vCenter Server par appliance, ONTAP tools 10.x prend en charge le mode multitenant et vous permet de gérer plusieurs instances de vCenter Server à partir d’une seule interface ONTAP tools Manager, réduisant ainsi le nombre d’appliances et les besoins globaux en ressources. Si vous utilisez des datastores vVols sur plusieurs instances de vCenter Server, remplacez le certificat auto-signé par un certificat signé par une autorité de certification afin de sécuriser les communications. Consultez "Ajouter des instances vCenter Server aux outils ONTAP" pour connaître la procédure.

Un déploiement à nœud unique nécessite trois adresses IPv4 statiques uniques sur le même sous-réseau:

Un déploiement HA ajoute une adresse IP supplémentaire pour chacun des deuxième et troisième nœuds ; l’adresse IP de ONTAP tools et l’adresse IP virtuelle sont partagées entre tous les nœuds. Consultez "Exigences et limites de configuration des outils ONTAP pour VMware vSphere" et "Exigences préalables au déploiement des ONTAP tools" pour obtenir la feuille de travail de déploiement complète.

ONTAP tools expose les ports 443 et 8443 comme ports de transfert externes pour ONTAP tools Manager, l'API REST, le fournisseur VASA et le back-end du plug-in client vSphere. Les autres ports du tableau des exigences de ports sont des ports inter-nœuds utilisés en interne par le cluster Kubernetes de l'appliance ; dans un déploiement à nœud unique, ils ne nécessitent pas d'accès externe, et dans un déploiement HA, les trois nœuds doivent pouvoir se joindre sur ces ports, y compris UDP 8472 pour la communication de pod à pod. Voir "Exigences et limites de configuration des outils ONTAP pour VMware vSphere" pour le tableau complet des ports.

Un certificat sécurise une connexion uniquement s'il prouve l'identité du serveur auquel vous vous connectez. L'extension SAN (Subject Alternative Name) fournit cette preuve : elle répertorie les noms DNS et les adresses IP pour lesquels le certificat est valide.

Le certificat SSL de la machine du serveur vCenter doit répondre aux exigences suivantes :

Si le certificat n'a pas de SAN, ou si le SAN ne correspond pas au nom DNS, à l'adresse IP ou au PNID du serveur vCenter, les opérations des outils ONTAP échouent avec des erreurs de validation du certificat. Cette validation ne peut pas être désactivée. Corrigez le SAN avec vSphere Certificate Manager avant d'ajouter l'instance du serveur vCenter. Consultez "Ajouter des instances vCenter Server aux outils ONTAP" pour connaître les exigences et obtenir des exemples concernant les certificats.

Par défaut, ONTAP tools valide les certificats du système de stockage, pour la même raison qu'il valide les certificats du serveur vCenter : l'extension SAN indique à quel cluster ou à quelle LIF de gestion de SVM le certificat appartient. Le certificat auto-signé ONTAP par défaut ne comporte généralement pas d'extension SAN, ce qui entraîne l'échec de la validation lors de l'ajout du système de stockage.

Pour résoudre un échec de validation :

Si le certificat d’un back-end de stockage expire avant que vous ne le renouveliez, ONTAP tools marque le back-end de stockage comme inconnu, car il ne peut plus se connecter au système de stockage. Consultez "Ajouter un système de stockage dorsal aux ONTAP tools" et "Modifier l'indicateur de validation du certificat" pour connaître la procédure.

Les outils ONTAP prennent en charge les types de magasins de données et les protocoles suivants :

Consultez "Créer un datastore dans ONTAP tools" pour connaître les étapes de création.

ONTAP tools utilise par conception un modèle igroup imbriqué :

Si vous avez déjà des igroups plats mappés à des datastores que ONTAP tools détecte, ONTAP tools les convertit lors de la découverte : il conserve l’igroup d’origine comme igroup enfant renommé avec le otv_ préfixe, et crée un igroup parent au-dessus, sans modifier les mappages d’initiateurs sous-jacents. Les igroups qui ne sont pas mappés à un datastore, tels que les igroups de LUN de démarrage, restent inchangés.

Comme ONTAP tools s'appuie sur cette structure parent-enfant pour suivre l'accès des hôtes, ne renommez pas, ne modifiez pas et ne supprimez pas manuellement les igroups gérés par ONTAP tools. Utilisez plutôt les flux de travail de montage, de démontage et de mise à jour des hôtes de ONTAP tools. Consultez "Gestion des igroups imbriqués dans les outils ONTAP" et "Comment les ONTAP tools gèrent les igroups et les politiques d'exportation" pour plus de détails.

Les backends de stockage diffèrent par leur portée et leurs identifiants :

Voir "Ajouter un système de stockage dorsal aux ONTAP tools" et "Associer un système de stockage principal à une instance de serveur vCenter dans ONTAP tools" pour les étapes.

Les flux de travail des banques de données vVols dépendent de l’activation et de l’enregistrement du service VASA Provider auprès du serveur vCenter sélectionné. ONTAP tools utilise VASA Provider pour créer et gérer la représentation de la banque de données vVols, et les stratégies de stockage des VM utilisent les règles du fournisseur de type de stockage NetApp vVols. Dans une configuration HA, le flux de travail HA requiert également VASA Provider pour les banques de données vVols. Consultez "Activer les services optionnels dans ONTAP tools Manager" et "Enregistrez le fournisseur VASA auprès d'une instance de serveur vCenter dans ONTAP tools" pour connaître la procédure d’installation.

Broadcom a déprécié vVols à partir de VMware Cloud Foundation et de VMware vSphere Foundation 9.0 et prévoit d'abandonner cette fonctionnalité dans une prochaine version. Pour les nouveaux déploiements, prévoyez des datastores VMFS ou NFS et laissez le fournisseur VASA désactivé, sauf si vous utilisez actuellement vVols. Consultez les notes de version des outils ONTAP pour vérifier la prise en charge de vVols dans chaque version.

Vous pouvez protéger une banque de données VMFS éligible qui utilise le protocole iSCSI ou FC en l'ajoutant à un groupe de protection avec une relation SnapMirror, à l'aide d'une stratégie asynchrone ou AutomatedFailOverDuplex. Lorsqu'un cluster hôte contient des banques de données provenant de plusieurs SVM, utilisez plutôt le flux de travail de protection granulaire des banques de données pour sélectionner et protéger les banques de données au niveau du groupe de protection. Consultez "Protéger un datastore VMFS dans ONTAP tools" et "Protégez les banques de données d'un cluster avec les outils ONTAP" pour connaître la procédure.

Pour la reprise après sinistre basée sur la baie, activez le service SRA dans ONTAP tools et installez l'adaptateur SRA sur l'appliance VMware Live Site Recovery. Utilisez les mêmes planifications personnalisées SnapMirror sur les clusters source et de destination avant d'exécuter les workflows SRA. Dans une nouvelle configuration SRA, exécutez toujours un test de basculement ; si vous l'ignorez, l'opération de reprotection risque d'échouer. Consultez "Configurez SRA dans ONTAP tools pour protéger les banques de données" pour connaître les étapes de configuration.

Le SRA prend en charge les datastores NFSv3 et les datastores VMFS sur iSCSI et FC. La reprise après sinistre n'est pas prise en charge pour les datastores NVMe-oF, et VMware Live Site Recovery ne prend pas en charge la réplication basée sur les baies pour les datastores NFSv4.1 ou FlexGroup. Les groupes de cohérence sont pris en charge uniquement pour iSCSI et FC ; l'ajout de volumes NFS à un groupe de cohérence entraîne l'échec de la découverte des périphériques.

Le flux de travail de protection des clusters hôtes utilise SnapMirror active sync pour les datastores VMFS. ONTAP tools 10.6 prend également en charge la protection granulaire des datastores, ce qui vous permet de sélectionner les datastores VMFS éligibles à l'aide d'iSCSI ou de FC et d'appliquer la protection au niveau du groupe de protection. SRA s'intègre plutôt à VMware Live Site Recovery pour les flux de travail de reprise après sinistre basés sur les baies. Consultez "Critères d'éligibilité à la protection granulaire des datastores dans les outils ONTAP" pour plus de détails sur l'éligibilité.

L'accès est contrôlé dans deux environnements : les autorisations du serveur vCenter régissent l'accès aux objets vSphere, et les rôles ONTAP régissent les opérations de stockage. ONTAP tools vérifie d'abord le rôle vCenter, puis vérifie le rôle ONTAP associé au système back-end de stockage. ONTAP tools ne crée pas de comptes utilisateur dans vCenter ni dans ONTAP. Les administrateurs créent donc les comptes de service requis. Consultez "Découvrez le contrôle d'accès basé sur les rôles (RBAC) dans les outils ONTAP" pour plus d'informations.

Étant donné que ONTAP tools ne crée pas de comptes utilisateur dans vCenter ou ONTAP, un administrateur vSphere doit créer les comptes de service requis et attribuer des rôles dans les deux environnements. Dans vCenter Server, ONTAP tools étend le modèle RBAC avec des objets supplémentaires exposés via le plug-in distant. Dans ONTAP, l'accès est contrôlé par un rôle ONTAP attribué à l'utilisateur que vous fournissez lors de l'authentification d'un back-end de stockage ; ONTAP tools fournit des rôles prédéfinis et des fichiers de rôles JSON que vous pouvez utiliser pour attribuer les privilèges minimaux requis pour les opérations de back-end de stockage. Consultez "Comment le RBAC du serveur vCenter fonctionne avec les ONTAP tools for VMware vSphere" et "Configurer les rôles et privilèges des utilisateurs ONTAP pour les outils ONTAP" pour connaître les étapes de configuration.

À partir de ONTAP tools 10.5, les sauvegardes sont activées par défaut et s'exécutent toutes les 10 minutes. Les fichiers de sauvegarde sont stockés sur le datastore et vous permettent de redéployer et de restaurer l'appliance ONTAP tools elle-même si la machine virtuelle d'origine est perdue ; il ne s'agit pas d'une sauvegarde du cluster ONTAP ni de la configuration de vCenter Server gérée par ONTAP tools. Vous pouvez modifier la fréquence pour la définir entre 10 et 60 minutes. Voir "Modifier les paramètres de sauvegarde des outils ONTAP" et "Récupérer les ONTAP tools for VMware vSphere à partir d'une sauvegarde" pour connaître la procédure.

Vous pouvez le faire, mais ne désactivez pas les sauvegardes, car cela empêche ONTAP tools de maintenir un faible objectif de point de récupération. La désactivation des sauvegardes ne supprime pas les fichiers de sauvegarde existants. Consultez "Modifier les paramètres de sauvegarde des outils ONTAP" pour connaître la procédure.

Vous pouvez générer un bundle de journaux dans ONTAP tools Manager ou à partir du vSphere Client. Un bundle généré dans ONTAP tools Manager inclut les journaux de toutes les instances de vCenter Server gérées ; un bundle généré dans le vSphere Client est limité à l’instance de vCenter Server sélectionnée. Téléchargez l’archive générée et fournissez-la au support technique sur demande. Consultez "Codes d'erreur de déploiement des outils ONTAP" pour connaître la procédure.

Outre un bundle de journaux, vous pouvez activer l'accès de diagnostic à distance (SSH) au diag compte utilisateur depuis la console de maintenance. Une seule session de connexion diag est autorisée à la fois, et l'accès est automatiquement désactivé à minuit le lendemain ou dès que vous vous reconnectez en tant qu'utilisateur diag. Utilisez cet accès pour un dépannage plus approfondi que ce qu'un bundle de journaux fournit, et générez d'abord un bundle de journaux afin que le support technique dispose des journaux de base. Voir "Configurer l'accès de diagnostic à distance pour ONTAP tools" pour connaître la procédure.

La mise à niveau directe est prise en charge à partir des deux versions précédant immédiatement la dernière version (N-2). Si vous êtes plus en retard, effectuez d'abord la mise à niveau vers la plus ancienne version qui prend en charge une mise à niveau directe vers la dernière version, puis effectuez une nouvelle mise à niveau vers la dernière version. Activez la sauvegarde à faible RPO et téléchargez-la avant de commencer, car une mise à niveau ayant échoué ne peut pas toujours être annulée et la récupération dépend alors d'une sauvegarde à faible RPO ou d'une récupération par snapshot. Consultez "Mettez à niveau ONTAP tools for VMware vSphere 10.x vers 10.6" pour connaître les chemins et les étapes de mise à niveau pris en charge.

La migration est prise en charge uniquement à partir de versions spécifiques de ONTAP tools 9.x. Le chemin de migration dépend de l’utilisation ou non de vVols dans votre environnement : les environnements avec vVols migrent VASA Provider et mettent à jour SRA, tandis que les environnements avec uniquement des datastores NFS et VMFS suppriment le déploiement 9.x et déploient 10.x. Les datastores vVols utilisant NVMe/FC deviennent non opérationnels après la migration, car ONTAP tools 10.x prend en charge NVMe-oF uniquement avec les datastores VMFS. Consultez "Migrez des ONTAP tools for VMware vSphere 9.xx vers 10.6" pour connaître les versions sources prises en charge et les étapes.

Oui. ONTAP tools fournit une API REST pour l'automatisation, distincte de l'API REST du cluster ONTAP. L'accès à l'API utilise l'adresse IP de ONTAP tools et le port 8443 ; authentifiez-vous avec les identifiants de ONTAP tools Manager pour obtenir un jeton d'accès, puis envoyez le jeton dans l' x-auth en-tête. Les opérations de longue durée peuvent s'exécuter de manière asynchrone et renvoyer une tâche à surveiller. Consultez "Découvrez l'API REST des ONTAP tools" et "Effectuez votre premier appel API REST avec les ONTAP tools" pour commencer.