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

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. Pour ce scénario, migrez votre instance en mettant à jour les paramètres de configuration du réseau VNet. Déterminez si vous avez besoin de le faire.

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 instance de la Gestion des API hébergées sur la plateforme stv1 sera mise hors service le 31 août 2024. Si certaines de vos instances sont hébergées sur la plateforme stv1, migrez-les vers la plateforme stv2 avant cette date pour éviter les interruptions de service. Plus d’informations

Attention

• La migration de votre instance Gestion des API vers la plateforme stv2 est une opération de longue durée.
• L’adresse IP virtuelle de votre instance sera modifiée. 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. Planifiez votre migration en conséquence.
• 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.
• L’état de Gestion des API dans le Portail Microsoft Azure est Mise à jour.
• L'adresse IP virtuelle (ou les adresses, dans le cas d'un déploiement multi-régional) de l'instance sera modifiée.
• Azure gère le DNS du point de terminaison de gestion et fait la mise à jour vers le nouveau calcul immédiatement après 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 environ 15 minutes par défaut. 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

• Une instance Gestion des API hébergée sur la plateforme de calcul stv1. Pour vérifier que votre instance est bien hébergée sur la plateforme stv1, consultez Comment faire pour savoir quelle plateforme héberge mon instance Gestion des API ? L’instance doit être injectée dans un réseau virtuel.

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

  • À compter de mai 2024, une adresse IP publique n’est plus nécessaire lors du déploiement (injection) d’une instance Gestion des API dans un réseau virtuel en mode interne ou de la migration de la configuration du 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 ne fournissez pas d’adresse IP publique, une adresse IP publique gérée par Azure est automatiquement configurée. En mode réseau virtuel externe, l’adresse IP publique est utilisée pour le trafic d’API de runtime.
  • Actuellement, si vous activez la redondance de zone pour une instance Gestion des API dans un réseau virtuel en mode interne ou en mode externe, vous devez spécifier une nouvelle adresse IP publique.

Déclencher la migration d’une instance Gestion des API injectée dans un réseau

Déclenchez la migration vers la plateforme stv2 d’une instance Gestion des API injectée dans un réseau en mettant à jour la configuration réseau existante pour utiliser de nouveaux paramètres de réseau dans chaque région où l’instance est déployée. Une fois cette mise à jour terminée vous pouvez migrer de nouveau vers les réseaux virtuels et les sous-réseaux d’origine que vous avez utilisés.

Vous pouvez également migrer vers la plateforme stv2 en activant la redondance de zone, disponible dans le niveau Premium.

Important

L’adresse ou les adresses IP virtuelle(s) de votre instance de Gestion des API seront modifiées. Toutefois, 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 appairés pour utiliser la ou les nouvelles adresses IP virtuelles.

Mettre à jour la configuration du réseau

Vous pouvez utiliser le Portail Azure pour migrer vers un nouveau sous-réseau dans le même réseau virtuel ou un autre réseau virtuel. 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.

Portail

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. Sur la page Migration de la plateforme, à l’étape 1, passez en revue les exigences de migration et les prérequis.

4. À l’étape 2, choisissez les paramètres de migration :

   • Sélectionnez un emplacement à migrer.

   • Sélectionnez le réseau virtuel, le sous-réseau et l’adresse IP publique facultative vers lesquels vous souhaitez migrer.

     

   • Sélectionnez Revenir au sous-réseau d’origine dès que possible ou Rester dans le nouveau sous-réseau et conservez le calcul stv1 pendant 48 heures après la migration. Si vous choisissez la première option, le calcul stv1 est supprimé environ 15 minutes après la migration, ce qui vous permet de procéder directement à la migration vers le sous-réseau d’origine si vous le souhaitez. Si vous choisissez la deuxième option, le calcul stv1 est conservé pendant 48 heures. Vous pouvez utiliser cette période pour valider vos paramètres réseau et votre connectivité.

     

5. À l’étape 3, confirmez que vous souhaitez migrer, 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

