Exporter (0) Imprimer
Développer tout

Vue d'ensemble du cycle de vie de la migration dans Azure

Mis à jour: avril 2014

Le cycle de vie de migration comprend une méthodologie standard qui fournit des instructions pas-à-pas pour migrer vos applications et vos données vers . Les étapes de migration principales sont la phase d'analyse, la phase de migration de l'application, la phase de migration des données, la phase de test et d'optimisation et la phase d'exécution et de gestion, comme le montre le schéma ci-dessous.

Cette rubrique décrit chaque phase en détail et comporte des liens vers des informations supplémentaires.

prend également en charge Oracle sur les machines virtuelles . Pour plus d'informations, consultez Images de machine virtuelle Oracle pour Azure.

Auteur : Kun Cheng, Selcin Turkarslan, Norberto Garcia
Réviseurs : Paolo Salvatori, Steve Howard, Stuart Ozer

L'objectif de cette phase est de comprendre les exigences opérationnelles qui nécessitent une solution . Après avoir identifié les objectifs, examinez l'architecture d'application existante pour identifier les principales différences entre et des solutions sur site et pour déterminer si vous avez besoin de reconcevoir l'application existante sur site pour répondre aux besoins d'une solution . Les tâches et les questions suivantes vous permettent de créer un plan de migration :

  • Définir les exigences opérationnelles : il existe plusieurs problèmes potentiels liés aux scénarios d'entreprise lorsqu'une application s'exécute sur  :

    • La solution de déploiement vers cible-t-elle de nouveaux clients et utilisateurs ?

    • Exige-t-elle une architecture mutualisée pour prendre en charge plusieurs clients ?

    • L'application répond-t-elle aux règlements de conformité lorsque les données sont hébergées dans des centres de données Microsoft à la place des sites clients ?

    • Quelles applications sont-elles plus adaptées au cloud structuralement et stratégiquement ?

    • Quel type de migration convient le mieux à mon application : la migration de l'application complète et de toutes les dépendances vers  ; ou bien, la migration d'une partie de l'application dans le cloud tandis que certaines ressources restent sur site ; ou encore, la migration d'une application vers les rôles Web ou de travail avec des dépendances qui fonctionnent mieux sur une machine virtuelle .

    Les réponses à ces questions ont un impact sur la façon dont une application se comporte sur la plateforme .

  • Déterminer les différences entre les fonctionnalités : pouvez-vous exécuter votre application existante dans sans aucune modification ? Par exemple, la Base de données SQL (Base de données SQL) ne prend pas en charge toutes les fonctionnalités de SQL Server sur site. Si vous souhaitez déplacer une application sur site qui utilise le CLR (Common Language Runtime) dans la Base de données SQL, vous devez reconcevoir l'application en déplaçant la logique CLR depuis SQL Server vers la couche Application, ou réécrire la logique CLR à l'aide des instructions Transact-SQL prises en charge par la Base de données SQL. Notez que la Base de données SQL ne prend pas actuellement en charge le CLR de SQL.

    À compter de la version 2012, de nouvelles fonctionnalités de machine virtuelle ont été ajoutées à . Avec les machines virtuelles , vous pouvez migrer vos applications SQL Server existantes basées sur la plateforme Windows Server vers la plateforme avec peu de changement de code, voire aucun. Avec SQL Server dans une machine virtuelle , les administrateurs et les développeurs peuvent utiliser les mêmes outils de développement et d'administration disponibles sur site. Les performances d'une base de données relationnelle dans une machine virtuelle dépendent de nombreux facteurs, notamment de la taille de la machine virtuelle, du nombre de disques et de leur configuration, du réseau, de la configuration du logiciel de base de données et de la charge de travail de l'application. Nous recommandons que les développeurs évaluent leur application sur plusieurs tailles de machine virtuelle et avec des configurations de stockage différentes pour choisir la solution la plus appropriée. Pour plus d'informations, consultez Migration vers SQL Server dans une machine virtuelle de Azure.

  • Préparer un plan de performances et d'extensibilité : de nombreuses applications héritées sont conçues pour être étroitement intégrées entre la logique d'application et les composants d'accès aux données. Pour les applications héritées, il est logique de découpler les composants de l'application pour une exécution et une mise à l'échelle optimales sur . Si l'application est trop bavarde ou interroge beaucoup les données, envisagez d'utiliser le service Caching de Azure ou implémentez votre propre mécanisme de mise en cache pour regrouper les requêtes d'accès aux données et réduire les boucles entre votre application et les données. Si l'application à migrer comporte de grandes bases de données ou un volume élevé de transactions, la migration vers la Base de données SQL nécessitera probablement la reconception du modèle de base de données. Cela est dû au fait qu'une instance de Base de données SQL unique peut gérer un nombre limité de transactions par seconde et est limitée en taille. Si vous traitez de grandes bases de données ou un volume élevé de transactions, envisagez d'implémenter une architecture avec montée en charge utilisant plusieurs bases de données dans la Base de données SQL, ou commencez par utiliser des méthodes de montée en charge au lieu de monter en puissance localement en achetant des systèmes coûteux. L'implémentation de l'OLTP en mémoire ou d'une durabilité différée pour vos tables avec des volumes élevés de transactions doit également être prise en compte afin d'améliorer les performances. Pour plus d'informations sur l'OLTP en mémoire, consultez OLTP en mémoire (optimisation en mémoire). Pour plus d'informations sur la durabilité différée, consultez Contrôler la durabilité d'une transaction.

    Pour plus d'informations sur les éléments à prendre en considération pour les performances lors de l'utilisation de SQL Server sur une machine virtuelle, consultez Considérations relatives aux performances de SQL Server sur les machines virtuelles Azure et le livre blanc Guide des performances pour SQL Server dans des machines virtuelles Azure.

    La Base de données SQL a lancé un aperçu Premium limité de Base de données SQL. En réservant une capacité fixe de votre Base de données SQL et de ses réplicas secondaires, le service Premium offre une meilleure prévisibilité des performances pour les applications de cloud, par rapport aux éditions Web et Business existantes de Base de données SQL. Pour plus d'informations sur les comptes Premium de Base de données SQL, consultez Gestion d'une base de données Premium et Aperçu Premium du Guide de Base de données SQL.

  • Préparer un plan pour la gestion du cycle de vie de l'application : il est important de tenir compte des versions et des scénarios de mise à niveau dans . Selon votre contrat de niveau de service, vous devrez peut-être conserver plusieurs versions de votre application pour prendre en charge vos différents niveaux de clients. Vous pouvez aussi réduire le temps mort lorsque vous mettez à niveau une application dans . Nous vous conseillons de conserver avec soin l'environnement temporaire et l'environnement de production dans . Assurez-vous que vous pouvez restaurer les mises à niveau validées en cas de problèmes de compatibilité. Votre plan de restauration de mise à niveau doit couvrir d'abord votre application, puis la base de données.

