Réhéberger une application locale en la migrant vers des machines virtuelles Azure et Azure SQL Managed Instance

  • Article
  • 30 minutes pour lire

Cet article explique comment la société fictive Contoso migre une application frontale basée sur Windows .NET à deux niveaux s’exécutant sur des machines virtuelles VMware vers une machine virtuelle Azure en utilisant Azure Migrate. L’article explique également la façon dont Contoso migre la base de données de l’application vers Azure SQL Managed Instance. Cette migration suit les préparatifs décrits dans Déployer une infrastructure de migration.

L’application SmartHotel360 utilisée dans cet exemple est un logiciel open source. Si vous souhaitez l’utiliser à des fins de test, téléchargez-la à partir de GitHub.

Notes

L’exemple d’application de cet article, SmartHotel360, est archivé, mais reste disponible sur GitHub à titre de référence.

Axes stratégiques

L’équipe informatique de direction chez Contoso a travaillé en étroite collaboration avec des partenaires commerciaux pour comprendre l’objectif de cette migration. Ils veulent réaliser les objectifs suivants :

  • Répondre à la croissance de l’entreprise. Contoso se développe. Il en découle une pression accrue sur l’infrastructure et les systèmes locaux et de l’entreprise.

  • Gagner en efficacité. Contoso doit supprimer les procédures inutiles et rationaliser les processus pour ses développeurs et ses utilisateurs. Pour que l’entreprise réponde rapidement aux besoins des clients, son équipe informatique doit être rapide et ne pas perdre de temps ou d’argent.

  • Gagner en agilité. Le service informatique doit être plus réactif face aux besoins de l’entreprise. Elle doit réagir plus rapidement que l’évolution du marché pour réussir dans une économie mondiale. L’informatique chez Contoso ne doit pas devenir une entrave à l’activité.

  • Adaptation. À mesure que l’entreprise croît, le service informatique doit fournir des systèmes capables de croître au même rythme.

Objectifs de la migration

Contoso utilise des objectifs de migration pour déterminer la meilleure méthode de migration. L’équipe cloud de Contoso a identité les objectifs de cette migration :

  • Performances d’application égales. Après la migration, l’application dans Azure devrait offrir les mêmes performances qu’aujourd’hui dans l’environnement VMware local de Contoso. Migrer l’application vers le cloud ne signifie nullement que ses performances deviennent moins critiques.

  • Pas de développement d’applications. Contoso ne souhaite pas investir dans l’application. Elle est vitale pour l’entreprise mais, dans sa forme actuelle, le seul objectif est de la migrer vers le cloud.

  • Administration minimale. Une fois l’application migrée, les tâches d’administration de base de données sont réduites au minimum.

  • Évitez Azure SQL Database. Contoso ne souhaite pas utiliser Azure SQL Database pour cette application et recherche des alternatives.

Conception de la solution

Après avoir clarifié les objectifs et les contraintes de l’entreprise, Contoso conçoit et révise une solution de déploiement. Contoso identifie également le processus de migration et les services Azure à utiliser.

Architecture actuelle

  • Contoso dispose d’un centre de données principal, contoso-datacenter, qui se trouve à New York. Il dispose d’une connexion de fibre optique à Internet à partir de Metro Ethernet Networks qui fournit 500 mégabits par seconde. Le centre de données principal est entièrement virtualisé avec des produits VMware. Contoso dispose de deux hôtes de virtualisation VMware exécutant ESXi 6.5 gérés par vCenter Server 6.5.

  • Contoso a trois branches aux États-Unis. Chaque branche est connectée localement à Internet par le biais de connexions de qualité professionnelle, et chaque branche est connectée au centre de données principal. Cette configuration permet au réseau entier d’être toujours connecté, et elle optimise la connectivité Internet.

  • Contoso utilise des serveurs DNS sur son réseau interne.

  • Contoso utilise Active Directory pour la gestion d’identité.

  • Contoso a un contrôleur de domaine local, contosodc1. Les contrôleurs de domaine au niveau des branches locales s’exécutent sur des serveurs physiques. Les contrôleurs de domaine s’exécutent sur des machines virtuelles VMware. L’environnement VMware est géré par vCenter Server 6.5, vcenter.contoso.com, s’exécutant sur une machine virtuelle.

  • L’application SmartHotel360 est hiérarchisée sur deux machines virtuelles, WEBVM et SQLVM hébergées sur un hôte VMware ESXi version 6.5, contosohost1.contoso.com.

Diagramme de l’architecture actuelle de Contoso.

Architecture proposée

Dans ce scénario, Contoso migre son application de voyage locale à deux niveaux de la façon suivante :

  • Migration de la base de données de l’application, SmartHotelDB, vers une instance managée SQL.
  • Migration du front-end, WEBVM, vers une machine virtuelle Azure.
  • Désaffectez les machines virtuelles locales dans le centre de données Contoso une fois la migration terminée.

Diagramme de l’architecture du scénario.

Considérations liées à la base de données

