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 opérationnels 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 start-up informatique, la base de données de fournisseur est utilisée pour garantir que les composants sont toujours en stock et arrivent juste-à-temps pour être utilisés dans le processus de fabrication. Les contrôleurs de stock utilisent des appareils mobiles pour mettre à jour cette base de données à mesure des arrivages et les acheteurs utilisent un site web pour superviser les niveaux de stock et identifier le meilleur moment pour la commande. Les responsables utilisent un ensemble de rapports stratégiques pour superviser le processus et améliorer l’efficacité. Vous voulez vous assurer qu’aucun de ces utilisateurs n’est affecté de façon négative par la migration vers Azure.

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

Investiguer les dépendances

Dans un système complexe, un composant fonctionne rarement de manière entièrement indépendante. Au lieu de cela, il appelle d’autres processus et composants. Les bases de données, par exemple, peuvent dépendre de services d’annuaire qui hébergent des comptes d’utilisateur. Lorsque 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 de ce type, une défaillance totale de la base de données peut se produire.

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

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

Souvenez-vous également 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 en dépend pour déterminer quels produits présenter aux utilisateurs, le déplacement entraînera-t-il une interruption de 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, communiquez avec les parties prenantes, les administrateurs et les développeurs impliqués dans chaque base de données et composant système. Consultez la documentation et, si vous n’êtes pas sûr de comprendre le comportement des systèmes, envisagez d’exécuter des tests, tels que des captures réseau, pour observer ce comportement.

Préparer une solution de secours

Dans n’importe quel projet de migration, vous devez toujours être prêt en cas de 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 devienne indisponible et que les utilisateurs ne puissent pas faire leur travail. Il est courant d’atténuer ce risque, qui peut avoir un impact important sur la rentabilité de votre société, en planifiant une restauration locale de la base de données d’origine et non modifiée.

Pour le plan de secours, prenez en compte les éléments suivants :

Comment garantir que vous pouvez revenir à une base de données qui n’est pas affectée par l’échec de la migration ? Par exemple, il est vivement recommandé d’effectuer une sauvegarde de base de données complète juste avant de commencer la migration.
Pendant quelle durée acceptable la base de données peut-elle être hors connexion si vous devez revenir à une version antérieure ?
De quel budget disposez-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é ? Si c’est le 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 non affectée par la migration, sans devoir la restaurer à partir de la sauvegarde.

Migration hors connexion et en ligne

Pour migrer une base de données, vous disposez d’au moins deux options :

Notes

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

Arrêter le système, transférer la base de données, puis reconfigurer et redémarrer le système pour utiliser la nouvelle base de données. Il s’agit d’une migration hors connexion.
Maintenir le système en cours d’exécution pendant que vous déplacez la base de données vers son nouvel emplacement, restaurer par progression les transactions en cours sur la base de données d’origine vers la nouvelle base de données pendant la migration, puis basculer vos applications pour une connexion à la nouvelle base de données. Il s’agit d’une migration en ligne.

Il est plus simple d’effectuer une migration hors connexion pendant laquelle les utilisateurs ne peuvent pas modifier les données. Toutefois, si votre base de données est occupée ou stratégique 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 le même fuseau horaire pendant des heures d’ouverture normales. L’équipe ne travaille généralement pas le week-end. Entre le vendredi 18h et le dimanche 9h, 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 :

Mettez la base de données hors connexion lorsque toutes les transactions sont terminées le vendredi soir.
Effectuez une sauvegarde complète ou une exportation de la base de données.
Arrêtez le serveur local et conservez-le au cas où vous devriez revenir en arrière.
Restaurez la base de données sur le système cloud cible.
Mettez le système cible en ligne.
Reconfigurez les clients pour qu’ils se connectent à la base de données cloud.

Dans ce cas, une migration hors connexion est possible, car il existe une longue période pendant laquelle une interruption du service n’a que 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 en sachant que vous ne perdrez aucune modification apportée.

Migrations en ligne

