Partilhar via

Migrar uma instância de gerenciamento de API injetada por rede virtual hospedada na plataforma stv1 para stv2

  • Artigo

APLICA-SE A: Developer | Prémio

Este artigo fornece etapas para migrar uma instância de Gerenciamento de API hospedada stv1 na plataforma de computação in-loco para a stv2 plataforma quando a instância é injetada (implantada) em uma VNet externa ou interna . Descubra se você precisa fazer isso.

Nota

Novidade em agosto de 2024: para ajudá-lo a migrar sua instância injetada de rede virtual, melhoramos as opções de migração no portal! Agora você pode migrar sua instância in-loco e manter a mesma sub-rede e endereço IP.

Para uma instância de injeção de rede virtual, você tem as seguintes opções de migração:

  • Opção 1: Manter a mesma sub-rede - Migrar a instância in-loco e manter a configuração de sub-rede existente das instâncias. Você pode escolher se o endereço VIP original da instância de Gerenciamento de API será preservado (recomendado) ou se um novo endereço VIP será gerado.

  • Opção 2: Alterar para uma nova sub-rede - Migre sua instância especificando uma sub-rede diferente na mesma VNet ou em uma VNet diferente. Após a migração, opcionalmente, migre de volta para a sub-rede original da instância. O processo de migração altera o(s) endereço(s) VIP(s) da instância. Após a migração, você precisa atualizar todas as dependências de rede, incluindo DNS, regras de firewall e redes virtuais para usar o(s) novo(s) endereço(s) VIP.

Em determinadas condições menos frequentes, a migração na mesma sub-rede pode não ser possível ou comportar-se de forma diferente. Para obter mais informações, consulte Condições especiais e cenários.

Se você precisar migrar um Gerenciamento de API não injetado stv1 por VNnet hospedado na plataforma, consulte Migrar uma instância de Gerenciamento de API não injetada por VNet para a plataforma stv2.

Importante

O suporte para instâncias de gerenciamento de API hospedadas na stv1 plataforma está sendo desativado. No Azure global, a data de aposentadoria é 31 de agosto de 2024. No Azure Government e no Azure operado pela 21Vianet (Azure na China), a data de desativação é 24 de fevereiro de 2025. Se você tiver instâncias hospedadas na stv1 plataforma, migre-as para a plataforma antes da stv2 data de desativação para evitar interrupções no serviço.

Atenção

  • Migrar sua instância de Gerenciamento de API para a stv2 plataforma é uma operação de longa duração.
  • 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 apenas da computação subjacente e não tem impacto na configuração de serviço/API persistida na camada de armazenamento.

  • O processo de atualização envolve a criação de uma nova computação em paralelo com a computação antiga, o que pode levar até 45 minutos. Planeje tempos mais longos para implantações em várias regiões e em cenários que envolvam a alteração da sub-rede mais de uma vez.
  • O status de Gerenciamento de API no portal do Azure será Atualizando.
  • Para determinadas opções de migração, você pode optar por preservar o endereço VIP ou um novo VIP público será gerado.
  • Para cenários de migração quando um novo endereço VIP é gerado:
    • O Azure gerencia a migração.
    • O DNS do gateway ainda aponta 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 a apontar 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 nas regras de firewall, se houver, para permitir que a nova sub-rede de computação alcance os back-ends.
    • Após a migração bem-sucedida, a computação antiga é automaticamente desativada após um curto período. Ao mudar para uma nova sub-rede usando a folha Migração de plataforma no portal, 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 para serviços com injeção de rede virtual.

Pré-requisitos

Outros pré-requisitos são específicos para as opções de migração nas seções a seguir.

Opção 1: Migrar e manter a mesma sub-rede

Você pode migrar sua instância de Gerenciamento de API para a stv2 plataforma mantendo a configuração de sub-rede existente, o que simplifica sua migração. Você pode migrar usando a folha de migração de plataforma no portal do Azure ou a API REST Migrar para Stv2.

