Partager via

Bonnes pratiques de 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 la surveillance, la correction et les meilleures pratiques recommandées pour maintenir le cloud privé prêt pour 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.

Remarque

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 : la charge de travail est affectée. Quand un hôte particulier est en cours de mise à niveau, les machines virtuelles sur cet hôte peuvent perdre leur connectivité pendant une période de 2 secondes à 1 minute, avec tout ou partie des symptômes suivants :

    • Erreurs de test Ping

    • Perte de paquets

    • Messages d’erreur (par exemple, Hôte de destination inaccessible et Réseau inaccessible)

    Pendant cette fenêtre de mise à niveau, tous les accès au plan de gestion NSX sont bloqués. Vous ne pouvez pas changer la configuration de l’environnement NSX pendant cette période. Vos charges de travail continuent de s’exécuter normalement, sous réserve de l’impact de la mise à niveau détaillé précédemment.

    Pendant la mise à niveau, nous vous recommandons de ne pas planifier d’autres activités, comme une mise à l’échelle du cloud privé, dans votre cloud privé. 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

Remarque

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 un processus de correction de l’hôte.

La correction de l’hôte 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éfectueux 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 », « 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

Meilleures pratiques relatives aux opérations de maintenance

Les actions suivantes sont toujours recommandées 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.
  • 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 des tolérances de pannes (FTT) : Pour éviter toute perte de données, modifiez les machines virtuelles configurées avec une stratégie de stockage vSAN pour les échecs à tolérer (FTT) de 0 vers une stratégie de stockage vSAN conforme au contrat SLA Microsoft (FTT=1 pour jusqu’à cinq hôtes dans un cluster et FTT=2 pour six hôtes ou plus dans un cluster) et assurez-vous que les opérations de maintenance de l’hôte puissent s’effectuer 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 qui sont 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 : Dans le cas d’une machine virtuelle orpheline, la machine virtuelle doit être réinscrite si possible (si elle n’a pas été supprimée) ou supprimée 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 seront 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 l’une de ces configurations de blocage de maintenance existe sur un hôte Azure VMware Solution, vous recevez des alertes sur votre tableau de bord Resource Health pour AVS. Pour vous assurer que les hôtes non sains sont remplacés et que les mises à niveau réussissent, ces configurations bloquantes seront 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 Cette erreur est rencontrée 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 supprimer tout CDROM monté sur les machines virtuelles de charge de travail du client en mode émuler ou détacher ISO. Il est recommandé d’utiliser le « mode passthrough » pour monter n’importe quel CD-ROM.
EPC_DRSOVERRIDERULE Cette erreur se produit lorsqu’il existe une machine virtuelle avec remplacement DRS défini sur le mode « Désactivé ». 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 Cette erreur se produit lorsqu’une machine virtuelle est configurée pour utiliser un 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 Cette erreur se produit lorsqu’un magasin de données externe attaché à un cloud privé AVS devient inaccessible. Suivez cet article pour la suppression d’un magasin de données obsolète attaché au cluster
EPC_NWADAPTER_STALE Cette erreur est rencontrée lorsque l’interface réseau connectée sur la machine virtuelle utilise la carte réseau, ce 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 Cette erreur se produit lorsque le port série d’une 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 Cette erreur se produit lorsque le port/périphérique USB parallèle d’une machine virtuelle 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. Pour plus d’informations, consultez cet article de la base de connaissances de Broadcom.
EPC_INVALIDVM / EPC_ORPHANVM Cette 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. Pour plus d’informations, consultez cet article de la Base de connaissances .
EPC_VMHOSTDRSRULE Cette erreur est rencontrée 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éfinissez les « règles prioritaires » pour l'affinité hôte-VM. Pour plus d’informations, consultez ce document .
EPC_FTT_ZERO Cette erreur se produit lorsqu'une machine virtuelle a un « nombre d'échecs à tolérer » égal à 0 ou « Aucune redondance des données ». Suivez cet article de la base de connaissances pour configurer FTT en tant que 1 ou 2 pour la machine virtuelle.
EPC_FTTVIOLATION Cette 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. Reportez-vous à cet article de la base de connaissances pour en savoir plus sur la stratégie FTT.
ERECOMMENDATION_CLUSTER_SIZE Cette recommandation indique qu’un cluster dans le cloud privé a 14 hôtes ou plus. AVS prend en charge un maximum de 16 hôtes dans un cluster. Créez un nouveau cluster pour tout nouvel hôte requis.
ERECOMMENDATION_PRIVATECLOUD_SIZE Cette recommandation indique qu’un cloud privé a 90 hôtes ou plus. AVS 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.

Remarque

Les administrateurs de locataires Azure VMware Solution ne doivent pas modifier ni supprimer les alarmes VMware vCenter Server définies précédemment, car elles sont gérées par le plan de contrôle Azure VMware Solution sur vCenter Server. 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

Maintenant que vous avez couvert les meilleures pratiques de maintenance du cloud privé Azure VMware Solution, vous pouvez en savoir plus sur les points suivants :

  • Last updated on