Dans le cadre de la conception de la solution, Contoso compare les fonctionnalités d’Azure SQL Database et de SQL Managed Instance. L’entreprise choisit SQL Managed Instances en raison des considérations suivantes :

  • Compatibilité avec les logiciels existants.

    • Le service SQL Managed Instance vise à offrir une compatibilité de quasi 100 % avec la dernière version locale de SQL Server. Nous recommandons le service SQL Managed Instance aux clients qui exécutent SQL Server localement ou sur des machines virtuelles IaaS (infrastructure as a service) et qui souhaitent migrer leurs applications vers un service entièrement managé en changeant le moins possible la conception. Pour plus d’informations, consultez Présentation d’Azure SQL Managed Instance

    • Contoso compte migrer un grand nombre d’applications des machines virtuelles locales vers IaaS. Beaucoup de ces applications sont fournies par un ISV. Contoso se rend compte que SQL Managed Instance peut garantir une compatibilité de base de données pour ces applications. En revanche, SQL Database peut ne pas être pris en charge.

    • SQL Managed Instance prend en charge SQL Server Agent, qui est un composant essentiel pour SmartHotel360. Sans cette compatibilité, Contoso devrait reconcevoir les plans de maintenance requis par l’application.

  • Échange de licences. Avec Software Assurance, Contoso peut échanger ses licences existantes contre une réduction de tarif sur une instance managée SQL en utilisant Azure Hybrid Benefit pour SQL Server. Pour cette raison, Contoso peut économiser jusqu’à 30 % sur SQL Managed Instance.

  • Technologie de sécurité et isolation réseau.

    • Le service SQL Managed Instance prend en charge de nombreuses fonctionnalités de sécurité, dont le chiffrement permanent, le masquage dynamique des données, la sécurité au niveau des lignes et la détection des menaces.

    • SQL Managed Instance est entièrement contenu dans le réseau virtuel ; il fournit donc une isolation et une sécurité accrues pour les données de Contoso. Contoso peut bénéficier des avantages du cloud public tout en maintenant l’environnement isolé de l’Internet public.

  • Migration automatisée. Contoso peut effectuer une migration vers SQL Managed Instance à l’aide du service Azure Database Migration Service complètement automatisé. Une fois ce service en place, Contoso peut le réutiliser pour les futures migrations de base de données.

Examen de la solution

Contoso évalue la conception proposée en dressant la liste des avantages et des inconvénients.

Considération Détails
Avantages Controso peut déplacer WEBVM vers Azure sans changement, ce qui simplifie la migration.

SQL Managed Instance prend en charge les spécifications techniques et les objectifs de Contoso.

SQL Managed Instance offre une compatibilité de 100 % avec le déploiement actuel de Contoso, tout en permettant à l’entreprise de ne plus utiliser SQL Server 2008 R2.

Contoso peut tirer parti de son investissement dans Software Assurance et utiliser Azure Hybrid Benefit pour SQL Server et Windows Server.

Contoso peut réutiliser Azure Database Migration Service pour d’autres migrations futures.

SQL Managed Instance intègre une tolérance de panne que Contoso n’a pas besoin de configurer. Cette fonctionnalité signifie que la couche Données n’est plus un point de défaillance unique.
Inconvénients WEBVM exécute Windows Server 2008 R2. Bien que ce système d’exploitation soit pris en charge par Azure, cette plateforme n’est plus prise en charge. Pour plus d’informations, consultez Stratégie de prise en charge des produits Microsoft SQL Server.

La couche web reste un point unique de basculement et seule la machine WEBVM fournit les services.

Contoso devra continuer à prendre en charge la couche web de l’application en tant que machine virtuelle au lieu d’opter pour un service managé tel qu’Azure App Service.

Pour la couche Données, le service SQL Managed Instance n’est peut-être pas la meilleure solution si Contoso veut personnaliser le système d’exploitation ou le serveur de base de données, ou si l’entreprise veut exécuter des applications tierces avec SQL Server. L’exécution de SQL Server sur une machine virtuelle IaaS peut apporter cette flexibilité.

Processus de migration

Contoso migre les couchez web et Données de son application SmartHotel360 vers Azure en effectuant procédant comme suit :

  1. Ajoutez quelques composants spécifiques à l’infrastructure Azure configurée précédemment par Contoso (comme décrit dans Déployer une infrastructure de migration). Une grande partie de l’infrastructure requise pour cette migration est déjà en place.

  2. Migrez la base de données à l’aide d’Azure Database Migration Service. Le service se connecte à la machine virtuelle locale exécutant SQL Server par le biais d’une connexion VPN site à site entre le centre de données de Contoso et Azure. Le service migre ensuite la base de données.

  3. Migrez la couche web à l’aide d’Azure Migrate. Ce processus nécessite la préparation de l’environnement VMware local, la configuration et l’activation de la réplication, et la migration des machines virtuelles par leur basculement vers Azure.

    Diagramme de l’architecture de la migration.

Services Azure

Service Description Coût
Azure Database Migration Service Azure Database Migration Service permet une migration fluide à partir de plusieurs sources de base de données vers des plateformes de données Azure, avec un temps d’arrêt minimal. Apprenez-en davantage sur les régions prises en charge et sur la tarification de Azure Database Migration Service.
Azure SQL Managed Instance SQL Managed Instance est un service de base de données managé qui représente une instance de SQL Server entièrement managée dans le cloud Azure. Il utilise le même code que la dernière version du moteur de base de données SQL Server et offre les dernières fonctionnalités, améliorations en termes de performances et correctifs de sécurité. L’utilisation d’une instance managée SQL exécutée dans Azure entraîne des frais basés sur la capacité. Apprenez-en davantage sur la tarification du service SQL Managed Instance.
Azure Migrate Contoso utilise Azure Migrate pour évaluer ses machines virtuelles VMware. Azure Migrate évalue la pertinence de la migration des ordinateurs. Il fournit des estimations de dimensionnement et de coût pour l’exécution des machines dans Azure. Azure Migrate est disponible sans coût supplémentaire. Il se peut que l’entreprise ait des frais à payer en fonction des outils (internes ou de fournisseur de logiciel indépendant) qu’elle décide d’utiliser pour l’évaluation et la migration. Apprenez-en davantage sur la tarification Azure Migrate.