Pré-requisitos

  • Um grupo de segurança de rede deve ser anexado stv2 a cada sub-rede e as regras NSG para Gerenciamento de API na plataforma devem ser configuradas. A seguir estão as configurações mínimas de conectividade:

    • Saída para o Armazenamento do Azure pela porta 443
    • Saída para o SQL do Azure pela porta 1433
    • Saída para o Azure Key Vault pela porta 443
    • Entrada do Azure Load Balancer pela porta 6390
    • Entrada da tag de serviço ApiManagement pela porta 3443
    • Entrada pela porta 80/443 para clientes que chamam o serviço de Gerenciamento de API
    • A sub-rede deve ter pontos de extremidade de serviço habilitados para o Armazenamento do Azure, o SQL do Azure e o Cofre da Chave do Azure

  • O espaço de endereço de cada sub-rede existente deve ser grande o suficiente para hospedar uma cópia do serviço existente lado a lado com o serviço existente durante a migração.

  • Outras considerações sobre a rede:

    • Desative todas as regras de dimensionamento automático configuradas para instâncias de Gerenciamento de API implantadas na sub-rede. As regras de dimensionamento automático podem interferir no processo de migração.
    • Se você tiver várias instâncias de Gerenciamento de API na mesma sub-rede, migre cada instância em sequência. Recomendamos que você migre imediatamente todas as instâncias na sub-rede para evitar possíveis problemas com instâncias hospedadas em plataformas diferentes na mesma sub-rede.

  • Use o ambiente Bash no Azure Cloud Shell. Para obter mais informações, consulte Guia de início rápido para Bash no Azure Cloud Shell.

  • Se preferir executar comandos de referência da CLI localmente, instale a CLI do Azure. Se estiver a utilizar o Windows ou macOS, considere executar a CLI do Azure num contentor Docker. Para obter mais informações, consulte Como executar a CLI do Azure em um contêiner do Docker.

    • Se estiver a utilizar uma instalação local, inicie sessão no CLI do Azure ao utilizar o comando az login. Para concluir o processo de autenticação, siga os passos apresentados no seu terminal. Para outras opções de entrada, consulte Entrar com a CLI do Azure.

    • Quando solicitado, instale a extensão da CLI do Azure na primeira utilização. Para obter mais informações sobre as extensões, veja Utilizar extensões com o CLI do Azure.

    • Execute o comando az version para localizar a versão e as bibliotecas dependentes instaladas. Para atualizar para a versão mais recente, execute o comando az upgrade.

Opções de endereço IP público - migração da mesma sub-rede

Você pode escolher se o endereço VIP original da instância de Gerenciamento de API será preservado (recomendado) ou se um novo endereço VIP será gerado.

  • Preservar o endereço IP virtual - Se você preservar o endereço VIP em uma VNet no modo externo, as solicitações de API podem permanecer responsivas durante a migração (consulte Tempo de inatividade esperado); para uma VNet no modo interno, o tempo de inatividade temporário é esperado. A configuração da infraestrutura (como domínios personalizados, locais e certificados de CA) será bloqueada por 45 minutos. Nenhuma configuração adicional é necessária após a migração.

    Com essa opção, a stv1 computação é excluída permanentemente após a conclusão da migração. Não há opção de mantê-lo temporariamente.

    A imagem a seguir mostra uma visão geral de alto nível do que acontece quando o endereço IP é preservado.

    Diagrama de migração in-loco para a mesma sub-rede e preservando o endereço IP.

  • Novo endereço IP virtual - Se você escolher essa opção, o Gerenciamento de API gerará um novo endereço VIP para sua instância. As solicitações de API permanecem responsivas durante a migração. A configuração da infraestrutura (como domínios personalizados, locais e certificados de CA) será bloqueada por 30 minutos. Após a migração, você precisará atualizar todas as dependências de rede, incluindo DNS, regras de firewall e redes virtuais para usar o novo endereço VIP.

    Com essa opção, a computação é mantida por um curto período por padrão após a stv1 conclusão da migração, para que você possa validar a instância migrada e confirmar a configuração de rede e DNS.

    A imagem a seguir mostra uma visão geral de alto nível do que acontece quando um novo endereço IP é gerado.

    Diagrama de migração in-loco para a mesma sub-rede e geração de novo endereço IP.

Endereço IP pré-criado para migração

Para instâncias de Gerenciamento de API acessíveis por um endereço IP público, o Gerenciamento de API pré-cria um endereço IP público para o processo de migração. Encontre o endereço IP pré-criado na saída JSON das propriedades da sua instância de Gerenciamento de API. Em customProperties, o endereço IP pré-criado é o valor da Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps propriedade. Para uma implantação em várias regiões, o valor é uma lista separada por vírgulas de endereços IP pré-criados.

