Points à prendre en compte concernant la migration

24 minutes

Un système d’entreprise s’exécutant localement peut avoir une architecture couplée à d’autres services fonctionnant dans le même environnement. Il est important de comprendre les relations entre un système que vous souhaitez migrer, et les autres applications et services que votre organisation utilise actuellement.

Dans votre entreprise de démarrage technologique, la base de données du fournisseur est utilisée pour s’assurer que les composants sont toujours en stock et arrivent juste-à-temps pour leur utilisation dans le processus de fabrication. Les contrôleurs de stock utilisent des appareils mobiles pour mettre à jour cette base de données à mesure que les envois arrivent et les acheteurs utilisent un site web pour surveiller les niveaux de stock et identifier le meilleur moment pour commander. Les responsables utilisent un ensemble de rapports critiques pour surveiller le processus et améliorer l’efficacité. Vous souhaitez vous assurer qu’aucun de ces utilisateurs n’est affecté négativement par la migration vers Azure.

Ici, vous allez apprendre à planifier et à exécuter une migration de base de données fluide dans le cloud.

Examiner les dépendances

Dans un système complexe, un composant fonctionne rarement entièrement indépendamment. Au lieu de cela, il effectue des appels à d’autres processus et composants. Les bases de données, par exemple, peuvent dépendre des services d’annuaire qui hébergent des comptes d’utilisateur. Quand vous déplacez une base de données dans le cloud, pouvez-vous accéder à ce service d’annuaire ? Si ce n’est pas le cas, comment les utilisateurs se connecteront-ils ? Lorsque vous ignorez une dépendance comme celle-ci, il peut y avoir un échec total de la base de données.

Pour atténuer les risques, vérifiez si votre base de données dépend des services suivants :

Services d’annuaire, tels qu’Active Directory.
Autres magasins de principaux de sécurité.
Autres bases de données.
API web ou autres services réseau.

N’oubliez pas non plus que d’autres composants peuvent dépendre de votre base de données. Si vous déplacez la base de données sans reconfigurer les composants dépendants, quelles sont les conséquences ? Par exemple, si vous déplacez une base de données de catalogue de produits et que le site web public dépend de celui-ci pour déterminer quels produits présenter aux utilisateurs, le déplacement entraîne-t-il une interruption du service ?

Vérifiez si l’un de ces types de composants dépend de votre base de données :

Sites web et API web.
Applications clientes, telles que les applications mobiles et les logiciels de bureau.
Autres bases de données.
Rapports
Entrepôts de données.

Pour effectuer ces vérifications, contactez les parties prenantes, les administrateurs et les développeurs impliqués dans chaque composant de base de données et système. Consultez la documentation, si vous n’êtes pas sûr que vous comprenez le comportement des systèmes, envisagez d’exécuter des tests, tels que des captures réseau pour observer le comportement.

Préparez-vous à revenir

Dans n’importe quel projet de migration, vous devez toujours être préparé pour une défaillance. Dans un projet de migration de base de données vers le cloud, la pire éventualité est que la nouvelle base de données devient indisponible et que les utilisateurs ne peuvent pas effectuer leurs tâches. Il est courant d’atténuer ce risque, qui peut avoir un impact important sur la rentabilité de votre entreprise, en envisageant de revenir à la base de données initiale non modifiée locale.

Pour le plan de secours, envisagez les éléments suivants :

Comment vous assurer que vous pouvez revenir à une base de données qui n’est pas touchée par la migration ayant échoué ? Par exemple, il est vivement recommandé d’effectuer une sauvegarde complète de la base de données, juste avant de commencer la migration.
Combien de temps est-il acceptable que la base de données soit hors connexion, si vous devez revenir en arrière ?
Combien de budget avez-vous pour le plan de secours ? Par exemple, pouvez-vous vous permettre de répliquer la base de données sur un serveur de secours dédié ? Dans ce cas, vous pouvez désactiver ce serveur juste avant la migration. Pour revenir en arrière, vous démarrez ce serveur. Vous disposez immédiatement d’une base de données qui n’est pas affectée par la migration, sans avoir à la restaurer à partir de la sauvegarde.

Migration hors connexion et en ligne

Pour migrer une base de données, vous avez au moins deux options :

Remarque

