Déplacer des données vers SQL Managed Instance

  • 15 minutes

Beaucoup de migrations passent par une phase où la base de données locale et la base de données cloud doivent être synchronisées. Par exemple, il peut arriver que des clients apportent des modifications aux deux bases de données.

Vous avez migré la base de données des produits de sport dans Azure SQL Managed Instance. Le site web utilise déjà la base de données cloud. Vous commencez à reconfigurer les clients pour qu’ils utilisent la nouvelle base de données. Vous avez décidé de faire passer les utilisateurs au nouveau système par lots. Pour chaque équipe, vous devez prendre le temps de résoudre les problèmes éventuels avant de migrer les prochains utilisateurs. Cette approche permet de résoudre les problèmes sans perturber tous les utilisateurs en même temps. Ensuite, vous reconfigurez le système d’analyse de données pour utiliser la nouvelle base de données dans Azure. Pendant ce temps, vous voulez vérifier que la base de données cloud et la base de données locale sont synchronisées toutes les heures.

Vous allez explorer différentes méthodes pour implémenter la synchronisation des données. Ces méthodes peuvent également être utilisées pour migrer les données de manière sélective, si jamais vous avez besoin de transférer une partie des tables seulement. Cette flexibilité permet une approche plus personnalisée de la migration des données.

Options de connectivité avec les serveurs locaux

Il est souvent nécessaire de garder les données des bases de données locales synchronisées avec Azure SQL Managed Instance. Par exemple, vous pouvez souhaiter organiser la migration d’applications clientes vers la nouvelle base de données, ce qui signifie qu’à un moment donné, les clients se connecteront aux deux bases de données.

Avant de choisir une méthode de synchronisation des données, il est important de vérifier que votre connectivité est sécurisée. Pour établir la communication entre les ordinateurs locaux et les ressources Azure, vous avez le choix entre trois options de connectivité différentes.

  • Point à site. Une connexion par passerelle VPN point à site (P2S) vous permet de créer une connexion sécurisée à votre réseau virtuel à partir d’un ordinateur de client individuel.
  • Site à site. Une passerelle VPN de site à site est utile pour connecter un site local complet au réseau Azure.
  • ExpressRoute. Azure ExpressRoute vous permet de créer des connexions privées entre des centres de données Azure et votre infrastructure locale ou l’infrastructure d’un environnement de colocation. Les connexions ExpressRoute ne transitent pas par l’Internet public et offrent de meilleurs niveaux de fiabilité, de rapidité, de latence et de sécurité que les connexions Internet classiques.

Point de terminaison public

Le point de terminaison public pour SQL Managed Instance vous permet de vous connecter à la base de données à partir d’Internet sans utiliser de VPN et est conçu pour la communication de données uniquement. Le point de terminaison public pour les données peut coexister simultanément avec le point de terminaison privé. Pour des raisons de sécurité, l’implémentation prévoit une séparation des tâches entre un administrateur de base de données et un administrateur réseau lors de l’activation du point de terminaison public.