Use o endereço IP (ou endereços) precriados para ajudá-lo a gerenciar o processo de migração:

  • Quando você migra e preserva o endereço VIP, o endereço IP pré-criado é atribuído temporariamente à nova stv2 implantação, antes que o endereço IP original seja atribuído à stv2 implantação. Se você tiver regras de firewall limitando o acesso à instância de Gerenciamento de API, por exemplo, poderá adicionar o endereço IP pré-criado à lista de permissões para preservar a continuidade do acesso do cliente durante a migração. Após a conclusão da migração, você pode remover o endereço IP pré-criado da sua lista de permissões.
  • Quando você migra e gera um novo endereço VIP, o endereço IP pré-criado é atribuído à nova stv2 implantação durante a migração e persiste após a conclusão da migração. Use o endereço IP pré-criado para atualizar suas dependências de rede, como DNS e regras de firewall, para apontar para o novo endereço IP.

Tempo de inatividade esperado e retenção de computação

Ao migrar uma instância injetada por rede virtual e manter a mesma configuração de sub-rede, espera-se um tempo de inatividade mínimo ou nenhum para o gateway de API. A tabela a seguir resume o tempo de inatividade esperado e stv1 a retenção de computação para cada cenário de migração ao manter a mesma sub-rede:

Modo VNet Opção IP público Tempo de inatividade esperado stv1 retenção de computação
Externa Preservar VIP Sem tempo de inatividade; o tráfego é servido em um endereço IP temporário por até 20 minutos durante a migração para a nova stv2 implantação Sem retenção
Externa Novo VIP Sem tempo de inatividade Retido por padrão por 15 minutos para permitir que você atualize as dependências de rede
Interna Preservar VIP Tempo de inatividade por aproximadamente 20 minutos durante a migração enquanto o endereço IP existente é atribuído à nova stv2 implantação. Sem retenção
Interna Novo VIP Sem tempo de inatividade Retido por padrão por 15 minutos para permitir que você atualize as dependências da rede; pode ser estendido para 48 horas ao usar o portal

Etapas de migração - mantenha a mesma sub-rede

  1. No portal do Azure, navegue até sua instância de Gerenciamento de API.
  2. No menu à esquerda, em Configurações, selecione Migração de plataforma.
  3. Em Selecione uma opção de migração, selecione Manter a mesma sub-rede.
  4. Em Escolha uma opção de endereço IP, selecione uma das duas opções de endereço IP.

    Nota

    Se a sua rede virtual estiver no modo externo, tome nota do endereço IP público pré-criado para o processo de migração. Use esse endereço para configurar a conectividade de rede para sua instância migrada.

  5. (Para instâncias injetadas no modo interno e migrando para um novo VIP) Em Escolha o cenário que se alinha aos seus requisitos, escolha uma das duas opções, dependendo se você deseja manter a computação original stv1 por um período após a migração.
  6. Selecione Verificar para executar verificações automatizadas na sub-rede. Se forem detetados problemas, ajuste a configuração da sub-rede e execute verificações novamente. Para outras dependências de rede, como DNS e regras de firewall, verifique manualmente.
  7. Confirme que deseja migrar e selecione Iniciar migração. O status da sua instância de Gerenciamento de API muda para Atualização. O processo de migração leva aproximadamente 45 minutos para ser concluído. Quando o status muda para Online, a migração é concluída.

Opção 2: Migrar e alterar para nova sub-rede

Usando o portal do Azure, você pode migrar sua instância especificando uma sub-rede diferente na mesma VNet ou em uma VNet diferente. Após a migração, opcionalmente, migre de volta para a sub-rede original da instância.

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.

Diagrama de migração in-loco para uma nova sub-rede.

Pré-requisitos

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

  • (Opcional) Um novo recurso de endereço IPv4 público de SKU padrão na(s) mesma(s) região(ões) e assinatura que sua instância de Gerenciamento de API. Para obter detalhes, consulte Pré-requisitos para conexões de rede.

Importante

  • A partir de maio de 2024, um recurso de endereço IP público não será mais necessário ao implantar (injetar) uma instância de Gerenciamento de API em uma VNet no modo interno ou ao migrar a configuração de VNet interna para uma nova sub-rede. No modo VNet externo, 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 e usado para o tráfego da API de tempo de execução. Forneça o endereço IP público apenas se quiser possuir e controlar o endereço IP público usado para comunicação de entrada ou saída para a Internet.

