Partilhar via

Realocar os Serviços de Aplicativo do Azure para outra região

  • Artigo

Este artigo descreve como mover recursos do Serviço de Aplicativo para uma região diferente do Azure.

Há vários motivos pelos quais você pode querer mover seus recursos existentes do Azure de uma região para outra. Você pode querer:

  • Aproveite uma nova região do Azure.
  • Implante recursos ou serviços disponíveis apenas em regiões específicas.
  • Atender aos requisitos internos de política e governança.
  • Alinhar-se com fusões e aquisições de empresas
  • Atenda aos requisitos de planejamento de capacidade.

Os recursos do Serviço de Aplicativo são específicos da região e não podem ser movidos entre regiões. Você deve criar uma cópia dos recursos existentes do Serviço de Aplicativo na região de destino e, em seguida, realocar o conteúdo para o novo aplicativo. Se o aplicativo de origem usar um domínio personalizado, você poderá migrá-lo para o novo aplicativo na região de destino após a conclusão da realocação.

Para facilitar a cópia do seu aplicativo, você pode fazer backup e restaurar um aplicativo individual do Serviço de Aplicativo em um plano do Serviço de Aplicativo em outra região.

Pré-requisitos

  • Verifique se o aplicativo do Serviço de Aplicativo está na região do Azure da qual você deseja mover.
  • Certifique-se de que a região de destino suporta o Serviço de Aplicativo e qualquer serviço relacionado, cujos recursos você deseja mover.
  • Valide se existe permissão suficiente para implantar recursos do Serviço de Aplicativo na assinatura e região de destino.
  • Valide se alguma política do Azure é atribuída com uma restrição de região.
  • Considere quaisquer custos operacionais, pois os preços dos recursos de computação podem variar de região para região. Para estimar seus possíveis custos, consulte Calculadora de preços.

Preparação

Identifique todos os recursos do Serviço de Aplicativo que você está usando no momento. Por exemplo:

Determinados recursos, como certificados importados ou conexões híbridas, contêm integração com outros serviços do Azure. Para obter informações sobre como mover esses recursos entre regiões, consulte a documentação dos respetivos serviços.

Planear

Esta seção é uma lista de verificação de planejamento nas seguintes áreas:

  • Dependências de estado, armazenamento e downstream
  • Certificados
  • Configuração
  • Conectividade VNet / Nomes personalizados / DNS
  • Identidades
  • Pontos Finais de Serviço

Dependências de estado, armazenamento e downstream

  • Determine se seu Aplicativo do Serviço de Aplicativo tem ou sem monitoração de estado. Embora recomendemos que os Aplicativos do Serviço de Aplicativo sejam sem monitoração de estado e que os %HOME%\site arquivos na unidade sejam apenas aqueles necessários para executar o aplicativo implantado com quaisquer arquivos temporários, ainda é possível armazenar o %HOME%\site estado do aplicativo de tempo de execução na unidade virtual. Se o seu aplicativo gravar o estado no caminho de armazenamento compartilhado do aplicativo, certifique-se de planejar como você gerenciará esse estado durante uma movimentação de recurso.

    Gorjeta

    Você pode usar o Kudu para, juntamente com o acesso ao portal, fornecer uma API de acesso a arquivos (Virtual File System (VFS)) que pode ler/gravar arquivos no %HOME%\site diretório. Para obter mais informações, consulte Kudu Wiki.

  • Verifique se há cache interno e estado no código do aplicativo.

  • Desative a configuração de afinidade de sessão. Sempre que possível, recomendamos que desative a definição de afinidade de sessão. A desativação da afinidade de sessão melhora o balanceamento de carga para uma expansão horizontal. Qualquer estado interno pode afetar o planejamento para reduzir uma carga de trabalho - especialmente se o tempo de inatividade zero for um requisito. Sempre que possível, pode ser benéfico refatorar qualquer estado do aplicativo para torná-lo sem estado em preparação para a mudança.

  • Analise cadeias de conexão de banco de dados. As cadeias de conexão de banco de dados podem ser encontradas nas Configurações do aplicativo. No entanto, eles também podem ser codificados ou gerenciados em arquivos de configuração que são fornecidos com o aplicativo. Analise e planeje a migração/replicação de dados como parte do planejamento de nível superior para mover a carga de trabalho. Para aplicativos chatos ou críticos de latência, não é eficiente para o aplicativo na região de destino retornar às fontes de dados na região de origem.

  • Analise o cache externo (por exemplo, Redis). Os caches de aplicativos devem ser implantados o mais próximo possível do aplicativo. Analise como os caches são preenchidos, as políticas de expiração/remoção e qualquer impacto que um cache frio possa ter nos primeiros usuários a acessar a carga de trabalho após o corte.

  • Analise e planeje dependências de API (ou aplicativo) A comunicação entre regiões terá um desempenho significativamente menor se o aplicativo na região de destino retornar às dependências que ainda estão na região de origem. Recomendamos que você realoque todas as dependências a jusante como parte da realocação da carga de trabalho. No entanto, os recursos *no local* são a exceção, em especial os recursos geograficamente mais próximos da região de destino (como pode ser o caso dos cenários de repatriamento).

    O Registro de Contêiner do Azure pode ser uma dependência downstream (tempo de execução) para o Serviço de Aplicativo configurado para ser executado em Imagens de Contêiner Personalizadas. Faz mais sentido que o Registro de Contêiner esteja na mesma região que o próprio Aplicativo. Considere carregar as imagens necessárias para um novo ACR na região get de destino. Caso contrário, considere usar o recurso de replicação geográfica se você planeja manter as imagens na região de origem.

  • Analisar e planear serviços regionais. Os dados do Application Insights e do Log Analytics são serviços regionais. Considere a criação de um novo armazenamento do Application Insights e do Log Analytics na região de destino. Para o App Insights, um novo recurso também afeta a cadeia de conexão que deve ser atualizada como parte da alteração na Configuração do aplicativo.

