Exporter (0) Imprimer
Développer tout

Mise en œuvre d'un plan de migration pour Azure

Mis à jour: avril 2014

Azure est une plateforme informatique de services à l'échelle d'Internet hébergée dans les centres de données Microsoft. Avec Azure, les développeurs et les administrateurs n'ont pas besoin d'implémenter le logiciel sous-jacent et l'infrastructure de matériel car tous les systèmes d'exploitation, les matériels, les réseaux, les ressources de stockage et les mises à jour de plateforme sous-jacents sont automatiquement pris en charge par Microsoft.

Après avoir migré votre application dans le cloud, nous vous recommandons fortement d'exécuter les tests fonctionnels et de performances sur votre application, exactement comme vous le faites pour toute application récemment déployée. Étant donné que Azure est différent de votre plateforme sur site, vous devez prendre en compte un certain nombre d'éléments importants lorsque vous implémentez la migration :

Notez que le thème de cette rubrique concerne principalement les services de cloud computing de Azure. Pour obtenir des informations de base sur la migration avec SQL Server dans une machine virtuelle de Azure, consultez Migration avec le service d'ordinateur virtuel de Windows Azure.

Auteur : Kun Cheng, Steve Howard
Contributeurs : Selcin Turkarslan

Configuration des tests de validation

Lors de la migration de vos applications dans le cloud, vous devez savoir comment les tester et les déboguer afin de vous assurer qu'elles fonctionnent comme prévu dans le cloud. Voici la liste des méthodes que vous pouvez utiliser pour tester votre application :

  • Azure Tools pour Microsoft Visual Studio : Vous pouvez créer votre application puis exécuter et déboguer localement cette application à l'aide des émulateurs de calcul et de stockage fournis dans Windows Azure Tools. Cela vous permet de développer votre application localement avant de la publier sur Windows Azure. Azure Tools pour Microsoft Visual Studio étend Visual Studio 2010 et vous permet de tester votre application avec des émulateurs de calcul et de stockage qui fournissent la plupart des fonctions de Azure. Nous vous recommandons d'effectuer ce type de test lors des premières phases du test fonctionnel. Pour plus d'informations, consultez Azure Tools pour Microsoft Visual Studio.

  • SQL Server Data Tools : SQL Server Data Tools (SSDT) offre un environnement intégré dans Visual Studio 2010 qui permet de concevoir des bases de données, de créer ou modifier des objets de base de données et des données, ou encore d'exécuter des requêtes pour toutes les plateformes SQL prises en charge ; notamment, la Base de données SQL Microsoft Azure hors site et Microsoft SQL Server 2012 sur site. Il vous permet de tester vos solutions de base de données à l'aide de la base de données locale par défaut ou la Base de données SQL Microsoft Azure en examinant la partie de l'application relative à l'accès aux données relationnelles. Pour plus d'informations, consultez SQL Server Data Tools. Remarque : Azure Tools pour Microsoft Visual Studio et SSDT vous permettent de réaliser les tests de fonctionnalité et de compatibilité de base sur votre application, avec des sources de données en ligne et hors connexion. Pour tester tous les aspects d'une véritable application de cloud en termes de fonctionnalité, de performances et d'évolutivité, vous devez effectuer un test de simulation dans Azure, une fois l'application déployée et exécutée.

  • Infrastructure de test automatique : de nombreuses applications existantes possèdent déjà une infrastructure de test automatique qui permet de s'assurer que tous les composants et toutes les fonctionnalités de l'application fonctionnent comme prévu. Lorsqu'une application s'exécute sur Azure, l'infrastructure de test automatique peut ne pas fonctionner en raison de sa conception. Si l'infrastructure de test automatique doit être exécutée sur site mais peut se connecter à une application dans Azure à l'aide de points de terminaison définis, il est possible qu'elle fonctionne. Sinon, il est recommandé d'héberger à la fois l'infrastructure de test automatique et votre application dans Azure pour réduire les problèmes potentiels de perte de connexion et de latence.

  • Test de charge de Visual Studio : si une application ne possède pas d'infrastructure de test automatique, nous vous recommandons de créer une nouvelle infrastructure et d'utiliser le test de charge de Visual Studio pour simuler l'utilisation avec plusieurs utilisateurs simultanés.

Synchronisation des bases de données pour réduire le temps de basculement