Etapas de migração - alterar para uma nova sub-rede

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

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

  3. Em Selecione uma opção de migração, selecione Alterar para uma nova sub-rede.

  4. Em Escolha o cenário que se alinha aos seus requisitos, escolha uma das duas opções, dependendo se você deseja manter a computação original stv1 por um período após a migração.

    Captura de tela das opções para reter a computação stv1 no portal.

  5. Em Definir configurações de migração para cada local:

    1. Selecione um local para migrar.
    2. Selecione a rede virtual, a sub-rede e o endereço IP público opcional para o qual deseja migrar.

    Captura de tela mostrando a seleção de configurações de migração de rede no portal.

  6. Em Verificar se a sub-rede atende aos requisitos de migração, selecione Verificar para executar verificações automatizadas na sub-rede. Se forem detetados problemas, ajuste a configuração da sub-rede e execute verificações novamente. Para outras dependências de rede, como DNS e regras de firewall, verifique manualmente.

  7. Confirme que deseja migrar e selecione Migrar. O status da sua instância de Gerenciamento de API muda para Atualização. O processo de migração leva aproximadamente 45 minutos para ser concluído. Quando o status muda para Online, a migração é concluída.

Se sua 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

Se você migrou e alterou para uma nova sub-rede, opcionalmente, migre de volta para a sub-rede original usada em cada região. 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 longa duração e espere que o endereço VIP mude.

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.

Diagrama de migração in-loco de volta à sub-rede original.

Importante

Se a VNet e a sub-rede estiverem bloqueadas (porque outras stv1 instâncias de Gerenciamento de API baseadas em plataforma são implantadas lá) ou se o grupo de recursos onde a VNet original é implantada tiver um bloqueio de recurso, certifique-se de remover o bloqueio antes de migrar de volta para a sub-rede original. Aguarde a conclusão da remoção do bloqueio antes de tentar a migração para a sub-rede original. Mais informações.

Pré-requisitos adicionais

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

  • (Opcional) Um novo recurso de endereço IPv4 público de SKU padrão na(s) mesma(s) região(ões) e assinatura que sua instância de Gerenciamento de API.

    Importante

    • A partir de maio de 2024, um recurso de endereço IP público não será mais necessário ao implantar (injetar) uma instância de Gerenciamento de API em uma VNet no modo interno ou ao migrar a configuração de VNet interna para uma nova sub-rede. No modo VNet externo, 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 e usado para o tráfego da API de tempo de execução. Forneça o endereço IP público apenas se quiser possuir e controlar o endereço IP público usado para comunicação de entrada ou saída para a Internet.

Atualizar configuração de VNet

  1. No portal, navegue até a 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 os 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. Selecione Aplicar.
  8. Se sua 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 Guardar.

Depois de atualizar a configuração da rede virtual, o status da instância de Gerenciamento de API muda para Atualização. O processo de migração leva aproximadamente 45 minutos para ser concluído. Quando o status muda para Online, a migração é concluída.

Verificar a migração

Para verificar 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 é stv2 ou stv2.1.

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

Para cenários em que o gateway antigo é temporariamente retido após a migração, a computação antiga e a nova criada durante a migração coexistem por um curto período de tempo, aproximadamente 15 minutos, que você pode usar para validar a implantação e que seus aplicativos funcionem conforme o esperado. Para determinados cenários, você pode, opcionalmente, estender o período de retenção para 48 horas por meio de uma configuração de portal.

  • Durante essa janela, os gateways antigos e novos estão on-line e servindo tráfego. Você não será cobrado durante esse período.
  • Use esta janela para atualizar quaisquer dependências de rede, incluindo DNS, regras de firewall e redes virtuais para usar o novo endereço VIP e espaço de endereço de sub-rede.
  • Além disso, verifique o status de rede da instância atualizada para garantir a conectividade da instância com suas dependências. No portal, no menu à esquerda, em Implantação e infraestrutura, selecione >Status da rede 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 serve o tráfego.

Reverter automaticamente se a migração falhar

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

Para obter ajuda se a migração falhar, contacte o suporte do Azure.

Se você precisar da capacidade de reverter manualmente, a recomendação é implantar uma nova stv2 instância lado a lado com sua instância original de Gerenciamento de API.

Condições especiais e cenários

Sob certas condições, a Opção 1: Migrar e manter a mesma sub-rede pode não estar disponível ou comportar-se de forma diferente. O portal deteta essas condições e recomenda a(s) opção(ões) de migração. Se você não conseguir usar a Opção 1 ou se houver várias condições, use a Opção 2: Alterar para uma nova sub-rede.

  • VNet com condições internas especiais - Se sua instância de Gerenciamento de API estiver atualmente implantada em uma VNet com condições internas especiais (não relacionadas à configuração do cliente), você será notificado no portal de que a Opção 1 para migração da mesma sub-rede no portal inclui tempo de inatividade adicional (aproximadamente 1 hora). Recomenda-se o uso do portal para migração. Você também pode usar o seguinte script modificado da CLI do Azure para migração da mesma sub-rede com aproximadamente 1 hora de tempo de inatividade:

    APIM_NAME={name of your API Management instance}
