Partilhar via

Detalhes técnicos da migração para o suporte alargado dos Serviços Cloud do Azure (suporte alargado)

  • Artigo

Este artigo discute os detalhes técnicos relativos à ferramenta de migração como pertencentes aos Serviços de Nuvem (clássico).

Detalhes sobre recursos/cenários suportados para migração

Extensões e migração de plug-ins

  • Todas as extensões habilitadas e suportadas são migradas.
  • As extensões desativadas não serão migradas.
  • Os plugins são um conceito legado 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 ativada, o plug-in precisa ser removido antes de instalar a extensão. Essa limitação afeta mais os 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 Cofre de Chaves. Como parte da migração, criamos um Cofre de Chaves para os clientes com o nome do Serviço de Nuvem e transferimos todos os certificados do Azure Service Manager para o Cofre de Chaves.
  • A referência a este Cofre da Chave é especificada no modelo ou passada pelo PowerShell ou pela CLI do Azure.

Arquivos de configuração e definição de serviço

Serviço de nuvem e implantações

  • Cada implantação de 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 Serviço de Nuvem (clássico), precisará excluir um slot (preparação) e usar a ferramenta de migração para mover o outro slot (produção) para o Gerenciador de Recursos do Azure.
  • O endereço IP público na implantação do Serviço de Nuvem permanece o mesmo após a migração para o Gerenciador de Recursos do Azure e é exposto como um recurso IP de SKU Básico (dinâmico ou estático).
  • O nome DNS e o domínio (cloudapp.net) para o serviço de nuvem migrado permanecem os mesmos.

Migração de rede virtual

  • Se uma implantação de Serviços de Nuvem estiver em uma rede virtual, durante a migração, todos os Serviços de Nuvem e 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 Serviço de Nuvem é migrado um após o outro.

Migração de implantações que não estão em uma rede virtual

  • No final de 2018, o Azure começou a criar automaticamente novas implantações (sem rede virtual especificada pelo cliente) em uma plataforma criada como rede virtual "padrão". Essas redes virtuais padrão são ocultadas dos clientes.
  • Como parte da migração, essa rede virtual padrão é exposta aos clientes uma vez no Gerenciador de Recursos do Azure. Para gerenciar ou atualizar a implantação no Gerenciador de Recursos do Azure, os clientes precisam 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 desse período (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 Gerenciador de Recursos do Azure. Outra abordagem é migrar por meio da criação de novas implantações de preparo e 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 de Validar API contém uma mensagem de erro mencionando explicitamente se essa implantação está qualificada para migração.

Balanceador de Carga

  • Para um Serviço de Nuvem usando um ponto de extremidade público, um balanceador de carga criado pela plataforma associado ao Serviço de Nuvem é exposto dentro da assinatura do cliente no Gerenciador de Recursos do Azure. O balanceador de carga é um recurso 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 Cofre da Chave e migra todos os certificados para ele. A ferramenta não permite que você use um Cofre de Chaves existente.
  • Os Serviços na Nuvem (suporte estendido) exigem um Cofre da Chave localizado na mesma região e assinatura. Este Cofre de Chaves é criado automaticamente como parte da migração.

Recursos e recursos não disponíveis para migração

Esta lista contém os principais cenários que envolvem combinações de recursos, recursos e Serviços de Nuvem. Esta lista não é exaustiva.

Recurso Próximos passos / solução alternativa
Regras de dimensionamento automático A migração passa, mas as regras são abandonadas. Recrie as regras após a migração nos Serviços de Nuvem (suporte estendido).
Alertas A migração passa, mas os alertas são descartados. Recrie as regras após a migração nos Serviços de Nuvem (suporte estendido).
Gateway de VPN Remova o Gateway VPN antes de iniciar a migração e, em seguida, recrie o Gateway VPN assim que a migração for concluída.
Express Route Gateway (apenas na mesma subscrição que a Rede Virtual) Remova o Express Route Gateway antes de iniciar a migração e, em seguida, recrie o Gateway assim que a migração for concluída.
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 Não suportado. Remova todos os grupos de afinidade antes da migração.
Redes virtuais usando 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 Não suportado
Redes virtuais com implantações em lote do Azure Não suportado
Redes virtuais que contêm serviços HDInsight Não suportado.
Redes virtuais que contêm implantações do Gerenciamento de API do Azure Não suportado.

Para migrar a rede virtual, altere a rede virtual da implantação do Gerenciamento de API. Esta é uma operação sem tempo de inatividade.
Circuitos Classic Express Route Não suportado.

Esses circuitos precisam ser migrados para o Azure Resource Manager antes de iniciar a migração de PaaS. Para saber mais, consulte Movendo circuitos de Rota Expressa do modelo de implantação clássico para o Resource Manager.
Controlo de Acesso Baseado em Funções Após a migração, o URI das alterações de recurso para Microsoft.Compute políticas RBAC Microsoft.ClassicCompute precisa ser atualizado após a migração.
Gateway de Aplicação Não suportado.

Remova o Gateway de Aplicativo antes de iniciar a migração e, em seguida, recrie o Gateway de Aplicativo assim que a migração for concluída para o Azure Resource Manager

Configurações / cenários de migração não suportados

Configuração / Cenário Próximos passos / 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 são suportadas para migração.

1. Use a API de validação para verificar se a implantação está qualificada para migração.
2. Se elegível, as implantações são movidas para o Azure Resource Manager em uma rede virtual com prefixo de "DefaultRdfeVnet"
Migração de implantações contendo a implantação de slots de produção e de preparo 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 preparação. Depois que o slot de preparo for excluído, migre o slot de produção como um Serviço de Nuvem independente (suporte estendido) no Gerenciador de Recursos do Azure. Em seguida, reimplante o ambiente de preparo como um novo serviço de nuvem (suporte estendido) e torne-o trocável com o primeiro.
Migração de implantações contendo implantação de slots de produção e de preparo usando endereços IP reservados Não suportado.
Migração de produção e implementação de preparo em diferentes redes virtuais A migração de um serviço de nuvem de dois slots requer a exclusão do slot de preparo. Depois que o slot de preparo for excluído, migre o slot de produção como um serviço de nuvem independente (suporte estendido) no Gerenciador de Recursos do Azure. Uma nova implantação de Serviços de Nuvem (suporte estendido) pode ser vinculada à implantação migrada com a propriedade permutável habilitada. Os arquivos de implantação da implantação do slot de preparo antigo podem ser reutilizados para criar essa nova implantação permutável.
Migração de Cloud Service vazio (Cloud Service sem implementação) Não suportado.
Migração de implantação contendo o plug-in de área de trabalho remota e as extensões de área de trabalho remota Opção 1: Remova o plug-in da área de trabalho remota antes da migração. Isso requer alterações nos arquivos de implantação. A migração, então, passa.

Opção 2: Remova a extensão da área de trabalho remota e migre a implantação. Após a migração, remova o plugin e instale a extensão. Isso requer alterações nos arquivos de implantação.

Remova o plugin e a extensão antes da migração. Os plug-ins não são recomendados para uso em Serviços de Nuvem (suporte estendido).
Redes virtuais com implantação de PaaS e IaaS Não suportado

Mova as implantações de PaaS ou IaaS para uma rede virtual diferente. Isso causa tempo de inatividade.
Implantações do Serviço de Nuvem usando tamanhos de função herdados (como Small ou ExtraLarge). Os tamanhos das funções 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 Cloud Service para diferentes redes virtuais Não suportado

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. Migrar 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 Não suportado. A atenuação envolve mover a função para uma sub-rede, o que requer uma reinicialização da função (tempo de inatividade)

Tradução de recursos e convenção de nomenclatura pós-migração

Como parte da migração, os nomes dos recursos são alterados e alguns recursos dos Serviços de Nuvem são expostos como recursos do Azure Resource Manager. A tabela resume as alterações específicas para a migração de Serviços de Nuvem.

Serviços na nuvem (clássico)

Nome do recurso		 Serviços na nuvem (clássico)

Sintaxe		 Serviços na nuvem (suporte alargado)

Nome do recurso		 Serviços na nuvem (suporte alargado)

Sintaxe
Serviço Cloud cloudservicename Não associado Não associado
Implantação (portal criado)

Implantação (não criado no portal)		 deploymentname Serviços na nuvem (suporte alargado) cloudservicename
Rede Virtual vnetname

Group resourcegroupname vnetname

Não associado		 Rede Virtual (não portal criado)

Rede Virtual (portal criado)

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 IP reservado reservedipname IP reservado (não criado no portal)

IP reservado (portal criado)		 reservedipname

group-resourcegroupname-reservedipname
Não associado Não associado Balanceador de Carga LB-cloudservicename

Problemas de migração e como lidar com eles.

A migração ficou presa em uma operação por muito tempo.

  • Confirmar, preparar e abortar pode levar muito tempo, dependendo do número de implantações. As operações expirarão após 24 horas.
  • Cometer, preparar e abortar operações são idempotentes. A maioria dos problemas pode ser corrigida repetindo. Pode haver erros transitórios, que podem desaparecer em poucos minutos, recomendamos tentar novamente após um intervalo. Se a migração usando o portal do Azure e a operação estiver presa em um "estado em andamento", use o PowerShell para repetir a operação.
  • Entre em contato com o suporte para ajudar a migrar ou reverter a implantação do back-end.

A migração falhou em uma operação.

  • Se a validação falhar, é porque a implantação ou a rede virtual contém um cenário/recurso/recurso sem suporte. Use a lista de cenários sem suporte para encontrar a solução alternativa nos documentos.
  • Preparar operação primeiro faz validação, incluindo algumas validações caras (não cobertas na validação). A falha na preparação pode ser devida a um cenário sem suporte. Encontre o cenário e a solução alternativa nos documentos públicos. Abortar precisa ser chamado para voltar ao estado original e desbloquear a implantação para atualizações e operações de exclusão.
  • Se o abortamento falhar, tente novamente 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 falha de confirmação, não deve haver nenhum problema de plano de dados para sua implantação. Sua implantação deve ser capaz de lidar com o tráfego do cliente sem qualquer problema.

Portal atualizado após Preparar. A experiência foi reiniciada e Confirmar ou Anular não está mais visível.

  • O portal armazena as informações de migração localmente e, portanto, após a atualização, ele começará a partir da fase de validação, mesmo que o Serviço de Nuvem esteja na fase de preparação.
  • Você pode usar o portal para percorrer as etapas de validação e preparação novamente para expor o botão Abortar e Confirmar. Não causará falhas.
  • Os clientes podem usar o PowerShell ou a API REST para abortar ou confirmar.

Quanto tempo podem demorar as operações?

O Validate foi concebido para ser rápido. A preparação é mais longa e leva algum tempo, dependendo do número total de instâncias de função que estão sendo migradas. Abortar e comprometer também pode levar tempo, mas leva menos tempo em comparação com a preparação. Todas as operações expirarão após 24 horas.

Próximos passos

Para obter assistência na migração de sua implantação de Serviços de Nuvem (clássica) para Serviços de Nuvem (suporte estendido), consulte nossa página inicial de Suporte e solução de problemas .