Entre la phase de test, la phase intermédiaire et la phase de production, vous devez essayer de réduire le temps de basculement autant que possible. Cela peut prendre plusieurs heures voire des jours de copier une base de données de grande taille sur site vers Azure. En outre, il est peu probable que vous soyez disposé à ne pas utiliser votre application pendant le temps nécessaire pour migrer entièrement les données existantes. C'est pourquoi, vous devez élaborer un plan visant à réduire le temps mort lié au basculement. Notez que le basculement désigne le temps nécessaire pour exécuter le déplacement final vers Azure. Avant de basculer, consultez vos tables et identifiez celles qui contiennent des données statiques et celles qui contiennent des données qui peuvent changer pendant le basculement. Pour les données statiques, il n'est pas nécessaire de les déplacer pour le basculement. Toutefois, si vous ne savez pas avec certitude si les données d'une table peuvent changer pendant le basculement, vous devez inclure une logique dans votre système pour migrer toutes les modifications ultérieurement. Il est également recommandé de déterminer si toutes les données de vos systèmes sur site doivent être migrées dans le cloud avant de mettre en ligne l'application sur Azure. Si votre application peut être mise en ligne et les données peuvent être récupérées ultérieurement, vous pouvez supprimer tout temps mort.

Toutefois, si les données dans Azure doivent être cohérentes avec les données sur site avant de passer en ligne sur Azure, envisagez de réduire la quantité de données à migrer au moment du basculement, car cela permet de minimiser le temps mort nécessaire pour le basculement. Dans certains cas, il peut être approprié de déplacer une partie de vos données avant le basculement, puis de déplacer les données restantes après le basculement réel. Dans ces cas, votre plan de migration doit identifier clairement les données qui doivent être migrées d'abord, ainsi que les données restantes, qui peuvent être migrées après le basculement. Cela permet de mettre en ligne votre application sur Azure avec moins de temps mort, car elle peut être mise en production pendant que vous migrez les données restantes. Vous pouvez utiliser les méthodes de synchronisation de données suivantes pour migrer les données avant le basculement :

Synchronisation des données SQL de Azure

Windows Azure Le service Synchronisation des données SQL (Aperçu) fournit des fonctionnalités de synchronisation des données pour les bases de données SQL : SQL Server et Base de données SQL. Le service propose actuellement deux fonctionnalités :

  • La synchronisation des données entre les bases de données SQL Server sur site et les instances de Windows Azure Base de données SQL, ce qui permet aux applications informatiques et sur site d'utiliser des données identiques.

  • La synchronisation des données entre plusieurs instances de Windows Azure Base de données SQL ; les instances peuvent être dans le même centre de données, dans différents centres de données ou dans différentes régions.

Windows Azure Synchronisation des données SQL (Aperçu) est une bonne option pour synchroniser des bases de données sur site et des instances de Windows Azure Base de données SQL dans les situations suivantes :

  • Vous devez effectuer des tests d'applications parallèles.

  • Vous devez exécuter votre application en parallèle avant le déplacement final de toutes les opérations de données sur site vers Windows Azure.

  • Lors de la migration vers Windows Azure, vous devez exécuter l'application sur site et, en même temps, vous devez réduire au maximum le temps mort.

  • Vous devez effectuer une synchronisation des données continue dans le cadre d'une solution hybride entre l'application sur site et l'application Windows Azure.

Notez que pour assurer le suivi des modifications des données incrémentielles, lorsque le groupe de synchronisation est configuré, Synchronisation des données SQL (Aperçu) ajoute une table de suivi des modifications à chaque table qui est synchronisée. Si vous utilisez Synchronisation des données SQL (Aperçu), assurez-vous que vos planifications d'espace prennent en compte les tables de suivi des modifications. En outre, vous ne devez pas modifier les structures des tables ou des clés primaires des tables qui sont synchronisées après la configuration de la synchronisation, sauf si vous réinitialisez le groupe de synchronisation. Synchronisation des données SQL (Aperçu) ne convient pas si une synchronisation des données intermédiaires ou actuelles est requise.

Avertissement : Synchronisation des données SQL (Aperçu) est actuellement disponible uniquement en version préliminaire, dans le but de fournir des commentaires pour les versions futures, mais ne doit pas être utilisé dans des environnements de production.

Pour plus d'informations sur Synchronisation des données SQL (Aperçu), consultez SQL Data Sync (Preview).

Réplication, mise en miroir ou envoi de journaux

Vous pouvez utiliser la réplication, la mise en miroir ou l'envoi de journaux pour déplacer des données SQL Server sur site vers d'autres serveurs SQL Server sur site ou vers une instance de SQL Server s'exécutant sur une machine virtuelle Azure. Toutefois, vous ne pouvez pas utiliser ces fonctionnalités pour déplacer des données dans ou hors de la Base de données SQL de Azure. Pour plus d'informations, consultez Réplication et envoi de journaux et Mise en miroir de bases de données et envoi de journaux.

Personnaliser, extraire, transformer et charger (ETL)

Pour réduire le temps nécessaire pour migrer des données au moment du basculement, vous devez déplacer autant de données que possible dans la plateforme Azure avant le basculement réel. Vous pouvez créer un travail ETL personnalisé pour déplacer les données modifiées depuis votre système sur site vers votre environnement Azure. Lors de la migration de SQL Server 2008 sur site, ou d'une version ultérieure, il est recommandé d'utiliser la capture de données modifiées ou le suivi de données modifiées pour vous assurer que toutes les données modifiées, et uniquement celles-ci, sont réellement déplacées depuis la base de données sur site vers l'instance de Base de données SQL de Azure. Pour plus d'informations sur ces deux fonctionnalités, consultez Suivi des données modifiées dans la documentation en ligne de SQL Server. Pour les bases de données qui n'utilisent pas la capture ou le suivi de données modifiées, vous devez créer un système de suivi de vos modifications et des données qui ont été migrées. Dans tous les cas, il est préférable de déplacer le moins de données possible au moment du basculement réel, pour réduire le temps mort requis.

Exporter une application de la couche Données (DAC)

À l'aide de DAC, vous pouvez exporter des données d'une instance SQL Server et les placer dans le stockage des objets blob Azure, où elles peuvent être importées dans une Base de données SQL Azure. Avec DAC, vous pouvez définir des filtres pour identifier les tables qui doivent être importées ou exportées. Toutefois, vous ne pouvez pas configurer les filtres de ligne. C'est pourquoi, DAC convient si les tables complètes tiennent dans une seule base de données, mais ne fonctionne pas correctement avec les bases de données montées en charge. DAC ne convient pas pour migrer des applications de données si une synchronisation continue est requise. Pour plus d'informations, consultez Exporter une application de la couche Données dans la Documentation en ligne de SQL Server.

Sauvegarde et restauration

Le but de créer des sauvegardes de base de données est de vous permettre de récupérer les données perdues suite à des erreurs d'administration, à des erreurs d'application ou à la perte totale d'un centre de données. La sauvegarde et la restauration de données sont différentes dans la Base de données SQL de Azure par rapport à un environnement SQL Server sur site et doivent utiliser les ressources et les outils disponibles. Pour qu'elles soient efficaces, les sauvegardes et les restaurations à des fins de récupération doivent répondre à une stratégie de récupération et de sauvegarde de la Base de données SQL Azure. Il existe trois catégories générales de problèmes qui peuvent surgir dans une instance de Base de données SQL Azure :

  • Défaillances de l'infrastructure ou du matériel : dans un centre de données, des défaillances matérielles peuvent se produire. Par exemple, le nœud physique qui exécute votre instance de Base de données SQL de Azure peut s'arrêter.

  • Problèmes ou défaillances dus à l'application ou à l'utilisateur : Les utilisateurs ou les applications peuvent apporter des modifications indésirables aux données. Dans ce cas, une opération de restauration peut être nécessaire. Par exemple, un utilisateur peut modifier les données du mauvais client.

  • Perte de fonctionnalités de centre de données : le contrat de niveau de service de la Base de données SQL Azure prévoit spécifiquement une exception en cas de pertes dues à des facteurs externes échappant raisonnablement au contrôle de Microsoft, tels que des sinistres. En cas de sinistre, le centre de données peut être endommagé de telle sorte que les bases de données ne peuvent pas être récupérées à partir des réplicas ou des sauvegardes sur place.

Vous devez décider quel niveau de sécurité vous souhaitez en ce qui concerne les données stockées dans les centres de données de la Base de données SQL de Azure. Pour plus d'informations sur les outils de sauvegarde et de restauration disponibles et sur la façon de créer une stratégie de récupération d'urgence, consultez l'article Business Continuity in SQL Database dans la bibliothèque MSDN.

Basculer vers Azure

Lorsque vous procédez à la migration réelle de votre application dans Azure, les méthodes suivantes sont disponibles :

  • Exécution en parallèle : avec cette méthode, votre application peut s'exécuter en parallèle sur site et sur Azure. Cela vous permet de tester en conditions réelles votre application dans Azure avant qu'elle ne soit entièrement dépendante du cloud. Vos tests doivent inclure les suivants, sans s'y limiter : test de fonctionnalités, test de performances, test d'évolutivité. Lorsque vous avez complètement terminé de tester votre nouveau système sur Azure, effectuez la migration finale des données et arrêtez votre système sur site.

  • Pause et basculement : cette approche est appropriée lorsque toutes les données doivent être synchronisées avant de passer totalement en ligne sur Azure. Avec cette méthode, tous les tests fonctionnels et de performances doivent être au préalable effectués sur Azure. Ensuite, déterminez le système de réplication des données dans votre environnement Azure en utilisant l'une des méthodes de synchronisation des données spécifiées ci-dessus. Nous vous conseillons de maintenir les données aussi synchronisées que possible en réduisant le temps nécessaire pour la dernière synchronisation ou pour l'opération ETL avant le basculement final. Lorsque vous êtes prêt à basculer sur Azure, arrêtez le système sur site, effectuez la dernière synchronisation des données et mettez votre application en ligne sur Azure.

Voir aussi

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft