Exporter (0) Imprimer
Développer tout

Planification d'une migration vers Azure

Mis à jour: avril 2014

Lorsque vous commencez à planifier votre migration, vous devez prendre en compte plusieurs éléments clés comme le coût, les besoins métiers et techniques, la chronologie et les tests requis dans le processus de migration. Cette section vous guide dans la résolution d'un certain nombre de problèmes et vous conseille les étapes à suivre pour planifier votre migration vers Azure :

Auteur : Steve Howard
Réviseurs : James Podgorski, Paolo Salvatori, Selcin Turkarslan, Stuart Ozer

Le coût est l'un des facteurs essentiels à prendre en compte. Nous vous recommandons de l'aborder très tôt dans le processus de décision et de planification de la migration d'une application sur site vers Azure. L'estimation du coût d'une application Azure dépend de plusieurs facteurs tels que la charge du trafic réseau, les caractéristiques d'entre/sortie de l'application et le volume de données qu'elle traite. Le calcul du coût dépasse l'objet de cette rubrique. Nous vous recommandons d'utiliser le calculateur de coût de Azure pour avoir une estimation lorsque vous commencez à planifier votre migration. La calculateur de coût de Azure est disponible ici.

Lorsque vous calculez le coût pour votre organisation, n'oubliez pas d'inclure les coûts de développement et de test directs de Azure. Dans un projet de développement sur site, les serveurs de développement et de test sont payants. De même, dans l'environnement Azure, vous devez payer les ressources utilisées pendant le développement et le test. En outre, vous devez calculer les coûts de formation et d'apprentissage, ainsi que les coûts associés au déplacement de l'application dans Azure. Nous vous recommandons d'effectuer des tests de performances et de planifier les capacités pour déterminer au préalable la capacité requise pour l'application.

Azure peut parfaitement répondre à un certain nombre de besoins métiers et techniques. Voici une liste non exhaustive des applications qui gagnent à être migrées vers Azure :

  • Base utilisateur distribuée : les centres de données Azure sont situés sur plusieurs continents. L'interconnexion entre les centres de données permet une distribution des données très performante lorsque cela est nécessaire. Les fonctionnalités Azure telles que le réseau de diffusion de contenu et les services de synchronisation des données vous permettent de distribuer les données pertinentes, ou celles très utilisées, dans les centres de données les plus proches des utilisateurs. Lorsque les utilisateurs se connectent à des centres de données proches de leur emplacement géographique, la longueur de la boucle est plus faible et l'expérience d'utilisation est optimisée.

  • Charge variable : vous devez acquérir du matériel pour permettre aux applications locales de gérer les pics de charge. Par exemple, un point de vente achète généralement des serveurs pour être en mesure de gérer la charge pendant la saison d'achat. De même, un service comptable peut avoir besoin de planifier une infrastructure supplémentaire pour gérer les pics de charge en fin de mois ou la clôture comptable de fin d'année. Le reste du temps, les serveurs destinés à la gestion de ces charges sont sous-exploités. Les applications conçues pour une mise à l'échelle flexible peuvent tirer parti de Azure grâce à la possibilité de créer de nouvelles instances en ligne pendant les pics d'activité et de revenir aux niveaux de traitement habituels et à des capacités normales lorsque les besoins sont plus faibles. De cette manière, sous réserve de disposer d'applications correctement managées et structurées, Azure vous permet de payer uniquement le service dont vous avez besoin.

  • Mutualisation : pour les fournisseurs de services, Azure propose plusieurs méthodes pour fournir des services d'application à un nombre quelconque de clients de la même infrastructure, ce qui réduit les coûts d'exploitation.

  • Concentration sur les applications : les fournisseurs de services souhaitent généralement concentrer leurs ressources davantage sur le développement d'applications et de fonctionnalités, plutôt que sur la gestion de l'infrastructure. Azure vous libère d'une grande partie de la charge administrative requise par l'infrastructure d'hébergement des applications sur serveur traditionnelles ou des applications sur site. Il vous permet de concentrer vos ressources sur le développement des applications et des fonctionnalités.

  • Réduction des ressources requises pour l'infrastructure : lorsque vous structurez vos applications pour tirer parti de la mise à l'échelle flexible d'Azure, les instances des rôles et des ressources sont allouées à mesure qu'elles sont requises. Aucun investissement matériel préalable n'est requis, et vous n'avez pas besoin de maintenir les serveurs utilisés pour gérer les pics de charge pendant les périodes d'utilisation normale.

