VENTES: 1-800-867-1389

Planification d'un projet de migration de Base de données SQL Azure

Mis à jour: avril 2014

Cette rubrique décrit les méthodes conseillées pour organiser et migrer une base de données SQL Server sur site vers Base de données SQL Microsoft Azure dans le cadre d'un projet de migration . Elle couvre les sujets suivants :

  1. Perspectives concernant la migration de base de données

  2. L'Analyse dans laquelle vous avez défini les objectifs du projet de migration de base de données

  3. La gestion du sous-projet de migration de données par le biais des phases de Planification et conception, Développer, Test, Stabilisation et Déploiement.

Auteur : Shaun Tinline-Jones
Contributeur : Steve Howard
Réviseur : Shawn Hernan

La migration de base de données est un sous-projet du projet à plus grande échelle de migration de solution. Il existe généralement des points d'intégration et des dépendances entre les projets de migration d'application et de base de données. Cependant, la migration de base de données peut généralement se faire en parallèle avec peu de goulots d'étranglement.

Dans un projet de migration Base de données SQL Azure, l'approche doit tenir compte de trois perspectives :

  • Le cycle de vie du projet doit être agile et itératif par nature. Créez un plan initial en vous basant sur vos premières recherches. Lors de la planification d'une nouvelle itération, affinez le plan en fonction des recherches effectuées lors des itérations précédentes.

  • La taille et la complexité de la base de données et de ses applications associées détermine de nombreux facteurs dans un projet de migration :

    • La complexité de la base de données détermine l'effort d'ingénierie requis pour migrer la base de données.

    • La taille de la base de données, soit la quantité de données qu'elle contient, détermine le temps nécessaire pour remplir la nouvelle base de données et basculer de la base de données sur site à la base de données dans Base de données SQL Azure.

  • La migration d'une base de données vers une nouvelle plateforme entraîne souvent des modifications qui affectent les autres couches de la solution qui utilisent la base de données. Le projet de migration doit coordonner le travail de développement entre toutes les couches affectées, et fournir un déploiement unifié de tous les composants modifiés.

Chaque base de données à migrer peut être classée dans l'un des quatre quartiers définis selon la taille et la complexité. Le quartier dans lequel se situe une base de données vous permet de comprendre l'étendue d'un projet de migration de la base de données vers Base de données SQL Azure et de choisir un mécanisme de migration approprié. Les quarties sont les suivants :

Une base de données volumineuse nécessite un basculement plus long vers Base de données SQL Azure, car il faudra davantage de temps pour transférer les données sur Internet. Plus une base de données est complexe, et plus il est probable que des modifications soient nécessaires, ce qui augmente d'autant la quantité de travaux d'ingénierie.

La taille et la complexité de la base de données source sont des aspects clés pour définir l'objectif du projet de migration.

Pendant la phase d'analyse, vous définissez l'objectif et la vision du projet. Les objectifs généraux du projet doivent inclure les objectifs de la base de données à migrer.

Toutes les bases de données doivent répondre aux besoins de l'entreprise, tels que la disponibilité, la récupération, le temps de réponse et à la conformité aux règles de sécurité et de protection des données. Lorsque vous migrez une base de données vers Base de données SQL Azure, configurez le service de base de données de sorte qu'il soit conforme aux besoins de l'entreprise, ou negociez un nouvel ensemble de conditions qui peuvent être remplies par Base de données SQL Azure. Il est également possible que vous soyez amené à modifier vos processus d'administration. Par exemple, si vous effectuez actuellement des sauvegardes de base de données nocturnes, vous devrez peut-être utiliser les fonctions de copie de base de données ou d'exportation d'application de la couche Données prises en charge par Base de données SQL Azure.

Les besoins de l'entreprise ne peuvent pas être déterminés en analysant la base de données et le code d'application existants. Vous devez déterminer les conditions requises en interrogeant les parties prenantes et les administrateurs, et en consultant les documents de processus tels que les contrats de niveau de service.

