Como posso solucionar o atraso ou backlog na replicação ou uma lista de pendências no meu servidor de origem Linux para o Application Migration Service?
Percebo atraso ou backlog no meu servidor de origem Linux ao replicar dados usando o AWS Application Migration Service.
Breve descrição
Estes são os fatores que contribuem para o atraso e a lista de pendências na replicação de dados de um servidor de origem para um servidor de destino:
- Velocidade de uplink de rede e disponibilidade da largura de banda: A velocidade da conexão de rede entre o servidor de origem e o servidor de replicação pode ter um impacto significativo no desempenho de replicação. Conexões lentas podem impedir a conclusão do processo de replicação. Além disso, a largura de banda limitada restringe a quantidade de dados que você pode replicar em um determinado momento.
- Alterações no disco durante a replicação: Durante o processo de replicação, o servidor de origem pode continuar gravando novos dados em seus discos. Se houver um grande aumento na quantidade de novos dados que o servidor de origem está gravando, os dados se acumularão e criarão um backlog significativo. O AWS Replication Agent deve enviar esse backlog com a sincronização inicial. Quanto maior o backlog, mais tempo é necessário para concluir a replicação dos dados.
- Velocidade de E/S dos discos de armazenamento: Durante o processo de replicação, o AWS Replication Agent lê blocos de armazenamento de discos e transmite dados ao servidor de replicação. No entanto, a alta latência de leitura nos discos do servidor de origem pode afetar a velocidade e a eficiência da replicação de dados. Discos lentos causam atrasos, e discos rápidos melhoram a velocidade de replicação.
- Carga no servidor de origem: A contenção de recursos no servidor de origem pode levar à alta utilização da CPU, consumo de memória, espera de E/S ou outras restrições de recursos. Por exemplo, a alta utilização da CPU pode causar gargalos de replicação. Isso ocorre porque o sistema se esforça para alocar recursos de CPU entre o AWS Replication Agent e outros processos. Da mesma forma, o alto consumo de memória pode fazer com que o sistema troque páginas de memória por disco. Isso resulta em maior espera de E/S e em uma desaceleração no processo de replicação.
- Recursos de replicação subprovisionados: A preparação de volumes do Amazon Elastic Block Store (Amazon EBS) com menor throughput e IOPS pode causar alta latência de leitura e gravação e alto comprimento de fila. Todos esses problemas afetam o desempenho da replicação. Além disso, um tipo de instância de servidor de replicação com baixo throughput de rede e largura de banda do Amazon EBS gera problemas de desempenho de replicação.
Resolução
Para determinar o motivo subjacente do atraso, primeiro realize verificações no servidor de origem. Em seguida, realize verificações na área de preparação.
Verificações do servidor de origem
Verificar se o servidor de origem está inicializado e em execução
Certifique-se de que o servidor de origem para a migração esteja inicializado e em execução.
Verificar se o servidor de origem pode estabelecer uma conexão SSL com o endpoint regional da API do Application Migration Service e o servidor de replicação
Certifique-se de que os certificados SSL não sejam interceptados e alterados em nenhum ponto entre o servidor de origem e o endpoint da API do Application Migration Service. Além disso, certifique-se de que os certificados SSL não sejam interceptados e alterados entre o servidor de origem e o servidor de replicação. Para fazer isso, execute o comando a seguir:
# echo -n | openssl s_client -connect mgn.<region>.amazonaws.com:443 # echo -n | openssl s_client -connect <replication server IP>:1500
Observação: use o comando listado na seção a seguir, Verificar conexões TCP ativas, para encontrar o endereço IP do servidor de replicação.
Verificar se todos os processos do AWS Replication Agent estão em execução
Execute o comando a seguir para listar os serviços do AWS Replication Agent em execução:
# ps -u aws-replication
A saída a seguir mostra os processos do AWS Replication Agent que devem estar em execução:
PID TTY TIME CMD 30878 ? 00:00:00 update_onprem_v 30879 ? 00:00:00 run_linux_migra 30880 ? 00:00:00 tailer 30881 ? 00:04:45 java 30902 ? 00:00:01 tailer 30904 ? 00:00:00 run_linux_migra 30905 ? 00:00:10 update_onprem_v 31023 ? 00:00:00 tail
Verificar conexões TCP ativas
Execute o comando a seguir para verificar se há cinco conexões TCP ativas estabelecidas com o servidor de replicação na porta TCP 1500.
# sudo netstat -anp | awk '$5 ~ /:1500$/ {print}'
Verifique a saída do comando para ver as conexões ativas:
tcp6 0 0 172.31.1.39:54814 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54828 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54832 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54812 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54800 172.31.0.82:1500 ESTABLISHED 30881/java
Verificar a utilização da CPU no núcleo da CPU em que o AWS Replication Agent está sendo executado
O AWS Replication Agent é um processo de execução única que opera em um núcleo de CPU por vez. Se a utilização da CPU for alta no núcleo em que o AWS Replication Agent está sendo executado, a replicação de dados ficará mais lenta.
1.Execute os comandos a seguir e, em seguida, revise a saída para determinar o seguinte:
- O ID do processo do AWS Replication Agent.
- O núcleo da CPU (indicado por psr) em que ele está sendo executado.
# ps --pid $(pidof /var/lib/aws-replication-agent/jre/bin/java) -o psr,pid,comm # mpstat -P <psr column value> 3
2.Em seguida, verifique a utilização da CPU do núcleo de CPU identificado.
Verificar o desempenho do disco no servidor de origem
Se houver baixo throughput de leitura (rMB/s) nos discos de origem, menos dados serão lidos e replicados. Anote qualquer aumento nas métricas IO depth (avgqu-sz) (Profundidade de E/S) e I/O wait (await) (Espera de E/S)). Você pode usar as ferramentas sar ou iostat para medir o throughput de disco:
# iostat -myx 3 # sar -dp 2
Verificar se há um pico nas operações de gravação no servidor de origem
Um pico nas operações de gravação no servidor de origem pode causar o aumento do atraso na replicação. Esse crescimento continua até que o AWS Replication Agent transmita todos os dados gravados para o servidor de replicação. Execute o teste iostat periodicamente para determinar qual é a carga de E/S à medida que a workload muda. Se o throughput de gravação (wMB/s) exceder o throughput de rede disponível, você verá um atraso na replicação.
Observação: para calcular a largura de banda necessária do servidor de origem para o servidor de replicação, consulte Calcular a largura de banda necessária para a porta TCP 1500.
Verificar a velocidade de replicação e a largura de banda disponível do servidor de origem para a sub-rede da área de teste
1.Em sua região da AWS de destino, inicie uma instância de teste do Amazon Elastic Compute Cloud (Amazon EC2) usando a AMI de publicação CE-ssl-speedtest. A instância do EC2 deve ser do mesmo tipo de instância do servidor de replicação.
2.Selecione a mesma sub-rede usada nas configurações de replicação do seu servidor de origem.
3.Certifique-se de que o grupo de segurança permita o acesso de entrada da porta TCP 1500.
4.No servidor de origem, configure o SpeedTest CLI conforme mostrado no exemplo a seguir:
# cd /tmp # git clone https://github.com/librespeed/speedtest-cli.git # cd speedtest-cli/ # ls -l # ./build.sh # cat << EOF >> ./servers.json [ { "id": 1, "name": "PHP Backend", "server": "https://<test server private IP>:1500/speedtest/", "dlURL": "/garbage.php", "ulURL": "/empty.php", "pingURL": "/empty.php" } ] EOF
Observação: no exemplo anterior, certifique-se de substituir o endereço IP do servidor de teste. Se você estiver usando o IP público do servidor de teste para um teste de velocidade, inclua "getIpURL": "/getIP.php" depois de "pingURL".
5.Execute o CLI LibreSpeed conforme mostrado no exemplo a seguir para testar a velocidade de replicação:
# ./out/librespeed-cli-linux-amd64 —local-json ./servers.json —server 1 —no-icmp —skip-cert-verify —simple Ping: 11.00 ms Jitter: 0.00 ms Download rate: 503.84 Mbps Upload rate: 493.56 Mbps
Verificar se um servidor de origem foi desligado incorretamente
Se um servidor de origem for desligado incorretamente, o AWS Replication Agent escaneará novamente todos os discos após a reinicialização do servidor. O AWS Replication Agent repete a leitura dos discos, e o atraso aumenta continuamente até que a nova leitura seja concluída. Para obter mais informações, consulte Quais sistemas operacionais Windows e Linux oferecem suporte a novas leituras após a reinicialização?
Verificar se há um upgrade do kernel
Se o kernel for atualizado no servidor de origem e o servidor for reinicializado, o AWS Replication Agent falhará na execução. A versão do kernel em execução corresponde à versão do kernel para a qual o driver do AWS Replication Agent foi compilado durante a instalação do agente.
Execute os seguintes comandos para verificar se a versão do kernel em execução corresponde à versão do kernel para a qual o driver do AWS Replication Agent foi compilado:
$ uname -r $ modinfo -F vermagic /var/lib/aws-replication-agent/aws-replication-driver.ko
Observação: vermagic é usado para verificar em qual versão do kernel o driver do kernel está compilado.
Verificar se a porta TCP 1500 não está bloqueada de saída
Certifique-se de que a porta TCP 1500 não esteja bloqueada de saída do servidor de origem para o servidor de replicação.
Revisar os logs do agente do MGN
Inspecione os logs do agente do MGN para detectar quaisquer problemas de conectividade com o servidor de replicação na porta TCP 1500. Além disso, verifique se há irregularidades de replicação que indiquem perda frequente de conexão. Depois de identificar esses problemas, revise a topologia da rede para investigar melhor.
Verificar se os dispositivos intermediários não têm uma MTU menor
Confirme se nenhum dos dispositivos intermediários no caminho de replicação tem uma MTU menor. Uma MTU menor reduz a velocidade de replicação e causa atrasos no processo. É uma prática recomendada manter um tamanho consistente de MTU em todo o caminho de replicação. Se um dispositivo no caminho tiver uma MTU menor, atualize-o ou substitua-o por um dispositivo com MTU superior.
Observação: se você estiver replicando pela Internet pública, certifique-se de que a MTU seja 1500. 1500 é o limite aceito pelo gateway da Internet, peering e VPN. Quadros Jumbo funcionam somente na Amazon Virtual Private Cloud (Amazon VPC) ou no AWS Direct Connect e têm suas próprias limitações. Para obter mais informações, consulte as informações a seguir:
Verificar se o controle de utilização da largura de banda da rede está desativada nas configurações de replicação no servidor de origem
O controle de utilização da largura de banda deve ser desativado nas configurações de replicação do servidor de origem.
Ativar o controle de utilização de largura de banda no servidor de origem limita o throughput de dados do AWS Replication Agent. Isso pode resultar em um crescimento constante ou estagnado do atraso se houver uma lista de pendências no servidor de origem. Para manter a largura de banda constante e limitada para transferência de dados, ative o controle de utilização da largura de banda da rede.
Para verificar o controle de utilização da largura de banda, conclua as seguintes etapas:
1.Abra o console do Application Migration Service.
2.Escolha Source servers (Servidores de origem) e selecione o servidor de origem.
3.Escolha a guia Replication settings (Configurações de replicação).
3.Se a opção Throttle network bandwidth (Limitar largura de banda da rede) estiver ativada, certifique-se de que o valor limitado seja igual ou maior que a largura de banda necessária para a replicação de dados. Para obter mais informações, consulte a nota na seção anterior, Verificar se há um pico nas operações de gravação no servidor de origem.
Verificações de recursos da área de preparação
Verificar se a porta TCP 1500 não está bloqueada de entrada
Certifique-se de que a porta TCP 1500 não esteja bloqueada de entrada nos grupos de segurança do servidor de replicação.
Observação: você deve concluir as etapas a seguir no console do Amazon Elastic Compute Cloud (Amazon EC2).
1.Abra o console do Amazon EC2.
2.Selecione o grupo de segurança que está anexado à instância do replicador.
3.Verificar se a porta TCP 1500 de entrada é permitida no grupo de segurança conectado.
Verificar a métrica NetworkIn CloudWatch
Se a métrica NetworkIn do Amazon CloudWatch para o servidor de replicação se aproximar do limite de largura de banda, poderá ocorrer controle de utilização. O controle de utilização resulta em uma velocidade de replicação mais lenta e maior atraso. Considere fazer upgrade para um tipo de instância maior que possa lidar com a largura de banda necessária.
Verificar o throughput agregado e a IOPS dos volumes EBS do servidor de replicação
O desempenho do servidor de replicação poderá ficar reduzido se o throughput agregada e a IOPS dos volumes do Amazon Elastic Block Store (Amazon EBS) excederem os limites. Se ocorrer controle de utilização, mude para um tipo de instância de servidor de replicação que atenda às suas necessidades de replicação e mantenha o desempenho sem controle de utilização. É uma prática recomendada usar um tipo de instância otimizado para EBS da geração atual para servidores de replicação. Em instâncias sem suporte para throughput otimizado para EBS, o tráfego de rede lida com o tráfego entre sua instância e seus volumes do EBS. Em instâncias otimizadas para EBS, os dois tipos de tráfego são mantidos separados. Monitore a rede do servidor de replicação e as métricas do EBS CloudWatch. Para obter mais informações, consulte as informações a seguir:
Monitorar métricas de todos os volumes de replicação do EBS
O atraso e a lista de pendências se acumulam quando a velocidade de gravação do volume do servidor de replicação não consegue corresponder à taxa de alteração no servidor de origem. Para evitar atrasos na replicação, use um tipo de volume mais rápido com maior IOPS e largura de banda. Para um desempenho ideal do volume do EBS, é uma prática recomendada monitorar as métricas do CloudWatch para cada volume do EBS de replicação.
Verificar os volumes do EBS criados a partir de um snapshot
Servidores de replicação que possuem volumes EBS criados a partir de um snapshot podem ter aumentado a latência das operações de E/S na primeira vez em que cada bloco foi acessado. Essa latência pode causar atraso no crescimento ou estagnação até que o processo de nova verificação seja concluído. Para obter mais informações, consulte Esteja ciente da penalidade de desempenho ao inicializar volumes a partir de snapshots.
Verifique a cota de snapshots na região de destino
Certifique-se de que sua conta da AWS não tenha atingido os limites de cota de snapshots na região da AWS em que você está replicando servidores de origem. Use os seguintes comandos da AWS Command Line Interface (AWS CLI) para verificar se você atingiu a cota de snapshots na região. No exemplo a seguir, substitua a região pela sua região da AWS de destino:
# aws service-quotas get-service-quota --service-code ebs --quota-code L-309BACF6 --region region --query "Quota.Value" # aws ec2 describe-snapshots --owner-ids self --region region --query "length(Snapshots)"
Observação: Se você receber erros ao executar os comandos da AWS CLI, utilize a versão mais recente da AWS CLI.
Informações relacionadas
Identificação de gargalos de replicação ao usar o AWS Application Migration Service
Conteúdo relevante
- AWS OFICIALAtualizada há um ano