Prérequis

Contoso et les autres utilisateurs doivent respecter les prérequis suivants pour ce scénario.

Spécifications Détails
Abonnement Azure Contoso a créé un abonnement dans le premier article de cette série. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit.

Si vous créez un compte gratuit, vous êtes l’administrateur de votre abonnement et pouvez effectuer toutes les actions.

Si vous utilisez un abonnement existant et que vous n’êtes pas l’administrateur de l’abonnement, collaborez avec l’administrateur pour qu’il vous donne les autorisations Propriétaire ou Contributeur aux ressources et aux groupes de ressources nécessaires.
Infrastructure Azure Contoso a configuré son infrastructure Azure comme décrit dans Infrastructure Azure pour la migration.
Serveurs locaux Le serveur vCenter Server local doit exécuter la version 5.5, 6.0 ou 6.5.

Un hôte ESXi doit exécuter la version 5.5, 6.0 ou 6.5.

L’hôte ESXi doit exécuter une ou plusieurs machines virtuelles VMware.
Machines virtuelles locales Examinez les machines Linux approuvées pour s’exécuter sur Azure.
Database Migration Service Pour le service Azure Database Migration Service, vous avez besoin d’un périphérique VPN local compatible.

Vous devez être en mesure de configurer l’appareil VPN local. Il doit avoir une adresse IPv4 publique externe. L’adresse ne peut pas se trouver derrière un périphérique NAT.

Assurez-vous de disposer de l’accès à votre base de données SQL Server locale.

Le Pare-feu Windows doit pouvoir accéder au moteur de base de données source. Pour plus d’informations, consultez Configurer un pare-feu Windows pour accéder au moteur de base de données.

S’il y a un pare-feu devant votre machine de base de données, ajoutez des règles pour autoriser l’accès à la base de données, et aux fichiers par le biais du port SMB 445.

Les informations d’identification utilisées pour se connecter à l’instance SQL Server source et qui ciblent l’instance SQL Managed Instance cible doivent appartenir au rôle serveur sysadmin.

Vous devez disposer d’un partage réseau dans votre base de données locale, que le service Azure Database Migration Service puisse utiliser pour sauvegarder la base de données source.

Vérifiez que le compte de service qui exécute l’instance source de SQL Server dispose d’autorisations d’écriture sur le partage réseau.

Notez l’utilisateur Windows, et son mot de passe, qui dispose d’autorisations complètes sur le partage réseau. Le service Azure Database Migration Service emprunte ces informations d’identification pour charger les fichiers de sauvegarde sur le conteneur de Stockage Azure.

Le processus d’installation SQL Server Express définit le protocole TCP/IP sur Désactivé par défaut. Vérifiez qu’il est défini sur Activé.

Étapes du scénario

Voici comment Contoso prévoie de configurer le déploiement :

  • Étape 1 : Préparer une instance managée SQL. Contoso a besoin d’une instance managée existante vers laquelle la base de données SQL Server locale migrera.

  • Étape 2 : Préparer le service Azure Database Migration Service. Contoso doit inscrire le fournisseur de migration de base de données, créer une instance, puis créer un projet Database Migration Service. Contoso doit également configurer un URI de signature d’accès partagé (URI SAP) pour l’instance Database Migration Service. Un URI SAS fournit un accès délégué aux ressources du compte de stockage Contoso. Ainsi, Contoso peut accorder des autorisations limitées aux objets de stockage. Contoso configure un URI SAS afin qu’Azure Database Migration Service puisse accéder au conteneur du compte de stockage sur lequel le service charge les fichiers de sauvegarde SQL Server.

  • Étape 3 : Préparez Azure pour la migration avec l’outil Migration et modernisation. Contoso ajoute cet outil qui fait partie d’Azure Migrate à son projet Azure Migrate. La migration et la modernisation s’appelaient précédemment Migration de serveur Azure Migrate.

  • Étape 4 : Préparer l’instance VMware locale pour l’outil Migration et modernisation. Contoso prépare des comptes pour la découverte de machines virtuelles et prépare également la connexion aux machines virtuelles Azure après migration.

  • Étape 5 : Répliquer les machines virtuelles locales. Contoso configure la réplication et commence à répliquer des machines virtuelles vers Stockage Azure.

  • Étape 6 : Migrer la base de données via le service Azure Database Migration Service. Contoso migre la base de données.

  • Étape 7 : Migrer les machines virtuelles avec l’outil Migration et modernisation. Contoso effectue un test de migration pour vérifier que tout fonctionne correctement, puis opère une migration complète pour déplacer la machine virtuelle vers Azure.

Étape 1 : Préparer une instance managée SQL

