Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Migre a un MSK clúster de Amazon
Amazon MSK Replicator se puede utilizar para la migración de MSK clústeres. Consulte ¿Qué es Amazon MSK Replicator?. Como alternativa, puede usar Apache MirrorMaker 2.0 para migrar de un clúster que no sea de un MSK clúster a uno de AmazonMSK. 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
Un resumen de los pasos a seguir MirrorMaker para migrar a un MSK clúster
Cree el MSK clúster de destino
Comience MirrorMaker desde una EC2 instancia de Amazon dentro del mismo Amazon VPC que el clúster de destino.
-
Inspecciona el MirrorMaker retraso.
-
Después de MirrorMaker ponerse al día, redirija a los productores y consumidores al nuevo clúster utilizando los agentes de arranque del MSK clúster.
-
Cierre. MirrorMaker
MirrorMaker Prácticas recomendadas 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 un búfer 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.
-
Uso del monitor y de la memoria. CPU
-
-
Para un gran rendimiento del consumidor
-
Aumente la cantidad de subprocesos o consumidores por MirrorMaker proceso (num.streams).
-
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.
-
Usa Amazon EFS mounts para mantener todos los archivos de configuración accesibles desde todas las EC2 instancias de Amazon.
-
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.
Ventajas de 2. MirrorMaker *
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 end-to-end la latencia de 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.*.