L’option en ligne n’est actuellement pas disponible pour les bases de données MySQL dans Data Migration Service.

Arrêtez le système, transférez la base de données, puis reconfigurez et redémarrez le système pour utiliser la nouvelle base de données. Il s’agit d’une migration hors connexion.
Conservez le système en cours d’exécution pendant que vous déplacez la base de données vers son nouvel emplacement, restaurez les transactions effectuées sur la base de données d’origine vers la nouvelle base de données pendant la migration, puis changez vos applications pour vous connecter à la nouvelle base de données. Il s’agit d’une migration en ligne.

Il est plus simple d’effectuer une migration hors connexion, où les utilisateurs ne peuvent pas modifier les données pendant la migration. Toutefois, si votre base de données est occupée ou critique pour la réussite de votre organisation, cela peut ne pas être possible.

Migrations hors connexion

Supposons que votre base de données prenne en charge une équipe d’analystes qui travaillent tous dans un fuseau horaire unique pendant les heures ouvrées normales. L’équipe ne travaille généralement pas le week-end. Entre 18h00 le vendredi et 19h00 le dimanche, la base de données n’est pas souvent utilisée.

Dans ce cas, vous pouvez effectuer une migration hors connexion pendant le week-end, en procédant comme suit :

Mettre la base de données hors connexion, une fois toutes les transactions terminées le vendredi soir.
Effectuez une sauvegarde complète ou exportez la base de données.
Arrêtez le serveur local et conservez-le au cas où vous devez revenir.
Restaurez la base de données sur le système cloud cible.
Mettez le système cible en ligne.
Reconfigurez les clients pour se connecter à la base de données cloud.

Dans ce cas, une migration hors connexion est possible, car il existe une longue période quand une interruption du service a peu d’effet sur les utilisateurs. Pendant ce temps, vous pouvez effectuer une sauvegarde et une restauration complètes de la base de données, sachant que vous ne manquerez aucune modification.

Migrations en ligne

Considérez maintenant une autre base de données qui prend en charge une application de vente. Le personnel des ventes est distribué dans le monde entier et travaille également le week-end. Il n’y a pas de période de faible activité, la base de données est toujours occupée et, si vous prenez la base de données hors connexion pendant une période importante, elle aura un impact sur les utilisateurs. L’activité des ventes est critique pour l’entreprise, de sorte qu’une interruption du service aura un effet direct sur la ligne de fond de l’organisation.

Dans les cas suivants, envisagez d’effectuer une migration en ligne. Dans une migration en ligne, les temps d’arrêt sont limités au temps nécessaire pour basculer vers la nouvelle base de données. Utilisez un outil tel que Azure Data Migration Service pour exécuter une migration en ligne. Les migrations en ligne présentent les différences suivantes avec les migrations hors connexion :

Vous ne déplacez pas la base de données d’origine hors connexion avant d’effectuer une sauvegarde ou une exportation.
Pendant que la migration est en cours, les modifications s’appliquent à l’ancienne base de données.
L’outil de migration garantit que ces modifications sont copiées dans la nouvelle base de données avant le basculement. Cette opération est souvent obtenue en reconfigurant l’ancienne base de données pour répliquer les modifications vers la nouvelle base de données.

Migration d’applications

Une fois que vous avez migré une base de données, comment (et quand) devez-vous basculer vers le nouveau système et mettre à jour les applications pour qu'elles utilisent la nouvelle base de données ? Vous pouvez :

Déplacez les applications un par un vers la nouvelle base de données.
Déplacer des sous-ensembles d’utilisateurs.
Adoptez une combinaison des deux approches.

L’intention est que vous effectuez une migration d’application en petites étapes qui peuvent être facilement restaurées si quelque chose va mal. Que vous ayez suivi une approche hors connexion ou en ligne de la migration de base de données, vous devez toujours disposer d’une configuration opérationnelle située à la source d’origine. En théorie, vous serez en mesure de revenir à la source d’origine rapidement. Toutefois, si les données changent constamment, vous devez prendre en compte l’endroit où ces modifications ont été apportées.

