Detalhes técnicos da migração para os Serviços de Nuvem do Azure (suporte estendido)
Este artigo aborda os detalhes técnicos da ferramenta de migração pertencente aos Serviços de Nuvem (clássico).
Detalhes sobre recursos/cenários com suporte para migração
Migração de extensões e plug-ins
- Todas as extensões habilitadas e suportadas são migradas.
- As extensões desabilitadas não serão migradas.
- Plug-ins são um conceito herdado e devem ser removidos antes da migração. Eles são suportados para migração, mas após a migração, se a extensão precisar ser habilitada, o plug-in precisará ser removido antes de instalar a extensão. Essa limitação afeta principalmente plug-ins e extensões de área de trabalho remota.
Migração de certificados
- Nos Serviços de Nuvem (suporte estendido), os certificados são armazenados em um Key Vault. Como parte da migração, criamos um Key Vault para os clientes que tem o nome do Serviço de Nuvem e transferimos todos os certificados do Service Manager do Azure para esse Key Vault.
- A referência a esse Key Vault é especificada no modelo ou transmitida por meio do PowerShell ou da CLI do Azure.
Arquivos de configuração e de definição de serviço
- Os arquivos .cscfg e .csdef precisam ser atualizados para os Serviços de Nuvem (suporte estendido) com pequenas alterações.
- Os nomes de recursos como rede virtual e SKU de máquina virtual (VM) são diferentes. Consulte Conversão de recursos e convenção de nomenclatura após a migração
- Os clientes podem recuperar suas novas implantações usando o PowerShell e a API REST.
Serviço de Nuvem e implantações
- Cada implantação dos Serviços de Nuvem (suporte estendido) é um Serviço de Nuvem independente. As implantações não são mais agrupadas em um serviço de nuvem usando slots.
- Se você tiver dois slots no seu Serviço de Nuvem (clássico), precisará excluir um deles (de preparo) e usar a ferramenta de migração para mover o outro (de produção) para Azure Resource Manager.
- O endereço IP público na implantação do Serviço de Nuvem permanece o mesmo após a migração para o Azure Resource Manager e é exposto como recurso Básico de IP de SKU (dinâmico ou estático).
- O nome DNS e o domínio (cloudapp.net) para o serviço de nuvem migrado não mudam.
Migração de rede virtual
- Se uma implantação de Serviços de Nuvem estiver em rede virtual, durante a migração todos os Serviços de Nuvem e os recursos de rede virtual associados serão migrados juntos.
- Após a migração, a rede virtual é colocada em um grupo de recursos diferente do Serviço de Nuvem.
- Para redes virtuais com vários Serviços de Nuvem, cada um deles é migrado sequencialmente.
Migração de implantações que não estão em rede virtual
- No final de 2018, o Azure iniciou automaticamente a criação de novas implantações (sem rede virtual especificada pelo cliente) em uma rede virtual "padrão" criada na plataforma. Essas redes virtuais padrão ficam ocultas dos clientes.
- Como parte da migração, esta rede virtual padrão é exposta aos clientes uma vez no Azure Resource Manager. Para gerenciar ou atualizar a implantação no Azure Resource Manager, os clientes devem adicionar essas informações de rede virtual na seção NetworkConfiguration do arquivo .cscfg.
- A rede virtual padrão, quando migrada para o Azure Resource Manager, é colocada no mesmo grupo de recursos que o Serviço de Nuvem.
- Os Serviços de Nuvem criados antes dessa data (antes do final de 2018) não estarão em nenhuma rede virtual e não poderão ser migrados usando a ferramenta. Considere reimplantar esses Serviços de Nuvem diretamente no Azure Resource Manager. Outra abordagem é migrar por meio da criação de uma nova implantação de Preparo e verificando a VIPSwap. Confira mais detalhes aqui
- Para verificar se uma implantação está qualificada para migração, execute a API de validação na implantação. O resultado da API Validate contém uma mensagem de erro que menciona explicitamente se esta implantação é elegível para migração.
Load Balancer
- Para um Serviço de Nuvem que use um ponto de extremidade público, uma plataforma criada pelo balanceador de carga associada ao Serviço de Nuvem é exposta na assinatura do cliente no Azure Resource Manager. O balanceador de carga é um recurso do tipo somente leitura e as atualizações são restritas somente por meio dos arquivos de Configuração de Serviço (.cscfg) e Definição de Serviço (.csdef).
Key Vault
- Como parte da migração, o Azure cria automaticamente um novo Key Vault, para o qual migra todos os certificados. A ferramenta não permite que você use um Key Vault existente.
- Os Serviços de Nuvem (suporte estendido) exigem um Key Vault localizado nas mesmas região e assinatura. Esse Key Vault é criado automaticamente como parte da migração.
Os recursos e as funcionalidades não disponíveis para migração
Essa lista contém os principais cenários que envolvem combinações de recursos, funcionalidades e Serviços de Nuvem. Essa lista não é completa.
| Recurso | Próximas etapas / solução alternativa |
|---|---|
| Regras de Dimensionamento Automático | A migração é feita, mas as regras são ignoradas. Recrie as regras após a migração nos Serviços de Nuvem (suporte estendido). |
| Alertas | A migração é feita, mas os alertas são ignorados. Recrie as regras após a migração nos Serviços de Nuvem (suporte estendido). |
| Gateway de VPN | Remova o Gateway de VPN antes de iniciar a migração e crie novamente o Gateway de VPN após a conclusão da migração. |
| Gateway do Express Route (na mesma assinatura como Rede Virtual somente) | Remova o Gateway do Express Route antes de iniciar a migração e crie novamente o Gateway após a conclusão da migração. |
| Quota | A cota não é migrada. Solicite uma nova cota no Azure Resource Manager antes da migração para que a validação seja bem-sucedida. |
| Grupos de afinidade | Sem suporte. Remova todos os grupos de afinidade antes da migração. |
| Redes virtuais usando um emparelhamento de rede virtual | Antes de migrar uma rede virtual emparelhada para outra rede virtual, exclua o emparelhamento, migre a rede virtual para o Gerenciador de Recursos e recrie o emparelhamento. Isso pode causar tempo de inatividade dependendo da arquitetura. |
| Redes virtuais que contêm ambientes do Serviço de Aplicativo | Sem suporte |
| Redes virtuais com Implantações do Lote do Azure | Sem suporte |
| Redes virtuais que contêm serviços do HDInsight | Sem suporte. |
| Redes virtuais que contêm implantações do Gerenciamento de API do Azure | Sem suporte. Para migrar a rede virtual, altere a rede virtual da implantação do Gerenciamento de API. Essa é uma operação sem tempo de inatividade. |
| Circuitos do ExpressRoute clássico | Sem suporte. Esses circuitos precisam ser migrados para o Azure Resource Manager antes da migração do PaaS ser iniciada. Para saber mais, consulte Movimentação dos circuitos do ExpressRoute do modelo de implantação clássico para o Resource Manager. |
| Controle de Acesso Baseado em Função | Após a migração, o URI do recurso muda de Microsoft.ClassicCompute para Microsoft.Compute. As políticas de RBAC precisam ser atualizadas após a migração. |
| Gateway de Aplicativo | Sem suporte. Remova o Gateway de Aplicativo antes de iniciar a migração e crie novamente o Gateway de Aplicativo após a conclusão da migração para o Azure Resource Manager |
Cenários de configuração / migração sem suporte
| Configuração / Cenário | Próximas etapas / solução alternativa |
|---|---|
| Migração de algumas implantações mais antigas que não estão em uma rede virtual | Algumas implantações do Serviço de Nuvem que não estão em uma rede virtual não têm suporte para migração. 1. Use a API de validação para verificar se a implantação está qualificada para migração. 2. Se elegíveis, as implantações passam para o Azure Resource Manager numa rede virtual com o prefixo “DefaultRdfeVnet” |
| Migração de implantações que contêm a implantação de slot de preparo e de produção usando endereços IP dinâmicos | A migração de um Serviço de Nuvem de dois slots requer a exclusão do slot de preparo. Após a exclusão do slot de preparo, migre o slot de produção como um Serviço de Nuvem independente (suporte estendido) no Azure Resource Manager. Em seguida, reimplante o ambiente de preparo como um novo Serviço de Nuvem (suporte estendido) e o torne trocável com o primeiro. |
| Migração de implantações que contêm a implantação de slot de preparo e de produção usando endereços IP Reservados | Sem suporte. |
| Migração de implantação de produção e preparo para uma rede virtual diferente | A migração de um serviço de nuvem de dois slots requer a exclusão do slot de preparo. Após a exclusão do slot de preparo, migre o slot de produção como um serviço de nuvem independente (suporte estendido) no Azure Resource Manager. Uma implantação nova dos Serviços de Nuvem (suporte estendido) pode ser vinculada à implantação migrada com a propriedade trocável habilitada. Os arquivos de implantações da implantação do slot de preparo antigo podem ser reutilizados para criar essa nova implantação trocável. |
| Migração do Serviço de Nuvem vazio (Serviço de Nuvem sem implantação) | Sem suporte. |
| Migração da implantação que contém o plug-in da área de trabalho remota e as extensões da área de trabalho | Opção 1: remova o plug-in da área de trabalho remota antes da migração. Isto requer alterações nos arquivos de implantação. A migração então ocorre. Opção 2: remova a extensão da área de trabalho remota e migre a implantação. Após a migração, remova o plug-in e instale a extensão. Isto requer alterações nos arquivos de implantação. Remova o plug-in e a extensão antes da migração. Os plug-ins não são recomendados para uso nos Serviços de Nuvem (suporte estendido). |
| Redes virtuais com a PaaS e a implantação de IaaS | Sem suporte Mova as implantações de PaaS ou IaaS para uma rede virtual diferente. Isso causa tempo de inatividade. |
| Implantações de Serviço de Nuvem usando tamanhos de função herdados (como Small ou ExtraLarge). | Os tamanhos de função precisam ser atualizados antes da migração. Atualize todos os artefatos de implantação para fazer referência a esses novos tamanhos de função modernos. Para obter mais informações, consulte Tamanhos de VM disponíveis |
| Migração do Serviço de Nuvem para uma rede virtual diferente | Sem suporte 1. Mova a implantação para uma rede virtual clássica diferente antes da migração. Isso causa tempo de inatividade. 2. Migre a nova rede virtual para o Azure Resource Manager. Ou 1. Migre a rede virtual para o Azure Resource Manager 2. Mova o Serviço de Nuvem para uma nova rede virtual. Isso causa tempo de inatividade. |
| Serviço de Nuvem em uma rede virtual, mas não tem uma sub-rede explícita atribuída | Sem suporte. A mitigação envolve mover a função para uma sub-rede, o que requer uma reinicialização de função (tempo de inatividade) |
Conversão de recursos e convenção de nomenclatura após a migração
Como parte da migração, os nomes de recursos são alterados e poucos recursos dos Serviços de Nuvem são expostos como recursos do Azure Resource Manager. A tabela resume as alterações específicas da migração de Serviços de Nuvem.
| Serviços de Nuvem (clássico) Nome do recurso |
Serviços de Nuvem (clássico) Sintaxe |
Serviços de Nuvem (suporte estendido) Nome do recurso |
Serviços de Nuvem (suporte estendido) Sintaxe |
|---|---|---|---|
| Serviço de nuvem | cloudservicename |
Não associado | Não associado |
| Implantação (criada pelo portal) Implantação (criada sem portal) |
deploymentname |
Serviços de Nuvem (suporte estendido) | cloudservicename |
| Rede Virtual | vnetname Group resourcegroupname vnetname Não associado |
Rede Virtual (não criada pelo portal) Rede Virtual (criada pelo portal) Redes Virtuais (Padrão) |
vnetname group-resourcegroupname-vnetname VNet-cloudservicename |
| Não associado | Não associado | Key Vault | KV-cloudservicename |
| Não associado | Não associado | Grupo de Recursos para Implantações de Serviços de Nuvem | cloudservicename-migrated |
| Não associado | Não associado | Grupo de Recursos para Rede Virtual | vnetname-migrated group-resourcegroupname-vnetname-migrated |
| Não associado | Não associado | IP Público (Dinâmico) | cloudservicenameContractContract |
| Nome do IP Reservado | reservedipname |
Reserva de IP (criado sem portal) IP Reservado (criado pelo portal) |
reservedipname group-resourcegroupname-reservedipname |
| Não associado | Não associado | Load Balancer | LB-cloudservicename |
Problemas de migração e como tratá-los.
Migração paralisada em uma operação por longo tempo.
- As operações de confirmação, preparação e anulação podem ser muito demoradas, dependendo do número de implantações. As operações atingirão seu tempo limite após 24 horas.
- As operações de confirmação, preparação e anulação são idempotentes. A maioria dos problemas é corrigível com uma nova tentativa. Pode haver erros transitórios, que talvez desapareçam em minutos. Recomendamos tentar novamente após um intervalo. Se você estiver migrando com o uso do portal do Azure e a operação estiver paralisada em "estado em andamento", use o PowerShell para tentar executá-la novamente.
- Entre em contato com o suporte para ajudar a migrar ou reverter a implantação do back-end.
Falha de uma operação na migração.
- Se a validação falhou, é porque a implantação ou rede virtual contém um cenário/recurso/recurso não suportado. Use a lista de cenários sem suporte para encontrar a solução alternativa nos documentos.
- A operação de preparação primeiro faz a validação, incluindo algumas validações caras (não cobertas pela validação). A falha de preparação pode dever-se a um cenário sem suporte. Encontre o cenário e a solução alternativa nos documentos públicos. A anulação precisa ser acionada, para que haja a volta ao estado original e a implantação seja desbloqueada para as operações de atualização e exclusão.
- Se a anulação falhar, tente novamente executar a operação. Se as novas tentativas falharem, entre em contato com o suporte.
- Se a confirmação falhar, tente novamente a operação. Se a nova tentativa falhar, entre em contato com o suporte. Mesmo em caso de falha de confirmação, não deve haver problemas de plano de dados para sua implantação. Sua implantação deve conseguir lidar com o tráfego do cliente sem problemas.
Portal atualizado após a Preparação. Experiência reiniciada e Confirmação ou Anulação não são mais visíveis.
- O portal armazena as informações de migração localmente; portanto, após a atualização, ele começará pela fase de validação, mesmo que o Serviço de Nuvem esteja na fase de preparação.
- Você pode usar o portal para percorrer novamente as etapas de validação e preparação, para expor os botões Anular e Confirmar. Não causará falhas.
- Os clientes podem usar o PowerShell ou a API REST para anulação ou confirmação.
Quanto tempo as operações podem demorar?
A validação foi projetada para ser rápida. A preparação é a execução mais longa e leva algum tempo, dependendo do total das instâncias de função migradas. Abortar e confirmar também podem levar tempo, mas levam menos tempo em comparação com a preparação. Todas as operações atingirão seu tempo limite após 24 horas.
Próximas etapas
Para obter ajuda ao migrar sua implantação dos Serviços de Nuvem (clássico) para os Serviços de Nuvem (suporte estendido), confira nossa página de aterrissagem de Suporte e solução de problemas.