Notes de mise à jour de VMware vSAN 6.6

|

Mises à jour le : 16 mai 2017

VMware vSAN 6.6 | 18 avril 2017 | Build ISO 5310538

Vérifiez les compléments et les mises à jour de ces notes de mise à jour.

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les rubriques suivantes :

Nouveautés

VMware Virtual SAN 6.6 (vSAN) présente les nouvelles fonctions et améliorations suivantes :

  • Monodiffusion. Dans vSAN 6.6 et versions ultérieures, la multidiffusion n'est pas requise sur les commutateurs physiques qui prennent en charge le cluster vSAN. Si certains hôtes de votre cluster vSAN exécutent des versions antérieures du logiciel, un réseau multidiffusion est toujours requis.

  • Chiffrement. vSAN prend en charge le chiffrement des données au repos de la banque de données vSAN. Lorsque vous activez le chiffrement, vSAN effectue un reformatage successif de chaque groupe de disques du cluster. Le chiffrement vSAN nécessite une connexion approuvée entre vCenter Server et un serveur gestionnaire de clés (KMS). Le serveur KMS doit prendre en charge le protocole KMIP (Key Management Interoperability Protocol) 1.1 standard.

  • Disponibilité de cluster étendu améliorée avec la protection de pannes locale. Vous pouvez fournir une protection de pannes locale pour les objets de machine virtuelle dans un site unique dans un cluster étendu. Vous pouvez définir un Niveau primaire de pannes à tolérer pour le cluster et un Niveau secondaire de pannes à tolérer pour les objets d'un site unique. Lorsqu'un seul site n'est pas disponible, vSAN maintient la disponibilité avec la redondance locale dans le site disponible.
    • Disponibilité de cluster étendu améliorée avec la protection de pannes locale. Vous pouvez fournir une protection de pannes locale pour les objets de machine virtuelle dans un site unique dans un cluster étendu. Définissez un Niveau principal d'échecs à tolérer pour le cluster et un Niveau secondaire d'échecs à tolérer pour les objets dans un site unique. Lorsqu'un seul site n'est pas disponible, vSAN maintient la disponibilité avec la redondance locale dans le site disponible.
    • Modifier l'hôte témoin. Vous pouvez modifier l'hôte témoin pour un cluster étendu. Sur la page Domaines de pannes et cluster étendu, cliquez sur Modifier l'hôte témoin.

  • Aide à la configuration et mises à jour. Vous pouvez utiliser les pages Aide à la configuration et Mises à jour pour vérifier la configuration de votre cluster vSAN et résoudre tous les problèmes.
    • Aide à la configuration vous aide à vérifier la configuration des composants du cluster, résoudre les problèmes et les problèmes. Les contrôles de configuration sont divisés en catégories, semblables à celles de vSAN Health Service. Les contrôles de configuration couvrent la compatibilité matérielle, le réseau et les options de configuration vSAN.
    • Vous pouvez utiliser la page Mises à jour pour mettre à jour le microprogramme et les pilotes du contrôleur de stockage pour répondre à la configuration requise de vSAN.

  • Limitation de la resynchronisation. Vous pouvez limiter les IOPS utilisées pour la resynchronisation du cluster. Utilisez ce contrôle si les latences augmentent dans le cluster en raison de la resynchronisation ou si le trafic de resynchronisation est trop élevé sur un hôte.

  • Améliorations de Health Service. De nouveaux contrôles de santé améliorés vérifient le chiffrement, l'appartenance au cluster, l'écart temporel, le microprogramme du contrôleur, les groupes de disques, les disques physiques et l'équilibre des disques. Les contrôles de santé en ligne peuvent surveiller la santé du cluster vSAN et envoyer les données au système principal d'analyse de VMware pour une analyse avancée. Pour utiliser les contrôles de santé en ligne, vous devez participer au Programme d'amélioration du produit.

  • Mise à jour Surveillance de vSAN basée sur l'hôte. Vous pouvez surveiller la santé de vSAN et la configuration de base par le biais du client de l'hôte ESXi. Dans le navigateur du client hôte, cliquez sur Stockage. Sélectionnez la banque de données vSAN, puis cliquez sur Surveiller. Cliquez sur les onglets pour afficher les informations vSAN de l'hôte. Dans l'onglet vSAN, vous pouvez cliquer sur Modifier les paramètres pour corriger les problèmes de configuration au niveau de l'hôte.

  • Améliorations du service de performance. Le service de performance vSAN inclut des statistiques relatives à la mise en réseau, à la resynchronisation et à iSCSI. Vous pouvez sélectionner des intervalles de temps enregistrés dans les vues de performances. vSAN enregistre chaque intervalle de temps sélectionné lorsque vous exécutez une requête de performances.

  • Intégration de vSAN à vCenter Server Appliance. Vous pouvez créer un cluster vSAN lorsque vous déployez vCenter Server Appliance et hébergez le dispositif sur ce cluster. Le programme d'installation de vCenter Server Appliance vous permet de créer un cluster vSAN à un seul hôte, avec des disques réclamés à partir de l'hôte. vCenter Server Appliance est déployé sur le cluster vSAN.

  • Améliorations du mode de maintenance. La boîte de dialogue Confirmer le mode maintenance fournit des informations pour guider vos activités de maintenance. Vous pouvez afficher l'incidence de chaque option d'évacuation de données. Par exemple, vous pouvez vérifier s'il reste suffisamment d'espace libre disponible pour terminer l'option sélectionnée.

  • Améliorations du rééquilibrage et de la réparation. Les opérations de rééquilibrage de disque sont plus efficaces. L'opération de rééquilibrage manuel fournit de meilleurs rapports de progression.
    • Le protocole de rééquilibrage a été affiné pour être plus efficace et obtenir un meilleur équilibrage du cluster. Le rééquilibrage manuel fournit davantage de mises à jour et de meilleurs rapports de progression.
    • Des opérations de réparation plus efficaces nécessitent moins de resynchronisations du cluster. vSAN peut réparer partiellement des composants dégradés ou absents afin d'augmenter les Échecs à tolérer même si vSAN n'est pas en mesure de rendre l'objet conforme.

  • Prise en charge des erreurs de disque. Si un disque fait l'objet de latences élevées ou d'un encombrement important, vSAN considère le périphérique comme un disque mourant et évacue les données du disque. vSAN prend en charge le disque mourant en évacuant ou en reconstruisant les données. Aucune action de l'utilisateur n'est nécessaire, sauf si le cluster manque de ressources ou possède des objets inaccessibles. Lorsque vSAN termine l'évacuation des données, l'état de santé est répertorié comme DyingDiskEmpty. vSAN ne démonte pas le périphérique en panne.

  • Nouvelles commandes esxcli.
    • Afficher la santé du cluster vSAN : esxcli vsan health
    • Afficher les informations de débogage de vSAN : esxcli vsan debug

