Architettura ad alta disponibilità

IBM Cloud® Databases for PostgreSQL controlla la distribuzione delle richieste tra i membri di postgres, come descritto in Alta disponibilità per PostgreSQL

Una zona di disponibilità è un luogo logicamente e fisicamente isolato all'interno di una regione IBM Cloud in cui i dati vengono elaborati e ospitati.

• Una zona di disponibilità dispone di infrastrutture di alimentazione, raffreddamento e rete indipendenti, isolate dalle altre zone per rafforzare la tolleranza ai guasti evitando singoli punti di guasto tra le zone.
• Una zona di disponibilità offre una larghezza di banda elevata e una bassa latenza tra le zone all'interno di una regione.

Una regione (sede) è un gruppo geograficamente e fisicamente separato di una o più zone di disponibilità con infrastrutture elettriche e di rete indipendenti e isolate da altre regioni.

• Le regioni sono progettate per eliminare i singoli punti di guasto condivisi con altre regioni e garantire una bassa latenza interzona all'interno della regione.
• Ogni regione dispone di 3 diversi data center (DC) a scopo di ridondanza.

Zone di disponibilità

Activity Tracker Event Routing è un servizio regionale ad alta disponibilità.

• Activity Tracker Event Routing è disponibile in più regioni. Per ulteriori informazioni sulle regioni in cui è disponibile Activity Tracker Event Routing, vedere Regioni.
• Ogni regione multizona dispone di tre diversi data center per la ridondanza configurati in modalità active/active.
• Se si verifica un malfunzionamento di tutti i data center in un'ubicazione, Activity Tracker Event Routing diventa indisponibile in tale ubicazione.
• In ciascuna regione supportata, il traffico viene bilanciato tra le infrastrutture distribuite in più zone di disponibilità, senza alcun singolo punto di guasto.

Per ulteriori informazioni sulla disponibilità dei servizi, consultare gli Accordi sul livello di servizio(SLA).

La tabella seguente elenca lo stato di alta disponibilità (HA) per le regioni (sedi) in cui è disponibile il servizio IBM Cloud Activity Tracker Event Routing:

Elenco delle località in cui il servizio è disponibile

Area geografica	Regione	Supportato dall'UE	Stato HA
Asia Pacifico	Chennai (in-che)	N/A	SZR
Asia Pacifico	Mumbai (in-mum)	N/A	SZR
Asia Pacifico	Osaka (jp-osa)	N/A	MZR
Asia Pacifico	Sydney (au-syd)	N/A	MZR
Asia Pacifico	Tokyo (jp-tok)	N/A	MZR
Europa	Francoforte (eu-de)		MZR
Europa	Londra (eu-gb)	N/A	MZR
Europa	Madrid (eu-es)		MZR
America del Nord	Dallas (us-south)	N/A	MZR
America del Nord	Montreal (ca-mon)	N/A	MZR
America del Nord	Toronto (ca-tor)	N/A	MZR
America del Nord	Washington (us-east)	N/A	MZR
America del Sud	San Paolo (br-sao)	N/A	MZR

Dove

• Una geografia è un'area geografica o un organismo politico più grande che contiene una o più regioni.

• Una regione è un territorio geografico definito.

  Una regione può essere una specifica area identificata da un codice postale, una città, uno stato, un gruppo di stati o un gruppo di nazioni.

  Una regione comprende più zone di disponibilità per soddisfare i requisiti di accesso locale, bassa latenza e sicurezza della regione stessa.

• N/A significa che la funzione non è applicabile a quella geografia.

• MZR significa regione multizona. Ulteriori informazioni.

Architettura di disaster recovery

IBM Cloud® Databases for PostgreSQL controlla la distribuzione delle richieste tra i membri di postgres, come descritto in Alta disponibilità per PostgreSQL

IBM Cloud Object Storage gestisce i geobuet utilizzati per memorizzare i backup di postgres per IBM Cloud Activity Tracker Event Routing. La gestione dei bucket di geolocalizzazione è descritta in Alta disponibilità per IBM Cloud Object Storage

Guasto di una singola zona

IBM Cloud Activity Tracker Event Routing è HA e può continuare a funzionare anche in caso di guasto di una singola zona o macchina macchina.

Fallimento regionale

