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) di vSphere. Le dimensioni dei cluster in modo da avere almeno un nodo di riserva per la resilienza.
  • vSAN fornisce uno spazio di archiviazione principale ridondante, che richiede almeno tre nodi per fornire la protezione da un singolo errore. Per i cluster più grandi, puoi configurare vSAN per fornire una resilienza maggiore.
  • Le macchine virtuali (VM) vCenter, PSC e NSX Manager sono configurate con spazio di archiviazione RAID-10 per evitare errori di archiviazione. Le VM sono inoltre protette da guasti di nodi e rete da vSphere HA.
  • Gli host ESXi hanno ventole e NIC ridondanti.
  • Gli interruttori 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) disponibilità per i seguenti tipi di VM:

  • Host ESXi
  • vCenter
  • PSC
  • NSX Manager

VMware Engine monitora costantemente quanto segue per rilevare eventuali errori:

  • Dischi rigidi
  • Porte NIC fisiche
  • Server
  • Ventole
  • Potenza
  • Interruttori
  • Cambia porte

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.

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

  • ESXi
  • Titolare dei servizi della piattaforma vCenter
  • vSAN
  • NSX

Backup e ripristino

I backup includono quanto segue:

  • Backup incrementali di notte di 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.

Manutenzione di backend e interna

La manutenzione di backend e interna in genere comporta la riconfigurazione degli asset fisici o l'installazione di patch software. Non influisce sul normale consumo degli asset serviti. Con NIC ridondanti in ogni rack fisico, il normale traffico di rete e le operazioni del cloud privato non sono interessati. Potresti notare un impatto sulle prestazioni solo se la tua organizzazione prevede di utilizzare l'intera larghezza di banda ridondante durante l'intervallo di manutenzione.

Manutenzione del portale

Quando il piano di controllo o l'infrastruttura vengono aggiornati, è necessario un certo tempo di inattività del servizio. Gli intervalli di manutenzione possono essere anche una volta al mese e si prevede che la frequenza diminuisca nel tempo. VMware Engine ti avvisa dell'imminente manutenzione del portale e fa il possibile per 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:

  • Applicazioni e piano di gestione VMware
  • Accesso a vCenter
  • Tutto il networking e lo spazio di archiviazione

Manutenzione dell'infrastruttura VMware

Occasionalmente è necessario apportare modifiche alla configurazione dell'infrastruttura VMware. Questi intervalli possono verificarsi ogni 1-2 mesi, ma la frequenza dovrebbe diminuire nel tempo. In genere, questo tipo di manutenzione può essere eseguita senza interrompere il normale consumo del cloud privato. Durante un intervallo di manutenzione VMware, i seguenti servizi continuano a funzionare senza alcun impatto:

  • Applicazioni e piano di gestione VMware
  • Accesso a vCenter
  • Tutto il networking e lo spazio di 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 di versione minore di un componente dello stack VMware
  • Upgrade: modifica principale della versione di un componente stack VMware

VMware Engine testa le patch di sicurezza critiche non appena diventano disponibili da VMware. In base allo SLA (accordo sul livello del servizio), VMware Engine ha come target un'implementazione delle patch di sicurezza in 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 della versione principale.

Inoltre, VMware Engine collabora con i principali fornitori del settore per assicurarsi 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

Google consiglia di seguire i seguenti passaggi prima di avviare un aggiornamento o un upgrade:

  • 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 possibili 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 (accordo sul livello del servizio).
  • Rimuovi i montaggi CD delle VM: rimuovi tutti i CD montati sulle VM dei carichi di lavoro non compatibili con vMotion.
  • Completa le installazioni degli strumenti VMware: completa eventuali installazioni o upgrade di 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 spente.
  • Rimuovi VM e datastore inaccessibili: rimuovi le VM orfane e inaccessibili dall'inventario vCenter. Rimuovi tutti i datastore esterni non accessibili.
  • Disabilita regole DRS: le regole DRS che bloccano una VM a un host impediscono a un nodo di entrare in modalità di manutenzione. Puoi disabilitare le regole DRS prima dell'upgrade e attivarle al termine dell'upgrade.
  • Aggiornamento dei componenti aggiuntivi di VMware e delle soluzioni di terze parti: verifica che i componenti aggiuntivi di VMware e le soluzioni di terze parti distribuite sul tuo cloud privato vCenter siano compatibili con le versioni successive all'upgrade menzionate in precedenza. Esempi di strumenti includono quelli per il backup, il monitoraggio, l'orchestrazione del ripristino di emergenza e altre funzioni simili. Verifica con 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 utilizza la modalità di manutenzione di VMware per eseguire upgrade, aggiornamenti e manutenzione dei nodi. Ciò garantisce il funzionamento continuo dei carichi di lavoro nel 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 bus SCSI: VM configurate per condividere bus SCSI.
  • Montaggi di CD-ROM: VM con CD-ROM collegati, soprattutto se tali CD-ROM non possono essere spostati su un altro nodo utilizzando vMotion.
  • Connessioni con porte seriali: VM che utilizzano connessioni con porte seriali che ne impediscono lo spostamento su un altro nodo mediante vMotion.
  • Mappature dei dispositivi non elaborati (RDM): VM che accedono direttamente ai dispositivi di archiviazione fisici.

Se è necessario un intervento

Se una di queste configurazioni è presente su un nodo, l'assistenza clienti Google Cloud ti avvisa almeno 24 ore prima di intraprendere le azioni correttive necessarie per mantenere la disponibilità del tuo cloud privato. In alcuni casi, passaggi come spegnere una VM e spostarla con vMotion e poi accenderla oppure la rimozione di CD-ROM potrebbero interrompere brevemente il carico di lavoro.

Passaggi successivi