Otimize o carregamento de rede
Jumbo Frames são quadros ethernet maiores do que os 1500 bytes padrão. Os tamanhos típicos do Jumbo Frame são de 9000 bytes. Um aumento do tamanho do quadro no servidor de banco de dados de origem, todos os dispositivos de rede intermediários, como switches, e os servidores Intel R3load reduzem o consumo de CPU e aumentam a taxa de transferência da rede. O tamanho do quadro deve ser idêntico em todos os dispositivos, caso contrário, a conversão consome muitos recursos.
Recursos de rede adicionais, como RSS (Receive Side Scaling), podem ser ativados ou configurados para distribuir o processamento de rede entre vários processadores A execução de servidores R3load no VMware provou tornar o ajuste de rede para Jumbo Frames e RSS mais complexo e não é recomendado, a menos que haja um nível de habilidade muito especializado disponível.
O R3load exporta dados de tabelas DBMS e compacta esses dados brutos independentes de formato em arquivos de despejo. Esses arquivos de despejo precisam ser carregados no Azure e importados para o banco de dados do SQL Server de destino.
O desempenho da cópia e do carregamento para o Azure desses arquivos de despejo é um componente crítico no processo geral de migração.
Há duas abordagens básicas para o upload de arquivos de despejo R3load:
Copie de servidores de exportação R3load locais para o armazenamento de blob do Azure via Internet Pública com AzCopy
Em cada um dos servidores R3load, execute uma cópia do AzCopy com esta linha de comando:
Azcopy copy "C:\ExportServer_1\Dumpfiles" "https://[storage_account].blob.core.windows.net/ExportServer_1/Dumpfiles?[SAS_Token]" --recursive
Você pode aumentar a taxa de transferência definindo a variável de ambiente AZCOPY_CONCURRENCY_VALUE. Esta variável especifica o número de pedidos simultâneos que podem ocorrer.
Se o computador tiver menos de 5 CPUs, o [valor] desta variável será definido como 32. Caso contrário, o valor predefinido é igual a 16 vezes o número de CPUs. O valor padrão máximo dessa variável é 300, mas você pode definir manualmente esse valor maior ou menor:
| Sistema operativo | Comando |
|---|---|
| Windows | set AZCOPY_CONCURRENCY_VALUE=[value] |
| Linux | export AZCOPY_CONCURRENCY_VALUE=[value] |
| macOS | export AZCOPY_CONCURRENCY_VALUE=[value] |
Use o azcopy env para verificar o valor atual da variável de ambiente AZCOPY_CONCURRENCY_VALUE. Se o valor estiver em branco, você poderá ler qual valor está sendo usado observando o início de qualquer arquivo de log AzCopy. O valor selecionado, e o motivo pelo qual foi selecionado, são relatados lá.
Antes de definir o valor de simultaneidade, execute um teste de referência. O processo de teste de referência relata o valor de simultaneidade recomendado. Em alternativa, se as condições da rede e as cargas úteis variarem, defina esta variável para a palavra AUTO em vez de para um número específico. O valor AUTO faz com que o AzCopy sempre execute o mesmo processo de ajuste automático que ele usa em testes de benchmark.
Se um cliente tiver um servidor poderoso e internet rápida, o valor da simultaneidade pode ser aumentado. Se o valor da simultaneidade for aumentado demais, a conexão com o servidor de exportação R3load será perdida devido à saturação da rede. Monitore a taxa de transferência da rede no Gerenciador de Tarefas do Windows. A taxa de transferência de cópia de mais de 1 Gigabit por segundo por R3load Export Server pode ser facilmente alcançada. A taxa de transferência de cópia pode ser ampliada com mais servidores R3load (quatro são descritos no diagrama anterior).
Um script semelhante precisa ser executado nos servidores de Importação R3load no Azure para copiar os arquivos do Blob para um sistema de arquivos que o R3load possa acessar.
Copie de servidores de exportação R3load locais para uma Máquina Virtual do Azure ou armazenamento de blob por meio de uma conexão de Rota Expressa dedicada usando AzCopy, Robocopy ou uma ferramenta semelhante
Robocopy C:\Export1\Dump1 \\az_imp1\Dump1 /MIR /XF *.SGN /R:20 /V /S /Z /J /MT:8 /MON:1 /TEE /UNILOG+:C:\Export1\Robo1.Log
O diagrama de blocos a seguir ilustra quatro servidores Intel R3load executando R3load. Em segundo plano, o Robocopy é iniciado a carregar arquivos de despejo. Quando tabelas e pacotes divididos inteiros são concluídos, o arquivo SGN é copiado manualmente ou por meio de um script. Quando o arquivo SGN de um pacote chega ao servidor R3load de importação, ele dispara a importação para esse pacote automaticamente.
Nota
Copiar arquivos através de protocolos NFS ou Windows SMB não é tão rápido ou robusto quanto mecanismos como o AzCopy. Recomenda-se testar o desempenho de ambas as técnicas de upload de arquivos. É recomendável notificar o Suporte da Microsoft para projetos de migração VLDB, pois operações de rede de taxa de transferência muito alta podem ser identificadas incorretamente como ataques de negação de serviço.