Migração para Ambiente do Serviço de Aplicativo v3 com o recurso de migração lado a lado

Observação

O recurso de migração descrito neste artigo é usado para a migração automatizada lado a lado (sub-rede diferente) do Ambiente do Serviço de Aplicativo v2 para o Ambiente do Serviço de Aplicativo v3.

Se você estiver procurando informações sobre o recurso de migração in-loco, consulte Migrar para o Ambiente do Serviço de Aplicativo v3 usando o recurso de migração in-loco. Se você estiver procurando informações sobre opções manuais de migração, consulte Opções de migração manual. Para obter ajuda para decidir qual opção de migração é ideal para você, confira a Árvore de decisão do caminho de migração. Para obter mais informações sobre o Ambiente do Serviço de Aplicativo v3, consulte Visão geral do Ambiente do Serviço de Aplicativo v3.

O Serviço de Aplicativo pode automatizar a migração do Ambiente do Serviço de Aplicativo v1 e v2 para um Ambiente do Serviço de Aplicativo v3. Há várias opções de migração. Examine a árvore de decisão de caminho de migração para decidir qual opção é melhor para seu caso de uso. O Ambiente do Serviço de Aplicativo v3 fornece vantagens e diferenças de recursos em relação às versões anteriores. Examine os recursos com suporte do Ambiente do Serviço de Aplicativo v3 antes de migrar para reduzir o risco de um problema inesperado com o aplicativo.

O recurso de migração lado a lado automatiza sua migração para o Ambiente do Serviço de Aplicativo v3. O recurso de migração lado a lado cria um novo Ambiente do Serviço de Aplicativo v3 com todos os seus aplicativos em uma sub-rede diferente. O Ambiente do Serviço de Aplicativo existente não será excluído até que você inicie a exclusão no final do processo de migração. Devido a esse processo, haverá uma opção de reversão se você precisar cancelar a migração. Essa opção de migração é melhor para clientes que desejam migrar para o Ambiente do Serviço de Aplicativo v3 sem tempo de inatividade e podem usar uma sub-rede diferente para o novo ambiente. Se você precisar usar a mesma sub-rede e puder dispor de cerca de uma hora de tempo de inatividade do aplicativo, consulte o recurso de migração in-loco. Para obter opções manuais de migração que permitam migrar em seu próprio ritmo, consulte as opções de migração manual.

Importante

É recomendável usar esse recurso para ambientes de desenvolvimento primeiro antes de migrar ambientes de produção, para garantir que não haja problemas inesperados. Forneça comentários relacionados a este artigo ou ao recurso usando os botões na parte inferior da página.

Cenários com suporte

No momento, o recurso de migração lado a lado não oferece suporte às migrações para o Ambiente do Serviço de Aplicativo v3 nas seguintes regiões:

Público do Azure

• EAU Central

Azure Government

• DoD Central dos EUA
• DoD do Leste dos EUA
• Governo dos EUA do Arizona
• Governo dos EUA do Texas
• Gov. dos EUA – Virgínia

Microsoft Azure operado pela 21Vianet

• Leste da China 2
• Norte da China 2

As seguintes configurações do Ambiente do Serviço de Aplicativo podem ser migradas usando o recurso de migração lado a lado. A tabela fornece a configuração do Ambiente do Serviço de Aplicativo v3 ao usar o recurso de migração lado a lado com base em seu Ambiente do Serviço de Aplicativo existente.

Configuração	Configuração do Ambiente do Serviço de Aplicativo v3
Ambiente do Serviço de Aplicativo v2 de ILB (Balanceador de Carga Interno)	Ambiente do Serviço de Aplicativo v3 de ILB
Ambiente do Serviço de Aplicativo v2 do Externo (ELB/para internet com IP público)	Ambiente do Serviço de Aplicativo v3 do ELB
|Ambiente do Serviço de Aplicativo v2 com ILB com sufixo de domínio personalizado	|Ambiente do Serviço de Aplicativo v3 de ILB com sufixo de domínio personalizado

O Ambiente do Serviço de Aplicativo v3 pode ser implantado com redundância de zona. A redundância de zona pode ser habilitada desde que o Ambiente do Serviço de Aplicativo v3 esteja em uma região que dê suporte à redundância de zona.

Se você quiser que o novo Ambiente do Serviço de Aplicativo v3 use um sufixo de domínio personalizado e não estiver usando um atualmente, o sufixo de domínio personalizado poderá ser configurado a qualquer momento após a conclusão da migração. Para obter mais informações, consulte Configurar o sufixo de domínio personalizado para o Ambiente do Serviço de Aplicativo. Se o ambiente existente tiver um sufixo de domínio personalizado e você não quiser mais usá-lo, você deverá configurar um sufixo de domínio personalizado para a migração. Você pode remover o sufixo de domínio personalizado após a conclusão da migração.

Limitações do recurso de migração lado a lado

Veja a seguir as limitações ao usar o recurso de migração lado a lado:

