Sobre a migração do Gateway do ExpressRoute

Este artigo descreve o processo de migração de gateway do ExpressRoute, permitindo que você mova do SKU atual para qualquer SKU igual ou superior e do IP Básico para o IP Padrão, aumentando a confiabilidade e a disponibilidade, enquanto os downgrades não têm suporte.

Para obter diretrizes sobre como atualizar endereços IP públicos de SKU básicos para outros serviços de rede, consulte Como atualizar o Basic para o SKU Standard.

Experiência de migração do gateway

A experiência de migração de gateway permite implantar um segundo gateway de rede virtual no mesmo GatewaySubnet, com o Azure atribuindo automaticamente um novo IP público, eliminando a necessidade de criação manual de IP. Quando as configurações forem migradas do gateway antigo para o novo, os dois gateways serão executados simultaneamente para minimizar a interrupção, embora breves interrupções de conectividade ainda possam ocorrer.

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 com suporte

A experiência guiada de migração de gateway do ExpressRoute permite aos clientes mudar sua SKU atual por uma SKU igual ou superior. Não há suporte para migrar para um SKU inferior (fazer downgrade).

Se você tiver um gateway do ExpressRoute implantado na mesma rede virtual que um Gateway de VPN, poderá usar a ferramenta de migração do Gateway do ExpressRoute. Não há nenhum impacto esperado no tráfego do Gateway de VPN durante esse processo.

Saiba como migrar usando o portal do 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 Escalonável)

O Gateway Escalonável do ExpressRoute (ErGwScale) é um novo SKU de gateway de rede virtual que fornece conectividade flexível e de alta largura de banda para suas redes virtuais do 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 Escalonável.

Etapas para migrar para um novo gateway

1. Validar: Verifique se todos os recursos estão no estado Concluído. Se os pré-requisitos não forem atendidos, a validação falhará e a migração não poderá continuar.
2. Preparar: o Azure cria um novo gateway de rede virtual, atribui automaticamente um novo IP público, um novo IP público e restabelece conexões, esse processo pode levar até 45 minutos; você pode especificar um nome personalizado para o novo gateway ou o Azure adicionará _migrated ao nome original por padrão. O gateway existente é bloqueado durante a preparação a fim de evitar alterações, ficando com a opção de anular e excluir o novo gateway e as conexões.

3. Migrar: transfira o tráfego do gateway antigo para o novo. Essa etapa pode levar até 15 minutos e pode causar breves interrupções de conectividade. Não navegue para longe da página de migração enquanto o tráfego está sendo movido. Sair da página pode interromper o processo.
4. Confirmar: conclua a migração excluindo o gateway original e suas conexões. Se precisar cancelar a migração, primeiro alterne o tráfego de volta para o gateway original selecionando a opção na seção Migrar, clique em Migrar e, depois escolha Anular 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 ExpressRoute: a ferramenta de migração foi projetada para gateways de rede virtual do ExpressRoute. Ele não dá suporte a gateways de VPN nem a outros tipos de gateway. - Mesmo requisito de rede virtual: a migração só tem suporte na mesma rede virtual. Não há suporte para migrações entre assinaturas, entre regiões ou entre gateways (por exemplo, para/de gateways de VPN).
• Sem downgrade: o downgrade de uma SKU habilitada para Az para uma SKU não habilitada para Aznão tem suporte.
• Tamanho GatewaySubnet: O GatewaySubnet deve ter um prefixo /27 ou menor para continuar com a migração. Para obter mais informações, consulte Criar vários prefixos para uma sub-rede para obter mais informações.
• Conectividade de ponto de extremidade privado: PEs (pontos de extremidade privados) conectados por meio do emparelhamento privado do ExpressRoute podem enfrentar problemas de conectividade durante a migração. Consulte as diretrizes sobre como atenuar esses problemas na documentação de conectividade do ponto de extremidade privado. Conectividade de ponto de extremidade privado.
• Gateways legados: Gateways ExpressRoute criados ou conectados a circuitos em 2017 ou antes não têm suporte.
• SKUs sem suporte: os gateways que usam o SKU "padrão" não são qualificados 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 continuar com um HSM (Módulo de Segurança de Hardware) dedicado conectado à rede virtual. Para continuar com a migração, desaloque o HSM (Módulo de Segurança de Hardware) dedicado. Para obter etapas detalhadas de solução de problemas, consulte Solucionar problemas de HSM dedicado.

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

perguntas frequentes

Como fazer para adicionar um segundo prefixo ao GatewaySubnet?

A adição de vários prefixos ao GatewaySubnet está atualmente em versão prévia pública e tem suporte apenas por meio do PowerShell. 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 monitorar a integridade do novo gateway?

O monitoramento do novo gateway é o mesmo do 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ê tinha monitoramento existente, alertas, janelas de manutenção definidas pelo cliente ou configurações de diagnóstico anteriormente definidas, será necessário reconfigurá-los 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á nenhum período de espera obrigatório para realizar o commit. 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 fazer para verificar se meu SKU de gateway está qualificado para migração?

O Assistente do Azure notificará você se o gateway for qualificado ou exigir a migração. Você também pode verificar o recurso de Gateway do ExpressRoute no portal do Azure—se o seu gateway for qualificado, uma barra de notificação na parte superior da página exibirá a mensagem "Implementar Gateways do ExpressRoute com Redundância de Zona".

Como validar se meu gateway é Resiliente à Zona depois da migração?

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

• Verifique o Assistente do Azure: se o gateway tiver resiliência de zona, você não verá mais alertas do Assistente recomendando um gateway com redundância de zona.
• Verificar marcas de recurso: o gateway migrado terá uma marca padrão rotulada GatewaySKUMigration, indicando que ele foi movido para o modelo de implantação resiliente a zonas.

Essas verificações confirmam que o gateway agora é resiliente a zonas.

Posso reverter essa alteração?

Sim, até que seja concluído. A migração é composta por quatro etapas principais:

1. Validar – confirma se o gateway está elegível para migração. Nenhuma alteração neste estágio; nada para reverter

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

3. Migrar – transferir 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 longe 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 desativando o gateway antigo e suas conexões. Depois que a alteração for confirmada, ela não poderá mais ser revertida.

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

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

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

Se a etapa Preparar falhar porque o circuito de SKU Básico tem uma conexão entre regiões, clique em anular a migração do gateway e em atualizar o SKU do circuito antes de tentar novamente. Essa configuração não tem suporte e a migração continua falhando até que o SKU do circuito seja atualizado.

Próximas etapas

• Solucione problemas de migração com Troubleshooting Gateway Migration.
• Saiba como migrar usando o portal do Azure.
• Saiba como migrar usando o PowerShell.