Passer en revue les stratégies et les outils de migration

Effectué

Dans le contexte de la migration de SQL Server, une planification minutieuse est essentielle pour garantir la réussite de la migration. Cette planification implique de savoir comment et pourquoi effectuer la migration.

Représentation visuelle du processus de migration de SQL Server qui souligne la compréhension des avantages, l’utilisation des outils et l’équilibrage du temps d’arrêt pour assurer la réussite de la migration.

  1. Comprendre le pourquoi implique de reconnaître les avantages une fois la migration terminée.
  2. Le comment englobe la sélection des outils de migration appropriés et le développement d’un plan de migration complet.
  3. Un élément essentiel de ce processus est l’évaluation du temps d’arrêt que l’organisation est prête à tolérer. Il est essentiel de réduire le temps d’arrêt pendant le processus de migration pour maintenir l’efficacité et la continuité opérationnelles.

Dans ce projet de migration, votre équipe a engagé le processus avec une réunion de lancement. Votre rôle consiste à explorer les outils de migration de quelques serveurs SQL Server et à fournir des insights sur l’effet potentiel sur les coûts futurs des licences SQL. En outre, vous devez parvenir à un accord sur le niveau acceptable de temps d’arrêt. Le chef de projet souhaite également incorporer une phase de test, au cours de laquelle quelques serveurs sont migrés à des fins de test avant l’exécution de la migration complète.

Comprendre les avantages de la migration

Vous utilisez probablement des machines virtuelles dans votre propre infrastructure en utilisant Hyper-V ou d’autres fournisseurs de machines virtuelles. La migration vers cette plateforme ne devrait donc pas générer une courbe d’apprentissage abrupte.

L’utilisation d’une machine virtuelle vous permet d’avoir un contrôle administratif total sur le système d’exploitation hôte et l’instance SQL Server. Vous pouvez configurer et gérer la haute disponibilité, la récupération d’urgence et l’application de correctifs pour SQL Server plus facilement que sur vos ordinateurs locaux. Vous pouvez également configurer des sauvegardes et des mises à jour automatiques pour faciliter votre charge administrative globale. L’exécution de SQL Server sur une machine virtuelle Azure prend entièrement en charge les composants SQL Server suivants :

  • Réplication transactionnelle SQL Server
  • Groupes de disponibilité Always On
  • Integration Services
  • Analysis Services
  • Reporting Services
  • Copie des journaux de transaction

SQL Server est optimisé pour la migration d’applications SQL Server existantes vers des machines virtuelles Azure, avec jusqu’à 256 To de stockage pris en charge. Toutes les versions et éditions de SQL Server sont disponibles et offrent une compatibilité à 100 % avec vos versions locales de SQL Server.

Licence

Il existe trois types de modèles de licence qui peuvent être utilisés pour les machines virtuelles SQL Server hébergées dans Azure. Évaluez celle qui convient le mieux à votre scénario de migration.

  • Le modèle Paiement à l’utilisation (PAYG) signifie que le coût par seconde de l’exécution de la machine virtuelle Azure comprend le coût de la licence SQL Server.

  • Le modèle BYOL (apportez votre propre licence) est également connu sous le nom d’Azure Hybrid Benefit (AHB) et vous permet d’utiliser votre propre licence SQL Server avec une machine virtuelle exécutant SQL Server. Vous ne payez que pour l’utilisation de machines virtuelles. Cette option est disponible uniquement pour les clients qui disposent d’un Accord Entreprise.

  • Le modèle de licence haute disponibilité/récupération d’urgence (HA/DR) est utilisé pour le réplica HA/DR gratuit dans Azure. Si vous avez Software Assurance, vous pouvez implémenter des plans de récupération d’urgence hybride avec SQL Server sans entraîner des coûts de licence supplémentaires pour l’instance de récupération d’urgence passive.

Conseil

Pour savoir comment modifier le modèle de licence d’une machine virtuelle SQL dans Azure, consultez l’article Changer le modèle de licence d’une machine virtuelle SQL dans Azure.

Mise en réseau

Si vous approvisionnez une machine virtuelle SQL Server dans le Portail Azure, vous avez la possibilité de spécifier le type de connectivité SQL, notamment :

  • Public : connexion à SQL Server via Internet.
  • Privé : connexion à SQL Server dans le même réseau virtuel.
  • Local : connexion à SQL Server localement sur la même machine virtuelle.

Si vous souhaitez vous connecter à votre moteur de base de données SQL Server depuis Internet, sélectionnez Public. Le portail effectue automatiquement les étapes suivantes :

  • Il active le protocole TCP/IP pour SQL Server.
  • Il configure une règle de pare-feu pour ouvrir le port TCP de SQL Server (1433 par défaut).
  • Il active l’authentification SQL Server, requis pour l’accès public.
  • Il configure le groupe de sécurité réseau sur l’ordinateur virtuel pour tout trafic TCP sur le port SQL Server.