• Seu novo Ambiente do Serviço de Aplicativo v3 está em uma sub-rede diferente, mas na mesma rede virtual que o ambiente existente.
• Não será possível alterar a região em que o Ambiente do Serviço de Aplicativo está localizado.
• O Ambiente de Serviço de Aplicativo do ELB não poderá ser migrado para o Ambiente do Serviço de Aplicativo v3 de ILB e vice-versa.
• Se o Ambiente do Serviço de Aplicativo existente usar um sufixo de domínio personalizado, será necessário configurar o sufixo de domínio personalizado para o Ambiente do Serviço de Aplicativo v3 durante o processo de migração.
  • Se você não quiser mais usar um sufixo de domínio personalizado, poderá removê-lo assim que a migração for concluída.
• O recurso de migração lado a lado só está disponível usando a CLI ou por meio da API REST. O recurso não está disponível no portal do Azure.

O Ambiente do Serviço de Aplicativo v3 não dá suporte aos recursos a seguir que talvez você esteja usando no Ambiente do Serviço de Aplicativo v2 atual.

• Configurar uma associação TLS/SSL baseada em IP com os seus aplicativos.
• O Ambiente do Serviço de Aplicativo v3 não recorrerá ao DNS do Azure se os servidores DNS personalizados configurados na rede virtual não puderem resolver determinado nome. Se esse comportamento for necessário, verifique se você tem um encaminhador para um DNS público ou inclua o DNS do Azure na lista de servidores DNS personalizados.

O recurso de migração lado a lado não oferece suporte aos seguintes cenários. Consulte as opções de migração manual se o Ambiente do Serviço de Aplicativo se enquadrar em uma dessas categorias.

• Ambiente do Serviço de Aplicativo v1
  • Você pode encontrar a versão de seu Ambiente do Serviço de Aplicativo navegando até ele no portal do Azure e selecionando Configuração em Configurações no lado esquerdo. Você também pode usar o Azure Resource Explorer e examinar o valor da propriedade kind para o Ambiente do Serviço de Aplicativo.
  • Se você tiver um Ambiente do Serviço de Aplicativo v1, poderá migrar usando o recurso de migração in-loco ou uma das opções de migração manual.
• Ambiente de Serviço de Aplicativo v2 do ELB com endereços IP SSL.
• Ambiente do Serviço de Aplicativo v2 fixado à zona

A plataforma do Serviço de Aplicativo examina seu Ambiente do Serviço de Aplicativo para confirmar o suporte à migração lado a lado. Se seu cenário não passar em todas as verificações da validação, você não poderá migrar neste momento usando o recurso de migração lado a lado. Se seu ambiente estiver em um estado não íntegro ou suspenso, você não poderá migrar até fazer as atualizações necessárias.

Observação

O Ambiente do Serviço de Aplicativo v3 não tem suporte para IP SSL. Se você usar o IP SSL, deverá remover todas as associações de IP SSL antes de migrar para o Ambiente de Serviço de Aplicativo v3. O recurso de migração dará suporte ao seu ambiente quando todas as associações de IP SSL forem removidas.

Solução de problemas

Se o Ambiente do Serviço de Aplicativo não passar nas verificações de validação ou tentar executar uma etapa de migração na ordem incorreta, você verá uma das seguintes mensagens de erro:

