Migración a un clúster de Amazon MSK

El Replicador Amazon MSK se puede utilizar para la migración de clústeres de MSK. Consulte ¿Qué es Amazon MSK Replicator?. Como alternativa, puede usar Apache MirrorMaker 2.0 para migrar de un clúster que no sea de MSK a uno de Amazon MSK. Para ver un ejemplo de cómo hacerlo, consulte Migrar un clúster de Apache Kafka local a Amazon MSK mediante. MirrorMaker Para obtener información sobre cómo usarlo MirrorMaker, consulte Reflejar datos entre clústeres en la documentación de Apache Kafka. Recomendamos configurarlo MirrorMaker en una configuración de alta disponibilidad.

Un resumen de los pasos a seguir para migrar MirrorMaker a un clúster de MSK

1. Cree el clúster de MSK de destino

2. Comience MirrorMaker desde una instancia de Amazon EC2 dentro de la misma Amazon VPC que el clúster de destino.

3. Inspeccione el retraso MirrorMaker .

4. Cuando se MirrorMaker ponga al día, redirija a los productores y consumidores al nuevo clúster utilizando los intermediarios bootstrap del clúster de MSK.

5. Cierre. MirrorMaker

Migración de su clúster de Apache Kafka a Amazon MSK

Supongamos que tiene un clúster de Apache Kafka llamado CLUSTER_ONPREM. Dicho clúster se rellena con temas y datos. Si desea migrar dicho clúster a un nuevo clúster de Amazon MSK llamado CLUSTER_AWSMSK, este procedimiento ofrece una gran perspectiva de los pasos que debe seguir.

Migración de su clúster de Apache Kafka existente a Amazon MSK

1. En CLUSTER_AWSMSK, cree todos los temas que desee migrar.

   No puede utilizar MirrorMaker este paso porque no vuelve a crear automáticamente los temas que desea migrar con el nivel de replicación adecuado. Puede crear los temas en Amazon MSK con los mismos factores de replicación y números de particiones que tuviesen en CLUSTER_ONPREM. También puede crear los temas con distintos factores de replicación y números de particiones.

2. Comience MirrorMaker desde una instancia que tenga acceso de lectura CLUSTER_ONPREM y acceso de escritura. CLUSTER_AWSMSK

3. Ejecute el siguiente comando para duplicar todos los temas:

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

   En este comando, config/mirrormaker-consumer.properties señala a un agente de arranque en CLUSTER_ONPREM, por ejemplo, bootstrap.servers=localhost:9092. Y config/mirrormaker-producer.properties apunta a un agente de arranque en CLUSTER_AWSMSK; por ejemplo,. bootstrap.servers=10.0.0.237:9092,10.0.2.196:9092,10.0.1.233:9092

4. Siga MirrorMaker ejecutándose en segundo plano y continúe usándolo. CLUSTER_ONPREM MirrorMaker refleja todos los datos nuevos.

5. Compruebe el progreso de la duplicación inspeccionando el desfase entre el último desfase de cada tema y el desfase actual que se MirrorMaker está consumiendo.

   Recuerde que MirrorMaker se trata simplemente de utilizar un consumidor y un productor. Por lo tanto, puede comprobar el intervalo utilizando la herramienta kafka-consumer-groups.sh. Para localizar el nombre del grupo de consumidores, mire en el archivo mirrormaker-consumer.properties para el group.id y utilice su valor. Si en el archivo no se encuentra dicha clave, puede crearla. Por ejemplo, establezca group.id=mirrormaker-consumer-group.

6. Cuando MirrorMaker termine de reflejar todos los temas, detenga a todos los productores y consumidores y, a continuación, pare. MirrorMaker A continuación, redirija a los productores y los consumidores al clúster de CLUSTER_AWSMSK cargando los valores de los agentes de arranque de sus productores y consumidores. Reinicie todos los productores y consumidores en CLUSTER_AWSMSK.

Migración de un clúster de Amazon MSK a otro

Puede usar Apache MirrorMaker 2.0 para migrar de un clúster que no sea de MSK a uno de MSK. Por ejemplo, puede migrar de una versión de Apache Kafka a otra. Para ver un ejemplo de cómo hacerlo, consulte Migrar un clúster de Apache Kafka local a Amazon MSK mediante. MirrorMaker De forma alternativa, el Replicador Amazon MSK se puede utilizar para la migración de clústeres de MSK. Para obtener más información acerca del Replicador Amazon MSK, consulte MSKReplicador.

MirrorMaker Mejores prácticas de la versión 1.0