Certificados

Há vários tipos diferentes de certificados que precisam ser levados em consideração ao planejar sua realocação do Serviço de Aplicativo:

  • Um Certificado Gerenciado Gratuito do Serviço de Aplicativo não é exportável.
  • Um Certificado do Serviço de Aplicativo por meio do Azure Key Vault pode ser exportado usando PS1/CLI.
  • Um certificado que você gerencia fora do Serviço de Aplicativo.
  • Um Certificado do Serviço de Aplicativo, não gerenciado por meio do Cofre de Chaves do Azure, pode ser exportado.
  • Os recursos de certificado do Serviço de Aplicativo podem ser movidos para um novo Grupo de Recursos ou Assinatura, mas não entre regiões. As realocações entre regiões não são suportadas pelos Certificados do Serviço de Aplicativo.
  • Os certificados gerenciados que você gerencia e armazena no Cofre da Chave do Azure precisariam primeiro ser exportados do Cofre da Chave de origem e reimportados para o Cofre da Chave de Destino associado ao aplicativo de destino.

Alguns outros pontos a considerar:

  • Os Endereços Atribuídos ao Aplicativo, em que a conexão SSL de um aplicativo do Serviço de Aplicativo está vinculada a um IP designado do aplicativo específico, podem ser usados para listar chamadas de permissões de redes de terceiros para o Serviço de Aplicativo. Por exemplo, um administrador de rede/TI pode querer bloquear chamadas de saída de uma rede local ou VNet para usar um endereço estático e conhecido. Como tal, se o recurso Endereço Atribuído ao Aplicativo estiver em uso, as regras de firewall upstream - como internas, externas ou de terceiros - para os chamadores no aplicativo devem ser verificadas e informadas do novo endereço. As regras de firewall podem ser internas, externas ou de terceiros, como parceiros ou clientes conhecidos.

  • Considere qualquer Network Virtual Appliance (NVA) upstream ou proxy reverso. A configuração do NVA pode precisar ser alterada se você estiver reescrevendo o cabeçalho do host ou e/ou terminação SSL.

Nota

O Ambiente do Serviço de Aplicativo é a única oferta do Serviço de Aplicativo que permite chamadas downstream para dependências de aplicativos downstream sobre SSL, onde o SSL depende de autoassinado/PKI com certificados de CA raiz não padrão. O serviço multilocatário não fornece acesso para que os clientes carreguem para o armazenamento de certificados confiáveis.

O Ambiente do Serviço de Aplicativo hoje não permite a compra de certificados SSL, apenas Traga seus próprios certificados. O IP-SSL não é possível (e não faz sentido), mas o SNI é. O Ambiente Interno do Serviço de Aplicativo não seria associado a um domínio público e, portanto, os certificados SSL usados devem ser fornecidos pelo cliente e, portanto, são transportáveis, por exemplo, certificados para uso interno gerados usando PKI. O Ambiente do Serviço de Aplicativo v3 no modo externo compartilha os mesmos recursos que o Serviço de Aplicativo multilocatário regular.