Mensagem de erro	Descrição	Recomendação
A migração só pode ser chamada em um ASE na VNET do ARM e esse ASE está na VNET Clássica.	Os Ambientes do Serviço de Aplicativo em redes virtuais Clássicas não podem migrar usando o recurso de migração lado a lado.	Migrar usando uma das opções de migração manual.
A Migração ASEv3 ainda não está pronta.	A infraestrutura subjacente não está pronta para dar suporte a Ambiente do Serviço de Aplicativo v3.	Migre usando uma das opções de migração manual se você quiser migrar imediatamente. Caso contrário, aguarde até que o recurso de migração lado a lado esteja disponível em sua região.
Não é possível habilitar a redundância de zona para este ASE.	A região em que o Ambiente do Serviço de Aplicativo está não dá suporte à redundância de zona.	Se você precisar habilitar a redundância de zona, use uma das opções de migração manual para migrar para uma região que dê suporte à redundância de zona.
A migração não pode ser chamada neste ASE de sufixo DNS personalizado no momento.	A migração de sufixo de domínio personalizado está bloqueada.	Abra uma solicitação de suporte para envolver a equipe de suporte para resolve seu problema.
A migração do ASE com redundância de zona não pode ser chamada no momento.	A migração do Ambiente do Serviço de Aplicativo com redundância de zona está bloqueada.	Abra uma solicitação de suporte para envolver a equipe de suporte para resolve seu problema.
A migração não pode ser chamada no ASEv2 fixado em uma zona.	O Ambiente do Serviço de Aplicativo v2 que está fixado em uma zona não pode ser migrado usando o recurso de migração lado a lado no momento.	Migre usando uma das opções de migração manual se você quiser migrar imediatamente.
Operação de migração de reversão existente em andamento, tente novamente mais tarde.	Uma tentativa de migração anterior está sendo revertida.	Aguarde até que a reversão que está em andamento seja concluída para tentar iniciar a migração novamente.
Properties.VirtualNetwork.Id deve conter a ID do recurso da sub-rede.	O erro será exibido se você tentar migrar sem fornecer uma nova sub-rede para posicionamento do Ambiente do Serviço de Aplicativo v3.	Siga as diretrizes e conclua a etapa para identificar a sub-rede que você usará para o Ambiente do Serviço de Aplicativo v3.
Não é possível migrar para <requested phase> da fase <previous phase> em que a Migração sem tempo de inatividade está.	Esse erro será exibido se você tentar executar uma etapa de migração na ordem incorreta.	Siga as etapas de migração em ordem.
Falha ao iniciar a operação de reversão no ASE no estado híbrido, tente novamente mais tarde.	Esse erro será exibido se você tentar reverter a migração, mas algo der errado. Esse erro não afetará o ambiente antigo nem o novo.	Abra uma solicitação de suporte para envolver a equipe de suporte para resolve seu problema.
Esse ASE não pode ser migrado sem tempo de inatividade.	Esse erro é exibido se você tentar usar o recurso de migração lado a lado em um Ambiente do Serviço de Aplicativo v1.	O recurso de migração lado a lado não é compatível com o Ambiente do Serviço de Aplicativo v1. Migre usando o recurso de migração in-loco ou uma das opções de migração manual.
A migração não está disponível para essa assinatura.	O suporte precisa ser contratado para migrar esse Ambiente do Serviço de Aplicativo.	Abra uma solicitação de suporte para envolver a equipe de suporte para resolve seu problema.
A migração com redundância de zona não pode ser chamada, pois os endereços IP criados durante a pré-migração não contam com redundância de zona.	Esse erro será exibido se você tentar uma migração com redundância de zona, mas não tiver criado IPs com redundância de zona durante a etapa de geração de IP.	Abra um caso de suporte para obter auxílio se você precisar habilitar a redundância de zona. Caso contrário, você poderá migrar sem habilitar a redundância de zona.
A migração não poderá ser chamada se o IP SSL estiver habilitado em qualquer um dos sites.	Os Ambientes do Serviço de Aplicativo que têm sites com IP SSL habilitado não podem ser migrados usando o recurso de migração lado a lado.	Remova o IP SSL de todos os seus aplicativos no Ambiente do Serviço de Aplicativo para habilitar o recurso de migração.
Não é possível migrar dentro da mesma sub-rede.	O erro será exibido se você especificar a mesma sub-rede em que o ambiente atual está para o posicionamento do Ambiente do Serviço de Aplicativo v3.	Você deve especificar uma sub-rede diferente para o Ambiente do Serviço de Aplicativo v3. Se você precisar usar a mesma sub-rede, migre usando o recurso de migração in-loco.
A assinatura tem muitos Ambientes do Serviço de Aplicativo. Remova alguns antes de tentar criar mais.	A cota para sua assinatura do Ambiente do Serviço de Aplicativo foi atendida.	Remova os ambientes desnecessários ou contate o suporte para examinar as opções.
A migração não pode ser chamada neste ASE até que a atualização ativa seja concluída.	Os Ambientes do Serviço de Aplicativo não podem ser migrados durante as atualizações da plataforma. Você pode definir sua preferência de atualização no portal do Azure. Em alguns casos, uma atualização será iniciada ao visitar a página de migração se o Ambiente do Serviço de Aplicativo não estiver no build atual.	Aguarde até que a atualização seja concluída e, em seguida, migre.
Operação de gerenciamento do Ambiente do Serviço de Aplicativo em andamento.	O Ambiente do Serviço de Aplicativo está passando por uma operação de gerenciamento. Essas operações podem incluir atividades como implantações ou atualizações. A migração estará bloqueada até a conclusão dessas operações.	Você poderá migrar depois que essas operações forem concluídas.
Seu InteralLoadBalancingMode não é suportado no momento.	Os Ambientes de Serviço de Aplicativo que têm o InternalLoadBalancingMode definido com determinados valores não podem ser migrados usando o recurso de migração no momento. O InternalLoadBalancingMode deve ser alterado manualmente pela equipe da Microsoft.	Abra uma solicitação de suporte para envolver a equipe de suporte para resolve seu problema. Solicite uma atualização para o InternalLoadBalancingMode para permitir a migração.
A migração é inválida. Seu ASE precisa ser atualizado para a versão mais recente para garantir uma migração bem-sucedida. Vamos atualizar seu ASE agora. Experimente migrar novamente em algumas horas, assim que a atualização da plataforma for concluída.	Seu ambiente de serviço de aplicativo não está na compilação mínima exigida para a migração. Uma atualização é iniciada. O Ambiente do Serviço de Aplicativo não será afetado, mas você não poderá dimensionar ou fazer alterações no Ambiente do Serviço de Aplicativo enquanto a atualização estiver em andamento. Você não poderá fazer a migração até que a atualização seja concluída.	Aguarde até que a atualização seja concluída e, em seguida, migre.
A migração completa não poderá ser chamada antes que os endereços IP sejam gerados.	Esse erro aparece se você tentar migrar antes de concluir as etapas de pré-migração.	Verifique se você concluiu todas as etapas de pré-migração antes de tentar migrar. Consulte o guia passo a passo para migração.
A migração completa não pode ser chamada no Ase com o sufixo dns personalizado definido, mas sem uma Configuração de Sufixo Dns Personalizada AseV3 definida.	O Ambiente do Serviço de Aplicativo existente usa um sufixo de domínio personalizado. Será necessário configurar o sufixo de domínio personalizado para o Ambiente do Serviço de Aplicativo v3 durante o processo de migração.	Configurar um sufixo de domínio personalizado. Se você não quiser mais usar um sufixo de domínio personalizado, poderá removê-lo assim que a migração for concluída.

