Migrar uma instância do Gerenciamento de API injetada em VNet, hospedada na plataforma stv1 para a stv2

APLICA-SE A: Desenvolvedor | Premium

Este artigo apresenta etapas para migrar uma instância do Gerenciamento de API hospedada na plataforma de computação stv1 in-loco para a plataforma stv2 quando a instância é injetada (implantada) em uma VNet externa ou interna. Para esse cenário, migre sua instância atualizando as configurações da VNet. Descubra se você precisa fazer isso.

Caso precise migrar uma instância do Gerenciamento de API não injetada em uma VNnet, hospedada na plataforma stv1, confira Migrar uma instância do Gerenciamento de API não injetada em uma VNet para a plataforma stv2.

Importante

O suporte para instâncias do Gerenciamento de API hospedadas na plataforma stv1 será desativado até 31 de agosto de 2024. Se tiver instâncias hospedadas na plataforma stv1, migre-as para a plataforma stv2 antes dessa data para evitar interrupções do serviço. Saiba mais.

Cuidado

• Migrar sua instância do Gerenciamento de API para a plataforma stv2 é uma operação de execução longa.
• O endereço VIP da instância será alterado. Após a migração, você precisará atualizar as dependências de rede, incluindo DNS, regras de firewall e VNets para usar o novo endereço VIP. Planeje sua migração adequadamente.
• A migração para stv2 não é reversível.

O que acontece durante a migração?

A migração da plataforma de Gerenciamento de API de stv1 para stv2 envolve a atualização da computação subjacente autônoma e não tem nenhum impacto na configuração de serviço/api persistida na camada de armazenamento.

• O processo de atualização envolve a criação de uma computação em paralelo à computação antiga, o que pode demorar 45 minutos.
• O status do Gerenciamento de API no portal do Azure será Atualizando.
• O endereço VIP (ou os endereços, no caso de uma implantação de várias regiões) da instância será alterado.
• O Azure gerencia o DNS do ponto de extremidade de gerenciamento e atualiza para a nova computação imediatamente na migração bem-sucedida.
• O DNS do Gateway ainda apontará para a computação antiga se um domínio personalizado estiver em uso.
• Se o DNS personalizado não estiver em uso, o DNS do gateway e do portal apontará para a nova computação imediatamente.
• Para uma instância no modo VNet interno, o cliente gerencia o DNS, de modo que as entradas DNS continuam apontando para computação antiga até serem atualizadas pelo cliente.
• É o DNS que aponta para a computação nova ou antiga e, portanto, sem tempo de inatividade para as APIs.
• São necessárias alterações às regras de firewall, se houver, para permitir que a nova sub-rede de computação alcance aos back-ends.
• Após a migração bem-sucedida, a computação antiga será automaticamente desativada após cerca de 15 minutos por padrão. Você pode habilitar uma configuração de migração para manter o gateway antigo por 48 horas. A opção de atraso de 48 horas só está disponível nos serviços injetados na VNet.

Pré-requisitos

• Uma instância do Gerenciamento de API hospedada na plataforma de computação stv1. Para confirmar se a sua instância está hospedada na plataforma stv1, confira Como saber qual plataforma hospeda minha instância do Gerenciamento de API? A instância precisa ser injetada em uma rede virtual.

• Uma nova sub-rede na rede virtual atual, em cada região em que a instância do Gerenciamento de API é implantada. (Como alternativa, configure uma sub-rede em uma rede virtual diferente nas mesmas regiões e assinatura da instância do Gerenciamento de API). Um grupo de segurança de rede deve ser anexado à sub-rede e as regras de NSG para Gerenciamento de API devem ser configuradas.