Prenons maintenant l’exemple d’une autre base de données qui prend en charge une application de ventes. Le personnel de ventes est réparti 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 mettez la base de données hors connexion pendant une longue période, cela aura un impact sur les utilisateurs. L’activité de ventes étant critique pour l’entreprise, une interruption du service aura un impact direct sur les résultats financiers de l’organisation.

Dans des cas comme celui-ci, envisagez d’effectuer une migration en ligne. Dans une migration en ligne, le temps d’arrêt se limite au temps nécessaire pour basculer vers la nouvelle base de données. Utilisez un outil comme Azure Data Migration Service pour exécuter une migration en ligne. Les migrations en ligne présentent les différences suivantes par rapport aux migrations hors connexion :

Vous ne déplacez pas la base de données d’origine en mode 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. Ce résultat est souvent obtenu en reconfigurant l’ancienne base de données pour répliquer les modifications dans la nouvelle.

Migration d’applications

Après avoir migré une base de données, comment (et quand) devez-vous basculer vers le nouveau système et mettre à jour les applications pour utiliser la nouvelle base de données ? Vous pouvez :

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

L’objectif consiste à effectuer la migration d’applications par petites étapes qui peuvent être facilement restaurées en cas de problème. Que vous ayez suivi une approche hors connexion ou en ligne pour la migration de base de données, vous devez toujours disposer d’une configuration fonctionnelle située dans la source d’origine. En théorie, vous serez en mesure de revenir rapidement à la source d’origine. Toutefois, si les données changent constamment, vous devez tenir compte de 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. Il se peut que les utilisateurs et les applications ne voient plus un affichage cohérent des données. Dans un système transactionnel, cette situation sera probablement inacceptable. Dans ce cas, vous devez conserver une forme de réplication bidirectionnelle entre les bases de données tout en maintenant les deux systèmes en ligne. Sinon, si une application a pour objectif 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 aussi 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, alors 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 synchronisée avec l’ancienne, généralement par une sorte 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 sont pas répercutées dans l’ancienne, d’où le risque de conflits. Une application exécutée sur l’ancienne base de données peut apporter une modification en conflit avec des données qui ont été modifiées dans la nouvelle base de données. La réplication remplacera aveuglément la modification dans la nouvelle base de données, ce qui aboutit à une « mise à jour perdue ».

Approches de test

Si la base de données joue un rôle essentiel dans votre activité, les conséquences d’une défaillance peuvent être considérables. Pour veiller à ce que cela ne se produise pas, envisagez d’exécuter des tests de performances sur la base de données migrée afin de vous assurer qu’elle est adaptée à la charge que les utilisateurs peuvent y placer et qu’elle peut y répondre rapidement. N’oubliez pas qu’il peut y avoir des périodes d’activité soutenue, où la demande est bien plus élevée que la normale. Vous devez vous assurer que votre système migré gère la charge de travail attendue.

Effectuez toujours un certain type de tests 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 la fonctionnalité du système sont corrects.

Vous devez également envisager d’exécuter un « test d’endurance ». Un test d’endurance est un test de charge conçu pour voir comment le système dans son ensemble fonctionne sous pression. Un test d’endurance met la pression sur la nouvelle base de données et détermine si elle est stable dans des conditions de demande élevée. 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.

Une fois que vous avez établi que le nouveau système est stable, vous pouvez commencer à migrer les utilisateurs. Toutefois, vous devrez peut-être également vous assurer 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’une sorte de test à l’aveugle, conçu pour vous permettre de trouver des problèmes liés au nouveau système. Supervisez les réponses de ces utilisateurs et apportez les ajustements nécessaires.

Maintien des systèmes parallèles

Il existe plusieurs raisons pour lesquelles vous pouvez choisir d’exécuter l’ancienne base de données locale parallèlement à 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 de contrôle de validité sur la base de données migrée pour évaluer sa fonctionnalité, sa stabilité et sa capacité avant de l’utiliser pour prendre en charge des personnes. Le maintien du système local en parallèle vous permet de rétablir rapidement les utilisateurs sur l’ancien système en cas de problème 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 d’abord un petit nombre d’utilisateurs vers le nouveau système et à superviser les résultats. Si tout s’exécute correctement, 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 soient tous dans 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 prenant en charge les ressources humaines avant celles associées aux ventes.