Visão geral do processo de migração usando o recurso de migração lado a lado

A migração lado a lado consiste em uma série de etapas que devem ser seguidas em ordem. Os pontos-chave são determinados para um subconjunto das etapas. É importante entender o que acontece durante essas etapas e como o ambiente e os aplicativos são afetados. Depois de revisar as informações a seguir e quando estiver pronto para migrar, siga o guia passo a passo.

Valide se há suporte para a migração usando o recurso de migração lado a lado para o Ambiente do Serviço de Aplicativo

A plataforma valida que o Ambiente do Serviço de Aplicativo pode ser migrado usando o recurso de migração lado a lado. Se o Ambiente do Serviço de Aplicativo não passar em todas as verificações da validação, você não poderá migrar neste momento usando o recurso de migração lado a lado. Confira a seção Solução de problemas para obter detalhes das possíveis causas de falha de validação. Se seu ambiente estiver em um estado não íntegro ou suspenso, você não poderá migrar até fazer as atualizações necessárias. Se você não puder migrar usando o recurso de migração lado a lado, confira as opções de migração manual.

A validação também verifica se o Ambiente do Serviço de Aplicativo não está na compilação mínima exigida para a migração. A compilação mínima é atualizada periodicamente para garantir que as correções de bug e melhorias mais recentes estejam disponíveis. Se o Ambiente do Serviço de Aplicativo não estiver na compilação mínima, você precisará iniciar a atualização por conta própria. Essa atualização é um processo padrão em que o Ambiente do Serviço de Aplicativo não será afetado, mas você não poderá dimensionar ou fazer alterações no Ambiente do Serviço de Aplicativo enquanto a atualização estiver em andamento. Não é possível migrar até que a atualização seja concluída. As atualizações podem levar de 8 a 12 horas para serem concluídas ou mais, dependendo do tamanho do ambiente. Se você planejar uma janela de tempo específica para a migração, deverá executar a verificação de validação de 24 a 48 horas antes do tempo de migração planejado para garantir que você tenha tempo para uma atualização, se necessária.

Selecionar e preparar a sub-rede para o novo Ambiente do Serviço de Aplicativo v3

A plataforma cria o Ambiente do Serviço de Aplicativo v3 em uma sub-rede diferente do Ambiente do Serviço de Aplicativo existente. Você precisa selecionar uma sub-rede que atenda aos seguintes requisitos:

• A sub-rede deve estar na mesma rede virtual e, portanto, na mesma região que o Ambiente do Serviço de Aplicativo existente.
  • Se a rede virtual não tiver uma sub-rede disponível, você precisará criar uma. Talvez seja necessário aumentar o espaço de endereço da sua rede virtual para criar uma sub-rede. Para obter mais informações, consulte Criar uma rede virtual.
• A sub-rede deverá se comunicar com a sub-rede em que o Ambiente do Serviço de Aplicativo existente está. Não deverá haver grupos de segurança de rede nem outras configurações de rede que possam impedir a comunicação entre as sub-redes.
• A sub-rede deverá ter uma única delegação de Microsoft.Web/hostingEnvironments.
• A sub-rede deverá ter endereços IP disponíveis suficientes para dar suporte ao novo Ambiente do Serviço de Aplicativo v3. O número de endereços IP necessários dependerá do número de instâncias que você vai usar para o novo Ambiente do Serviço de Aplicativo v3. Para saber mais, confira Rede do Ambiente do Serviço de Aplicativo v3.
• A sub-rede não deverá ter nenhum bloqueio aplicado. Se houver bloqueios, eles deverão ser removidos antes da migração. Se necessário, os bloqueios poderão ser adicionados novamente quando a migração for concluída. Para obter mais informações sobre bloqueios e herança de bloqueio, consulte Bloquear recursos para proteger a infraestrutura.
• Não deve haver nenhuma política do Azure bloqueando a migração ou as ações relacionadas. Se houver políticas que bloqueiem a criação de Ambientes do Serviço de Aplicativo ou a modificação de sub-redes, elas deverão ser removidas antes da migração. Se necessário, as políticas poderão ser adicionadas novamente quando a migração for concluída. Para obter mais informações sobre o Azure Policy, consulte a Visão geral do Azure Policy.

Gerar endereços IP de saída para o novo Ambiente do Serviço de Aplicativo v3

A plataforma cria os novos endereços IP de saída. Embora esses IPs sejam criados, a atividade com o Ambiente do Serviço de Aplicativo existente não é interrompida. No entanto, você não poderá dimensionar nem fazer alterações no ambiente existente. Esse processo leva cerca de 15 minutos para ser concluído.

Quando concluído, os novos IPs de saída que o seu futuro Ambiente do Serviço de Aplicativo v3 usará são criados. Esses novos IPs não têm nenhum efeito sobre o ambiente existente.

