Migrazione di cluster utilizzando Apache Kafka MirrorMaker

Puoi eseguire il mirroring o la migrazione del cluster utilizzando MirrorMaker, che fa parte di Apache Kafka. Ad esempio, puoi utilizzarlo per eseguire la migrazione del cluster Apache Kafka in Amazon MSK o per eseguire la migrazione da un cluster MSK a un altro. Per informazioni su come utilizzare MirrorMaker, consulta.Mirroring dei dati tra clusternella documentazione di Apache Kafka. Consigliamo la configurazione MirrorMaker in una configurazione a disponibilità elevata.

Una descrizione delle fasi da seguire quando si utilizza MirrorMaker per eseguire la migrazione in un cluster MSK

1. Creare il cluster MSK di destinazione

2. Avvio delle MirrorMaker da un'istanza Amazon EC2 all'interno dello stesso Amazon VPC del cluster di destinazione.

3. Ispezionare l' MirrorMaker Ritardo.

4. Dopo MirrorMaker recupera, reindirizza produttori e consumatori al nuovo cluster utilizzando i broker bootstrap del cluster MSK.

5. Arresto del sistema MirrorMaker.

Migrazione del cluster Apache Kafka in Amazon MSK

Supponi di disporre di un cluster Apache Kafka denominato CLUSTER_ONPREM, popolato con argomenti e dati. Se desideri migrare il cluster in un cluster Amazon MSK appena creato denominatoCLUSTER_AWSMSK, questa procedura fornisce una visualizzazione di alto livello delle fasi che occorre seguire.

Per eseguire la migrazione del cluster Apache Kafka esistente in Amazon MSK

1. In CLUSTER_AWSMSK, creare tutti gli argomenti che desideri migrare.

   Non puoi utilizzare MirrorMaker per questa fase perché non ricrea automaticamente gli argomenti che desideri migrare con il livello di replica corretto. Puoi creare gli argomenti in Amazon MSK con gli stessi fattori di replica e numeri di partizioni che esistevano inCLUSTER_ONPREM. È possibile inoltre creare gli argomenti con diversi fattori di replica e numeri di partizioni.

2. Avvio delle MirrorMaker da un'istanza che dispone dell'accesso in lettura aCLUSTER_ONPREMe l'accesso in scrittura aCLUSTER_AWSMSK.

3. Eseguire il comando seguente per creare una copia speculare di tutti gli argomenti:

   <path-to-your-kafka-installation>/bin/kafka-mirror-maker.sh --consumer.config config/mirrormaker-consumer.properties --producer.config config/mirrormaker-producer.properties --whitelist '.*'

   In questo comando, config/mirrormaker-consumer.properties punta a un broker bootstrap in CLUSTER_ONPREM; ad esempio, bootstrap.servers=localhost:9092. Econfig/mirrormaker-producer.propertiespunta a un broker bootstrap in CLUSTER_AWSMSK; ad esempio,bootstrap.servers=10.0.0.237:9092,10.0.2.196:9092,10.0.1.233:9092.

4. Keep MirrorMaker in esecuzione in background e continuare a utilizzareCLUSTER_ONPREM. MirrorMaker mirroring di tutti i nuovi dati.

5. Controllare lo stato di avanzamento del mirroring esaminando il ritardo tra l'ultimo offset per ogni argomento e l'offset corrente da cui MirrorMaker sta consumando.

   Ricordare che MirrorMaker utilizza semplicemente un consumatore e un produttore. Quindi, è possibile controllare il ritardo usando lo strumento kafka-consumer-groups.sh. Per trovare il nome del gruppo di consumatori, cercare all'interno del file group.id mirrormaker-consumer.properties e utilizzare il suo valore. Se tale chiave non esiste nel file, è possibile crearla. Ad esempio, impostare group.id=mirrormaker-consumer-group.

6. Dopo MirrorMaker termina il mirroring di tutti gli argomenti, interrompere tutti i produttori e i consumatori e quindi interrompere MirrorMaker. Quindi, reindirizzare i produttori e i consumatori al cluster CLUSTER_AWSMSK modificando i relativi valori dei broker bootstrap del produttore e del consumatore. Riavviare tutti i produttori e i consumatori su CLUSTER_AWSMSK.

Migrazione da un cluster Amazon MSK a un altro

Puoi usare Apache MirrorMaker per eseguire la migrazione di un cluster MSK in un altro cluster. Ad esempio, puoi eseguire la migrazione da una versione di Apache Kafka a un'altra. Per un esempio di come utilizzareAWS CloudFormationper eseguire questa operazione, consulta.AWS::MSK::Cluster Esempi(cerca l'esempio intitolatoCreate Two MSK Clusters To Use With Apache MirrorMaker.

MirrorMaker Best practice 1.0

