Mettre à l’échelle une migration vers Azure

Cet article montre comment la société fictive Contoso réalise une migration à l’échelle vers Azure. La société réfléchit à la façon de planifier et d’effectuer une migration de plus de 3 000 charges de travail, 8 000 bases de données et 10 000 machines virtuelles.

Axes stratégiques

L’équipe informatique a travaillé en étroite collaboration avec des partenaires commerciaux pour comprendre le résultat qu’ils souhaitent obtenir avec cette migration :

  • Répondre à la croissance de l’entreprise. Contoso étant en pleine croissance, son infrastructure et ses systèmes locaux sont soumis à une charge importante.
  • Gagner en efficacité. Contoso doit supprimer les procédures inutiles et rationaliser les processus pour les développeurs et les utilisateurs. L’entreprise a besoin d’une informatique rapide et doit éviter de perdre du temps ou d’argent en répondant plus rapidement aux exigences des clients.
  • Gagner en agilité. le service informatique de Contoso doit être plus réactif face aux besoins de l’entreprise. Pour relever les défis de l’économie mondialisée, il doit être en mesure de devancer les évolutions du marché. Il ne doit pas être une entrave à l'activité.
  • Adaptation. À mesure que l’entreprise croît, l’informatique de Contoso doit fournir des systèmes capables de croître au même rythme.
  • Améliorer les modèles de coûts. Contoso souhaite réduire les besoins en fonds propres dans le budget informatique. Contoso souhaite utiliser les capacités du cloud pour mettre à l’échelle et réduire les besoins en matériel coûteux.
  • Réduire les coûts de licences. Contoso souhaite réduire les coûts liés au cloud.

Objectifs de la migration

L’équipe cloud de Contoso a épinglé les objectifs de cette migration. Elle a utilisé les objectifs suivants pour déterminer la meilleure méthode de migration.

Spécifications Détails
Migrer rapidement vers Azure Contoso souhaite déplacer des applications et des machines virtuelles vers Azure aussi vite que possible.
Compiler un inventaire complet Contoso souhaite dresser un inventaire complet des applications, des bases de données et des machines virtuelles présentes dans l’organisation.
Évaluer et classer les applications Contoso souhaite tirer pleinement parti du cloud. Par défaut, Contoso considère que tous les services s’exécuteront en tant que PaaS (Platform as a service). La capacité IaaS (Infrastructure as a service) sera utilisée où PaaS ne conviendra pas.
Former et migrer vers DevOps Contoso souhaite passer à un modèle DevOps. Contoso prévoit d’assurer des formations à Azure et DevOps, et de réorganiser les équipes selon les besoins.

Après avoir défini les objectifs et les contraintes, Contoso examine l’encombrement informatique et identifie le processus de migration.

Déploiement actuel

Contoso a planifié et configuré une infrastructure Azure, elle a également essayé différentes combinaisons de migration en preuve de concept (POC), comme détaillé dans le tableau précédent. Elle est maintenant prête à effectuer une migration complète vers Azure, à grande échelle. Voici ce que Contoso souhaite migrer.