Activity Tracker Event Routing è un servizio di piattaforma. Non esiste un failover interregionale automatico o un disaster recovery interregionale. Se tutte le zone di disponibilità di una regione si guastano, Activity Tracker Event Routing diventa non disponibile in quella regione.

Le vostre responsabilità per HA e DR

Il ripristino di emergenza riguarda il superare un errore catastrofico o la perdita di disponibilità in una singola ubicazione.

Activity Tracker Event Routing è un servizio di piattaforma. Non esiste un failover interregionale automatico o un disaster recovery interregionale. Se tutte le zone di disponibilità di una regione si guastano, Activity Tracker Event Routing diventa non disponibile in quella posizione.

È possibile creare una configurazione per instradare verso una destinazione di backup in una regione diversa.

In caso di disastro regionale, è necessario completare i seguenti passaggi per stabilire l'alta disponibilità interregionale:

1. Decidete quale sarà la vostra zona di recupero. Scegli una delle seguenti opzioni:

   • Controllare l'area di ripristino DR suggerita e utilizzarla come area di ripristino.

   • Se le impostazioni dell'account Activity Tracker Event Routing sono state configurate con una posizione primaria e una posizione di backup secondaria, verificare se una delle due posizioni è ancora operativa e utilizzarne una come area di ripristino.

   • Se le impostazioni dell'account Activity Tracker Event Routing sono state configurate solo con una sede primaria e questa sede è inattiva, controllare le regioni supportate da Activity Tracker Event Routing e scegliere una regione attiva come regione di ripristino.

2. È possibile definire i target solo nelle regioni supportate da Activity Tracker Event Routing. Tuttavia, l'obiettivo effettivo può essere disponibile in una regione diversa e continuare a essere operativo. Innanzitutto, è necessario verificare la disponibilità dell'obiettivo. Scegliere quindi una delle seguenti opzioni:

   • Se una destinazione è disponibile in una regione diversa da quella inattiva e la regione di ripristino scelta è quella configurata nelle impostazioni dell'account Activity Tracker Event Routing, la posizione primaria e la posizione secondaria di backup includono i dettagli della destinazione. È possibile continuare a controllare i percorsi definiti nell'account per assicurarsi che gli eventi siano instradati verso la destinazione.

   • Se un target è disponibile in una regione diversa da quella inattiva e la regione di ripristino scelta non è una regione configurata nelle impostazioni dell'account Activity Tracker Event Routing, è necessario configurare il target in qualsiasi regione supportata da Activity Tracker Event Routing che sia disponibile, preferibilmente nella regione scelta come regione di ripristino. Successivamente, è necessario controllare le rotte definite nell'account, in modo che gli eventi vengano instradati verso la nuova destinazione configurata.

   • Se il target non è disponibile, è necessario seguire il processo di recupero DR di quel tipo di target e approvvigionarne uno nuovo nella regione di recupero scelta. È necessario configurare la destinazione in qualsiasi regione supportata da Activity Tracker Event Routing che sia disponibile, preferibilmente nella regione scelta come regione di ripristino. Successivamente, è necessario controllare le rotte definite nell'account, in modo che gli eventi vengano instradati verso la nuova destinazione configurata.

3. Si definiscono i percorsi per indicare come gli eventi vengono instradati verso i target configurati nell'account. Questi percorsi sono globali e non sono legati a una regione specifica. Pertanto, nel caso di uno scenario DR, è necessario verificare che tutti i target configurati siano operativi e che le regole si applichino ai target e alle sedi operative.

   Se la regione che si è guastata sta raccogliendo anche eventi globali nell'account, è necessario aggiornare il percorso nella regione di ripristino per raccogliere gli eventi globali.

Quando Activity Tracker Event Routing si ripristina nella regione inattiva, la configurazione viene ripristinata. Completare i seguenti passaggi per continuare a operare nella regione che si è interrotta:

1. È necessario verificare che anche gli eventuali target esistenti in quella regione siano recuperati e funzionanti.
2. Se si è abilitata la raccolta degli eventi di auditing globale nell'area di recupero, è necessario aggiornare il percorso per interrompere gli eventi globali in quell'area.
3. Se sono stati configurati nuovi target, è possibile aggiornare la configurazione per tornare a utilizzare i target che si sono interrotti. Si può anche decidere di continuare a usare i target abilitati nell'area di ripristino.