Questo elenco di best practice si applica a MirrorMaker 1.0.

• Esegui MirrorMaker sul cluster di destinazione. In questo modo, se si verifica un problema di rete, i messaggi sono ancora disponibili nel cluster di origine. Se corri MirrorMaker sul cluster di origine e gli eventi vengono memorizzati nel produttore e si verifica un problema di rete, gli eventi potrebbero andare persi.

• Se è richiesta la crittografia dei dati in transito, eseguirla nel cluster di origine.

• Per i consumatori, impostare auto.commit.enabled=false

• Per i produttori, impostare

  • max.in.flight.requests.per.connection=1

  • retries=Int.Max_Value

  • acks=all

  • max.block.ms = Long.Max_Value

• Per un elevato throughput produttore:

  • Esegui il buffer di messaggi e compila batch di messaggi: tune buffer.memory, batch.size, linger.ms

  • Ottimizza buffer socket — receive.buffer.bytes, send.buffer.bytes

• Per evitare la perdita di dati, disattiva il commit auto all'origine, per evitare la perdita di dati MirrorMaker può controllare i commit, operazione che in genere esegue dopo aver ricevuto l'ack dal cluster di destinazione. Se per il produttore è impostato su un valore maggiore di 1, i messaggi vengono conservati su più broker a il MirrorMaker consumer impegna l'offset alla fonte.

• Se l'ordine è importante, puoi impostare i tentativi su 0. In alternativa, per un ambiente di produzione, imposta il numero massimo di connessioni in transito su 1 per garantire che non venga eseguito il commit dei batch inviati senza seguire un ordine se un batch non riesce a metà. In questo modo, ogni batch inviato viene ritentato finché il batch successivo non viene inviato. Se max.block.ms non è impostato sul valore massimo e se il buffer del produttore è pieno, potrebbe verificarsi una perdita di dati (a seconda di alcune delle altre impostazioni). Questo può bloccare e causare uno stato di congestione nel consumatore.

• Per elevato throughput

  • Incrementa buffer.memory.

  • Incrementa le dimensioni batch.

  • Ottimizza linger.ms per consentire il riempimento dei batch. Ciò consente inoltre una migliore compressione, meno utilizzo della larghezza di banda della rete e meno storage sul cluster. Questo comporta un aumento della conservazione.

  • Monitora l'utilizzo della CPU e della memoria.

• Per elevato throughput consumatore

  • Aumentare il numero di thread/consumatori per MirrorMaker processo — num.streams.

  • Aumentare il numero di MirrorMaker esegue i processi tra macchine prima di incrementare i thread per consentire elevata disponibilità.

  • Aumentare il numero di MirrorMaker esegue prima sulla stessa macchina e poi su macchine diverse (con lo stesso ID gruppo).

  • Isola gli argomenti con throughput molto elevato e utilizzare gli argomenti con throughput elevato MirrorMaker istanze.

• Per gestione e configurazione

  • Utilizza AWS CloudFormation e strumenti di gestione della configurazione come Chef e Ansible.

  • Utilizza montaggi Amazon EFS per mantenere tutti i file di configurazione accessibili da tutte le istanze Amazon EC2.

  • Utilizza i container per semplificare il dimensionamento e la gestione di MirrorMakeristanze.

• In genere, sono necessari più consumatori per saturare un produttore in MirrorMaker. Pertanto, configura più consumatori. Innanzitutto, configurali su macchine diverse per fornire elevata disponibilità. Quindi, dimensiona le singole macchine fino ad avere un consumatore per ogni partizione, con i consumatori distribuiti in modo uniforme tra le macchine.

• Per elevato throughput di inserimento e consegna, ottimizza i buffer di ricezione e invio perché le relative impostazione predefinite potrebbero essere troppo basse. Per raggiungere prestazioni massime, assicurati che il numero totale di flussi (num.streams) corrisponda a tutte le partizioni argomento che MirrorMaker sta tentando di eseguire la copia nel cluster di destinazione.

MirrorMaker 2.* vantaggi

• Utilizza il framework e l'ecosistema Apache Kafka Connect.

• Rileva nuovi argomenti e partizioni.

• Sincronizza automaticamente la configurazione degli argomenti tra cluster.

• Supporta coppie di cluster "attiva/attiva", così come qualsiasi numero di cluster attivi.

• Fornisce nuovi parametri, tra cui end-to-end latenza di replica tra più data center e cluster.

• Emette gli offset necessari per eseguire la migrazione dei consumatori tra cluster e fornisce strumenti per la traslazione dell'offset.

• Supporta un file di configurazione di alto livello per la specifica di più cluster e flussi di replica in un'unica posizione, rispetto alle proprietà produttore/consumatore di basso livello per ogni MirrorMaker 1.* processo.