Outre la plateforme traditionnelle offrant des avantages orientés service, Azure peut héberger des ordinateurs virtuels. Ces dernier peuvent exécuter tous les systèmes d'exploitation pris en charge par Azure, et exécuter les applications comme si elles étaient exécutées sur site. Consultez Vue d'ensemble des machines virtuelles Azure pour obtenir la liste des systèmes d'exploitation pris en charge. Ces ordinateurs virtuels peuvent également faire partie d'une plus grande architecture applicative, pouvant inclure des instances de rôles web ou de processus, et d'autres composants Azure. Les ordinateurs virtuels vous permettent de déplacer des services ou des composants applicatifs moins facilement migrables vers Azure. Pour plus d'informations, consultez Migration with Azure Virtual Machines.

Dans la phase d'analyse et de conception, vous devez identifier les applications pouvant bénéficier du déplacement vers Azure. Ensuite, commencez à concevoir l'implémentation de Azure et planifiez-la. Durant cette phase, vous devez planifier la conception de l'architecture et la chronologie.

Voici quelques éléments clés de la planification :

  • Identification des défis actuels : la liste suivante affiche quelques exemples de problèmes à identifier lors d'une planification destinée à répondre à un besoin de re-structuration :

    • Composants d'application qui ne s'exécutent correctement aux charges actuelles sur l'architecture actuelle : par exemple, si une requête SQL ne fonctionne pas de façon satisfaisante, vous devez la régler avant la migration ou toute conception supplémentaire. Vous devez également reconcevoir et monter en puissance tous les composants de la couche Application.

    • Détermination des conditions d'une mise à l'échelle flexible : vous devez déterminer la façon dont votre application peut être décomposée en unités fonctionnelles, pouvant être mises à l'échelle et exécutées indépendamment les unes des autres.

    • Modèles de charge inégaux : vous devez identifier les modèles de charge inégaux et concevoir l'application de sorte qu'elle puisse monter en charge en cas de pic d'activité. Vous devez élaborer des plans pour gérer le niveau de la montée en charge entre les pics d'activité et les périodes de faible demande.

    • Projections de croissance : souvent, les projections de croissance sont le facteur qui alerte en premier le service informatique qu'une modification de paradigme est nécessaire. Déterminez si la montée en cherge est une solution pour répondre aux projections de croissance. Les projections de croissance sont également l'indicateur à prendre en compte pour envisager des changements de paradigme tels que le basculement vers un modèle d'analyse de gros volumes de données dans certaines applications centrées sur l'entrepôt de données. Lors de la phase de planification, vous devez envisager l'ensemble de ces options. Gardez à l'esprit que la solution optimale ne se présentera à vous qu'ultérieurement, lors des processus de conception et de mise en oeuvre. Vous devez lister toutes les possibilités et les facteurs déterminants afin de pouvoir les évaluer le moment venu, par exemple, lors de la migration initiale ou ultérieurement.

  • Identification de besoins techniques : déterminez les exigences de chaque composant de votre application tant en période de pic d'activité qu'en période creuse. Ensuite, planifiez la mise à l'échelle de chaque composant. Chaque composant peut avoir une capacité et un mécanisme de mise à l'échelle différents. Les spécifications techniques ne doivent pas tenir compte uniquement des performances. Par exemple, les spécifications pour une haute disponibilité et la récupération d'urgence, ou celles pour une latence réseau maximale, doivent être déterminées et comparées avec les capacités de Azure lorsque vous planifiez une migration. La liste suivante répertorie quelques exemples de spécifications techniques :

    • Utilisation du stockage relationnel : examinez les données stockées dans les bases de données relationnelles. Les données qui sont réellement relationnelles et transactionnelles par nature, ou les données qui nécessitent réellement le traitement transactionnel doivent rester dans le stockage relationnel. Vous pouvez utiliser une Base de données SQL sur Azure (Base de données SQL) ou SQL Server exécuté sur des machines virtuelles, pour stocker ce type de données. Vous pouvez stocker efficacement d'autres types de données dans le service Table de Azure, dans le stockage Blob de Azure ou dans les disques de Azure. Nous vous recommandons d'identifier le type de stockage nécessaire pour chaque partie de vos données.

    • Choix du stockage de vos données relationnelles : le choix d'une base de données SQL ou de SQL Server s'exécutant sur des machines virtuelles Azure dépend de plusieurs facteurs. Si vous souhaitez supprimer la charge administrative liée à la haute disponibilité, à l'équilibrage de charge et au basculement transparent, la Base de données SQL est le meilleur choix. Toutefois, dans la phase intermédiaire d'une migration d'application, ou dans des cas spéciaux où les fonctionnalités ne sont pas encore disponibles dans la Base de données SQL, SQL Server s'exécutant sur des ordinateurs virtuels de Azure peut être la meilleure solution. Les réponses à ces questions dépendent de la situation et de la solution. La liste suivante présente un certain nombre d'éléments à prendre en considération à ce sujet :

      • Taille de base de données : les bases de données Azure SQL sont actuellement limitées à 5 Go de données pour la base de données Web Edition, et à 150 Go de données pour la base de données Business Edition. Pour étendre la capacité de la base de données, utilisez une méthode de montée en charge. Pour en savoir plus sur les méthodes de montée en charge d'Azure, consultez la page « Montée en puissance parallèle de bases de données SQL Azure ». Pour obtenir des informations plus récentes sur les éditions disponibles et la taille des bases de données, consultezComptes et facturation de la Base de données SQL Azure.

      • Nombre de bases de données : par défaut, une base de données SQL prend en charge jusqu'à 6 serveurs par abonnement, et 150 bases de données dans chaque serveur de base de données SQL, y compris la base de données master. Une extension de cette limite est disponible. Pour plus d'informations, contactez un représentant du support technique à partir du Portail Clients de Microsoft Online Services.

      • Requêtes de bases de données croisées : une base de données SQL ne prend pas en charge les jonctions de bases de données croisées ou d'autres requêtes de base de données croisées. Si vous disposez d'unions ou des jointures qui requièrent des données provenant de plusieurs bases de données dans la Base de données SQL, vous devez appliquer cette logique dans la couche Application de votre application.

      • Objets CLR (Common Language Runtime) : une base de données SQL ne prend pas actuellement en charge les procédures stockées, les agrégations, les déclencheurs ou les fonctions CLR. Vous devez déplacer les procédures stockées, les déclencheurs ou les fonctions dans Transact-SQL pour leur exécution dans la Base de données SQL. La logique ou les opérations complexes, telles que les agrégations, qui ne peuvent pas être exécutées dans Transact-SQL au niveau de la base de données doivent être déplacées dans la couche applicative. Vous pouvez utiliser un rôle de travail pour effectuer ce travail.

      • Types de données : une base de données SQL ne prend pas en charge certains types de données système de SQL Server. Pour obtenir des informations plus récentes, consultez Data Types (SQL Database) dans la bibliothèque SQL MSDN.

      • Réplication : les types de réplication tels que la réplication transactionnelle ou la réplication de fusion ne sont pas disponibles dans une base de données SQL. Vous pouvez les configurer et les exécuter dans SQL Server s'exécutant sur des ordinateurs virtuels de Azure. Vous pouvez utiliser la synchronisation des données SQL pour synchroniser des données entre des instances de Base de données SQL. Cependant, le service de synchronisation des données SQL peut ne pas donner des résultats satisfaisants si une cohérence transactionnelle ou des résolutions de conflit complexes sont requises. Avertissement : la synchronisation de données SQL est actuellement disponible uniquement en version préliminaire, afin de recueillir des commentaires pour les versions futures, mais ne doit pas être utilisée dans des environnements de production.

      • Recherche en texte intégral : une base de données SQL Azure ne prend pas actuellement en charge la recherche en texte intégral. Si votre application exécute des requêtes de texte intégral sur des données character dans des tables SQL Server, vous pouvez envisager de migrer votre base de données vers SQL Server dans une machines virtuelle Azure. Pour plus d'informations sur SQL Server dans une machine virtuelle Azure, consultez la rubrique Migration vers SQL Server dans une machine virtuelle de Azure.

      • Licences : une base de données SQL est facturée par mois en fonction de la taille choisie. SQL Server requiert une licence lorsqu'il s'exécute sur une machine virtuelle Azure.

      • Connexion et sécurité : l'authentification Windows (sécurité intégrée) n'est pas prise en charge dans une base de données SQL, mais est disponible pour SQL Server s'exécutant sur des machines virtuelles Azure. Pour plus d'instructions et pour connaître les limitations de la Base de données SQL, consultez Instructions de sécurité et limitations de la Base de données SQL Azure.

  • Connexion et sécurité de l'utilisateur : grâce aux nouvelles améliorations réseau apportées à Azure, un domaine Active Directory actif sur un réseau local peut maintenant être étendu à Azure. Pour plus d'informations, consultez Migration with Azure Virtual Machines. Pour des informations détaillées sur l'administration de la sécurité dans la Base de données SQL, consultez Gestion des bases de données et des connexions dans Base de données SQL Azure.

  • Décomposition fonctionnelle de l'application : identifiez à quel endroit l'application peut être décomposée en unités fonctionnelles pour pouvoir s'exécuter dans des rôles ou des machines virtuelles Azure distincts. Cela permet une mise à l'échelle flexible et autorise les applications hybrides dans le cas de certaines applications qui ne conviennent pas pour le cloud computing..

  • Payment Card Industry (PCI) et autres exigences réglementaires : avant de déplacer une application ou un composant vers Azure, vérifiez l'état actuel des certifications ou exigences requises. Par exemple, pour les exigences de conformité PCI, vous pouvez ne pas migrer vers Azure certaines parties de l'application et de la base de données, et exécuter une application hybride. Cela vous permet de bénéficier des avantages de Azure et du cloud computing pour la plupart des composants, tout en continuant à garantir un contrôle institutionnel strict et la conformité des parties des données et de l'application qui l'exigent.

  • Composants clés ne pouvant pas être hébergés sur une plateforme Azure : il est possible que vous ne puissiez pas héberger certains composants ou certains types de données dans le cloud public pour d'autres motifs. Identifiez ces composants et envisagez d'utiliser une application hybride. Avec une architecture hybride, vous pouvez héberger certains composants dans Azure et profiter pleinement des avantages du cloud computing. En même temps, vous continuez à garantir un contrôle institutionnel strict et la conformité des parties des données et de l'application qui l'exigent.