• (Opcional) Um novo recurso de endereço IPv4 público do SKU Standard nas mesmas regiões e assinatura da instância de Gerenciamento de API. Para obter detalhes, veja Pré-requisitos para conexões de rede.

  Importante

  • A partir de maio de 2024, um endereço IP público não é mais necessário ao implantar (injetar) uma instância de Gerenciamento de API em uma VNet no modo interno ou migrar a configuração de VNet interna para uma nova sub-rede. No modo de VNet externa, especificar um endereço IP público é opcional; se você não fornecer um, um endereço IP público gerenciado pelo Azure será configurado automaticamente. No modo VNet externo, o endereço IP público é usado para tráfego de API de runtime.
  • Atualmente, se você habilitar a redundância de zona para uma instância de Gerenciamento de API em uma VNet no modo interno ou externo, você deverá especificar um novo endereço IP público.

Disparar a migração de uma instância do Gerenciamento de API injetada em rede

Dispare a migração de uma instância do Gerenciamento de API injetada em rede para a plataforma stv2, atualizando a configuração de rede existente para usar as novas configurações de rede em cada região em que a instância é implantada. Depois que essa atualização for concluída, como etapa opcional, você poderá migrar de volta às VNets e às sub-redes originais usadas.

Você também pode migrar para a plataforma stv2 habilitando a redundância de zona, disponível na camada Premium.

Importante

Os endereços VIP da instância do Gerenciamento de API serão alterados. No entanto, as solicitações de API permanecem responsivas durante a migração. A configuração de infraestrutura (como domínios personalizados, locais e certificados de AC) será bloqueada por 30 minutos. Após a migração, você precisará atualizar as dependências de rede, incluindo DNS, regras de firewall e VNets emparelhadas para usar os novos endereços VIP.

Atualizar a configuração de rede

Use o portal do Azure para migrar para uma nova sub-rede na mesma ou em outra VNet. A imagem a seguir mostra uma visão geral de alto nível do que acontece durante a migração para uma nova sub-rede.

Portal

1. No portal do Azure, navegue até a instância do Gerenciamento de API.

2. No menu à esquerda, em Configurações, selecione Migração de plataforma.

3. Na página Migração da Plataforma, na Etapa 1, examine os requisitos e os pré-requisitos de migração.

4. Na Etapa 2, escolha as configurações de migração:

   • Selecione um local para migrar.

   • Selecione a Rede virtual, a Sub-rede e o Endereço IP público opcional para o qual você deseja migrar.

     

   • Selecione Retornar à sub-rede original assim que possível ou Permanecer na nova sub-rede e manter a computação stv1 por 48 horas após a migração. Se você escolher a primeira opção, a computação stv1 será excluída aproximadamente 15 minutos após a migração, permitindo que você prossiga diretamente com a migração de volta para a sub-rede original, se desejado. Se você escolher a última opção, a computação stv1 será mantida por 48 horas. Você pode usar esse período para validar as configurações de rede e a conectividade.

     

5. Na Etapa 3, confirme se deseja migrar e selecione Migrar. O status da instância do Gerenciamento de API será alterado para Atualizando. O processo de migração demora cerca de 45 minutos para ser concluído. Quando o status for alterado para Online, a migração estará concluída.

Se a instância de Gerenciamento de API for implantada em várias regiões, repita as etapas anteriores para continuar migrando as configurações de VNet para os locais restantes da instância.

(Opcional) Migrar de volta para a sub-rede original

Opcionalmente, você pode migrar de volta para a sub-rede original usada em cada região antes da migração para a plataforma stv2. Para fazer isso, atualize a configuração da VNet novamente, desta vez, especificando a VNet e a sub-rede originais em cada região. Como na migração anterior, espere uma operação de execução demorada e espere que o endereço VIP seja alterado.

A imagem a seguir mostra uma visão geral de alto nível do que acontece durante a migração de volta para a sub-rede original.

Importante

Se a VNet e a sub-rede estiverem bloqueadas (porque outras instâncias do Gerenciamento de API baseadas na plataforma stv1 estão implantadas nelas) ou o grupo de recursos em que a VNet original está implantada tem um bloqueio de recurso, remova o bloqueio antes de migrar de volta para a sub-rede original. Aguarde a conclusão da remoção do bloqueio antes de tentar fazer a migração para a sub-rede original. Saiba mais.