Você receberá o novo endereço IP de entrada após a conclusão da migração, mas antes de fazer a alteração do DNS para redirecionar o tráfego do cliente para o novo Ambiente do Serviço de Aplicativo v3. Você não obtém o IP de entrada neste momento no processo porque há dependências em recursos do Ambiente do Serviço de Aplicativo v3 que serão criados durante a etapa de migração. Você terá a chance de atualizar todos os recursos que dependem do novo IP de entrada antes de redirecionar o tráfego para o novo Ambiente do Serviço de Aplicativo v3.

Esta etapa também é aquela em que você decide se deseja habilitar a redundância de zona para o novo Ambiente do Serviço de Aplicativo v3. A redundância de zona pode ser habilitada desde que o Ambiente do Serviço de Aplicativo v3 esteja em uma região que dê suporte à redundância de zona.

Atualizar recursos dependentes com novos IPs de saída

Os novos IPs de saída são criados e fornecidos a você antes de realmente iniciar a migração. A nova saída padrão para os endereços públicos da Internet é fornecida para que você possa ajustar firewalls externos, roteamento DNS, grupos de segurança de rede e outros recursos que dependam desses IPs antes de concluir a migração. É sua responsabilidade atualizar todos os recursos que serão afetados pela alteração de endereço IP associada ao novo Ambiente do Serviço de Aplicativo v3. Não passe para a próxima etapa antes de fazer todas as atualizações necessárias. Você poderá experimentar algum tempo de inatividade após a etapa de migração se tiver dependências nos IPs de saída e não fizer todas as atualizações necessárias. Isso ocorre porque, depois que a migração for concluída, mesmo que o tráfego ainda vá para os front-ends do Ambiente do Serviço de Aplicativo v2, sua computação subjacente é seu novo Ambiente do Serviço de Aplicativo v3.

Essa etapa também é um bom momento para examinar as alterações de dependência de rede de entrada e saída ao mudar para o Ambiente do Serviço de Aplicativo v3, incluindo a alteração de porta para a investigação de integridade do Azure Load Balancer, que agora usa a porta 80.

Delegar a sub-rede do Ambiente do Serviço de Aplicativo

O Ambiente do Serviço de Aplicativo v3 requer que a sub-rede na qual ele está tenha apenas uma delegação de Microsoft.Web/hostingEnvironments. A migração não terá êxito se a sub-rede do Ambiente do Serviço de Aplicativo não for delegada ou for delegada a um recurso diferente. A sub-rede selecionada para o novo Ambiente do Serviço de Aplicativo v3 deverá ter uma única delegação de Microsoft.Web/hostingEnvironments.

Reconhecer alterações no tamanho da instância

Seus Planos do Serviço de Aplicativo serão criados com o SKU Isolado v2 correspondente como parte da migração. Por exemplo, os planos I2 correspondem ao I2v2. Seus aplicativos podem ficar superprovisionados após a migração, pois a camada Isolada v2 tem mais memória e CPU por tamanho de instância correspondente. Você tem a oportunidade de escalar seu ambiente conforme necessário após a conclusão da migração. Para obter mais informações, revise os Detalhes do SKU.

Verifique se não existem bloqueios em seus recursos

Os bloqueios da rede virtual bloqueiam as operações da plataforma durante a migração. Se sua rede virtual tiver bloqueios, você precisará removê-los antes de migrar. Se necessário, os bloqueios poderão ser adicionados novamente quando a migração for concluída. Os bloqueios podem existir em três escopos diferentes: assinatura, grupo de recursos e recurso. Quando você aplica um bloqueio a um escopo pai, todos os recursos filho herdam o mesmo bloqueio. Se você tiver bloqueios aplicados na assinatura, grupo de recursos ou escopo do recurso, eles precisarão ser removidos antes da migração. Para obter mais informações sobre bloqueios e herança de bloqueio, consulte Bloquear recursos para proteger a infraestrutura.

Verifique se não há nenhuma migração de bloqueio do Azure Policies

O Azure Policy pode ser usado para negar a criação e a modificação de recursos a determinadas entidades de segurança. Se você tiver uma política que bloqueie a criação de Ambientes do Serviço de Aplicativo ou a modificação de sub-redes, será necessário removê-la antes de migrar. Se necessário, os bloqueios poderão ser adicionados novamente quando a migração for concluída. Para obter mais informações sobre o Azure Policy, consulte a Visão geral do Azure Policy.

Adicionar um sufixo de domínio personalizado (opcional)

Se o Ambiente do Serviço de Aplicativo existente usar um sufixo de domínio personalizado, você deverá configurar um sufixo de domínio personalizado para o novo Ambiente do Serviço de Aplicativo v3. O sufixo de domínio personalizado no Ambiente do Serviço de Aplicativo v3 é implementado de maneira diferente do que no Ambiente do Serviço de Aplicativo v2. Você precisa fornecer o nome de domínio personalizado, a identidade gerenciada e o certificado, que devem ser armazenados no Azure Key Vault. Para obter mais informações sobre o sufixo de domínio personalizado do Ambiente do Serviço de Aplicativo v3, incluindo os respectivos requisitos, instruções passo a passo e melhores práticas, confira Configurar um sufixo de domínio personalizado para o Ambiente do Serviço de Aplicativo. Se o Ambiente do Serviço de Aplicativo v2 tiver um sufixo de domínio personalizado, você deverá configurar um sufixo de domínio personalizado para o novo ambiente, mesmo se você não quiser mais usá-lo. Após concluir a migração, você poderá remover a configuração de sufixo de domínio personalizado, se necessário.

