Best practice per la disponibilità

Questa pagina descrive le best practice per garantire l'alta affidabilità dell'installazione di Google Distributed Cloud connesso. Distributed Cloud connesso non offre un contratto di servizio (SLA) e fornisce solo l'obiettivo del livello di servizio (SLO) descritto in questa pagina.

Scegliere e implementare il livello di disponibilità

Devi scegliere il livello di disponibilità per i carichi di lavoro di Distributed Cloud connesso più adatto alle tue esigenze aziendali. Ad esempio, un'applicazione di self-checkout in un negozio al dettaglio ha un rischio di disponibilità molto inferiore rispetto a un deployment RAN edge di un operatore di rete mobile.

La disponibilità di destinazione è direttamente proporzionale alla capacità delle risorse di riserva di Distributed Cloud che prenoti per le emergenze. La tabella seguente descrive questa relazione. Queste stime non includono i tempi di inattività pianificati con un periodo di manutenzione.

Il software Distributed Cloud connesso consuma alcune risorse su ogni macchina fisica. L'importo varia a seconda della configurazione specifica del deployment di Distributed Cloud connesso. Google consiglia di eseguire il benchmark del deployment di Distributed Cloud connesso per misurare questo importo e tenerne conto durante la pianificazione della distribuzione dei carichi di lavoro.

Fattore di forma di GDC connesso Capacità in uso Capacità riservata Disponibilità di destinazione
Rack GDC connesso
(cluster singolo di 6 macchine)		 83,33% 16,67% 99,9%
Rack GDC connesso
(cluster singolo di 6 macchine)		 100% 0% 93,5%
Server GDC connesso
(cluster singolo di 3 macchine)		 66,6% 33,3% 99,9%

Potresti riscontrare un'improvvisa perdita di capacità a causa di un guasto hardware o di un nodo che richiede un riavvio. Per prepararti a questo, devi progettare i carichi di lavoro tenendo conto delle quote di risorse in modo da avere sempre capacità disponibile su ogni nodo Distributed Cloud connesso che soddisfi il livello di disponibilità scelto.

Ad esempio, per ottenere una disponibilità di destinazione del 99,9% in un deployment di rack Distributed Cloud connesso, devi configurare i carichi di lavoro in modo che una delle sei macchine fisiche in ogni cluster Distributed Cloud connesso sia disponibile come backup.

Diversificare geograficamente le zone Distributed Cloud

Per ridurre al minimo l'impatto di potenziali guasti del piano di gestione, ti consigliamo vivamente di distribuire le zone Distributed Cloud in diverse regioni vicine.

Utilizzare la modalità di sopravvivenza

I cluster Distributed Cloud utilizzano un piano di controllo locale che viene eseguito sull'hardware Distributed Cloud connesso. I carichi di lavoro continuano a essere eseguiti quando la connessione a Google Cloud viene persa. Per ulteriori informazioni, vedi Modalità di sopravvivenza di Distributed Cloud connesso.

Comprendere gli aggiornamenti software e i periodi di manutenzione

Google aggiorna regolarmente il software Distributed Cloud connesso. Questi aggiornamenti software sono obbligatori e non puoi disattivarli. Distributed Cloud connesso ti consente di specificare singoli periodi di manutenzione per ciascuno dei tuoi cluster Distributed Cloud connesso.

Per ridurre le potenziali interruzioni temporanee dei carichi di lavoro, i periodi di manutenzione ti consentono di controllare quando possono avvenire gli upgrade automatici dei piani di controllo e dei nodi. I periodi di manutenzione sono utili, tra l'altro, per i seguenti tipi di scenari:

  • Orari non di punta: vuoi ridurre al minimo la probabilità di tempi di inattività pianificando gli upgrade automatici durante gli orari non di punta, quando il traffico è ridotto.
  • On-call: vuoi assicurarti che gli upgrade avvengano durante l'orario di lavoro in modo che qualcuno possa monitorarli e gestire eventuali problemi imprevisti.
  • Upgrade multi-cluster: vuoi implementare gli upgrade su più cluster in diverse regioni uno alla volta a intervalli specificati.