Pré-requisitos adicionais

• A sub-rede original desbloqueada, em cada região na qual a instância do Gerenciamento de API está implantada. Um grupo de segurança de rede deve ser anexado à sub-rede e as regras de NSG para Gerenciamento de API devem ser configuradas.

• (Opcional) Um novo recurso de endereço IPv4 público do SKU Standard nas mesmas regiões e assinatura da instância de Gerenciamento de API.

  Importante

  • A partir de maio de 2024, um endereço IP público não é mais necessário ao implantar (injetar) uma instância de Gerenciamento de API em uma VNet no modo interno ou migrar a configuração de VNet interna para uma nova sub-rede. No modo de VNet externa, especificar um endereço IP público é opcional; se você não fornecer um, um endereço IP público gerenciado pelo Azure será configurado automaticamente. No modo VNet externo, o endereço IP público é usado para tráfego de API de runtime.
  • Atualmente, se você habilitar a redundância de zona para uma instância de Gerenciamento de API em uma VNet no modo interno ou externo, você deverá especificar um novo endereço IP público.

Atualizar configuração de VNET

1. No portal, navegue até sua VNet original.
2. No menu à esquerda, selecione Sub-redes e, em seguida, a sub-rede original.
3. Verifique se os endereços IP originais foram liberados pelo Gerenciamento de API. Em IPs disponíveis, observe o número de endereços IP disponíveis na sub-rede. Todos os endereços (exceto para endereços reservados do Azure) devem estar disponíveis. Se necessário, aguarde até que os endereços IP sejam liberados.
4. Navegue até sua instância de Gerenciamento de API.
5. No menu à esquerda, em Rede, selecione Rede virtual.
6. Selecione a conexão de rede no local que deseja atualizar.
7. Selecione a rede VNet original e a sub-rede. Opcionalmente, selecione um novo IP público. Escolha Aplicar.
8. Se a instância de Gerenciamento de API for implantada em várias regiões, continue definindo as configurações de VNet para os locais restantes da instância.
9. Na barra de navegação superior, selecione Salvar.

Depois que você atualizar a configuração da VNet, o status da instância do Gerenciamento de API será alterado para Atualizando. O processo de migração demora cerca de 45 minutos para ser concluído. Quando o status for alterado para Online, a migração estará concluída.

Verificar migração

Para confirmar se a migração foi bem-sucedida, quando o status for alterado para Online verifique a versão da plataforma da sua instância de Gerenciamento de API. Após a migração bem-sucedida, o valor será stv2 ou stv2.1.

Confirmar as configurações antes que o gateway antigo seja limpo

Após a migração bem-sucedida de uma instância do Gerenciamento de API injetada em VNet, a computação antiga e a nova criadas durante a migração coexistem por um curto período, de cerca de 15 minutos, que é uma pequena janela de tempo que você pode usar para validar a implantação e se os seus aplicativos funcionam conforme o esperado. (Essa janela poderá ser estendida para 48 horas se você entrar em contato com o Suporte do Azure com antecedência.)

• Durante essa janela, os gateways antigos e novos ficam online atendendo ao tráfego. Você não é cobrado durante esse tempo.
• Use essa janela para atualizar qualquer dependência de rede, incluindo DNS, regras de firewall e VNets, para usar o novo endereço VIP e espaço de endereço de sub-rede.
• Além disso, verifique o status da rede da instância atualizada para garantir a conectividade da instância com as respectivas dependências. No portal, no menu à esquerda, em Implantação e infraestrutura, selecione Rede>Status de rede. Se necessário, atualize as configurações, como UDRs e regras NSG.
• Após a janela, o gateway antigo é desativado e o novo gateway é o único que atende ao tráfego.

Reverter automaticamente se a migração falhar

Se ocorrer uma falha durante o processo de migração, a instância será revertida automaticamente para a plataforma stv1. Se a migração for concluída com sucesso (a versão da plataforma da instância aparece como stv2 ou stv2.1 e o status como Online), você não poderá revertê-la para a plataforma stv1.

