Migración de cargas de trabajo de Apache Kafka a Azure HDInsight 4.0

Azure HDInsight 4.0 ofrece los componentes de código abierto más recientes con mejoras significativas en el rendimiento, la conectividad y la seguridad. En este documento se explica cómo migrar las cargas de trabajo de Apache Kafka en HDInsight 3.6 a HDInsight 4.0. Después de migrar las cargas de trabajo a HDInsight 4.0, podrá usar muchas de las nuevas características que no están disponibles en HDInsight 3.6.

Rutas de migración de HDInsight 3.6 Kafka

HDInsight 3.6 admite dos versiones de Kafka: 1.0.0 y 1.1.0. HDInsight 4.0 es compatible con las versiones 1.1.0 y 2.1.0. En función de la versión de Kafka y de la versión de HDInsight que desee ejecutar, hay varias rutas de migración admitidas. Estas rutas se explican a continuación y se ilustran en el diagrama siguiente.

• Ejecutar las versiones más recientes de Kafka y HDInsight (recomendado) : migre una aplicación de HDInsight 3.6 y Kafka 1.0.0 o 1.1.0 a HDInsight 4.0 con Kafka 2.1.0 (rutas D y E del diagrama).
• Ejecutar la versión más reciente de HDInsight, pero solo una versión más reciente de Kafka: migre una aplicación de HDInsight 3.6 y Kafka 1.0.0 a HDInsight 4.0 con Kafka 1.1.0 (ruta B del diagrama).
• Ejecutar HDInsight en la versión más reciente, conservar la versión de Kafka: migre una aplicación de HDInsight 3.6 y Kafka 1.1.0 a HDInsight 4.0 con Kafka 1.1.0 (ruta C del diagrama).
• Ejecutar Kafka en una versión más reciente, conservar la versión de HDInsight: migre una aplicación de Kafka 1.0.0 a 1.1.0 y permanecer en HDInsight 3.6 (ruta A del diagrama). Tenga en cuenta que con esta opción se sigue requiriendo implementar un nuevo clúster. No se admite la actualización de la versión de Kafka en un clúster existente. Después de crear un clúster con la versión que desee, migre los clientes de Kafka para que usen el nuevo clúster.

Versiones de Apache Kafka

Kafka 1.1.0

Si migra de Kafka 1.0.0 a 1.1.0, puede aprovechar las siguientes características nuevas:

• Las mejoras en el controlador de Kafka agilizan el cierre controlado, por lo que puede reiniciar los agentes y recuperarse de los problemas más rápidamente.
• Las mejoras en la lógica de FetchRequests que permiten tener más particiones (y, por tanto, más temas) en el clúster.
• Kafka Connect admite encabezados de registro y expresiones regulares para temas.

Para obtener una lista completa de las actualizaciones, vea las notas de la versión de Apache Kafka 1.1.

Apache Kafka 2.1.0

Si migra a Kafka 2.1, puede aprovechar las siguientes características nuevas:

• Mejora de la resistencia del agente debido a un protocolo de replicación mejorado.
• Nueva funcionalidad de la API KafkaAdminClient.
• Administración de cuotas configurable.
• Compatibilidad con la compresión Zstandard.

Para obtener una lista completa de las actualizaciones, vea las notas de la versión de Apache Kafka 2.0 y las notas de la versión de Apache Kafka 2.1.

Compatibilidad con el cliente de Kafka

Los nuevos agentes de Kafka admiten clientes más antiguos. KIP-35: recuperación de la versión de protocolo presentó un mecanismo para determinar de forma dinámica la funcionalidad de un agente de Kafka y KIP-97: mejora de la directiva de compatibilidad de RPC de cliente de Kafka presentó una nueva directiva de compatibilidad y garantías para el cliente de Java. Anteriormente, un cliente de Kafka tenía que interactuar con un agente de la misma versión o una versión más reciente. Ahora, las versiones más recientes de los clientes de Java y otros clientes que admiten KIP-35, como librdkafka, pueden revertir a tipos de solicitud anteriores o producir errores adecuados si la funcionalidad no está disponible.

Tenga en cuenta que no significa que el cliente admita agentes más antiguos. Para obtener más información, vea Matriz de compatibilidad.

Proceso de migración general

En la siguiente guía de migración se asume un clúster de Apache Kafka 1.0.0 o 1.1.0 implementado en HDInsight 3.6 en una única red virtual. El agente existente tiene algunos temas y los productores y consumidores los utilizan activamente.

Realice los pasos siguientes para completar la migración:

1. Implemente un nuevo clúster y clientes de HDInsight 4.0 para la prueba. Implemente un nuevo clúster de HDInsight 4.0 Kafka. Si se pueden seleccionar varias versiones de clúster de Kafka, se recomienda seleccionar la versión más reciente. Después de la implementación, establezca algunos parámetros necesarios y cree un tema con el mismo nombre que el del entorno existente. Además, establezca el cifrado TLS y Bring Your Own Key (BYOK) según sea necesario. A continuación, compruebe si funciona correctamente con el nuevo clúster.

   

2. Cambie el clúster para la aplicación de productor y espere hasta que los consumidores actuales consuman todos los datos de la cola. Cuando el nuevo clúster de HDInsight 4.0 Kafka esté listo, cambie el destino del productor existente al nuevo clúster. Déjelo como está hasta que la aplicación de consumidor existente haya consumido todos los datos del clúster existente.

   

3. Cambie el clúster en la aplicación de consumidor. Después de confirmar que la aplicación de consumidor existente ha terminado de consumir todos los datos del clúster existente, cambie la conexión al nuevo clúster.

   

4. Quite el clúster anterior y pruebe las aplicaciones según sea necesario. Una vez completado el cambio y que funcione correctamente, quite el antiguo clúster de HDInsight 3.6 Kafka y los productores y consumidores que se usan en la prueba, según sea necesario.

Pasos siguientes

• Optimización del rendimiento para los clústeres de Apache Kafka HDInsight
• Inicio rápido: Creación de un clúster de Apache Kafka en Azure HDInsight mediante Azure Portal