Fatores de desempenho e práticas recomendadas para migrações híbridas
Há muitos caminhos para migrar dados de uma organização de email local para o Microsoft 365 ou Office 365. Ao planejar a migração, uma questão comum é sobre como melhorar o desempenho da migração de dados e otimizar a velocidade de migração. Este artigo discute o desempenho da migração para implantações híbridas do Exchange. Para obter informações de desempenho sobre outros métodos de migração, consulte Desempenho e melhores práticas de migração do Microsoft 365 e Office 365.
A migração de implantação híbrida dá suporte à migração suave entre servidores locais do Exchange e Exchange Online no Microsoft 365 ou Office 365.
A migração de implantação híbrida é de longe o método de migração mais rápido para migrar dados da caixa de correio para o Microsoft 365 ou Office 365. Vimos até 100 GB/hora de taxa de transferência durante implantações reais do cliente. A tabela a seguir fornece uma lista de fatores que se aplicam a cenários nativos de migração híbrida do Microsoft 365 e Office 365.
Se o seu ambiente local contém vários sites em localizações geograficamente espalhadas, é possível melhorar o desempenho da migração criando pontos de extremidade de migração geograficamente próximos. Isso ocorre porque, nesse cenário, a migração usa a rede da Microsoft em comparação com o uso de um ponto de extremidade de migração centralizado que usa a sua rede local.
Fator 1: Fonte de dados (Exchange Server)
| Lista de Verificação | Descrição | Práticas recomendadas |
|---|---|---|
| Desempenho do sistema | A extração de dados é uma tarefa que usa muitos recursos. O sistema de origem deve ter recursos suficientes, como tempo e memória da CPU, para oferecer um melhor desempenho de migração. No momento da migração, o sistema de origem geralmente está perto da capacidade total para atender à carga de trabalho regular do usuário final. A carga de trabalho de migração adicional às vezes até reduz o acesso dos usuários finais devido à falta de recursos do sistema. | Monitore o desempenho do sistema durante um teste de migração piloto. Se o sistema está ocupado, recomendamos evitar uma programação de migração agressiva para o sistema específico, devido a potencial lentidão da migração e problemas de disponibilidade do serviço. Se possível, melhore o desempenho do sistema de origem, adicionando recursos de hardware e reduzindo a carga no sistema, movendo as tarefas e os usuários para outros servidores que não estejam envolvidos na migração. Para obter mais informações, consulte: Pergunte a Perf Guy: Dimensionamento de implantações do Exchange 2016 Exchange Server Integridade e Desempenho Noções básicas Sobre o Desempenho do Exchange 2010 Ao se migrar de uma organização do Exchange local quando há vários servidores de caixa de correio e vários bancos de dados, recomendamos criar uma lista de usuário de migração que é distribuída igualmente entre vários servidores de caixa de correio e bancos de dados. Com base no desempenho individual do servidor, a lista pode ser melhor ajustada para maximizar o resultado. Por exemplo, se o servidor A possui 50% mais disponibilidade de recursos do que o servidor B, é razoável ter 50% mais usuários no servidor A, no mesmo lote de migração. Práticas semelhantes podem ser aplicadas a outros sistemas de origem. Realize migrações quando os servidores tiverem uma disponibilidade máxima de recursos, como depois do expediente ou em finais de semana e feriados. |
| Tarefas de back-end | Outras tarefas de back-end executadas durante o momento da migração. Como é uma prática recomendada realizar a migração após o horário comercial, é comum que as migrações entrem em conflito com outras tarefas de manutenção executadas em seus servidores locais, como o backup de dados. | Revise outras tarefas do sistema que podem estar sendo executadas durante a migração. Recomendamos que você realize a migração de dados quando não estiver sendo executada nenhuma outra tarefa que consuma muitos recursos. Observação: para clientes que usam o Microsoft Exchange local, as tarefas de back-end comuns são soluções de backup e manutenção do exchange store . |
Fator 2: Servidor de migração
A migração de implantação híbrida é uma migração de dados pull/push iniciada na nuvem, e um servidor híbrido do Exchange atua como o servidor de migração. Isso é frequentemente ignorado, e os clientes usam uma máquina virtual de baixo desempenho para atuar como o servidor híbrido. Isso resulta em um baixo desempenho da migração.
Prática recomendada do servidor de migração
Além de aplicar as práticas recomendadas descritas anteriormente, testamos as práticas recomendadas a seguir, que resultaram em um desempenho de migração melhor em migrações reais de clientes:
- Usar máquinas físicas potentes de classe do servidor em vez de máquinas virtuais para os servidores híbridos do Exchange.
- Usar vários servidores híbridos por trás de um balanceador de carga de rede do cliente.
Por exemplo, em migrações reais de clientes, atingimos um resultado consistente de 30 GB/h usando a seguinte configuração:
- Rede: pipe de saída de 500 mb para a Internet; rede interna em 1 GB com um backbone de fibra de 10 GB.
- Hardware: as especificações para os dois servidores de acesso ao cliente/HUB (físico) são:
- CPU: Intel® Xeon® CPU E5520 @ 2.27 GHz 2.26 GHz (dois processadores).
- RAM: 24 GB.
- Discos: Oito, com 146 GB por disco. Configuração RAID 5 = espaço bruto total de 960 GB.
- MRSProxy: configurado com uma simultaneidade de 100.
Fator 3: Mecanismo de migração
A migração de implantação híbrida usa ferramentas nativas do Microsoft 365 e Office 365. Ele está sujeito à limitação do serviço de migração do Microsoft 365 e Office 365.
Exchange 2003 versus versões posteriores do Exchange
Há uma diferença fundamental com relação à experiência do usuário final quando a migração é a partir do Exchange 2003. Ao contrário das versões posteriores do Exchange, os usuários finais do Exchange 2003 não podem acessar as caixas de correio enquanto os dados estiverem sendo migrados. Portanto, os clientes que usam o Exchange 2003 estão geralmente mais preocupados sobre quando programar as migrações e sobre o tempo necessário para executá-las, especialmente quando o desempenho da migração é baixo devido a caixas de correio de tamanho grande ou a uma rede lenta.
A migração do Exchange 2003 é também muito sensível a interrupções. Por exemplo, em uma migração real do cliente, durante a migração de uma caixa de correio de 10 GB, ocorreu um incidente de serviço quando a migração da caixa de correio estava 50% concluída. O servidor de Acesso para Cliente do Office 365, que estava processando a migração de dados, precisou ser reiniciado para resolver o problema. Nesse caso, a migração dessa caixa de correio teve que ser reiniciada, o que significava que o cliente precisava migrar todos os 10GB de dados novamente. Não foi possível retomar a migração de onde ela tinha parado. Entretanto, no Exchange 2010 e nas versões posteriores é possível retomar as migrações após interrupções.
Melhor prática do mecanismo de migração
Alguns clientes escolhem migrações de dois saltos para caixas de correio do Exchange 2003 grandes e importantes:
- Primeiro salto: migrar caixas de correio do Exchange 2003 para um servidor do Exchange 2010 ou posterior, que geralmente é o servidor híbrido. O primeiro salto é um movimento offline, mas geralmente é uma forma muito rápida de migração em uma rede local.
- Segundo salto: migrar caixas de correio do Exchange 2010 ou posterior para o Microsoft 365 ou Office 365.
O segundo salto é um movimento online, que oferece uma melhor experiência para o usuário, além da tolerância a falhas. Essa abordagem de dois saltos exige uma licença do Exchange para a caixa de correio do usuário local temporária.
Proxy de Serviço de Replicação de Caixa de Correio (MRSProxy)
O PROXY MRS é o recurso de migração local que funciona com o Serviço de Replicação da Caixa de Correio em execução no Microsoft 365 e Office 365 lado. Para saber mais, confira o artigo Noções Básicas Sobre Solicitações de Movimentação.
Prática recomendada MRSProxy
É possível configurar a quantidade máxima de conexões do MRSProxy para o servidor híbrido local do Exchange. Execute o seguinte comando do Windows PowerShell:
Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSMaxConnections <number between 0 and unlimited; default is 100>
Observação
Para a maioria das migrações de clientes, é desnecessário alterar o valor padrão MRSMaxConnections. Caso precise proteger o servidor de origem da sobrecarga pela carga de migração, os clientes podem reduzir o número de conexões. Essa configuração é feita por servidor MRSProxy. Se um cliente possui dois servidores MRSProxy, cada um definido para 10 conexões, eles obterão 20 (2 x 10) como a quantidade total de conexões do MRSProxy. Para saber mais sobre a configuração do serviço MRSProxy em sua organização local do Exchange 2010, confira o artigo Iniciar o serviço MRSProxy em um servidor de acesso remoto para cliente.
Fator 4: Rede
Testes de verificação
Para clientes que estejam executando o Exchange 2010 ou posterior, o teste de desempenho da rede para migrações híbridas pode ser realizado, efetuando-se vários testes de migrações de caixa de correio. Como alternativa, é possível migrar caixas de correio reais do usuário com a opção -SuspendWhenReadyToComplete para obter uma indicação do desempenho da migração. Quando o teste for concluído, remova a solicitação de movimento para evitar afetar os usuários finais.
Para mais informações sobre solicitações de movimento, confira New-MoveRequest.
Fator 5: Serviço do Office 365
A limitação baseada em integridade de recursos do Microsoft 365 e Office 365 afeta as migrações usando as migrações de implantação híbrida do Microsoft 365 ou Office 365. Consulte a seção Fator 3: mecanismo de migração acima para obter mais detalhes.