Les objectifs d'un projet de migration en ce qui concerne la migration de base de données doivent répondre aux besoins de la base de données et refléter sa taille et sa complexité. Les bases de données complexes requièrent pour la migration un plus grand effort d'ingénierie que les bases de données simples. Pour les réduire les risques liés à un projet de migration de base de données complexe, vous pouvez limiter le projet initial en migrant les fonctionnalités utilisées dans la base de données sur site. L'incorporation des fonctionnalités propres à la Base de données SQL Azure peut être effectuée dans le cadre de projets ultérieurs.

La phase d'analyse est essentielle pour les phases de planification et de conception. Il est important de vérifier la totalité des problèmes qui peuvent affecter la migration lors de la phase d'analyse, mais il est inutile d'entrer trop dans les détails durant cette phase. La première itération des phases de planification et de conception doit ensuite s'intéresser plus à fond aux détails pour former des conceptions et des plans plus granulaires. Mettez en place un processus de commentaires pour modifier les documents détaillant la vision et la portée selon les résultats issus des travaux initiaux de planification et de conception.

Évaluer la complexité d'un projet de migration Base de données SQL Azure équivaut à déterminer la quantité de modifications nécessaires pour réussir la migration. Les différentes étapes d'un projet de migration Base de données SQL Azure requièrent des estimations de plus en plus précises de l'étendue des modifications techniques nécessaires à la migration. Une première estimation générale doit être incluse dans la définition de l'objectif du projet et prise en compte dans la décision de lancer le projet. Elle forme également la base des travaux initiaux de planification et de conception du projet. Les résultats des recherches plus détaillées effectuées ultérieurement doivent servir à élaborer des plans de projet et des conceptions de plus en plus détaillés, et, éventuellement, à modifier les objectifs du projet.

Résolvez toutes les dépendances sur les fonctionnalités non prises en charge par Base de données SQL Azure dans le cadre du projet de migration. Pour identifier dès le départ ces dépendances, vous n'avez pas besoin d'accéder au système de production. Cette opération s'effectue en comparant la documentation existante sur les fonctionnalités prises en charge par Base de données SQL Azure aux documents de conception de base de données ou aux spécifications de l'application. La documentation peut également être consultée par les utilisateurs familiarisés avec la conception de bases de données et d'applications. Ultérieurement, certains types de dépendances peuvent être confirmés à l'aide d'outils tels que l'Assistant Migration de Base de données SQL Azure.

Plusieurs bases de données sur site ont des dépendances sur des services à l'extérieur de la base de données. La participation dans une topologie de réplication, un processus d'extraction Integration Services de SQL Server, ou des tâches de maintenance récurrentes gérées par l'agent SQL Server en sont un exemple. Le projet de migration doit inclure le coût et le temps de développement requis pour modifier les dépendances sur l'un de ces services. Supprimez les dépendances sur tous les services qui ne prennent pas en charge Base de données SQL Azure. Vous pouvez être amené à apporter des modifications aux autres systèmes qui prennent en charge Base de données SQL Azure en raison des différences d'architecture entre SQL Server et Base de données SQL Azure.

En outre, les bases de données sur site peuvent contenir des objets Transact-SQL non pris en charge dans Base de données SQL Azure. Les applications qui accèdent à la base de données, ainsi que le code d'objets de base de données tels que des procédures stockées ou des déclencheurs, peuvent également utiliser des éléments syntaxiques non pris en charge par Base de données SQL Azure.

La complexité d'une base de données peut être évaluée dès le départ en analysant la conception de la base de données et de l'application, ou le code, en tenant compte des problèmes abordés dans les documents suivants :

La migration d'une base de données vers Base de données SQL Azure requiert souvent des modifications dans les applications et les systèmes qui utilisent la base de données.

Commencez par apporter les modifications nécessaires pour que les applications fonctionnent efficacement dans un environnement Base de données SQL Azure. Base de données SQL Azure est un service Web hébergé en dehors du centre de données. Cela signifie que certaines meilleures pratiques applicables aux bases de données, dont l'impact est inexistant lorsque le serveur de bases de données se trouve dans le même rack que le serveur d'applications, deviennent importantes lorsque la base de données est migrée vers Base de données SQL Azure. Chaque base de données hébergée dans Base de données SQL Azure est en cluster sur plusieurs serveurs pour améliorer la disponibilité globale. Toutefois, certaines opérations, ou l'échec de votre serveur actif, peuvent entraîner un événement de basculement temporaire qui ferme toutes les connexions ouvertes et restaure les transactions actives. Il est alors important que vos applications appliquent une logique fiable entre deux tentatives afin de redémarrer une transaction lorsque l'application reçoit une erreur de déconnexion.