Dans une migration hors connexion, la source et les destinations sont indépendantes les unes des autres. Les utilisateurs et les applications peuvent ne plus voir une vue cohérente des données. Dans un système transactionnel, cette situation est susceptible d’être inacceptable. Dans ce cas, vous devez conserver une certaine forme de réplication bidirectionnelle entre les bases de données alors que les deux systèmes restent actifs. Sinon, si l’objectif d’une application est de générer des rapports mensuels ou hebdomadaires, de générer des projections de ventes ou d’effectuer d’autres opérations statistiques, ce manque de cohérence peut ne pas être si inquiétant. De telles applications adoptent une « vision à long terme » des données plutôt que de dépendre de données à jour. Dans ce dernier cas, les applications transactionnelles utilisent la nouvelle base de données, tandis que les applications de création de rapports sont déplacées plus lentement.
Dans une migration en ligne, la nouvelle base de données est conservée synchronisée avec l’ancienne, généralement par une certaine forme de réplication. Le processus de réplication peut être asynchrone, de sorte qu’il peut y avoir un décalage. Toutefois, les modifications apportées aux données dans la nouvelle base de données ne seront pas propagées à l’ancienne, ce qui entraîne des conflits possibles. Une application s’exécutant sur l’ancienne base de données peut apporter une modification conflictuelle aux données qui ont été modifiées dans la nouvelle base de données. La réplication remplace aveuglement la modification dans la nouvelle base de données, ce qui entraîne une « mise à jour perdue ».

Approches de test

Si la base de données joue un rôle essentiel dans votre entreprise, les conséquences d’un échec peuvent être considérables. Pour renforcer votre confiance que cela ne se produira pas, envisagez d’exécuter des tests de performance sur la base de données migrée pour vous assurer qu’elle peut faire face à la charge que les utilisateurs pourraient lui imposer et y répondre efficacement. N’oubliez pas qu’il peut y avoir des périodes de pic d’activité, quand la demande est beaucoup plus élevée que la normale. Vous devez être sûr que votre système migré gère la charge de travail attendue.

Effectuez toujours un certain type de test de régression sur la nouvelle base de données avant d’autoriser l’accès aux utilisateurs. Ces tests vérifient que le comportement et les fonctionnalités du système sont corrects.

Vous devez également envisager d’exécuter un « test d’endurance ». Un test de trempe est un test de charge conçu pour voir comment le système dans son ensemble fonctionne sous pression. Un test d'immersion stresse la nouvelle base de données et détermine si elle est stable sous une forte demande. Un test d’endurance s’exécute sur une période de temps longue pour voir ce qu’il se passe lorsque la demande élevée persiste.

Lorsque vous avez établi que le nouveau système est stable, vous pouvez commencer à migrer des utilisateurs. Toutefois, vous aurez peut-être besoin d’une assurance supplémentaire que les utilisateurs trouveront le nouveau système acceptable. À ce stade, vous pouvez envisager le « test de contrôle de validité ». Un test de contrôle de validité dirige en toute transparence un petit sous-ensemble d’utilisateurs vers le nouveau système, mais ils ne savent pas qu’ils y accèdent. Il s’agit d’un test aveugle, destiné à vous aider à détecter les éventuels problèmes du nouveau système. Surveillez les réponses de ces utilisateurs et effectuez les ajustements nécessaires.

Maintenance des systèmes parallèles

Il existe plusieurs raisons pour lesquelles vous pouvez choisir d’exécuter l’ancienne base de données locale en parallèle avec la nouvelle base de données cloud :

Périodes de test. Comme vous l’avez vu dans la rubrique précédente, il est judicieux d’exécuter des tests canary sur la base de données migrée pour évaluer ses fonctionnalités, sa stabilité et sa capacité avant de l’utiliser pour prendre en charge les personnes. La maintenance du système local en parallèle vous permet de rétablir rapidement les utilisateurs de l’ancien système en cas de problèmes avec le nouveau système.
Migrations par phases. Une façon d’atténuer l’impact des défaillances inattendues en production consiste à déplacer un petit nombre d’utilisateurs vers le nouveau système en premier et à surveiller les résultats. Si toutes les exécutions sont fluides, vous pouvez déplacer d’autres groupes d’utilisateurs à mesure que vous gagnez en confiance dans la nouvelle base de données. Vous pouvez déplacer les utilisateurs par ordre alphabétique, par service, par emplacement ou par rôle, jusqu’à ce qu’ils se trouvent tous sur la nouvelle base de données.
Migrations fragmentaires. Une autre approche consiste à segmenter la migration non pas par utilisateur, mais par charge de travail. Par exemple, vous pouvez migrer les tables de base de données qui prennent en charge les ressources humaines, avant celles qui prennent en charge les ventes.

