Partager via

Migration d’une instance Gestion des API injectée dans un VNet, hébergée sur la plateforme stv1 et déplacée vers stv2

  • Article

S’APPLIQUE À : Développeur | Premium

Cet article décrit les étapes de migration d’une instance Gestion des API hébergée sur la plateforme de calcul stv1 sur place vers la plateforme stv2 lorsque l’instance est injectée (déployée) dans un VNet externe ou interne. Déterminez si vous avez besoin de le faire.

Remarque

Nouveauté d’août 2024 : pour vous aider à migrer votre instance injectée dans un réseau virtuel, nous avons amélioré les options de migration dans le portail. Vous pouvez désormais migrer votre instance sur place et conserver le même sous-réseau et la même adresse IP.

Vous avez les options de migration suivantes pour une instance injectée par un réseau virtuel :

  • Option 1 : conserver le même sous-réseau : migrez l’instance en place et conservez la configuration de sous-réseau existante des instances. Vous pouvez choisir de conserver (recommandé) l’adresse IP virtuelle d’origine de l’instance Gestion des API ou de générer une nouvelle adresse IP virtuelle.

  • Option 2 : remplacer par un nouveau sous-réseau : migrez votre instance en spécifiant un autre sous-réseau dans le même réseau virtuel ou un autre. Après la migration, vous pouvez éventuellement migrer de nouveau vers le sous-réseau d’origine de l’instance. Le processus de migration change la ou les adresses IP virtuelles de l’instance. Après la migration, vous devez mettre à jour toutes les dépendances réseau, notamment DNS, règles de pare-feu et réseaux virtuels pour utiliser la ou les nouvelles adresses IP virtuelles.

Dans certaines conditions moins fréquentes, la migration dans le même sous-réseau peut ne pas être possible ou se comporter différemment. Pour plus d'informations, voir Conditions et scénarios particuliers.

Si vous devez migrer une Gestion des API non injectée par un VNet hébergée sur la plateforme stv1, consultez Migrer une instance de gestion des API non injectée par un VNet vers la plateforme stv2.

Important

La prise en charge des instances Gestion des API hébergées sur la plateforme stv1 est en cours de mise hors service. Dans Azure global, la date de mise hors service est le 31 août 2024. Dans Azure Government et Azure géré par 21Vianet (Azure en Chine), la date de mise hors service est le 24 février 2025. Si vous avez des instances hébergées sur la plateforme stv1, migrez-les vers la plateforme stv2 avant la date de mise hors service pour éviter des interruptions de service.

Attention

  • La migration de votre instance Gestion des API vers la plateforme stv2 est une opération de longue durée.
  • La migration vers stv2 n’est pas réversible.

Que se passe-t-il pendant la migration ?

La migration de la plateforme Gestion des API de stv1 vers stv2 implique la mise à jour du calcul sous-jacent uniquement et n’a aucun impact sur la configuration du service/des API conservés dans la couche de stockage.

  • Le processus de mise à niveau implique la création d’un nouveau calcul en parallèle avec l’ancien calcul, ce qui peut prendre jusqu’à 45 minutes. Planifiez des temps plus longs pour les déploiements multi-région et dans les scénarios qui impliquent le changement de sous-réseau à maintes reprises.
  • L’état de Gestion des API dans le Portail Microsoft Azure est Mise à jour.
  • Pour certaines options de migration, vous pouvez choisir de conserver l’adresse IP virtuelle ou de générer une nouvelle adresse IP virtuelle publique.
  • Pour les scénarios de migration dans lesquels une nouvelle adresse IP virtuelle est générée :
    • Azure prend en charge la migration.
    • Le DNS de passerelle pointe toujours vers l’ancien calcul si un domaine personnalisé est utilisé.
    • Si le DNS personnalisé n’est pas utilisé, le DNS de la passerelle et du portail pointe immédiatement vers le nouveau calcul.
    • Pour une instance en mode VNet interne, le client gère le DNS, de sorte que les entrées DNS continuent de pointer vers l’ancien calcul jusqu’à ce que le client soit mis à jour.
    • C’est le DNS qui pointe vers le nouveau ou l’ancien calcul et, par conséquent, il n’y a aucun temps d’arrêt sur les API.
    • Des changements sont nécessaires sur vos règles de pare-feu, le cas échéant, pour permettre au nouveau sous-réseau de calcul d’accéder aux back-ends.
    • Une fois la migration réussie, l’ancien calcul est automatiquement désactivé après une courte période. Lorsque vous passez à un nouveau sous-réseau à l’aide du panneau Migration de plateforme dans le portail, vous pouvez activer un paramètre de migration pour conserver l’ancienne passerelle pendant 48 heures. L’option de délai de 48 heures n’est disponible que pour les services injectés par VNet.

