Maintenance et mises à jour du cloud privé

Les environnements de cloud privé sont conçus de sorte à n'avoir aucun point de défaillance unique :

  • Les clusters ESXi sont configurés avec la haute disponibilité vSphere (HA). Les clusters sont dimensionnés de manière à disposer d'au moins un nœud de secours pour la résilience.
  • vSAN fournit un espace de stockage principal redondant, qui requiert au moins trois nœuds pour assurer une protection contre une seule défaillance. Pour les clusters plus importants, vous pouvez configurer vSAN afin d'augmenter la résilience.
  • Les machines virtuelles vCenter, PSC et NSX Manager sont configurées avec un stockage RAID-10 afin d'éviter toute défaillance de stockage. Les VM sont également protégées contre les défaillances de nœud et de réseau par vSphere HA.
  • Les hôtes ESXi ont des ventilateurs et des cartes d'interface réseau redondants.
  • Les commutateurs TOR et centraux sont configurés par paires haute disponibilité pour assurer la résilience.

VMware Engine surveille en permanence le temps d'activité, la disponibilité et fournit des contrats de niveau de service de disponibilité pour les types de VM suivants :

  • Hôtes ESXi
  • vCenter
  • PSC
  • NSX Manager

VMware Engine surveille en permanence les défaillances dans éléments suivants :

  • Disques durs
  • Ports de carte d'interface réseau physiques
  • Serveurs
  • Ventilateurs
  • Alimentation
  • Commutateurs
  • Ports du commutateur

En cas de défaillance d'un disque ou d'un nœud, VMware Engine ajoute immédiatement et automatiquement un nouveau nœud au cluster VMware concerné pour restaurer l'opérabilité du service. Les processus suivants ont lieu sur votre cloud privé :

  • Surveillance et alertes automatisées : notre système de surveillance suit en permanence l'état de vos nœuds. Lorsqu'un problème indiquant une défaillance matérielle potentielle est détecté, une alerte est déclenchée.
  • Diagnostic avec intervention humaine : bien que le système soit conçu pour le remplacement automatique, nos ingénieurs examinent ces alertes pour déterminer rapidement la cause première. Cela nous permet de résoudre le bon problème et d'éviter de remplacer des nœuds inutilement lorsqu'une solution plus simple (comme un redémarrage) est recommandée. Par exemple, des problèmes réseau temporaires ou des bugs logiciels peuvent déclencher des alertes similaires à celles des défaillances matérielles. Nous souhaitons éviter d'impacter votre cluster avec le remplacement de nœuds lorsque ce n'est pas l'action recommandée. Le remplacement inutile d'un nœud déclenche une resynchronisation complète de vSAN, qui est une opération intensive en E/S de stockage.
  • Remplacement automatique des nœuds en cas de défaillance matérielle : si nos ingénieurs confirment une défaillance matérielle, le processus de remplacement automatique des nœuds commence immédiatement. Un nouveau nœud est ajouté à votre cluster, et vSAN lance la resynchronisation des données sur ce nœud.

Les éléments VMware suivants dans les clouds privés sont sauvegardés, conservés et mis à jour :

  • ESXi
  • vCenter Platform Services Controller
  • vSAN
  • NSX

Sauvegarde et restauration

Les sauvegardes incluent les éléments suivants :

  • Sauvegardes nocturnes des règles vCenter, PSC et DMS
  • API intégrées à vCenter pour sauvegarder les composants au niveau de la couche d'application
  • Sauvegarde automatique avant la mise à jour ou la mise à niveau du logiciel de gestion VMware

Maintenance

Les types de maintenance planifiée suivants sont inclus :

Maintenance interne et backend

La maintenance interne et backend implique généralement de reconfigurer les ressources physiques ou d'installer des correctifs logiciels. Elle n'a pas d'incidence sur la consommation normale des ressources concernées. Les cartes d'interface réseau redondantes adressées à chaque rack physique, le trafic réseau normal et les opérations dans le cloud privé ne sont pas affectés. Vous ne remarquerez peut-être un impact sur les performances que si votre organisation s'attend à utiliser la bande passante redondante complète pendant l'intervalle de maintenance.