Vous pouvez éventuellement revenir au sous-réseau d’origine que vous avez utilisés dans chaque région avant la migration vers la plateforme stv2. 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.

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

  • À compter de mai 2024, une adresse IP publique n’est plus nécessaire lors du déploiement (injection) d’une instance Gestion des API dans un réseau virtuel en mode interne ou de la migration de la configuration du 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 ne fournissez pas d’adresse IP publique, une adresse IP publique gérée par Azure est automatiquement configurée. En mode réseau virtuel externe, l’adresse IP publique est utilisée pour le trafic d’API de runtime.
  • Actuellement, si vous activez la redondance de zone pour une instance Gestion des API dans un réseau virtuel en mode interne ou en mode externe, vous devez spécifier une nouvelle adresse IP publique.

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

Après la migration réussie d'une instance de gestion d'API injectée par VNet, l'ancien et le nouveau calcul créés pendant la migration coexistent pendant une courte période, environ 15 minutes, ce qui constitue une petite fenêtre de temps que vous pouvez utiliser pour valider le déploiement et vous assurer que vos applications fonctionnent comme prévu. (Cette fenêtre peut être étendue à 48 heures en contactant le support Azure à l’avance.)

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

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 dans un réseau virtuel, vous avez besoin d’un nouveau sous-réseau pour la migration dans chaque réseau virtuel (mode externe ou interne). En mode externe, fournissez éventuellement une ressource d’adresse IP publique. Le sous-réseau doit avoir un NSG attaché conformément aux règles de la plateforme stv2, comme décrit ici.

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

  Étant donné que l’ancienne passerelle est vidée uniquement après que le nouveau calcul est sain et en ligne, il ne doit y avoir aucun temps d’arrêt si les noms d’hôte par défaut sont en cours d’utilisation. 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 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 avez créés pour la migration conservent la configuration suivante (doivent déjà être configurés dans 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 changeant les configurations de sous-réseau dans le panneau Migration de la plateforme.

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

  Il n’existe aucun moyen de conserver l’adresse IP si votre instance est injectée dans un VNet.

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

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

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

  Vous pouvez déployer une nouvelle instance Gestion des API avec le nouveau réseau virtuel, sous-réseau et éventuellement les nouvelles ressources 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.

  Après la migration réussie d'un service injecté par VNet, il y a une courte période pendant laquelle l'ancienne passerelle continue à servir le trafic et vous pouvez confirmer vos paramètres de réseau. Consultez Confirmer les paramètres avant que l'ancienne passerelle ne soit purgée

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

  Avec les instances injectées par VNet dans un mode interne, vous devez mettre à jour les zones DNS privées vers la nouvelle adresse IP du VNet 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. Migrez chaque emplacement séparément en mettant à jour les paramètres réseau correspondants, par exemple, à l’aide du panneau Migration de la plateforme. 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 ?

  • Vous ne pouvez pas migrer l’instance stv1 vers le même sous-réseau en une fois sans temps d’arrêt. Toutefois, vous pouvez éventuellement déplacer votre instance migrée vers le sous-réseau d’origine. Plus de détails ici.
  • L’ancienne passerelle prend entre 15 minutes et 45 minutes pour quitter le sous-réseau, afin que vous puissiez lancer le déplacement. Toutefois, vous pouvez activer un paramètre de migration pour conserver l’ancienne passerelle pendant 48 heures.
  • Vérifiez que le réseau de l’ancien sous-réseau du NSG et du pare-feu est mis à jour pour les dépendances stv2.
  • L'attribution d'adresses IP de sous-réseau n'est pas déterministe. Par conséquent, l'adresse IP ILB (entrée) d'origine pour les déploiements en « mode interne » peut changer lorsque vous revenez au sous-réseau d'origine. Cela nécessiterait une modification du DNS si vous utilisez des enregistrements A.

• Puis-je tester la nouvelle passerelle avant de basculer le trafic en direct ?

  • Par défaut, l’ancienne 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 en cas d’utilisation du nom de domaine par défaut ?

  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

Vidéo

Contenu connexe

• Comment savoir quelle plateforme héberge mon instance de Gestion des API ?

• Les avantages de la plateforme de calcul stv2 pour Gestion des API

• En savoir plus sur la mise hors service de la plateforme stv1 en août 2024