Compartilhar via

Migrar cargas de trabalho do Apache Kafka para o Azure HDInsight 5.1

O Azure HDInsight 5.1 oferece os mais recentes componentes de código aberto com aprimoramentos importantes em desempenho, conectividade e segurança. Este documento explica como migrar cargas de trabalho do Apache Kafka no HDInsight 4.0 (Kafka 2.1) para o HDInsight 5.1 (Kafka 3.2).

Versões do Apache Kafka

Apache Kafka 3.2.0

Se você migrar para o Kafka 3.2.0 (HDI 5.1), poderá aproveitar os seguintes novos recursos:

  • Suporte à sincronização automatizada de deslocamentos de consumidores entre clusters no MM 2.0, o que facilita migrar ou fazer failover de consumidores entre clusters KIP-545.
  • Dica para o líder de partição recuperar a partição: um novo recurso que permite que o controlador se comunique com um líder de partição de tópico recém-eleito, caso precise recuperar o estado dele KIP-704.
  • Dá suporte ao TLS 1.2 por padrão para comunicação segura.
  • Remoção de dependência do Zookeeper: produtores e consumidores não precisam mais do parâmetro zookeeper. Use a opção --bootstrap-server em vez de --zookeeper com os comandos da CLI KIP-500.
  • Tamanho da lista de pendências configurável para a criação do Acceptor: uma nova configuração que permite definir o tamanho da lista de pendências do SYN para os soquetes de aceitação do TCP nos agentes KIP-764.
  • Campo de código de erro de nível superior para DescribeLogDirsResponse: um novo código de erro que torna a API DescribeLogDirs consistente com outras APIs e permite retornar outros erros além de CLUSTER_AUTHORIZATION_FAILED KIP-784.

Para obter uma lista completa de atualizações, consulte Notas sobre a versão do Apache Kafka 3.2.0.

Compatibilidade do cliente Kafka

Novos agentes Kafka dão suporte a clientes mais antigos. KIP-35 - Recuperando versão de protocolo introduziu um mecanismo para determinar dinamicamente a funcionalidade de um agente Kafka e KIP-97: a política de compatibilidade de RPC de cliente Kafka aprimorada introduziu uma nova política de compatibilidade e garantias para o cliente Java. Anteriormente, um cliente Kafka tinha que interagir com um agente da mesma versão ou uma versão mais recente. Agora, as versões mais recentes dos clientes Java e outros clientes que dão suporte ao KIP-35, como librdkafka podem recorrer a tipos de solicitação mais antigos ou gerar erros apropriados se a funcionalidade não estiver disponível.

Screenshot shows Upgrade Kafka client compatibility.

Observação

É recomendável usar a versão do cliente do kafka da mesma forma que as versões do cluster. Para obter mais informações, consulte Matriz de compatibilidade.

Processo de migração geral

As diretrizes de migração a seguir consideram um cluster do Apache Kafka 2.1.1 implantado no HDInsight 4.0 em uma única rede virtual. O agente existente tem alguns tópicos e está sendo usado ativamente por produtores e consumidores. Não há suporte para a atualização da versão Kafka em um cluster existente. Depois de criar um cluster com a HDI 5.1, migre os clientes do Kafka para usar o novo cluster.

Para concluir a migração, execute as seguintes etapas:

  1. Implantar um novo cluster do HDInsight 5.1 e clientes para teste. Implantar um novo cluster do Kafka HDInsight 5.1. Se várias versões de cluster Kafka puderem ser selecionadas, é recomendável selecionar a versão mais recente. Após a implantação, defina alguns parâmetros conforme necessário e crie um tópico com o mesmo nome de seu ambiente existente. Além disso, defina TLS e criptografia BYOK (traga sua própria chave) conforme necessário. Em seguida, verifique se ele funciona corretamente com o novo cluster.

    Screenshot shows how to Deploy new HDInsight 5.1 clusters.

  2. Alterne o cluster para o aplicativo produtor e aguarde até que todos os dados da fila sejam consumidos pelos consumidores atuais. Quando o novo cluster do Kafka HDInsight 5.1 estiver pronto, alterne o destino do produtor existente para o novo cluster. Deixe-o como se encontrar até que o aplicativo consumidor existente tenha consumido todos os dados do cluster existente.

    Screenshot shows how to Switch cluster for producer app.

  3. Alterne o cluster no aplicativo consumidor. Depois de confirmar que o aplicativo consumidor existente concluiu o consumo de todos os dados do cluster existente, alterne a conexão para o novo cluster.

    Screenshot shows how to Switch cluster on consumer app.

  4. Remova o cluster antigo e os aplicativos de teste, conforme necessário. Depois que o comutador estiver concluído e funcionando corretamente, remova o antigo cluster do Kafka HDInsight 4.0 e os produtores e consumidores usados no teste, conforme necessário.

Próximas etapas