Prérequis

D’autres conditions préalables sont spécifiques aux options de migration dans les sections suivantes.

Option 1 : migrer et conserver le même sous-réseau

Vous pouvez migrer votre instance Gestion des API vers la plateforme stv2 en conservant la configuration de sous-réseau existante, ce qui simplifie votre migration. Vous pouvez effectuer une migration à l’aide du panneau Migration de plateforme dans le Portail Azure ou à l’aide de l’API REST Migrer vers Stv2.

Prérequis

  • Un groupe de sécurité réseau doit être attaché au sous-réseau et les règles de groupe de sécurité réseau pour Gestion des API sur la plateforme stv2 doivent être configurées. Les éléments suivants sont les paramètres minimaux de connectivité :

    • Sortie vers Stockage Azure sur le port 443
    • Sortie vers Azure SQL sur le port 1433
    • Sortie vers Azure Key Vault sur le port 443
    • Entrée à partir d’Azure Load Balancer sur le port 6390
    • Entrée à partir de l’étiquette de service ApiManagement sur le port 3443
    • Entrée sur le port 80/443 pour des clients appelant le service Gestion des API
    • Le sous-réseau doit avoir des points de terminaison de service activés pour Stockage Azure, Azure SQL et Azure Key Vault

  • L’espace d’adressage de chaque sous-réseau existant doit être suffisamment volumineux pour héberger une copie de votre service existant côte à côte avec votre service existant pendant la migration.

  • Autres considérations de réseau :

    • Désactivez les règles de mise à l’échelle automatique configurées pour des instances Gestion des API déployées dans le sous-réseau. Les règles de mise à l’échelle automatique peuvent interférer avec le processus de migration.
    • Si vous avez plusieurs instances Gestion des API dans le même sous-réseau, migrez chaque instance dans une séquence. Nous vous recommandons de migrer rapidement toutes les instances dans le sous-réseau pour éviter des problèmes éventuels avec des instances hébergées sur différentes plateformes dans le même sous-réseau.

Options d’adresse IP publique : migration dans le même sous-réseau

Vous pouvez choisir de conserver (recommandé) l’adresse IP virtuelle d’origine de l’instance Gestion des API ou de générer une nouvelle adresse IP virtuelle.

  • Conserver l’adresse IP virtuelle : si vous conservez l’adresse IP virtuelle dans un réseau virtuel en mode externe, les requêtes d’API peuvent rester dynamiques pendant une migration (voir Temps d’arrêt prévu) pour un réseau virtuel en mode interne, un temps d’arrêt temporaire est attendu. La configuration de l’infrastructure (par exemple, les domaines personnalisés, les emplacements et les certificats d’autorité de certification) est verrouillée pendant 45 minutes. Aucune configuration supplémentaire n'est nécessaire après la migration.

    Avec cette option, le calcul stv1 est définitivement supprimé après la réussite de la migration. Il n’existe aucune option pour le conserver temporairement.

    L’image suivante offre une vue d’ensemble de ce qui se passe lorsque l’adresse IP est conservée.

    Diagramme de la migration sur place vers le même sous-réseau et de la conservation de l’adresse IP.

  • Nouvelle adresse IP virtuelle : si vous choisissez cette option, Gestion des API génère une nouvelle adresse IP virtuelle pour votre instance. Les demandes d’API restent réactives pendant la migration. La configuration de l’infrastructure (par exemple, les domaines personnalisés, les emplacements et les certificats d’autorité de certification) est verrouillée pendant 30 minutes. Après la migration, vous devez mettre à jour toutes les dépendances réseau, notamment DNS, règles de pare-feu et réseaux virtuels pour utiliser la nouvelle adresse IP virtuelle.

    Avec cette option, le calcul stv1 est conservé pendant une courte période par défaut après la fin de la migration afin que vous puissiez valider l’instance migrée et confirmer la configuration réseau et DNS.

    L’image suivante offre une vue d’ensemble de ce qui se passe lorsqu’une nouvelle adresse IP est générée.

    Diagramme de la migration sur place vers le même sous-réseau et de la génération d’une nouvelle adresse IP.

Adresse IP pré-créée pour une migration

Pour les instances Gestion des API accessibles par un adresse IP publique, Gestion des API crée au préalable une adresse IP publique pour le processus de migration. Recherchez l’adresse IP pré-créée dans la sortie JSON des propriétés de votre instance Gestion des API. Sous customProperties, l’adresse IP pré-créée est la valeur de la propriété Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps. Pour un déploiement multirégional, la valeur est une liste séparée par des virgules d’adresses IP pré-créées.