Une fois que vous avez défini l'étendue de la migration, la quantité de travail pour chaque phase du plan de migration apparaît clairement. Examinez chaque application et chaque composant de données et estimez le temps et les ressources requis pour le développement, le test et la migration. En décomposant fonctionnellement votre application, vous pouvez développer les différents éléments en parallèle pour produire des composants pouvant être mis à l'échelle de façon flexible.

Définissez les étapes importantes du projet, par exemple les tests fonctionnels et de performances, ainsi que les dates de livraison, dans votre plan de migration. La migration peut comporter une série d'étapes et d'itérations à mesure que les différents composants sont prêts pour Azure, ou à mesure qu'ils sont prêts pour être déplacés dans les rôles web et de travail de Azure.

Lorsque la chronologie de développement et de migration est définie, planifiez la croissance et déterminez ce qui doit être effectué sur l'application et l'infrastructure existantes. Ce type de planification vous permet d'utiliser votre système existant jusqu'à ce que la migration soit terminée. Lorsque vous élaborez cette planification temporaire, identifiez les points d'accroche et déterminez ce qui doit être fait pour poursuivre les opérations, et quelles sont les opérations d'échelle qui peuvent continuer sur l'infrastructure temporaire. En outre, identifiez les étapes dont vous aurez besoin pour poursuivre les opérations. Souvent, ces étapes consistent simplement à paramétrer une requête SQL ou à ajouter un serveur Web, selon les caractéristiques spécifiques à votre application. Identifiez les plans d'urgence en cas de croissance plus rapide que prévu ou de pics d'activité inattendus. Lorsque vous élaborez vos plans d'urgence, déterminez si les pics d'activité ou la croissance peuvent être assurés par une montée en puissance vers le service Machines virtuelles Azure, car cela peut vous permettre de gérer ces situations sans devoir investir dans du matériel supplémentaire.

