Compartilhar via

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

  • Artigo

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. Descubra se você precisa fazer isso.

Observação

Novidades em agosto de 2024: para ajudar você a migrar sua instância injetada em VNet, aprimoramos 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 VNet, você tem as seguintes opções de migração:

  • Opção 1: manter a mesma sub-rede – Migre a instância in-loco e mantenha 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 está 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 rede virtual 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 os endereços VIP da instância. 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.

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

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 de Gerenciamento de API hospedadas na plataforma stv1 está sendo desativado. No Azure global, a data de desativação é 31 de agosto de 2024. No Azure Governamental e no Azure operado pela 21Vianet (Azure na China), a data de desativação é 24 de fevereiro de 2025. Se tiver instâncias hospedadas na plataforma stv1, migre-as para a plataforma stv2 antes da data de desativação para evitar interrupções do serviço.

Cuidado

  • Migrar sua instância do Gerenciamento de API para a plataforma stv2 é uma operação de execução longa.
  • 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. Planeje prazos mais longos para implantações em várias regiões e para cenários que envolvem a alteração da sub-rede mais de uma vez.
  • O status do 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 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 é 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 nos serviços injetados na VNet.

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 plataforma stv2 que mantém a configuração de sub-rede existente, o que simplifica sua migração. Você pode migrar usando a folha 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 a cada sub-rede e as regras NSG para o Gerenciamento de API na plataforma stv2 devem ser configuradas. Veja a seguir as configurações mínimas de conectividade:

    • Saída para o Armazenamento do Microsoft 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 marca 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 Microsoft Azure, o SQL do Azure e o Azure Key Vault

  • 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 seu serviço existente durante a migração.

  • Outras considerações de rede:

    • Desative 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 prontamente todas as instâncias na sub-rede para evitar possíveis problemas com instâncias hospedadas em diferentes plataformas na mesma sub-rede.

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 está 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 poderão 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 de infraestrutura (como domínios personalizados, locais e certificados de AC) será bloqueada por 45 minutos. Nenhuma configuração adicional é necessária após a migração.

    Com essa opção, a computação stv1 é excluída permanentemente após a conclusão da migração. Não há nenhuma opção para mantê-la 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 preservação do 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 dinâmicas 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 para usar o novo endereço VIP.

    Com essa opção, a computação stv1 é mantida por um curto período por padrão após a 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 as instâncias do Gerenciamento de API que podem ser acessadas por um endereço IP público, o Gerenciamento de API cria previamente um IP público para o processo de migração. Localize o endereço IP pré-criado na saída JSON das propriedades da instância de Gerenciamento de API. Em customProperties, o endereço IP pré-criado é o valor da propriedade Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps. Para uma implantação de várias regiões, o valor é uma lista separada por vírgulas de endereços IP pré-criados.

Use o endereço IP pré-criado (ou endereços) 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 implantação stv2, antes que o endereço IP original seja atribuído à implantação stv2. Se você tiver regras de firewall que limitam 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 lista de permissões.
  • Quando você migra e gera um novo endereço VIP, o endereço IP pré-criado é atribuído à nova implantação stv2 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 regras de DNS e firewall, para apontar ao novo endereço IP.

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

Ao migrar uma instância injetada por VNet e manter a mesma configuração de sub-rede, é esperado um tempo mínimo ou nenhum tempo de inatividade para o gateway de API. A tabela a seguir resume o tempo de inatividade e a retenção de computação stv1 esperados 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
Externo 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 implantação stv2 Nenhuma retenção
Externo Novo VIP Nenhum 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 implantação stv2. Nenhuma retenção
Interna Novo VIP Nenhum tempo de inatividade Mantido 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: manter a mesma sub-rede

  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. Em Selecionar uma opção de migração, selecione Manter a mesma sub-rede.
  4. Em Escolher uma opção de endereço IP, selecione uma das duas opções de endereço IP.

    Observação

    Se sua VNet estiver no modo externo, anote o 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 Escolher o cenário que se alinha com seus requisitos, escolha uma das duas opções, dependendo se você quer manter a computação stv1 original por um período após a migração.
  6. Selecione Verificar para executar verificações automatizadas na sub-rede. Se forem detectados problemas, ajuste a configuração da sub-rede e execute as verificações novamente. Para outras dependências de rede, como regras de DNS e firewall, verifique manualmente.
  7. Confirme que você quer migrar e selecione Iniciar migração. 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.

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

