Compartilhar via

Detalhes técnicos da migração para os Serviços de Nuvem do Azure (suporte estendido)

  • Artigo

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 com suporte serã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 têm suporte para migração, mas após esse processo, se a extensão precisar ser habilitada, o plug-in deverá ser removido antes da instalação da extensão. Isso afeta plug-ins e extensões da á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

Serviço de Nuvem e implantações

  • Cada implantação dos Serviços de Nuvem (suporte estendido) é um Serviço de Nuvem independente. A implantação não é mais agrupada em um serviço de nuvem com o uso de 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, essa rede virtual padrão será exposta aos clientes quando estiverem 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 de Validação conterá uma mensagem de erro mencionando explicitamente se essa implantação está qualificada 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 o uso de 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

Esses são 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 qualificada, as implantações serão movidas para o Azure Resource Manager em uma 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 será feita.

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 causará 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 causará 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 causará 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 (não criada pelo 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 IP Reservado (não criado pelo 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 falhar, o motivo é que a implantação ou a rede virtual contém um cenário/funcionalidade/recurso sem suporte. 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 anulação falhar, tente novamente executar 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. A anulação e a confirmação também podem demorar, embora menos do que 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.