Para obter ajuda em caso de falha na migração, entre em contato com o Suporte do Azure.

Caso precise da capacidade de revertê-la manualmente, a recomendação é implantar uma nova instância de stv2lado a lado com a sua instância original do Gerenciamento de API.

Ajuda e suporte

Estamos aqui para ajudar você a migrar para a plataforma stv2 com um mínimo de interrupções nos seus serviços.

Em caso de dúvidas, obtenha respostas rápidas dos especialistas da comunidade no Microsoft Q&A. Se tiver um plano de suporte e precisar de ajuda técnica, crie uma solicitação de suporte.

1. Em Resumo, digite uma descrição do problema, por exemplo, "desativação do stv1".
2. Em Tipo de problema, selecione Técnico.
3. Em Assinatura, selecione sua assinatura.
4. Em Serviço, selecione Meus serviços e, em seguida, Serviço de Gerenciamento de API.
5. Em Recurso, selecione o recurso do Azure para o qual você está criando uma solicitação de suporte.
6. Em Tipo de problema, selecione Administração e Gerenciamento.
7. Em Subtipo de problema, selecione Atualização, Escala ou Alterações de SKU.

Perguntas frequentes

• Quais informações precisamos escolher um caminho de migração?

  • Qual é o modo de rede da instância de Gerenciamento de API?
  • Os domínios personalizados estão configurados?
  • Um firewall está envolvido?
  • Alguma dependência conhecida tomada por upstream/downstream nos IPs envolvidos?
  • É uma implantação em várias regiões?
  • Podemos modificar a instância existente ou uma configuração paralela é necessária?
  • Pode haver tempo de inatividade?
  • A migração pode ser feita em horas que não são de negócios?

• Quais são os pré-requisitos para a migração?

  Para instâncias injetadas em VNet, você precisará de uma nova sub-rede para migrar em cada VNet (modo externo ou interno). No modo externo, opcionalmente, forneça um recurso de endereço IP público. A sub-rede deve ter um NSG anexado a ele seguindo as regras da plataforma stv2, conforme descrito aqui.

• A migração causará um tempo de inatividade?

  Como o gateway antigo será limpo somente depois que a nova computação estiver íntegra e online, não deverá haver nenhum tempo de inatividade se os nomes do host padrão estiverem em uso. É fundamental que todas as dependências de rede sejam cuidadas antecipadamente para que as APIs afetadas sejam funcionais. No entanto, se os domínios personalizados estiverem em uso, eles apontarão para a computação limpa até que sejam atualizados, o que pode causar um tempo de inatividade. Como alternativa, você pode habilitar uma configuração de migração para manter o gateway antigo por 48 horas. A coexistência da computação antiga e da nova facilitará a validação e você ainda poderá atualizar as entradas DNS personalizadas à vontade.

• Meu tráfego é forçado por um túnel através de um firewall. Quais alterações são necessárias?

  • Primeiro, verifique se as novas sub-redes que você criou para a migração mantêm a seguinte configuração (elas já devem estar configuradas na sub-rede atual):
    • Habilite pontos de extremidade de serviço, conforme descrito aqui
    • A UDR (rota definida pelo usuário) tem o salto da marca de serviço ApiManagement definida como "Internet" e não apenas para seu endereço de firewall
  • Os requisitos para a configuração do NSG para stv2 permanecem os mesmos se você tiver firewall ou não; verifique se sua nova sub-rede o tem
  • As regras de firewall referentes ao intervalo de endereços IP atual da instância de Gerenciamento de API devem ser atualizadas para usar o intervalo de endereços IP da nova sub-rede.

• Podem ocorrer perdas de dados ou de configuração pela migração ou durante ela?

  A migração de stv1 para stv2 envolve a atualização da plataforma de computação sozinha e a camada de armazenamento interna não é alterada. Portanto, toda a configuração é segura durante o processo de migração. Isso inclui a identidade gerenciada atribuída pelo sistema que, se habilitada, será preservada.