Usando o portal do Azure, você pode migrar sua instância especificando uma sub-rede diferente na mesma rede virtual 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 da migração in-loco para uma nova sub-rede.

Pré-requisitos

  • 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 a cada sub-rede e as regras NSG para o Gerenciamento de API na plataforma stv2 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 recurso de 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 e usado para tráfego de API de runtime. Forneça apenas o endereço IP público se você quiser possuir e controlar o endereço IP público usado para comunicação de entrada ou de saída para a Internet.

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

  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. Em Selecionar uma opção de migração, selecione Alterar para uma nova sub-rede.

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

    Captura de tela das opções para manter 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 você deseja migrar.

    Captura de tela da seleção das 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 detectados problemas, ajuste a configuração da sub-rede e execute as verificações novamente. Para outras dependências de rede, como regras de DNS e firewall, verifique manualmente.

  7. Confirme que você quer 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

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 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.

Diagrama da migração in-loco 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 recurso de 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 e usado para tráfego de API de runtime. Forneça apenas o endereço IP público se você quiser possuir e controlar o endereço IP público usado para comunicação de entrada ou de saída para a Internet.

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

Para cenários em que o gateway antigo fica 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. Você pode usar esse tempo para validar a implantação e verificar se seus aplicativos estão funcionando conforme o esperado. Para determinados cenários, opcionalmente, você pode estender o período de retenção para 48 horas por meio de uma configuração do portal.

  • 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 stv2 lado a lado com sua instância original do Gerenciamento de API.

Condições e cenários especiais

Em determinadas condições, a Opção 1: Migrar e manter a mesma sub-rede pode não estar disponível ou comportar-se de maneira diferente. O portal detecta essas condições e recomenda as opções de migração. Se você não puder usar a Opção 1, ou se várias condições estiverem presentes, use a Opção 2: Alterar para uma nova sub-rede.

  • VNet com condições internas especiais - Se sua instância do 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 que a Opção 1 para migração na mesma sub-rede no portal inclui tempo de inatividade adicional (aproximadamente 1 hora). É recomendável usar o portal para a migração. Você também pode usar o seguinte script da CLI do Azure modificado para migração na 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"}'

  • Múltiplas instâncias stv1 na sub-rede - Endereços IP gratuitos suficientes podem não estar disponíveis para uma migração na mesma sub-rede se você tentar migrar as instâncias simultaneamente. Você pode migrar as instâncias sequencialmente usando a Opção 1.

  • Delegação de sub-rede - Se a sub-rede em que 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 bloqueado - Se o acesso ao Azure Key Vault estiver atualmente bloqueado, você deverá migrar usando a Opção 2, incluindo configurar regras de NSG na nova sub-rede para acesso ao Azure Key Vault.

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, consulte os pré-requisitos para as opções para migrar e manter a mesma sub-rede ou para migrar e alterar para uma nova sub-rede.

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

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

    Ao migrar e alterar 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 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, para determinadas opções de migração, habilite 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 sub-redes usadas para a migração mantêm a seguinte configuração (elas já devem estar configuradas se você estiver migrando e mantendo sua 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 usando a folha de Migração de plataforma.

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

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

  • 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.

  • 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. Planeje prazos mais longos para implantações em várias regiões e para cenários que envolvem a alteração da sub-rede mais de uma vez.

  • Há 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, poderá implantar uma nova instância de Gerenciamento de API com o recurso de endereço IP VNet, sub-rede e (opcional) que você usará 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, após o serviço ter sido migrado com sucesso, você não poderá revertê-lo para a plataforma stv1.

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

    Com as instâncias injetadas em VNet no modo interno e alterando 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. 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. Ao migrar usando a folha Migração de plataforma no portal, você migra cada local separadamente. A API REST de Migração 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 operando 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 dinâmico?

    • Ao migrar para uma nova sub-rede, por padrão, os gateways gerenciados antigos e os 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á 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 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

Conteúdo relacionado