Pour plus d'informations sur les modifications d'application requises pour prendre en charge les bonnes performances, consultez Éléments à prendre en considération pour les performances de la Base de données SQL de Windows Azure.

Vous trouverez dans les documents suivants des modifications d'application supplémentaires, requises pour travailler efficacement avec Base de données SQL Azure :

Vous devez également apporter les modifications d'application requises pour répercuter toutes les modifications apportées à la base de données. Par exemple, si un agrégat défini par l'utilisateur est supprimé de la base de données, vous devez modifier toutes les applications qui exécutent les instructions Transact-SQL qui référencent l'agrégation.

Le travail de planification et de conception doit commencer pendant la phase d'évaluation de la complexité. Une partie essentielle de cette phase consiste à effectuer des recherches approfondies concernant les problèmes traités dans les deux sections qui suivent :

Lorsque les fonctionnalités devant être modifiées sont identifiés, faites une estimation initiale du travail de modification requis lors des premières itérations du projet. Chaque itération suivante doit donner lieu à une description plus complète de la base de données pour identifier toutes les modifications et pour formuler des définitions plus détaillées de l'étendue des modifications nécessaires. Mettez en place un processus de commentaires afin d'ajuster les objectifs et l'étendue du projet selon les résultats de la recherche plus détaillée effectuée pendant les itérations de planification et de conception. La première itération ne nécessite pas d'accès à l'environnement de production, mais doit aboutir à une réflexion raisonnablement précise de ce qui existe en production.

Vous pouvez obtenir cette première vue de planification en utilisant l'Assistant Migration de Base de données SQL Azure et en identifiant les différences entre SQL Server sur site et Base de données SQL Azure. Ces sujets sont présentés plus en détail dans les rubriques respectives. Les outils de données SQL Server (SSDT) s'avèrent très utiles à ce stade, surtout si la gestion du cycle de vie des applications (ALM) de la couche Données inclut l'utilisation de ces outils ou des scripts d'objets de base de données. L'effort à fournir est faible, et dépasse légèrement l'effort fourni par l'Assistant Migration de Base de données SQL Azure, mais cela reste raisonnable en termes de coûts. L'élégance de cette méthode repose sur les fonctions de productivité habituelles de Visual Studio, telles que le double-clic sur un avertissement et l'accès direct à la ligne concernée.

Vous pouvez vérifier votre estimation des problèmes tels que la prise en charge de Transact-SQL en utilisant plusieurs outils :

  • Vous pouvez connecter l'Assistant Migration de Base de données SQL Azure à une copie de test ou de production de la base de données sur site et générer un rapport sur les objets qui doivent être modifiés pour être exécutés sur Base de données SQL Azure. Pour plus d'informations, consultez Procédure : utiliser l'Assistant Migration SQL Azure.

  • Si tous les objets de la base de données sur site sont pris en charge par une application de la couche Données (DAC), vous pouvez extraire un package DAC et suivre l'une des procédures suivantes :

Alors que les outils d'évaluation peuvent aider à identifier les fonctionnalités qui ne sont pas prises en charge dans Base de données SQL Azure, ils ne reconnaissent pas nécessairement les autres fonctionnalités pouvant être utilisées pour obtenir la même fonctionnalité. Les planificateurs du projet doivent tenir compte de l'utilisation faite en entreprise des fonctionnalités et imaginer des alternatives prenant en charge également ces utilisations professionnelles. La décision de continuer doit être basée sur une estimation des coûts de développement et de déploiement des solutions alternatives, et non se limiter simplement à déconseiller l'utilisation de Base de données SQL Azure au motif qu'il ne prend pas en charge une fonctionnalité donnée.