Lorsque vous choisissez l’option Privé comme type de connectivité SQL dans le portail, Azure effectue une configuration identique à Public pour la plupart des paramètres. La différence est qu’il n’existe aucune règle de groupe de sécurité réseau pour autoriser le trafic externe sur le port SQL Server (1433 par défaut). Vous pouvez modifier les paramètres de connectivité pour votre machine virtuelle SQL dans le Portail Azure.

Gestion des clés

SQL Server fournit des fonctionnalités de chiffrement qui nécessitent que vous gériez et stockiez les clés de chiffrement. Le service Azure Key Vault (coffre de clés Azure, AKV) est conçu pour optimiser la sécurité et la gestion de ces clés dans un emplacement sécurisé et hautement disponible. Le connecteur SQL Server permet à SQL Server d’utiliser ces clés depuis Azure Key Vault.

Vous pouvez gagner du temps grâce à la fonctionnalité d’intégration AKV. Lorsque cette fonctionnalité est activée, elle installe automatiquement le connecteur SQL Server. La fonctionnalité configure ensuite le fournisseur EKM (Extensible Key Management) pour accéder à AKV, et crée les informations d’identification pour vous permettre d’accéder à votre coffre.

Dimensionnement des machines virtuelles

Pour commencer, vous pouvez choisir une image de machine virtuelle SQL Server avec la version, l’édition et le système d’exploitation requis. En outre, vous pouvez configurer le nombre de processeurs et la mémoire sur la taille appropriée pour vos charges de travail.

La plupart des options de réglage des performances de la base de données que vous utilisez pour vous assurer que votre SQL Server fonctionne correctement pour vos charges de travail locales s’appliquent toujours à SQL Server s’exécutant sur une machine virtuelle Azure. Vous devez prendre en compte d’autres éléments, notamment la taille de la machine virtuelle et la configuration des disques. Utilisez la liste de vérification suivante comme guide pour vous assurer que les performances optimales sont définies pour un SQL Server s’exécutant sur une machine virtuelle Azure.

Mesure de performance Option d’optimisation
Machine virtuelle
  • La taille minimale de machine virtuelle qui doit être sélectionnée pour les éditions Enterprise de SQL Server est DS3_v2 ou supérieure
  • Pour l’édition standard ou Web, utiliser DS2_v2 comme taille minimale
Stockage
  • Utiliser des disques SSD Premium pour les charges de travail de production
  • Stockage Standard pour l’environnement dev/test
  • S’assurer que le stockage est colocalisé au même emplacement que la machine virtuelle
Disques
  • Utiliser au moins 2 disques P30 (1 pour les fichiers journaux et 1 pour les fichiers de données notamment TempDB)
  • Pour les charges de travail nécessitant ~50 000 E/S par seconde, envisager d’utiliser un disque SSD Ultra
  • Éviter d’utiliser des disques de système d’exploitation ou temporaires pour le stockage ou la journalisation des bases de données
  • Activer la mise en cache de lecture sur le ou les disques hébergeant les fichiers de données et TempDB
  • Ne pas activer la mise en cache sur le ou les disques hébergeant le fichier journal
  • Entrelacer plusieurs disques de données Azure pour obtenir un débit d’E/S plus élevé
  • Formater avec des tailles d’allocation documentées
  • Placer TempDB sur le disque SSD local pour les charges de travail SQL Server stratégiques (après avoir choisi la bonne taille de machine virtuelle)
E/S
  • Activer la compression des pages de base de données
  • Activer l’initialisation de fichiers instantanée pour les fichiers de données
  • Limiter la croissance automatique sur la base de données
  • Désactiver la réduction automatique sur la base de données
  • Déplacer toutes les bases de données vers des disques de données, y compris les bases de données système
  • Déplacer les répertoires des journaux d’erreurs et des fichiers de trace SQL Server vers des disques de données
  • Configurer les emplacements par défaut du fichier de sauvegarde et du fichier de base de données
  • Activer les pages verrouillées
  • Appliquer les correctifs de performances de SQL Server

Vous souhaiterez peut-être appliquer des paramètres de performances spécifiques à votre charge de travail. Assurez-vous que les paramètres ont été testés dans un environnement de test avant la migration.

Outils et fonctionnalités pour la prise en charge de votre migration

Il existe de nombreuses méthodes de migration de votre serveur SQL Server vers une machine virtuelle Azure. La première étape du processus consiste à approvisionner une machine virtuelle Azure sur laquelle SQL Server est installé.

Pour obtenir les meilleures performances de transfert de données, migrez les fichiers de base de données de la machine virtuelle Azure à l’aide d’un fichier de sauvegarde compressé.

Pour réduire le temps d’arrêt pendant le processus de migration de base de données, utilisez l’option Always On ou l’option de réplication transactionnelle. S’il n’est pas possible d’utiliser l’une des méthodes ci-dessus, vous pouvez toujours migrer manuellement votre base de données.

