Descrizione di alta disponibilità e di ripristino di emergenza per Code Engine

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 nonostante 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 delle operazioni di servizio dopo una grave interruzione.

Code Engine è un servizio regionale ad alta disponibilità progettato per mantenere la disponibilità durante le interruzioni zonali. Code Engine soddisfa gli obiettivi di livello di servizio(SLO) con il piano standard.

Per ulteriori informazioni sugli standard di alta disponibilità e disaster recovery in IBM Cloud, vedere Come IBM Cloud garantisce alta disponibilità e ridondanza. Puoi anche trovare informazioni sugli SLA (Service Level Agreement).

Disponibilità delle istanze Code Engine

IBM Cloud® Code Engine è offerto in più sedi (regioni). Ogni regione contiene tre centri dati (zone) per la ridondanza.

Quando esegui il provisioning di un progetto Code Engine, selezioni l'ubicazione (MZR) in cui viene creata l'istanza. La regione determina il luogo in cui vengono ospitati i carichi di lavoro, come applicazioni, lavori, funzioni e flotte.

Per impostazione predefinita, il carico di lavoro viene distribuito in una singola zona. Se la zona di hosting si guasta, il carico di lavoro viene ricreato automaticamente in una delle zone rimanenti.

Il servizio esegue spostamenti controllati del carico di lavoro tra le zone durante le normali operazioni, come la manutenzione del servizio e gli aggiornamenti del software. Questi riavvii del rollout vengono eseguiti con grazia per ridurre al minimo le interruzioni. I failover non pianificati possono verificarsi durante eventi imprevisti nell'ambiente operativo.

Code Engine memorizza i metadati (comprese le definizioni di progetto, app, funzione, lavoro, flotta e build dell'immagine) e li replica in tutte le zone di una regione per garantire la disponibilità. Essendo un servizio di sola elaborazione, Code Engine non è responsabile di garantire l'alta disponibilità dei dati del carico di lavoro o delle immagini dei container. Consultare la documentazione dei rispettivi servizi cloud per avere indicazioni su come garantire l'alta disponibilità. Per la disponibilità delle immagini dei container, seguire le indicazioni riportate in IBM Cloud Container Registry per garantire che il carico di lavoro rimanga operativo durante un'interruzione zonale. Se leggete o memorizzate i dati in IBM Cloud Object Storage o in qualsiasi altro database o servizio di archiviazione di IBM Cloud, fate riferimento alla documentazione di ciascun servizio per le caratteristiche di alta disponibilità.

Code Engine topologia regionale topologia regionale topologia regionale — Code Engine

Regioni Code Engine

La tabella seguente elenca le regioni in cui è disponibile Code Engine e il loro stato di alta disponibilità.

Regioni altamente disponibili Code Engine
Area geografica	Regione	Alta disponibilità
Asia Pacifico	Australia, Sydney (`au-syd`)	MZR
Asia Pacifico	India, Chennai (`in-che`)	MZR
Asia Pacifico	Giappone, Osaka (`jp-osa`)	MZR
Asia Pacifico	Giappone, Tokyo (`jp-tok`)	MZR
Europa	Germania, Francoforte (`eu-de`)	MZR
Europa	Spagna, Madrid (`eu-es`)	MZR
Europa	Regno Unito, Londra (`eu-gb`)	MZR
America del Nord	Canada, Toronto (`ca-tor`)	MZR
America del Nord	Stati Uniti, Dallas (`us-south`)	MZR
America del Nord	Stati Uniti, Washington (`us-east`)	MZR
America del Sud	Brasile, San Paolo (`br-sao`)	MZR

Una geografia è un’area geografica che comprende una o più regioni. Ogni regione comprende diverse zone di disponibilità per soddisfare i requisiti locali in materia di accesso, bassa latenza e sicurezza. Ogni regione multizona(MZR) è composta da 3 o più zone indipendenti, in modo da garantire che un singolo evento di guasto abbia un impatto solo su una zona.

Ripristino di emergenza per istanze Code Engine

In caso di un grave disastro regionale, come un terremoto, un'alluvione o un evento meteorologico di grave entità, può essere colpita un'intera regione. Per garantire la resilienza dei carichi di lavoro a tali eventi, è opportuno distribuirli su più MZR e implementare un meccanismo di failover automatico utilizzando un servizio Edge Proxy. Ad esempio, è possibile utilizzare IBM Cloud® Internet Services. Per ulteriori informazioni sulla distribuzione di un'applicazione in più regioni, vedi Distribuzione di un'applicazione in più regioni con un nome dominio personalizzato.

Code Engine topologia globale topologia globale topologia globale — Code Engine

Come IBM aiuta a garantire il ripristino di emergenza

Backup delle tue istanze Code Engine

IBM Cloud esegue automaticamente il backup dei metadati del progetto Code Engine e li archivia in uno spazio di archiviazione interregionale per scopi di disaster recovery.

Punti finali interregionali
Regione Code Engine	Endpoint interregionale
`au-syd`	`AP`
`br-sao`	`BR`
`ca-tor`	`CA`
`eu-de`	`EU`
`eu-es`	`EU`
`eu-gb`	`EU`
`jp-osa`	`AP`
`jp-tok`	`AP`
`us-east`	`US`
`us-south`	`US`

Per evitare impatti indesiderati sui carichi di lavoro, come la duplicazione di lavori o la distribuzione di istanze di applicazioni non desiderate, Code Engine non ripristina automaticamente i carichi di lavoro. Il ripristino dei carichi di lavoro è una vostra responsabilità. Per ulteriori informazioni, vedi Descrizione delle tue responsabilità quando utilizzi Code Engine.

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

Il Recovery Time Objective (RTO ) è il tempo massimo accettabile in cui un sistema, un'applicazione o un processo aziendale possono rimanere offline prima di causare un impatto aziendale significativo.
Il Recovery Point Objective (RPO ) definisce la quantità massima accettabile di perdita di dati (misurata in tempo) dopo un evento HA o DR.

IBM esegue regolarmente test HA/DR che includono failover HA, scenari DR isolati (esclusi i dati di proprietà del cliente e le definizioni dei carichi di lavoro), ripristino dei dati e simulazione di parametri non tecnici.

Durante questi test vengono misurati e verificati gli obiettivi RTO (tempo di ripristino) e RPO (punto di ripristino).

Obiettivi RTO/RPO
Obiettivo	Destinazione
Failover automatico durante le interruzioni zonali	RTO = secondi, RPO = 0
Disaster Recovery, escluso il recupero di artefatti di proprietà del cliente	RTO = ore, RPO = 1 giorno

Pianificazione del ripristino in caso di disastro

Oltre ai test HA/DR di IBM, è necessario praticare regolarmente le procedure di disaster recovery. Nel costruire il vostro piano, considerate i seguenti scenari di fallimento e le relative soluzioni.

Eventi HA/DR e risoluzione
Evento	Risoluzione
Guasto hardware (infrastruttura di calcolo)	IBM fornisce un'infrastruttura resiliente ai guasti hardware di un singolo punto all'interno di una zona, senza necessità di configurazione.
malfunzionamento zona	Failover automatico (vedere Disponibilità delle istanze di Code Engine ). Il carico di lavoro viene spostato automaticamente in una zona disponibile.
Dati danneggiati	L'utente è responsabile della creazione di backup dei propri dati.
Fallimento regionale	Nessun failover automatico. Come descritto in Disaster Recovery per le istanze Code Engine, è necessario distribuire il carico di lavoro in una seconda regione multizona.
Disponibilità del carico di lavoro	L'utente è responsabile dell'implementazione delle applicazioni aziendali per il recupero dello stato da archivi o database esterni.
Resilienza HA/DR	Il cliente ha la responsabilità di garantire la disponibilità di personale qualificato per la gestione dei componenti e il ripristino dei carichi di lavoro e dei dati di proprietà del cliente durante un'interruzione.

Le vostre responsabilità per HA e DR

Utilizzate le seguenti liste di controllo associate a ciascuna caratteristica per aiutarvi a creare e mettere in pratica il vostro piano.

Immagini di container utilizzate per applicazioni, lavori e flotte di IBM Cloud® Code Engine

Verificare che le immagini del container siano disponibili nella regione di backup IBM Cloud Container Registry.
Basi di codice utilizzate per le funzioni di IBM Cloud® Code Engine

Verificare che i bundle di codice siano disponibili nella regione di backup IBM Cloud Container Registry.

Un piano di test completo per l'alta disponibilità (HA) e il disaster recovery (DR) comprende la definizione degli obiettivi RTO e RPO, l'identificazione dei sistemi critici e la convalida dell'integrità dei backup, del failover di rete e della sincronizzazione dei dati. Le fasi principali prevedono la simulazione di guasti (come il guasto di un nodo o l'interruzione di un sito), l'esecuzione di procedure di failover, la verifica della funzionalità del sistema e la documentazione del processo di fallback.