Après cette phase, nous vous recommandons de générer un projet pilote, car il fournit une vision claire des services et des outils de la plateforme .

Une fois que vous avez décidé de migrer votre application vers , commencez par une version pilote contenant peu de données, pour générer une preuve de concept. D'abord, vous devez implémenter les modifications de code requises dans votre application pour atteindre les objectifs de déploiement vers en termes de spécifications techniques et d'entreprise. Ensuite, compilez et déployez le code de l'application sur les rôles appropriés dans .

En général, la plupart des applications existantes sur site peuvent s'exécuter dans les services de cloud computing de moyennant très peu de modifications, voire aucune, mais cela peut créer des problèmes de performances, d'évolutivité et de sécurité. Pour optimiser les performances et garantir l'évolutivité, nous vous recommandons de reconcevoir votre application en utilisant plusieurs rôles avant la migration vers les services de cloud computing de . Pour plus d'informations, consultez Éléments à prendre en considération pour le développement des services de cloud computing Azure. Nous vous recommandons de commencer par déplacer votre application complète vers les services de cloud computing de , puis de déplacer les données. Pour des raisons de sécurité, de performances ou autres, certaines parties de l'application doivent parfois résider sur site. Cela requiert des solutions hybrides. Pour plus d'informations, consultez Solutions hybrides avec Azure.

