Manutenzione e aggiornamenti del cloud privato

Gli ambienti cloud privati sono progettati nei seguenti modi per non avere single point of failure:

  • I cluster ESXi sono configurati con l'alta disponibilità (HA) vSphere. I cluster sono dimensionati in modo da avere almeno un nodo di riserva per la resilienza.
  • vSAN fornisce spazio di archiviazione principale ridondante, richiedendo almeno tre nodi per fornire protezione contro un singolo errore. Per cluster più grandi, puoi configurare vSAN per fornire una maggiore resilienza.
  • Le macchine virtuali (VM) vCenter, PSC e NSX Manager sono configurate con archiviazione RAID-10 per evitare errori dello spazio di archiviazione. Le VM sono ulteriormente protette dagli errori di rete e dei nodi da vSphere HA.
  • Gli host ESXi hanno ventole e NIC ridondanti.
  • Gli switch TOR e spine sono configurati in coppie ad alta disponibilità per fornire resilienza.

VMware Engine monitora continuamente l'uptime, monitora la disponibilità e fornisce SLA (accordi sul livello del servizio) relativi alla disponibilità per i seguenti tipi di VM:

  • Host ESXi
  • vCenter
  • PSC
  • NSX Manager

VMware Engine monitora continuamente gli errori seguenti:

  • Dischi rigidi
  • Porte NIC fisiche
  • Server
  • Ventole
  • Potenza
  • Interruttori
  • Porte switch

In caso di errore di un disco o di un nodo, VMware Engine aggiunge immediatamente e automaticamente un nuovo nodo al cluster VMware interessato per ripristinare l'operabilità del servizio.

Viene eseguito il backup, la manutenzione e l'aggiornamento dei seguenti elementi VMware nei cloud privati:

  • ESXi
  • Controller servizi della piattaforma vCenter
  • vSAN
  • NSX

Backup e ripristino

I backup includono quanto segue:

  • Backup notturni incrementali delle regole vCenter, PSC e DVS.
  • API native vCenter per il backup dei componenti a livello di applicazione.
  • Backup automatico prima dell'aggiornamento o dell'upgrade del software di gestione VMware.

Manutenzione

Sono inclusi i seguenti tipi di manutenzione pianificata.

Backend e manutenzione interna

La manutenzione interna e di backend in genere comporta la riconfigurazione delle risorse fisiche o l'installazione di patch del software. ma non influisce sul normale consumo degli asset serviti. Le NIC ridondanti destinate a ogni rack fisico non incidono sul normale traffico di rete e sulle operazioni nel cloud privato. Potresti notare un impatto sulle prestazioni solo se l'organizzazione prevede di utilizzare la larghezza di banda ridondante completa durante l'intervallo di manutenzione.

Manutenzione di portali

È necessario un tempo di inattività del servizio limitato quando si aggiorna il piano di controllo o l'infrastruttura. Gli intervalli di manutenzione possono essere frequenti come una volta al mese e si prevede una diminuzione della frequenza nel tempo. VMware Engine ti informa dell'imminente manutenzione del portale e si impegna a mantenere l'intervallo di manutenzione il più breve possibile. Durante un intervallo di manutenzione del portale, i seguenti servizi continuano a funzionare senza alcun impatto:

  • Piano di gestione e applicazioni VMware
  • Accesso a vCenter
  • Tutte le funzionalità di networking e archiviazione

Manutenzione dell’infrastruttura VMware

Occasionalmente è necessario apportare modifiche alla configurazione dell'infrastruttura VMware. Questi intervalli possono verificarsi ogni uno o due mesi, ma si prevede che la frequenza diminuisca nel tempo. Questo tipo di manutenzione solitamente può essere eseguita senza interrompere il normale consumo del cloud privato. Durante un intervallo di manutenzione di VMware, i seguenti servizi continuano a funzionare senza alcun impatto:

  • Piano di gestione e applicazioni VMware
  • Accesso a vCenter
  • Tutte le funzionalità di networking e archiviazione

Aggiornamenti e upgrade

VMware Engine è responsabile della gestione del ciclo di vita del software VMware (ESXi, vCenter, PSC e NSX) nei cloud privati.

Gli aggiornamenti software includono:

  • Patch: patch di sicurezza o correzioni di bug rilasciate da VMware
  • Aggiornamenti: modifica secondaria della versione di un componente dello stack VMware
  • Upgrade: modifica principale della versione di un componente dello stack VMware

VMware Engine testa le patch di sicurezza critiche non appena vengono disponibili da VMware. In base allo SLA (accordo sul livello del servizio), VMware Engine prevede l'implementazione delle patch di sicurezza negli ambienti cloud privato entro una settimana dalla loro disponibilità.