Esta lista de mejores prácticas se aplica a la MirrorMaker versión 1.0.

• Ejecute MirrorMaker en el clúster de destino. De esta forma, si se produce un problema de red, los mensajes seguirán estando disponibles en el clúster de origen. Si se ejecuta MirrorMaker en el clúster de origen y los eventos están almacenados en el productor y hay un problema de red, es posible que se pierdan los eventos.

• Si en el tránsito es necesario cifrar, hágalo en el clúster de origen.

• Para los consumidores, establezca auto.commit.enabled=false

• Para los productores, establezca

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

  • retries=Int.Max_Value

  • acks=all

  • max.block.ms = Long.Max_Value

• Para un alto rendimiento del productor:

  • Almacene mensajes en búfer y rellene lotes de mensajes: tune buffer.memory, batch.size, linger.ms

  • Ajuste los búferes de conectores: receive.buffer.bytes, send.buffer.bytes

• Para evitar la pérdida de datos, desactive la confirmación automática en el origen para que MirrorMaker pueda controlar las confirmaciones, lo que suele hacer después de recibir el paquete del clúster de destino. Si el productor tiene acks=all y el clúster de destino tiene min.insync.replicas establecido en más de 1, los mensajes se conservan en más de un intermediario en el destino antes de que el consumidor confirme la compensación en el origen. MirrorMaker

• Si el orden es importante, puede establecer los reintentos en 0. De manera alternativa, para un entorno de producción, establezca las conexiones en tránsito máximas en 1 para garantizar que los lotes enviados no se envían fuera del orden si un lote produce un error a la mitad. De esta forma, cada lote enviado se vuelve a intentar hasta que el siguiente lote se envía. Si max.block.ms no se establece al valor mínimo y el búfer del producto está completo, puede haber pérdida de datos (dependiendo de otras configuraciones). Esto puede bloquear y ejercer presión contra el consumidor.

• Para un gran rendimiento

  • Aumente la memoria del búfer.

  • Aumente el tamaño del lote.

  • Sincronice linger.ms para permitir que los lotes se completen. Esto también permite una mejor compresión, menos uso de la banda ancha de red y menos almacenamiento en el clúster. Todo esto resultar en una mayor retención.

  • Supervisar el uso de la memoria y la CPU.

• Para un gran rendimiento del consumidor

  • Aumente el número de subprocesos o consumidores por proceso (num.streams). MirrorMaker

  • Aumente primero la cantidad de MirrorMaker procesos en las máquinas antes de aumentar los subprocesos para permitir una alta disponibilidad.

  • Aumente la cantidad de MirrorMaker procesos primero en la misma máquina y, después, en máquinas diferentes (con el mismo ID de grupo).

  • Aísle los temas que tengan un rendimiento muy alto y utilice MirrorMaker instancias independientes.

• Para la administración y la configuración

  • Utilice AWS CloudFormation y configure herramientas de administración como Chef y Ansible.

  • Utilice montajes de Amazon EFS para mantener accesibles todos los archivos de configuración desde todas las instancias de Amazon EC2.

  • Utilice contenedores para facilitar el escalado y la administración de las MirrorMaker instancias.

• Por lo general, se necesita más de un consumidor para saturar a un productor. MirrorMaker Por lo tanto, configure varios consumidores. En primer lugar, configúrelos en diferentes equipos para proporcionar alta disponibilidad. A continuación, escale equipos individuales hasta tener un consumidor para cada partición, con los consumidores distribuidos equitativamente entre los equipos.

• Para la adquisición y entrega de alto rendimiento, ajuste los búferes de recepción y envío, porque sus valores predeterminados podrían ser demasiado bajos. Para obtener el máximo rendimiento, asegúrese de que el número total de transmisiones (num.streams) coincida con todas las particiones temáticas que MirrorMaker se están intentando copiar al clúster de destino.

MirrorMaker 2.* ventajas

• Hace uso del marco y ecosistema de Apache Kafka Connect.

• Detecta nuevos temas y particiones.

• Sincroniza automáticamente la configuración de temas entre clústeres.

• Admite pares de clústeres «activo/activo», así como cualquier número de clústeres activos.

• Proporciona nuevas métricas, incluida la latencia de end-to-end replicación en varios centros de datos y clústeres.

• Emite las compensaciones necesarias para migrar consumidores entre clústeres y proporciona herramientas para traducir compensaciones.

• Admite un archivo de configuración de alto nivel para especificar varios clústeres y flujos de replicación en un solo lugar, en comparación con las propiedades de productor/consumidor de bajo nivel de cada MirrorMaker proceso 1.*.