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á.
Migrar 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 replicador do Amazon MSK?. Como alternativa, você pode usar o Apache MirrorMaker 2.0 para migrar de um cluster não MSK para um cluster do Amazon MSK. Para ver um exemplo de como fazer isso, consulte Migrar um cluster on-premises do Apache Kafka para o Amazon MSK usando. MirrorMaker Para obter informações sobre como usar MirrorMaker, consulte Espelhamento de dados entre clusters na documentação
Um descrição das etapas a serem seguidas MirrorMaker ao usar o cluster do MSK
Criar o cluster de destino do MSK
Comece MirrorMaker com uma EC2 instância da Amazon dentro da mesma Amazon VPC como o cluster de destino.
-
Inspecione o MirrorMaker atraso.
-
Depois de MirrorMaker se atualizar, redirecione produtores e consumidores para o novo cluster usando os corretores de bootstrap do cluster MSK.
-
Encerrar MirrorMaker.
MirrorMaker Práticas recomendadas 1.0
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 primeiro 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 com throughput muito alto 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 EC2 instâncias da Amazon.
-
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.
Vantagens de MirrorMaker 2. *
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