# In PowerShell, use the following syntax: $APIM_NAME={name of your API Management instance}
RG_NAME={name of your resource group} 
# Get resource ID of API Management instance
APIM_RESOURCE_ID=$(az apim show --name $APIM_NAME --resource-group $RG_NAME --query id --output tsv)
# Call REST API to migrate to stv2 and preserve VIP address for special condition
az rest --method post --uri "$APIM_RESOURCE_ID/migrateToStv2?api-version=2024-06-01-preview&migrateWithDowntime=true" --body '{"mode": "PreserveIP"}'

  • Várias instâncias stv1 na sub-rede - Endereços IP livres suficientes podem não estar disponíveis para uma migração de mesma sub-rede se você tentar migrar as instâncias simultaneamente. Talvez seja possível migrar instâncias sequencialmente usando a Opção 1.

  • Delegação de sub-rede - Se a sub-rede onde o Gerenciamento de API está implantado estiver atualmente delegada a outros serviços do Azure, você deverá migrar usando a Opção 2.

  • Azure Key Vault blocked - Se o acesso ao Azure Key Vault estiver bloqueado no momento, você deverá migrar usando a Opção 2, incluindo a configuração de regras NSG na nova sub-rede para acesso ao Azure Key Vault.

Ajuda e suporte

Estamos aqui para ajudá-lo a migrar para a stv2 plataforma com o mínimo de interrupções em seus serviços.

Se você tiver dúvidas, obtenha respostas rápidas de especialistas da comunidade em Perguntas e respostas da Microsoft. Se tiver um plano de suporte e precisar de ajuda técnica, crie um pedido de suporte.

  1. Em Resumo, digite uma descrição do seu problema, por exemplo, "stv1 retirement".
  2. Em Tipo de problema, selecione Técnico.
  3. Em Subscrição, selecione a sua subscrição.
  4. Em Serviço, selecione Meus serviços e, em seguida, selecione Serviço de Gerenciamento de API.
  5. Em Recurso, selecione o recurso do Azure para o qual está a criar um pedido de suporte.
  6. Em Tipo de problema, selecione Administração e gerenciamento.
  7. Para o subtipo Problema, selecione Upgrade, Scale ou SKU Changes.

