Utilizzo del mirroring
Il mirroring abilita la copia continua dei messaggi in una istanza del servizio Event Streams in una seconda istanza. La resilienza dell'applicazione può essere migliorata utilizzando il mirroring come se la prima istanza del servizio diventasse non disponibile, le applicazioni possono riconnettersi alla seconda istanza e continuare il loro normale funzionamento.
Questa funzione fa parte del servizio completamente gestito e può essere utilizzata solo tra le istanze del servizio che utilizzano il piano Enterprise Event Streams.
Caratteristiche del mirroring:
- Eseguire il mirroring degli argomenti, dei dati del messaggio e degli offset del gruppo di consumatori tra due istanze di servizio Event Streams, di cui è possibile eseguire il provisioning in diversi account IBM Cloud.
- SLA del 99.99% di disponibilità, congruente con il servizio Event Streams.
- Può essere monitorato utilizzando IBM Cloud® Monitoring.
Limitazioni del mirroring:
- Unidirezionale: i dati possono essere sottoposti a mirroring solo in una direzione alla volta tra una coppia di istanze del servizio. Ciò significa che il mirroring offre uno stile "attivo-passivo" di alta disponibilità, non "attivo-attivo".
- Asincrono: i messaggi devono essere prodotti correttamente sull'istanza origine prima che possano essere sottoposti a mirroring sull'istanza di destinazione. Ciò significa che quando si verifica un guasto, il cluster di destinazione potrebbe non contenere tutti i messaggi fino al punto esatto del guasto a causa del ritardo di replica e alcuni dati dei messaggi potrebbero andare persi.
- Consumo messaggi almeno una volta: quando un utente si sposta tra le istanze, potrebbe dover rielaborare i messaggi che ha già elaborato.
Prima di avviare il mirroring, considerare i seguenti punti:
- Potrebbe essere necessario modificare le applicazioni per sfruttare al meglio il mirroring.
- Assicurarsi che sia disponibile capacità sufficiente per il traffico di rete utilizzato per eseguire il mirroring dei dati tra istanze.
Per abilitare il mirroring, consultare Guida all'impostazione del mirroring.
Panoramica sul mirroring
Il mirroring degli argomenti selezionati si verifica tra due cluster ed è unidirezionale, il che significa che i dati vengono riflessi in una direzione da un singolo cluster di origine a uno di destinazione singolo. Ogni cluster dispone di un
alias di mirroring. In questo documento, A viene utilizzato per l'alias cluster di origine e B per l'alias cluster di destinazione. Gli alias sono configurabili quando il mirroring è abilitato, quindi, ad esempio,
potrebbero essere "us-south" e "us-east".
Un argomento denominato mytopic dal cluster di origine (A) appare sul cluster di destinazione (B) come mytopic.A che indica che ha origine da A. Questo tipo di argomento è denominato argomento remoto perché ha origine dal cluster remoto (origine). Al contrario, tutti gli argomenti creati direttamente sul cluster di destinazione dagli utenti vengono denominati argomenti locali.
Per selezionare quali argomenti vengono sottoposti a mirroring, è possibile configurare un pattern di espressione regolare utilizzando Controllo utente mirroring.
Il mirroring converte automaticamente gli offset dei consumatori tra le istanze di origine e di destinazione. Nelle precedenti versioni di Event Streams, i consumatori dovevano utilizzare un argomento speciale denominato A.checkpoints.internal (dove A è l'alias del cluster di origine). Ciò non è più necessario, tuttavia l'argomento del punto di controllo continua ad essere creato e aggiornato dal processo di mirroring per la retrocompatibilità con le applicazioni esistenti.
Le applicazioni che desiderano utilizzare l'argomento dei punti di controllo possono utilizzare Kafka MirrorClient per semplificare l'accesso ai dati contenuti in questo argomento
Infine, a causa della denominazione di argomenti remoti:
- Evita di utilizzare gli alias del cluster come parte dei nomi risorsa Kafka.
- Assicurati che il nome dell'argomento remoto (ad esempio l'argomento di origine e l'alias cluster di origine) non superi il limite di lunghezza per gli argomenti Kafka (249 caratteri). Se il nome di un argomento remoto supera questo limite, non verrà eseguito il mirroring dei messaggi per l'argomento.
Pianificazione della capacità
L'utilizzo della rete e l'ubicazione geografica delle istanze del servizio di origine e di destinazione devono essere considerati quando pianifichi la capacità.
Larghezza di banda di rete
La larghezza di banda di rete necessaria per eseguire il mirroring degli argomenti selezionati deve essere considerata nella quantità di larghezza di banda sia delle istanze del servizio di origine che di destinazione. Ad esempio, se 10 MB/s di traffico messaggi vengono prodotti dalle applicazioni nell'istanza del servizio di origine per gli argomenti sottoposti a mirroring, è necessario un ulteriore 10 MB/s di larghezza di banda in uscita per eseguire il mirroring di questi messaggi nell'istanza di destinazione. Ciò deve essere consentito insieme a qualsiasi larghezza di banda in uscita già utilizzata dalle applicazioni. I dashboard di monitoraggio possono essere usati per determinare l'utilizzo della rete in un'istanza del servizio. Per ulteriori informazioni, vedi Monitoraggio delle metriche Event Streams.
Posizione geografica
Come per qualsiasi rete, la velocità di trasmissione massima raggiungibile è un fattore della distanza su cui i dati vengono trasmessi (a causa della latenza crescente e della perdita di pacchetti). Ciò influenza la velocità di trasmissione massima che può essere raggiunta tra le istanze di origine e di destinazione. Posizionare le istanze del servizio di destinazione come ubicazioni geograficamente vicine il più possibile all'origine.
La tabella seguente fornisce indicazioni sulla produttività ottenibile durante il mirroring da un'istanza sorgente con una capacità di 150 MB/s.
| Regioni | Velocità di trasmissione massima per partizione | Velocità di trasmissione massima totale |
|---|---|---|
| us - sud < -> us - est | 1.5 MB/s | 35 MB/s |
| eu - gb < -> eu - de | 2.5 MB/s | 35 MB/s |
| au-syd < -> jp - tok | 0.4 MB/s | 12 MB/s |
| all'interno della stessa regione eu - gb < -> eu - gb | 2.5 MB/s | 35 MB/s |
I numeri indicano:
- Velocità di trasmissione totale massima: il numero massimo di MB/s di cui è possibile eseguire il mirroring in tutti gli argomenti selezionati.
- Velocità di trasmissione massima per partizione: il numero massimo di MB/s che è possibile sottoporre a mirroring all'interno di una partizione singola. Selezionare il numero di partizioni configurate per gli argomenti di origine per garantire che il carico per partizione rimanga entro questo limite.
Il superamento dei limiti determina un ritardo crescente tra i dati nelle istanze di origine e di destinazione. Un ritardo di dati di grandi dimensioni può causare la perdita di una quantità maggiore di dati del messaggio se l'istanza di origine ha esito negativo. Anche se il ritardo tra le istanze è zero, poiché il mirroring è asincrono, è necessario prevedere che alcuni dati potrebbero andare persi se l'istanza di origine ha esito negativo. I dashboard di monitoraggio possono essere utilizzati per determinare la latenza per ciascun argomento. Per ulteriori informazioni, vedere Monitoraggio del mirroring.
La guida sulla velocità di trasmissione raggiungibile è stata generata utilizzando i messaggi 100K prodotti su 50 partizioni di argomenti. Se il carico di lavoro utilizza dimensioni di messaggi più piccole (ad esempio, in 1K) o un numero inferiore di partizioni, il mirroring potrebbe non raggiungere questi livelli di velocità effettiva.
Eliminazione degli argomenti di destinazione ridondanti
Per evitare l'eliminazione accidentale dei dati nell'istanza di destinazione, gli argomenti non vengono automaticamente eliminati dall'istanza di destinazione quando vengono eliminati dall'origine. È responsabilità dell'utente eliminare gli argomenti sull'istanza di destinazione. Se gli argomenti sottoposti a mirroring vengono frequentemente eliminati e creati, nel cluster di destinazione è possibile utilizzare un numero maggiore di dischi e di partizioni. L'utilizzo può essere monitorato con il dashboard di monitoraggio nel cluster di destinazione, vedi Monitoraggio delle metriche Event Streams. Puoi eliminare gli argomenti che non sono più richiesti utilizzando le interfacce CLI, UI o admin.
Politiche di accesso IAM per il mirroring
Poiché le applicazioni hanno bisogno dell'accesso ai cluster di origine e di destinazione, le politiche di accesso IAM devono essere impostate su entrambi i cluster e utilizzare la chiave API dall'ID servizio a cui sono collegate le politiche. Possiamo utilizzare le funzioni di caratteri jolly IAM Assegnazione dell'accesso utilizzando le politiche dei caratteri jolly per semplificare le politiche di accesso che controllano l'accesso alle risorse sottoposte a mirroring.
Se sei nuovo alle politiche di accesso IAM, vedi Come funziona IBM Cloud IAM e Gestione dell'autenticazione per le tue istanze Event Streams per ulteriori dettagli.
Definisci le seguenti politiche di accesso IAM su entrambi i cluster, dove < ALIAS> è l'alias per l'altro cluster. Ad esempio, sul cluster B, l'ID risorsa è A.checkpoints.internal.
| Tipo di risorsa | ID risorsa | Ruolo |
|---|---|---|
| cluster | Lettore | |
| group | < NOME_RISORSA> .* | Come richiesto dall'applicazione |
| topic | < NOME_RISORSA> .* | Come richiesto dall'applicazione |
| txnid | < NOME_RISORSA> .* | Come richiesto dall'applicazione |
| argomento (specifico per l'argomento checkpoint) | < ALIAS>.checkpoints.internal | Lettore |
Concedere politiche di accesso dettagliate alle singole applicazioni. Ad esempio, per le applicazioni che utilizzano semplicemente l'accesso Lettura.
Per i controlli utente di mirroring, è necessario disporre delle seguenti autorizzazioni sul cluster di destinazione.
| Tipo di risorsa | ID risorsa | Ruolo |
|---|---|---|
| cluster | Gestore |
Restrizioni basate sul contesto e controlli di sicurezza della rete con il mirroring
Il mirroring segue un modello basato sul pull, in cui il cluster di destinazione avvia la connessione per prelevare i dati dal cluster di origine. Questo modello di mirroring basato sul pull impone controlli di rete al cluster di origine, garantendo che solo il cluster di destinazione autorizzato possa accedere ai dati del cluster di origine.
Quando sono abilitati i controlli di sicurezza della rete, come la restrizione basata sul contesto (CBR) o l'allowlisting CSE, viene definito un percorso sicuro a livello di rete e di identità di sicurezza aggiungendo un endpoint di servizio allowlist al cluster di origine, che include l'IP del pod di mirroring del cluster di destinazione. Questa configurazione impone un controllo di accesso a grana fine a livello di infrastruttura, consentendo solo all'endpoint di mirroring autorizzato (il cluster di destinazione) di prelevare i dati dal cluster di origine.
Le credenziali condivise tra il cluster di origine e quello di destinazione servono esclusivamente per il processo di mirroring e non garantiscono l'accesso ad altre risorse tra le distribuzioni Event Streams. Ciò significa che il processo di mirroring è isolato e sicuro, impedendo l'accesso non autorizzato ad altre risorse.
Questi controlli di sicurezza della rete devono essere abilitati prima dell'impostazione del mirroring. Se le restrizioni basate sul contesto vengono applicate dopo l'impostazione del mirroring, quest'ultimo non verrà avviato finché il cluster non verrà aggiornato.
Se il CBR è abilitato dopo il mirroring:
- Sollevare un ticket di assistenza.
- Attendere il successivo ciclo di aggiornamento del cluster (almeno 24 ore) per rendere effettive le modifiche.
- Includere gli indirizzi dei nodi mirror nelle regole CBR.
- Disattivare e riattivare il mirroring nel cluster di destinazione.
Considerazioni quando si condividono cluster tra più entità
Quando più entità, come unità aziendali differenti, condividono un'istanza e richiedono l'isolamento l'una dall'altra, seguire le istruzioni di denominazione per semplificare la gestione e il funzionamento dei cluster sottoposti a mirroring.
Denominare le risorse Kafka utilizzando il seguente modello: < ENTITY_PREFIX> < SEPARATORE> < NAME>
Dove:
- < ENTITY_PREFIX> è il prefisso per l'entità che utilizza questo argomento.
- < SEPARATOR> è un carattere facoltativo che viene utilizzato per separare facilmente le entità e i nomi delle risorse.
- < NAME> è il nome della risorsa Kafka.
Ad esempio, se l'unità aziendale di account richiede un argomento denominato fatture, è possibile denominarlo accounting.invoices.
Le politiche di accesso richieste devono essere modificate. Ad esempio, per l'unità aziendale di accounting, le seguenti politiche sono richieste sul cluster B:
| Tipo di risorsa | ID risorsa | Ruolo |
|---|---|---|
| cluster | Lettore | |
| group | contabilità. * | Come richiesto dall'applicazione |
| topic | contabilità. * | Come richiesto dall'applicazione |
| txnid | contabilità. * | Come richiesto dall'applicazione |
| (notare che questo è specifico per l'argomento del punto di controllo) | A.checkpoints.internal | Lettore |
Il Cluster A deve avere le stesse politiche di accesso oltre all'ultimo che deve essere su B.checkpoints.internal.
Mirroring dei controlli utente
È possibile configurare il mirroring utilizzando la CLI o l'API REST di amministrazione. Tutti i controlli utente di mirroring vengono eseguiti sul cluster di destinazione.
Impostazione della selezione argomento
La selezione di mirroring viene effettuata in base ai nomi degli argomenti sul cluster di origine utilizzando i modelli di espressione regolare (regex). Scegli attentamente i nomi degli argomenti sul tuo cluster di origine, considerando il suggerimento dalla sezione Considerazioni quando condividi i cluster tra più entità.
Con nomi di argomenti ben strutturati, come l'aggiunta di un prefisso agli argomenti che fanno parte dello stesso gruppo o applicazione, è facile controllare il mirroring. Con tale convenzione di denominazione in atto, tutti gli argomenti futuri che corrispondono al modello vengono automaticamente riflessi senza la necessità di ulteriori modifiche.
La selezione dell'argomento viene fornita sotto forma di un elenco di uno o più modelli regex. Un argomento viene selezionato se corrisponde a uno dei modelli nell'elenco.
Alcuni esempi di pattern per selezionare argomenti per il mirroring:
| Modelli di esempio | Spiegazione |
|---|---|
^topic1$ |
Nomi argomento completi. Questo corrisponde solo al singolo argomento denominato topic1. |
^topic1$,^topic2$ |
Elenco di modelli che corrispondono ai nomi argomento completi. Corrisponde ai due argomenti denominati topic1 e topic2. |
^aaa.* |
Corrispondenza con il prefisso. Questo corrisponde a qualsiasi nome argomento che inizia con aaa. |
^aaa.*,^bbb.* |
Elenco di modelli corrispondenti al prefisso. Corrisponde a qualsiasi nome argomento che inizia con aaa o bbb. |
^branch_[0-9]{3}_[a-z]*$ |
Modello regex più complesso per corrispondere ai nomi degli argomenti. Corrisponde a qualsiasi nome argomento che inizia con branch_, seguito da esattamente 3 cifre, seguito da _ e da qualsiasi numero di
lettere minuscole. |
.* |
Mirroring di tutti gli argomenti di origine. |
Quando si utilizza la CLI, i modelli vengono forniti come un elenco separato da virgole. Ad esempio, il seguente comando selezionerà tutti gli argomenti il cui nome ha il prefisso accounting o hr.
ibmcloud es mirroring-topic-selection-set --select '^accounting.*,^hr.*'
Il seguente comando mostra come effettuare la stessa selezione utilizzando l'API REST di amministrazione. I pattern sono nel formato di un array JSON denominato "includes".
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^accounting.*", "^hr.*"]}'
L'aggiornamento di una selezione argomento sostituisce la serie corrente di pattern.
Per rimuovere la selezione in modo che nessun argomento venga sottoposto a mirroring, utilizzare l'opzione --none con la CLI o un pattern vuoto con l'API REST di gestione, come riportato di seguito.
ibmcloud es mirroring-topic-selection-set --none
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":[""]}'
Per disabilitare selettivamente il mirroring, riapplicare la selezione dell'argomento tralasciando i pattern che si desidera disabilitare. Ad esempio, quando topic1, topic2, topic3 sono al momento sottoposti a mirroring, i seguenti comandi disabilitano il mirroring per topic2 ma lasciano gli altri due abilitati.
ibmcloud es mirroring-topic-selection-set --select '^topic1$,^topic3$'
curl -s -X POST -H "Content-Type: application/json" -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection -d '{"includes":["^topic1$","^topic3$"]}'
Richiamo della selezione argomento
È possibile recuperare la selezione di mirroring utilizzando le seguenti interfacce:
CLI:
ibmcloud es mirroring-topic-selection
API REST:
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/topic-selection
Richiamo degli argomenti attivi
È possibile richiamare gli argomenti di cui si sta eseguendo attivamente il mirroring utilizzando le seguenti interfacce:
CLI:
ibmcloud es mirroring-active-topics
API REST:
curl -s -X GET -H "Authorization: <bearer token>" <admin url>/admin/mirroring/active-topics
Creazione di applicazioni sensibili al mirroring
Produttori
Consigliamo ai produttori di produrre solo su argomenti locali. Il passaggio di un produttore tra le istanze generalmente richiederà una modifica della configurazione, in modo che il produttore utilizzi gli endpoint e le credenziali corretti per connettersi.
Consumer
I consumatori devono sottoscrivere e utilizzare sia gli argomenti locali che quelli remoti. Questo può essere fatto con un abbonamento wild - carded. Ad esempio, per utilizzare sia da accounting.invoice che da accounting.invoice.<ALIAS>,
utilizzare la sottoscrizione a accounting.invoice.*.
Quando si utilizzano argomenti sia locali che remoti, verificare se l'applicazione richiede un ordine rigoroso. In questo caso, gli argomenti remoti devono essere utilizzati completamente prima di iniziare a utilizzare gli argomenti locali. In questo modo i messaggi vengono elaborati nell'ordine in cui sono stati prodotti.
Offset consumer
Quando i dati del messaggio vengono sottoposti a mirroring tra due istanze, esistono diversi motivi per cui gli offset assegnati al messaggio nell'istanza di origine potrebbero non corrispondere all'offset utilizzato nell'istanza di destinazione. Ad esempio:
- Eliminazione e ricreazione di un argomento con lo stesso nome nell'istanza di origine.
- Mirroring degli argomenti con una politica di ripulitura compatta.
- Produzione di messaggi mediante transazioni.
Parte del processo di mirroring dei messaggi traccia quali offset nell'istanza di origine sono equivalenti a quali offset nell'istanza di destinazione. Per l'efficienza, viene tracciato solo un piccolo numero di offset equivalenti, con le posizioni vicino alla parte principale dell'argomento che sono preferite. Quando viene eseguito il commit degli offset per i gruppi di consumatori nell'istanza di origine, essi vengono convertiti nell'offset equivalente più vicino nell'istanza di destinazione e viene eseguito il commit di un offset corrispondente per il gruppo nell'istanza di destinazione. Questa conversione ha lo scopo di garantire che un utente che passa al cluster di destinazione non ignori i messaggi di cui è stato eseguito il mirroring. Tuttavia, poiché non tutti gli offset equivalenti vengono tracciate dal processo di mirroring, quando un utente passa all'istanza di destinazione è probabile che rielabori i dati già utilizzati nell'istanza di origine.
Quando si scrivono applicazioni che tengono traccia dell'avanzamento del consumer eseguendo il commit degli offset, considerare quanto segue:
- Gli offset dei consumatori vengono sottoposti a mirroring solo se il gruppo di consumatori corrispondente non viene utilizzato attivamente nell'istanza di destinazione.
- Si prevede di rielaborare alcuni dati del messaggio quando l'utente si sposta sull'istanza di destinazione.
- Più si trova dietro l'argomento principale di un consumer quando si sposta sull'istanza di destinazione, maggiore è il numero di dati potenzialmente necessari per il suo nuovo utilizzo.
- Se si desidera ridurre al minimo la quantità di dati riutilizzati e si può gestire con attenzione la commutazione delle applicazioni tra le istanze, la serie di passi consigliati per raggiungere questo obiettivo è:
- Arrestare la produzione dei messaggi sull'istanza di origine.
- Attendere fino a quando il consumatore non raggiunge la testa dell'argomento.
- Eseguire il commit di un offset in questa ubicazione.
- Passare il consumer all'istanza di destinazione.
Monitoraggio mirroring
È possibile monitorare il mirroring utilizzando IBM Cloud Monitoring. Per abilitare il monitoraggio, vedere Monitoraggio delle metriche di Event Streams. Il dashboard Monitoraggio è disponibile nel cluster di destinazione.
Il dashboard Event Streams Mirroring presenta le seguenti metriche:
- Velocità di trasmissione di mirroring: i byte al secondo della velocità di trasmissione di mirroring dall'istanza di origine Event Streams. Ciò è utile per verificare se il mirroring è attivo e per la pianificazione della capacità.
- Latenza mirroring: la latenza di mirroring per argomento al secondo dall'istanza di origine Event Streams. Ciò è utile per determinare la distanza tra un argomento e il cluster di destinazione.
I dati prodotti nella finestra di latenza potrebbero non essere ancora presenti sul cluster di destinazione e potrebbero ancora andare persi se si verifica un'emergenza sul cluster di origine. Tuttavia, se il mirroring è aggiornato, il failover mentre entrambi i cluster rimangono in buono stato può essere raggiunto senza alcuna perdita di dati.
Comprensione degli obiettivi di recupero con il mirroring
In un piano di protezione dei dati come il mirroring, l'RPO (recovery point objective) e l'RTO (recovery time objective) sono parametri chiave. È necessario comprendere le decisioni associate a questi obiettivi.
È possibile monitorare l'obiettivo del punto di ripristino utilizzando la metrica di latenza di mirroring fornita nel dashboard Mirroring. Questa metrica mostra il ritardo tra entrambi i cluster, in modo da poter stimare la quantità di perdita di dati in caso di emergenza. Sei responsabile del monitoraggio di tale valore e della garanzia che si adatti al tuo RPO.
L'obiettivo del tempo di recupero è completamente controllato dagli utenti ed è costituito dalle seguenti finestre di temporizzazione:
- Il tempo impiegato dall'utente per decidere di eseguire il failover.
- Il tempo impiegato dall'utente per eseguire il failover delle proprie applicazioni.
Esecuzione di test
Eseguire il test di failover e di ritorno quando si rende noto il mirroring delle applicazioni. Completa i passaggi descritti nello scenario di esempio di ripristino di emergenza e utilizza i dashboard Monitoraggio per garantire che tutti i passaggi siano completati come previsto.
Eliminazione e ricreazione di argomenti con lo stesso nome sul cluster di origine
Quando gli argomenti vengono eliminati sul cluster di origine, l'argomento corrispondente sul cluster di destinazione non viene eliminato automaticamente. Se successivamente si crea nuovamente l'argomento sul cluster di origine, i dati dal nuovo argomento nel cluster di origine verranno aggiunti alla fine dell'argomento esistente nel cluster di destinazione.
Considerazioni per Kafka Streams e Kafka Connect
Kafka Streams e Kafka Connect si basano su argomenti interni con nomi specifici per memorizzare stato e configurazione. Quando questi argomenti vengono sottoposti a mirroring, vengono ridenominati sul cluster di destinazione. Per questo motivo, le applicazioni Kafka Streams e Kafka Connect non possono eseguire il failover e il failback tra i cluster. Considerare ciò quando si pianifica il ripristino di emergenza di tali applicazioni.