Descrizione di alta disponibilità e di ripristino di emergenza per Red Hat OpenShift on IBM Cloud

L' alta disponibilitàLa capacità di un servizio o di un carico di lavoro di resistere ai guasti e di continuare a fornire capacità di elaborazione secondo un livello di servizio predefinito. (HA) è la capacità di un servizio di rimanere operativo e accessibile in presenza di guasti imprevisti. Il disaster recoveryLa capacità di un servizio o di un carico di lavoro di riprendersi da incidenti rari e gravi e da guasti su larga scala, come l'interruzione del servizio. Ciò include un disastro fisico che colpisce un'intera regione, il danneggiamento di un database o la perdita di un servizio che contribuisce a un carico di lavoro. L'impatto supera la capacità del progetto di alta disponibilità di gestirlo. è il processo di ripristino dell'istanza di servizio in uno stato funzionante.

Red Hat OpenShift on IBM Cloud è un servizio regionale o zonale ad alta disponibilità progettato per essere disponibile durante un'interruzione regionale o zonale. Red Hat OpenShift on IBM Cloud è progettato per soddisfare gli obiettivi di livello di servizio (SLO) con il piano standard.

Per ulteriori informazioni sulle regioni e le sedi dei data center disponibili, consultare Disponibilità di servizi e infrastrutture per località.

Architettura ad alta disponibilità

Red Hat OpenShift on IBM Cloud architettura crea un'elevata disponibilità a livello regionale, di zona e di cluster.

Disponibilità regione: Ogni regione è configurata con un programma di bilanciamento del carico altamente disponibile accessibile dall'endpoint API specifico della regione. Il programma di bilanciamento del carico instrada le richieste in entrata e in uscita ai cluster nelle zone regionali. La probabilità di un malfunzionamento a livello dell'intera regione è bassa. Tuttavia, per tenere conto di questo malfunzionamento, puoi configurare più cluster in regioni diverse e collegarli utilizzando un programma di bilanciamento del carico esterno. Se un'intera regione si guasta, il cluster dell'altra regione può assumere il carico di lavoro.
Disponibilità di cluster e zone: Un malfunzionamento della zona riguarda tutti gli host di calcolo fisici e l'archiviazione NFS. I malfunzionamenti includono interruzioni di alimentazione, raffreddamento, collegamento in rete o di archiviazione e disastri naturali, come inondazioni, terremoti e uragani. Per proteggerti da un malfunzionamento della zona, devi disporre di cluster in due ubicazioni diverse il cui carico viene bilanciato dal programma di bilanciamento del carico esterno. Creare un cluster in una posizione multizona, che distribuisce il master nelle varie zone. Oppure, si può considerare l'installazione di un secondo cluster in un'altra zona.
Disponibilità multizona: I cluster multizona distribuiscono i carichi di lavoro su più nodi e zone di lavoro, creando una protezione aggiuntiva contro i guasti di zona. I nodi operatore vengono distribuiti automaticamente con tre repliche distribuite su più zone. Se un'intera zona subisce un'interruzione, il carico di lavoro viene riprogrammato sui nodi dei lavoratori nelle altre zone, proteggendo l'applicazione dall'interruzione.
Bilanciamento del carico globale: Per proteggere l'applicazione da un guasto del master o per i cluster classici che devono risiedere in una delle regioni multizona supportate, è possibile creare più cluster in zone diverse all'interno di una regione e collegarli con un bilanciatore di carico globale.

Distribuzione delle risorse per un'elevata disponibilità.

I tuoi utenti hanno meno probabilità di riscontrare tempi di inattività quando distribuisci le tue applicazioni tra più nodi di lavoro, zone e cluster. Le funzionalità integrate, come il bilanciamento del carico e l'isolamento, aumentano la resilienza nei confronti di potenziali errori con host, reti o applicazioni. Rivedi la configurazione di questi cluster potenziali ordinati per gradi di disponibilità. Per ulteriori informazioni su come le risorse dell' IBM Cloud e sono distribuite tra zone geografiche e regioni, consultare la documentazione sulle sedi.

Cluster a zona singola: Solo classico; I cluster a zona singola hanno nodi operatore distribuiti su host fisici separati all'interno della stessa zona. Questa opzione protegge da determinate interruzioni, ad esempio durante un aggiornamento principale, ed è più semplice da gestire. Tuttavia, non protegge le tue app se un'intera zona subisce un'interruzione.
Gruppi multizona: Classico VPC; I cluster multizona dispiegano automaticamente nodi operatore con tre repliche distribuite su più zone. Se un'intera zona subisce un'interruzione, il carico di lavoro viene riprogrammato sui nodi dei lavoratori nelle altre zone, proteggendo l'applicazione dall'interruzione.
Gruppi multipli collegati con bilanciatori di carico: Classico VPC; È possibile configurare più cluster nella stessa zona o in zone diverse e collegarli tramite un bilanciatore di carico globale. Questa opzione è utile se si deve fornire un cluster in una singola regione di zona, ma si desiderano comunque i vantaggi della disponibilità multizona.