Perguntas mais frequentes

  • De que informações precisamos para 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?
    • Há um firewall envolvido?
    • Alguma dependência conhecida tomada por upstream/downstream nos IPs envolvidos?
    • É uma implantação multirregião?
    • Podemos modificar a instância existente ou é necessária uma configuração paralela?
    • Pode haver tempo de inatividade?
    • A migração pode ser feita fora do horário comercial?

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

    Para instâncias com injeção de rede virtual, consulte os pré-requisitos para as opções de migrar e manter a mesma sub-rede ou migrar e alterar para uma nova sub-rede.

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

    Ao migrar uma instância injetada por rede virtual e manter a mesma configuração de sub-rede, espera-se um tempo de inatividade mínimo ou nenhum para o gateway de API. Consulte a tabela de resumo em Tempo de inatividade esperado.

    Ao migrar e mudar para um novo endereço VIP, não deve haver nenhum tempo de inatividade se os nomes de host padrão estiverem em uso. É fundamental que todas as dependências de rede sejam atendidas antecipadamente para que as APIs afetadas sejam funcionais. No entanto, se domínios personalizados estiverem em uso, eles estarão apontando para a computação limpa até que sejam atualizados, o que pode causar um tempo de inatividade. Como alternativa, para determinadas opções de migração, habilite uma configuração de migração para manter o gateway antigo por 48 horas. Ter o antigo e o novo compute coexistindo facilitará a validação e, em seguida, você poderá atualizar as entradas DNS personalizadas à vontade.

  • Meu tráfego é forçado tunelado através de um firewall. Que alterações são necessárias?

    • Em primeiro lugar, certifique-se de que a(s) sub-rede(s) que você usa para a migração mantenha a seguinte configuração (elas já devem estar configuradas se você estiver migrando e mantendo sua sub-rede atual):
      • Habilite os pontos de extremidade de serviço conforme descrito aqui
      • O UDR (rota definida pelo usuário) tem o salto da tag de serviço ApiManagement definido como "Internet" e não apenas para o seu endereço de firewall
    • Os requisitos para a configuração NSG para stv2 permanecem os mesmos, quer você tenha firewall ou não; certifique-se de que sua nova sub-rede o tenha
    • 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 por/durante a migração?

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

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

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

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

    Sim, as instâncias injetadas por rede virtual podem ser migradas usando a folha de migração da plataforma.

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

    Sim, a folha de migração da plataforma no portal e a API REST têm opções para preservar o endereço IP.

  • Existe 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 sua instância de Gerenciamento de API não mostrar a versão da plataforma como stv2 ou stv2.1 e status como Online depois que você iniciou a migração, provavelmente falhou. Seu serviço é automaticamente revertido para a instância antiga e nenhuma alteração é feita.

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

    As solicitações de API permanecem responsivas durante a migração. A configuração da infraestrutura (como domínios personalizados, locais e certificados de CA) é bloqueada por 30 minutos.

  • Quanto tempo demorará a migração?

    A duração esperada para uma migração para uma nova configuração de rede virtual é de aproximadamente 45 minutos. O indicador para verificar se a migração já foi realizada é verificar se o Status da sua instância está de volta para Online e não Atualizando. Planeje tempos mais longos para implantações em várias regiões e em cenários que envolvam a alteração da sub-rede mais de uma vez.

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

    Se você planeja alterar a sub-rede durante a migração, pode implantar uma nova instância de Gerenciamento de API com a VNet, a sub-rede e o recurso de endereço IP (opcional) que você usará para a migração real. Navegue até a página Status da rede após a conclusão da implantação e verifique se cada status de conectividade do ponto de extremidade está verde. Se sim, você pode remover essa nova instância de Gerenciamento de API e prosseguir com a migração real com seu serviço -hosted original 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 stv1 plataforma. No entanto, depois que o serviço for migrado com êxito, você não poderá reverter para a stv1 plataforma.

  • É necessária alguma alteração nas zonas DNS personalizadas/privadas?

    Com instâncias injetadas por VNet no modo interno e mudando para um novo VIP, você precisará atualizar as zonas DNS privadas para o novo endereço IP da VNet adquirido após a migração. Preste atenção também para atualizar zonas DNS que não sejam do Azure (por exemplo, seus servidores DNS locais apontando 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 estiverem em uso.

  • Minha instância stv1 é implantada em várias regiões do Azure (várias regiões). Como faço para atualizar para stv2?

    As implantações em várias regiões incluem gateways mais gerenciados implantados em outros locais. Ao migrar usando a folha de migração de plataforma no portal, você migra cada local separadamente. A API REST Migrar para Stv2 migra todos os locais em uma chamada. A instância é considerada migrada para a nova plataforma somente quando todos os locais são migrados. Todos os gateways regionais continuam a operar normalmente durante todo o processo de migração.

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

    Sim, use a folha Migração de plataforma no portal ou use a API REST Migrar para stv2.

  • Posso testar o novo gateway em uma nova sub-rede antes de alternar o tráfego ao vivo?

    • Quando você migra para uma nova sub-rede, por padrão, os gateways gerenciados antigo e novo 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 antigos e novos gerenciados 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 nomes de domínio personalizados estiverem em uso, os registros DNS correspondentes talvez precisem ser atualizados com o novo endereço IP se não estiverem usando CNAME. Os clientes podem atualizar seu arquivo hosts para o novo IP de Gerenciamento de API e validar a instância antes de fazer a mudança. Durante esse processo de validação, o gateway antigo continua a servir o tráfego ao vivo.

  • Há alguma consideração ao usar o nome de domínio padrão em uma nova sub-rede?

    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 o switch acontece imediatamente em uma migração bem-sucedida, a nova instância começa a receber tráfego imediatamente, e é fundamental que quaisquer restrições/dependências de rede sejam atendidas com antecedência para evitar que as APIs afetadas fiquem indisponíveis.

  • O que devemos considerar para 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 stv1 plataforma. Observe que pode haver um novo IP para o ponto de extremidade de configuração da instância de Gerenciamento de API e quaisquer restrições de rede fixadas ao IP devem ser atualizadas.

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

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

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

    O modelo de faturamento permanece o mesmo e stv2 não haverá mais custos incorridos durante e após a migração.

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

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

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

Conteúdos relacionados