Distributed Cloud connesso supporta i seguenti tipi di periodi di manutenzione:

  • Periodo di manutenzione. Specifica un periodo di tempo durante il quale Google può eseguire la manutenzione e gli upgrade software sul cluster Distributed Cloud connesso.
  • Periodo di esclusione dalla manutenzione. Specifica un periodo di tempo durante il quale Google non può eseguire la manutenzione o gli upgrade software sul cluster Distributed Cloud connesso. Per configurare un periodo di esclusione dalla manutenzione, devi prima configurare un periodo di manutenzione. Un periodo di esclusione dalla manutenzione ha la precedenza sul periodo di manutenzione del cluster.

Oltre agli upgrade automatici, Google potrebbe occasionalmente dover eseguire altre attività di manutenzione. In questi casi, rispetta il periodo di manutenzione di un cluster, se possibile.

Se le attività vengono eseguite oltre il periodo di manutenzione, Distributed Cloud connesso tenta di metterle in pausa. Poi tenta di riprenderle durante il periodo di manutenzione successivo.

Distributed Cloud connesso si riserva il diritto di implementare upgrade di emergenza non pianificati al di fuori dei periodi di manutenzione. Inoltre, gli upgrade obbligatori da software ritirati o obsoleti potrebbero avvenire automaticamente al di fuori dei periodi di manutenzione.

Puoi anche eseguire l'upgrade manuale del cluster in qualsiasi momento. Gli upgrade avviati manualmente iniziano immediatamente e ignorano eventuali periodi di manutenzione.

Per scoprire come configurare un periodo di manutenzione per un cluster nuovo o esistente, vedi Configurare un periodo di manutenzione.

Scaglionamento degli aggiornamenti software

Per ridurre i tempi di inattività dei carichi di lavoro, gli aggiornamenti software di Distributed Cloud connesso sono scaglionati. In altre parole, Google esegue l'upgrade dei nodi worker in ogni cluster Distributed Cloud connesso in fasi. Tutti i nodi worker in una fase di upgrade software vengono disattivati contemporaneamente.

Il numero di nodi in una fase di upgrade software è determinato come segue:

  • Deployment di un massimo di 3 rack: ogni fase è il numero totale di macchine in tutti i rack diviso per 6 e arrotondato all'intero successivo.
  • Deployment di 4 o più rack: ogni fase è il numero totale di macchine in tutti i rack del deployment diviso per il numero di rack nel deployment.

Hai anche la possibilità di impostare le dimensioni della fase di upgrade software. In altre parole, puoi specificare il numero di nodi che possono essere disattivati contemporaneamente per un upgrade software in un cluster Distributed Cloud connesso. Per le istruzioni, vedi Gestire i tempi di inattività dei nodi durante gli upgrade software.

Limitazioni

I periodi di manutenzione presentano le seguenti limitazioni:

  • Un periodo di manutenzione per cluster. Puoi configurare un solo periodo di manutenzione per cluster. La configurazione di un nuovo periodo di manutenzione sovrascrive quello precedente.

  • Fusi orari per i periodi di manutenzione. Quando configuri e visualizzi i periodi di manutenzione, gli orari vengono visualizzati in modo diverso a seconda dello strumento che utilizzi, come descritto nelle sezioni seguenti.

Quando configuri i periodi di manutenzione

Quando utilizzi il flag --maintenance-window più generico per configurare un periodo di manutenzione, non puoi specificare un fuso orario. Quando utilizzi Google Cloud CLI o l'API, viene utilizzato il fuso orario UTC per visualizzare gli orari. La Google Cloud console utilizza il fuso orario locale per visualizzare gli orari.

Quando utilizzi flag più granulari, come --maintenance-window-start, puoi specificare il fuso orario come parte del valore. Se ometti il fuso orario, viene utilizzato il fuso orario locale. Gli orari vengono sempre memorizzati in formato UTC.

Quando visualizzi i periodi di manutenzione