Communauté VMware vSAN

Utilisez le site Web Communauté vSAN pour fournir des commentaires et demander une assistance si vous rencontrez des problèmes lors de l'utilisation de vSAN.

Mises à niveau pour cette version

Pour obtenir des instructions sur la mise à niveau de vSAN, consultez la documentation de VMware Virtual SAN 6.6.

vSAN 6.6 est une nouvelle version majeure qui nécessite une mise à niveau complète. Effectuez les tâches suivantes pour terminer la mise à niveau vers vSAN 6.6 :

  1. Mettre à niveau vCenter Server vers vSphere 6.5.0d. Pour plus d'informations, consultez les Notes de mise à jour de VMware vCenter Server 6.5.0d.
  2. Mettre à niveau les hôtes ESXi vers vSphere 6.5.0d. Pour plus d'informations, consultez les Notes de mise à jour de VMware ESXi 6.5.0d.
  3. Mettre à niveau le format sur disque vSAN vers la version 5.0.

Remarque : la mise à niveau directe de vSphere 6.0 Update 3 vers vSphere 6.5.0d et vSAN 6.6 n'est pas prise en charge.

Mise à niveau du format sur disque pour les hôtes disposant d'une capacité limitée

Lors d'une mise à niveau du format vSAN sur disque, une évacuation des groupes de disques est effectuée. Le groupe de disques est supprimé et mis à niveau vers la version 5.0 du format sur disque, puis le groupe de disques est de nouveau ajouté au cluster. Pour les clusters comprenant deux ou trois nœuds, ou les clusters ne disposant pas d'une capacité suffisante pour évacuer chaque groupe de disques, vous devez utiliser la commande RVC suivante pour mettre à niveau le format sur disque : vsan.ondisk_upgrade --allow-reduced-redundancy

Lorsque vous autorisez une redondance réduite, vos machines virtuelles ne sont pas protégées pendant la durée de la mise à niveau, car cette méthode ne supprime pas les données vers les autres hôtes du cluster. Elle supprime chaque groupe de disques, met à niveau le format sur disque, puis ajoute de nouveau le groupe de disques au cluster. Tous les objets restent disponibles, mais avec une redondance réduite.

Si vous activez la déduplication et la compression pendant la mise à niveau vers vSAN 6.6, vous pouvez sélectionner Autoriser la redondance réduite dans vSphere Web Client.

Utilisation de VMware Update Manager avec des clusters étendus

L'utilisation de VMware Update Manager pour mettre à niveau des hôtes en parallèle peut entraîner la mise à niveau de l'hôte témoin en parallèle avec l'un des hôtes de données d'un cluster étendu. Pour éviter tout problème de mise à niveau, ne configurez pas VMware Update Manager pour mettre à niveau un hôte témoin en parallèle avec les hôtes de données d'un cluster étendu. Mettez à niveau l'hôte témoin une fois que tous les hôtes de données ont été mis à niveau correctement et ont quitté le mode de maintenance.

Vérification des échecs du contrôle de santé pendant la mise à niveau

Pendant les mises à niveau du format sur disque de vSAN, le contrôle de la santé du disque physique et des métadonnées peut échouer par intermittence. Ces échecs peuvent se produire si le processus d'aliénation de transfert est lent, probablement parce que vSAN doit allouer des blocs physiques sur les périphériques de stockage. Avant de prendre une action, vérifiez l'état de ce contrôle de santé une fois que la période d'activité élevée, le déploiement de plusieurs machines virtuelles par exemple, est terminée. Si le contrôle de santé est toujours rouge, l'avertissement est valide. Si le contrôle de santé est vert, vous pouvez ignorer l'avertissement précédent. Pour plus d'informations, consultez l'article 2108690 de la base de connaissances.

Limitations

Pour plus d'informations sur les autres limites de configuration maximale de la version 6.6 de vSAN, consultez la documentation Configurations maximales.

Problèmes connus

    Les problèmes connus suivants surviennent dans vSAN 6.6 :

  • Le contrôle de santé de la cohérence du cluster échoue pendant l'opération de renouvellement de clés en profondeur
    L'opération de renouvellement de clés en profondeur sur un cluster vSAN peut prendre plusieurs heures. Pendant le renouvellement de clés, le contrôle de santé suivant peut indiquer un échec : Cohérence de la configuration du cluster. Le contrôle de cohérence du cluster ne détecte pas l'opération de renouvellement de clés en profondeur et il peut ne pas y avoir de problème.

    Solution : réinitialisez le contrôle de santé de la cohérence du cluster vSAN une fois que l'opération de renouvellement de clés en profondeur est terminée.

  • Le déploiement OVF de machine virtuelle échoue si DRS est désactivé
    Si vous déployez un modèle OVF sur le cluster vSAN, l'opération échoue si DRS est désactivé sur le cluster vSAN. Vous pouvez voir un message semblable au message suivant : L'opération n'est pas autorisée dans l'état actuel.

    Solution : activez DRS sur le cluster vSAN avant de déployer un modèle OVF.

  • Perte de la configuration de cluster étendu vSAN lorsque vous désactivez vSAN sur un cluster
    Si vous désactivez vSAN sur un cluster étendu, la configuration de celui-ci n'est pas conservée. La configuration du cluster étendu, de l'hôte témoin et du domaine de pannes est perdue.

    Solution : reconfigurez les paramètres de cluster étendu lorsque vous réactivez le cluster vSAN.

  • Machines virtuelles inactives ou inaccessibles après une panne de cluster totale
    Après une panne de cluster totale, certaines machines virtuelles hors tension ou suspendues peuvent devenir orphelines ou inaccessibles, en particulier lorsque le chiffrement vSAN est activé.

    Solution : utilisez la procédure suivante pour réenregistrer les machines virtuelles inactives ou inaccessibles.

    1. Utilisez RVC pour vous connecter à vCenter Server.
    2. Accédez au nom du cluster dans lequel il existe des machines virtuelles orphelines et réenregistrez-les. Par exemple, si le nom du cluster est « vsan », exécutez la commande suivante : vsan.check_state -ref /localhost/Datacenter/computers/vsan

      Exemple de sortie :

      vsan.check_state -ref /localhost/Datacenter/computers/vsan
      2017-03-03 18:54:04 +0000: Step 1: Check for inaccessible vSAN objects
      2017-03-03 18:54:10 +0000: Step 1b: Check for inaccessible vSAN objects, again
      2017-03-03 18:54:11 +0000: Step 2: Check for invalid/inaccessible VMs
      2017-03-03 18:54:11 +0000: Step 2b: Check for invalid/inaccessible VMs again
      2017-03-03 18:54:11 +0000: Step 3: Check for VMs for which VC/hostd/vmx are out of sync Did not find VMs for which VC/hostd/vmx are out of sync

  • La version du format sur disque de l'hôte témoin est postérieure à la version des hôtes de données
    Lorsque vous modifiez l'hôte témoin pendant une mise à niveau vers vSAN 6.6, le nouvel hôte témoin reçoit la dernière version du format sur disque. La version du format sur disque de l'hôte témoin peut être postérieure à la version du format sur disque des hôtes de données. Dans ce cas, l'hôte témoin ne peut pas stocker les composants.

    Solution : utilisez la procédure suivante pour modifier le format sur disque vers une version antérieure.

    1. Supprimez le groupe de disques sur le nouvel hôte témoin.
    2. Définissez les paramètres avancés pour activer le formatage des groupes de disques avec un format de disque antérieur. Pour plus d'informations, consultez l'article 2146221 de la base de connaissances.
    3. Recréez un groupe de disques sur l'hôte témoin avec une version de format sur disque vSAN qui correspond aux hôtes de données.

  • Les machines virtuelles hors tension s'affichent comme étant inaccessibles pendant le remplacement d'un hôte témoin
    Lorsque vous modifiez un hôte témoin dans un cluster étendu, les machines virtuelles qui sont hors tension s'affichent comme étant inaccessibles dans vSphere Web Client pendant un court laps de temps. Lorsque le processus est terminé, les machines virtuelles hors tension s'affichent comme étant inaccessibles. Toutes les machines virtuelles en cours d'exécution s'affichent comme étant accessibles tout au long du processus.

    Solution : aucune.

  • Impossible de placer les hôtes en mode de maintenance s'ils possèdent un support de démarrage défectueux
    vSAN ne peut pas placer en mode de maintenance des hôtes avec un support de démarrage défectueux. La tâche pour passer en mode de maintenance peut échouer avec une erreur vSAN interne en raison de l'impossibilité d'enregistrer les modifications de configuration. Vous pouvez voir des événements du journal semblables à celui-ci : Perte de connectivité avec le périphérique xxx sauvegardant le système de fichiers de démarrage.

    Solution : supprimez manuellement les groupes de disques de chaque hôte, en utilisant l'Option d'évacuation intégrale des données. Placez ensuite l'hôte en mode de maintenance.

  • Le contrôle de santé expire en cas d'échec d'un hôte
    En cas d'échec d'un hôte dans le cluster, le contrôle de santé peut expirer. Vous pouvez voir le message suivant : une tâche principale a nécessité plus de 120 secondes. Lorsque vSAN Health Service détecte un échec de l'hôte, il redémarre. Le contrôle de santé reprend automatiquement au bout de dix minutes.

    Solution : aucune.

  • Health Service ne fonctionne pas si le cluster vSAN comporte des hôtes ESXi exécutant vSphere 6.0 Update 1 ou version antérieure
    Health Service de vSAN 6.6 ne fonctionne pas si le cluster comporte des hôtes ESXi qui exécutent vSphere 6.0 Update 1 ou version antérieure.

    Solution : n'ajoutez pas d'hôtes ESXi à vSphere 6.0 Update 1 ou un logiciel antérieur à un cluster vSAN 6.6.

  • Après le basculement du cluster étendu, les machines virtuelles du site préféré enregistrent une alerte : Échec du basculement
    En cas d'échec du site secondaire dans un cluster étendu, les machines virtuelles basculent vers le site préféré. Les machines virtuelles qui se trouvent déjà sur le site préféré peuvent enregistrer l'alerte suivante : Échec du basculement. Ignorez cette alerte. Cela n'a aucune incidence sur le comportement du basculement.

    Solution : aucune.

  • Pendant la partition du réseau, les composants du site actif semblent être absents
    Pendant une partition du réseau dans un cluster vSAN à 2 hôtes ou étendu, vSphere Web Client peut afficher une vue du cluster sous l'angle du site non actif. Vous pouvez voir des composants actifs du site principal affichés comme étant absents.

    Solution : utilisez les commandes RVC pour interroger l'état des objets du cluster. Par exemple : vsan.vm_object_info

  • Le programme d'installation de vCenter Server Appliance accepte un nom de cluster d'une longueur supérieure à 80 caractères
    Si vous entrez un nom de cluster vSAN d'une longueur supérieure à 80 caractères, vCenter Server Appliance accepte le nom, mais la configuration n'est pas valide. vCenter Server Appliance échoue lors de son démarrage.

    Solution : entrez un nom de cluster vSAN d'une longueur inférieure ou égale à 80 caractères

  • Le programme d'installation de vCenter Server Appliance accepte une combinaison de lecteurs Flash et magnétiques pour la capacité
    Le programme d'installation de vCenter Server Appliance vous permet de sélectionner une combinaison de lecteurs Flash et magnétiques pour le niveau de la capacité d'un groupe de disques dans un nouveau cluster vSAN. Le niveau de la capacité de chaque groupe de disques peut prendre en charge soit tous les lecteurs Flash, soit tous les lecteurs magnétiques.

    Solution : ne combinez pas des lecteurs Flash et des lecteurs magnétiques sur le niveau de la capacité du cluster vSAN.

  • Tâches de configuration de mise à jour temporaires visibles si les hôtes sont déconnectés lorsque vous modifiez les configurations de chiffrement vSAN
    Lorsque vous modifiez les configurations dans un cluster vSAN chiffré (par exemple en activant ou en désactivant le chiffrement, ou en modifiant la clé KMS), une tâche de configuration de mise à jour de vSAN s'exécute sur chaque hôte toutes les 3 secondes jusqu'à ce que tous les hôtes se reconnectent ou que 5 minutes se soient écoulées. Ces tâches ne sont pas dangereuses et n'ont que rarement une incidence sur les performances.

    Solution : aucune.

  • Certains objets ne sont pas conformes après une réparation forcée
    Après l'exécution d'une réparation forcée, certains objets peuvent ne pas être réparés, car la propriété des objets a été transférée vers un mode différent pendant le processus. La réparation forcée peut être retardée pour ces objets.

    Solution : essayez l'opération de réparation forcée une fois que tous les autres objets sont réparés et resynchronisés. Vous pouvez attendre que vSAN répare les objets.

  • Lorsque vous déplacez un hôte d'un cluster chiffré vers un autre, puis que vous le replacez dans le cluster d'origine, la tâche échoue
    Lorsque vous déplacez un hôte d'un cluster vSAN chiffré vers un autre cluster vSAN chiffré, puis que vous replacez l'hôte dans le cluster d'origine chiffré, la tâche peut échouer. Vous pouvez voir le message suivant : Une erreur système générale s'est produite : Erreur non valide. Cette erreur se produit, car vSAN ne peut pas rechiffrer les données sur l'hôte à l'aide de la clé de chiffrement d'origine. Au bout d'un court laps de temps, vCenter Server restaure la clé d'origine sur l'hôte, et tous les disques démontés dans le cluster vSAN sont montés.

    Solution : redémarrez l'hôte et attendez que tous les disques soient montés.

  • Le cluster est partitionné si vCenter Server et les hôtes ESXi redémarrent
    Si vCenter Server et les hôtes ESXi d'un cluster vSAN sont redémarrés, le cluster est partitionné.

    Solution : redémarrez vSAN Health Service

  • Déséquilibre du cluster étendu après une récupération de site
    Lorsque vous récupérez un site en échec dans un cluster étendu, il arrive que des hôtes du site en échec soient remis en ligne de manière séquentielle sur une longue période. vSAN peut utiliser certains hôtes de manière excessive lorsqu'il commence à réparer les composants absents.

    Solution : récupérez tous les hôtes d'un site en échec simultanément dans une fenêtre temporelle réduite.

  • Les opérations de machines virtuelles échouent en raison d'un problème de HA maître avec les clusters étendus
    Selon certains scénarios de panne dans les clusters étendus, certaines opérations de machines virtuelles, telles que des activités vMotion ou de mise sous tension d'une machine virtuelle peuvent être affectées. Ces scénarios de panne incluent une panne partielle ou totale d'un site, ou une panne du réseau haute vitesse entre les sites. Ce problème est dû à la dépendance de la disponibilité de VMware HA pour les opérations normales des sites comportant des clusters étendus.

    Solution : désactivez vSphere HA avant d'exécuter vMotion, la création de machines virtuelles ou la mise sous tension de machines virtuelles. Réactivez ensuite vSphere HA.

  • Mise à jour La restauration ou le remplacement de l'instance de vCenter Server peuvent entraîner un partitionnement du cluster
    Si vCenter Server est remplacé ou récupéré à partir d'une sauvegarde, la liste d'appartenance à l'hôte peut devenir obsolète. Cela peut provoquer la partition des hôtes ESXi du cluster.

    Solution : utilisez la procédure suivante pour vous assurer que tous les hôtes sont ajoutés au cluster vSAN lorsque vCenter Server redémarre.

    1. Avant de redémarrer vCenter Server, configurez les hôtes afin qu'ils ignorent les mises à jour de la liste des membres du cluster. Exécutez la commande suivante sur chaque hôte dans le cluster vSAN :
      esxcfg-advcfg -s1 /VSAN/IgnoreClusterMemberListUpdates
    2. Une fois que vCenter Server s'exécute et que tous les hôtes sont présents dans le cluster, configurez les hôtes pour qu'ils utilisent les mises à jour de la liste des membres du cluster. Exécutez la commande suivante sur chaque hôte dans le cluster :
      esxcfg-advcfg -s0 /VSAN/IgnoreClusterMemberListUpdates
  • La tâche de désaffectation de disques ou de démontage de disques échoue
    La tâche de désaffectation de disques ou de démontage de disques peut échouer en raison d'un conflit entre la tâche de validation de l'écriture des données et la tâche de suppression de disques virtuels. Ce problème peut se produire pendant les mises à niveau qui nécessitent un nouveau format sur disque vSAN. Vous pouvez voir le message suivant dans le fichier VMkernel.log :

    4724 2017-04-10T18:46:51.309Z cpu30:67232)LSOM: LSOMFreeMDDispatch:3797: Throttled: Waiting for component cleanup

    Solution : redémarrez l'hôte pour effacer le conflit et retentez l'opération.

  • Le test de connectivité réseau de vMotion signale de manière incorrecte des échecs de test ping
    Le test de connectivité réseau de vMotion (Cluster > Surveiller > vSAN > Santé > Réseau) signale des échecs de test ping si la pile vMotion est utilisée pour vMotion. La vérification de connectivité réseau de vMotion (ping) ne prend en charge que les vmknics qui utilisent la pile réseau par défaut. Le contrôle échoue pour les vmknics qui utilisent la pile réseau vMotion. Ces rapports n'indiquent pas de problème de connectivité.

    Solution : configurez le vmknic pour qu'il utilise la pile réseau par défaut. Vous pouvez désactiver le contrôle de test ping vMotion à l'aide des commandes RVC. Par exemple : vsan.health.silent_health_check_configure -a vmotionpingsmall

  • Impossible d'effectuer un renouvellement de clés en profondeur si un groupe de disques est démonté
    Avant d'effectuer un renouvellement de clés en profondeur, vSAN effectue un renouvellement de clés superficiel. Le renouvellement de clés superficiel échoue en présence d'un groupe de disques démonté. Le processus de renouvellement de clés en profondeur ne peut pas commencer.

    Solution : remontez le groupe de disques démonté ou supprimez-le.

  • Les entrées de journal qui indiquent la configuration du pare-feu ont changé
    Une nouvelle entrée de pare-feu s'affiche dans le profil de sécurité lorsque le chiffrement vSAN est activé : vsanEncryption. Cette règle contrôle la manière dont les hôtes communiquent directement avec le KMS. Lorsqu'elle est déclenchée, les entrées de journal sont ajoutées à /var/log/vobd.log. Vous pouvez voir les messages suivants :

    La configuration du pare-feu a changé. L'opération 'addIP4' du groupe de règles vsanEncryption a réussi.
    La configuration du pare-feu a changé. L'opération 'removeIP4' du groupe de règles vsanEncryption a réussi.

    Vous pouvez ignorer ces messages.

    Solution : aucune.

  • Mise à jour Prise en charge limitée pour les disques de première classe avec les banques de données vSAN
    vSAN 6.6 ne prend pas complètement en charge les disques de première classe dans les banques de données vSAN. Si vous utilisez des disques de première classe dans une banque de données vSAN, vous pouvez rencontrer les problèmes suivants :

    • vSAN Health Service n'affiche pas correctement la santé des disques de première classe.
    • La répartition des capacités utilisées inclut la capacité utilisée pour les disques de première classe dans la catégorie suivante : Autre
    • L'état de santé des machines virtuelles qui utilisent des disques de première classe n'est pas calculé correctement.

    Solution : aucune.

  • Le basculement HA ne se produit pas après la définition de l'option Type de trafic sur un vmknic pour prendre en charge le trafic témoin
    Si vous définissez l'option de type de trafic sur un vmknic pour prendre en charge le trafic témoin, vSphere HA ne détecte pas automatiquement le nouveau paramètre. Vous devez désactiver HA manuellement, puis le réactiver pour qu'il puisse détecter le vmknic. Si vous configurez d'abord la vmknic et le cluster vSAN, puis activez HA sur le cluster, ce dernier détecte la vmknic.

    Solution : désactivez manuellement vSphere HA sur le cluster, puis réactivez-le.

  • Après la désactivation et la suppression du service cible iSCSI, certains objets iSCSI sont conservés dans la banque de données vSAN
    Si vous utilisez Web Client pour supprimer tous les LUN et toutes les cibles iSCSI, et désactivez le service cible iSCSI, l'objet de base iSCSI existe toujours dans la banque de données vSAN.

    Solution : pour supprimer l'objet de base iSCSI et toutes les métadonnées associées au service cible iSCSI, exécutez la commande suivante sur un hôte du cluster : esxcli vsan iscsi homeobject delete

  • Les opérations d'E/S iSCSI peuvent être interrompues lors du basculement d'une cible iSCSI
    Lors du basculement d'une cible iSCSI, les opérations d'E/S iSCSI peuvent être interrompues. Un échec ou un redémarrage de l'hôte peut déclencher un basculement de la cible iSCSI.

    Solution : redémarrez la session à partir de l'initiateur iSCSI.

  • La fonctionnalité MCS d'iSCSI n'est pas prise en charge
    Le service cible iSCSI vSAN ne prend pas en charge la fonctionnalité MCS (plusieurs connexions par session).

    Solution : aucune.

  • Tous les initiateurs iSCSI peuvent détecter les cibles iSCSI
    Le service cible iSCSI vSAN permet à tous les initiateurs du réseau de détecter les cibles iSCSI.

    Solution : vous pouvez isoler les hôtes ESXi des initiateurs iSCSI en les plaçant sur des VLAN distincts.

  • Après la résolution de la partition du réseau, un échec des opérations de machine virtuelle sur les machines virtuelles du clone lié peut se produire
    Certaines opérations de machine virtuelle sur les machines virtuelles du clone lié qui ne produisent aucune E/S dans le système d'exploitation invité peuvent échouer. Ces opérations peuvent inclure la prise de snapshots et l'interruption des machines virtuelles. Ce problème peut survenir après la résolution de la partition du réseau, lorsque l'espace de noms de la machine virtuelle parente de base n'est pas encore accessible. Lorsque l'espace de noms de la machine virtuelle parent est accessible, HA ne reçoit aucun message indiquant de mettre la machine virtuelle sous tension.

    Solution : effectuez un cycle d'alimentation pour les machines virtuelles qui n'exécutent pas activement les opérations d'E/S.

  • Lors de la déconnexion de Web Client après l'utilisation de l'assistant Configurer vSAN, certaines tâches de configuration peuvent échouer
    L'assistant Configurer vSAN peut prendre plusieurs heures pour effectuer les tâches de configuration. Vous devez rester connecté au client Web jusqu'à la fin de l'assistant de configuration. Ce problème survient généralement dans les clusters comprenant de nombreux hôtes et groupes de disques.

    Solution : si certaines tâches de configuration échouent, effectuez la configuration à nouveau.

  • Nouvelles règles de stratégies ignorées sur des hôtes ayant des versions plus anciennes du logiciel ESXi
    Cela peut se produire lorsque vous utilisez au moins deux clusters vSAN, dont l'un exécute la dernière version du logiciel et l'autre une version plus ancienne. vSphere Web Client affiche les règles de stratégies pour le dernier logiciel vSAN, mais ces nouvelles stratégies ne sont pas prises en charge sur les hôtes plus anciens. Par exemple, RAID-5/6 (codage d'effacement) – Capacité n'est pas pris en charge sur les hôtes qui exécutent la version 6.0U1 ou une version antérieure du logiciel. Vous pouvez configurer les nouvelles règles de stratégie, puis les appliquer à toutes les machines virtuelles et à tous les objets, mais elles sont ignorées sur les hôtes qui exécutent des versions plus anciennes du logiciel.

    Solution : aucune.

  • Les objets mémoire de snapshot ne s'affichent pas dans la répartition des capacités utilisées du moniteur de capacité de vSAN
    Pour les machines virtuelles créées avec une version matérielle antérieure à la version 10, la mémoire de snapshot est incluse dans les objets Vmem dans la ventilation de la capacité utilisée.

    Solution : pour afficher les objets mémoire de snapshot dans la ventilation de la capacité utilisée, créez des machines virtuelles avec une version matérielle 10 ou supérieure.

  • L'utilisation du stockage signalé dans la page Résumé VM peut apparaître plus importante après la mise à niveau vers vSAN 6.5 ou version ultérieure
    Dans les versions précédentes de vSAN, la valeur signalée pour l'utilisation du stockage de machine virtuelle correspondait à l'espace utilisé par une seule copie des données. Par exemple, si l'invité écrivait 1 Go sur un objet alloué dynamiquement avec deux miroirs, l'utilisation du stockage indiquait 1 Go. Dans vSAN 6.5 et versions ultérieures, le champ Utilisation du stockage affiche l'espace réel utilisé, en incluant toutes les copies des données. Ainsi, si l'invité écrit 1 Go sur un objet alloué dynamiquement avec deux miroirs, l'utilisation du stockage indique 2 Go. L'utilisation du stockage signalé sur certaines machines virtuelles peut apparaître plus importante après la mise à niveau vers vSAN 6.5, mais l'espace réel consommé n'a pas augmenté.

    Solution : aucune.

  • Impossible de placer un hôte témoin en mode de maintenance
    Lorsque vous tentez de placer un hôte témoin en mode de maintenance, celui-ci demeure dans l'état actuel et vous voyez la notification suivante : Un paramètre spécifié n'était pas correct.

    Solution : lorsque vous placez un hôte témoin en mode de maintenance, choisissez l'option Aucune migration de données.

  • Le déplacement de l'hôte témoin dans un cluster étendu, puis hors de celui-ci, laisse le cluster dans un état mal configuré
    Si vous placez l'hôte témoin dans un cluster vCenter compatible vSAN, une alarme vous informe que l'hôte témoin ne peut pas résider dans le cluster. Cependant, si vous déplacez l'hôte témoin en dehors du cluster, ce dernier reste dans un état mal configuré.

    Solution : déplacez l'hôte témoin en dehors du cluster étendu vSAN, puis reconfigurez le cluster étendu. Pour plus d'informations, consultez l'article 2130587 de la base de connaissances.

  • Lorsqu'une partition réseau a lieu dans un cluster possédant une banque de données de signal de pulsation HA, les machines virtuelles ne sont pas redémarrées sur l'autre site de données
    Lorsque le site préféré ou secondaire d'un cluster vSAN perd sa connexion réseau vers d'autres sites, les machines virtuelles qui s'exécutent sur le site qui perd la connectivité réseau ne sont pas redémarrées vers l'autre site de données et l'erreur suivante peut apparaître : Le basculement HA de la machine virtuelle vSphere HA a échoué.

    Il s'agit du comportement attendu pour les clusters vSAN.

    Solution : ne sélectionnez pas une banque de données de signal de pulsation HA lors de la configuration de vSphere HA sur le cluster.

  • Disques et groupes de disques vSAN démontés affichés comme montés dans le champ État opérationnel de vSphere Web Client
    Après le démontage de disques ou de groupes de disques vSAN soit par l'exécution de la commande esxcli vsan storage diskgroup unmount, soit par le service vSAN Device Monitor lorsque des disques affichent des latences élevées de façon persistante, vSphere Web Client affiche de manière incorrecte le champ État opérationnel comme Monté.

    Solution : utilisez le champ Santé pour vérifier l'état des disques au lieu du champ État opérationnel.

  • La mise à niveau du format sur disque affiche des disques qui ne sont pas sur vSAN
    Lorsque vous effectuez la mise à niveau du format sur disque, vSAN peut afficher de manière incorrecte des disques qui ont été supprimés du cluster. L'interface utilisateur peut également afficher l'état de la version comme étant mixte. Ce problème d'affichage se produit généralement lorsqu'un ou plusieurs disques sont démontés manuellement du cluster. Il n'affecte pas le processus de mise à niveau. Seuls les disques montés sont vérifiés. Les disques démontés sont ignorés.
  • Solution : aucune.

  • Tous les clusters vSAN partagent les mêmes paramètres de proxy externes
    Tous les clusters vSAN partagent les mêmes paramètres de proxy externes, même si vous définissez le proxy au niveau du cluster. vSAN utilise des proxys externes pour se connecter à Support Assistant, au programme d'amélioration du produit et à la base de données HCL, lorsque le cluster n'a pas un accès direct à Internet.

    Solution : aucune.

  • Les machines virtuelles d'un cluster étendu deviennent inaccessibles quand le site préféré est isolé, puis retrouvent une connectivité à l'hôte témoin uniquement
    Quand le site préféré se déconnecte ou perd sa connexion réseau au site secondaire et à l'hôte témoin, le site secondaire forme un cluster avec l'hôte témoin et poursuit les opérations de stockage. Les données sur le site préféré risquent de devenir obsolètes. Si le site préféré se reconnecte alors à l'hôte témoin, mais pas au site secondaire, l'hôte témoin quitte le cluster dans lequel il se trouve et forme un cluster avec le site préféré, ce qui peut rendre certaines machines virtuelles inaccessibles étant donné qu'elles n'ont plus accès aux données les plus récentes dans ce cluster.

    Solution : avant de reconnecter le site préféré au cluster, marquez le site secondaire comme site préféré. Après la resynchronisation des sites, vous pouvez marquer le site de votre choix comme site préféré.

  • Le modèle de consommation de stockage de l'assistant Stratégie de stockage de VM affiche des informations incorrectes
    Si un ou plusieurs hôtes d'un cluster vSAN n'exécutent pas la version 6.0 Update 2 ou une version ultérieure, le modèle de consommation de stockage de l'assistant Stratégie de stockage de VM peut afficher des informations incorrectes lorsque vous sélectionnez RAID 5/6 comme méthode de tolérance de panne.

    Solution : mettez à niveau tous les hôtes vers la dernière version du logiciel.