Manutenzione e aggiornamenti del cloud privato

Gli ambienti cloud privati sono progettati nei modi seguenti per non avere punto di errore:

  • 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 spazio di archiviazione principale ridondante, che richiede almeno tre nodi offrono protezione da un singolo errore. Per cluster più grandi, puoi e configurare vSAN per fornire una maggiore resilienza.
  • Le macchine virtuali (VM) vCenter, PSC e NSX Manager sono configurate con Archiviazione RAID-10 per protezione da guasti dello spazio di archiviazione. Le VM sono inoltre protette da guasti di nodi e rete 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
  • Ventole
  • Alimentazione
  • Interruttori
  • Cambiare porta

In caso di errore di un disco o di un nodo, VMware Engine immediatamente e automaticamente aggiunge 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
  • Controller servizi della piattaforma vCenter
  • vSAN
  • NSX

Backup e ripristino

I backup includono:

  • 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 della gestione VMware software.

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 di gli asset serviti. Con NIC ridondanti in ogni rack fisico, le normali operazioni di rete e cloud privato non subiranno modifiche. 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 inattività del servizio limitato quando il piano di controllo l'infrastruttura sia aggiornata. Gli intervalli di manutenzione possono essere frequenti fino a una volta al mese e la loro frequenza dovrebbe diminuire 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:

  • Piano 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:

  • 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 di VMware software (ESXi, vCenter, PSC e NSX) in 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 principale della versione di un componente dello stack VMware

VMware Engine testa le patch di sicurezza critiche non appena vengono disponibili in VMware. In base allo SLA, VMware Engine prevede l'implementazione di patch di sicurezza negli ambienti cloud privati entro una settimana dalla loro disponibilità.

Quando è disponibile una nuova versione principale del software VMware, VMware Engine collabora con i clienti per coordinare periodo di manutenzione per applicare l'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 di applicare gli upgrade delle versioni principali.

VMware Engine collabora anche con i principali fornitori del settore per garantire supportano l'ultima versione del software VMware prima di implementare una dell'upgrade della versione di Kubernetes. Per informazioni sull'assistenza per fornitori specifici, contatta il team di assistenza clienti 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 cloud privato, l'unico 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 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 di inattività 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 montaggi CD delle VM:rimuovi tutti i CD montati sulle VM dei carichi 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 datastore e VM inutilizzati VM dall'inventario 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 e le soluzioni di terze parti VMware: verifica che VMware i componenti aggiuntivi e le soluzioni di terze parti di cui è stato eseguito il deployment nel vCenter del cloud privato compatibili con le versioni successive all'upgrade menzionate in precedenza. Esempi di strumenti includono quelli per il backup, il monitoraggio, l'orchestrazione 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 sui processi di manutenzione

VMware Engine sfrutta la modalità di manutenzione di VMware per eseguire upgrade, aggiornamenti e manutenzione dei nodi. Ciò contribuisce a garantire un funzionamento continuo dei carichi di lavoro del cloud privato. Tuttavia, le seguenti configurazioni potrebbero Sono necessari ulteriori passaggi 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 dei bus SCSI: VM configurate per la condivisione dei bus SCSI.
  • Montaggi CD-ROM:VM a cui sono collegati i CD-ROM, soprattutto se si tratta di CD-ROM non possono essere spostati 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 non elaborate dei dispositivi (RDM): VM che accedono direttamente allo spazio di archiviazione fisico dispositivi mobili.

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 i passaggi di correzione necessari per mantenere la disponibilità del tuo Private Cloud. In alcuni casi, passaggi come lo spegnimento di VM e lo spostamento con vMotion e l'accensione o la rimozione di CD-ROM potrebbero interrompere brevemente il carico di lavoro.

Passaggi successivi