Évitez d'inclure des objectifs autres que la migration, en particulier dans le cadre de migrations complexes. Le fait d'ajouter de la complexité est une erreur habituelle qui mène inévitablement à l'échec du projet. L'une des motivations les plus courantes est celle d'exploiter un modèle de base de données avec montée en puissance parallèle. Faites-le uniquement en cas de nécessité, par exemple :

  • Vous migrez une base de données plus volumineuse que la taille maximale prise en charge par Base de données SQL Azure.

  • Le cas d'entreprise n'est viable que si une architecture mutualisée est implémentée au départ.

  • Les spécifications de calcul de la base de données dépassent les possibilités d'une seule base de données Base de données SQL Azure.

La planification et la conception doivent tenir compte des coûts. Les facteurs de coût doivent être évalués lors de chaque phase et à chaque itération, et sont un élément important dans chaque décision de continuer. Cet élément peut être exclu de la planification et de la conception car la probabilité que ce risque devienne un problème est faible ; toutefois la sous-estimation des coûts peut avoir un niveau de gravité assez élevé.

L'attitude gagnante consiste à identifier les risques et à leur affecter une évaluation de probabilité et de gravité. Répertoriez tous les risques, même ceux qui semblent insignifiants. Assurez-vous que toutes les parties prenantes estiment que les risques les plus probables ont été correctement évalués. Vérifiez que chaque risque probable est accompagné d'un plan de limitation et d'une planification acceptable si le risque bascule en problème. Créez un processus pour ajouter des plans aux nouveaux risques identifiés lors de chacune des phases de la migration. Les problèmes détectés et résolus pendant la phase de déploiement finale doivent être enregistrés en tant que risques potentiels pour les projets à venir. Il est également important d'évaluer les risques tels qu'ils s'appliquent dans un environnement dans le cloud, et non la façon dont ils s'appliquent dans les environnements plus familiers sur site.

Il est important que le projet décrive exhaustivement toutes les fonctionnalités utilisées par la base de données par rapport à l'ensemble des fonctionnalités prises en charge dans Base de données SQL Azure, et qu'il estime les coût de conversion et les coûts d'exécution de la base de données dans Base de données SQL Azure. Cette analyse doit se faire suffisamment tôt dans l'itération pour que le projet puisse être annulé si les coûts pèsent plus lourd que les avantages tirés. Par exemple, un projet de migration Base de données SQL Azure a rencontré des problèmes relativement tard car les planificateurs ne s'étaient pas aperçus que la compression de données utilisée par la base de données sur site n'est pas prise en charge par Base de données SQL Azure. Cela a entraîné une augmentation majeure des coûts projetés pour l'exécution de la base de données sur Base de données SQL Azure. C'est typiquement le type de problème qui doit être identifié relativement tôt dans le projet.

Chaque itération dans les phases de planification et de conception doit inclure une estimation approfondie des modifications requises dans la couche Données. Par exemple, la deuxième itération peut inclure la création d'une trace du générateur de profils pour l'environnement de test fonctionnel, et son exécution au moyen de SQLAzureMW. Une troisième itération peut passer à l'environnement de test des performances, où des outils d'analyse des performances sont à votre disposition pour identifier les zones potentiellement prêtes à la migration.

Base de données SQL Azure ne prend pas en charge les fonctionnalités SQL Server 2000 et SQL Server 2005 supprimées dans SQL Server 2008 et les versions ultérieures. Par exemple, Base de données SQL Azure ne prend pas en charge la syntaxe *= or =* pour spécifier des jointures. Par conséquent, la migration de ces bases de données vers Base de données SQL Azure doit également traiter une bonne partie des mêmes problèmes rencontrés lors de la mise à niveau de SQL Server 2000 ou de SQL Server 2005. Vous pouvez utiliser des outils tels que les compteurs de l'Analyseur de performances, XEvents et les Conseillers de mise à niveau de SQL Server pour rechercher ces dépendances. Pour plus d'informations sur l'identification de ces problèmes, consultez Mettre à niveau le moteur de base de données.

Le développement est une opération distincte permettant d'effectuer les tâches générées dans les phases de planification et de conception. Les utilisateurs affectés aux tâches de développement ne doivent pas être chargés d'autres tâches dans d'autres phases du projet de migration.

