Creazione di una configurazione di routing resiliente a un disastro regionale
IBM Cloud Metrics Routing è un servizio regionale multi-tenant ad alta disponibilità. Tuttavia, è anche possibile configurare una configurazione di routing per un'istanza di backup per ridurre al minimo la perdita di dati in caso di disastro regionale.
Per ulteriori informazioni sulla disponibilità e il ripristino dell' IBM Cloud Metrics Routing, forniti dal servizio, vedere Informazioni sull'alta disponibilità e il ripristino di emergenza.
Comprendere obiettivi, percorsi e regole
Prima di creare una regione di backup, è necessario comprendere destinazioni, percorsi e regole.
-
Gli obiettivi vengono creati all'interno di una regione ma sono risorse globali. Per ulteriori informazioni, vedere Gestione degli obiettivi.
-
I percorsi sono globali in un account e vengono valutati in tutte le regioni in cui è distribuito IBM Cloud Metrics Routing. Per ulteriori informazioni, vedere Gestione dei percorsi.
-
Le regole specificano quali metriche vengono instradate in una regione e dove instradarle. Per ulteriori informazioni, vedere Definizione delle regole di routing.
-
La configurazione delle impostazioni dell'account definisce informazioni quali gli obiettivi predefiniti in cui vengono raccolte le metriche nell'account, i tipi di endpoint autorizzati a gestire la configurazione, le posizioni dei metadati di configurazione e le posizioni autorizzate in cui archiviare i dati nell'account. Per ulteriori informazioni, vedere Configurazione delle impostazioni dell'account.
Se né la regione dei metadati primaria né quella dei metadati di backup configurate nelle impostazioni dell'account sono disponibili, non verrà instradata alcuna metrica.
Instradamento verso una destinazione di backup in una regione diversa
Puoi configurare una destinazione di backup per i dati instradati dalla tua istanza IBM Cloud Metrics Routing verso una destinazione in esecuzione in una regione diversa. È quindi possibile instradare tutti i dati sia verso la destinazione primaria che verso quella di backup. Configurando una destinazione di backup si ottengono destinazioni sincronizzate. È possibile passare al backup senza tempi di inattività e con una perdita minima di dati in caso di calamità naturale a livello regionale.
La creazione di una seconda destinazione per scopi di backup comporta costi aggiuntivi per l'esecuzione dell'istanza della destinazione di backup.
In questo esempio, la fonte delle metriche è nella regione di Toronto ( ca-tor
). Le metriche dal servizio IBM Cloud vengono inviate da IBM Cloud Metrics Routing a un'istanza di IBM Cloud Monitoring a Dallas ( us-south
). Viene creata una configurazione di routing regionale resiliente ai disastri per instradare le metriche anche a un'istanza di IBM Cloud Monitoring (Target 2) nella regione di Washington ( us-east
). Tutte le metriche vengono
inviate sia al target nella regione di Dallas ( us-south
) che a quello nella regione di Washington ( us-east
).
Il target 2 fornisce all'utente le metriche storiche della regione di Washington (us-east
). Se la regione di Dallas (us-south
) non è disponibile, gli utenti hanno a disposizione le metriche di Toronto (ca-tor
)
nella regione di Washington (us-east
).
Per gli utenti senza una configurazione di routing resiliente ai disastri, non sono disponibili metriche storiche in una seconda regione.
Per ulteriori informazioni sulla configurazione dei percorsi, vedere Gestione dei percorsi. Quando si configurano le regole di routing associate ai percorsi, è necessario configurare le regole in modo da instradare le stesse metriche verso entrambe le posizioni di destinazione, in modo che ciascuna posizione disponga degli stessi dati.
Inoltre, è necessario definire un'area di backup dei metadati per il backup dei metadati. La regione dei metadati di backup deve essere diversa dalla regione dei metadati primari.
Considerazioni sulla sicurezza in un ambiente con due target
Quando si configura un ambiente con una destinazione di backup, è necessario considerare quanto segue:
-
Le restrizioni basate sul contesto consentono ai proprietari e agli amministratori degli account di definire e applicare restrizioni di accesso per le risorse IBM Cloud in base ai criteri di una regola. I criteri includono la posizione di rete delle richieste di accesso, il tipo di endpoint da cui viene inviata la richiesta e talvolta l'API a cui la richiesta tenta di accedere. Queste restrizioni si integrano con le tradizionali policy IAM, basate sull'identità, per fornire un ulteriore livello di protezione. Per ulteriori informazioni, vedere Cosa sono le restrizioni basate sul contesto?
Se nell'account sono configurate regole basate sul contesto, assicurarsi che le regole di restrizione basate sul contesto siano definite sia per la posizione primaria che per quella di backup.
È possibile configurare regole di restrizione basate sul contesto per i target IBM Cloud Monitoring.
Per un elenco completo dei servizi che supportano restrizioni basate sul contesto, vedere Servizi integrati con restrizioni basate sul contesto.
-
IBM Cloud® Identity and Access Management (IAM) consente di controllare in modo sicuro l'accesso a tutte le risorse cloud in modo coerente in IBM Cloud. I permessi e le autorizzazioni IAM devono consentire al servizio di instradare le metriche sia alle destinazioni primarie che a quelle di backup.
Gestione automatica dei disastri
È possibile scegliere di consentire a IBM Cloud Metrics Routing di gestire un disastro regionale come descritto in Comprensione dell'alta disponibilità e del disaster recovery.
In questo caso non vengono addebitati costi aggiuntivi per una seconda istanza di destinazione. Tuttavia, si presentano anche i seguenti rischi:
- Non è possibile accedere ai dati storici della regione in cui si è verificato il disastro.
- I dati vengono persi quando si configura una nuova istanza mentre quella esistente non è disponibile.
- Tutte le metriche indirizzate a una destinazione IBM Cloud Monitoring e poi trasmesse in streaming a un'istanza IBM® Event Streams for IBM Cloud® vengono mantenute solo fino alla dimensione del buffer per 24 ore. I dati potrebbero quindi andare persi. Per ulteriori informazioni, vedere Informazioni sulle responsabilità quando si utilizzano Event Streams