Élément Volume Détails
Charges de travail > 3 000 applications
  • Les applications s’exécutent sur des machines virtuelles.
  • Les plateformes d’applications sont Windows, SQL Server et LAMP.
  • Bases de données Environ 8 500 bases de données Les bases de données utilisées sont SQL Server, MySQL et PostgreSQL.
    Machines virtuelles > 35 000 machines virtuelles Les machines virtuelles s’exécutent sur des hôtes VMware et sont gérées par des serveurs vCenter.

    Processus de migration

    À présent que Contoso a défini des axes stratégiques et des objectifs de migration, elle peut s’aligner sur la méthodologie de migration. Elle peut s’appuyer sur l’application de vagues et de sprints de migration pour planifier et exécuter des efforts de migration de manière itérative.

    Plan

    Contoso lance le processus de planification en découvrant et évaluant les applications, les données et l’infrastructure locales. Voici ce que fera Contoso :

    • Contoso doit découvrir les applications, mapper les dépendances entre les applications et établir l’ordre et les priorités de la migration.
    • Au cours de l’évaluation, Contoso établit un inventaire complet des applications et des ressources. Avec le nouvel inventaire, Contoso utilise et met à jour ces éléments existants :
      • La base de données de gestion des configurations (CMDB). Elle contient les configurations techniques des applications de Contoso.
      • Le catalogue de services. Il contient les détails opérationnels des applications, notamment les partenaires commerciaux associés et les contrats de niveau de service.

    Découvrir les applications

    Contoso exécute des milliers d’applications sur une série de serveurs. Outre la base de données CMDB et le catalogue de services, Contoso a besoin d’outils de détection et d’évaluation.

    Les outils doivent fournir un mécanisme capable d’alimenter le processus de migration en données d’évaluation. Les outils d’évaluation doivent fournir des données qui permettent d’établir un inventaire intelligent des ressources physiques et virtuelles de Contoso. Les données doivent inclure des informations de profil et des métriques de performances.

    À l’issue de la détection, Contoso doit disposer d’un inventaire complet des ressources et des métadonnées associées. La société utilisera cet inventaire pour définir le plan de migration.

    Identifier les classifications

    Contoso identifie certaines catégories communes pour classifier les ressources dans l’inventaire. Ces classifications sont essentielles aux décisions que va prendre Contoso pour la migration. La liste de classifications aide à établir les priorités de migration et à identifier les problèmes complexes.

    Category Valeur attribuée Détails
    Groupe de l’entreprise Liste des noms de groupes de l’entreprise Quel est le groupe en charge de l’élément d’inventaire ?
    Candidat à une preuve de concept O/N L’application peut-elle être utilisée en tant que preuve de concept ou utilisateur précoce pour la migration vers le cloud ?
    Dette technique Aucune/Légère/Lourde L’élément d’inventaire est-il en cours d’exécution ou utilise-t-il un produit, une plateforme ou un système d’exploitation dont le support n’est plus assuré ?
    Implications pour le pare-feu O/N L’application communique-t-elle avec Internet ou un trafic extérieur ? S’intègre-t-elle à un pare-feu ?
    Problèmes de sécurité O/N Existe-t-il des problèmes de sécurité connus liés à l’application ? L’application utilise-t-elle des données non chiffrées ou des plateformes obsolètes ?

    Découvrir les dépendances d’applications

    Dans le cadre du processus d’évaluation, Contoso doit déterminer où s’exécutent les applications. Elle doit également déterminer les dépendances et les connexions entre les serveurs d’applications. Contoso mappe l’environnement en étapes :

    1. Contoso cherche à déterminer comment les serveurs et les machines mappent aux applications, emplacements réseau et groupes individuels.
    2. Contoso identifie clairement les applications ayant peu de dépendances, et pouvant être migrées rapidement.
    3. Contoso peut se servir du mappage pour identifier les dépendances et les communications plus complexes entre les serveurs d’applications. Contoso peut ensuite regrouper logiquement ces serveurs pour représenter les applications, puis élaborer une stratégie de migration basée sur ces groupes.

    Une fois le mappage terminé, Contoso peut vérifier que tous les composants d’application sont identifiés et pris en compte au moment d’établir le plan de migration.

    Diagram of a dependency mapping.

    Évaluer les applications

    Dans la dernière étape du processus de découverte et d’évaluation, Contoso peut examiner les résultats de l’évaluation et du mappage pour déterminer comment migrer chaque application du catalogue de services.

    Pour bien représenter ce processus d’évaluation, Contoso ajoute quelques classifications à l’inventaire.

    Category Valeur attribuée Détails
    Groupe de l’entreprise Liste des noms de groupes de l’entreprise Quel est le groupe en charge de l’élément d’inventaire ?
    Candidat à une preuve de concept O/N L’application peut-elle être utilisée en tant que preuve de concept ou utilisateur précoce pour la migration vers le cloud ?
    Dette technique Aucune/Légère/Lourde L’élément d’inventaire est-il en cours d’exécution ou utilise-t-il un produit, une plateforme ou un système d’exploitation dont le support n’est plus assuré ?
    Implications pour le pare-feu O/N L’application communique-t-elle avec Internet ou un trafic extérieur ? S’intègre-t-elle à un pare-feu ?
    Problèmes de sécurité O/N Existe-t-il des problèmes de sécurité connus liés à l’application ? L’application utilise-t-elle des données non chiffrées ou des plateformes obsolètes ?
    Stratégie de migration Réhébergement/Refactorisation/Réarchitecture/Regénération De quel type de migration l’application a-t-elle besoin ? Comment l’application sera-t-elle déployée dans Azure ? Plus d’informations
    Complexité technique 1-5 Quel est le degré de complexité de la migration ? Cette valeur doit être définie par l’équipe DevOps de Contoso et par les partenaires compétents.
    Caractère critique pour l’entreprise 1-5 Quelle importance l’application a-t-elle pour l’entreprise ? Par exemple, une note de 1 pourrait être attribuée à une application utilisée par un petit groupe de travail, et une note de 5 à une application critique utilisée dans toute l’organisation. Cette note influencera le niveau de priorité de sa migration.
    Priorité de migration 1/2/3 Quelle est la priorité de migration de l’application ?
    Risque de migration 1-5 Quel est le niveau de risque de la migration de l’application ? L’équipe DevOps de Contoso et les partenaires concernés doivent se mettre d’accord sur cette valeur.

    Déterminer les coûts

    Pour déterminer les coûts et les économies potentielles de la migration vers Azure, Contoso peut se servir de la Calculatrice du coût total de possession (TCO) pour calculer le coût TCO pour Azure et le comparer à celui d’un déploiement sur site équivalent.

    Identifier les outils d’évaluation

    Contoso choisit l’outil qui lui permettra de détecter, évaluer et établir l’inventaire. Contoso recense un ensemble d’outils et services Azure, d’outils et de scripts natifs et d’outils de partenaires. En particulier, Contoso souhaite savoir comment utiliser Azure Migrate pour effectuer une évaluation précise.

    Azure Migrate

    Le service Azure Migrate permet de détecter et d’évaluer les machines virtuelles VMware locales en vue de préparer une migration vers Azure. Voici les actions qu’effectue Azure Migrate :

    1. Découvrir : Détecter les machines virtuelles VMware locales.

      Azure Migrate prend en charge la détection à partir de plusieurs serveurs vCenter (en série) et peut exécuter des détections dans différents projets Azure Migrate.

      Azure Migrate assure la détection via une machine virtuelle VMware exécutant Azure Migrate Collector. Le même collecteur peut détecter les machines virtuelles sur différents serveurs vCenter, et envoyer des données à différents projets.

    2. Évaluer la préparation : Évaluez si les machines locales se prêtent à une exécution dans Azure. Une évaluation comprend les éléments suivants :

      • Recommandations de taille : Obtenez des suggestions de taille pour les machines virtuelles Azure, en fonction de l’historique des performances des machines virtuelles locales.
      • Coûts mensuels estimés : obtenez les coûts estimés pour l’exécution de machines locales dans Azure.
    3. Identifier les dépendances : visualisez les dépendances des machines locales afin de créer des groupes de machines optimaux pour l’évaluation et la migration.

    Diagram of how the Azure Migrate service works.

    Contoso doit utiliser Azure Migrate correctement, étant donné l’échelle de cette migration :

    • Contoso évalue chaque application via Azure Migrate. Cette évaluation vérifie qu’Azure Migrate retourne les données au portail Azure en temps voulu.
    • Les administrateurs Contoso apprennent à déployer Azure Migrate à grande échelle.
    • Contoso prend note des limites d’Azure Migrate résumées dans le tableau suivant.
    Action Limite
    Création d’un projet Azure Migrate 10 000 machines virtuelles
    Découverte 10 000 machines virtuelles
    Évaluation 10 000 machines virtuelles

    Contoso prévoit d’utiliser Azure Migrate de la façon suivante :

    • Dans vCenter, les machines virtuelles sont organisées dans des dossiers. Cela facilitera le travail des administrateurs qui pourront axer l’évaluation sur les machines virtuelles d’un dossier spécifique.
    • Évaluez les dépendances entre les machines. Pour cela, des agents doivent être installés sur les machines virtuelles à évaluer.

    Contoso utilisera des scripts automatisés pour installer les agents Windows ou Linux nécessaires. En utilisant des scripts, Contoso pourra envoyer (push) l’installation aux machines virtuelles situées dans un dossier vCenter.

    Outils de base de données

    Outre Azure Migrate, Contoso cherchera à utiliser des outils spécialement conçus pour l’évaluation des bases de données. Des outils comme l’Assistant Migration de données l’aideront à évaluer les bases de données SQL Server en vue de la migration.

    L’Assistant Migration de données peut aider Contoso à déterminer si les bases de données locales sont compatibles avec une série de solutions de base de données Azure. Ces solutions incluent Azure SQL Database, SQL Server s’exécutant sur une machine virtuelle Azure IaaS et Azure SQL Managed Instance.

    En plus de Database Migration Service, Contoso dispose de quelques scripts qu’elle utilise pour détecter et répertorier les bases de données SQL Server. Ces scripts se trouvent dans le dépôt GitHub.

    Outils d’évaluation des partenaires

    Plusieurs autres outils de partenaires peuvent être utiles à Contoso pour évaluer l’environnement local en vue de la migration vers Azure. En savoir plus sur les partenaires de migration Azure.

    Étape 2 : Migrer

    Une fois l’évaluation terminée, Contoso doit identifier des outils pour déplacer applications, données et infrastructure vers Azure.

    Stratégies de migration

    Contoso a le choix entre quatre stratégies de migration globales.

    Stratégie Détails Usage
    Réhébergement
  • Souvent appelée migration lift-and-shift, cette option sans code permet de migrer rapidement des applications existantes vers Azure.
  • Les applications sont migrées en l’état, avec les avantages du cloud et sans les risques ou les coûts associés aux modifications de code.
  • Contoso peut réhéberger des applications moins stratégiques qui ne nécessitent pas de modifications de code.
  • Refactorisation
  • Également appelée réempaquetage, cette stratégie nécessite des modifications minimes du code ou de la configuration de l’application pour connecter celle-ci à Azure PaaS et tirer un meilleur parti des capacités du cloud.
  • Contoso peut refactoriser des applications stratégiques afin qu’elles conservent les mêmes fonctionnalités de base, mais en les déplaçant pour qu’elles s’exécutent sur une plateforme Azure telle qu’Azure App Service.
  • Cela demande peu de modifications de code.
  • En revanche, Contoso devra assurer la maintenance d’une plateforme de machines virtuelles, car Microsoft ne gérera pas cela.
  • Réarchitecture
  • Cette stratégie consiste à modifier ou à étendre la base de code d’une application de façon à optimiser son architecture et ainsi profiter des capacités du cloud et de la mise à l’échelle.
  • Elle permet d’en faire une application moderne dotée d’une architecture résiliente, hautement évolutive et pouvant être déployée de façon indépendante.
  • Les services Azure peuvent accélérer le processus, mettre à l’échelle des applications en toute confiance et les gérer en toute simplicité.
  • Reconstruire
  • Cette approche consiste à reconstruire entièrement une application à l’aide de technologies cloud natives.
  • Azure PaaS propose un environnement complet de développement et de déploiement dans le cloud. Cette solution élimine en partie le coût et la complexité des licences logicielles. Elle évite également d’avoir à recourir à une infrastructure applicative sous-jacente, à des intergiciels (middleware) et à d’autres ressources.
  • Contoso peut réécrire les applications critiques pour tirer parti de technologies cloud, telles que les microservices ou le calcul serverless.
  • Contoso gère les applications et les services qu’elle développe, et Azure tout le reste.
  • Les données doivent aussi être prises en considération, surtout au vu du volume des bases de données de Contoso. L’approche par défaut de la société consiste à utiliser des services PaaS comme Azure SQL Database pour tirer pleinement parti des fonctionnalités du cloud. En passant à un service PaaS pour les bases de données, Contoso ne s’occupera plus que de gérer les données. Elle laissera le soin à Microsoft de gérer la plateforme sous-jacente.

    Évaluer les outils de migration

    Contoso utilise essentiellement ces services et outils Azure pour la migration :

    • Azure Migrate : Service de migration de machines virtuelles locales et d’autres ressources vers Azure.
    • Azure Database Migration Service : Migre les bases de données locales comme SQL Server, MySQL et Oracle vers Azure.

    Azure Migrate

    Azure Migrate est le service Azure capital quand il s’agit d’orchestrer la migration au sein d’Azure et des sites locaux vers Azure.

    Azure Migrate orchestre la réplication d’emplacements locaux vers Azure. Dès lors que la réplication est configurée et qu’elle s’exécute, les machines locales peuvent être basculées vers Azure, ce qui marque la fin de la migration.

    Contoso avait déjà réalisé une preuve de concept pour vérifier si Azure Migrate pouvait l’aider à migrer vers le cloud.

    Utiliser Azure Migrate à grande échelle

    Contoso envisage d’effectuer plusieurs migrations lift-and-shift. Pour s’assurer que cela fonctionne, Azure Migrate exécutera une réplication par lots d’environ 100 machines virtuelles à la fois. Pour déterminer comment cela fonctionne, Contoso a besoin de planifier la capacité pour la migration proposée.

    Contoso doit collecter des informations sur ses volumes de trafic. En particulier :

    • Elle doit déterminer le taux de modification des machines virtuelles à répliquer.
    • Elle doit tenir compte de la connectivité réseau du site local à Azure.

    Face aux exigences de capacité et de volume, les équipes doivent allouer suffisamment de bande passante, compte tenu du taux de modification quotidien des données des machines virtuelles en question, pour atteindre son objectif de point de récupération (RPO). Enfin, elle doit déterminer le nombre de serveurs qu’il faudra pour exécuter les composants Azure Migrate du déploiement.

    Collecter les informations locales

    Contoso peut utiliser Azure Migrate :

    • Pour profiler à distance les machines virtuelles sans aucune répercussion sur l’environnement de production. Cela permet de cerner les besoins en bande passante et stockage pour la réplication et le basculement.
    • Sans installer les composants Site Recovery locaux.

    L’outil collecte des informations sur les machines virtuelles compatibles et incompatibles, le nombre de disques par machine virtuelle et l’activité des données par disque. De même, il identifie les besoins en bande passante réseau, ainsi que l’infrastructure Azure nécessaire au succès de la réplication et du basculement.

    Contoso doit veiller à exécuter l’outil de planification sur une machine Windows Server qui correspond à la configuration minimale exigée pour le serveur de configuration Site Recovery. Le serveur de configuration est une machine Site Recovery qui est nécessaire à la réplication des machines virtuelles VMware locales.

    Identifier la configuration requise pour Site Recovery

    Outre la réplication des machines virtuelles, Site Recovery a besoin de plusieurs composants pour la migration de VMware.

    Composant Détails
    Serveur de configuration
  • Généralement une machine virtuelle VMware configurée au moyen d’un modèle OVF.
  • Le composant de serveur de configuration coordonne les communications entre les machines locales et Azure, et gère la réplication des données.
  • Serveur de traitement
  • Installé par défaut sur le serveur de configuration.
  • Le composant serveur de processus reçoit les données de réplication, les optimise en les mettant en cache, en les compressant et en les chiffrant, puis les envoie au Stockage Azure.
  • De plus, le serveur de processus installe le service Mobility d’Azure Site Recovery sur les machines virtuelles que vous voulez répliquer, puis effectue une détection automatique des machines locales.
  • Les déploiements mis à l’échelle ont besoin d’autres serveurs de processus autonomes pour gérer les importants volumes de trafic de réplication.
  • Service Mobilité
  • L’agent du service Mobility est installé sur chaque machine virtuelle VMware à migrer avec Azure Site Recovery.
  • Contoso doit déterminer comment déployer ces composants en tenant compte des considérations de capacité.


    Composant Besoins en capacité
    Taux de modification quotidien maximal
  • Un seul serveur de processus peut prendre en charge un taux de modification quotidien maximal de 2 téraoctets (To). Sachant qu’une machine virtuelle ne peut utiliser qu’un seul serveur de processus, le taux quotidien maximal de modification de données pris en charge pour une machine virtuelle répliquée est de 2 To.
  • Débit maximal
  • Un compte de stockage Azure standard peut gérer au maximum 20 000 requêtes par seconde. Les opérations d’entrée/sortie par seconde (IOPS) sur une machine virtuelle en cours de réplication doivent donc s’inscrire dans cette limite. Par exemple, si une machine virtuelle dispose de 5 disques et que chaque disque génère 120 IOPS (taille de 8 Ko) sur la machine virtuelle, la limite de 500 IOPS sur le disque Azure est respectée.
  • Le nombre de comptes de stockage nécessaires est égal au nombre total d’IOPS de la machine source divisé par 20 000. Un ordinateur répliqué ne peut appartenir qu’à un seul compte de stockage dans Azure.
  • Serveur de configuration D’après leur estimation de réplication de 100 à 200 machines virtuelles et des exigences de dimensionnement du serveur de configuration, les équipes Contoso considèrent qu’elles ont besoin du type de configuration de machine serveur suivant :
  • UC : 16 processeurs virtuels (2 sockets × 8 cœurs @ 2,5 GHz)
  • Mémoire : 32 Go
  • Disque cache : 1 To
  • Taux de modification des données : 1 To à 2 To
    En plus des exigences de dimensionnement, Contoso doit vérifier que l’emplacement du serveur de configuration est optimal, à savoir sur les mêmes réseau et segment de réseau local que les machines virtuelles à migrer.
  • Serveur de traitement Contoso prévoit de déployer un serveur de processus dédié, autonome, capable de répliquer entre 100 et 200 machines virtuelles :
  • UC : 16 processeurs virtuels (2 sockets × 8 cœurs @ 2,5 GHz)
  • Mémoire : 32 Go
  • Disque cache : 1 To
  • Taux de modification des données : 1 To à 2 To
    Le serveur de processus devant accomplir un travail intense, il se situe sur un hôte ESXi capable de gérer les E/S disque, le trafic réseau et l’UC nécessaires à la réplication. Pour cela, Contoso examinera s’il y a lieu d’utiliser un hôte dédié.
  • Mise en réseau
  • Après avoir examiné l’infrastructure VPN site à site actuelle, Contoso a décidé d’implémenter Azure ExpressRoute. Cette implémentation est critique parce qu’elle réduira la latence et améliorera la bande passante pour la région Azure primaire de Contoso (East US 2).
  • Contoso devra superviser attentivement les flux de données en provenance du serveur de processus. Si les données surchargent la bande passante réseau, Contoso envisagera de limiter la bande passante du serveur de processus.
  • Stockage Azure
  • Pour la migration, Contoso doit identifier le type et le nombre appropriés de comptes Stockage Azure cibles. Site Recovery réplique les données de machine virtuelle dans le stockage Azure.
  • Site Recovery peut répliquer vers des comptes de stockage SSD Standard ou SSD Premium.
  • Pour prendre une décision concernant le stockage, Contoso doit examiner les limites de stockage et tenir compte des perspectives de croissance et d’utilisation à l’avenir. Compte tenu de la vitesse et de la priorité des migrations, Contoso a décidé d’utiliser des SSD Premium.
  • Contoso a décidé d’utiliser des disques managés pour toutes les machines virtuelles déployées dans Azure. Le nombre d’opérations d’entrée/sortie par seconde (IOPS) aidera à déterminer le type de disque qui sera utilisé : HDD Standard, SSD Standard ou SSD Premium.
  • Azure Database Migration Service

    Azure Database Migration Service est un service complètement managé permettant des migrations sans heurts de plusieurs sources de base de données vers des plateformes de données Azure avec un temps d’arrêt minimum. Voici quelques détails sur le service :

    • Il intègre les fonctionnalités d’outils et de services existants. Il utilise l’Assistant Migration de données pour générer des rapports d’évaluation qui identifient les recommandations concernant la compatibilité des bases de données, et les modifications nécessaires.
    • Il utilise un processus de migration simple et auto-guidé, dont l’évaluation intelligente qui permet de résoudre les problèmes potentiels avant la migration.
    • Il permet une migration à grande échelle, de plusieurs sources vers la base de données Azure cible.
    • Il assure une prise en charge de SQL Server, de la version 2005 à la version 2017.

    Le service Database Migration Service n’est pas le seul outil de migration de base de données Microsoft. Une comparaison des outils et des services peut être consultée ici.

    Utiliser le service Database Migration Service à grande échelle

    Contoso utilise le service Database Migration Service lors de la migration à partir de SQL Server.

    Pendant l’approvisionnement du service Database Migration Service, Contoso doit le dimensionner correctement et le configurer de façon à optimiser les performances des migrations de données. Contoso va sélectionner le niveau de service critique pour l’entreprise avec quatre vCores. Cette option permet au service de tirer parti de plusieurs processeurs virtuels pour la parallélisation et un transfert de données plus rapide.

    Screenshot that shows Database Migration Service scaling, with the Business Critical option selected.

    Une autre tactique de mise à l’échelle que Contoso peut utiliser consiste à effectuer un scale-up temporaire d’Azure SQL Database ou l’instance cible d’Azure Database pour MySQL vers le niveau tarifaire Premium pendant la migration des données. Cela minimise la limitation de base de données qui pourrait avoir une incidence sur les activités de transfert de données lorsqu’une organisation utilise des niveaux inférieurs.

    Utiliser d’autres outils

    En plus de Database Migration Service, Contoso peut utiliser d’autres outils et services pour identifier les informations de machines virtuelles :

    • Des scripts qui facilitent les migrations manuelles. Ceux-ci sont disponibles dans le dépôt GitHub.
    • Plusieurs outils partenaires pour la migration.

    < docutune:ignore "cost management tools" -->

    Prêt pour la production

    Après avoir déplacé les ressources vers Azure, Contoso doit les rationaliser pour améliorer les performances et optimiser le retour sur investissement à l’aide d’outils de gestion des coûts. Azure étant un service facturé à l’utilisation, il est essentiel pour Contoso de comprendre le fonctionnement des systèmes et de vérifier qu’ils sont correctement dimensionnés.

    Azure Cost Management + Billing

    Pour rentabiliser au mieux son investissement cloud, Contoso entend tirer parti de l’outil gratuit Azure Cost Management + Billing. Cette solution permet à Contoso de gérer les dépenses cloud avec transparence et précision. Cette solution propose des outils pour surveiller, répartir et réduire les coûts liés au cloud.

    La solution Azure Cost Management + Billing fournit des rapports sous la forme de tableaux de bord simples, qui facilitent l’affectation des coûts, les rétrospectives et les rétrofacturations. L’outil permet d’optimiser les dépenses cloud en identifiant les ressources sous-utilisées, ce qui permettra à Contoso de les gérer et de les ajuster.

    Apprenez-en davantage avec la Vue d’ensemble d’Azure Cost Management + Billing.

    Screenshot of an example graph of cost over time in Azure Cost Management + Billing.

    Outils natifs

    Contoso prévoit aussi d’utiliser des scripts pour localiser les ressources non utilisées.

    Pendant les migrations de grande ampleur, il est fréquent qu’il reste des reliquats de données, comme des disques durs virtuels, qui occasionnent des frais sans pour autant être utiles à l’entreprise. Les scripts sont disponibles dans le dépôt GitHub.

    Contoso entend tirer parti du travail réalisé par le service informatique de Microsoft, et envisage d’implémenter le kit ARO (Azure Resource Optimization). Le kit se trouve également dans le dépôt GitHub.

    Contoso peut déployer un compte Azure Automation avec des runbooks et des planifications préconfigurés dans son abonnement et commencer à faire des économies. L’optimisation des ressources se produit automatiquement dans un abonnement dès lors qu’une planification est activée ou créée ; elle s’étend aux nouvelles ressources. Ces fonctionnalités d’automation décentralisées permettent de réduire les coûts. Voici quelques fonctionnalités :

    • Mise en veille automatique des machines virtuelles Azure basée sur une faible utilisation de l’UC.
    • Mise en veille et sortie de veille programmées des machines virtuelles Azure.
    • Mise en veille et sortie de veille programmées des machines virtuelles Azure, par ordre croissant et décroissant, à l’aide d’étiquettes Azure.
    • Suppression en bloc des groupes de ressources à la demande.

    Outils d’optimisation de partenaires

    Contoso peut utiliser des outils de partenaires, comme Hanu et Scalr.

    Étape 4 : Sécuriser et gérer

    Contoso utilise les ressources de sécurité et de gestion Azure durant cette étape pour régir, sécuriser et superviser les applications cloud dans Azure. Ces ressources permettent à une organisation d’utiliser les produits disponibles sur le portail Azure, dans un environnement sécurisé et bien géré.

    Contoso commence à utiliser ces services pendant la migration. Elle profite de la prise en charge hybride d’Azure qui lui permet de continuer à en utiliser un bon nombre, pour une expérience harmonisée sur le cloud hybride.

    Sécurité

    Contoso s’appuiera sur Microsoft Defender pour le cloud pour une gestion unifiée de la sécurité et Microsoft Defender pour Identity pour l’ensemble des charges de travail cloud hybrides.

    Defender pour le cloud offre une visibilité et un contrôle complets sur la sécurité des applications cloud dans Azure. Contoso peut ainsi détecter rapidement les menaces et prendre les mesures nécessaires pour y répondre, et réduire les risques de sécurité en activant la protection adaptative contre les menaces.

    En savoir plus sur Defender pour le cloud.

    Supervision

    Contoso a besoin d’une visibilité sur l’intégrité et les performances des applications, données et infrastructure nouvellement migrées qui s’exécutent désormais dans Azure. Contoso utilisera les outils de supervision cloud Azure intégrés, comme Azure Monitor, un espace de travail Log Analytics et Application Insights.

    Grâce à ces outils, Contoso peut facilement collecter des données provenant de diverses sources, et bénéficier d’insights. Par exemple, Contoso peut mesurer l’utilisation de l’UC, de la mémoire et du disque des machines virtuelles, afficher les dépendances des applications et du réseau au niveau des diverses machines virtuelles et suivre les performances des applications. Contoso se servira de ces outils de supervision du cloud pour prendre des mesures et s’intégrer à des solutions de service.

    Apprenez-en davantage sur la supervision Azure.

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

    Contoso aura besoin d’une stratégie de continuité d’activité et reprise d’activité (BCDR) pour ses ressources Azure.

    Azure fournit des fonctionnalités BCDR intégrées permettant de protéger les données et maintenir applications et services opérationnels.

    En plus des fonctionnalités intégrées, la société Contoso tient à s’assurer qu’elle pourra récupérer après une défaillance, éviter les interruptions d’activité coûteuses, répondre aux objectifs de conformité et protéger les données contre les ransomwares et les erreurs humaines. Pour ce faire :

    • Contoso prévoit de déployer la solution économique Sauvegarde Microsoft Azure pour sauvegarder les ressources Azure. Comme cette solution est intégrée, Contoso pourra configurer des sauvegardes cloud en quelques étapes simples.
    • Contoso configurera la récupération d’urgence pour les machines virtuelles Azure au moyen d’Azure Site Recovery, de façon à assurer la réplication, le basculement et la restauration automatique entre les régions Azure spécifiées. Cela garantit que applications qui s’exécutent sur des machines virtuelles Azure restent disponibles dans une région secondaire choisie par Contoso au cas où une panne surviendrait dans la région primaire. Plus d’informations

    Conclusion

    Dans cet article, la société Contoso a établi des plans pour effectuer une migration Azure à l’échelle. Elle a divisé le processus de migration en quatre étapes, à savoir : évaluation, migration, puis optimisation, sécurité, et gestion une fois la migration terminée.

    Il est important pour une organisation d’envisager un projet de migration dans son ensemble, et de faire migrer ses systèmes en les décomposant sous forme de classifications et de numéros qui font sens pour l’entreprise. En évaluant les données et en appliquant des classifications, les projets peuvent être décomposés en une série de migrations de plus petite taille, qui peuvent s’exécuter rapidement et de manière sécurisée. La somme de ces petites migrations se transforme rapidement et avec succès en une migration d’envergure vers Azure.