Pour configurer une instance managée SQL, Contoso a besoin d’un sous-réseau remplissant les conditions suivantes :

  • Connecte uniquement l’instance managée. Le sous-réseau doit être dédié. Il doit être vide. Il ne doit contenir aucun autre service cloud. Le sous-réseau ne doit pas être un sous-réseau de passerelle. Une fois l’instance managée créée, Contoso ne doit pas ajouter de ressources au sous-réseau.

  • Pas dans un groupe de sécurité réseau. Aucun groupe de sécurité réseau ne doit être associé au sous-réseau.

  • Achemine uniquement vers Internet. Le sous-réseau doit avoir une table de routage définie par l’utilisateur. Le seul itinéraire attribué doit être 0.0.0.0/0 tronçon suivant vers Internet.

  • N’a pas de point de terminaison de service. Le sous-réseau ne doit pas avoir de point de terminaison de service, stockage ou SQL, associé. Les points de terminaison doivent être désactivés sur le réseau virtuel.

  • Possède au moins 16 adresses IP. Le sous-réseau doit avoir un minimum de 16 adresses IP. Pour plus d’informations sur le dimensionnement du sous-réseau pour l’instance managée, consultez Configurer un réseau virtuel existant pour Azure SQL Managed Instance.

  • Avec un DNS personnalisé, inclut un programme de résolution spécifique. Contoso configure la résolution de noms DNS pour utiliser un ou plusieurs des serveurs DNS Azure de l’entreprise. En raison de l’environnement hybride de Contoso, ils doivent également utiliser des paramètres DNS personnalisés. Pour utiliser un DNS personnalisé, Contoso doit ajouter 168.63.129.16, une adresse IP virtuelle, à la liste des résolveurs récursifs dans Azure. Pour plus d’informations sur le DNS personnalisé pour une instance managée, consultez Résoudre les noms de domaine privés dans Azure SQL Managed Instance.

Configurer un réseau virtuel pour l’instance gérée

Pour configurer le réseau virtuel, les administrateurs de Contoso effectuent les étapes suivantes :

  1. Ils créent un réseau virtuel, VNET-SQLMI-EUS2, dans la région primaire, East US 2. Contoso ajoute le réseau virtuel au groupe de ressources ContosoNetworkingRG.

  2. Ils attribuent l’espace d’adressage de 10.235.0.0/24. Contoso vérifie que la plage ne chevauche pas d’autres réseaux au sein de son entreprise.

  3. Ils ajoutent deux sous-réseaux au réseau :

    • SQLMI-DB-EUS2 avec une plage d’adresses de 10.235.0.0/25.
    • SQLMI-SAW-EUS2 avec une plage d’adresses de 10.235.0.128/29. Ce sous-réseau joint un annuaire à l’instance gérée.

    Capture d’écran montrant le volet Créer un réseau virtuel.

  4. Une fois le réseau virtuel et les sous-réseaux déployés, Contoso ajoute le peering réseau comme suit :

    • Jumelez VNET-SQLMI-EUS2 et VNET-HUB-EUS2, qui est le réseau virtuel hub dans East US 2.
    • Jumelez VNET-SQLMI-EUS2 et VNET-PROD-EUS2, qui est le réseau de production.

    Capture d’écran montrant l’appairage des réseaux.

  5. Ils définissent des paramètres DNS personnalisés. Le système DNS pointe tout d’abord sur les contrôleurs de domaine dans Azure de Contoso. Azure DNS est secondaire. Les contrôleurs de domaine de Contoso sont configurés comme suit :

    • Situé dans le sous-réseau PROD-DC-EUS2 dans VNET-PROD-EUS2, le réseau de production dans East US 2.
    • CONTOSODC3 avec l’adresse IP 10.245.42.4.
    • L’adresse CONTOSODC4 avec l’adresse IP 10.245.42.5.
    • Résolveur Azure DNS avec l’adresse IP 168.63.129.16.

    Capture d’écran montrant les serveurs DNS des réseaux.

Besoin de plus d’aide ?

Configuration du routage

Un réseau virtuel privé connecte l’instance managée. Contoso a besoin d’une table de routage pour que le réseau virtuel communique avec le service de gestion Azure. Si le réseau virtuel ne peut pas communiquer avec le service qui le gère, le réseau virtuel devient inaccessible.

Contoso prend en compte ces facteurs :

  • La table de routage contient un ensemble de règles (routes) qui spécifient la manière dont les paquets envoyés à partir de l’instance managée doivent être routés dans le réseau virtuel.
  • Chaque paquet qui quitte un sous-réseau suit l’itinéraire spécifié par la table de routage associée.
  • Un sous-réseau a une seule table de routage associée, mais une table de routage peut spécifier le routage pour plusieurs sous-réseaux.
  • La création de tables de routage dans Microsoft Azure n’occasionne aucun frais.

Pour configurer le routage, les administrateurs Contoso suivent les étapes ci-dessous :

  1. Créez une table de routage définie par l’utilisateur, nommée MIRouteTable, qui est affectée à ContosoNetworkingRG, un groupe de ressources.

    Capture d’écran qui montre la table de routage.

  2. Ajoutez un itinéraire dont le préfixe d’adresse est 0.0.0.0/0. L’option Type de tronçon suivant est définie sur Internet Cette configuration répond aux exigences relatives à SQL Managed Instance.

    Capture d’écran qui montre le préfixe de la table de routage.

  3. Ils associent la table de routage au sous-réseau SQLMI-DB-EUS2, dans le réseau VNET-SQLMI-EUS2.

    Capture d’écran qui montre le sous-réseau de la table de routage.

Besoin de plus d’aide ?

Créer une instance gérée