Utilisez l’adresse IP pré-créée (ou adresses) pour vous aider à gérer le processus de migration :

  • Lorsque vous migrez ou conservez l’adresse IP, l’adresse IP pré-créée est attribuée au nouveau déploiement stv2 temporairement, avant l’attribution de l’adresse IP d’origine au déploiement stv2. Si vous avez des règles de pare-feu limitant l’accès à l’instance Gestion des API, vous pouvez par exemple ajouter l’adresse IP pré-créée à la liste d’autorisation pour préserver la continuité de l’accès client pendant la migration. Après avoir effectué la migration, vous pouvez supprimer l’adresse IP pré-créée de la liste d’autorisation.
  • Quand vous migrez et générez une nouvelle adresse IP virtuelle, l’adresse IP pré-créée est attribuée au nouveau déploiement stv2 pendant la migration et persiste après l’achèvement de la migration. Utilisez l’adresse IP pré-créée pour mettre à jour vos dépendances réseau, comme les règles de pare-feu et DNS, à pointer vers la nouvelle adresse IP.

Temps d’arrêt prévu et rétention de calcul

Lors de la migration d’une instance injectée par un réseau virtuel et de la conservation de la même configuration de sous-réseau, un temps d’arrêt inexistant ou minimal est attendu pour la passerelle API. Le tableau suivant résume le temps d’arrêt et la rétention de calcul stv1 pour chaque scénario de migration lors de la conservation du même sous-réseau :

Mode réseau virtuel Option IP publique Temps d’arrêt prévu Rétention de calcul stv1
Externe Conserver une adresse IP virtuelle Aucun temps d’arrêt, le trafic est servi sur une adresse IP temporaire pendant jusqu’à 20 minutes pendant une migration vers le nouveau déploiement stv2 Pas de conservation
Externe Nouvelle adresse IP virtuelle aucun temps d’arrêt Conservé par défaut pendant 15 minutes pour vous permettre de mettre à jour des dépendances réseau
Interne Conserver une adresse IP virtuelle Temps d’arrêt de 20 minutes environ pendant la migration alors que l’adresse IP existante est attribuée au nouveau déploiement stv2. Pas de conservation
Interne Nouvelle adresse IP virtuelle aucun temps d’arrêt Conservation par défaut pendant 15 minutes pour vous permettre de mettre à jour les dépendances réseau ; possibilité de prolongation jusqu’à 48 heures lors de l’utilisation du portail

Étapes de migration : conserver le même sous-réseau

  1. Dans le portail Azure, accédez à votre instance APIM.
  2. Dans le menu de gauche sous Paramètres, sélectionnez Plateforme de migration.
  3. Sous Sélectionner une option de migration, sélectionnez Conserver le même sous-réseau.
  4. Sous Choisir une option d’adresse IP, sélectionnez l’une des deux options d’adresse IP.

    Remarque

    Si votre réseau virtuel est en mode externe, notez l’adresse IP publique précréée pour le processus de migration. Utilisez cette adresse pour configurer la connectivité réseau de votre instance migrée.

  5. (Pour les instances injectées en mode interne et migrant vers une nouvelle adresse IP virtuelle) Sous Choisir le scénario qui correspond à vos exigences, choisissez l’une des deux options selon que vous souhaitez conserver le calcul stv1 d’origine pendant une certaine période après la migration.
  6. Sélectionnez Vérifier pour exécuter des vérifications automatisées sur le sous-réseau. Si des problèmes sont détectés, ajustez la configuration de votre sous-réseau et réexécutez les vérifications. Pour les autres dépendances réseau, telles que les règles DNS et de pare-feu, procédez à une vérification manuelle.
  7. Confirmez que vous souhaitez effectuer une migration, puis sélectionnez Démarrer la migration. L’état de votre instance Gestion des API passe à Mise à jour en cours. Le processus de migration prend environ 45 minutes. Lorsque l’état passe à En ligne, la migration est terminée.

Option 2 : migrer et passer à un nouveau sous-réseau

L’utilisation du Portail Azure vous permet de migrer votre instance en spécifiant un autre sous-réseau dans le même réseau virtuel ou un autre. Après la migration, vous pouvez éventuellement migrer de nouveau vers le sous-réseau d’origine de l’instance.

L’image suivante offre une vue d’ensemble générale de ce qui se passe lors de la migration vers un nouveau sous-réseau.