Quando è disponibile una nuova versione principale del software VMware, VMware Engine collabora con i clienti per coordinare un periodo di manutenzione adeguato per l'applicazione dell'upgrade. VMware Engine applica gli upgrade della versione principale almeno sei mesi dopo il rilascio della versione principale e avvisa i clienti un mese prima dell'applicazione degli upgrade delle versioni principali.

VMware Engine collabora anche con i principali fornitori del settore per garantire che supportino la versione del software VMware più recente prima di implementare un upgrade della versione principale. Per informazioni sull'assistenza per fornitori specifici, contatta l'assistenza clienti Google Cloud.

preparazione

Prima di avviare un aggiornamento o un upgrade, Google consiglia di completare i seguenti preparativi:

  • Controlla la capacità di archiviazione: assicurati che l'utilizzo dello spazio di archiviazione del cluster vSphere sia inferiore all'80% per mantenere lo SLA. Se l'utilizzo è superiore all'80%, gli upgrade potrebbero richiedere più tempo del solito o non riuscire completamente. Se l'utilizzo dello spazio di archiviazione è superiore al 70%, aggiungi un nodo per espandere il cluster ed evitare potenziali tempi di inattività durante gli upgrade.
  • Modifica i criteri di archiviazione vSAN con FTT pari a 0: cambia le VM configurate con un criterio di archiviazione vSAN per Failures to Tolerate (FTT) pari a 0 in un criterio di archiviazione vSAN con FTT pari a 1 per mantenere lo SLA.
  • Rimuovi i montaggi CD delle VM: rimuovi tutti i CD montati sulle VM dei carichi di lavoro e non compatibili con vMotion.
  • Completa le installazioni di strumenti VMware: completa eventuali installazioni o upgrade degli strumenti VMware prima dell'inizio dell'upgrade pianificato.
  • Rimuovi la condivisione del bus SCSI sulle VM: rimuovi la condivisione del bus SCSI sulle VM se non vuoi che le VM vengano disattivate.
  • Rimuovi datastore e VM inaccessibili:rimuovi le VM inutilizzate e inaccessibili dall'inventario vCenter. Rimuovi tutti i datastore esterni inaccessibili.
  • Disabilita regole Distributed Resource Scheduler (DRS): le regole DRS che fissano una VM a un host impediscono a un nodo di entrare in modalità di manutenzione. Puoi disabilitare le regole DRS prima dell'upgrade e abilitarle al termine dell'upgrade.
  • Aggiorna i componenti aggiuntivi e le soluzioni di terze parti VMware: verifica che i componenti aggiuntivi e le soluzioni di terze parti VMware di cui è stato eseguito il deployment nel tuo vCenter cloud privato siano compatibili con le versioni post-upgrade menzionate in precedenza. Esempi di strumenti includono quelli per il backup, il monitoraggio, l'orchestrazione del ripristino di emergenza e altre funzioni simili. Consulta il fornitore della soluzione e, se necessario, aggiornala in anticipo per garantire la compatibilità dopo l'upgrade.

Configurazioni che potrebbero influire sui processi di manutenzione

VMware Engine sfrutta la modalità di manutenzione di VMware per eseguire upgrade, aggiornamenti e manutenzione dei nodi. Ciò garantisce il funzionamento continuo dei carichi di lavoro del cloud privato. Tuttavia, le seguenti configurazioni potrebbero richiedere passaggi aggiuntivi prima che un nodo possa entrare in modalità di manutenzione:

  • Regole DRS: DEVONO regole che obbligano le VM a rimanere su un nodo specifico.
  • Condivisione dei bus SCSI: VM configurate per la condivisione dei bus SCSI.
  • Montaggi CD-ROM: VM a cui sono collegati CD-ROM, soprattutto se questi CD-ROM non possono essere spostati su un altro nodo utilizzando vMotion.
  • Connessioni su porta seriale:VM che utilizzano connessioni a porte seriali che ne impediscono lo spostamento su un altro nodo tramite vMotion.
  • Mappature non elaborate dei dispositivi (RDM): VM che accedono direttamente ai dispositivi di archiviazione fisici.

Se è necessaria un'azione

Se una di queste configurazioni è presente su un nodo, l'assistenza clienti Google Cloud ti invia una notifica almeno 24 ore prima di intraprendere le azioni di correzione richieste per mantenere la disponibilità del tuo cloud privato. In alcuni casi, passaggi come lo spegnimento di una VM e il suo spostamento con vMotion per poi accenderla o la rimozione di CD-ROM, potrebbero interrompere brevemente il carico di lavoro.

Passaggi successivi