Descrizione di alta disponibilità e di ripristino di emergenza per IBM Cloud Logs

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. Per i servizi, la disponibilità è definita nell'Accordo sul livello dei servizi. La disponibilità comprende sia gli eventi pianificati che quelli non pianificati, come manutenzione, guasti e disastri. (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.

IBM Cloud Logs è un servizio regionale multi-tenant ad alta disponibilità e puoi trovare le regioni e le sedi dei data center disponibili nella documentazione delle sedi. IBM Cloud Logs, in quanto servizio regionale, soddisfa gli obiettivi di livello di servizio(SLO ) definiti con il piano Standard. L'SLO non è una garanzia e IBM non emetterà crediti per il mancato raggiungimento di un obiettivo.

Gli obiettivi di livello di servizio (SLO) descrivono i punti di progettazione che i servizi dell' IBM Cloud e sono progettati per soddisfare. L' IBM Cloud Logs e è progettato per raggiungere il seguente obiettivo di disponibilità.

SLO per IBM Cloud Logs
Obiettivo di disponibilità	Valore obiettivo
Disponibilità %	99.99%

Architettura ad alta disponibilità

Una zona di disponibilità è una posizione logicamente e fisicamente isolata all'interno di una regione dell' IBM Cloud, dove i dati vengono elaborati e ospitati.

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

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

Le regioni sono progettate per eliminare i singoli punti di errore condivisi con altre regioni e garantire una bassa latenza tra le zone all'interno della regione.
Ogni regione dispone di 3 diversi centri dati (DC) per la ridondanza.

Funzioni ad alta disponibilità

IBM Cloud Logs supporta le seguenti funzioni ad alta disponibilità:

Caratteristiche HA per IBM Cloud Logs
Funzione	Descrizione
Distribuzione multizona	IBM Cloud Logs viene distribuito solo nelle regioni multizona (MZR) e, all'interno di una MZR, il cluster del piano dati si estende a tutte e tre le zone, garantendo che la perdita di una zona non influisca sulla disponibilità del servizio.
IBM Cloud Logs riproduzione delle risorse tra le zone	Tutte le risorse dell' IBM Cloud Logs, come avvisi, metriche e registri, sono replicate in tre zone all'interno degli MZR. In questo modo si garantisce che i dati vengano conservati in caso di perdita di zona.
Monitoraggio del funzionamento/prontezza	Tutti i microservizi sono monitorati tramite sonde di vitalità e prontezza ( Kubernetes ).

Architettura di disaster recovery

IBM Cloud Logs è basato su un Red Hat OpenShift on IBM Cloud e su VPC che utilizza regioni multizona e distribuisce tutti i nodi dei lavoratori su tre zone. I bilanciatori di carico VPC elaborano il traffico in entrata e lo inoltrano alla rete di servizi in esecuzione nel cluster.

Non esiste un failover interregionale automatico o un disaster recovery interregionale. Se tutte le zone di disponibilità in una regione non funzionano, l' IBM Cloud Logs a non sarà disponibile in quella regione.

Funzioni di ripristino in caso di emergenza

IBM Cloud Logs supporta le seguenti funzioni di disaster recovery:

Funzioni DR per IBM Cloud Logs
Funzione	Descrizione
Regione alternativa	È possibile utilizzare il servizio in esecuzione su una regione alternativa, separatamente dal servizio principale
Backup dei database	Una copia del set di dati corrente è memorizzata

Pianificazione per DR

I passi del DR devono essere praticati regolarmente. Mentre costruisci il tuo piano, considera i seguenti scenari di guasto e le relative soluzioni.

Scenari di DR per IBM Cloud Logs
Operazione non riuscita	Risoluzione
Guasto hardware (singolo punto)	IBM fornisce un database resistente a un singolo punto di guasto hardware all'interno di una zona, senza necessità di configurazione.
malfunzionamento zona	IBM Cloud Logs utilizza un'implementazione regionale multizona che è resiliente da un punto di guasto della zona.
Dati danneggiati	In caso di corruzione dei dati, il database verrà riportato all'ultimo stato stabile disponibile nel sito di backup. Per il ripristino utilizziamo backup di tipo " IBM Cloud Object Storage ", vedi Backup
Guasto regionale	Seguire i passaggi indicati in Le tue responsabilità per HA e DR