Funzioni ad alta disponibilità

Esamina le funzionalità a tua disposizione per fornire un'elevata disponibilità per le tue app e i tuoi servizi.

Caratteristiche HA per Red Hat OpenShift on IBM Cloud
Funzione	Descrizione
Opzioni anti-affinità	Utilizzare le regole anti-affinità per distribuire lo spiegamento dei pod tra i nodi dei lavoratori invece di limitarlo a nodi specifici. Ciò offre ulteriore flessibilità per il carico di lavoro.
Serie di repliche	Per aumentare la disponibilità della tua applicazione, puoi specificare una serie di repliche nella tua distribuzione. Se un'istanza dell'applicazione si interrompe, Kubernetes avvia automaticamente una nuova istanza per mantenere il numero specificato di istanze dell'applicazione.
Bilanciamento del carico multizona (Classic)	Quando si crea un cluster classico multizona, viene creato automaticamente un bilanciatore di carico multizona in ogni zona in cui risiede il cluster per gestire tutte le richieste in arrivo alle applicazioni e bilanciare il carico tra i bilanciatori di carico delle applicazioni (ALB) nelle zone del cluster. Abilita anche i controlli dell'integrità per gli indirizzi IP Ingress pubblici.
Bilanciamento del carico VPC (VPC)	Quando si crea un cluster VPC, viene creato automaticamente un bilanciatore del carico VPC per gestire tutte le richieste in entrata alle applicazioni e bilanciare il carico delle richieste tra i bilanciatori del carico delle applicazioni (ALB) nelle zone del cluster. Abilita anche i controlli dell'integrità per gli indirizzi IP Ingress pubblici.
Cluster autoscaler	Il componente aggiuntivo cluster autoscaler scala automaticamente i pool di worker nel cluster per aumentare o diminuire il numero di nodi worker nel pool in base alle esigenze di dimensionamento dei carichi di lavoro pianificati.

Funzioni di ripristino in caso di emergenza

La strategia generale per il disaster recovery consiste nel configurare l'archiviazione e il backup dei dati con soluzioni come Portworx.

Red Hat OpenShift on IBM Cloud supporta le seguenti funzioni di disaster recovery:

Caratteristiche DR per Red Hat OpenShift on IBM Cloud
Funzione	Descrizione
Portworx	Una soluzione di storage software-defined di terze parti, altamente disponibile, che si può usare per gestire lo storage persistente locale per i database containerizzati e altre applicazioni stateful, o per condividere i dati tra i pod in più zone. Rivedere i prerequisiti
OpenShift Data Foundation(ODF)Ripristino regionale in caso di disastro	Una soluzione di disaster recovery che fornisce un ripristino automatico "con un solo clic" in caso di disastro regionale. Le applicazioni vengono automaticamente ridistribuite a un' OpenShift Container Platform e designata con un cluster ODF disponibile in un'altra regione.
COS (Cloud Object Storage)	Un'opzione di archiviazione persistente e altamente disponibile che si monta sulle tue app, disponibile come plug-in. Rivedere i limiti.
Autoripristino	Il sistema Autorecovery utilizza vari controlli per interrogare lo stato di integrità dei nodi di lavoro. Se Autorecovery rileva un nodo worker non funzionante in base ai controlli configurati, attiva un'azione correttiva come il riavvio di un nodo worker VPC o il ricaricamento del sistema operativo in un nodo worker classico.
Portabilità dei dati con Velero	Un'opzione di terze parti per esportare i dati dal cluster a un'istanza di COS ( IBM ) o a un altro provider di servizi cloud ( s3 ).
Portabilità dei dati tramite l'interfaccia di linea di comando(`kubectl`, CLI)	Esportare i dati utilizzando l'interfaccia della riga di comando ( `kubectl`, CLI).

Esaminare altre opzioni per l'esportazione dei dati, come rclone o OADP.

Obiettivo tempo di ripristino (RTO) e obiettivo punto di ripristino (RPO)

Caratteristiche RTO/RPO per Red Hat OpenShift on IBM Cloud
Funzione	RTO e RPO	Considerazioni
Portworx	RTO = RPO ( <60s ), RPO = ( <60s )- 15m	I valori differiscono tra configurazioni asincrone o sincrone (note anche come Metro DR). Per ulteriori informazioni, vedere Impostazione del ripristino di emergenza con l' Portworx.
ODF Recupero regionale in caso di disastro	RTO = 0, RPO = 0	Questi valori si applicano solo a livello di cluster. La registrazione regionale e metropolitana non è attualmente disponibile.
Cloud Object Storage	Vedere i documenti di archiviazione degli oggetti.

Come l' IBM® a aiuta a garantire il ripristino di emergenza

IBM® adotta specifiche azioni di recupero per l' Red Hat OpenShift on IBM Cloud, in caso di disastro.

