Migrazione a un cluster Amazon MSK

Il replicatore Amazon MSK può essere utilizzato per eseguire la migrazione dei cluster MSK. Per informazioni, consulta Cos'è Amazon MSK Replicator?. In alternativa, puoi utilizzare Apache MirrorMaker 2.0 per migrare da un cluster non MSK a un cluster Amazon MSK. Per un esempio di come eseguire questa operazione, consulta Migrare un cluster Apache Kafka locale su Amazon MSK utilizzando. MirrorMaker Per informazioni sull'uso MirrorMaker, consulta Mirroring dei dati tra i cluster nella documentazione di Apache Kafka. Ti consigliamo di eseguire la configurazione in una configurazione ad alta MirrorMaker disponibilità.

Una descrizione dei passaggi da seguire quando si utilizza per MirrorMaker migrare a un cluster MSK

1. Creazione del cluster MSK di destinazione

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

3. Ispeziona il ritardo. MirrorMaker

4. Dopo aver MirrorMaker recuperato il ritardo, reindirizza produttori e consumatori al nuovo cluster utilizzando i broker bootstrap del cluster MSK.

5. MirrorMakerSpegnere.

Migrazione del cluster Apache Kafka ad Amazon MSK

Supponi di disporre di un cluster Apache Kafka denominato CLUSTER_ONPREM, popolato con argomenti e dati. Se desideri eseguire la migrazione di tale cluster in un nuovo cluster Amazon MSK denominato CLUSTER_AWSMSK, questa procedura fornisce una vista generale dei passaggi necessari.

Migrazione del cluster Apache Kafka esistente ad Amazon MSK

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

   Non puoi utilizzarlo MirrorMaker per questo passaggio perché non ricrea automaticamente gli argomenti che desideri migrare con il giusto livello di replica. È possibile creare gli argomenti in Amazon MSK con gli stessi fattori di replica e numeri di partizioni che esistevano in CLUSTER_ONPREM. È possibile inoltre creare gli argomenti con diversi fattori di replica e numeri di partizioni.

2. Inizia MirrorMaker da un'istanza con accesso in lettura CLUSTER_ONPREM e accesso in scrittura. CLUSTER_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. E config/mirrormaker-producer.properties indica un broker di bootstrap in CLUSTER_AWSMSK; ad esempio,. bootstrap.servers=10.0.0.237:9092,10.0.2.196:9092,10.0.1.233:9092

4. Continua a MirrorMaker funzionare in background e continua a utilizzare. CLUSTER_ONPREM MirrorMaker rispecchia tutti i nuovi dati.

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

   Ricorda che si MirrorMaker tratta semplicemente di utilizzare 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 aver MirrorMaker finito di rispecchiare tutti gli argomenti, interrompete tutti i produttori e i consumatori, e poi smettete 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

È possibile utilizzare Apache MirrorMaker 2.0 per migrare da un cluster non MSK a un cluster MSK. Ad esempio, puoi eseguire la migrazione da una versione di Apache Kafka a un'altra. Per un esempio di come eseguire questa operazione, consulta Migrare un cluster Apache Kafka locale su Amazon MSK utilizzando. MirrorMaker In alternativa, è possibile utilizzare il replicatore Amazon MSK per eseguire la migrazione dei cluster MSK. Per ulteriori informazioni sul replicatore Amazon MSK, consulta la pagina MSKReplicatore.

MirrorMaker 1.0 migliori pratiche

Questo elenco di best practice si applica alla MirrorMaker versione 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 esegui MirrorMaker sul cluster di origine e gli eventi sono memorizzati nel buffer nel produttore e c'è 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 i buffer dei socket: receive.buffer.bytes, send.buffer.bytes

• Per evitare la perdita di dati, disattiva il commit automatico all'origine, in modo che MirrorMaker possa controllare i commit, cosa che in genere esegue dopo aver ricevuto l'ack dal cluster di destinazione. Se il produttore ha acks=all e il cluster di destinazione ha impostato min.insync.replicas su più di 1, i messaggi vengono mantenuti su più di un broker nella destinazione prima che il consumatore esegua il commit dell'offset all'origine. MirrorMaker

• 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

  • Aumenta MirrorMaker il numero di thread/consumatori per processo: num.streams.

  • Aumenta il numero di MirrorMaker processi tra le macchine prima di aumentare i thread per consentire un'elevata disponibilità.

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

  • Isola gli argomenti con una velocità effettiva molto elevata e utilizza istanze separate MirrorMaker .

• Per gestione e configurazione

  • Strumenti di gestione AWS CloudFormation dell'uso e 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 contenitori per semplificare la scalabilità e la gestione delle MirrorMaker istanze.

• In genere, è necessario più di un consumatore per saturare un produttore. 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 ottenere le massime prestazioni, assicuratevi che il numero totale di stream (num.streams) corrisponda a tutte le partizioni degli argomenti che state tentando di copiare nel MirrorMaker 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 nuove metriche, tra cui end-to-end la latenza di replica su 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 specificare più cluster e flussi di replica in un'unica posizione, rispetto alle proprietà produttore/consumatore di basso livello per ogni processo 1.*. MirrorMaker