Se a migração incluir um sufixo de domínio personalizado, para o Ambiente do Serviço de Aplicativo v3, o domínio personalizado não será mostrado na seção Essentials da página Visão Geral do portal, como é para o Ambiente do Serviço de Aplicativo v1/v2. Em vez disso, para o Ambiente do Serviço de Aplicativo v3, vá para a página Sufixo de domínio personalizado em que você poderá confirmar se o sufixo de domínio personalizado está configurado corretamente. Além disso, no Ambiente do Serviço de Aplicativo v2, se você tiver um sufixo de domínio personalizado, o nome do host padrão incluirá o seu sufixo de domínio personalizado e estará no formulário APP-NAME.internal.contoso.com. No Ambiente do Serviço de Aplicativo v3, o nome do host padrão sempre usa o sufixo de domínio padrão e estará no formulário APP-NAME.ASE-NAME.appserviceenvironment.net. Essa diferença ocorre porque o Ambiente do Serviço de Aplicativo v3 mantém o sufixo de domínio padrão quando você adiciona um sufixo de domínio personalizado. Com o Ambiente do Serviço de Aplicativo v2, há apenas um único sufixo de domínio.

Migrar para o Ambiente do Serviço de Aplicativo v3

Após concluir as etapas anteriores, será necessário continuar com a migração o mais rápido possível.

Não há tempo de inatividade do aplicativo durante a migração, mas como ocorre na etapa de geração de IP, você não poderá escalar ou modificar o Ambiente do Serviço de Aplicativo existente nem implantar aplicativos nele durante esse processo.

Importante

Como o dimensionamento é bloqueado durante a migração, você deve dimensionar seu ambiente para o tamanho desejado antes de iniciar a migração.

A migração lado a lado exige uma janela de serviço de três a seis horas para migrações do Ambiente de Serviço de Aplicativo v2 para v3. Durante a migração, as configurações de dimensionamento e ambiente são bloqueadas e os seguintes eventos ocorrem:

• O novo Ambiente do Serviço de Aplicativo v3 é criado na sub-rede selecionada.
• Seus novos Planos do Serviço de Aplicativo são criados no novo Ambiente do Serviço de Aplicativo v3 com a camada Isolada v2 correspondente.
• Seus aplicativos serão criados no novo Ambiente do Serviço de Aplicativo v3.
• A computação subjacente dos seus aplicativos é movida para o novo Ambiente do Serviço de Aplicativo v3. Os front-ends do Ambiente do Serviço de Aplicativo v2 ainda estão atendendo ao tráfego. O endereço IP de entrada antigo permanecerá em uso.
  • Para ambientes do Serviço de Aplicativo ILB, os front-ends do Ambiente do Serviço de Aplicativo v3 não serão usados até que você atualize as zonas DNS privadas com o novo endereço IP de entrada.
  • Para Ambientes do Serviço de Aplicativo de ELB, o processo de migração não redireciona o tráfego para os front-ends do Ambiente do Serviço de Aplicativo v3, até que você conclua a etapa final da migração.

Quando essa etapa for concluída, o tráfego do aplicativo continuará direcionado para o antigo Ambiente do Serviço de Aplicativo v2 e os IPs de entrada que foram atribuídos a ele. No entanto, agora você também tem um Ambiente do Serviço de Aplicativo v3 com todos os seus aplicativos.

Obter o endereço IP de entrada para seu novo Ambiente do Serviço de Aplicativo v3 e atualizar recursos dependentes

O novo endereço IP de entrada é fornecido para que você possa configurar novos pontos de extremidade com serviços como o Gerenciador de Tráfego ou o Azure Front Door e atualize qualquer uma de suas zonas DNS privadas. Não passe para a próxima etapa antes de fazer essas alterações. Haverá tempo de inatividade se você não atualizar recursos dependentes com o novo IP de entrada. É sua responsabilidade atualizar todos os recursos afetados pela alteração de endereço IP associada ao novo Ambiente do Serviço de Aplicativo v3. Não passe para a próxima etapa antes de fazer todas as atualizações necessárias.

Redirecionar o tráfego do cliente, validar o Ambiente do Serviço de Aplicativo v3 e concluir a migração