Une fois le réseau virtuel et la table de routage en place, les administrateurs de Contoso peuvent provisionner une instance managée SQL en effectuant les étapes suivantes :

  1. Comme l’instance gérée sert une application métier, ils la déploient dans la région primaire de l’entreprise, East US 2. Ils ajoutent l’instance gérée au groupe de ressources ContosoRG.

  2. Ils sélectionnent un niveau tarifaire, une taille de calcul et un stockage pour l’instance. Pour plus d’informations sur les coûts, consultez Tarification de SQL Managed Instance.

    Capture d’écran montrant le volet Instance managée SQL.

  3. Avec le déploiement de l’instance managée, ContosoRG inclut deux nouvelles ressources :

    • L’instance SQL Managed Instance.
    • Un cluster virtuel peut prendre en charge plusieurs instances gérées.

    Capture d’écran montrant deux nouvelles ressources

Besoin de plus d’aide ?

Démarrage rapide : Créer une instance gérée SQL Azure.

Étape 2 : Préparer le service Azure Database Migration Service

Pour préparer Azure Database Migration Service, les administrateurs de Contoso doivent effectuer les tâches suivantes :

  • Inscrire le fournisseur Database Migration Service dans Azure.

  • Fournir au service Database Migration Service l’autorisation d’accès à Stockage Azure pour charger les fichiers de sauvegarde utilisés par le service pour migrer une base de données. Pour fournir l’accès au Stockage Azure :

    • Ils créent un conteneur de Stockage Blob Azure.
    • Ils génèrent un URI SAS pour ce conteneur.

  • Créer un projet Azure Database Migration Service.

Les administrateurs Contoso effectuent les étapes suivantes :

  1. Ils inscrivent le fournisseur de migration de base de données sous l’abonnement de Contoso.

    Capture d’écran montrant l’inscription de Database Migration Service.

  2. Ils créent un conteneur de Stockage Blob Azure. Contoso génère un URI SAP afin que le service Azure Database Migration Service puisse y accéder.

    Capture d’écran montrant la génération d’un URI SAS

  3. Créer une instance d’Azure Database Migration Service.

    Capture d’écran montrant la création d’une instance

  4. Ils placent l’instance Database Migration Service dans le sous-réseau PROD-DC-EUS2 du réseau virtuel VNET-PROD-DC-EUS2.

    • L’instance doit être placée dans PROD-DC-EUS2, car le service doit se trouver dans un réseau virtuel pouvant accéder à la machine virtuelle locale exécutant SQL Server via une passerelle VPN.
    • VNET-PROD-EUS2 est appairé à VNET-HUB-EUS2, et est autorisé à utiliser des passerelles distantes. L’autorisation garantit que l’instance peut communiquer si nécessaire. Contoso sélectionne Utiliser des passerelles distantes pour activer cette configuration.

    Capture d’écran montrant la configuration d’un réseau

Besoin de plus d’aide ?

Étape 3 : Préparer Azure pour la migration avec l’outil Migration et modernisation

Pour pouvoir migrer les machines virtuelles, Contoso doit effectuer les tâches suivantes :

  • Créer un réseau virtuel pour les machines virtuelles Azure créées pendant la migration.
  • Provisionner l’outil Migration et modernisation dans le cadre d’Azure Migrate.

Lorsque Contoso a préparé la migration vers Azure dans Déployer une infrastructure de migration, l’entreprise a configuré un réseau que l’outil de migration et de modernisation peut utiliser.

  • SmartHotel360 est une application de production, et les machines virtuelles seront migrées vers le réseau de production Azure, VNET-PROD-EUS2, dans la région primaire, East US 2.
  • ContosoRG, un groupe de ressources pour les ressources de production, comprend les deux machines virtuelles.
  • La machine virtuelle frontale de l’application, WEBVM, migrera vers le sous-réseau frontal ,PROD-FE-EUS2, dans le réseau de production.
  • La machine virtuelle de la base de données de l’application, SQLVM, migrera vers le sous-réseau de base de données ,PROD-DB-EUS2, du réseau de production.

Étape 4 : Préparer l’instance VMware locale pour l’outil Migration et modernisation

Pour migrer les machines virtuelles vers Azure, Contoso doit disposer des composants Azure suivants :

  • Un réseau virtuel pour les machines virtuelles Azure lors de leur création pendant la migration.
  • L’appliance Azure Migrate, approvisionnée et configurée.

Les administrateurs de Contoso configurent ces composants en effectuant ces étapes :

  1. Lorsque Contoso a préparé la migration vers Azure dans Déployer une infrastructure de migration, l’entreprise a configuré un réseau que l’outil de migration et de modernisation peut utiliser.

    • L’application SmartHotel360 est une application de production, et les machines virtuelles seront migrées vers le réseau de production Azure, VNET-PROD-EUS2, dans la région primaire, East US 2.
    • ContosoRG, un groupe de ressources pour les ressources de production, comprend les deux machines virtuelles.
    • La machine virtuelle frontale de l’application, WEBVM, migrera vers le sous-réseau frontal ,PROD-FE-EUS2, dans le réseau de production.
    • La machine virtuelle de la base de données de l’application, SQLVM, migrera vers le sous-réseau de base de données ,PROD-DB-EUS2, du réseau de production.

  2. Approvisionnez l’appliance Azure Migrate.

    1. Depuis Azure Migrate, téléchargez le fichier image .OVA et importez-le dans VMware.

      Capture d’écran montrant le téléchargement du fichier OVA

    2. Démarrez l’image importée et configurez l’outil en effectuant les étapes suivantes :

      1. Remplir les conditions préalables.

        Capture d’écran montrant la configuration des prérequis

      2. Pointez l’outil sur l’abonnement Azure.

        Capture d’écran montrant comment sélectionner l’abonnement

      3. Définissez les informations d’identification de VMware vCenter.

        Capture d’écran montrant la définition des informations d’identification de VMware vCenter

      4. Ajoutez les informations d’identification basées sur Linux ou Windows pour la découverte.

        Capture d’écran montrant la définition des informations d’identification de Linux et Windows

  3. Une fois la configuration effectuée, l’outil met un certain temps à énumérer toutes les machines virtuelles. Une fois que l’outil termine l’énumération, les administrateurs de Contoso peuvent voir les machines virtuelles renseignées dans l’outil Azure Migrate dans Azure.