Dans tous ces cas, il existe une période pendant laquelle l’ancienne base de données locale s’exécute en parallèle avec la nouvelle base de données cloud. Vous devez vous assurer que les modifications apportées à l’ancienne base de données sont également appliquées à la nouvelle base de données et qu’elles circulent dans la direction opposée. Vous pouvez scripter cette synchronisation ou utiliser un outil comme Azure Data Migration Service.

Si vous décidez de conserver des bases de données parallèles et de synchroniser les modifications, posez-vous les questions suivantes :

Résolution des conflits. Est-il probable qu’une modification d’une ligne locale se produise à un moment similaire à une modification différente de la même ligne dans le cloud ? Cela créerait un conflit, où il n’est pas clair quelle modification doit être conservée. Comment résoudre ces conflits ?
Trafic réseau. Combien de trafic réseau sera généré pendant la synchronisation des modifications entre les bases de données ? Avez-vous suffisamment de capacité réseau pour ce trafic ?
Latence. En cas de modification dans l’une des bases de données, quel décalage (le cas échéant) est acceptable avant que cette modification atteigne l’autre base de données ? Par exemple, dans un catalogue de produits, vous pourrez peut-être attendre jusqu’à un jour avant que de nouveaux produits soient visibles par tous les utilisateurs. Toutefois, si la base de données inclut des informations transactionnelles critiques, telles que les taux de change monétaires, ces données doivent être synchronisées beaucoup plus fréquemment, si elles ne sont pas instantanées.

Migration fragmentaire

Une migration fragmentaire consiste à diviser un système complet en charges de travail et à migrer une charge de travail à la fois.

Bases de données multiples

Un système complexe peut inclure plusieurs bases de données qui prennent en charge plusieurs charges de travail. Par exemple, les ressources humaines peuvent utiliser la base de données StaffDB , tandis que l’équipe commerciale peut avoir des applications mobiles qui interrogent à la fois la base de données ProductCatalogDB et la base de données OrdersDB .

Bien sûr, vous pouvez choisir de migrer l’ensemble du système de base de données vers le cloud en une seule fois. Cela peut être plus simple, car vous n’avez pas besoin d’exécuter des bases de données locales et dans le cloud. Vous n’avez pas besoin de prendre en compte la façon dont ces bases de données communiquent pendant la migration. Toutefois, les risques de défaillance sont plus élevés. Un problème unique peut affecter à la fois l’équipe des ressources humaines et l’équipe commerciale.

Envisagez d’atténuer ces risques pour les systèmes de base de données de taille moyenne et volumineuse en effectuant une migration fragmentaire, où vous déplacez une charge de travail à la fois. Dans cet exemple, vous pouvez commencer par migrer la base de données StaffDB , car les problèmes associés à un échec seraient limités à l’équipe des ressources humaines et ne vous empêcheraient pas de prendre des commandes. En résolvant les problèmes qui surviennent lors de la migration de StaffDB , vous allez apprendre des leçons qui s’appliquent à d’autres migrations de charge de travail.

Ensuite, vous pouvez envisager de migrer la charge de travail du catalogue de produits vers le cloud. Si vous le faites, tenez compte des questions telles que :

Comment vous assurez-vous que les produits nouvellement ajoutés au catalogue sont disponibles pour commander ?
Avez-vous besoin de synchroniser des données avec la base de données OrdersDB , qui reste locale ?
Quelle latence est acceptable pour que les nouveaux produits atteignent la base de données OrdersDB à partir du catalogue de produits ?

Migrations fragmentaires de base de données unique

Même si vous n’avez qu’une seule base de données qui prend en charge toutes les charges de travail, vous pouvez toujours envisager une migration fragmentaire. Par exemple, vous pouvez diviser la base de données en éléments comme suit :

Tables prenant en charge les opérations RH.
Tables prenant en charge les ventes.
Tables qui soutiennent l’analyse et la création de rapports.