A etapa final é redirecionar o tráfego para o novo Ambiente do Serviço de Aplicativo v3 e concluir a migração. A plataforma faz essa alteração para você, mas somente quando você a inicia. Antes de executar esta etapa, você deve examinar o novo Ambiente do Serviço de Aplicativo v3 e executar todos os testes necessários para validar que ele está funcionando conforme o esperado. Por padrão, o tráfego vai para os front-ends do Ambiente do Serviço de Aplicativo v2. Se você estiver usando um Ambiente do Serviço de Aplicativo ILB v3, poderá testar os front-ends do Ambiente do Serviço de Aplicativo v3 atualizando a zona DNS privada com o novo endereço IP de entrada. Caso esteja usando um Ambiente do Serviço de Aplicativo ELB v3, o processo de teste dependerá de sua configuração de rede específica. Um método simples para testar ambientes de ELB é atualizar o arquivo de hosts para usar seu novo endereço IP de entrada do Ambiente do Serviço de Aplicativo v3. Caso tenha domínios personalizados atribuídos a seus aplicativos individuais, você poderá, como alternativa, atualizar o DNS deles para apontar para o novo IP de entrada. Testar essa alteração permite que você valide totalmente o Ambiente do Serviço de Aplicativo v3 antes de iniciar a etapa final da migração em que o antigo Ambiente do Serviço de Aplicativo foi excluído.

Quando estiver pronto para redirecionar o tráfego, você poderá realizar a etapa final da migração. Esta etapa atualiza os registros DNS internos para apontar para o endereço IP do balanceador de carga do seu novo Ambiente do Serviço de Aplicativo v3 para os front-ends criados durante a migração. As alterações são efetivadas em alguns minutos. Se você tiver problemas, verifique as configurações de cache e TTL. Esta etapa também desliga o ambiente antigo do Serviço de Aplicativo e o exclui. Seu novo Ambiente do Serviço de Aplicativo v3 agora é o ambiente de produção.

Se você descobrir problemas com o novo Ambiente do Serviço de Aplicativo v3, não execute o comando para redirecionar o tráfego do cliente. Esse comando também iniciará a exclusão do Ambiente do Serviço de Aplicativo v2. Se você encontrar um problema, poderá reverter todas as alterações e retornar ao Ambiente do Serviço de Aplicativo v2 antigo. O processo de reversão leva de 3 a 6 horas para ser concluído. Não há tempo de inatividade associado a esse processo. Depois que o processo de reversão for concluído, o ambiente antigo do Serviço de Aplicativo estará online novamente e o novo Ambiente do Serviço de Aplicativo v3 será excluído. Em seguida, você poderá tentar a migração novamente depois de resolver os possíveis problemas.

Preços

Não há nenhum custo para migrar o Ambiente do Serviço de Aplicativo. No entanto, você será cobrado pelo Ambiente do Serviço de Aplicativo v2 e o novo Ambiente do Serviço de Aplicativo v3 depois de iniciar o processo de migração. Você deixará de ser cobrado pelo Ambiente do Serviço de Aplicativo v2 antigo quando concluir a etapa de migração final em que o DNS é atualizado e o ambiente antigo é excluído. Você deve concluir a validação o mais rápido possível para evitar o acúmulo de cobranças em excesso. Para obter mais informações sobre os preços do Ambiente do Serviço de Aplicativo v3, consulte os detalhes de preços.

Ao migrar de versões anteriores para o Ambiente do Serviço de Aplicativo v3, há cenários que você deve considerar que podem reduzir o custo mensal. As reservas e os planos de economia podem reduzir ainda mais seus custos. Para obter informações sobre oportunidades de economia de custos, consulte Oportunidades de economia de custos após a atualização para o Ambiente do Serviço de Aplicativo v3.

Observação

Devido às diferenças entre os tipos de preço Isolado e Isolado v2, seus aplicativos poderão ser superprovisionados após a migração, uma vez que a camada Isolado v2 tem mais memória e CPU por tamanho de instância correspondente. Você terá a oportunidade de escalar o ambiente conforme necessário quando a migração for concluída. Para obter mais informações, revise os Detalhes do SKU.

Reduzir verticalmente seus planos do Serviço de Aplicativo

Os SKUs do plano do Serviço de Aplicativo disponíveis para Ambiente do Serviço de Aplicativo v3 são executados na camada Isolado v2 (Iv2). O número de núcleos e a quantidade de RAM são efetivamente dobrados por camada correspondente em comparação com a camada Isolada. Ao migrar, seus planos do Serviço de Aplicativo são convertidos na camada correspondente. Por exemplo, suas instâncias I2 são convertidas em I2v2. Embora a I2 tenha dois núcleos e 7 GB de RAM, a I2v2 tem quatro núcleos e 16 GB de RAM. Se você espera que seus requisitos de capacidade permaneçam iguais, você está superprovisionado e pagando por computação e memória que não está usando. Para esse cenário, você pode reduzir verticalmente sua instância I2v2 para I1v2 e acabar com um número semelhante de núcleos e RAM que você tinha anteriormente.

Perguntas frequentes

• E se não houver suporte para migrar meu Ambiente do Serviço de Aplicativo no momento?
  No momento, não é possível migrar usando o recurso de migração lado a lado. Se você tiver um ambiente sem suporte e desejar migrar imediatamente, consulte as Opções de migração manual.
• Como faço para escolher a opção de migração ideal para mim?
  Leia a árvore de decisão de caminho de migração para decidir qual opção é melhor para seu caso de uso.
