Sobre a migração do gateway ExpressRoute

Este artigo descreve o processo de migração do gateway do ExpressRoute, permitindo que o utilizador mude da sua SKU atual para qualquer SKU igual ou superior e de IP Básico para IP Standard — aprimorando a fiabilidade e a disponibilidade, sendo que downgrades não são suportados.

Para obter orientação sobre como atualizar endereços IP públicos de SKU básico para outros serviços de rede, consulte Atualizando Basic para SKU padrão.

Experiência de migração do gateway

A experiência de migração de gateway permite implementar um segundo gateway virtual de rede na mesma GatewaySubnet, com Azure atribuindo automaticamente um novo IP- eliminando a necessidade de criação manual de IP — enquanto as configurações são migradas do gateway antigo para o novo; ambos os gateways funcionam simultaneamente para minimizar interrupções, embora possam ainda ocorrer breves interrupções de conectividade.

Após a migração, o gateway antigo e suas conexões são excluídos, e o novo gateway é marcado com CreatedBy: GatewaySKUMigration para identificá-lo como um recurso migrado e não deve ser excluído.

Cenários de migração suportados

A experiência guiada de migração do gateway ExpressRoute permite que os clientes mudem de sua SKU atual para qualquer SKU igual ou superior. Não há suporte para a migração para um SKU (downgrades) mais baixo.

Se tiver um gateway ExpressRoute implementado na mesma rede virtual que um Gateway de VPN, pode usar a ferramenta de migração do ExpressRoute Gateway. Não há impacto esperado no tráfego do Gateway de VPN durante este processo.

Aprenda a migrar usando o portal Azure.
Saiba como migrar usando o PowerShell.

Para maior confiabilidade e alta disponibilidade, recomendamos migrar para um SKU habilitado para Az.

Migrar para ErGwScale (gateway escalável)

O ExpressRoute Scalable Gateway (ErGwScale) é um novo SKU de gateway de rede virtual que oferece conectividade flexível e de alta largura de banda para as suas redes virtuais Azure.

Você pode configurar o dimensionamento do gateway, de acordo com os requisitos, definindo as unidades de escala mínima e máxima:

• Para configurar um gateway de tamanho fixo, defina as unidades de escala mínima e máxima com o mesmo valor (por exemplo, defina ambas como 1, defina ambas como 20, defina ambas como 40).
• Para habilitar o dimensionamento automático, defina a unidade de escala mínima como 2 ou superior e especifique a unidade de escala máxima desejada (até 40).

Isso permite que o gateway seja dimensionado automaticamente com base em seus requisitos de carga de trabalho.

Para obter mais informações, consulte Sobre o gateway escalável.

Etapas para migrar para um novo gateway

1. Validar: verifique se todos os recursos estão num estado de sucesso. Se algum pré-requisito não for atendido, a validação falhará e a migração não poderá prosseguir.
2. Prepare: Azure cria um novo gateway de rede virtual, atribui automaticamente um novo IP Público- um novo IP Público e restabelece ligações—este processo pode demorar até 45 minutos; pode especificar um nome personalizado para o novo gateway, ou Azure irá adicionar _migrated ao nome original por defeito. Durante a preparação, o gateway existente é bloqueado para evitar alterações, com a opção de cancelar e eliminar o novo gateway e as conexões.

3. Migrar: alterne o tráfego do gateway antigo para o novo. Esta etapa pode levar até 15 minutos e pode causar breves interrupções de conectividade. Não navegue para fora da página de migração enquanto o tráfego está sendo movido. Sair da página pode interromper o processo.
4. Commit: finalize a migração excluindo o gateway original e suas conexões. Se você precisar cancelar a migração, primeiro alterne o tráfego de volta para o gateway original selecionando o botão de opção na seção Migrar , clique em Migrar e, finalmente, escolha Abortar para excluir o novo gateway e suas conexões.

Limitations

A experiência de migração de gateway guiada tem as seguintes limitações:

• Somente Rota Expressa: A ferramenta de migração foi projetada para gateways de rede virtual de Rota Expressa. Ele não suporta gateways VPN ou outros tipos de gateway.
• Same Rede Virtual Requirement: A migração só é suportada dentro da mesma rede virtual. Migrações entre assinaturas, entre regiões ou entre diferentes tipos de gateway (por exemplo, de/para gateways VPN) não são suportadas.
• Sem downgrades: não é suportado o downgrade de uma SKU habilitada para Az para uma SKU não habilitada para Az.
• Tamanho da Subnet Gateway: A Subnet Gateway deve ter um prefixo /27 ou maior (por exemplo, /26 ou /25) para prosseguir com a migração. Se forem configurados vários prefixos de endereço, tanto os prefixos existentes como os recentemente adicionados do GatewaySubnet podem ser usados durante a migração, e o prefixo original não pode ser eliminado enquanto ainda estiver em uso. Para mais informações, veja Criar múltiplos prefixos para uma subrede.
• Conectividade de ponto final privado: os pontos de extremidade privados (PEs) conectados via emparelhamento privado da Rota Expressa podem enfrentar problemas de conectividade durante a migração. Consulte as orientações sobre como atenuar esses problemas na documentação de conectividade de ponto de extremidade privado. Conectividade de ponto final privado.
• Gateways herdados: gateways do ExpressRoute criados ou conectados a circuitos em 2017 ou antes não são suportados.
• SKUs sem suporte: gateways que usam a SKU "padrão" não são elegíveis para migração. Para verificar a elegibilidade de migração do seu Gateway, deve haver uma notificação do Advisor.
• Circuito dedicado incompatível: a migração de gateway não pode prosseguir com um HSM (Hardware Security Module) dedicado conectado à rede virtual. Para prosseguir com a migração, desaloque o Módulo de Segurança de Hardware (HSM) dedicado. Para obter etapas detalhadas de solução de problemas, consulte Solucionar problemas de HSM dedicado.