Per saperne di più sulla responsabilità tra l'utente e IBM Cloud per l'utilizzo di IBM Cloud Activity Tracker Event Routing, vedere Comprendere le proprie responsabilità nell'utilizzo di IBM Cloud Activity Tracker Event Routing.

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

La tabella seguente indica i tempi di ripristino stimati in caso di situazione di DR:

Gestione delle modifiche

La gestione delle modifiche comprende attività quali aggiornamenti, modifiche alla configurazione ed eliminazioni.

Si consiglia di assegnare agli utenti e ai processi i ruoli e le azioni IAM con i privilegi minimi richiesti per il loro lavoro. Vedere Come posso evitare la cancellazione accidentale dei servizi?

Come IBM® supporta la pianificazione del disaster recovery

• IBM® conduce test annuali su vari scenari di disastro e perfeziona continuamente la documentazione di ripristino in base ai risultati ottenuti durante questi test.

• i clienti hanno a disposizione un'assistenza globale 24 ore su 24, 7 giorni su 7, con esperti di materia IBM® pronti a intervenire in caso di disastro.

  Tutti i Subject Matter Expert di IBM® ricevono una formazione annuale sulle politiche e le procedure di business continuity e disaster recovery per garantire la preparazione in caso di disastro.

I metadati gestiti da Activity Tracker Event Routing in una regione sono conservati nei data center vicini a quella regione.

Una regione multizona (MZR) è costituita da 3 o più zone di disponibilità indipendenti l'una dall'altra per garantire che singoli eventi di guasto interessino solo una singola zona.

Per impostazione predefinita, Activity Tracker Event Routing è distribuito in 3 zone. Ogni zona è configurata con active/active/active:

• Ogni zona è situata in un diverso centro dati della regione.
• Gli eventi inviati al servizio vengono replicati automaticamente alle altre zone con una bassa latenza. Non devi fare nulla per abilitare la replica.
• Il servizio è progettato per resistere a un guasto di una singola zona senza interruzioni.

L'architettura MZR offre il failover automatico tra le zone all'interno della regione e l'alta disponibilità per un'istanza di auditing all'interno di una regione.

Activity Tracker Event Routing i metadati includono informazioni su dove e come raccogliere e memorizzare gli eventi di auditing nel vostro account per i servizi regionali e per i servizi globali come IAM.

• Un target è una risorsa in cui è possibile raccogliere eventi di auditing.
• Un percorso è una risorsa che definisce le regole che determinano l'instradamento degli eventi di auditing nell'account.

Activity Tracker Event Routing esegue backup regolari dei metadati per regione:

• I backup regolari vengono eseguiti quotidianamente e conservati per 30 giorni.
• I backup incrementali continui vengono conservati per gli ultimi 7 giorni.

Activity Tracker Event Routing i metadati sono replicati in più regioni.

• I backup regolari vengono archiviati in più regioni e sono ripristinabili in altre regioni.

La tabella seguente mostra le regioni in cui la copia di un backup regolare è replicata e disponibile:

Per ulteriori informazioni sulla disponibilità dei servizi all'interno delle regioni e dei data center, vedere Disponibilità dei servizi e dell'infrastruttura per località.

La tabella seguente indica la regione di ripristino in caso di situazione di DR:

Come IBM mantiene i servizi

Tutti gli aggiornamenti seguono le best practice del servizio IBM e prevedono un piano di ripristino e un processo di rollback. Gli aggiornamenti regolari per le nuove funzionalità e la manutenzione fanno parte delle normali operazioni. Tale manutenzione può occasionalmente causare brevi intervalli di interruzione che vengono gestiti dalla logica di riprova della disponibilità del client. Le modifiche vengono distribuite in modo sequenziale, regione per regione e zona per zona all'interno di una stessa regione. Gli aggiornamenti vengono annullati al primo segno di difetto.

Le modifiche complesse vengono attivate e disattivate con flag di funzione per controllare l'esposizione.

Le modifiche che hanno un impatto sui carichi di lavoro dei clienti sono dettagliate nelle notifiche. Per ulteriori informazioni, consultare le notifiche e lo stato di monitoraggio della manutenzione programmata, gli annunci e le note di rilascio che hanno un impatto su questo servizio.