Come si riprende da un guasto un IBM

In caso di guasto di una zona o di una regione, IBM è responsabile del recupero dei componenti. IBM tenterà di ripristinare il cluster nella stessa regione in base all'ultimo stato nella memoria interna persistente. IBM aggiorna e recupera i componenti operativi del cluster, come il bilanciatore di carico dell'applicazione Ingress e il plug-in di archiviazione dei file.

IBM offre anche la possibilità di integrarsi con altri servizi di IBM Cloud, come i provider di archiviazione, in modo da poter eseguire il backup e il ripristino dei dati. È tua responsabilità implementare queste integrazioni.

Come l' IBM e mantiene i servizi

Tutti gli aggiornamenti seguono le migliori pratiche di serviz IBM, compresi i piani di ripristino e i processi di rollback. La manutenzione regolare potrebbe causare brevi interruzioni, mitigate dalla logica di riprova della disponibilità del cliente. Le modifiche vengono introdotte in modo sequenziale, regione per regione e zona per zona all'interno di una regione. IBM ripristina gli aggiornamenti al primo segno di un difetto.

Le modifiche complesse vengono abilitate e disabilitate con flag di funzionalità per controllare l'esposizione.

I cambiamenti che hanno un impatto sul carico di lavoro dei clienti sono dettagliati nelle notific IBM Cloud. Per ulteriori informazioni sulla manutenzione programmata, gli annunci e le note di rilascio che riguardano questo servizio, vedere Monitoraggio delle notifiche e dello stato.

Le vostre responsabilità per l'alta disponibilità e il disaster recovery

È tua responsabilità testare continuamente il tuo piano per HA e DR.

Potrebbero verificarsi interruzioni nella connettività di rete e brevi periodi di indisponibilità di un servizio. È responsabilità dell'utente assicurarsi che il codice sorgente dell'applicazione includa la logica di riprova della disponibilità del client per mantenere un'elevata disponibilità dell'applicazione.

Sei responsabile della configurazione del tuo cluster per ottenere il livello appropriato di disponibilità per le tue applicazioni e i tuoi servizi. Il livello di disponibilità impostato per il cluster influisce sulla copertura dei termini dell'accordo sul livello di servizio IBM Cloud HA. Ad esempio, per ricevere una copertura HA completa secondo i termini dello SLA, è necessario impostare un cluster multizona con un totale di almeno 6 nodi worker, due nodi worker per zona distribuiti uniformemente in tre zone.

Sei responsabile del ripristino dei carichi di lavoro che eseguono il cluster e i tuoi dati dell'applicazione. Per ulteriori informazioni sulle responsabilità dell'utente per il ripristino d'emergenza, vedere Responsabilità dell'utente nell'uso di Red Hat OpenShift on IBM Cloud.

Gestione delle modifiche

La gestione delle modifiche comprende attività quali aggiornamenti, modifiche alla configurazione e cancellazioni. Tieni a mente i seguenti punti per ridurre i tempi di inattività o la perdita di dati per il tuo carico di lavoro.

Si raccomanda di assegnare agli utenti e ai processi i ruoli e le azioni IAM con il minor numero di privilegi necessari per il loro lavoro. Ad esempio, limitare la possibilità di eliminare le risorse di produzione.
Utilizzare l'API, la CLI o gli strumenti della console per applicare gli aggiornamenti dei nodi worker forniti, che includono le patch del sistema operativo, o per richiedere il riavvio, il ricarico o la sostituzione dei nodi worker.
Utilizzare l'API, la CLI o gli strumenti della console per applicare le major e minor Kubernetes aggiornamenti master e major, minor e aggiornamenti del nodo worker patch. Assicurati di rivedere le informazioni e i requisiti per ogni aggiornamento della versione per evitare problemi o tempi di inattività.
Assicurarsi che i nodi worker del cluster eseguano la versione più recente Ubuntu versione.
Assicurati di comprendere i programmi di rilascio per eventuali componenti aggiuntivi che esegui nel tuo cluster.

Considerazioni per l'implementazione di app e servizi

Il modo in cui configuri il cluster influisce sul livello di disponibilità che ottieni per le tue app e i tuoi servizi. Più ampiamente distribuisci la tua configurazione su più nodi di lavoro e cluster, meno è probabile che i tuoi utenti riscontrino tempi di inattività con la tua applicazione.

Rivedi queste potenziali configurazioni delle applicazioni ordinate con diversi gradi di disponibilità.

Un'installazione con n+2 pod gestiti da un set di repliche su un singolo nodo.
Una distribuzione con n+2 pod gestiti da una serie di repliche ed distribuiti a più nodi (anti-affinità) in un cluster a zona singola.
Una distribuzione con n+2 pod gestiti da una serie di repliche ed distribuiti a più nodi (anti-affinità) in un cluster multizona tra zone.

Per informazioni sulla creazione di un carico di lavoro altamente disponibile, consultare la seguente documentazione.