Diagramme d’une migration sur place vers un nouveau sous-réseau.

Prérequis

  • Un nouveau sous-réseau dans le réseau virtuel actuel, dans chaque région où l'instance de Gestion des API est déployée. (Vous pouvez également configurer un sous-réseau sur un autre réseau virtuel, dans les mêmes régions et le même abonnement que votre instance Gestion des API). Un groupe de sécurité réseau doit être attaché au sous-réseau et les règles de groupe de sécurité réseau pour Gestion des API sur la plateforme stv2 doivent être configurées.

  • (Facultatif) Une nouvelle ressource d’adresse IPv4 publique de SKU Standard dans la ou les mêmes régions et le même abonnement que votre instance Gestion des API. Pour plus d’informations, consultez Prérequis pour les connexions réseau.

Important

  • Depuis mai 2024, il n’est plus nécessaire de disposer d’une ressource d’adresse IP publique lors du déploiement (injection) d’une instance de Gestion des API dans un réseau virtuel en mode interne ou lors de la migration de la configuration d’un réseau virtuel interne vers un nouveau sous-réseau. En mode réseau virtuel externe, la spécification d’une adresse IP publique est facultative. Si vous n’en fournissez pas, une adresse IP publique gérée par Azure est automatiquement configurée et utilisée pour le trafic de l’API runtime. Ne fournissez l’adresse IP publique uniquement si vous souhaitez posséder et contrôler l’adresse IP publique utilisée pour les communications entrantes ou sortantes vers Internet.

Étapes de la migration – Passer à un nouveau sous-réseau

  1. Dans le portail Azure, accédez à votre instance APIM.

  2. Dans le menu de gauche sous Paramètres, sélectionnez Plateforme de migration.

  3. Sous Sélectionner une option de migration, sélectionnez Passer à un nouveau sous-réseau.

  4. Sous Choisir le scénario qui correspond à vos exigences, choisissez l’une des deux options selon que vous souhaitez conserver le calcul stv1 d’origine pendant une certaine période après la migration.

    Capture d’écran des options permettant de conserver le calcul stv1 sur le portail.

  5. Sous Définir les paramètres de migration pour chaque emplacement :

    1. Sélectionnez un emplacement à migrer.
    2. Sélectionnez le réseau virtuel, le sous-réseau et l’adresse IP publique facultative vers lesquels vous souhaitez migrer.

    Capture d’écran de la sélection des paramètres de migration réseau sur le portail.

  6. Sous Vérifier que votre sous-réseau répond aux exigences de migration, sélectionnez Vérifier pour exécuter des vérifications automatisées sur le sous-réseau. Si des problèmes sont détectés, ajustez la configuration de votre sous-réseau et réexécutez les vérifications. Pour les autres dépendances réseau, telles que les règles DNS et de pare-feu, procédez à une vérification manuelle.

  7. Confirmez que vous souhaitez effectuer une migration, puis sélectionnez Migrer. L’état de votre instance Gestion des API passe à Mise à jour en cours. Le processus de migration prend environ 45 minutes. Lorsque l’état passe à En ligne, la migration est terminée.

Si votre instance Gestion des API est déployée dans plusieurs régions, répétez les étapes précédentes pour continuer la migration des paramètres de réseau virtuel pour les emplacements restants de votre instance.

(Facultatif) Migrer de nouveau vers le sous-réseau d’origine

Si vous avez migré et êtes passé à un nouveau sous-réseau, vous pouvez éventuellement revenir au sous-réseau d’origine que vous avez utilisé dans chaque région. Pour ce faire, mettez de nouveau à jour la configuration du VNet, en spécifiant cette fois le VNet et le sous-réseau d’origine dans chaque région. Comme lors de la migration précédente, attendez-vous à une opération de longue durée et que l’adresse IP virtuelle change.

L’image suivante offre une vue d’ensemble générale de ce qui se passe lors de la migration inverse vers le sous-réseau d’origine.

Diagramme de migration sur place vers le sous-réseau d'origine.

Important

Si le VNet et le sous-réseau sont verrouillés (car d’autres instances stv1 de Gestion des API basées sur la plateforme y sont déployées) ou si le groupe de ressources où le VNet d’origine est déployé a un verrou de ressource, veillez à supprimer le verrou avant de revenir au sous-réseau d’origine. Attendez que la suppression du verrou soit terminée avant de tenter la migration vers le sous-réseau d'origine. Plus d’informations

Autres composants requis

  • Le sous-réseau d'origine non verrouillé, dans chaque région où l'instance de Gestion des API est déployée. Un groupe de sécurité réseau doit être attaché au sous-réseau et les règles de groupe de sécurité réseau pour Gestion des API doivent être configurées.

  • (Facultatif) Une nouvelle ressource d’adresse IPv4 publique de SKU Standard dans la ou les mêmes régions et le même abonnement que votre instance Gestion des API.

    Important

    • Depuis mai 2024, il n’est plus nécessaire de disposer d’une ressource d’adresse IP publique lors du déploiement (injection) d’une instance de Gestion des API dans un réseau virtuel en mode interne ou lors de la migration de la configuration d’un réseau virtuel interne vers un nouveau sous-réseau. En mode réseau virtuel externe, la spécification d’une adresse IP publique est facultative. Si vous n’en fournissez pas, une adresse IP publique gérée par Azure est automatiquement configurée et utilisée pour le trafic de l’API runtime. Ne fournissez l’adresse IP publique uniquement si vous souhaitez posséder et contrôler l’adresse IP publique utilisée pour les communications entrantes ou sortantes vers Internet.

Mettre à jour la configuration VNet

  1. Dans le portail, naviguez vers votre réseau virtuel d’origine.
  2. Dans le menu de gauche, sélectionnez Sous-réseaux, puis le sous-réseau d’origine.
  3. Vérifiez que les adresses IP d’origine sont publiées par Gestion des API. Sous Adresses IP disponibles, notez le nombre d’adresses IP disponibles dans le sous-réseau. Toutes les adresses (sauf les adresses réservées Azure) doivent être disponibles. Si nécessaire, attendez que les adresses IP soient publiées.
  4. Accédez à votre instance API Management.
  5. Dans le menu de gauche, sous Réseau, sélectionnez Réseau virtuel.
  6. Sélectionnez la connexion réseau dans l’emplacement que vous souhaitez mettre à jour.
  7. Sélectionnez le réseau et le sous-réseau du réseau virtuel d’origine. Sélectionnez éventuellement une nouvelle adresse IP publique. Sélectionnez Appliquer.
  8. Si votre instance Gestion des API est déployée dans plusieurs régions, poursuivez la configuration des paramètres de réseau virtuel pour les emplacements restants de votre instance.
  9. Dans la barre de navigation supérieure, sélectionnez Enregistrer.

Après avoir mis à jour la configuration du VNet, l’état de votre instance Gestion des API passe à la Mise à jour. Le processus de migration prend environ 45 minutes. Lorsque l’état passe à En ligne, la migration est terminée.

Vérifier la migration

Pour vérifier que la migration a réussi, quand l’état devient En ligne, vérifiez la version de plateforme de votre instance Gestion des API. Une fois la migration correctement effectuée, la valeur est stv2 ou stv2.1.

Confirmer les paramètres avant que l'ancienne passerelle ne soit purgée

Pour les scénarios dans lesquels l’ancienne passerelle est temporairement conservée après la migration, l’ancien et le nouveau calcul créé pendant la migration coexistent pendant une courte période, environ 15 minutes, que vous pouvez utiliser pour valider le déploiement et le fonctionnement correct de vos applications. Pour certains scénarios, vous pouvez éventuellement étendre la période de rétention à 48 heures via un paramètre de portail.

  • Pendant cette fenêtre, l'ancienne et la nouvelle passerelle sont toutes deux en ligne et servent le trafic. Vous n’êtes pas facturé pendant cette période.
  • Utilisez cette fenêtre pour mettre à jour toutes les dépendances réseau, notamment le DNS, les règles de pare-feu et les VNets pour qu’ils utilisent la nouvelle adresse IP virtuelle et le nouvel espace d'adressage du sous-réseau.
  • Vérifiez également l’état du réseau de l’instance mise à jour pour assurer la connectivité de l’instance à ses dépendances. Dans le menu de gauche du portail, sous Déploiement et infrastructure, sélectionnez Réseau>État du réseau. Si nécessaire, mettez à jour les paramètres tels que les UDR et les règles NSG.
  • Après la fenêtre, l'ancienne passerelle est mise hors service et la nouvelle passerelle est la seule à desservir le trafic.

Restaurer automatiquement en cas d’échec de la migration

En cas de défaillance pendant le processus de migration, l’instance restaure automatiquement la plateforme stv1. Si la migration s’effectue correctement (la version de la plateforme de l’instance s’affiche sous la forme stv2 ou stv2.1 et l’état en tant que En ligne), vous ne pouvez pas revenir à la plateforme stv1.

En cas d'échec de la migration, contactez le support Azure.

Si vous avez besoin de la fonctionnalité de restauration manuelle, la suggestion consiste à déployer une nouvelle stv2 instance côte à côte avec votre instance de Gestion des API d’origine.