• Como confirmar se a migração foi concluída e bem-sucedida?

  A migração será considerada completa e bem-sucedida quando o status na página de Visão geral indicar Online, com a versão da plataforma sendo stv2 ou stv2.1. Verifique também se o status da rede na folha de Rede mostra verde para toda a conectividade necessária.

• Posso fazer a migração usando o portal?

  Sim, as instâncias injetadas em VNet podem ser migradas com a alteração das configurações da sub-rede na folha Migração da plataforma.

• Posso preservar o endereço IP da instância?

  Atualmente, não há nenhuma maneira de preservar o endereço IP se a sua instância é injetada em uma VNet.

• Há um caminho de migração sem modificar a instância existente?

  Sim, você precisa de uma migração lado a lado. Isso significa que você cria uma nova instância de Gerenciamento de API em paralelo com sua instância atual e copia a configuração para a nova instância.

• O que acontece se a migração falhar?

  Se a sua instância de Gerenciamento de API não mostrar a versão da plataforma como stv2 ou stv2.1 e o status como Online após você iniciar a migração, provavelmente ocorreu uma falha. Seu serviço é revertido automaticamente para a instância antiga e nenhuma alteração é feita.

• Qual funcionalidade não está disponível durante a migração?

  As solicitações de API permanecem dinâmicas durante a migração. A configuração de infraestrutura (como domínios personalizados, locais e certificados de AC) é bloqueada por 30 minutos. Após a migração, você precisará atualizar as dependências de rede, incluindo DNS, regras de firewall e VNets para usar o novo endereço VIP.

• Quanto tempo a migração levará?

  A duração esperada de uma migração para uma nova configuração de VNet é de aproximadamente 45 minutos. O indicador usado para verificar se a migração já foi feita é ver se o status da instância voltou para Online e não Atualizando.

• Há uma maneira de validar a configuração da VNet antes de tentar a migração?

  Você pode implantar uma nova instância de Gerenciamento de API com a nova VNet, sub-rede e (opcional) recurso de endereço IP que você usa para a migração real. Navegue até a página de status de rede após a conclusão da implantação e verifique se cada status de conectividade de ponto de extremidade está verde. Nesse caso, você pode remover essa nova instância do Gerenciamento de API e continuar com a migração real com seu serviço original hospedado pela stv1.

• Posso reverter a migração, se necessário?

  Se houver uma falha durante o processo de migração, a instância será revertida automaticamente para a plataforma stv1. No entanto, depois que o serviço for migrado com êxito, você não poderá revertê-lo para a plataforma stv1.

  Depois que um serviço injetado em VNet for migrado com êxito, haverá uma breve janela de tempo durante o qual o gateway antigo continuará atendendo ao tráfego e você poderá confirmar as configurações de rede. Confira Confirmar as configurações antes que o gateway antigo seja limpo

• Há alguma alteração necessária em zonas DNS privadas/domínio personalizado?

  Com as instâncias injetadas em VNet no modo interno, você precisará atualizar as zonas DNS privadas para o novo endereço IP da VNet adquirido após a migração. Lembre-se de atualizar as zonas DNS não Azure também (por exemplo, servidores DNS locais que apontam para o endereço IP privado do Gerenciamento de API). No entanto, no modo externo, o processo de migração atualizará automaticamente os domínios padrão se estiver em uso.

• Minha instância stv1 está implantada em várias regiões do Azure. Como fazer para atualizar para o stv2?

  As implantações de várias regiões incluem mais gateways gerenciados implantados em outras localizações. Migre cada local separadamente atualizando as configurações de rede correspondentes, por exemplo, usando a folha Migração da plataforma. A instância é considerada migrada para a nova plataforma somente quando todos os locais são migrados. Todos os gateways regionais continuam operando normalmente durante todo o processo de migração.