Configuração

  • Analise a Configuração do Aplicativo para ver as configurações específicas do ambiente e da região que podem precisar de modificação. Certifique-se de verificar se inclui a configuração do arquivo de disco, que pode ou não ser substituída pelas Configurações do aplicativo.

  • Considere que a configuração também pode ser gerenciada a partir de uma dependência de banco de dados central (downstream) ou de um serviço como a Configuração de Aplicativo do Azure.

  • Recrie referências do Cofre da Chave do Serviço de Aplicativo. As referências do Cofre da Chave estão relacionadas ao MSI exclusivo atribuído ao recurso (que tem acesso ao plano de dados KV) e o próprio Cofre da Chave provavelmente precisa estar na mesma região de origem. O conteúdo do Az Key Vault não pode ser exportado através de um limite geográfico do Azure.

Conectividade VNet / Nomes personalizados / DNS

  • O Ambiente do Serviço de Aplicativo é um serviço de locatário único com injeção de rede virtual. A rede do Ambiente do Serviço de Aplicativo difere do Serviço de Aplicativo multilocatário, que requer um ou ambos os "Pontos de Extremidade Privados" ou "Integração de Rede Virtual Regional". Outras opções que podem estar em jogo incluem a integração VNet baseada em VPN P2S herdada e Conexões Híbridas (um serviço de Retransmissão do Azure).

    Nota

    A Rede ASEv3 é simplificada - o tráfego de Gerenciamento do Azure e as próprias dependências downstream dos Ambientes do Serviço de Aplicativo não são visíveis para a Rede Virtual do cliente, simplificando consideravelmente a configuração necessária onde o cliente está usando um túnel de força para todo o tráfego, ou enviando um subconjunto de tráfego de saída, por meio de um Dispositivo Virtual de Rede/Firewall.

    As Conexões Híbridas (Azure Relay) são regionais. Se as Conexões Híbridas forem usadas e embora um Namespace de Retransmissão do Azure possa ser movido para outra região, seria mais simples reimplantar a Conexão Híbrida (garantir que a conexão Híbrida seja configurada na nova região na implantação dos recursos de destino) e vinculá-la novamente ao Gerenciador de Conexões Híbridas. O local do Hybrid Connection Manager deve ser cuidadosamente considerado.

  • Siga a estratégia para uma região de espera quente. Certifique-se de que a rede principal e a conectividade, a rede Hub, os controladores de domínio, DNS, VPN ou Rota Expressa, etc., estão presentes e são testados antes da realocação de recursos.

  • Valide todas as ACLs e configurações de rede upstream ou downstream. Por exemplo, considere um serviço downstream externo que permita listar apenas o tráfego do seu aplicativo. Uma realocação para um novo Plano de Aplicativo para um Serviço de Aplicativo multilocatário também seria uma alteração nos endereços IP de saída.

  • Na maioria dos casos, é melhor garantir que as redes virtuais da região de destino tenham espaço de endereçamento exclusivo. Um espaço de endereçamento exclusivo facilita a conectividade VNet se for necessário, por exemplo, replicar dados. Portanto, nesses cenários, há um requisito implícito para mudar:

    • DNS Privado
    • Qualquer configuração codificada ou externa que faça referência a recursos por endereço IP (sem um nome de host)
    • ACLs de rede, incluindo grupos de segurança de rede e configuração de firewall (considere o impacto em qualquer NVAs local aqui também)
    • Quaisquer regras de roteamento, tabelas de rotas definidas pelo usuário

    Além disso, certifique-se de verificar a configuração, incluindo intervalos de IP / tags de serviço específicos da região, se estiver levando adiante os recursos de implantação de DevOps existentes.

  • São necessárias menos alterações para o DNS privado implantado pelo cliente configurado para encaminhar para o Azure para domínios do Azure e Zonas Privadas do DNS do Azure. No entanto, como os pontos de extremidade privados são baseados em um FQDN de recurso e esse geralmente também é o nome do recurso (que pode ser esperado que seja diferente na região de destino), lembre-se de cruzar a configuração para garantir que os FQDNs referenciados na configuração sejam atualizados de acordo.

  • Recrie pontos de extremidade privados, se usados, na região de destino. O mesmo se aplica à integração regional de redes virtuais.

  • O DNS para o Ambiente do Serviço de Aplicativo normalmente é gerenciado por meio da solução de DNS personalizada privada dos clientes (há uma substituição manual de configurações disponível em um básico por aplicativo). O Ambiente do Serviço de Aplicativo fornece um balanceador de carga para entrada/saída, enquanto o próprio Serviço de Aplicativo filtra os cabeçalhos do Host. Portanto, vários nomes personalizados podem ser apontados para o mesmo ponto de extremidade de entrada do Ambiente do Serviço de Aplicativo. O Ambiente do Serviço de Aplicativo não requer validação de domínio.

    Nota

    O ponto de extremidade Kudu para o Ambiente do Serviço de Aplicativo v3 só está disponível em {resourcename}.scm.{asename}.appserviceenvironment.net. Para obter mais informações sobre o Ambiente do Serviço de Aplicativo v3, DNS e Redes, etc., consulte Ambiente do Serviço de Aplicativo, rede.

    Para o Ambiente do Serviço de Aplicativo, o cliente é o proprietário do roteamento e, portanto, dos recursos usados para a transferência. Onde quer que o acesso esteja habilitado ao Ambiente do Serviço de Aplicativo externamente - normalmente por meio de um NVA de Camada 7 ou Proxy Reverso - o Gerenciador de Tráfego ou o Azure Front Door/Other L7 Global Load Balancing Service pode ser usado.

  • Para a versão multilocatária pública do serviço, um nome {resourcename}.azurwwebsites.net padrão é provisionado para os pontos de extremidade do plano de dados, juntamente com um nome padrão para o ponto de extremidade Kudu (SCM). Como o serviço fornece um ponto de extremidade público por padrão, a associação deve ser verificada para provar a propriedade do domínio. No entanto, uma vez que a associação esteja em vigor, a reverificação não é necessária, nem é necessário que os registros DNS públicos apontem para o ponto de extremidade do Serviço de Aplicativo.

  • Se você usar um domínio personalizado, vincule-o preventivamente ao aplicativo de destino. Verifique e habilite o domínio no aplicativo de destino.

Identidades

  • Recrie Identidades de Serviço Gerenciado do Serviço de Aplicativo na nova região de destino.

  • Atribua a nova credencial MSI downstream service access (RBAC). Normalmente, um aplicativo Microsoft Entra ID criado automaticamente (usado pelo EasyAuth) assume como padrão o nome do recurso do aplicativo. Pode ser necessário considerar aqui a recriação de um novo recurso na região de destino. Uma entidade de serviço definida pelo usuário seria útil - pois pode ser aplicada tanto à origem quanto ao destino com permissões de acesso extras para recursos de implantação de destino.

  • Planeje a realocação do Provedor de Identidade (IDP) para a região de destino. Embora o Microsoft Entra ID seja um serviço global, algumas soluções dependem de um IDP local (ou downstream no local).

  • Atualize todos os recursos para o Serviço de Aplicativo que possam contar com credenciais de FTP do Kudu.

Pontos finais de serviço

Os pontos de extremidade do serviço de rede virtual para o Serviço de Aplicativo do Azure restringem o acesso a uma rede virtual especificada. Os pontos de extremidade também podem restringir o acesso a uma lista de intervalos de endereços IPv4 (protocolo Internet versão 4). Qualquer usuário que se conecte aos Hubs de Eventos de fora dessas fontes tem acesso negado. Se os pontos de extremidade de serviço fossem configurados na região de origem para o recurso de Hubs de Eventos, o mesmo precisaria ser feito no de destino.

Para uma recriação bem-sucedida do Serviço de Aplicativo do Azure para a região de destino, a VNet e a Sub-rede devem ser criadas previamente. Caso a movimentação desses dois recursos esteja sendo realizada com a ferramenta Azure Resource Mover, os pontos de extremidade de serviço não serão configurados automaticamente. Portanto, eles precisam ser configurados manualmente, o que pode ser feito por meio do portal do Azure, da CLI do Azure ou do Azure PowerShell.

Recolocar

Para realocar recursos do Serviço de Aplicativo, você pode usar o portal do Azure ou a Infraestrutura como Código (IaC).

Realocar usando o portal do Azure

A maior vantagem de usar o portal do Azure para realocar é sua simplicidade. O aplicativo, o plano e o conteúdo, bem como muitas configurações, são clonados no novo recurso e plano do Serviço de Aplicativo.

Lembre-se de que, para as camadas do Ambiente do Serviço de Aplicativo (Isolado), você precisa reimplantar todo o Ambiente do Serviço de Aplicativo em outra região primeiro e, em seguida, pode começar a reimplantar os planos individuais no novo Ambiente do Serviço de Aplicativo na nova região.