Si vous décidez d'utiliser SQL Server dans une machine virtuelle , modifiez vos applications SQL Server existantes pour vous connecter à la base de données SQL Server dans une machine virtuelle . En outre, suivez l'une des méthodes de migration suivantes :

  • Il est possible que vous possédiez déjà une application fonctionnant sur une machine virtuelle existant. Vous pouvez migrer cette machine virtuelle dans . Dans ce cas, votre application, ses paramètres de configuration et ses données existent déjà dans cette machine virtuelle. Cependant, vous devrez peut-être télécharger un fichier .vhd volumineux vers . En outre, il peut y avoir des dépendances de pilotes et matérielles sur votre machine virtuelle existante, et celles-ci peuvent ne pas être disponibles dans .

  • Vous pouvez générer une machine virtuelle dans . Pour effectuer cette opération, vous pouvez créer une machine virtuelle de la Bibliothèque d'images, qui contient déjà SQL Server. Ensuite, installez votre application sur cette machine virtuelle. Cela réduit le temps de téléchargement et supprime les dépendances de pilote et matérielles, mais requiert l'installation de l'application et le téléchargement des données.

Pour plus d'informations sur la migration de bases de données SQL Server existantes vers SQL Server dans une machine virtuelle , consultez la rubrique Migration vers SQL Server dans une machine virtuelle de Azure.

Si vous utilisez les services de cloud computing de , déplacez les données relationnelles depuis SQL Server sur site vers la Base de données SQL et déplacez les données non structurées vers un service de stockage comme Blob, Table ou Lecteurs . Pour plus d'informations, consultez Migration des données vers les services de Table et Blob de Windows Azure et Migration de bases de données SQL vers la Base de données SQL de Azure.

Si vous décidez d'utiliser SQL Server sur des machines virtuelles , vous pouvez suivre l'une des deux méthodes de migration suivantes :

  • Vous pouvez avoir des données sur une machine virtuelle existant. Vous pouvez charger cette machine virtuelle existante dans un fichier .vhd et le télécharger sur .

  • Vous pouvez générer une machine virtuelle dans . Ensuite, vous pouvez charger les données dans un fichier .vhd et le télécharger sur . Ensuite, vous pouvez attacher ce fichier .vhd téléchargé, ou un disque vide, à la machine virtuelle en tant que disque de données. Vous pouvez utiliser les disques de données pour stocker les journaux et les fichiers de données SQL Server. En outre, vous pouvez utiliser les outils et les techniques décrits dans la rubrique Migration vers SQL Server dans une machine virtuelle de Azure pour migrer vos bases de données SQL Server existantes depuis SQL Server vers une machine virtuelle .

Après avoir migré votre application et vos données vers , effectuez les tests fonctionnels et de performances. Dans cette phase, testez votre application dans le cloud et vérifiez qu'elle fonctionne comme prévu. Ensuite, comparez les performances entre l'application sur site et l'application sur . Après cela, résolvez tous les problèmes de fonctionnalités, de performances ou d'évolutivité de votre application dans le cloud. Pour plus d'informations, consultez Mise en œuvre d'un plan de migration pour Azure.

Après la phase de test et d'optimisation, configurez et implémentez un contrôle et un suivi d'application à l'aide des diagnostics . Les diagnostics vous permettent de collecter des données de diagnostics pour une application exécutée dans . Utilisez les données de diagnostic pour le débogage et le dépannage, pour mesurer les performances, pour surveiller l'utilisation des ressources, pour l'analyse et la planification des capacités du trafic, et pour l'audit. Pour plus d'informations, consultez Diagnostics et débogage dans Azure dans la bibliothèque MSDN.

Si vous devez synchroniser les données entre l'application sur site et la Base de données SQL ou entre des serveurs de Base de données SQL différents, installez et configurez le service Synchronisation des données SQL (Aperçu). En outre, nous vous recommandons de prévoir et de configurer un plan de récupération des données en cas d'erreurs d'utilisateur ou de catastrophes naturelles. Pour plus d'informations, consultez Éléments à prendre en considération pour la haute disponibilité et la récupération d'urgence avec la Base de données SQL de Azure.

Voir aussi

Afficher:
© 2014 Microsoft