Preparazione del test
- Definire gli obiettivi: Confermare il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO).
- Identificare i sistemi critici: Elencare tutti i sistemi, i dati e le applicazioni che richiedono il failover.
- Stabilire i ruoli del team: Definire le responsabilità del team DR e assegnare un referente chiave.
- Verifica dei backup: Conferma che i backup sono validi e accessibili.
- Isolamento dell'ambiente: Isolare i sistemi di test per evitare impatti accidentali sugli ambienti di produzione.
Esecuzione del test
- Simulare uno scenario di guasto: avviare un guasto pianificato, come l'interruzione della connettività di rete, l'arresto di un servizio o lo spegnimento di un server primario.
- Esecuzione del failover: Eseguire la procedura di failover documentata verso il sito secondario/DR.
- Verificare l'integrità dei dati: Utilizzare checksum o valori hash per garantire che i dati non siano danneggiati.
- Convalida delle applicazioni: Testare la funzionalità delle applicazioni sul sito DR.
- Reindirizzamento DNS/Traffico: Verificare che il traffico degli utenti sia reindirizzato al nuovo nodo attivo.
Post-test e documentazione
- Eseguire il failback: Riportare in linea il sito primario e risincronizzare i dati.
- Documentare i risultati: Registrare i tempi, i successi e le eventuali deviazioni dal piano.
- Identificare le lacune: Individuare le carenze del piano e aggiornare le procedure di conseguenza.
- Audit della comunicazione: Verificare che le notifiche siano state inviate a tutte le parti interessate.
Scenari di test comuni
- Test HA: Failover locale su un nodo di standby (ad esempio, all'interno dello stesso data center).
- Test DR: Failover completo verso una sede geograficamente separata.
- Ripristino dei dati: Ripristino completo dei dati e degli artefatti del carico di lavoro di proprietà del cliente da un datastore di backup alla posizione di backup primaria o selezionata.
- Disponibilità del personale: Verificate l'impatto operativo se il personale chiave non è disponibile o non può collegarsi ai vostri sistemi.