Para realocar seus recursos do Serviço de Aplicativo para uma nova região usando o portal do Azure:

  1. Crie um backup do aplicativo de origem.
  2. Crie um aplicativo em um novo plano do Serviço de Aplicativo, na região de destino.
  3. Restaurar o backup no aplicativo de destino
  4. Se você usar um domínio personalizado, associe-o preventivamente ao aplicativo asuid. de destino e habilite o domínio no aplicativo de destino.
  5. Configure tudo o resto em seu aplicativo de destino para ser o mesmo que o aplicativo de origem e verifique sua configuração.
  6. Quando estiver pronto para que o domínio personalizado aponte para o aplicativo de destino, remapeie o nome de domínio.

Realocar usando IaC

Use o IaC quando existir ou puder ser criado um pipeline de Integração Contínua e Entrega/Implantação Contínua (CI/CD) existente. Com um pipeline de CI/CD instalado, seu recurso do Serviço de Aplicativo pode ser criado na região de destino por meio de uma ação de implantação ou uma implantação zip do Kudu.

Os requisitos de SLA devem determinar quanto esforço adicional é necessário. Por exemplo: Trata-se de uma reimplantação com tempo de inatividade limitado ou é necessária uma redução quase em tempo real com tempo de inatividade mínimo ou nulo?

A inclusão de serviços de borda de roteamento de tráfego externo e global, como o Gerenciador de Tráfego ou o Azure Front Door, ajuda a facilitar a transferência para usuários e aplicativos externos.

Gorjeta

É possível usar o Gerenciador de Tráfego (ATM) ao fazer failover dos Serviços de Aplicativo atrás de pontos de extremidade privados. Embora os pontos de extremidade privados não sejam acessíveis pelos testes do Gerenciador de Tráfego - se todos os pontos de extremidade estiverem degradados, o ATM permitirá o roteamento. Para obter mais informações, consulte Controlando o tráfego do Serviço de Aplicativo do Azure com o Gerenciador de Tráfego do Azure.

Validar

Quando a realocação for concluída, teste e valide o Serviço de Aplicativo do Azure com as diretrizes recomendadas:

  • Depois que o Serviço de Aplicativo do Azure for realocado para a região de destino, execute um teste de fumaça e integração. Você pode testar ou executar manualmente um teste por meio de um script. Certifique-se de validar se todas as configurações e recursos dependentes estão vinculados corretamente e se todos os dados configurados estão acessíveis.

  • Valide todos os componentes e integração do Serviço de Aplicativo do Azure.

  • Execute testes de integração na implantação da região de destino, incluindo todos os testes formais de regressão. Os testes de integração devem estar alinhados com os processos usuais de implantação e teste do Rhythm of Business aplicáveis à carga de trabalho.

  • Em alguns cenários, particularmente quando a realocação inclui atualizações, alterações nos aplicativos ou Recursos do Azure ou uma alteração no perfil de uso, use o teste de carga para validar se a nova carga de trabalho é adequada à finalidade. O teste de carga também é uma oportunidade para validar as operações e a cobertura de monitoramento. Por exemplo, use o teste de carga para validar se a infraestrutura necessária e os logs de aplicativos estão sendo gerados corretamente. Os testes de carga devem ser medidos em relação às linhas de base de desempenho da carga de trabalho estabelecidas.

Gorjeta

Uma realocação do Serviço de Aplicativo também é uma oportunidade para reavaliar o planejamento de disponibilidade e recuperação de desastres. O Serviço de Aplicativo e o Ambiente do Serviço de Aplicativo (Ambiente do Serviço de Aplicativo v3) oferecem suporte a zonas de disponibilidade e é recomendável configurar com uma configuração de zona de disponibilidade. Tenha em mente os pré-requisitos para implantação, preços e limitações e considere-os no planejamento de movimentação de recursos. Para obter mais informações sobre zonas de disponibilidade e Serviço de Aplicativo, consulte Confiabilidade no Serviço de Aplicativo do Azure.

Limpeza

Exclua o aplicativo de origem e o plano do Serviço de Aplicativo. Um plano do Serviço de Aplicativo na camada não gratuita cobra uma taxa, mesmo que nenhum aplicativo esteja sendo executado nele.

Próximos passos

Clonagem de aplicativo do Serviço de Aplicativo do Azure usando o PowerShell