Manutenzione e aggiornamenti del cloud privato

Gli ambienti cloud privati sono progettati nei seguenti modi per non avere un singolo punto di défaillance:

  • I cluster ESXi sono configurati con l'alta disponibilità (HA) di vSphere. I cluster sono dimensionati 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 protezione contro un singolo errore. Per i cluster più grandi, puoi configurare vSAN per offrire una maggiore resilienza.
  • Le macchine virtuali (VM) vCenter, PSC e NSX Manager sono configurate con archiviazione RAID-10 per proteggersi da errori di archiviazione. Le VM sono inoltre protette da guasti di nodi e reti da vSphere HA.
  • Gli host ESXi dispongono di ventole e NIC ridondanti.
  • Gli switch TOR e spine sono configurati in coppie HA per garantire la resilienza.

VMware Engine monitora continuamente l'uptime e la disponibilità e fornisce SLA di disponibilità per i seguenti tipi di VM:

  • Host ESXi
  • vCenter
  • PSC
  • NSX Manager

VMware Engine monitora continuamente i seguenti elementi per rilevare eventuali errori:

  • Dischi rigidi
  • Porte NIC fisiche
  • Server
  • Fan
  • Alimentazione
  • Interruttori
  • Cambiare porta

Se un disco o un nodo non funziona, VMware Engine aggiunge immediatamente e automaticamente un nuovo nodo al cluster VMware interessato per ripristinare l'operabilità del servizio.

Di seguito sono riportati gli elementi VMware nei cloud privati di cui viene eseguito il backup, la manutenzione e l'aggiornamento:

  • ESXi
  • vCenter Platform Services Controller
  • vSAN
  • NSX

Backup e ripristino

I backup includono:

  • Backup incrementali notturni delle regole di vCenter, PSC e DVS.
  • API native di vCenter per eseguire 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 di asset fisici o l'installazione di patch software. Non influisce sul normale consumo delle risorse in fase di pubblicazione. Con le NIC ridondanti che vanno a ogni rack fisico, il normale traffico di rete e le operazioni del cloud privato non sono interessati. Potresti notare un impatto sul rendimento solo se la tua organizzazione prevede di utilizzare l'intera larghezza di banda ridondante durante l'intervallo di manutenzione.

Manutenzione del portale

È necessario un tempo di riposo limitato del servizio quando viene aggiornato il piano di controllo o l'infrastruttura. Gli intervalli di manutenzione possono essere frequenti fino a una volta al mese e si prevede che la frequenza diminuisca nel tempo. VMware Engine ti invia una notifica relativa alla manutenzione imminente 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:

  • Piattaforma di gestione e applicazioni VMware
  • Accesso a vCenter
  • Tutto il networking e lo spazio di archiviazione

Manutenzione dell'infrastruttura VMware

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

  • Piattaforma di gestione e applicazioni 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 minore della versione di un componente dello stack VMware
  • Upgrade: modifica della versione principale di un componente dello stack VMware

VMware Engine testa le patch di sicurezza critiche non appena diventano disponibili da VMware. In base allo SLA, VMware Engine prevede l'implementazione di 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 una periodo di manutenzione adatta per l'applicazione dell'upgrade. VMware Engine applica gli upgrade delle versioni principali 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 inoltre con i principali vendor del settore per assicurarsi che supportino la versione software VMware più recente prima di implementare un upgrade di versione principale. Per informazioni sull'assistenza per fornitori specifici, contatta il team di assistenza clienti di Cloud.

Responsabilità dell'aggiornamento del certificato

Gli aggiornamenti dei certificati sono di proprietà di Google. Se viene visualizzato un errore di aggiornamento del certificato, non è richiesta alcuna azione e il certificato viene rinnovato prima della scadenza. Tuttavia, se LDAPS è configurato nel tuo cloud privato, sei unicamente responsabile del certificato specifico associato all'errore.

preparazione

Google consiglia di eseguire le seguenti preparazioni prima di iniziare un aggiornamento o un upgrade:

  • Verifica 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 normale 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 riposo durante gli upgrade.
  • Modifica i criteri di archiviazione vSAN con FTT pari a 0: modifica 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 mount dei CD delle VM: rimuovi i CD montati sulle VM del carico di lavoro che non sono compatibili con vMotion.
  • Completa le installazioni degli 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 spente.
  • Rimuovi datastore e VM inaccessibili:rimuovi le VM inutilizzate e inaccessibili dall'inventario di vCenter. Rimuovi eventuali datastore esterni inaccessibili.
  • Disattiva le regole DRS (Distributed Resource Scheduler): le regole DRS che fissano una VM a un host impediscono a un nodo di entrare in modalità di manutenzione. Puoi disattivare le regole DRS prima dell'upgrade e riattivarle al termine dell'upgrade.
  • Aggiorna i componenti aggiuntivi VMware e le soluzioni di terze parti:verifica che i componenti aggiuntivi VMware e le soluzioni di terze parti 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. Rivolgiti al fornitore della soluzione e aggiornalo in anticipo se necessario per garantire la compatibilità dopo l'upgrade.

Configurazioni che potrebbero influire sulle procedure di manutenzione

VMware Engine sfrutta la modalità di manutenzione di VMware per eseguire upgrade, aggiornamenti e manutenzione dei nodi. In questo modo, puoi garantire il funzionamento continuo dei tuoi workload Private Cloud. Tuttavia, le seguenti configurazioni potrebbero richiedere passaggi aggiuntivi prima che un nodo possa entrare in modalità di manutenzione:

  • Regole DRS: regole MUST che forzano le VM a rimanere su un nodo specifico.
  • Condivisione del bus SCSI:VM configurate per condividere bus SCSI.
  • Montaggi di CD-ROM: VM con CD-ROM collegati, in particolare se non è possibile spostarli su un altro nodo utilizzando vMotion.
  • Connessioni porta seriale:VM che utilizzano connessioni porta seriale che ne impediscono il trasferimento a un altro nodo utilizzando vMotion.
  • Mappature dei dispositivi non elaborati (RDM): VM che accedono direttamente ai dispositivi di archiviazione fisico.

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 adottare i passaggi di correzione necessari per mantenere la disponibilità del tuo private cloud. In alcuni casi, passaggi come lo spegnimento di una VM, lo spostamento con vMotion e il successivo riavvio o la rimozione di CD-ROM potrebbero interrompere brevemente il carico di lavoro.

Passaggi successivi