Migrer les services cloud Azure (classiques) vers les services cloud Azure (support étendu)

Article
07/24/2024

Ce document fournit une vue d’ensemble de la migration de Cloud Services (classique) vers Cloud Services (support étendu).

Azure Cloud Services (support étendu) a pour principal avantage de fournir une résilience régionale ainsi qu’une parité des fonctionnalités avec Azure Cloud Services déployé à l’aide d’Azure Service Manager. Il offre également certaines fonctionnalités Azure Resource Manager telles que le contrôle d’accès en fonction du rôle (RBAC), les balises, la stratégie et prend en charge les modèles de déploiement et les liaisons privées. Les deux modèles de déploiement (support étendu et classique) sont disponibles avec des structures de tarification similaires.

Azure Cloud Services (support étendu) offre deux possibilités aux clients pour migrer d’Azure Service Manager vers Azure Resource Manager : le redéploiement et la migration sur place.

Le tableau ci-dessous met en évidence les comparaisons entre ces deux options.

Redeploy	Migration sur place
Les clients peuvent déployer un nouveau service cloud directement dans Azure Resource Manager, puis supprimer l’ancien service cloud dans Azure Service Manager après la validation.	L’outil de migration sur place permet une migration transparente orchestrée via la plateforme des déploiements Cloud Services (classique) existants vers Cloud Services (support étendu).
Le redéploiement permet aux clients d’effectuer les opérations suivantes : - Définir des noms de ressources. - Organiser ou réutiliser les ressources en fonction des besoins. - Réutiliser la configuration du service et les fichiers de définition avec des modifications minimes.	Pour la migration sur place, la plateforme : - Définit les noms des ressources. - Organise chaque déploiement et les ressources associées dans des groupes de ressources individuels. - Modifie le fichier de définition et de configuration existant pour Azure Resource Manager.
Les clients doivent orchestrer le trafic vers le nouveau déploiement.	La migration conserve l’adresse IP et le chemin d’accès aux données reste inchangé.
Les clients doivent supprimer les anciens services cloud dans Azure Resource Manager.	La plateforme supprime les ressources Cloud Services (classique) après la migration.
Cette migration est un scénario de type lift-and-shift, qui offre plus de flexibilité, mais nécessite plus de temps.	Ce scénario est une migration automatisée qui offre la rapidité, mais moins de flexibilité.

Lors de l’évaluation des plans de migration de Cloud Services (classique) vers Cloud Services (support étendu), vous pouvez examiner d’autres services Azure, tels que : Virtual Machine Scale Sets, App Service, Azure Kubernetes Service et Azure Service Fabric. Ces services continuent d’offrir d’autres capacités, tandis que Cloud Services (support étendu) conserve principalement la parité des fonctionnalités avec Cloud Services (classique).

En fonction de l’application, Azure Cloud Services (support étendu) peut nécessiter beaucoup moins d’efforts pour passer à Azure Resource Manager par rapport à d’autres options. Si votre application n’évolue pas, Cloud Services (support étendu) est une option viable à prendre en compte, car elle fournit un chemin de migration rapide. À l’inverse, si votre application évolue en permanence et a besoin d’un ensemble de fonctionnalités plus moderne, explorez d’autres services Azure pour mieux répondre à vos besoins actuels et futurs.

Présentation du redéploiement

Le redéploiement de vos services avec Cloud Services (support étendu) offre les avantages suivants :

Prend en charge les rôles web et de travail, comme [Cloud Services (classique).
Il n’y a pas de changement dans la conception, l’architecture ou les composants des rôles de travail et web.
Aucune modification n’est requise pour le code du runtime, car le plan de données est identique aux services cloud.
Les versions du système d’exploitation invité Azure et les mises à jour associées sont alignées sur Cloud Services (classique).
Le processus de mise à jour sous-jacent en ce qui concerne les domaines de mise à jour, la procédure de mise à niveau, la restauration et les changements de service autorisés pendant une mise à jour restent inchangés.

Un nouveau service cloud (support étendu) peut être déployé directement dans Azure Resource Manager à l’aide des outils clients suivants :

Présentation de l’outil de migration

La migration prise en charge par la plateforme offre les principaux avantages suivants :

Permet une migration fluide orchestrée par une plateforme sans temps d’arrêt pour la plupart des scénarios. Apprenez-en davantage sur les scénarios pris en charge.
Migre les services cloud actuels en trois étapes simples : valider, préparer, valider (ou abandonner). En savoir plus sur le fonctionnement de l’outil de migration.
Propose des tests pour les déploiements migrés après la préparation réussie. Valide et finalise la migration alors que la fonction d’abandon restaure la migration.

L’outil de migration utilise les mêmes API et a la même expérience que la migration des machines virtuelles (classiques).

Configurer l’accès pour la migration

Pour effectuer cette migration, vous devez être ajouté en tant que coadministrateur de l’abonnement et inscrire les fournisseurs nécessaires.

Connectez-vous au portail Azure.
Dans le menu Hub, sélectionnez Abonnement. Si vous ne le voyez pas, sélectionnez Tous les services.
Recherchez l’entrée d’abonnement appropriée, puis examinez le champ MON RÔLE. Pour un coadministrateur, la valeur doit être Administrateur de compte. Si vous n’êtes pas en mesure d’ajouter un coadministrateur, contactez un administrateur de services fédérés ou un coadministrateur de l’abonnement afin qu’il vous ajoute.
Inscrire votre abonnement pour l’espace de noms Microsoft.ClassicInfrastructureMigrate à l’aide du Portail, de PowerShell ou de l’interface CLI
```
Register-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate 
```
Vérifiez l’état de votre inscription. L’inscription peut prendre quelques minutes.
```
Get-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate 
```

En quoi la migration des services cloud (classiques) est-elle différente de celle des machines virtuelles (classiques) ?

Azure Service Manager prend en charge deux produits de calcul différents : Machines virtuelles Azure (classiques) et Azure Cloud Services (classique) ou des rôles de travail/web. Les deux produits varient en fonction du type de déploiement qui se trouve dans le service cloud. L’offre Azure Cloud Services (classique) utilise le service cloud contenant des déploiements avec des rôles web/de travail. L’offre Machines virtuelles Azure (classique) utilise un service cloud contenant des déploiements avec des machines virtuelles IaaS.

La liste des scénarios pris en charge diffère entre les services cloud (classiques) et les machines virtuelles (classiques) en raison de différences dans les types de déploiement.

Étapes de la migration

Les clients peuvent migrer leurs déploiements de services cloud (classiques) à l’aide des quatre opérations utilisées pour migrer des machines virtuelles (classiques).

Valider la migration : valide que les scénarios non pris en charge courants n’empêchent pas la migration.
Préparer la migration : duplique les métadonnées de la ressource dans Azure Resource Manager. Toutes les ressources sont verrouillées pour les opérations de création/mise à jour/suppression afin de garantir la synchronisation des métadonnées des ressources sur Azure Server Manager et Azure Resource Manager. Toutes les opérations de lecture fonctionnent avec les API Cloud Services (classique) et Cloud Services (support étendu).
Abandonner la migration : supprime les métadonnées de ressources d’Azure Resource Manager. Déverrouille toutes les ressources pour les opérations de création/mise à jour/suppression.
Valider la migration : supprime les métadonnées de ressources d’Azure Service Manager. Déverrouille les ressources pour les opérations de création/mise à jour/suppression. L’abandon n’est plus autorisé après les tentatives de validation.

Remarque

Les opérations de préparation, d’abandon et de validation sont idempotentes et, par conséquent, en cas d’échec, une nouvelle tentative doit résoudre le problème.

L’image présente le schéma des étapes associées à la migration.

Pour plus d’informations sur la migration, consultez Migration prise en charge par la plateforme de ressources IaaS Classic vers Azure Resource Manager.

Ressources et fonctionnalités prises en charge disponibles pour la migration associée à Cloud Services (classique)

Comptes de stockage
Réseaux virtuels (Azure Batch non pris en charge)
Network Security Group
Adresses IP publiques réservées
Listes de contrôle d’accès par point de terminaison
Itinéraires définis par l’utilisateur
Équilibreur de charge interne
Migration de certificat vers un coffre de clés
Plug-ins et extension (basés sur XML et JSON)
Tâches Au démarrage/À l’arrêt
Déploiements avec performances réseau accélérées
Déploiements utilisant un ou plusieurs rôles
Équilibreur de charge de base
Entrée, entrée d’instance, points de terminaison internes
Adresses IP publiques dynamiques
Nom DNS
Règles de trafic réseau

Configurations/scénarios de migration pris en charge

La liste suivante contient les principaux scénarios impliquant des combinaisons de ressources, de fonctionnalités et de services cloud. Cette liste n’est pas exhaustive.

Service	Configuration	Commentaires
Microsoft Entra Domain Services	Réseaux virtuels contenant Microsoft Entra Domain Services	Un réseau virtuel contenant à la fois un déploiement de service cloud et Microsoft Entra Domain Services est pris en charge. Le client doit d’abord migrer séparément Microsoft Entra Domain Services, puis migrer le réseau virtuel vers la gauche uniquement avec le déploiement du service cloud
Service cloud	Service cloud avec un déploiement dans un seul emplacement uniquement.	Les services Cloud contenant un déploiement d’emplacement de production peuvent être migrés. Il n’est pas recommandé de migrer l’emplacement de préproduction, car cela peut entraîner des problèmes de conservation du nom de domaine complet du service. Pour migrer l’emplacement de préproduction, commencez par mettre le déploiement de préproduction en production, puis effectuez la migration vers Azure Resource Manager.
Service cloud	Déploiement qui ne s’effectue pas dans un réseau virtuel visible publiquement (déploiement de réseau virtuel par défaut)	Un service cloud peut être dans un réseau virtuel visible publiquement, dans un réseau virtuel masqué ou peut ne pas être situé dans un réseau virtuel. Les services cloud dans un réseau virtuel masqué et les réseaux virtuels visibles publiquement sont pris en charge pour la migration. Le client peut utiliser l’API Validate pour déterminer si un déploiement est à l’intérieur d’un réseau virtuel par défaut ou non et, par conséquent, déterminer s’il peut être migré.
Service cloud	Extensions XML (BGInfo, débogueur Visual Studio, Web Deploy et débogage à distance).	Toutes les extensions XML sont prises en charge pour la migration
Réseau virtuel	Réseau virtuel contenant plusieurs services cloud.	Un réseau virtuel contenant plusieurs services cloud est pris en charge pour la migration. Le réseau virtuel et tous les services cloud qu’il contient sont migrés ensemble vers Azure Resource Manager.
Réseau virtuel	Migration de réseaux virtuels créés via le portail (nécessite l’utilisation de « Group Resource-group-name VNet-Name » dans le fichier .cscfg)	Dans le cadre de la migration, le nom du réseau virtuel dans cscfg est modifié de façon à utiliser l’ID Azure Resource Manager du réseau virtuel. (subscription/subscription-id/resource-group/resource-group-name/resource/vnet-name) Pour gérer le déploiement après la migration, mettez à jour la copie locale du fichier .cscfg pour qu’il commence à utiliser l’ID Azure Resource Manager au lieu du nom de réseau virtuel. Un fichier .cscfg qui utilise l’ancien schéma d’affectation de noms échoue à la validation.
Réseau virtuel	Migration de déploiement avec des rôles dans un sous-réseau différent.	Un service avec différents rôles dans différents sous-réseaux est pris en charge pour la migration.

Étapes suivantes

Vue d’ensemble de la migration prise en charge par la plateforme de ressources IaaS Classic vers Azure Resource Manager
Migrer vers Cloud Services (support étendu) à l’aide du portail Azure
Migrer vers Cloud Services (support étendu) à l’aide de PowerShell

Partager via