Le tue responsabilità per HA e DR

IBM Cloud dispone di piani di continuità operativaLa capacità di un'azienda di resistere alle interruzioni e di gestire i servizi mission-critical normalmente e senza interruzioni in conformità con gli SLA (service - level agreement) predefiniti. per garantire il ripristino dei servizi entro poche ore in caso di disastro. Sei responsabile del backup dei tuoi dati e del relativo ripristino dei tuoi contenuti.

In caso di grave catastrofe regionale, come un terremoto, un'inondazione o un tornado, l'intera regione potrebbe essere colpita.

Per recuperare un'istanza di IBM Cloud Logs, è necessario fornire una nuova istanza di IBM Cloud Logs e ricreare le risorse di IBM Cloud Logs. Devi anche avere una strategia DR per i bucket dell' IBM Cloud Object Storage, associati all'istanza, e l'istanza dell' IBM Cloud Event Notifications, che potresti aver configurato per attivare avvisi di notifica.

Per garantire che i carichi di lavoro siano resilienti a tali eventi, completare i seguenti passaggi:

Definire la strategia regionale per ripristinare la configurazione non funzionante.

Controlla la località dei dati e i requisiti di conformità quando scegli la regione di ripristino.

Per ulteriori informazioni sulle sedi, vedere:
- IBM Cloud Logs regioni supportate
- IBM Cloud Object Storage regioni supportate
- IBM Cloud Event Notifications regioni supportate. IBM Cloud Event Notifications non è supportato in tutte le regioni in cui è supportato IBM Cloud Logs.
Se si dispone di configurazioni che non utilizzano Terraform, eseguire il backup delle configurazioni correnti utilizzando l'API. Se utilizzi Terraform, salva i tuoi script Terraform per aiutarti a ricreare la regione che è inattiva. Considera l'utilizzo di un sistema di controllo delle versioni per archiviare i file di backup o gli script Terraform.

È possibile utilizzare Terraform per creare istanz IBM Cloud Logs. Vedi Gestione delle risorse Terraformare le risorse.

È possibile utilizzare Terraform per creare le risorse dell' IBM Cloud Logs. Vedere IBM Cloud Logs Risorse Terraform.

Puoi utilizzare Terraform per creare il tuo bucket di dati, il tuo bucket di metriche o entrambi, con resilienza Cross Region per archiviare e accedere ai dati in più regioni geografiche e garantire alta disponibilità, durata e capacità di disaster recovery. Vedere IBM Cloud Object Storage Risorse Terraform.

Puoi utilizzare Terraform per creare le tue risorse di configurazione ( IBM Cloud Event Notifications ). Vedere IBM Cloud Event Notifications Risorse Terraform.

Puoi utilizzare Terraform per creare le tue autorizzazioni e permessi IAM. Vedi le risorse IAM Terraform.

Verifica sempre che sia possibile ripristinare la configurazione di backup in un'area alternativa.

In caso di disastro regionale, è necessario completare i seguenti passaggi per recuperare la propria istanza in una nuova regione:

Identificare una regione alternativa in cui ripristinare l'istanza di IBM Cloud Logs.
Creare la nuova istanza di IBM Cloud Logs. Per ulteriori informazioni, vedi Provisioning di un'istanza.
Se l'istanza dispone di bucket di dati o metriche configurati, completare i seguenti passaggi:
- Se l'istanza di IBM Cloud Logs nella regione colpita dal disastro utilizzava un bucket Cross Region IBM Cloud Object Storage (COS), è possibile collegare lo stesso bucket alla nuova istanza di IBM Cloud Logs, ma non è possibile interrogare i dati creati sull'istanza di IBM Cloud Logs nella regione colpita dal disastro utilizzando i dashboard o la CLI della nuova istanza di IBM Cloud Logs. Sarà possibile interrogare solo i dati inseriti nella nuova regione. È possibile scaricare e visualizzare i dati esistenti della regione che è inattiva. Per ulteriori informazioni sulla struttura dei dati dell'archivio, vedere Interrogazione dei dati direttamente dall'archivio.
- Se hai bisogno di accedere ai log dall'istanza IBM Cloud Logs nell'area del disastro utilizzando la dashboard o la CLI dell'istanza IBM Cloud Logs appena creata, contatta l'assistenza IBM. Per ulteriori informazioni sulla strategia di disaster recovery per IBM Cloud Object Storage, vedere Endpoint interregionali, Sicurezza dei dati, Creare un' Content Store e sicura e Utilizzo della replica per la continuità aziendale e il disaster recovery.
- Se stavi utilizzando bucket locali o regionali della regione interessata, crea nuovi bucket. Collegare le benne alla nuova istanza di IBM Cloud Logs. Per ulteriori informazioni, vedere Configurazione del bucket dati e Configurazione del bucket metriche.
- Definire le autorizzazioni IAM tra l'istanza dell' IBM Cloud Logs e e i bucket. Per ulteriori informazioni, vedere Creazione di un'autorizzazione di accesso(S2S)per concedere l'accesso a un bucket.
Se la tua istanza nella regione colpita dal disastro non è stata configurata con bucket di tipo " IBM Cloud Object Storage ", i log e i dati delle metriche andranno persi.
Se nel tuo caso sono configurati degli avvisi, completa i seguenti passaggi:
- Crea una nuova istanza di IBM Cloud Event Notifications o utilizza una già esistente che potresti avere a disposizione in un'altra regione, assicurandoti sempre che soddisfi i tuoi requisiti di conformità e di localizzazione dei dati. Per ulteriori informazioni, vedi Provisioning di un'istanza. Per ulteriori informazioni sulla strategia di disaster recovery per IBM Cloud Event Notifications, vedere Protezione dei dati in IBM Cloud Event Notifications e Disaster recovery.
- Definire le autorizzazioni IAM tra l'istanza IBM Cloud Logs e l'istanza IBM Cloud Event Notifications. Per ulteriori informazioni, vedere Creazione di un'autorizzazione di accesso remoto(S2S)per lavorare con il servizio di accesso remoto(IBM Cloud Event Notifications ).
- Configurare IBM Cloud Event Notifications come integrazione in uscita. Per ulteriori informazioni, vedere Configurare l'instradamento degli eventi verso le destinazioni in IBM Cloud Event Notifications.
Ricreare le risorse nella nuova istanza di IBM Cloud Logs.

Creare viste.

Creare cruscotti.

Creare avvisi.

Creare politiche TCO.

Creare regole di analisi.

Creare eventi per le metriche.

Abilita l'utilizzo dei dati.

Configurare le regole dei dati.

Configurare le politiche di arricchimento dei dati.

Per facilitare il recupero di un'istanza di Amazon Web Services ( IBM Cloud Logs ), utilizza Terraform per gestire le tue istanze, configurazioni e accesso IAM. L'utilizzo di Terraform eliminerà la necessità di passaggi manuali durante la configurazione di istanze in un'altra regione.

Dopo aver ripristinato l'istanza, è necessario riconfigurare le origini dati per inviare i registri alla nuova istanza:

Se la nuova regione ha un tenant di configurazione ( IBM Cloud Logs Routing ) configurato, è necessario utilizzare l'obiettivo corrente associato a tale regione per visualizzare e monitorare i registri della piattaforma. Se la nuova regione non ha un tenant dell' IBM Cloud Logs Routing, creare un tenant dell' IBM Cloud Logs Routing che faccia riferimento alla nuova istanza dell' IBM Cloud Logs. Vedere Creazione di un tenant dell' IBM Cloud Logs Routing e Informazioni su alta disponibilità e disaster recovery per l' IBM Cloud Logs Routing.
Se la nuova regione ha una configurazione di tipo " IBM Cloud Activity Tracker Event Routing " che raccoglie gli eventi di monitoraggio delle attività dalla regione che non funziona, è possibile utilizzare la configurazione esistente per visualizzare e gestire gli eventi. Se la nuova regione non dispone di una configurazione di IBM Cloud Activity Tracker Event Routing che raccolga gli eventi di tracciamento delle attività dalla regione che è inattiva, è necessario aggiungere una regola per indicare dove e come si desidera raccogliere gli eventi. Per ulteriori informazioni, vedere Creazione di una configurazione di instradamento resiliente a un disastro regionale.
Riconfigurare l' Agent di registrazione e in modo che punti all'endpoint di ingestione dell'area di ripristino dell' IBM Cloud Logs.

