Maintenance du cloud privé Azure VMware Solution

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 CD-ROM des VM : Les VM ayant un CD-ROM monté en mode « Émulation » empêchent leur migration à chaud depuis les hôtes qui doivent être placés en mode maintenance. 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 comme « Physique » pour les machines virtuelles. Les VM connectées à des contrôleurs de bus SCSI en mode « Virtuel » peuvent être éteintes en mode maintenance car ces VM ne peuvent pas être migrées en direct depuis des hôtes qui doivent être placés en mode maintenance. 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.
    • Veillez à ce que les opérations de secours soient mises en pause pendant la fenêtre 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 Cela se produit lorsque le CD-ROM de la VM utilise le mode émulation et que l’image ISO n’est pas accessible. Pour retirer un CD-ROM monté sur la VM de charge de travail d’un client en mode émulation ou pour détacher un ISO, voir cet article de la base de connaissances. Utilisez le mode Passthrough pour monter un CD-ROM.
EPC_DRSOVERRIDERULE Cela se produit lorsqu’une VM a le paramètre DRS Override défini sur Désactivé. Une VM ne devrait pas bloquer vMotion lors du passage de l’hôte en mode maintenance. Définissez des règles DRS partiellement automatisées pour la VM. Pour en savoir plus sur les politiques de placement des VM, consultez ce document.
EPC_SCSIDEVICE_SHARINGMODE Se produit lorsqu’une VM est configurée pour utiliser un contrôleur SCSI avec partage de bus en mode virtuel . Pour supprimer un contrôleur SCSI engagé en partage de bus en mode virtuel et connecté aux machines virtuelles, consultez cet article de la base de connaissances.
EPC_DATASTORE_INACCESSIBLE Se produit lorsqu’un magasin de données externe attaché à Azure VMware Solution Private Cloud devient inaccessible. Pour supprimer un datastore obsolète attaché à un cluster, voir cet article.
EPC_NWADAPTER_STALE Cela se produit lorsqu’une interface réseau connectée sur la VM utilise un adaptateur réseau qui devient inaccessible. Pour supprimer un adaptateur réseau obsolète qui est connecté aux machines virtuelles, consultez cet article de la base de connaissances.
EPC_DVSWITCH_INACCESSIBLE Cela se produit lorsque l’adaptateur réseau de la VM connecté fait référence à un DVSwitch ou un groupe de ports qui n’est pas accessible. Cette condition peut empêcher l’évacuation des machines virtuelles et bloquer le passage de l’hôte ESXi en mode Maintenance. Retirez tous les adaptateurs connectés à un segment NSX inexistant et connectez un adaptateur réseau accessible.
EPC_SERIAL_PORT Cela se produit lorsqu’un port série de VM est connecté à un périphérique 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 datastore partagé entre tous les serveurs ESXi participant au vMotion de la VM. Pour plus d’informations, consultez cet article de la base de connaissances de Broadcom.
EPC_HARDWARE_DEVICE Cela se produit lorsqu’un port parallèle de VM ou un périphérique USB est connecté à un appareil qui 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 sur le cluster. Stockez les fichiers sur un datastore partagé entre tous les serveurs ESXi participant au vMotion de la VM. Pour en savoir plus sur les erreurs de compatibilité entre Broadcom et vMotion, consultez cet article de la base de connaissances.
EPC_INVALIDVM / EPC_ORPHANVM / EPC_INACCESSIBLEVM Elle se produit lorsqu’une VM orpheline ou invalide est présente dans l’inventaire. Vérifiez que toutes vos machines virtuelles sont accessibles au vCenter. Pour en savoir plus sur Broadcom et les VM qui apparaissent comme invalides, orphelines ou inaccessibles, consultez cet article.
EPC_VMHOSTDRSRULE Se produit lorsqu’une VM possède une règle DRS d’affinité hôte ou d’anti-affinité. Une VM ne devrait pas bloquer VMware vMotion lors du passage d’un hôte en mode maintenance. Définir des règles de préférence pour l’affinité VM-hôte. Pour en savoir plus, consultez créer une stratégie de placement.
EPC_FTT_ZERO Cela se produit lorsqu’une VM a « Failures to Tolerate » réglé sur 0 ou « No data redundancy ». Pour en savoir plus sur Broadcom et comment configurer FTT sur 1 ou 2 pour la VM, consultez cet article.
EPC_FTTVIOLATION Cela se produit lorsqu’un cluster ne dispose pas du nombre minimum d’hôtes nécessaire à la politique de stockage. 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. Pour en savoir plus sur Broadcom et la politique FTT, consultez cet article.
EPC_VSANSTORAGEUTILIZATION Cela se produit lorsque l’utilisation de vSAN sur le cluster dépasse 75%, ce qui peut entraîner une dégradation des performances et rendre le cluster inmaintenable. 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. Pour faire évoluer vSAN, voir le tutoriel - Mettre à l’échelle les clusters dans un cloud privé. Pour apprendre à sauvegarder et supprimer des machines virtuelles qui ne sont pas essentielles, voir Solutions de sauvegarde pour les machines virtuelles Azure VMware Solution.
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 :

  • Dernière mise à jour :