Conditions et scénarios particuliers

Dans certaines conditions, l'option 1 : migrer et conserver le même sous-réseau peut ne pas être disponible ou se comporter différemment. Le portail détecte ces conditions et recommande la ou les options de migration. Si vous ne pouvez pas utiliser l'option 1 ou si plusieurs conditions sont présentes, utilisez l'option 2 : passer à un nouveau sous-réseau.

  • VNet avec conditions internes spéciales - Si votre instance de gestion des API est actuellement déployée dans un réseau virtuel avec des conditions internes spéciales (sans rapport avec la configuration du client), vous êtes informé dans le portail que l'option 1 pour la migration vers le même sous-réseau dans le portail inclut des temps d'arrêt supplémentaires (environ 1 heure). Il est recommandé d'utiliser le portail pour la migration. Vous pouvez également utiliser le script Azure CLI modifié suivant pour la migration du même sous-réseau avec environ 1 heure d'indisponibilité :

    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"}'

  • Plusieurs instances stv1 dans le sous-réseau - Il se peut que des adresses IP libres suffisantes ne soient pas disponibles pour une migration du même sous-réseau si vous tentez de migrer les instances simultanément. Vous pourrez peut-être migrer des instances de manière séquentielle à l’aide de l’option 1.

  • Délégation de sous-réseau - Si le sous-réseau sur lequel la gestion des API est déployée est actuellement délégué à d’autres services Azure, vous devez migrer à l’aide de l’option 2.

  • Azure Key Vault bloqué - Si l’accès à Azure Key Vault est actuellement bloqué, vous devez migrer à l’aide de l’option 2, y compris la configuration de règles NSG dans le nouveau sous-réseau pour l’accès à Azure Key Vault.

Aide et support

Nous vous proposons ici de vous aider à migrer vers la plateforme stv2 avec un minimum d’interruptions pour vos services.

Si vous avez des questions, interrogez les experts de la communauté dans Microsoft Q&A et obtenez des réponses rapides. Si vous disposez d’un plan de support et que vous avez besoin d’une aide technique, créez une demande de support.

  1. Pour Résumé, tapez une description de votre problème, par exemple « mise hors service stv1 ».
  2. Sous Type de problème, sélectionnez Technique.
  3. Sous Abonnement, sélectionnez votre abonnement.
  4. Sous Service, sélectionnez Mes services, puis Service de gestion des API.
  5. Sous Ressource, sélectionnez la ressource Azure pour laquelle vous créez une demande de support.
  6. Pour le Type de problème, sélectionnez Administration et gestion.
  7. Pour le Sous-type de problème, sélectionnez Mettre à niveau, Mettre à l’échelle ou Modifier la référence SKU.