Per saperne di più sulla responsabilità di proprietà tra te e IBM Cloud per l'utilizzo di IBM Cloud Logs, consulta Comprensione delle tue responsabilità quando utilizzi IBM Cloud Logs.

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

IBM Cloud Logs fornisce modi per proteggere i dati e ripristinare le funzioni di servizio. Sono in atto piani di continuità aziendale per raggiungere l'obiettivo del punto di ripristinoNella pianificazione del disaster recovery, il momento in cui i dati vengono ripristinati, misurato in termini di tempo (secondi, minuti, ore) a partire dall'istanza recuperata fino al punto in cui si è verificato il disastro. (RPO) e l'obiettivo del tempo di ripristinoNella pianificazione del disaster recovery, la durata del tempo necessario per ripristinare un processo aziendale dopo un disastro. (RTO) per il servizio. La tabella seguente illustra gli obiettivi per il IBM Cloud Logs.

RPO e RTO per IBM Cloud Logs
Obiettivo di ripristino in caso di disastro	Valore obiettivo
RPO	Entro 4 ore
RTO	Entro 24 ore

Gestione delle modifiche

La gestione delle modifiche comprende attività quali aggiornamenti, modifiche alla configurazione e cancellazioni.

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. Vedere Come posso evitare la cancellazione accidentale dei servizi?

Considera la possibilità di creare un backup utilizzando l'API prima di eseguire l'aggiornamento a una nuova versione di IBM Cloud Logs se disponi di configurazioni che non utilizzano Terraform.

Come IBM® supporta la pianificazione del disaster recovery

IBM® esegue test annuali su vari scenari di catastrofi e perfeziona continuamente la nostra documentazione di ripristino in base ai risultati ottenuti durante questi test.
un supporto globale 24 ore su 24, 7 giorni su 7, è a disposizione dei clienti con esperti in materia ( IBM® ) che sono reperibili per aiutare in caso di emergenza.

Tutti gli esperti in materia di continuità operativa ( IBM® ) vengono formati annualmente sulle politiche e le procedure di continuità operativa e di disaster recovery per garantire la preparazione in caso di disastro.

IBM Cloud Logs è un servizio regionale altamente disponibile.

Per ulteriori informazioni sulle regioni in cui è disponibile IBM Cloud Logs, vedere Sedi.
Ogni regione dispone di tre diversi data center per la ridondanza, configurati in modalità di active/active.
Se si verifica un malfunzionamento di tutti i data center in un'ubicazione, IBM Cloud Logs diventa indisponibile in tale ubicazione.
In ogni regione supportata, il traffico viene bilanciato attraverso l'infrastruttura in più zone di disponibilità, senza un singolo punto di guasto.

La tabella seguente elenca lo stato di alta disponibilità (HA) per le regioni (località) in cui è disponibile il servizio IBM Cloud Logs:

Elenco delle località in cui il servizio è disponibile
Area geografica	Regione	Supportato dall'UE	Stato HA
Asia Pacifico	Osaka (`jp-osa`)	Non applicabile	`MZR`
Asia Pacifico	Sydney (`au-syd`)	Non applicabile	`MZR`
Asia Pacifico	Tokyo (`jp-tok`)	Non applicabile	`MZR`
Europa	Francoforte (`eu-de`)	SÌ	`MZR`
Europa	Londra (`eu-gb`)	NO	`MZR`
Europa	Madrid (`eu-es`)	SÌ	`MZR`
America del Nord	Toronto (`ca-tor`)	Non applicabile	`MZR`
America del Nord	Montreal (`ca-mon`)	Non applicabile	`MZR`
America del Nord	Dallas (`us-south`)	Non applicabile	`MZR`
America del Nord	Washington (`us-east`)	Non applicabile	`MZR`
America del Sud	Sao Paulo (`br-sao`)	Non applicabile	`MZR`