Si vous migrez d’abord les tables des opérations des RH, tout problème survenant affecte uniquement le personnel RH. Les analystes des ventes et des données continuent de travailler sur l’ancienne base de données sans interruption.

Avant d’effectuer une migration fragmentaire, vous devez bien comprendre les bases de données et comment elles sont utilisées par les applications. Par exemple, certaines tables de votre base de données peuvent prendre en charge les ventes et les rapports. Cela signifie que vous ne pouvez pas diviser correctement les charges de travail. Vous devez synchroniser ces tables entre les bases de données locales et cloud, jusqu’à ce que toutes les charges de travail aient été migrées.

Problèmes de sécurité

Vos bases de données peuvent contenir des données sensibles, telles que les détails du produit, les informations personnelles du personnel et les détails de paiement. Par conséquent, la sécurité est toujours une priorité élevée. Vous devez décider comment protéger ces données pendant la migration et dans la nouvelle base de données.

Protection pare-feu

Dans une application connectée à Internet, les serveurs de base de données sont généralement protégés par au moins deux pare-feu. Le premier pare-feu sépare Internet des serveurs frontaux, si ces serveurs hébergent des sites web ou des API web, par exemple. Seul le port TCP 80 doit être ouvert sur le pare-feu externe, mais ce port doit être ouvert pour toutes les adresses IP sources, à l’exception des adresses bloquées.

Le deuxième pare-feu sépare les serveurs frontaux des serveurs de base de données. Il est recommandé de publier le service de base de données sur un numéro de port privé qui n’est pas connu dans le monde extérieur. Sur le deuxième pare-feu, ouvrez ce numéro de port uniquement pour les adresses IP des serveurs frontaux. Cette disposition empêche toute communication directe d’un utilisateur Internet malveillant vers les serveurs de base de données.

Si vous envisagez de migrer des serveurs de base de données vers des machines virtuelles Azure, utilisez un réseau virtuel avec des groupes de sécurité réseau (NSG) pour répliquer des règles de pare-feu. Si vous utilisez Azure Database pour MySQL, Azure Database for MariaDB ou Azure Database pour PostgreSQL, vous pouvez créer des règles de pare-feu pour protéger la base de données à l’aide de la page de sécurité de connexion pour le serveur dans le portail Azure.

Authentification et autorisation

Dans la plupart des bases de données, vous devez contrôler étroitement qui accède aux données et les modifie. Ce contrôle exige que les utilisateurs soient identifiés positivement lorsqu’ils se connectent à la base de données. Ce processus est appelé authentification et est généralement effectué avec un nom d’utilisateur et un mot de passe. Les systèmes de base de données tels que MySQL, MariaDB et PostgreSQL fournissent leurs propres mécanismes d’authentification. Vous devez vous assurer que vous continuez à authentifier les utilisateurs en toute sécurité lorsque vous migrez vos systèmes vers le cloud.

Remarque

Les services Azure Database pour MySQL, Azure Database for MariaDB et Azure Database pour PostgreSQL émulent l’authentification traditionnelle MySQL, MariaDB et PostgreSQL.

Lorsque vous savez qui est l’utilisateur, vous devez leur attribuer des autorisations pour effectuer les tâches qui font partie de leur travail. Ce processus est appelé autorisation.

Pour un projet de migration de base de données, vous devez vous assurer que les utilisateurs sont autorisés correctement dans la base de données cloud :

Découvrez où sont stockés les comptes d’utilisateur dans le système local. Dans MySQL, les comptes d’utilisateur sont généralement stockés dans la user table de la mysql base de données, mais il est possible, par exemple, d’intégrer des comptes d’utilisateur stockés dans Active Directory.
Obtenez la liste de tous les comptes d’utilisateur. Dans MySQL, par exemple, vous pouvez utiliser cette commande :
```
SELECT host, user FROM mysql.user;
```
Pour chaque compte d’utilisateur, découvrez l’accès dont ils ont besoin à la base de données. Dans MySQL, par exemple, vous pouvez utiliser cette commande pour le dbadmin@on-premises-host compte d’utilisateur :
```
SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
```
Recréez chaque compte d’utilisateur dans la base de données cloud. Dans MySQL, par exemple, vous pouvez utiliser cette commande pour créer un compte :
```
CREATE USER 'dbadmin'@'cloud-host'
```
Autorisez chaque compte d’utilisateur au niveau d’accès correct dans la base de données cloud. Dans MySQL, par exemple, vous pouvez utiliser cette commande pour permettre à un utilisateur d’accéder à la base de données complète :
```
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
```