L’activation du point de terminaison public pour l’instance managée passe par deux étapes obligatoires. Pour effectuer ces étapes, vous aurez besoin de deux rôles distincts en vertu de la séparation des tâches, avec les autorisations de base de données et réseau suivantes :

  1. Un administrateur de base de données avec des autorisations de contrôle d’accès en fonction du rôle dans l’étendue Microsoft.Sql/managedInstances/* doit exécuter un script PowerShell afin d’activer le point de terminaison public pour l’instance managée.
  2. Un administrateur réseau avec des autorisations de contrôle d’accès en fonction du rôle dans l’étendue Microsoft.Network/* doit ouvrir le port 3342 utilisé par le point de terminaison public sur le groupe de sécurité réseau (NSG) et indiquer une route UDR pour éviter un routage asymétrique.

Choisir une méthode de synchronisation

Vous pouvez utiliser un grand nombre de méthodes pour synchroniser les données d’une instance managée SQL Database avec un serveur local et inversement.

Sauvegarde et restauration natives

Vous pouvez restaurer une base de données dans Azure SQL Managed Instance à partir d’un fichier Stockage Blob Azure à l’aide d’une signature d’accès partagé (SAS).

Cela implique la création d’informations d’identification avec un accès au Stockage Blob Azure, puis l’utilisation de la commande BACKUP DATABASE avec l’option COPY_ONLY. Si votre base de données est supérieure à 200 Go, vous pouvez utiliser une sauvegarde sur bande en fournissant plusieurs emplacements d’URL.

BACKUP DATABASE YourDatabase TO URL = 'https://youraccount.blob.core.windows.net/yourcontainer/yourdatabase.bak' WITH COPY_ONLY

Pour restaurer la base de données dans SQL Managed Instance :

RESTORE DATABASE YourDatabase FROM URL = 'https://youraccount.blob.core.windows.net/yourcontainer/yourdatabase.bak'

Fichier BACPAC avec SqlPackage

Un fichier BACPAC est essentiellement une version compressée des métadonnées et des données de votre base de données. Bien que cette méthode de déploiement soit compatible avec SQL Database, SQL Managed Instance ne prend pas en charge la migration via BACPAC dans le portail Azure. En guise d’alternative, l’utilitaire SQLPackage doit être utilisé avec le fichier BACPAC.

Programme de copie en bloc (BCP)

L’utilitaire BCP est un outil en ligne de commande qui exporte les tables dans des fichiers pour vous permettre de les importer. Utilisez cette approche pour migrer d’une base de données SQL unique vers SQL Managed Instance et inversement.

Azure Data Factory (ADF)

Azure Data Factory est conçu pour le déplacement et l’orchestration de données, avec l’accent mis sur l’ingestion. ADF assure la prise en charge du runtime d’intégration pour exécuter des packages SSIS ainsi que la prise en charge de l’Internet public pour SQL Managed Instance.

Réplication transactionnelle

La réplication transactionnelle est un moyen de déplacer des données entre des serveurs de base de données connectés en continu.

Le processus commence par un instantané des objets et des données de base de données. Une fois l’instantané initial pris, toutes les modifications ultérieures des données ou du schéma sur le serveur de publication sont généralement remises à Azure SQL Managed Instance en quasi-temps réel à mesure qu’elles sont apportées.

SQL Managed Instance est flexible parce qu’il peut faire office de serveur de publication, de serveur de distribution et d’abonné.

La réplication est l’une des quelques technologies qui vous permet de répliquer des parties d’une table. Nous appelons ces parties de table des articles. Ces données sont ensuite envoyées à un serveur de distribution, qui fournit les données à un nombre quelconque d’abonnés.

Exigences

  • La connectivité doit utiliser l’authentification SQL entre les participants de la réplication.
  • Un partage de compte de stockage Azure pour le répertoire de travail utilisé par la réplication.
  • Port 445 (trafic TCP sortant) ouvert dans les règles de sécurité du sous-réseau de l’instance managée pour accéder au partage de fichiers Azure.
  • Port 1433 (trafic TCP sortant) ouvert si le serveur de publication ou le serveur de distribution se trouve sur une instance managée et que l’abonné est en local.

Connexion d’applications à une instance managée SQL

Une instance managée SQL doit être placée à l’intérieur d’un sous-réseau de réseau virtuel Azure dédié aux instances managées. Ce déploiement vous confère une adresse IP privée sécurisée et la possibilité de vous connecter à des réseaux locaux.

Diagramme montrant comment la connectivité a lieu dans Azure SQL Managed Instance.

Les utilisateurs et les applications clientes peuvent se connecter à la base de données d’instance managée via le portail Azure, PowerShell, Azure CLI et l’API REST.

Toutes les communications sont chiffrées et signées avec des certificats. Pour vérifier la fiabilité des parties communicantes, les instances managées vérifient en permanence ces certificats à l’aide de listes de révocation de certificat. Si les certificats sont révoqués, l’instance managée SQL ferme les connexions pour protéger les données.