Tout plan de migration doit inclure des plans détaillés de test des fonctionnalités et de la charge. La description des méthodologies de test dépasse le cadre de cet article. La liste suivante répertorie quelques points importants à ne pas oublier lors des tests :

  • Automatisez les scripts de test.

  • Testez tous les niveaux et les composants de votre application.

  • Testez en utilisant les taux d'activité réels de vos systèmes.

  • Testez jusqu'au maximum de votre utilisation prévue, et au-delà.

Il est recommandé de prévoir suffisamment de temps pour les tests de la build et d'exécution, ainsi que pour la résolution des problèmes rencontrés lors du test.

Lorsque vous définissez les exigences opérationnelles et techniques, identifiez les ressources nécessaires pour réussir la migration. Vous devrez peut-être étoffer les équipes pour la migration. Lorsque vous identifiez les ressources, tenez compte de ces trois points :

  • Personnel : vous devrez peut-être embaucher des employés possédant des compétences supplémentaires pour migrer correctement votre application. En outre, après la migration, les rôles du personnel technique peuvent changer et vos employés auront peut-être besoin d'être formés. Par exemple, les rôles d'administrateur de comptes et d'administrateur de services peuvent gérer les connexions, l'accès et le service, et monter en puissance les niveaux.

  • Outils : identifiez les outils dont vous avez besoin pour développer, tester et déployer votre application Azure. Pour plus d'informations, consultez Azure Tools pour Microsoft Visual Studio et Prise en charge des outils et utilitaires de la base de données SQL Azure.

  • Conseil : vous pouvez avoir besoin d'une expertise spécifique pour migrer votre application. Un spécialiste de la migration peut vous faire gagner un temps considérable et vous faire économiser de l'argent en vous évitant les pièges courants.

Pour les petites application, le portail de gestion Azure peut suffire pour la gestion des déploiements Azure. Le portail de gestion Azure vous permet de vous connecter et de gérer vos déploiements et vos applications, ainsi que modifier le nombre de rôles d'instance et de gérer les instances de la Base de données SQL. Toutefois, pour les applications complexes et celles qui fournissent un service aux clients, le portail de gestion Azure peut ne pas être suffisant.

Azure expose l'API REST pour vous permettre de gérer par programmation des applications et des ordinateurs virtuels hébergés dans Azure, ainsi que pour mettre en service et utiliser le stockage Windows azure. Vous pouvez écrire une interface de gestion pour gérer la mise à l'échelle et l'analyse de votre environnement Azure. Votre plan de migration doit inclure un plan de gestion de l'application après la migration, surtout si cette gestion concerne une interface ou une automatisation personnalisée.

Pour plus d'informations sur l'API REST pour la gestion de vos déploiements Azure, consultez Références de l'API pour Azure.

Voir aussi

Afficher:
© 2015 Microsoft