Manutenzione e aggiornamenti del cloud privato

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

  • I cluster ESXi sono configurati con l'alta disponibilità (HA) vSphere. 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 vengono inoltre protetto da errori di rete e dei nodi da parte dell'alta disponibilità di vSphere.
  • 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, la disponibilità e fornisce SLA (accordi sul livello del servizio) per la disponibilità dei seguenti tipi di VM:

  • Host ESXi
  • vCenter
  • PSC
  • NSX Manager

VMware Engine monitora continuamente gli errori seguenti:

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

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.

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

  • 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 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 implica la riconfigurazione fisica risorse o l'installazione di patch del 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 sulle prestazioni solo se la tua organizzazione prevede di utilizzare larghezza di banda ridondante durante l'intervallo di manutenzione.

Manutenzione di portali

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

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

Manutenzione dell’infrastruttura VMware

Di tanto in tanto è necessario apportare modifiche alla configurazione dell'ambiente VMware dell'infrastruttura. Questi intervalli possono verificarsi ogni uno o due mesi, ma si prevede che la frequenza diminuisca nel tempo. Questo tipo di manutenzione solitamente senza interrompere il normale consumo del cloud privato. Durante una sessione di VMware di manutenzione, i seguenti servizi continuano a funzionare senza 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 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 in VMware. In base allo SLA (accordo sul livello del servizio), VMware Engine ha come target un'implementazione di patch di sicurezza agli ambienti cloud privato entro una settimana la disponibilità del servizio.

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

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 in uso. Per informazioni sull'assistenza per fornitori specifici, contatta Assistenza clienti Google Cloud.

Responsabilità dell'aggiornamento dei certificati

Gli aggiornamenti dei certificati sono di proprietà di Google. Se ottieni un certificato errore di aggiornamento, non è richiesta alcuna azione e il certificato viene rinnovato prima la scadenza del periodo di conservazione. Tuttavia, se LDAPS è configurato nel cloud privato, l'unico responsabile del certificato specifico associato all'errore.

preparazione

Google consiglia di seguire le seguenti preparazioni prima di avviare un aggiornamento upgrade:

  • Controlla la capacità di archiviazione: assicurati che lo spazio di archiviazione del cluster vSphere è 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:cambia le VM configurate con una Criterio di archiviazione vSAN per FTT (Failures to Tolerate) pari a 0 per uno spazio di archiviazione vSAN con FTT di 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 di strumenti VMware: completa le installazioni oppure gli 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 che le VM vengano spente.
  • Rimuovi datastore e VM inaccessibili:rimuovi datastore e VM inutilizzati VM dall'inventario vCenter. Rimuovi tutti i datastore esterni inaccessibili.
  • Disabilita regole Distributed Resource Scheduler (DRS): regole DRS che bloccano una La VM a un host impedisce a un nodo di entrare in modalità di manutenzione. Puoi disattivare le regole DRS prima dell'upgrade e abilitarle dopo completato.
  • 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. Verifica con il fornitore della soluzione ed esegui l'aggiornamento prima di procedere di tempo, 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: 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 i CD-ROM, soprattutto se si tratta di CD-ROM non possono essere spostati su un altro nodo utilizzando vMotion.
  • Connessioni su porta seriale:VM che utilizzano connessioni a porte seriali che impediscono spostandoli su un altro nodo tramite 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 esiste su un nodo, l'assistenza clienti Google Cloud ti avvisa almeno 24 ore prima di intraprendere le azioni correttive richieste per mantenere la disponibilità del tuo cloud privato. 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