Migrar as cargas de trabalho do Apache Kafka para o Azure HDInsight 4.0

  • Artigo

O Azure HDInsight 4.0 oferece os mais recentes componentes open-source com melhorias significativas no desempenho, conectividade e segurança. Este documento explica como migrar cargas de trabalho do Apache Kafka no HDInsight 3.6 para o HDInsight 4.0. Depois de migrar suas cargas de trabalho para o HDInsight 4.0, você pode usar muitos dos novos recursos que não estão disponíveis no HDInsight 3.6.

Caminhos de migração do HDInsight 3.6 Kafka

O HDInsight 3.6 suporta duas versões do Kafka: 1.0.0 e 1.1.0. O HDInsight 4.0 suporta as versões 1.1.0 e 2.1.0. Dependendo da versão do Kafka e da versão do HDInsight que você gostaria de executar, há vários caminhos de migração suportados. Esses caminhos são explicados abaixo e ilustrados no diagrama a seguir.

  • Execute o Kafka e o HDInsight nas versões mais recentes (recomendado): migre um aplicativo HDInsight 3.6 e Kafka 1.0.0 ou 1.1.0 para o HDInsight 4.0 com Kafka 2.1.0 (caminhos D e E abaixo).
  • Execute o HDInsight na versão mais recente, mas o Kafka apenas em uma versão mais recente: migre um aplicativo HDInsight 3.6 e Kafka 1.0.0 para o HDInsight 4.0 com Kafka 1.1.0 (caminho B abaixo).
  • Execute o HDInsight na versão mais recente, mantenha a versão Kafka: migre um aplicativo HDInsight 3.6 e Kafka 1.1.0 para o HDInsight 4.0 com Kafka 1.1.0 (caminho C abaixo).
  • Execute o Kafka em uma versão mais recente, mantenha a versão do HDInsight: migre um aplicativo Kafka 1.0.0 para 1.1.0 e permaneça no HDInsight 3.6 (caminho A abaixo). Observe que essa opção ainda exigirá a implantação de um novo cluster. Não há suporte para a atualização da versão do Kafka em um cluster existente. Depois de criar um cluster com a versão desejada, migre seus clientes Kafka para usar o novo cluster.

Upgrade paths for Apache Kafka on 3.6.

Versões do Apache Kafka

Kafka 1.1.0

Se você migrar do Kafka 1.0.0 para o 1.1.0, poderá aproveitar os seguintes novos recursos:

  • Melhorias no controlador Kafka aceleram o desligamento controlado, para que você possa reiniciar corretores e se recuperar de problemas mais rapidamente.
  • Melhorias na lógica FetchRequests que permitem que você tenha mais partições (e, portanto, mais tópicos) no cluster.
  • Kafka Connect suporta cabeçalhos de registro e expressões regulares para tópicos.

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

Apache Kafka 2.1.0

Se você migrar para o Kafka 2.1, poderá aproveitar os seguintes recursos:

  • Melhor resiliência do broker devido a um protocolo de replicação aprimorado.
  • Nova funcionalidade na API KafkaAdminClient.
  • Gestão de quotas configurável.
  • Suporte para compressão Zstandard.

Para obter uma lista completa de atualizações, consulte Notas de versão do Apache Kafka 2.0 e Notas de versão do Apache Kafka 2.1.

Compatibilidade com o cliente Kafka

Novos corretores Kafka suportam clientes mais antigos. KIP-35 - A versão do protocolo de recuperação introduziu um mecanismo para determinar dinamicamente a funcionalidade de um broker Kafka e o KIP-97: A Política de Compatibilidade RPC do Cliente Kafka Melhorada introduziu uma nova política de compatibilidade e garantias para o cliente Java. Anteriormente, um cliente Kafka tinha que interagir com um corretor da mesma versão ou uma versão mais recente. Agora, versões mais recentes dos clientes Java e outros clientes que suportam KIP-35 podem librdkafka voltar para tipos de solicitação mais antigos ou lançar erros apropriados se a funcionalidade não estiver disponível.

Upgrade Kafka client compatibility.

Note que isso não significa que o cliente suporta corretores mais antigos. Para obter mais informações, consulte Matriz de compatibilidade.

Processo geral de migração

As diretrizes de migração a seguir pressupõem um cluster Apache Kafka 1.0.0 ou 1.1.0 implantado no HDInsight 3.6 em uma única rede virtual. O corretor existente tem alguns tópicos e está sendo usado ativamente por produtores e consumidores.

Current Kafka presumed environment.

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

  1. Implante um novo cluster HDInsight 4.0 e clientes para teste. Implante um novo cluster HDInsight 4.0 Kafka. Se várias versões do 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 do seu ambiente existente. Além disso, defina TLS e traga sua própria chave (BYOK) de criptografia conforme necessário. Em seguida, verifique se ele funciona corretamente com o novo cluster.

    Deploy new HDInsight 4.0 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 HDInsight 4.0 Kafka estiver pronto, alterne o destino do produtor existente para o novo cluster. Deixe-o como está até que o aplicativo Consumer existente tenha consumido todos os dados do cluster existente.

    Switch cluster for producer app.

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

    Switch cluster on consumer app.

  4. Remova o cluster antigo e teste os aplicativos conforme necessário. Quando o switch estiver completo e funcionando corretamente, remova o cluster HDInsight 3.6 Kafka antigo e os produtores e consumidores usados no teste, conforme necessário.

Próximos passos