Maintenance du portail

Certains temps d'arrêt de service limités sont requis lorsque le plan de contrôle ou l'infrastructure est mis à jour. Les intervalles de maintenance peuvent être aussi fréquents qu'une fois par mois, et cette fréquence devrait diminuer au fil du temps. VMware Engine vous informe de la maintenance imminente du portail et fait son possible pour que l'intervalle de maintenance soit aussi court que possible. Pendant un intervalle de maintenance du portail, les services suivants continuent de fonctionner sans aucune incidence :

  • Plan de gestion et applications VMware
  • Accès à vCenter
  • Mise en réseau et stockage

Maintenance de l'infrastructure VMware

Il est parfois nécessaire de modifier la configuration de l'infrastructure VMware. Cette modification peut se produire tous les mois voire tous les deux mois, pour s'espacer ensuite au fil du temps. Google peut généralement effectuer ce type de maintenance, y compris les mises à jour de certificats, sans interrompre la consommation normale du cloud privé. Lors d'un intervalle de maintenance VMware, les services suivants continuent de fonctionner sans subir d'effet :

  • Plan de gestion et applications VMware
  • Accès à vCenter
  • Mise en réseau et stockage

Mises à jour et mises à niveau

VMware Engine est responsable de la gestion du cycle de vie des logiciels VMware (ESXi, vCenter, PSC et NSX) dans les clouds privés.

Les mises à jour logicielles incluent les suivantes :

  • Des correctifs : correctifs de sécurité ou corrections de bugs publiés par VMware
  • Des mises à jour : modification de la version mineure d'un composant de la pile VMware
  • Des mises à niveau : modification majeure de la version d'un composant de la pile VMware

VMware Engine teste les correctifs de sécurité critiques dès qu'ils sont disponibles dans VMware. Google s'efforcera de commencer le déploiement des correctifs critiques concernés dans les environnements cloud privés dans la semaine suivant leur disponibilité. Le délai réel de finalisation du correctif varie en fonction des disponibilités de planification et de la nécessité de planifier le correctif pour éviter tout temps d'arrêt pour les charges de travail des clients.

Lorsqu'une nouvelle version majeure des logiciels VMware est disponible, VMware Engine collabore avec ses clients pour coordonner un intervalle de maintenance adapté à l'application de la mise à niveau. VMware Engine applique les mises à niveau de versions majeures au moins six mois après la sortie de la version majeure et avertit les clients un mois avant l'application de ces mises à niveau.

VMware Engine collabore également avec les principaux fournisseurs du secteur pour s'assurer qu'ils sont compatibles avec la dernière version des logiciels VMware avant de procéder à une mise à niveau de version majeure. Pour obtenir des informations sur la compatibilité d'un fournisseur spécifique, contactez Cloud Customer Care.

Responsabilité de la mise à jour des certificats

La mise à jour des certificats relève de la responsabilité de Google. Si vous recevez une erreur de mise à jour du certificat, aucune action n'est requise. Le certificat est renouvelé avant son expiration. Toutefois, si LDAPS est configuré dans votre cloud privé, vous êtes seul responsable du certificat spécifique associé à cette erreur. Les mises à jour des certificats peuvent avoir lieu lors de la maintenance de l'infrastructure VMware.

Préparation

