Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure VMware Solution effectue une maintenance périodique du cloud privé. Cette maintenance comprend des correctifs de sécurité, des mises à jour mineures et majeures de la pile logicielle VMware. Cette page décrit les étapes de surveillance, de correction et de maintenance de l’hôte qui permettent de préparer le cloud privé à la maintenance.
Maintenance de l’hôte et gestion du cycle de vie
Un avantage des clouds privés Azure VMware Solution est que la maintenance de la plateforme est effectuée pour vous. Microsoft est responsable de la gestion du cycle de vie des logiciels VMware (ESXi vCenter Server et vSAN) et des appliances NSX. Microsoft est également responsable de l’amorçage de la configuration réseau, comme la création de la passerelle de niveau 0 et l’activation du routage Nord-Sud. Vous êtes responsable de la configuration du SDN NSX : segments réseau, règles de pare-feu distribuées, passerelles de niveau 1 et équilibreurs de charge.
Note
Une passerelle T0 est créé et configuré dans le cadre d’un déploiement de cloud privé. Toute modification apportée à ce routeur logique ou aux machines virtuelles des nœuds de périphérie NSX pourrait affecter la connectivité à votre cloud privé et doit donc être évitée.
Microsoft est responsable de l’application des correctifs, des mises à jour ou des mises à niveau vers ESXi, vCenter Server, vSAN et NSX dans votre cloud privé. L’impact des correctifs, des mises à jour et des mises à niveau sur ESXi, vCenter Server et NSX appelle les considérations suivantes :
ESXi : il n’y a aucun impact sur les charges de travail exécutées dans votre cloud privé. L’accès à vCenter Server et à NSX n’est pas bloqué pendant cette période. Pendant cette période, nous vous recommandons de ne prévoir aucune autre activité, comme effectuer un scale-up d’un cloud privé, planifier ou lancer des migrations HCX actives, apporter des modifications à la configuration de HCX, etc., dans votre cloud privé.
vCenter Server : il n’y a aucun impact sur les charges de travail exécutées dans votre cloud privé. Pendant cette période, vCenter Server sera indisponible et vous ne pourrez pas gérer les machines virtuelles (les arrêter, démarrer, créer ou supprimer). Nous vous recommandons de ne pas planifier d’autres activités, comme un scale-up du cloud privé, la création de réseaux, etc., dans votre cloud privé. Si vous utilisez les interfaces utilisateur de VMware Site Recovery Manager ou de vSphere Replication, nous vous recommandons de ne pas effectuer les actions suivantes : configurer vSphere Replication, et configurer ou exécuter des plans de récupération de site pendant la mise à niveau de vCenter Server.
NSX - Microsoft suit le flux de travail de mise à niveau NSX Broadcom standard. Les mises à niveau de NSX Edge sont effectuées en premier, une à la fois, ce qui peut entraîner des pertes de paquets temporaires lorsqu’Edge bascule de manière transparente vers un autre nœud Edge actif pendant la mise à niveau. En règle générale, cela n’affecte pas les applications de bout en bout, car la retransmission au niveau de la couche TCP résout généralement le problème. Pour les hôtes, Azure VMware Solution utilise des mises à niveau du mode maintenance de l’hôte pour éviter tout impact pendant les mises à niveau de l’hôte ; ce processus déplace toutes les machines virtuelles vers d’autres hôtes du cluster et place les hôtes en mode maintenance avant la mise à niveau. Pendant la mise à niveau, l’accès au plan de gestion NSX est bloqué et les modifications de configuration apportées à l’environnement NSX ne peuvent pas être apportées. Nous vous recommandons de ne pas planifier d’autres activités, comme l’augmentation de la capacité de votre cloud privé, etc. Ces activités peuvent empêcher le démarrage de la mise à niveau, ou peuvent avoir un impact négatif sur la mise à niveau et l’environnement.
Vous recevez une notification via Azure Service Health, qui indiquera la chronologie de la mise à jour. Cette notification fournit également des détails sur le composant mis à niveau, son effet sur les charges de travail, l’accès au cloud privé et d’autres services Azure. Vous pouvez replanifier une mise à niveau si nécessaire.
Il existe plusieurs mises à jour de logiciels :
Correctifs : correctifs de sécurité ou correctifs logiciels publiés par VMware
Mises à jour : changement de version mineur d’un composant de la pile VMware
Mises à niveau : changement de version majeur d’un composant de la pile VMware
Note
Microsoft teste les mises à jour de sécurité critiques dès qu’elles sont mises à disposition par VMware.
Les solutions de contournement VMware documentées sont implémentées à la place de l’installation d’un patch correspondant jusqu’au déploiement des prochaines mises à jour planifiées.
Surveillance et correction de l’hôte
Azure VMware Solution surveille en permanence l’intégrité des composants de VMware et des éléments sous-jacents. Quand Azure VMware Solution détecte une défaillance, elle entreprend des actions pour réparer les composants défaillants. Quand Azure VMware Solution détecte une dégradation ou une défaillance sur un nœud Azure VMware Solution, il déclenche le processus de correction des hôtes.
La correction des hôtes implique le remplacement du nœud défaillant par un nouveau nœud sain dans le cluster. Ensuite, lorsque cela est possible, l’hôte défaillant est placé en mode de maintenance VMware vSphere. VMware vSphere déplace les machines virtuelles de l’hôte défaillant vers d’autres serveurs disponibles dans le cluster, permettant ainsi une migration dynamique des charges de travail sans temps d’arrêt. Si l’hôte défaillant ne peut pas être placé en mode de maintenance, l’hôte est supprimé du cluster. Avant la suppression de l’hôte défaillant, les charges de travail du client sont migrées vers un hôte nouvellement ajouté.
Conseil / Astuce
Communication au client : un e-mail est envoyé à l’adresse e-mail du client avant que le remplacement ne soit lancé et à nouveau une fois le remplacement réussi.
Pour recevoir des e-mails liés au remplacement de l'hôte, vous devez être ajouté à l'un des rôles Azure Role-Based Access Control (RBAC) suivants dans l'abonnement : « ServiceAdmin », « CoAdmin », « Propriétaire » ou « Contributeur ».
Azure VMware Solution supervise les conditions suivantes sur l’hôte :
- État des processeurs
- État de la mémoire
- État des connexions et de l’alimentation
- État du ventilateur matériel
- Perte de connectivité réseau
- État de la carte système matérielle
- Des erreurs se sont produites sur un ou plusieurs disques d’un hôte vSAN
- Tension du matériel
- État de la température du matériel
- État de l’alimentation du matériel
- État du stockage
- Échec de connexion
Actions pour garantir que le cloud privé est prêt pour la maintenance
Les actions suivantes sont nécessaires pour garantir que les opérations de maintenance de l’hôte sont effectuées avec succès :
- Utilisation du stockage vSAN : Pour maintenir le contrat de niveau de service (SLA), assurez-vous que l’utilisation de l’espace de stockage de votre cluster vSphere reste inférieure à 75%. Si l’utilisation dépasse 75%, les mises à niveau peuvent prendre plus de temps que prévu ou échouer entièrement. Si votre utilisation du stockage dépasse 75%, envisagez d’ajouter un nœud pour développer le cluster et d’éviter les temps d’arrêt potentiels pendant les mises à niveau.
- Retirez ou mettez à jour tout adaptateur réseau ou switch connecté à la machine virtuelle obsolète ou inaccessible afin qu’ils ne bloquent pas la maintenance vMotion ou Azure. Si cela n’est pas achevé avant le début de la mise à niveau, Microsoft agira en votre nom en déplaçant ces adaptateurs VM vers un groupe/segment de ports isolé créé par Microsoft en état déconnecté afin que la mise à jour puisse se poursuivre. Microsoft envoie également périodiquement des notifications de santé des ressources Azure VMware Solution pour ces machines virtuelles, afin que vous puissiez agir de manière proactive et maintenir l’environnement prêt pour les mises à niveau prévues.
- Règles drS (Distributed Resource Scheduler) : DrS VM-VM règles d’anti-affinité doivent être configurées de manière à disposer d’au moins (N+1) hôtes dans le cluster, où N correspond au nombre de machines virtuelles faisant partie de la règle DRS.
- Violation du paramètre Failures to Tolerate (FTT) : Évitez toute perte de données en modifiant les machines virtuelles configurées avec une stratégie de stockage vSAN définissant le paramètre Failures to Tolerate (FTT) sur 0 afin d’appliquer une stratégie de stockage vSAN conforme au SLA Microsoft (FTT=1 pour un cluster comportant jusqu’à cinq hôtes et FTT=2 pour un cluster comportant six hôtes ou plus). Assurez-vous que les opérations de maintenance de l’hôte peuvent être effectuées en toute transparence.
- Supprimez les montages de machine virtuelle CD-ROM : Les machines virtuelles montées avec le « mode Émuler » CD-ROMs bloquent la maintenance de l'hôte. Vérifiez que CD-ROMs sont montés en « mode directe ».
- Port série/parallèle ou appareil externe : Si vous utilisez un fichier image (ISO, FLP, etc.), vérifiez qu’il est accessible à partir de tous les hôtes ESXi du cluster. Stockez les fichiers sur un magasin de données partagés entre tous les serveurs ESXi qui participent à la vMotion de la machine virtuelle. Pour plus d’informations, consultez l’article Broadcom KB.
- Machines virtuelles orphelines : Pour les machines virtuelles orphelines, elles doivent être réinscrites si elles ne sont pas déjà supprimées ou supprimées de l’inventaire. Pour plus d’informations, consultez l’article Broadcom KB.
- Contrôleur partagé SCSI : Lorsque vous utilisez le partage de bus SCSI, utilisez le type de bus « Physique » pour les machines virtuelles. Les machines virtuelles connectées aux contrôleurs SCSI virtuels sont désactivées. Pour plus d’informations, consultez l’article Broadcom KB.
-
Machines virtuelles et applications tierces : Pour les machines virtuelles tierces et les applications :
- Vérifiez que les solutions tierces déployées sur Azure VMware Solution sont conformes et n’interfèrent pas avec les opérations de maintenance.
- Assurez-vous que la machine virtuelle ne soit pas configurée avec une règle DRS « Doit être exécutée » VM-Host. En outre, vérifiez que ces applications sont compatibles avec les versions à venir de la pile VMware.
- Contactez votre fournisseur de solution et mettez à jour à l’avance si nécessaire pour maintenir la compatibilité après la mise à niveau.
Important
Si des configurations de blocage de maintenance existent sur un hôte Azure VMware Solution, vous recevez des alertes sur votre tableau de bord Resource Health. Pour vous assurer que les hôtes non sains sont remplacés et que les mises à niveau réussissent, ces configurations bloquantes sont atténuées en effectuant les étapes de correction appropriées pour maintenir la disponibilité de votre cloud privé. Dans certains cas, ces étapes de correction incluent la mise hors tension d’une machine virtuelle et sa migration vers un autre hôte, puis son alimentation, ce qui peut interrompre brièvement l’exécution de l’application sur la machine virtuelle.
Codes d’alerte et table de correction
| Code d’erreur | Détails de l’erreur | Action recommandée |
|---|---|---|
| EPC_CDROM_EMULATEMODE | Une erreur se produit lorsque CD-ROM sur la machine virtuelle utilise le mode émuler, dont l’image ISO n’est pas accessible. | Suivez cet article de la base de connaissances pour retirer tout CD-ROM monté sur une VM de charge de travail du client en mode émulé ou pour détacher une image ISO. La recommandation consiste à utiliser le « mode passthrough » pour monter n’importe quel CD-ROM. |
| EPC_DRSOVERRIDERULE | Une erreur se produit lorsqu’une VM avec une dérogation DRS définie sur le mode « Désactivé » est présente. | La machine virtuelle ne doit pas bloquer vMotion lors de la maintenance de l’hôte. Définissez des règles DRS partiellement automatisées pour la machine virtuelle. Reportez-vous à ce document pour en savoir plus sur les stratégies de placement des machines virtuelles. |
| EPC_SCSIDEVICE_SHARINGMODE | Une erreur se produit lorsqu’une machine virtuelle est configurée pour utiliser le contrôleur SCSI avec le partage de bus en mode « virtuel ». | Suivez cet article de la Base de connaissances pour la suppression d’un contrôleur SCSI utilisé dans le partage de bus en mode virtuel et qui est attaché à des machines virtuelles. |
| EPC_DATASTORE_INACCESSIBLE | Une erreur se produit quand un magasin de données externe attaché à Azure VMware Solution cloud privé devient inaccessible. | Suivez cet article pour la suppression d’un magasin de données obsolète attaché au cluster |
| EPC_NWADAPTER_STALE | Une erreur se produit lorsque l’interface réseau connectée de la machine virtuelle utilise un adaptateur réseau qui devient inaccessible. | Suivez cet article de la Base de connaissances pour la suppression des adaptateurs N/W obsolètes attachés aux machines virtuelles. |
| EPC_SERIAL_PORT | Une erreur se produit lorsqu’un port série de machine virtuelle est connecté à un appareil qui n’est pas accessible sur l’hôte de destination. | Si vous utilisez un fichier image (ISO, FLP, et ainsi de suite), assurez-vous qu’il est accessible à partir de tous les serveurs ESXi sur le cluster. Stockez les fichiers sur un magasin de données partagé entre tous les serveurs ESXi qui participent à vMotion de la machine virtuelle. Pour plus d’informations, consultez cet article de la base de connaissances de Broadcom. |
| EPC_HARDWARE_DEVICE | Une erreur se produit lorsqu’un port parallèle de machine virtuelle/périphérique USB est connecté à un appareil ne peut pas être accessible sur l’hôte de destination. | Si vous utilisez un fichier image (ISO, FLP, et ainsi de suite), assurez-vous qu’il est accessible à partir de tous les serveurs ESXi du cluster. Stockez les fichiers sur un magasin de données partagé entre tous les serveurs ESXi qui participent à la vMotion de la machine virtuelle. En savoir plus sur Broadcom et VMotion échoue avec l’erreur de compatibilité. |
| EPC_INVALIDVM / EPC_ORPHANVM | Une erreur se produit lorsqu’une machine virtuelle orpheline ou non valide est présente dans l’inventaire. | Vérifiez que toutes vos machines virtuelles sont accessibles au vCenter. En savoir plus sur Broadcom et les machines virtuelles qui apparaissent comme non valides, orphelines ou inaccessibles. |
| EPC_VMHOSTDRSRULE | Une erreur se produit lorsqu’il existe une machine virtuelle avec une règle d’affinité hôte/anti-affinité DRS. | La machine virtuelle ne doit pas bloquer VMware vMotion lors de la mise en mode maintenance d’un hôte. Définir des règles de préférence pour l’affinité VM-hôte. En savoir plus sur la création d’une stratégie de placement. |
| EPC_FTT_ZERO | Une erreur survient lorsqu’une machine virtuelle a « Failures to Tolerate » défini sur 0 ou « No data redundancy ». | En savoir plus sur Broadcom et comment configurer FTT en tant que 1 ou 2 pour la machine virtuelle. |
| EPC_FTTVIOLATION | Une erreur se produit lorsqu’un cluster n’a pas le nombre minimal d’hôtes dont la stratégie de stockage a besoin. | Ajoutez des hôtes en fonction des besoins de la stratégie de stockage ou modifiez la stratégie FTT de machine virtuelle pour prendre en charge le placement de l’hôte en mode maintenance. En savoir plus sur la stratégie Broadcom et FTT. |
| EPC_VSANSTORAGEUTILIZATION | Une erreur se produit lorsque l’utilisation de vSAN sur le cluster est supérieure à 75%, ce qui peut entraîner une dégradation des performances et rendre le cluster impossible à gérer. | Si l’utilisation de vSAN sur le cluster est supérieure à 75%, vous pouvez ajouter des nœuds pour augmenter la capacité disponible ou réduire l’utilisation des données sur le cluster. Suivez ce document Tutoriel : Mettre à l’échelle des clusters dans un cloud privé pour augmenter la capacité de vSAN. Suivez les instructions pour les solutions de sauvegarde pour les machines virtuelles d’Azure VMware Solution afin d’apprendre à sauvegarder et à supprimer les machines virtuelles qui ne sont pas indispensables. |
| ERECOMMENDATION_CLUSTER_SIZE | Cette recommandation indique qu’un cluster dans le cloud privé a 14 hôtes ou plus. Azure VMware Solution prend en charge un maximum de 16 hôtes dans un cluster. | Créez un cluster pour les nouveaux hôtes qui peuvent être nécessaires. |
| ERECOMMENDATION_PRIVATECLOUD_SIZE | Cette recommandation indique qu’un cloud privé a 90 hôtes ou plus. Azure VMware Solution prend en charge un maximum de 96 hôtes dans un cloud privé. | Envisagez de créer un cloud privé pour tous les nouveaux hôtes et de distribuer les hôtes dans les clouds privés si nécessaire. |
| ERECOMMENDATION_VCENTER_SCALE | Cette recommandation identifie que la machine virtuelle vCenter est approvisionnée avec moins de cœurs d’UC ou moins de mémoire que recommandé pour le nombre actuel de machines virtuelles dans le cloud privé. | Ouvrez une demande de support pour augmenter la mémoire et le processeur vCenter. |
Note
Azure VMware Solution administrateurs de locataires ne doivent pas modifier ni supprimer les alarmes VMware vCenter Server définies précédemment, car le plan de contrôle Azure VMware Solution sur vCenter Server les gère. Ces alarmes sont utilisées par l’analyse de la solution VMware Azure pour déclencher le processus de correction de l’hôte Azure VMware Solution.
Étapes suivantes
Vous avez appris à garantir une maintenance transparente Azure VMware Solution cloud privé. L’étape suivante peut être d’en savoir plus sur les points suivants :