Para obter detalhes sobre erros de resolução de problemas e práticas recomendadas, consulte Solução de Problemas na Migração de Gateway.

FAQ

Como adiciono um segundo prefixo à GatewaySubnet?

A adição de múltiplos prefixos ao GatewaySubnet está atualmente disponível via linha de comandos (PowerShell, CLI) ou Azure Resource Manager Templates. Quando você adiciona um prefixo adicional, ambos os prefixos serão usados pelo gateway migrado, portanto, não exclua o prefixo antigo. Para obter instruções, consulte Criar vários prefixos para uma sub-rede.

Como faço para monitorizar a integridade do novo gateway?

O monitoramento para o novo gateway é o mesmo que para o gateway antigo. O novo gateway é um recurso separado com suas próprias métricas. Durante a migração, você também pode observar padrões de tráfego usando a ferramenta de migração.

Após a migração, se você tiver definido monitoramento, alertas, janelas de manutenção definidas pelo cliente ou configurações de diagnóstico existentes, será necessário reconfigurá-las no gateway recém-criado.

A migração causará tempo de inatividade?

A migração pode causar alguns minutos de tempo de inatividade. Planeje executar a migração durante uma janela de manutenção para minimizar o impacto.

Quanto tempo posso esperar antes de me comprometer com o novo gateway?

Não há período de espera obrigatório para fazer o compromisso. No entanto, se você precisar de tempo para validar a conectividade e garantir que todos os requisitos sejam atendidos antes de finalizar a migração, terá até 15 dias para confirmar após a migração.

Como verifico se meu SKU de gateway é elegível para migração?

O Assistente do Azure notificará se o seu gateway for elegível ou necessitar de migração. Também pode consultar o seu recurso de Gateway ExpressRoute no portal Azure — se o seu gateway for elegível, um banner no topo da página mostrará a mensagem "Implementar Gateways ExpressRoute Redundantes de Zona."

Como faço para validar se meu gateway é Zone Resilient após a migração?

Para confirmar se o gateway é resiliente à zona após a migração:

• Verifique o Assistente do Azure: Se o seu gateway for resiliente em zonas, já não verá alertas do Advisor a recomendar um gateway redundante por zona.
• Verificar etiquetas de recurso: O gateway migrado terá uma etiqueta padrão rotulada GatewaySKUMigration, indicando que foi movido para o modelo de implantação resiliente à zona.

Essas verificações confirmam que seu gateway agora é resiliente à zona.

Posso reverter essa alteração?

Sim, até que seja cometido. A migração é composta por quatro grandes etapas:

1. Validar – Confirma se o gateway é elegível para migração. Nenhuma alteração nesta fase; nada para reverter

2. Prepare – Cria um novo Rede Virtual Gateway com a configuração desejada. O processo pode ser abortado após a etapa 2 e o novo gateway será excluído.

3. Migrar – Transfira a configuração do gateway existente para o novo. Se necessário, a configuração pode ser revertida para o gateway existente após a etapa 3. Não navegue para fora da página de migração enquanto o tráfego está sendo movido. Sair da página pode interromper o processo.

4. Commit – Finalize a migração desmantelando o gateway antigo e as suas conexões. Uma vez confirmada, a alteração não pode mais ser revertida.

Qual é o impacto do tráfego durante a migração? Há perda de pacotes ou interrupção de roteamento?

Durante o processo de migração, o tráfego é redirecionado perfeitamente. Não há perda esperada de pacotes ou interrupção de roteamento em condições normais.

O que devo fazer se a etapa Preparar falhar devido a uma ligação entre regiões num circuito SKU Básico durante a migração de um gateway?

Se a etapa Preparar falhar porque seu circuito SKU básico tem uma conexão entre regiões, aborte a migração do gateway e atualize o circuito SKU antes de tentar novamente. Esta configuração não é suportada e a migração continua a falhar até que o circuito SKU seja atualizado.

Próximas Etapas

• Solucione problemas de migração com Solução de problemas de migração de gateway.
• Aprenda a migrar usando o portal Azure.
• Saiba como migrar usando o PowerShell.