• Como posso saber se devo usar o recurso de migração lado a lado?
  O recurso de migração lado a lado é melhor para clientes que desejam migrar para o Ambiente do Serviço de Aplicativo v3, mas não podem suportar o tempo de inatividade do aplicativo. Como uma nova sub-rede será usada para seu novo ambiente, há considerações de rede a serem observadas, incluindo novos IPs. Se você puder contar com algum tempo de inatividade, confira o recurso de migração in-loco, que resulta em alterações mínimas de configuração, ou as opções de migração manual. O recurso de migração in-loco cria o Ambiente do Serviço de Aplicativo v3 na mesma sub-rede que o ambiente existente e usa a mesma infraestrutura de rede.
• Haverá tempo de inatividade durante a migração?
  Não, não há tempo de inatividade durante o processo de migração lado a lado. Seus aplicativos continuam sendo executados no Ambiente do Serviço de Aplicativo existente até que você conclua a etapa final da migração, na qual as alterações de DNS entram em vigor imediatamente. Depois de concluir a etapa final, o Ambiente do Serviço de Aplicativo antigo será desligado e excluído. Seu novo Ambiente do Serviço de Aplicativo v3 agora é o ambiente de produção.
• Precisarei fazer algo com meus aplicativos após a migração para colocá-los em execução no novo Ambiente do Serviço de Aplicativo?
  Não, todos os aplicativos em execução no ambiente antigo serão migrados automaticamente para o novo ambiente e executados como antes. Nenhuma entrada do usuário é necessária.
• E se meu Ambiente do Serviço de Aplicativo tiver um sufixo de domínio personalizado?
  O recurso de migração lado a lado oferece suporte a esse cenário de migração.
• E se meu Ambiente do Serviço de Aplicativo estiver fixado à zona?
  O recurso de migração lado a lado não oferece suporte a esse cenário de migração no momento. Se você tiver um Ambiente do Serviço de Aplicativo fixado em uma zona e quiser migrar imediatamente, consulte as opções de migração manual.
• E se meu Ambiente de Serviço de Aplicativo tiver endereços IP SSL?
  Não há suporte para IP SSL no Ambiente de Serviço de Aplicativo v3. Você deve remover todos as associações de IP SSL antes de migrar usando o recurso de migração ou uma das opções manuais. Se você pretende usar o recurso de migração lado a lado, depois de remover todas as associações de IP SSL, você passará nessa verificação de validação e poderá prosseguir com a migração automatizada.
• Quais propriedades de meu Ambiente do Serviço de Aplicativo serão alteradas?
  Você está no Ambiente do Serviço de Aplicativo v3, portanto, não deixe de examinar os recursos e as diferenças de recursos em comparação com as versões anteriores. Os IPs de entrada e de saída são alterados ao usar o recurso de migração lado a lado. Observe que, para o Ambiente do Serviço de Aplicativo de ELB, anteriormente havia um único IP para entrada e saída. Para o Ambiente do Serviço de Aplicativo v3, eles são separados. Para saber mais, confira Rede do Ambiente do Serviço de Aplicativo v3. Para obter uma comparação completa das versões do Ambiente do Serviço de Aplicativo, consulte Comparação de versão do Ambiente do Serviço de Aplicativo.
• O que acontecerá se a migração falhar ou se houver um problema inesperado durante a migração?
  Se houver um problema inesperado, equipes de suporte estarão disponíveis. Recomendamos migrar ambientes de desenvolvimento antes de mexer em qualquer ambiente de produção para saber mais sobre o processo de migração e ver como isso afeta suas cargas de trabalho. Com o recurso de migração lado a lado, você pode reverter todas as alterações se houver algum problema.
• O que acontecerá com meu Ambiente do Serviço de Aplicativo antigo?
  Se você decidir migrar um Ambiente do Serviço de Aplicativo usando o recurso de migração lado a lado, o ambiente antigo será usado até a etapa final do processo de migração. Depois de concluir a etapa final, o ambiente antigo e todos os aplicativos hospedados nele serão desligados e excluídos. Seu ambiente antigo não estará mais acessível. Uma reversão para o ambiente antigo neste momento não é possível.
• O que acontecerá com os recursos do Ambiente do Serviço de Aplicativo V1/V2 depois de 31 de agosto de 2024?
  Após 31 de agosto de 2024, se você não tiver migrado para o Ambiente do Serviço de Aplicativo v3, seu Ambiente do Serviço de Aplicativo v1/v2 e os aplicativos implantados neles não estarão mais disponíveis. O Ambiente do Serviço de Aplicativo v1/v2 é hospedado em unidades de escala do serviço de aplicativo em execução na arquitetura de Serviços de nuvem (clássico) que será desativada em 31 de agosto de 2024. Por isso, o Ambiente do Serviço de Aplicativo v1/v2 não estará mais disponível após essa data. Migre para Ambiente do Serviço de Aplicativo v3 para manter seus aplicativos em execução ou salvar ou fazer backup de todos os recursos ou dados que você precisa manter.

Próximas etapas

Migrar seu Ambiente do Serviço de Aplicativo para o Ambiente do Serviço de Aplicativo v3 usando o recurso de migração lado a lado

Rede do Ambiente do Serviço de Aplicativo v3

Usar um Ambiente do Serviço de Aplicativo v3

Sufixo do Custom Domain