Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Utilizza la replica per aumentare la resilienza di un'applicazione di streaming Kafka in tutte le regioni
È possibile utilizzare MSK Replicator per configurare topologie di cluster attive-attive o attive-passive per aumentare la resilienza dell'applicazione Apache Kafka in tutte le regioni. AWS In una configurazione attiva-attiva, entrambi i cluster MSK eseguono attivamente operazioni di lettura e scrittura. In una configurazione attiva-passiva, solo un cluster MSK alla volta serve attivamente lo streaming di dati, mentre l'altro cluster è in standby.
## Considerazioni per la creazione di applicazioni Apache Kafka multiregione
I consumatori devono essere in grado di rielaborare i messaggi duplicati senza ripercussioni a valle. MSK Replicator replica i dati at-least-once che possono causare duplicati nel cluster di standby. Quando si passa alla AWS regione secondaria, i consumatori possono elaborare gli stessi dati più di una volta. Il replicatore MSK dà la priorità alla copia dei dati rispetto agli offset dei consumatori per prestazioni migliori. Dopo un failover, il consumatore può iniziare a leggere dagli offset precedenti con conseguente duplicazione dell'elaborazione.
I produttori e i consumatori devono inoltre tollerare una perdita minima di dati. Poiché MSK Replicator replica i dati in modo asincrono, quando la AWS regione primaria inizia a riscontrare errori, non vi è alcuna garanzia che tutti i dati vengano replicati nella regione secondaria. È possibile utilizzare la latenza di replica per determinare il numero massimo di dati che non sono stati copiati nella regione secondaria.
## Utilizzo della topologia di cluster attiva-attiva rispetto a quella attiva-passiva
Una topologia di cluster attiva-attiva offre tempi di ripristino quasi nulli e la possibilità per l'applicazione di streaming di funzionare contemporaneamente in più regioni AWS . Quando un cluster in una regione è danneggiato, le applicazioni connesse al cluster nell'altra regione continuano a elaborare i dati.
Le configurazioni attive-passive sono adatte alle applicazioni che possono essere eseguite in una sola regione AWS alla volta o quando è necessario un maggiore controllo sull'ordine di elaborazione dei dati. Le configurazioni attive-passive richiedono più tempo di ripristino rispetto alle configurazioni attive-attive, poiché, dopo un failover, è necessario avviare l'intera configurazione attiva-passiva, compresi produttori e consumatori, nella regione secondaria per riprendere lo streaming dei dati.
# Crea una configurazione di cluster Kafka attivo-passiva con le configurazioni di denominazione degli argomenti consigliate
Per una configurazione attiva-passiva, ti consigliamo di utilizzare una configurazione simile di produttori, cluster MSK e consumatori (con lo stesso nome di gruppo di consumatori) in due regioni diverse. AWS È importante che i due cluster MSK abbiano capacità di lettura e scrittura identiche per garantire una replica affidabile dei dati. È necessario creare un replicatore MSK per copiare continuamente i dati dal cluster primario a quello di standby. È inoltre necessario configurare i produttori in modo che scrivano i dati in argomenti su un cluster nella stessa regione. AWS
Per una configurazione attiva-passiva, create un nuovo replicatore con replica identica dei nomi degli argomenti (**mantieni lo stesso nome degli argomenti** nella console) per iniziare a replicare i dati dal tuo cluster MSK nella regione primaria al cluster nella regione secondaria. Si consiglia di utilizzare un set duplicato di produttori e consumatori nelle due AWS regioni, ciascuno dei quali si connette al cluster della propria regione utilizzando la propria stringa di bootstrap. Ciò semplifica il processo di failover poiché non richiede modifiche alla stringa di bootstrap. Per garantire che i consumatori leggano da dove l'avevano interrotto, i consumatori dei cluster di origine e di destinazione devono avere lo stesso ID del gruppo di consumatori.
Se si utilizza la replica identica dei nomi degli argomenti (**Mantieni lo stesso nome degli argomenti** nella console) per MSK Replicator, gli argomenti verranno replicati con lo stesso nome degli argomenti di origine corrispondenti.
Si consiglia di configurare le impostazioni e le autorizzazioni a livello di cluster per i client nel cluster di destinazione. Non è necessario configurare le impostazioni a livello di argomento e la lettura letterale, ACLs poiché MSK Replicator le copia automaticamente se è stata selezionata l'opzione per copiare le liste di controllo degli accessi. Per informazioni, consulta [Replica dei metadati](msk-replicator-how-it-works.md#msk-replicator-metadata-replication).
# Failover nella regione secondaria AWS
Ti consigliamo di monitorare la latenza di replica nella AWS regione secondaria utilizzando Amazon. CloudWatch Durante un evento di servizio nella AWS regione principale, la latenza di replica può aumentare improvvisamente. Se la latenza continua ad aumentare, utilizza il AWS Service Health Dashboard per verificare la presenza di eventi di servizio nella AWS regione principale. Se si verifica un evento, puoi eseguire il failover nella regione secondaria AWS .
# Esegui un failover pianificato nella regione secondaria AWS
È possibile eseguire un failover pianificato per testare la resilienza dell'applicazione rispetto a un evento imprevisto nella AWS regione principale in cui si trova il cluster MSK di origine. Un failover pianificato non dovrebbe comportare la perdita di dati.
Se utilizzi un argomento identico alla configurazione della replica dei nomi, segui questi passaggi:
1. Arresta tutti i produttori e i consumatori che si connettono al cluster di origine.
1. Crea un nuovo replicatore MSK per replicare i dati dal cluster MSK nella regione secondaria al cluster MSK nella regione principale con la replica identica dei nomi degli argomenti (**mantieni lo stesso nome degli** argomenti nella console). Ciò è necessario per copiare i dati che verranno scritti dalla regione secondaria alla regione primaria, in modo da poter eseguire il failback nella regione primaria al termine dell'evento imprevisto.
1. Avvia produttori e consumatori collegati al cluster di destinazione nella regione secondaria. AWS
Se utilizzi la configurazione dei nomi degli argomenti con prefisso, segui questi passaggi per il failover:
1. Arresta tutti i produttori e i consumatori che si connettono al cluster di origine.
1. Crea un nuovo replicatore MSK per replicare i dati dal cluster MSK nella regione secondaria al cluster MSK nella regione primaria. Ciò è necessario per copiare i dati che verranno scritti dalla regione secondaria alla regione primaria, in modo da poter eseguire il failback nella regione primaria al termine dell'evento imprevisto.
1. Avvia i produttori sul cluster target nella regione secondaria AWS .
1. A seconda dei requisiti di ordinamento dei messaggi dell'applicazione, segui i passaggi indicati in una delle schede seguenti.
------
#### [ No message ordering ]
Se l'applicazione non richiede l'ordinamento dei messaggi, avvia i consumatori della AWS regione secondaria che leggono sia gli argomenti locali (ad esempio, topic) che quelli replicati (ad esempio`.topic`) utilizzando un operatore wildcard (ad esempio,). `.*topic`
------
#### [ Message ordering ]
Se l'applicazione richiede l'ordinamento dei messaggi, avvia i consumatori solo per gli argomenti replicati sul cluster di destinazione (ad esempio, `.topic`) ma non per gli argomenti locali (ad esempio, `topic`).
------
1. Attendi che tutti i consumatori degli argomenti replicati sul cluster MSK di destinazione completino l'elaborazione di tutti i dati, in modo che il ritardo del consumatore sia 0 e anche il numero di record elaborati sia 0. Quindi, interrompi i consumatori per gli argomenti replicati sul cluster di destinazione. A questo punto, tutti i record replicati dal cluster MSK di origine al cluster MSK di destinazione sono stati utilizzati.
1. Avvia i consumatori per gli argomenti locali (ad esempio, `topic`) sul cluster MSK di destinazione.
# Eseguite un failover non pianificato nella regione secondaria AWS
È possibile eseguire un failover non pianificato quando si verifica un evento di servizio nella AWS regione principale in cui è presente il cluster MSK di origine e si desidera reindirizzare temporaneamente il traffico verso la regione secondaria che include il cluster MSK di destinazione. Un failover non pianificato potrebbe causare una perdita di dati poiché MSK Replicator replica i dati in modo asincrono. È possibile tenere traccia del ritardo dei messaggi utilizzando le metriche in. [Monitoraggio della replica](msk-replicator-monitor.md)
Se utilizzi la configurazione di replica dei nomi degli argomenti identica (**mantieni lo stesso nome degli argomenti** nella console), segui questi passaggi:
1. Prova a chiudere tutti i produttori e i consumatori che si connettono al cluster MSK di origine nella regione primaria. Questa operazione potrebbe non riuscire a causa di problemi in quella regione.
1. Avvia i produttori e i consumatori a connettersi al cluster MSK di destinazione nella AWS regione secondaria per completare il failover. Poiché MSK Replicator replica anche i metadati, compresi gli offset di lettura ACLs e gli offset dei gruppi di consumatori, i produttori e i consumatori riprenderanno senza problemi l'elaborazione quasi da dove l'avevano interrotta prima del failover.
Se utilizzi la configurazione del nome dell'`PREFIX`argomento, segui questi passaggi per il failover:
1. Prova a chiudere tutti i produttori e i consumatori che si connettono al cluster MSK di origine nella regione primaria. Questa operazione potrebbe non riuscire a causa di problemi in quella regione.
1. Avvia i produttori e i consumatori a connettersi al cluster MSK di destinazione nella AWS regione secondaria per completare il failover. Poiché MSK Replicator replica anche i metadati, compresi gli offset di lettura ACLs e gli offset dei gruppi di consumatori, i produttori e i consumatori riprenderanno senza problemi l'elaborazione quasi da dove l'avevano interrotta prima del failover.
1. A seconda dei requisiti di ordinamento dei messaggi dell'applicazione, segui i passaggi indicati in una delle schede seguenti.
------
#### [ No message ordering ]
Se l'applicazione non richiede l'ordinamento dei messaggi, avviate i consumatori della AWS regione di destinazione che leggono sia gli argomenti locali (ad esempio) che quelli replicati (ad esempio`topic`) utilizzando un operatore wildcard (ad esempio,`.topic`). `.*topic`
------
#### [ Message ordering ]
1. Avvia i consumatori solo per gli argomenti replicati nel cluster di destinazione (ad esempio, `.topic`) ma non per gli argomenti locali (ad esempio, `topic`).
1. Attendi che tutti i consumatori degli argomenti replicati sul cluster MSK di destinazione completino l'elaborazione di tutti i dati, in modo che il ritardo di offset sia 0 e anche il numero di record elaborati sia 0. Quindi, interrompi i consumatori per gli argomenti replicati sul cluster di destinazione. A questo punto, tutti i record replicati dal cluster MSK di origine al cluster MSK di destinazione sono stati utilizzati.
1. Avvia i consumatori per gli argomenti locali (ad esempio, `topic`) sul cluster MSK di destinazione.
------
1. Una volta terminato l'evento di servizio nella regione primaria, create un nuovo replicatore MSK per replicare i dati dal cluster MSK nella regione secondaria al cluster MSK nella regione primaria con la posizione iniziale del replicatore impostata sulla *prima*. Ciò è necessario per copiare i dati che verranno scritti dalla regione secondaria alla regione primaria, in modo da poter eseguire il failback nella regione primaria al termine dell'evento di servizio. Se non impostate la posizione iniziale del Replicator sulla *prima*, i dati prodotti nel cluster nella regione secondaria durante l'evento di servizio nell'area primaria non verranno copiati nuovamente nel cluster nell'area primaria.
# Eseguire il failback nella regione principale AWS
È possibile eseguire il failback AWS nella regione principale al termine dell'evento di servizio in quella regione.
Se utilizzi la configurazione della replica dei nomi per argomento identico, segui questi passaggi:
1. Crea un nuovo Replicatore MSK con il cluster secondario come origine e il cluster primario come destinazione, impostando la posizione iniziale sulla replica del nome dell'argomento *più antica* e identica (**mantieni lo stesso nome degli argomenti** nella console).
In questo modo verrà avviato il processo di copia di tutti i dati scritti nel cluster secondario dopo il failover nella regione primaria.
1. Monitora la `MessageLag` metrica sul nuovo replicatore in Amazon CloudWatch fino al raggiungimento`0`, il che indica che tutti i dati sono stati replicati dal secondario al primario.
1. Dopo che tutti i dati sono stati replicati, interrompi la connessione di tutti i produttori al cluster secondario e avvia i produttori a connettersi al cluster primario.
1. Attendi `MaxOffsetLag` che i tuoi consumatori si connettano al cluster secondario `0` per assicurarti di aver elaborato tutti i dati. Per informazioni, consulta [Monitora i ritardi dei consumatori](consumer-lag.md).
1. Una volta che tutti i dati sono stati elaborati, interrompi i consumatori nell'area secondaria e avvia i consumatori a connettersi al cluster primario per completare il failback.
1. Eliminate il replicatore creato nel primo passaggio, che consiste nella replica dei dati dal cluster secondario a quello primario.
1. Verifica che il Replicator esistente che copia i dati dal cluster primario a quello secondario abbia lo stato «RUNNING» e il `ReplicatorThroughput` parametro in Amazon. CloudWatch `0`
*Tieni presente che quando crei un nuovo Replicator con la posizione iniziale Earliest for failback, inizia a leggere tutti i dati negli argomenti relativi ai cluster secondari.* A seconda delle impostazioni di conservazione dei dati, gli argomenti possono contenere dati provenienti dal cluster di origine. Sebbene MSK Replicator filtri automaticamente tali messaggi, dovrete comunque sostenere costi di elaborazione e trasferimento dei dati per tutti i dati del cluster secondario. È possibile tenere traccia del totale dei dati elaborati dal replicatore utilizzando. `ReplicatorBytesInPerSec` Per informazioni, consulta [Parametri del replicatore MSK](msk-replicator-monitor.md#msk-replicator-metrics).
Se utilizzi la configurazione dei nomi degli argomenti con prefisso, segui questi passaggi:
È necessario avviare le fasi di failback solo dopo che la replica dal cluster nella regione secondaria al cluster nella regione primaria è stata ripristinata e il MessageLag parametro in CloudWatch Amazon è vicino a 0. Un failback pianificato non dovrebbe comportare la perdita di dati.
1. Arresta tutti i produttori e i consumatori che si connettono al cluster MSK nella regione secondaria.
1. Per la topologia attiva-passiva, elimina il replicatore che replica i dati dal cluster nella regione secondaria alla regione primaria. Non è necessario eliminare il replicatore per la topologia attiva-attiva.
1. Avvia i produttori che si connettono al cluster MSK nella regione primaria.
1. A seconda dei requisiti di ordinamento dei messaggi dell'applicazione, segui i passaggi indicati in una delle schede seguenti.
------
#### [ No message ordering ]
Se la tua applicazione non richiede l'ordinamento dei messaggi, avvia i consumatori della AWS regione primaria che leggono sia gli argomenti locali (ad esempio`topic`) che quelli replicati (ad esempio) utilizzando un operatore wildcard (ad esempio,`.topic`). `.*topic` I consumatori sugli argomenti locali (ad esempio: topic) riprenderanno dall'ultimo offset utilizzato prima del failover. Se erano presenti dati non elaborati prima del failover, verranno elaborati ora. Nel caso di un failover pianificato, tale record non dovrebbe esistere.
------
#### [ Message ordering ]
1. Avvia i consumatori solo per gli argomenti replicati nella regione primaria (ad esempio, `.topic`) ma non per gli argomenti locali (ad esempio, `topic`).
1. Attendi che tutti i consumatori degli argomenti replicati sul cluster nella regione primaria completino l'elaborazione di tutti i dati, in modo che il ritardo di offset sia 0 e anche il numero di record elaborati sia 0. Quindi, interrompi i consumatori per gli argomenti replicati sul cluster nella regione primaria. A questo punto, tutti i record prodotti nella regione secondaria dopo il failover sono stati utilizzati nella regione primaria.
1. Avvia i consumatori per gli argomenti locali (ad esempio, `topic`) sul cluster nella regione primaria.
------
1. Verificate che il replicatore esistente dal cluster nella regione primaria al cluster nella regione secondaria sia nello stato RUNNING e funzioni come previsto utilizzando le `ReplicatorThroughput` metriche di latenza e.
# Creare una configurazione attiva-attiva utilizzando MSK Replicator
**Se si desidera creare una configurazione attiva-attiva in cui entrambi i cluster MSK eseguano attivamente operazioni di lettura e scrittura, si consiglia di utilizzare un replicatore MSK con replica dei nomi degli argomenti con prefisso (aggiungi il prefisso al nome degli argomenti nella console).** Tuttavia, ciò richiederà la riconfigurazione dei consumatori per la lettura degli argomenti replicati.
Segui questi passaggi per configurare la topologia attiva-attiva tra il cluster MSK di origine A e il cluster MSK di destinazione B.
1. Crea un replicatore MSK con il cluster MSK A come origine e il cluster MSK B come destinazione.
1. Dopo aver creato correttamente il replicatore MSK precedente, crea un replicatore con il cluster B come origine e il cluster A come destinazione.
1. Crea due set di produttori, ognuno dei quali scrive i dati contemporaneamente nell'argomento locale (ad esempio, "topic") nel cluster nella stessa regione del produttore.
1. Crea due set di consumatori, ciascuno dei quali legge i dati utilizzando un abbonamento wildcard (ad esempio». \$1topic») dal cluster MSK nella stessa AWS regione del consumatore. In questo modo, i consumatori leggeranno automaticamente i dati prodotti localmente nella regione dall'argomento locale (ad esempio, `topic`), nonché i dati replicati dall'altra regione nell'argomento con il prefisso `.topic`. Questi due gruppi di consumatori devono avere gruppi di consumatori diversi in IDs modo che gli offset dei gruppi di consumatori non vengano sovrascritti quando MSK Replicator li copia nell'altro cluster.
Se si desidera evitare la riconfigurazione dei client, anziché utilizzare la replica dei nomi degli argomenti con prefisso (**aggiungere il prefisso al nome degli argomenti nella console), è possibile creare i replicatori MSK utilizzando la replica dei nomi** degli argomenti identici (**Mantieni** lo stesso nome degli argomenti nella console) per creare una configurazione attiva-attiva. Tuttavia, pagherete costi aggiuntivi per l'elaborazione e il trasferimento dei dati per ogni Replicator. Questo perché ogni replicatore dovrà elaborare il doppio della normale quantità di dati, una volta per la replica e un'altra per evitare cicli infiniti. È possibile tenere traccia della quantità totale di dati elaborati da ciascun replicatore utilizzando la metrica. `ReplicatorBytesInPerSec` Per informazioni, consulta [Monitoraggio della replica](msk-replicator-monitor.md). Questa metrica include i dati replicati nel cluster di destinazione e i dati filtrati da MSK Replicator per evitare che i dati vengano ricondotti allo stesso argomento da cui provengono.
**Nota**
Se utilizzi la replica identica dei nomi degli argomenti (**Mantieni lo stesso nome degli argomenti** nella console) per configurare una topologia attiva-attiva, attendi almeno 30 secondi dopo aver eliminato un argomento prima di ricrearne uno con lo stesso nome. Questo periodo di attesa consente di evitare che i messaggi duplicati vengano replicati nel cluster di origine. I consumatori devono essere in grado di rielaborare i messaggi duplicati senza ripercussioni a valle. Per informazioni, consulta [Considerazioni per la creazione di applicazioni Apache Kafka multiregione](msk-replicator-increase-resiliency.md#msk-replication-multi-region-kafka-applications).