Dove

Una geografia è un'area geografica o un corpo politico più ampio che contiene una o più regioni.
Una regione è un territorio geografico definito.
Una regione può essere un'area con un codice postale specifico, una città, uno stato, un gruppo di stati o persino un gruppo di paesi.
Una regione contiene più zone di disponibilità per soddisfare i requisiti di accesso locale, bassa latenza e sicurezza della regione.
MZR significa regione multizona. Ulteriori informazioni.

Per ulteriori informazioni sulla disponibilità dei servizi nelle regioni e nei centri dati, consultare Disponibilità di servizi e infrastrutture per località.

I dati gestiti da IBM Cloud Logs in una regione sono conservati nei centri dati vicini a quella regione.

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

Per impostazione predefinita, IBM Cloud Logs è distribuito su 3 zone. Ogni zona è configurata con un active/active/active:

Ogni zona si trova in un diverso centro dati della regione.
I dati di ciascuna zona vengono automaticamente replicati nelle altre zone con bassa latenza. Non è necessario fare nulla per abilitare la replica.
Il servizio è progettato per resistere a un guasto in una singola zona senza interruzioni.

L'architettura MZR offre un failover automatico tra le zone all'interno della regione e un'elevata disponibilità per l'implementazione dell' IBM Cloud Logs.

I metadati gestiti dall' IBM Cloud Logs, includono i metadati del cliente, come le informazioni sulle impostazioni critiche, le chiavi, le definizioni degli allarmi, le definizioni dell' e2m, i dati delle metriche e così via.

IBM Cloud Logs esegue regolarmente il backup dei dati in ogni regione:

Vengono eseguiti backup regolari ogni giorno, che vengono conservati per 30 giorni e archiviati in bucket di archiviazione interregionale ( IBM Cloud Object Storage )
Vengono conservati backup incrementali continui degli ultimi 7 giorni.

Se si verifica un guasto completo della regione, i dati di backup rimangono disponibili e vengono quindi ripristinati nell'ambito del ripristino del servizio di IBM Cloud Logs.

Come l' IBM e recupera dai guasti di zona

In caso di guasto di una zona, l' IBM Cloud e risolverà l'interruzione di zona. Poiché il piano dati si estende su tutte e tre le zone di una regione, non ci sarà alcun impatto sulla disponibilità del servizio e il bilanciatore di carico globale riprenderà a inviare dati alla zona ripristinata. Per il momento non sarà necessario alcun intervento da parte del cliente.

Come l' IBM e si riprende dai fallimenti regionali

Quando una regione viene ripristinata dopo un errore, IBM tenterà di ripristinare l'istanza di servizio dallo stato regionale. Se lo stato regionale è corrotto, il servizio viene ripristinato allo stato dell'ultimo backup interno, che viene continuamente trasmesso in streaming a un sito dati alternativo in un bucket di archiviazione interregionale ( IBM Cloud Object Storage ) gestito dal servizio. Se i dati di backup sono stati danneggiati, c'è la possibilità di perdere i dati delle ultime 24 ore. Questi backup non sono disponibili per il ripristino di emergenza gestito dal cliente.

Se IBM non è in grado di ripristinare l'istanza di servizio, il cliente deve eseguire il ripristino come descritto in Architettura di disaster recovery.

Come l' IBM e mantiene i servizi

Tutti gli aggiornamenti seguono le migliori pratiche di assistenza dell' IBM, e sono dotati di un piano di ripristino e di un processo di rollback. Gli aggiornamenti regolari per le nuove funzionalità e la manutenzione avvengono nell'ambito delle normali operazioni. Tale manutenzione può occasionalmente causare brevi intervalli di interruzione che vengono gestiti 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. Gli aggiornamenti vengono annullati al primo segno di difetto.

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