Chiffrement

À mesure que les données sont envoyées sur le réseau, elles peuvent être interceptées par une attaque « man-in-the-middle ». Pour éviter cela, Azure Database pour MySQL, Azure Database for MariaDB et Azure Database pour PostgreSQL prennent en charge ssl (Secure Sockets Layer) pour chiffrer les communications. SSL est appliqué par défaut et il est vivement recommandé de ne pas modifier ce paramètre.

Vous devrez peut-être modifier les paramètres de connexion de vos applications clientes pour utiliser le chiffrement SSL. Discutez de cette rubrique avec vos développeurs pour déterminer les modifications, le cas échéant, qui sont nécessaires.

Surveillance et gestion

Une partie de la planification de la migration d’une base de données consiste à prendre en compte la façon dont les administrateurs de base de données continueront d’effectuer leurs tâches après la migration.

Supervision

Les administrateurs de base de données locaux sont utilisés pour surveiller régulièrement les problèmes tels que les goulots d’étranglement matériels ou la contention de l’accès réseau. Ils surveillent pour s’assurer qu’ils peuvent résoudre tous les problèmes avant que la productivité soit affectée. Vous pouvez vous attendre à toute base de données qui n’est pas régulièrement surveillée pour commencer à provoquer des problèmes tôt ou tard.

Vous devez adopter exactement la même approche pour les bases de données cloud. Il peut être plus facile de résoudre les problèmes dans un système PaaS comme Azure, car vous pouvez ajouter des ressources sans acheter, installer et configurer du matériel. Toutefois, vous devez toujours repérer les problèmes de développement, de sorte que la surveillance est une priorité élevée parmi vos tâches quotidiennes.

Avant de migrer des bases de données dans le cloud, découvrez quels outils de surveillance vos administrateurs utilisent actuellement. Si ces outils sont compatibles avec votre solution cloud proposée, vous devrez peut-être les reconnecter aux bases de données migrées. Si ce n’est pas le cas, vous devez examiner les alternatives.

N’oubliez pas qu’Azure inclut un ensemble d’outils de surveillance des performances et collecte un large éventail de compteurs de performances et de données de journal. Vous affichez ces données à l’aide de tableaux de bord et de graphiques dans le portail Azure, en configurant Azure Monitor. Vous créez des graphiques, des tableaux et des rapports personnalisés, spécifiquement conçus pour les besoins de vos administrateurs.

Gestion

Vos administrateurs de base de données utilisent des outils préférés pour modifier le schéma et le contenu de la base de données localement. S’ils utilisent les mêmes outils après la migration, vous pouvez continuer à tirer parti de leur expertise. Commencez par évaluer si l’ensemble d’outils existant est compatible avec la base de données hébergée dans le cloud proposée. De nombreux outils seront compatibles, car ils sont basés sur des normes largement adoptées telles que SQL, mais il est important de vérifier cette compatibilité. Si les outils de gestion actuels ne fonctionnent pas après la migration, essayez d’identifier les alternatives avec vos administrateurs.

Azure inclut plusieurs outils que vous pouvez utiliser pour administrer les bases de données MySQL, MariaDB et PostgreSQL :

Le portail Azure. Ce site web dispose d’installations puissantes que vous utilisez pour configurer, surveiller et gérer des bases de données, ainsi que toutes les autres ressources que vous pouvez créer dans le cloud Azure.
Azure PowerShell. Il s’agit d’un environnement d’exécution de script et d’un langage qui a un large ensemble de commandes. Utilisez PowerShell, qui est disponible pour les environnements Windows et Linux, pour automatiser des tâches d’administration de base de données complexes.
Azure CLI. Il s’agit d’une interface de ligne de commande vers Azure. Utilisez-le pour gérer les services et les ressources dans Azure. Vous pouvez utiliser l’interface CLI à partir des environnements d’interpréteur de commandes Windows et Linux, et à partir de scripts Bash.