Besoin de plus d’aide ?

Outil de migration et de modernisation

Préparer des machines virtuelles sur site

Après la migration, Contoso souhaite se connecter aux machines virtuelles Azure et autoriser Azure à gérer les machines virtuelles. Les administrateurs de Contoso doivent effectuer les étapes suivantes avant la migration :

  1. Pour l’accès via Internet :

    • Activez le protocole RDP ou SSH sur la machine virtuelle locale avant la migration.
    • Ajoutez des règles TCP et UDP pour le profil public, si nécessaire.
    • Vérifiez que le pare-feu du système d’exploitation autorise les connexions RDP ou SSH.

  2. Pour l’accès via un VPN site à site :

    • Activez le protocole RDP ou SSH sur la machine virtuelle locale avant la migration.
    • Vérifiez que le pare-feu du système d’exploitation autorise les connexions RDP ou SSH.
    • Pour Windows, définir la stratégie SAN du système d’exploitation sur la machine virtuelle locale sur OnlineAll.

  3. Installer l’agent Azure :

  4. Autres points à considérer :

    • Pour Windows, aucune mise à jour de Windows ne peut être en attente sur la machine virtuelle lors du lancement d’une migration. S’il y a des mises à jour en attente, personne ne peut se connecter à la machine virtuelle tant que Windows n’a pas terminé ses mises à jour.
    • Après migration, un administrateur peut consulter les diagnostics de démarrage pour afficher une capture d’écran de la machine virtuelle. Si cette méthode ne fonctionne pas, un administrateur doit vérifier que la machine virtuelle est en cours d’exécution et de consulter ces conseils de dépannage.

Besoin de plus d’aide ?

Étape 5 : Répliquer les machines virtuelles locales

Avant de migrer des serveurs vers Azure, les administrateurs de Contoso doivent configurer et activer la réplication.

Une fois la découverte terminée, les administrateurs peuvent commencer la réplication des machines virtuelles VMware vers Azure. Ils effectuent les étapes suivantes :

  1. Dans le projet Azure Migrate, accédez à Serveurs>Azure Migrate : Migration de serveur. Sélectionnez ensuite Répliquer.

    Capture d’écran montrant l’option Répliquer.

  2. Dans Répliquer>Paramètres de la source>Vos machines sont-elles virtualisées ? , sélectionnez Oui, avec VMware vSphere.

  3. Dans Appliance locale, sélectionnez le nom de l’appliance Azure Migrate configurée, puis sélectionnez OK.

    Capture d’écran montrant l’onglet Paramètres de la source

  4. Dans Machines virtuelles, sélectionnez les machines à répliquer et choisissez d’importer les paramètres de migration à partir d’une évaluation.

    • Si les administrateurs ont exécuté une évaluation des machines virtuelles, ils peuvent appliquer les recommandations relatives au dimensionnement et au type de disque (Premium/Standard) des machines virtuelles qui apparaissent dans les résultats de l’évaluation. Dans Importer les paramètres de migration à partir d’une évaluation Azure Migrate ?, sélectionnez Oui.
    • Si vos administrateurs n’ont pas exécuté d’évaluation ou ne souhaitez pas utiliser les paramètres de l’évaluation, sélectionnez Non.
    • Si les administrateurs choisissent d’utiliser l’évaluation, sélectionnez le groupe de machines virtuelles et le nom de l’évaluation.

    Capture d’écran montrant la sélection des évaluations.

  5. Dans Machines virtuelles, recherchez les machines virtuelles nécessaires et cochent chaque machine virtuelle à migrer. Ensuite, sélectionnez Next: Paramètres de la cible.

  6. Dans Paramètres cibles, sélectionnez l’abonnement et la région ciblée vers laquelle les machines virtuelles migrent. Spécifiez le groupe de ressources dans lequel résideront les machines virtuelles Azure après la migration. Dans Réseau virtuel, sélectionnez le réseau virtuel/sous-réseau Azure auquel les machines virtuelles Azure sont jointes après la migration.

  7. Dans Azure Hybrid Benefit :

    • Sélectionnez Non pour appliquer Azure Hybrid Benefit.
    • Sélectionnez Oui pour appliquer éventuellement des abonnements Software Assurance ou Windows Server aux machines éligibles exécutant Windows Server.

    Sélectionnez ensuite Suivant.

  8. Dans Calcul, passez en revue les noms, les tailles, les types de disques de système d’exploitation et les groupes à haute disponibilité des machines virtuelles. Elles doivent satisfaire aux exigences d’Azure. Pour plus d’informations, consultez les exigences de VMware dans Matrice de prise en charge de la découverte VMware.

    • Taille de machine virtuelle : Lorsque vous utilisez les recommandations des résultats de l’évaluation, la liste des tailles de machine virtuelle contient la taille recommandée. Sinon, Azure Migrate choisit une taille qui correspond à la taille la plus proche dans l’abonnement Azure. Vous pouvez également choisir une taille manuelle dans Taille de la machine virtuelle Azure.
    • Disque du système d’exploitation : spécifiez le disque du système d’exploitation (démarrage) pour la machine virtuelle. Le disque du système d’exploitation est le disque qui contient le chargeur de démarrage et le programme d’installation du système d’exploitation.
    • Groupe à haute disponibilité : si la machine virtuelle doit se trouver dans un groupe à haute disponibilité Azure après la migration, spécifiez-le ici. Ce groupe doit être dans le groupe de ressources cible spécifié pour la migration.

  9. Dans Disques, indiquez si les disques de machine virtuelle doivent être répliqués sur Azure. Sélectionnez ensuite le type de disque (SSD/HDD Standard ou SSD Premium) dans Azure, puis sélectionnez Suivant.

    • Excluez éventuellement des disques de la réplication.
    • Un disque exclu ne se trouve pas sur la machine virtuelle Azure après la migration.

  10. Dans Réviser + lancer la réplication, passez en revue les paramètres. Sélectionnez ensuite Répliquer afin de démarrer la réplication initiale pour les serveurs.

Remarque

Avant le démarrage de la réplication, mettez à jour à tout moment les paramètres de réplication dans Gérer>Réplication des machines. Vous ne pouvez pas changer les paramètres après le démarrage de la réplication.

Étape 6 : Migrer la base de données Azure Database Migration Service

Les administrateurs de Contoso doivent créer un projet Database Migration Service, puis migrer la base de données.

Créer un projet Azure Database Migration Service

Les administrateurs Contoso effectuent les étapes suivantes :

  1. Créer un projet Azure Database Migration Service.

  2. Sélectionnez le type de serveur source SQL Server et Azure SQL Managed Instance en tant que cible.

    Capture d’écran montrant le volet Nouveau projet de migration

    L’Assistant Migration s’ouvre.

Migrer la base de données

Les administrateurs Contoso effectuent les étapes suivantes :

  1. Dans l’Assistant Migration, spécifiez la machine virtuelle source où se trouve la base de données locale. Entrez les informations d’identification pour accéder à la base de données.

    Capture d’écran montrant le volet Détails de la source

  2. Sélectionnez la base de données à migrer : SmartHotel.Registration.

    Capture d’écran montrant le volet Sélectionner les bases de données sources

  3. Pour la cible, entrez le nom de l’instance managée dans Azure ainsi que les informations d’identification d’accès.

    Capture d’écran montrant le volet Détails de la cible

  4. Dans Nouvelle activité>Exécuter la migration, spécifiez les paramètres d’exécution de la migration :

    • Informations d’identification de la source et de la cible.
    • La base de données à migrer.
    • Le partage réseau créé sur la machine virtuelle locale. Le service Azure Database Migration Service enregistre les sauvegardes sources sur ce partage.
      • Le compte de service qui exécute l’instance source de SQL Server doit avoir des autorisations d’écriture sur ce partage réseau.
      • Le chemin d’accès au partage doit être son nom de domaine complet.
    • L’URI SAP qui donne au service Azure Database Migration Service l’accès au conteneur du compte de stockage dans lequel le service charge les fichiers de sauvegarde pour la migration.

    Capture d’écran montrant l’écran Configurer les paramètres de migration

  5. Enregistrez les paramètres de migration, puis exécutez la migration.

  6. Dans Vue d’ensemble, surveillez l’état de la migration.

    Capture d’écran montrant l’état

  7. Une fois la migration terminée, vérifiez que les bases de données cibles existent sur l’instance gérée.

    Capture d’écran montrant la vérification de la migration de la base de données

Étape 7 : Migrer les machines virtuelles avec l’outil Migration et modernisation

Les administrateurs Contoso effectuent une migration de test rapide et vérifient le bon fonctionnement de la machine virtuelle. Ensuite, ils procèdent à la migration de celle-ci.

Exécuter un test de migration

Les administrateurs Contoso effectuent les étapes suivantes :

  1. Dans Objectifs de migration>Serveurs>Azure Migrate : Server Migration, sélectionnez Tester les serveurs migrés.

    Capture d’écran montrant l’élément Tester les serveurs migrés

  2. Sélectionnez et maintenez l’appui (ou effectuez un clic droit) sur la machine virtuelle à tester, puis sélectionnez Tester la migration.

    Capture d’écran montrant l’élément Tester la migration

  3. Dans Migration de test, sélectionnez le réseau virtuel Azure dans lequel la machine virtuelle Azure se trouvera après la migration. Nous recommandons d’utiliser un réseau virtuel hors production.

    Le travail Migration de test démarre.

  4. Supervisez le travail dans les notifications du portail.

  5. Une fois la migration terminée, affichez la machine virtuelle Azure migrée dans Machines virtuelles dans le portail Azure. Le nom de la machine a le suffixe -Test.

  6. Une fois le test terminé, sélectionnez et maintenez l’appui, ou effectuez un clic droit, sur la machine virtuelle Azure dans Réplication des machines, puis sélectionnez Nettoyer la migration test.

    Capture d’écran montrant l’élément Nettoyer la migration de test

Migrer la machine virtuelle

Les administrateurs de Contoso peuvent à présent opérer une migration complète pour achever le déplacement :

  1. Dans le projet Azure Migrate, accédez à Serveurs>Azure Migrate : Migration de serveur, puis sélectionnez Réplication de serveurs.

    Capture d’écran montrant l’élément Réplication de serveurs

  2. Dans Réplication des machines, sélectionnez et maintenez l’appui (ou effectuez un clic droit) sur la machine virtuelle, puis sélectionnez Migrer.

  3. Dans Migrer>Arrêter les machines virtuelles et effectuer une migration planifiée sans perte de données, sélectionnez Oui>OK.

    • Par défaut, Azure Migrate arrête la machine virtuelle locale et exécute une réplication à la demande pour synchroniser tout changement apporté à la machine virtuelle depuis la dernière réplication. Cette action permet d’éviter toute perte de données.
    • Pour ignorer l’arrêt de la machine virtuelle, sélectionnez Non.

    Un travail de migration démarre pour la machine virtuelle.

  4. Suivez le travail dans les notifications Azure.

  5. Une fois le travail terminé, affichez et gérez la machine virtuelle à partir de la page Machines virtuelles.

  6. Mettez à jour les enregistrements DNS pour la machine WEBVM sur l’un des contrôleurs de domaine Contoso.

Mettre à jour la chaîne de connexion

Dans la dernière étape du processus de migration, les administrateurs de Contoso mettent à jour la chaîne de connexion de l’application pour qu’elle pointe vers la base de données migrée qui s’exécute sur l’instance SQL Managed Instance :

  1. Dans le portail Azure, recherchez la chaîne de connexion en sélectionnant Paramètres>Chaînes de connexion.

    Capture d’écran qui montre l’option Chaînes de connexion

  2. Mettez à jour la chaîne avec le nom d’utilisateur et le mot de passe de l’instance managée SQL.

  3. Une fois la chaîne configurée, ils remplacent la chaîne de connexion actuelle dans le fichier web.config de l’application.

  4. Après avoir mis à jour et enregistré le fichier, redémarrez IIS sur la machine WEBVM en exécutant iisreset /restart dans une fenêtre d’invite de commandes.

    Une fois IIS redémarré, l’application utilise la base de données s’exécutant sur l’instance managée SQL.

  5. Arrêtez la machine virtuelle locale SQLVM.

    La migration est terminée.

Besoin de plus d’aide ?

Nettoyer après la migration

Une fois la migration terminée, une machine virtuelle Azure exécute l’application SmartHotel360, et SQL Managed Instance héberge la base de données SmartHotel360.

Contoso effectue à présent les tâches de nettoyage suivantes :

  • Supprimer la machine WEBVM de l’inventaire de vCenter Server.
  • Supprimer la machine SQLVM de l’inventaire de vCenter Server.
  • Supprimer les machines WEBVM et SQLVM des tâches de sauvegarde locales.
  • Mettre à jour la documentation interne afin qu’elle indique le nouvel emplacement et l’adresse IP de la machine WEBVM.
  • Supprimer la machine SQLVM de la documentation interne. En guise d’alternative, Contoso peut réviser la documentation afin qu’elle indique que la machine SQLVM a été supprimée et ne figure plus dans l’inventaire des machines virtuelles.
  • Passer en revue toutes les ressources qui interagissent avec les machines virtuelles qui ont été mises hors service Mettre à jour les paramètres ou la documentation appropriés afin de refléter la nouvelle configuration

Examiner le déploiement

Les ressources ayant été migrées dans Azure, Contoso doit rendre sa nouvelle infrastructure entièrement opérationnelle et la sécuriser.

Sécurité

L’équipe de sécurité de Contoso vérifie les machines virtuelles Azure et l’instance SQL Managed Instance pour détecter d’éventuels problèmes de sécurité dans l’implémentation :

  • L’équipe examine les groupes de sécurité réseau utilisés pour contrôler l’accès à la machine virtuelle. Les groupes de sécurité réseau aident à s’assurer que seul le trafic autorisé à accéder à l’application peut passer.

  • L’équipe de sécurité de Contoso prend également en considération la sécurisation des données sur le disque à l’aide d’Azure Disk Encryption et d’Azure Key Vault.

  • L’équipe active la détection des menaces sur l’instance gérée. La détection des menaces envoie une alerte à l’équipe de sécurité/au système de support de Contoso afin d’ouvrir un ticket en cas de détection d’une menace. Pour plus d’informations sur la détection des menaces, consultez Configurer Advanced Threat Protection dans Azure SQL Managed Instance.

    Capture d’écran montrant l’écran Détection des menaces pour SQL Managed Instance.

Pour en savoir plus sur les pratiques de sécurité pour les machines virtuelles, consultez Bonnes pratiques de sécurité pour les charges de travail IaaS dans Azure.

Continuité d’activité et reprise d’activité

Pour assurer la continuité d'activité et la reprise d'activité, Contoso effectue les actions suivantes :

Gestion des licences et optimisation des coûts

  • Contoso dispose déjà d’une licence pour WEBVM. Pour tirer parti de la tarification avec Azure Hybrid Benefit, Contoso convertit la machine virtuelle Azure existante.
  • Contoso utilise Azure Cost Management + Billing pour s’assurer de respecter les budgets établis par la direction informatique de l’entreprise.

Conclusion

Cet article décrit comment Contoso a réhébergé l’application SmartHotel360 dans Azure en migrant la machine virtuelle frontale de l’application vers Azure avec Azure Migrate. Contoso migre la base de données locale vers une instance managée SQL en utilisant le service Azure Database Migration Service.

Étapes suivantes