Dans tous ces cas, il y a un moment où l’ancienne base de données locale s’exécute parallèlement à 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 et qu’elles circulent dans la direction opposée. Vous pouvez générer un script pour cette synchronisation ou utiliser un outil comme Azure Data Migration Service.

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

Résolution des conflits. Une modification apportée à une ligne localement peut-elle se produire au même moment qu’une autre modification apportée à la même ligne dans le cloud ? Cela créerait un conflit dans lequel il n’est pas évident de savoir quelle modification doit être conservée. Comment pouvez-vous résoudre de tels conflits ?
Trafic réseau. Quelle quantité de trafic réseau sera générée lors de la synchronisation des modifications entre les bases de données ? Disposez-vous d’une capacité réseau suffisante pour ce trafic ?
Latence. Quand l’une des bases de données est modifiée, quel est le décalage (le cas échéant) acceptable avant que cette modification n’atteigne l’autre base de données ? Par exemple, dans un catalogue de produits, vous pouvez attendre jusqu’à un jour avant que de nouveaux produits ne soient visibles pour tous les utilisateurs. Toutefois, si la base de données contient des informations transactionnelles critiques, telles que des taux de change de devises, ces données doivent être synchronisées beaucoup plus fréquemment, si ce n’est instantanément.

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 prenant en charge plusieurs charges de travail. Par exemple, les ressources humaines peuvent utiliser la base de données StaffDB, tandis que l’équipe des ventes peut disposer d’applications mobiles qui interrogent à la fois la base de données ProductCatalogDB et la base de données OrdersDB.

Vous pouvez bien évidemment choisir de migrer l’intégralité du système de base de données vers le cloud en une seule opération. Cela peut être plus simple, car vous n’êtes pas obligé d’exécuter les bases de données localement et dans le cloud. Vous n’avez pas besoin de prendre en compte comment ces bases de données communiquent pendant la migration. Les risques de défaillance sont toutefois plus élevés. Un seul problème peut affecter à la fois l’équipe des ressources humaines et l’équipe des ventes.

Envisagez d’atténuer ces risques pour les systèmes de base de données de taille moyenne et grande en effectuant une migration fragmentaire dans laquelle vous déplacez une charge de travail à la fois. Dans cet exemple, vous pouvez envisager de migrer la base de données StaffDB en premier, car les problèmes de défaillance se limiteraient à l’équipe des ressources humaines et ne vous empêcheraient pas de prendre des commandes. En résolvant les problèmes survenant avec la migration de StaffDB, vous tirerez des leçons qui s’appliquent à d’autres migrations de charges de travail.

Vous pouvez ensuite envisager de migrer la charge de travail du catalogue de produits vers le cloud. Dans ce cas, posez-vous des questions telles que :

Comment s’assurer que les produits récemment ajoutés au catalogue sont disponibles en commande ?
Devez-vous synchroniser des données avec la base de données OrdersDB, qui reste en local ?
Quelle est la latence acceptable pour que les nouveaux produits atteignent la base de données OrdersDB à partir du catalogue de produits ?

Migrations fragmentaires avec une seule base de données

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 plusieurs éléments tels que :

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

Si vous migrez les tables des opérations RH en premier, les problèmes qui surviennent n’affectent que le personnel RH. Les analystes de ventes et de données continuent à travailler sur l’ancienne base de données sans interruption.

Avant d’effectuer une migration fragmentaire, vous devez parfaitement 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 la création de 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.

Considérations sur la sécurité

Vos bases de données peuvent contenir des données sensibles, telles que des informations sur les produits, des informations personnelles sur les équipes et des informations de paiement. La sécurité est donc toujours prioritaire. Vous devez décider comment protéger ces données pendant la migration et dans la nouvelle base de données.

Protection par pare-feu

Dans une application connectée à Internet, les serveurs de bases 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 front-end, 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 front-end des serveurs de bases 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 du monde extérieur. Sur le deuxième pare-feu, ouvrez ce numéro de port uniquement pour les adresses IP des serveurs front-end. Cette configuration empêche toute communication directe entre un utilisateur Internet malveillant et les serveurs de bases de données.