Quando visualizzi le informazioni sul cluster, i timestamp dei periodi di manutenzione possono essere visualizzati in formato UTC o nel fuso orario locale, a seconda di come visualizzi le informazioni:

  • Quando utilizzi la Google Cloud console per visualizzare le informazioni sul cluster, gli orari vengono sempre visualizzati nel fuso orario locale.
  • Quando utilizzi gcloud CLI per visualizzare le informazioni sul cluster, gli orari vengono sempre visualizzati in formato UTC.

In entrambi i casi, RRULE è sempre in formato UTC. Ciò significa che, se specifichi, ad esempio, i giorni della settimana, questi giorni sono in formato UTC.

Configurare i periodi di manutenzione del cluster

Distributed Cloud connesso ti consente di specificare un periodo di manutenzione per ciascuno dei tuoi cluster Distributed Cloud connesso. Questa finestra indica a Google di aggiornare il software Distributed Cloud solo durante l'orario e con la frequenza specificati.

Le seguenti regole regolano i periodi di manutenzione dei cluster Distributed Cloud connesso:

  • Se specifichi un periodo di manutenzione per un cluster Distributed Cloud connesso, Google aggiorna il tuo software Distributed Cloud connesso 48 ore dopo che l' aggiornamento è stato annunciato tramite le note di rilascio di Distributed Cloud connesso. Nella pagina delle note di rilascio, puoi abbonarti al feed RSS delle note di rilascio di Distributed Cloud connesso per rimanere informato sugli aggiornamenti software man mano che vengono rilasciati.
  • La durata minima di un periodo di manutenzione è di cinque ore. Puoi specificare un periodo più lungo in base alla complessità dell'installazione di Distributed Cloud connesso e ai requisiti aziendali.
  • La frequenza minima degli aggiornamenti software è una volta alla settimana. Puoi specificare periodi di manutenzione settimanali o giornalieri. Puoi includere ed escludere giorni specifici.
  • Puoi modificare la pianificazione del periodo di manutenzione per un cluster in qualsiasi momento, tranne quando è già stato pianificato un periodo di manutenzione o quando è in corso un periodo di manutenzione.
  • Se l'aggiornamento software non viene completato entro il periodo di tempo specificato, viene messo in pausa e riprende durante il periodo di manutenzione pianificato successivo.

Per istruzioni dettagliate, vedi Configurare un periodo di manutenzione per un cluster.

Riparazione dell'hardware non riuscita

Quando Google rileva un guasto dell'hardware Distributed Cloud connesso, eseguiamo una delle seguenti operazioni:

  • Per l'hardware Distributed Cloud di proprietà di Google, Google tenta di pianificare una visita in loco entro tre giorni lavorativi. Affinché un tecnico autorizzato da Google possa eseguire la diagnosi e le riparazioni necessarie, devi concedergli l'accesso all'hardware Distributed Cloud connesso.

  • Per l'hardware Distributed Cloud di proprietà del cliente, Google invia una notifica al cliente e al SI certificato da Google del problema. Devi collaborare con il SI che ha fornito l'hardware Distributed Cloud connesso per pianificare la visita di un tecnico ed eseguire la diagnosi e le riparazioni necessarie.

Se si verifica un guasto dell'hardware Distributed Cloud connesso, si applica uno dei seguenti scenari, a seconda che l'hardware Distributed Cloud connesso utilizzi l'archiviazione SED (Self-Encrypting Disk):

  • I rack Distributed Cloud connessi archiviano i dati su unità non SED. Quando Google o un SI certificato da Google esegue riparazioni in loco, tutte le unità disco vengono rimosse dalla macchina Distributed Cloud connesso interessata prima dell'inizio della manutenzione e vengono affidate alla tua custodia per la durata della riparazione.

  • I server Distributed Cloud connesso archiviano i dati su unità SED. Quando una macchina smette di funzionare, Google o un SI certificato da Google sostituisce l'intera macchina. Prima che la macchina venga rimossa dai tuoi locali, Google si assicura che i tuoi dati siano stati cancellati in modo sicuro da tutte le unità.

Altri punti di errore

Sei responsabile della manutenzione dei seguenti aspetti dell'installazione di Distributed Cloud che non sono sotto il controllo di Google e che possono influire sulla disponibilità di Distributed Cloud connesso:

Passaggi successivi