• Posso atualizar minha instância stv1 para a mesma sub-rede?

  • Não é possível migrar a instância stv1 para a mesma sub-rede em uma só passagem sem nenhum tempo de inatividade. No entanto, opcionalmente, você pode mover sua instância migrada de volta para a sub-rede original. Mais detalhes aqui.
  • O gateway antigo leva de 15 a 45 minutos para desocupar a sub-rede, para que você possa iniciar a mudança. No entanto, você pode habilitar uma configuração de migração para manter o gateway antigo por 48 horas.
  • Verifique se a rede de sub-rede antiga do NSG e do firewall está atualizada para dependências stv2.
  • A alocação de endereço IP da sub-rede não é determinística, portanto, o IP ILB (entrada) original para implantações de “modo interno” poderá mudar quando você voltar para a sub-rede original. Isso exigirá uma alteração de DNS se você estiver usando registros A.

• Posso testar o novo gateway antes de alternar o tráfego ao vivo?

  • Por padrão, os gateways gerenciados antigos e novos coexistem por 15 minutos, o que é uma pequena janela de tempo para validar a implantação. Você pode habilitar uma configuração de migração para manter o gateway antigo por 48 horas. Essa alteração mantém os gateways gerenciados antigos e novos ativos para receber tráfego e facilitar a validação.
  • O processo de migração atualiza automaticamente os nomes de domínio padrão e, se estiver sendo usado, o tráfego roteia para os novos gateways imediatamente.
  • Se os nomes de domínio personalizados estiverem em uso, os registros DNS correspondentes poderão precisar ser atualizados com o novo endereço IP se não estiverem usando CNAME. Os clientes podem atualizar o arquivo de hosts para o novo IP do Gerenciamento de API e validar a instância antes de fazer a alternância. Durante esse processo de validação, o gateway antigo continua a atender ao tráfego dinâmico.

• Há considerações ao usar o nome de domínio padrão?

  As instâncias que estão usando o nome DNS padrão no modo externo têm o DNS atualizado automaticamente pelo processo de migração. Além disso, o ponto de extremidade de gerenciamento, que sempre usa o nome de domínio padrão, é atualizado automaticamente pelo processo de migração. Como a alternância ocorre imediatamente em uma migração bem-sucedida, a nova instância começa a receber o tráfego imediatamente. Portanto, é fundamental lidar com qualquer restrição/dependência antecipadamente para evitar que as APIs afetadas fiquem indisponíveis.

• O que devemos considerar para os gateways auto-hospedados?

  Você não precisa fazer nada em seus gateways auto-hospedados. Você só precisa migrar instâncias de Gerenciamento de API em execução no Azure que são afetadas pela desativação da plataforma stv1. Observe que pode haver um novo IP para o ponto de extremidade de configuração da instância de Gerenciamento de API e todas as restrições de rede fixadas ao IP devem ser atualizadas.

• Como o portal do desenvolvedor é afetado pela migração?

  Não há nenhum impacto no portal do desenvolvedor. Se domínios personalizados forem usados, o registro DNS deverá ser atualizado com o IP efetivo, após a migração. No entanto, se os domínios padrão estiverem em uso, eles serão atualizados automaticamente na migração bem-sucedida. Não há tempo de inatividade para o portal do desenvolvedor durante a migração.

• Há algum impacto no custo depois de migrarmos para o stv2?

  O modelo de cobrança permanece o mesmo para stv2 e não haverá nenhum custo extra gerado durante e após a migração.

• Quais permissões RBAC são necessárias para a migração da stv1 para a stv2?

  O usuário/o processo que realiza a migração precisa ter acesso de gravação na instância do Gerenciamento de API. Além disso, as seguintes duas permissões são necessárias:

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/publicIPAddresses/join/action

Vídeo

Conteúdo relacionado

• Como saber qual plataforma hospeda minha instância de Gerenciamento de API?

• Benefícios da plataforma de computação stv2 para o Gerenciamento de API

• Saiba mais sobre a desativação da plataforma stv1 em agosto de 2024