La plupart des bases de données migrées vers Base de données SQL Azure requièrent des modifications qui affectent les niveaux applicatifs. Dès que des paramètres tels que les types de données, le nombre de colonnes retournées, la valeur Transact-SQL dynamique ou les paramètres d'entrée sont modifiés, la couche Données du code de l'application doit être modifiée. Même si aucun objet de base de données n'est modifié par la migration, l'architecture de Base de données SQL Azure exige des modifications applicatives, notamment pour obtenir une logique fiable entre deux tentatives et pour gérer les erreurs. En résumé, le développement des bases de données doit être intégré au développement de la couche applicative.

Le développement des bases de données peut être effectué à l'aide de n'importe quel outil de développement prenant en charge les bases de données SQL Server. L'avantage d'utiliser un outil tel que SSDT, contenant la logique de Base de données SQL Azure, est que vous pouvez définir l'objectif de la build du projet de base de données sur Base de données SQL Azure, et SSDT identifiera la syntaxe compatible lorsque vous écrivez du code. Pour plus d'informations, consultez Outils de données Microsoft SQL Server (SSDT). Avant SSDT, les développeurs utilisaient le kit d'émulation de Azure et se connectaient à SQL Server Express. Cette solution est plus pratique et s'apparente à un développement hors connexion, mais reste un ensemble de fonctionnalités sur site et peut donc être trompeuse par rapport aux possibilités de Base de données SQL Azure. Il est plus productif et plus efficace de caler le plus possible l'identification des problèmes avec la planification, et au moment du codage, l'opération doit s'apparenter à l'écriture du code. Si vous développez sans outil contenant la logique de Base de données SQL Azure, vous pouvez démarrer le développement sur Base de données SQL Azure dès que possible. Les outils de développement hors connexion comme SSDT permettent à plusieurs développeurs de travailler simultanément sur le même projet. SSDT intègre également des fonctionnalités de contrôle et de génération de code source, comme celles qui figurent dans Team Foundation Server. Si la migration affecte le code d'application et le code de base de données à la fois, le projet de base de données peut être intégré dans le même environnement de build. Si la migration affecte les applications et les bases de données à la fois, le projet SSDT peut être intégré dans la même solution que le processus de génération de projets applicatifs. Ce sont des avantages appréciables compte tenu des difficultés évidentes de connectivité lorsque vous développez directement sur Base de données SQL Azure.

Lorsque la migration requiert relativement peu de modifications sur le modèle de données, importez ce modèle de données dans SSDT et commencez à appliquer les modifications. La proposition de valeur, ici, est que chaque ressource de développement peut travailler dans sa zone de focus respective, et vous pouvez intégrer le tout pendant la phase de build.

Dans chaque itération du projet, l'équipe de déploiement doit fournir à l'équipe de planification un retour régulier et répondre à leurs cycles de façon proactive. Reconnaissez qu'il est moins risqué de procéder régulièrement à une validation, pour ensuite basculer et reprendre plus rapidement l'activité, plutôt que d'accumuler du code sans le valider pendant une longue période. Bien que cela ne soit pas nouveau, il est utile de rappeler que le non respect de ces paradigmes lors du développement de solutions dans le cloud peut coûter très cher.

Similairement aux autres activités dans le cycle de vie de l'application d'un projet de migration, il existe des activités et des objectifs qui restent constants même pour une migration vers Base de données SQL Azure. Les zones de test importantes pour Base de données SQL Azure, que les planificateurs et les développeurs négligent généralement, sont les suivantes :

  • Gestion des erreurs

  • Logique de nouvelle tentative

  • Réponse aux limitations

  • Déploiement des modifications

  • Paradigme de montée en puissance

  • Effets de la latence réseau

  • Sécurité

  • Journalisation

Tenez compte de ces éléments, car ils sont à la base des tests des fonctionnalités et des performances et permettent de dériver des cas d'utilisation. Il existe de nombreux outils de test, mais ce qui compte, c'est la capacité à isoler l'activité de la base de données. Les tests fonctionnels augmentent la productivité en réduisant les risques d'erreur des outils de développement, afin de capturer précisément les fonctionnalités de SQL Server qui ne figurent pas dans Base de données SQL Azure. Selon les outils de développement et les mécanismes de la build, les tests fonctionnels peuvent n'identifier aucun problème et offrent simplement une garantie supplémentaire avant de lancer les tests de performances, plus longs et plus coûteux.