Forum aux questions

  • De quelles informations avons-nous besoin pour choisir un chemin de migration ?

    • Quel est le mode de réseau de l’instance Gestion des API ?
    • Des domaines personnalisés sont-ils configurés ?
    • Un pare-feu est-il impliqué ?
    • Des dépendances connues prises en amont/en aval sur les IP sont-elles impliquées ?
    • Est-ce un déploiement dans plusieurs régions ?
    • Pouvons-nous modifier l’instance existante ou une configuration parallèle est-elle nécessaire ?
    • Peut-il y avoir un temps d’arrêt ?
    • La migration peut-elle être effectuée en dehors des heures de travail ?

  • Quels sont les prérequis de la migration ?

    Pour les instances injectées par un réseau virtuel, consultez les prérequis pour les options afin de migrer et conserver le même sous-réseau ou de migrer et passer à un nouveau sous-réseau.

  • La migration entraîne-t-elle un temps d’arrêt ?

    Lors de la migration d’une instance injectée par un réseau virtuel et de la conservation de la même configuration de sous-réseau, un temps d’arrêt inexistant ou minimal est attendu pour la passerelle API. Consultez le tableau récapitulatif dans Temps d’arrêt prévu.

    Lors de la migration et du passage vers une nouvelle adresse IP virtuelle, il ne doit y avoir aucun temps d’arrêt si des noms d’hôte par défaut sont utilisés. Il est essentiel que toutes les dépendances réseau soient traitées à l’avance, pour que les API impactées soient fonctionnelles. Toutefois, si des domaines personnalisés sont en cours d’utilisation, ils pointent vers le calcul vidé jusqu’à ce qu’ils soient mis à jour, ce qui peut entraîner un temps d’arrêt. Vous pouvez également activer, pour certaines options de migration, un paramètre de migration pour conserver l’ancienne passerelle pendant 48 heures. L’ancienne et la nouvelle coexistence de calcul facilitent la validation, puis vous pouvez mettre à jour les entrées DNS personnalisées à l’écran.

  • Mon trafic a un tunneling forcé à travers un pare-feu. Quels sont les changements nécessaires ?

    • Tout d’abord, vérifiez que le ou les sous-réseaux que vous utilisez conservent la configuration suivante (doivent déjà être configurés si vous migrez et conservez votre sous-réseau actuel) :
      • Activez les points de terminaison de service comme décrit ici
      • L’UDR (route définie par l’utilisateur) a le tronçon de l’étiquette de service ApiManagement défini sur « Internet » et pas seulement sur votre adresse de pare-feu
    • Les exigences de la configuration NSG pour stv2 restent identiques que vous ayez un pare-feu ou non. Vérifiez que votre nouveau sous-réseau a cette configuration
    • Les règles de pare-feu qui référencent la plage d’adresses IP actuelle de l’instance Gestion des API doivent être mises à jour pour utiliser la plage d’adresses IP de votre nouveau sous-réseau.

  • Les données ou les pertes de configuration peuvent-elles se produire par ou pendant la migration ?

    La migration de stv1 vers stv2 implique la mise à jour de la plateforme de calcul uniquement, la couche de stockage interne n’est pas changée. Par conséquent, toute la configuration est protégée pendant le processus de migration. Cela inclut l'identité managée affectée par le système, qui est préservée si elle est activée.

  • Comment vérifier que la migration est terminée et réussie ?

    La migration est considérée terminée et réussie quand l’état sur la page Vue d’ensemble indique En ligne ainsi que la version de plateforme stv2 ou stv2.1. Vérifiez également que l’état du réseau dans le panneau Réseau affiche en vert toutes les connectivités nécessaires.

  • Puis-je effectuer la migration à partir du portail ?

    Oui. Les instances injectées dans un réseau virtuel peuvent être migrées en utilisant le volet Migration de plateforme.

  • Puis-je conserver l’adresse IP de l’instance ?

    Oui, le panneau Migration de plateforme du portail et l’API REST proposent des options permettant de conserver l’adresse IP.

  • Existe-t-il un chemin de migration qui ne modifie pas l’instance existante ?

    Oui, vous avez besoin d’une migration côte à côte. Cela signifie que vous créez une instance Gestion des API en parallèle de votre instance actuelle et copiez la configuration sur la nouvelle instance.

  • Que se passe-t-il si la migration échoue ?

    Si votre instance Gestion des API n’affiche pas la version de plateforme stv2 ou stv2.1 et l’état En ligne une fois la migration lancée, c’est qu’elle a probablement échoué. Votre service est automatiquement restauré sur l’ancienne instance et aucun changement n’est effectué.

  • Quelle fonctionnalité n’est pas disponible pendant la migration ?

    Les demandes d’API restent réactives pendant la migration. La configuration de l’infrastructure (par exemple, les domaines personnalisés, les localisations et les certificats d’autorité de certification) est verrouillée pendant 30 minutes.

  • Combien de temps prend la migration ?

    La durée prévue d'une migration vers une nouvelle configuration VNet est d'environ 45 minutes. Pour voir si la migration a déjà été effectuée, vérifiez si l’état de votre instance est En ligne de nouveau et pas Mise à jour. Planifiez des temps plus longs pour les déploiements multi-région et dans les scénarios qui impliquent le changement de sous-réseau à maintes reprises.

  • Existe-t-il un moyen de valider la configuration du VNet avant de tenter la migration ?

    Si vous planifiez de changer de sous-réseau pendant la migration, vous pouvez déployer une nouvelle instance Gestion des API avec le réseau virtuel, sous-réseau et éventuellement la nouvelle ressource d’adresse IP que vous utilisez pour la migration réelle. Accédez à la page État du réseau une fois le déploiement terminé, puis vérifiez si chaque état de connectivité de point de terminaison est vert. Si oui, vous pouvez supprimer cette nouvelle instance Gestion des API et continuer la migration réelle avec votre service hébergé stv1 d’origine.

  • Puis-je restaurer la migration si nécessaire ?

    En cas de défaillance pendant le processus de migration, l’instance restaure automatiquement la plateforme stv1. Toutefois, une fois le service migré avec succès, vous ne pouvez pas revenir à la plateforme stv1.

  • Des changements sont-il nécessaires dans les domaines personnalisés/zones DNS privées ?

    Avec les instances injectées par un réseau virtuel en mode interne et le passage à une nouvelle adresse IP virtuelle, vous devez mettre à jour les zones DNS privées vers la nouvelle adresse IP du réseau virtuel acquise après la migration. Veillez à mettre à jour aussi les zones DNS non-Azure (par exemple, vos serveurs DNS locaux pointant vers l’adresse IP privée de Gestion des API). Toutefois, en mode externe, le processus de migration met automatiquement à jour les domaines par défaut s’ils sont utilisés.

  • Mon instance stv1 est déployée sur plusieurs régions Azure (multi-région). Comment effectuer la mise à niveau vers stv2 ?

    Les déploiements multi-région ont d’autres passerelles managées déployées dans d’autres localisations. Lorsque vous migrez en utilisant le volet Migration de plateforme dans le portail, vous migrez chaque emplacement séparément. L’API REST Migrer vers Stv2 migre tous les emplacements d’un seul appel. L’instance est considérée comme migrée vers la nouvelle plateforme uniquement quand toutes les localisations sont migrées. Toutes les passerelles régionales continuent de fonctionner normalement pendant le processus de migration.

  • Puis-je mettre à niveau mon instance stv1 vers le même sous-réseau ?

    Oui, utilisez le panneau Migration de plateforme dans le portail ou utilisez l’API REST Migrer vers stv2.

  • Puis-je tester la nouvelle passerelle dans un nouveau sous-réseau avant de basculer le trafic en direct ?

    • Quand vous migrez vers un nouveau sous-réseau, par défaut, l’ancienne passerelle managée et la nouvelle passerelle managée coexistent pendant 15 minutes, ce qui est une petite fenêtre de temps pour valider le déploiement. Vous pouvez activer un paramètre de migration pour conserver l’ancienne passerelle pendant 48 heures. Cette modification conserve l’ancienne et les nouvelles passerelles managées actives pour recevoir le trafic et faciliter la validation.
    • Le processus de migration met automatiquement à jour les noms de domaine par défaut et, s’il est utilisé, le trafic est routé immédiatement vers les nouvelles passerelles.
    • Si des noms de domaine personnalisés sont utilisés, les enregistrements DNS correspondants doivent peut-être être mis à jour avec la nouvelle adresse IP si vous n’utilisez pas CNAME. Les clients peuvent mettre à jour leur fichier hôtes vers la nouvelle IP de Gestion des API et valider l’instance avant d’effectuer le basculement. Pendant ce processus de validation, l’ancienne passerelle continue de servir le trafic en direct.

  • Quels sont les points à prendre en compte lors de l’utilisation d’un nom de domaine par défaut dans un nouveau sous-réseau ?

    Pour les instances qui utilisent le nom DNS par défaut en mode externe, le DNS est mis à jour automatiquement par le processus de migration. De plus, le point de terminaison de gestion, qui utilise toujours le nom de domaine par défaut, est automatiquement mis à jour par le processus de migration. Comme le basculement se produit immédiatement en cas de migration réussie, la nouvelle instance commence à recevoir le trafic immédiatement, et il est essentiel que toutes les restrictions/dépendances réseau soient traitées en avance pour éviter que les API impactées ne soient pas disponibles.

  • Quels sont les points à prendre en compte pour les passerelles auto-hébergées ?

    Vous n’avez pas besoin de faire quoi que ce soit dans vos passerelles auto-hébergées. Vous devez simplement migrer les instances Gestion des API qui s’exécutent dans Azure et sont impactées par la mise hors service de la plateforme stv1. Notez qu’il peut y avoir une nouvelle IP pour le point de terminaison de configuration de l’instance Gestion des API, et toutes les restrictions réseau épinglées à l’IP doivent être mises à jour.

  • Comment le portail des développeurs est-il impacté par la migration ?

    Il n’y a aucun impact sur le portail des développeurs. Si des domaines personnalisés sont utilisés, l’enregistrement DNS doit être mis à jour avec l’IP effective, après la migration. Toutefois, si les domaines par défaut sont utilisés, ils sont automatiquement mis à jour quand la migration est réussie. Il n’y a aucun temps d’arrêt pour le portail des développeurs pendant la migration.

  • Y a-t-il un impact sur le coût après la migration vers stv2 ?

    Le modèle de facturation reste le même pour stv2 et aucun coût supplémentaire n’est facturé pendant et après la migration.

  • Quelles sont les autorisations RBAC requises pour la migration stv1 vers stv2 ?

    L’utilisateur ou le processus qui effectue la migration a besoin d’un accès en écriture à l’instance Gestion des API. En outre, les deux autorisations suivantes sont requises :

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

Contenu connexe