Il s’agit des principaux outils et fonctionnalités permettant de prendre en charge et de migrer vos bases de données SQL Server vers SQL Server exécuté sur une machine virtuelle Azure.

  • Extension de migration Azure SQL pour Azure Data Studio : l’extension de migration Azure SQL est optimisée avec la dernière version de Azure Database Migration Service et vous aide à évaluer votre état de préparation à la migration, en fournissant des recommandations de références SKU appropriées pour les ressources Azure, et en facilitant la migration de votre base de données SQL Server vers Azure. Il s’agit d’un outil idéal pour les bases de données de petites et moyennes entreprises. Il repose sur la dernière version des services de migration des données. Il fournit également une fonctionnalité d’évaluation avancée qui évalue les bases de données SQL Server prêtes pour la migration vers Azure SQL.

  • Sauvegarde et restauration avec Stockage Blob Azure : vous pouvez restaurer une base de données de Stockage Blob Azure vers votre serveur SQL Server exécuté sur une machine virtuelle Azure.

  • Détachement et attachement à partir d’une URL : vous pouvez détacher votre base de données et fichiers journaux, puis les transférer vers un compte Stockage Azure. Attachez ensuite la base de données à partir de l’URL de l’objet blob sur votre machine virtuelle Azure.

  • Copie des journaux de transaction : la copie des journaux de transaction est une méthode permettant de migrer une base de données SQL Server vers une machine virtuelle Azure. Elle implique la synchronisation continue d’une copie secondaire de la base de données sur le serveur de destination à l’aide de sauvegardes des journaux des transactions à partir du serveur source. Quand elle est prête, la sauvegarde finale de fichier journal est appliquée à la machine virtuelle Azure, ce qui permet une migration transparente avec un temps d’arrêt minimal.

  • Azure Migrate : Azure Migrate est un service de migration complet qui prend en charge un large éventail de scénarios de migration, notamment la migration SQL Server. Azure Migrate fournit une suite d’outils conçus pour l’évaluation et la migration des serveurs locaux, de l’infrastructure, des applications et des données à grande échelle dans le cadre d’une migration vers Azure.

  • Assistant Expérimentation de base de données (DEA) : utilisez cet Assistant pour déterminer si votre serveur cible peut gérer la charge de travail si vous rencontrez des problèmes de performances. Vous pouvez utiliser les métriques d’analyse pour obtenir des données de comparaison vous permettant de déterminer si la version ciblée offre une meilleure expérience après la migration.

  • Assistant Migration de données (DMA) : utilisez-le pour migrer le schéma de base de données, les données, les utilisateurs, les rôles de serveur, SQL Server et les connexions Windows d’un serveur SQL Server local vers un serveur SQL Server sur une machine virtuelle Azure. L’outil exécute d’abord une évaluation qui vous invite à résoudre tout problème de compatibilité. Vous pouvez ensuite utiliser le même outil pour migrer le schéma et les données de la base de données évaluée vers Azure.

Remarque

Bien que l’Assistant Migration de données soit un outil disponible utile, nous vous recommandons d’utiliser le service Azure Database Migration Service pour des migrations volumineuses et bénéficier d’une expérience globale améliorée.

Conseil

Pour savoir comment évaluer des instances SQL Server locales à migrer vers Azure SQL et découvrir les nouvelles fonctionnalités de la plateforme SQL Server cible dont la base de données peut tirer parti après une mise à niveau, consultez Évaluer des bases de données SQL Server pour une migration vers un module Azure SQL.

Définir votre approche de migration

Il est important de prendre en compte les exigences de temps d’arrêt associées à la migration. Si vous migrez vers SQL Server sur une machine virtuelle ou sur une Azure SQL Database.

La méthode choisie pour migrer la base de données dépend généralement de la durée pendant laquelle les bases de données SQL Server peuvent être hors ligne. Un autre facteur de votre décision peut être la part du processus que vous souhaitez automatiser par rapport à la migration manuelle. Il existe trois types de migrations basés sur le temps d’arrêt :

  • Migration sans temps d’arrêt
  • Migration avec une petite fenêtre de maintenance
  • Migration avec une grande fenêtre de maintenance

Migration sans temps d’arrêt

Les charges de travail stratégiques nécessitent normalement des migrations sans temps d’arrêt. Vous pouvez utiliser des groupes de disponibilité Always On pour répliquer les données d’une base de données SQL Server vers un serveur SQL Server sur une machine virtuelle Azure.

Migration avec une petite fenêtre de maintenance

Les petites fenêtres de maintenance sont souvent exprimées en minutes. Utilisez Azure Database Migration Service pour répliquer et migrer des données d’une base de données SQL Server locale vers un serveur SQL Server exécuté sur une machine virtuelle Azure.

Remarque

Pour migrer une application entière, vous pouvez utiliser Azure Site Recovery.

Migration avec une grande fenêtre de maintenance

Les grandes fenêtres de maintenance sont souvent mesurées en heures ou en jours, et conviennent aux bases de données d’application qui changent rarement ou dans lesquelles la charge de travail n’est pas essentielle pour l’entreprise. Vous avez plusieurs possibilités : utiliser des fichiers d’exportation et d’importation SQL Server Management Studio BACPAC, utiliser une approche de sauvegarde et de restauration ou détacher puis attacher la base de données.