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á.
Migre para um cluster da Amazon MSK
O Amazon MSK Replicator pode ser usado para migração de MSK clusters. Consulte O que é o Amazon MSK Replicator?. Como alternativa, você pode usar o Apache MirrorMaker 2.0 para migrar de um cluster sem MSK cluster para um cluster da AmazonMSK. Para obter um exemplo de como fazer isso, consulte Migrar um cluster Apache Kafka local para a Amazon usando. MSK MirrorMaker Para obter informações sobre como usar MirrorMaker, consulte Espelhamento de dados entre clusters na documentação
Um resumo das etapas a serem seguidas ao usar MirrorMaker para migrar para um cluster MSK
Crie o MSK cluster de destino
Comece MirrorMaker com uma EC2 instância da Amazon dentro da VPC mesma Amazon do 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 MSK cluster.
-
Desligar MirrorMaker.
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.
-
Uso do monitor 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 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 EFS montagens da Amazon para manter todos os arquivos de configuração acessíveis a partir de 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
