Migrar as cargas de trabalho do Apache Kafka para o Azure HDInsight 4.0
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.
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.
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.
Para concluir a migração, execute as seguintes etapas:
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.
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.
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.
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.