Google recommande de prendre les précautions suivantes avant de commencer une mise à jour ou une mise à niveau :

  • Vérifiez la capacité de stockage : assurez-vous que l'utilisation de l'espace de stockage du cluster vSphere est inférieure à 80 % pour conserver le contrat de niveau de service. Si l'utilisation est supérieure à 80 %, les mises à niveau peuvent prendre plus de temps que d'habitude ou échouer complètement. Si votre utilisation de l'espace de stockage est supérieure à 70 %, ajoutez un nœud pour développer le cluster et éviter les temps d'arrêt potentiels lors des mises à niveau.
  • Modifiez les règles de stockage vSAN avec des FTT de 0 : modifiez les VM configurées avec une règle de stockage vSAN pour les FTT de 0 par une règle de stockage vSAN pour les FTT de 1 afin de maintenir le contrat de niveau de service.
  • Supprimez les installations de CD des VM : supprimez tous les CD installés sur vos VM de charge de travail qui ne sont pas compatibles avec vMotion.
  • Terminez les installations d'outils VMware : effectuez toutes les installations ou mises à niveau d'outils VMware avant le début de la mise à niveau planifiée.
  • Supprimez le partage de bus SCSI sur les VM : supprimez le partage de bus SCSI sur les VM si vous ne souhaitez pas qu'elles soient éteintes.
  • Supprimez les VM et les datastores inaccessibles : supprimez les VM inutilisées et inaccessibles de l'inventaire vCenter. Supprimez tous les datastores externes inaccessibles.
  • Désactivez les règles Distributed Resource Scheduler (DRS) : les règles DRS permettant d'épingler une VM à un hôte empêchent le nœud de passer en mode de maintenance. Vous pouvez désactiver les règles DRS avant la mise à niveau et les activer une fois la mise à niveau terminée.
  • Mettez à jour les modules complémentaires VMware et les solutions tierces : vérifiez que les modules complémentaires VMware et les solutions tierces déployés sur votre cloud privé vCenter sont compatibles avec les versions postérieures à la mise à niveau mentionnées précédemment. Voici quelques exemples d'outils destinés à la sauvegarde, à la surveillance, à l'orchestration de la reprise après sinistre et à d'autres fonctions semblables. Contactez le fournisseur des solutions et effectuez la mise à jour à l'avance si nécessaire pour vous assurer de la compatibilité après la mise à niveau.

Durée de la mise à niveau et processus en arrière-plan

Les facteurs suivants peuvent affecter la durée de la mise à niveau :

  • Resynchronisations vSAN : la durée du processus de mise à niveau, en particulier la suppression des nœuds temporaires, varie en fonction des exigences de resynchronisation des données vSAN. Les tâches de resynchronisation vSAN et de rééquilibrage du cluster peuvent dépasser l'intervalle de maintenance désigné. Il s'agit de processus d'arrière-plan attendus qui n'affecteront pas la disponibilité des charges de travail.
  • Problèmes matériels sous-jacents : dans de rares cas, les redémarrages de l'hôte pendant la mise à niveau peuvent révéler des défaillances matérielles sous-jacentes. Pour respecter le SLA et assurer l'intégrité du cluster, le système donne la priorité au remplacement du matériel défectueux avant de poursuivre. Cette intervention nécessaire peut prolonger la durée globale de la mise à niveau.

Configurations pouvant affecter les processus de maintenance

VMware Engine utilise le mode de maintenance de VMware pour effectuer les mises à niveau, les mises à jour et la maintenance des nœuds. Cela permet d'assurer le fonctionnement continu de vos charges de travail de cloud privé. Toutefois, les configurations suivantes peuvent nécessiter des étapes supplémentaires avant qu'un nœud puisse passer en mode maintenance :

  • Règles DRS : règles MUST qui forcent les VM à rester sur un nœud spécifique.
  • Partage de bus SCSI : VM configurées pour partager des bus SCSI.
  • Montages de CD-ROM : VM avec CD-ROM associés, en particulier si ces CD-ROM ne peuvent pas être déplacés vers un autre nœud à l'aide de vMotion.
  • Connexions au port série : les VM utilisant des connexions au port série qui les empêchent d'être déplacées vers un autre nœud à l'aide de vMotion.
  • Mappages de périphériques bruts (RDM) : VM accédant directement aux périphériques de stockage physiques.

Si une action est nécessaire

Si l'une de ces configurations existe sur un nœud, Cloud Customer Care vous en informe au moins 24 heures avant de prendre les mesures correctives nécessaires pour maintenir la disponibilité de votre cloud privé. Dans certains cas, des étapes telles que l'arrêt d'une VM, son déplacement avec vMotion, puis son redémarrage, ou la suppression de CD-ROM peuvent perturber brièvement votre charge de travail.

Étape suivante