Si vous envisagez de migrer des serveurs de bases de données vers des machines virtuelles Azure, utilisez un réseau virtuel avec des groupes de sécurité réseau pour répliquer les 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 en utilisant la page Sécurité de la 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 de manière positive 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 vérifier que vous continuez d’authentifier les utilisateurs de manière sécurisée quand vous migrez vos systèmes vers le cloud.

Notes

Les services Azure Database pour MySQL, Azure Database for MariaDB et Azure Database pour PostgreSQL émulent les authentifications MySQL, MariaDB et PostgreSQL classiques.

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

Pour un projet de migration de base de données, vous devez vérifier que les utilisateurs sont correctement autorisés 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 table user de la base de données mysql, mais il est possible, par exemple, de les intégrer aux 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;
```
Déterminez l’accès à la base de données dont dispose chaque compte d’utilisateur. Dans MySQL, par exemple, vous pouvez utiliser cette commande pour le compte d’utilisateur dbadmin@on-premises-host :
```
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'
```
Accordez à chaque compte d’utilisateur le niveau d’accès approprié dans la base de données cloud. Dans MySQL, par exemple, vous pouvez utiliser cette commande pour autoriser un utilisateur à accéder à la base de données complète :
```
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
```

Chiffrement

À mesure que des données sont envoyées sur le réseau, elles peuvent être interceptées par une attaque dite de l’intercepteur ou « man-in-the-middle ». Pour éviter cela, Azure Database pour MySQL, Azure Database for MariaDB et Azure Database pour PostgreSQL prennent en charge le protocole SSL (Secure Sockets Layer) pour chiffrer les communications. Le protocole 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 ce sujet avec vos développeurs pour déterminer les modifications nécessaires, le cas échéant.

Surveillance et gestion

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

Surveillance

Les administrateurs de bases de données locales procèdent régulièrement à une supervision pour repérer les problèmes tels que les goulots d’étranglement matériels ou les conflits d’accès réseau. Ils supervisent pour s’assurer de pouvoir résoudre les problèmes avant que la productivité ne soit affectée. Vous pouvez vous attendre à ce que toutes les bases de données qui ne sont pas supervisées régulièrement posent tôt ou tard des problèmes.

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 ni configurer du matériel. Toutefois, comme vous devez toujours repérer les problèmes de développement, la supervision est prioritaire parmi vos tâches quotidiennes.

Avant de migrer des bases de données dans le cloud, découvrez les outils de supervision actuellement utilisés par vos administrateurs. Si ces outils sont compatibles avec la solution basée sur le cloud que vous proposez, il vous suffit peut-être de les reconnecter aux bases de données migrées. Si ce n’est pas le cas, vous devez investiguer les alternatives.

Gardez à l’esprit qu’Azure comprend un ensemble d’outils de supervision des performances et collecte un large éventail de compteurs de performances et de données de journal. Vous pouvez afficher ces données à l’aide des tableaux de bord et des graphiques dans le portail Azure, en configurant Azure Monitor. Vous pouvez créer des graphes, des tables et des rapports personnalisés, conçus spécifiquement 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 locale. S’ils utilisent les mêmes outils après la migration, vous pouvez continuer à bénéficier 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 sont 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 d’administration actuels ne fonctionnent pas après la migration, essayez d’identifier des solutions alternatives avec vos administrateurs.

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

Le portail Azure. Ce site web offre de puissantes fonctionnalités que vous utilisez pour configurer, superviser 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 scripts et d’un langage avec un large éventail de commandes. Utilisez PowerShell, qui est disponible pour les environnements Windows et Linux, afin d’automatiser des tâches d’administration de base de données complexes.
Azure CLI. Il s’agit d’une interface de ligne de commande pour Azure. Utilisez-la pour gérer les services et les ressources dans Azure. Vous pouvez utiliser l’interface CLI à partir des environnements de shell Windows et Linux, et dans des scripts Bash.

Continuer