Migração para um cluster do Amazon MSK - Amazon Managed Streaming for Apache Kafka

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Migração para um cluster do Amazon MSK

O replicador do Amazon MSK pode ser usado para a migração do cluster do MSK. Consulte O que é o Amazon MSK Replicator?. Como alternativa, você pode usar o Apache MirrorMaker 2.0 para migrar de um cluster não MSK para um cluster Amazon MSK. Para obter um exemplo de como fazer isso, consulte Migrar um cluster Apache Kafka local para o Amazon MSK usando. MirrorMaker Para obter informações sobre como usar MirrorMaker, consulte Espelhamento de dados entre clusters na documentação do Apache Kafka. Recomendamos a configuração MirrorMaker em uma configuração altamente disponível.

Um resumo das etapas a serem seguidas ao usar MirrorMaker para migrar para um cluster MSK
  1. Criar o cluster de destino do MSK

  2. Comece MirrorMaker com uma instância do Amazon EC2 dentro da mesma Amazon VPC do cluster de destino.

  3. Inspecione o MirrorMaker atraso.

  4. Depois de MirrorMaker se atualizar, redirecione produtores e consumidores para o novo cluster usando os corretores de bootstrap do cluster MSK.

  5. Desligar MirrorMaker.

Migração do cluster do Apache Kafka para o Amazon MSK

Suponha que você tenha um cluster do Apache Kafka chamado CLUSTER_ONPREM. Esse cluster é preenchido com tópicos e dados. Se quiser migrar esse cluster para um cluster recém-criado do Amazon MSK chamado CLUSTER_AWSMSK, esse procedimento fornecerá uma visualização de alto nível das etapas que você deverá seguir.

Para migrar o cluster existente do Apache Kafka para o Amazon MSK
  1. No CLUSTER_AWSMSK, crie todos os tópicos que deseja migrar.

    Você não pode usar MirrorMaker essa etapa porque ela não recria automaticamente os tópicos que você deseja migrar com o nível de replicação correto. Você pode criar os tópicos no Amazon MSK com os mesmos fatores de replicação e números de partições que eles tinham em CLUSTER_ONPREM. Você também pode criar os tópicos com diferentes fatores de replicação e números de partições.

  2. Comece MirrorMaker com uma instância que tenha acesso de leitura CLUSTER_ONPREM e gravação CLUSTER_AWSMSK a.

  3. Execute o seguinte comando para espelhar todos os tópicos:

    <path-to-your-kafka-installation>/bin/kafka-mirror-maker.sh --consumer.config config/mirrormaker-consumer.properties --producer.config config/mirrormaker-producer.properties --whitelist '.*'

    Nesse comando, config/mirrormaker-consumer.properties aponta para um agente de bootstrap no CLUSTER_ONPREM; por exemplo, bootstrap.servers=localhost:9092. E config/mirrormaker-producer.properties aponta para um corretor de bootstrap em CLUSTER_AWSMSK; por exemplo,. bootstrap.servers=10.0.0.237:9092,10.0.2.196:9092,10.0.1.233:9092

  4. Continue MirrorMaker executando em segundo plano e continue usandoCLUSTER_ONPREM. MirrorMaker espelha todos os novos dados.

  5. Verifique o progresso do espelhamento inspecionando o intervalo entre o último deslocamento de cada tópico e o deslocamento atual do qual está sendo consumido. MirrorMaker

    Lembre-se de que MirrorMaker é simplesmente usar um consumidor e um produtor. Portanto, você pode verificar o atraso usando a ferramenta kafka-consumer-groups.sh. Para localizar o nome do grupo de consumidores, procure o group.id no arquivo mirrormaker-consumer.properties e use seu valor. Se essa chave não existir no arquivo, você poderá criá-la. Por exemplo, defina group.id=mirrormaker-consumer-group.

  6. Depois de MirrorMaker terminar de espelhar todos os tópicos, pare todos os produtores e consumidores e, em seguida, pare. MirrorMaker Redirecione os produtores e consumidores para o cluster CLUSTER_AWSMSK alterando seus valores dos agentes de bootstrap dos produtores e consumidores. Reinicie todos os produtores e consumidores no CLUSTER_AWSMSK.

Migração de um cluster do Amazon MSK para outro

Você pode usar o Apache MirrorMaker 2.0 para migrar de um cluster não MSK para um cluster MSK. Por exemplo, você pode migrar de uma versão do Apache Kafka para outra. Para obter um exemplo de como fazer isso, consulte Migrar um cluster Apache Kafka local para o Amazon MSK usando. MirrorMaker Como alternativa, o replicador do Amazon MSK pode ser usado para a migração do cluster do MSK. Para obter mais informações sobre o replicador do Amazon MSK, consulte MSKReplicador.

MirrorMaker 1.0 melhores práticas

Essa lista de melhores práticas se aplica à MirrorMaker versão 1.0.

  • Execute MirrorMaker no cluster de destino. Dessa forma, se ocorrer um problema de rede, as mensagens ainda estarão disponíveis no cluster de origem. Se você executa MirrorMaker no cluster de origem e os eventos são armazenados em buffer no produtor e há um problema de rede, os eventos podem ser perdidos.

  • Se a criptografia for necessária em trânsito, execute-a no cluster de origem.

  • Para os consumidores, defina auto.commit.enabled=false

  • Para os produtores, defina

    • max.in.flight.requests.per.connection=1

    • retries=Int.Max_Value

    • acks=all

    • max.block.ms = Long.Max_Value

  • Para obter um throughput alto do produtor:

    • Mensagens de buffer e lotes de mensagens de preenchimento: ajuste buffer.memory, batch.size, linger.ms

    • Ajuste os buffers de soquete: receive.buffer.bytes, send.buffer.bytes

  • Para evitar a perda de dados, desative a confirmação automática na origem, para que ela MirrorMaker possa controlar as confirmações, o que normalmente acontece depois de receber o pacote do cluster de destino. Se o produtor tiver acks=all e o cluster de destino tiver min.insync.replicas definido como mais de 1, as mensagens persistirão em mais de um agente no destino antes que o consumidor confirme a compensação na origem. MirrorMaker

  • Se a ordem for importante, você poderá definir novas tentativas como 0. Como alternativa, para um ambiente de produção, defina conexões máximas em trânsito como 1 para garantir que os lotes enviados não sejam confirmados fora de ordem se um lote falhar no meio. Dessa forma, cada lote enviado é repetido até que o próximo lote seja enviado. Se max.block.ms não estiver definido como o valor máximo, e se o buffer do produtor estiver cheio, poderá haver perda de dados (dependendo de algumas das outras configurações). Isso pode bloquear e retropressionar o consumidor.

  • Para obter throughput alto

    • Aumente o buffer.memory.

    • Aumente o tamanho do lote.

    • Ajuste linger.ms para permitir que os lotes sejam preenchidos. Isso também permite uma melhor compactação, menos uso de largura de banda de rede e menos armazenamento no cluster. Isso resulta em maior retenção.

    • Monitore o uso da CPU e da memória.

  • Para obter throughput alto do consumidor

    • Aumente o número de threads/consumidores por MirrorMaker processo — num.streams.

    • Aumente o número de MirrorMaker processos nas máquinas antes de aumentar os segmentos para permitir a alta disponibilidade.

    • Aumente o número de MirrorMaker processos primeiro na mesma máquina e depois em máquinas diferentes (com o mesmo ID de grupo).

    • Isole tópicos que tenham uma taxa de transferência muito alta e use instâncias separadas MirrorMaker .

  • Para gerenciamento e configuração

    • Ferramentas de gerenciamento de uso AWS CloudFormation e configuração, como Chef e Ansible.

    • Use montagens do Amazon EFS para manter todos os arquivos de configuração acessíveis em todas as instâncias do Amazon EC2.

    • Use contêineres para facilitar o escalonamento e o gerenciamento de MirrorMaker instâncias.

  • Normalmente, é preciso mais de um consumidor para saturar um produtor. MirrorMaker Portanto, configure vários consumidores. Primeiro, defina-os em diferentes máquinas para fornecer alta disponibilidade. Depois, ajuste a escala das máquinas individuais até ter um consumidor para cada partição, com consumidores distribuídos igualmente entre máquinas.

  • Para obter consumo e entrega de throughput alto, ajuste os buffers de recebimento e envio porque seus padrões podem ser muito baixos. Para obter o máximo desempenho, certifique-se de que o número total de streams (num.streams) corresponda a todas as partições de tópicos que MirrorMaker estão tentando copiar para o cluster de destino.

MirrorMaker 2.* vantagens

  • Usa a estrutura e o ecossistema do Apache Kafka Connect.

  • Detecta novos tópicos e partições.

  • Sincroniza automaticamente a configuração de tópicos entre clusters.

  • Oferece suporte a pares de cluster “ativo/ativo”, além de qualquer número de clusters ativos.

  • Fornece novas métricas, incluindo latência end-to-end de replicação em vários data centers e clusters.

  • Emite deslocamentos necessários para migrar consumidores entre clusters e oferece as ferramentas para a conversão do deslocamento.

  • Suporta um arquivo de configuração de alto nível para especificar vários clusters e fluxos de replicação em um só lugar, em comparação com propriedades de produtor/consumidor de baixo nível para cada processo 1.*. MirrorMaker