Le test de la solution migrée doit répondre aux nouveaux cas d'utilisation qui avait un impact limité sur les implémentations sur site. Créez des tests qui forcent les erreurs nécessitant de nouvelles tentatives de transaction, et testez l'impact des charges de travail maximales et des pics d'activité. Une bonne solution dans le cloud permet de réduire le temps de résolution des problèmes. Cela peut être obtenu en développant une logique d'application qui enregistre l'activité et analyse régulièrement l'intégrité actuelle du système. Étant donné que les enregistrements dans la base de données peuvent être coûteux et consister en une simple écriture sur une autre table, le code d'application qui exécute les appels à la base de données doit enregistrer les erreurs, les avertissements et les durées. Par exemple, un client passe plusieurs heures à résoudre les problèmes de certains serveurs qui indiquent de faibles performances. Il utilise de nombreux outils pour identifier rapidement la cause du problème et le résoudre. Après plusieurs heures, les serveurs recommencent soudainement à fonctionner correctement. Le problème n'avait en fait rien à voir avec l'application, et était dû à la mise à niveau en cours d'exécution de la plateforme. L'effort entrepris pour le résoudre aurait pu être considérablement réduit si l'application avait été conçue pour enregistrer les points de données et si les administrateurs avaient analysé régulièrement l'intégrité des solutions. Ils auraient ainsi pu fournir à l'ingénieur de l'assistance des données plus fiables et lui permettre d'identifier plus facilement l'origine du problème. Bien sûr, les utilisations ultérieures de ce type de données peuvent comporter la redirection des consommateurs vers un centre de données différent.

Il est courant que l'expérience de déploiement soit oubliée. Or, les tests doivent inclure l'expérience de déploiement et suggérer la façon dont les changements ultérieurs peuvent être appliqués sur un environnement existant, et donner une idée de leur fiabilité. Le déploiement d'une nouvelle base de données, sa préparation et son lancement en production, sont des opérations très différentes du déploiement des modifications dans un environnement de production existant. Il n'y a pas de différence par rapport à une solution sur site, toutefois, nous tenons à souligner ici deux points importants :

  • Les déploiements qui ont fonctionné sur site peuvent ne pas fonctionner dans des solutions basées sur le cloud.

  • Un effort supplémentaire considérable est nécessaire pour inclure cela dans le plan de test, avec peu de retours immédiats.

Le test doit également être inclus dans le modèle itératif, et les problèmes doivent être transmis aux équipes de développement et de test. Au début, les tests peuvent être assez rudimentaires et très semblables aux tests sur site. Avec chaque itération, incorporez des cas plus orientés « cloud ». Les cas de test doivent couvrir les problèmes identifiés dans la documentation répertoriée dans la section Évaluation de la complexité ci-dessus.

La complexité de la migration peut être le résultat de contraintes liées au temps mort, il est alors d'autant plus essentiel de tester le plan de déploiement proposé.

Cette phase n'est pas différente de celle d'un cycle de vie de développement d'application normal. Dans un projet de migration, les développeurs doivent idéalement travailler uniquement aux problèmes identifiés par les tests, et non à coder la première version de la version migrée de la base de données.

Similairement à la phase de stabilisation, la phase de déploiement de la migration sur le cloud n'est pas différente de celle des projets de migration sur site. Des tests complets augmentent les chances de réussite lors de cette phase.

Une bonne communication est un facteur essentiel pour la migration. Des mises à jour d'état régulières et suffisamment détaillées sont essentielles pour une bonne expérience du consommateur, ou du moins, pour prendre conscience des objectifs métiers plus vastes de la migration sur le cloud.

Le succès de la phase de déploiement dépend de la qualité du travail effectué lors de la phase précédente. Des recherches, une planification, un développement et des tests insuffisants augmentent considérablement le risque de problèmes au cours du déploiement. Parfois, les problèmes de déploiement sont si sérieux qu'ils arrêtent le projet et entraînent la restauration des systèmes sur site. Dans certains cas, ils ont été tels que la société a remis en question sa capacité à utiliser des systèmes dans le cloud. Des recherches, une planification, un développement et des tests adéquats, aboutissent généralement à un déploiement qui se déroule conformément au plan. Même si des problèmes surgissent, une bonne planification comporte souvent des exigences de build qui réduisent leur impact.

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft