Fin de vie de SQL Server 2008

  • Article

Le 9 Juillet 2019 sera la fin du support pour les versions 2008 et 2008 R2 de SQL Server. Il est encore temps pour migrer vos serveurs vers la nouvelle version de SQL Server. Et pourquoi pas en profiter pour migrer vers Azure. D'autant plus qu'un nouveau service, Azure, SQL Managed Instance (MI), est désormais disponible en version « GA » depuis Octobre 2018, et permet une compatibilité proche des 100% avec un SQL Server installé sur site.

Enfin, dans le cas d'applications ne pouvant pas être migrées dans les prochains mois, il existe la possibilité de les héberger dans des machines virtuelles Azure, grâce aux modèles de machines embarquant directement SQL server, et de bénéficier dans ce cas d'une extension de support supplémentaire de 3 ans.

Dans cet article, nous allons voir, en fonction des situations, quelles sont les options possibles pour continuer à utiliser vos applications dans les meilleures conditions de supports et de fonctionnalités.

Ci-dessous, voici les 4 possibilités de migration :

  • Migration, sur site, vers la version 2017 (Quand cela est possible pour vos applications)
  • Migration vers SQL Database en mode PaaS (Quand cela est possible pour vos applications)
  • Migration vers Azure SQL Database Managed Instance, qui propose une compatibilité avec SQL Server proche de 100%
  • Dans le cas d'applications difficiles à migrer dans les prochains mois, déploiement dans une machine virtuelle Azure avec les modèles de machine virtuelle SQL Server 2008

Pré requis

En règle générale le processus de migration ressemble aux étapes illustrées ci-dessous. Même si au final, il existe de nombreuses manières d'exécuter un plan de migration, cela reste un projet à part entière :

La partie découverte peut se réaliser avec l'outil MAP Toolkit :

/Fr-fr/previous-versions//bb977556(v=technet.10)

Cependant, quelle que soit la solution envisagée, il est de bon augure de réaliser les tâches suivantes avant toute migration :

Sur le Server SQL source :

  • Vérifier que le dernier Service Pack est bien appliqué
  • Reconstruire les index (si les index sont très fragmentés)
  • Vérifier l'intégrité de votre base de données avec DBCC CHECKDB () (ou sur une copie, car cette opération peut prendre du temps)
  • Noter si la base de données n'est pas liée à un plan de maintenance
  • Noter la présence de serveurs liés
  • Noter si l'agent SQL est utilisé
  • Faire un backup complet

Sur la cible :

Migration vers SQL Server 2017 (sur site)

Ici, nous sommes dans un scénario classique de migration. Avec la version 2017, il est possible soit de passer par une sauvegarde puis une restauration de la base de données, soit utiliser l'outil Data Migration Assistant (DMA).

En plus des prérequis détaillés plus haut dans cet article, sur le serveur cible qui héberge SQL Server 2017 :

Enfin, vérifiez aussi les fonctionnalités dépréciées dans la version SQL Server 2017 : /fr-fr/sql/database-engine/deprecated-database-engine-features-in-sql-server-2017?view=sql-server-2017

 

En ce qui concerne la migration elle-même, il est possible d'utiliser les méthodes suivantes:

Sauvegarde et restauration des bases de données

 

Data Migration Assistant

Migration vers SQL Database (PaaS)

C'est une autre possibilité de migration, et aussi l'occasion de moderniser votre infrastructure de donnée avec les solutions Cloud. De plus, vous bénéficierez de tous les avantages d'un service managé (Pas de gestion de matériel, données répliquées en 3 exemplaires, gestion des mises à jour transparentes, élasticité, ….).

Encore une fois, il existe plusieurs méthodes pour migrer vos bases SQL vers SQL Database. Mais principalement, les 3 méthodes illustrées ci-dessous peuvent être utilisées, après avoir consulté les prérequis détaillés plus haut :

 

 

Afin de mesurer l'impact de la migration, il est possible d'utiliser l'outil Database Experimentation Assistant (DEA). Cet outil permet la capture de traces, sur un serveur existant, afin d'être rejouées sur SQL Database, SQL Managed instance ou SQL sur Linux. DEA peut être téléchargé ici : https://www.microsoft.com/en-us/download/details.aspx?id=54090

Enfin, comme je l'ai déjà mentionné, il existe d'autres manières de migrer ses bases de données comme l'utilisation de SQL Server Integration Services (SSIS) ou Azure Data Factory v2.

 

Migration vers Azure SQL Database Managed Instance (PaaS)

SQL Database Managed Instance (MI) est un service managé (PaaS) offrant une compatibilité avec SQL server proche de 100%, tout en supportant des fonctionnalités qui ne sont pas présentes dans SQL Database comme :

  • Fonction native de sauvegarde / restauration
  • Server lié
  • CLR
  • SQL Agent
  • DB mail (SMTP externe)
  • …

De plus, SQL Database MI fonctionne dans son propre VNet, ce qui permet de renforcer la sécurité de votre base de données…. Mais au détriment, aujourd'hui, d'un manque d'intégration avec, par exemple, les autres services Azure.

Une vue d'ensemble complète de SQL Database MI est disponible sur cette page web : https://docs.microsoft.com/fr-fr/azure/sql-database/sql-database-managed-instance#sql-features-supported

Migration vers SQL Database Managed Instance

Encore une fois, après avoir vérifié les prérequis expliqués plus haut dans cet article, il existe plusieurs solutions :

Globalement la sauvegarde à partir d'une URL va suivre le cheminement suivant :

Tous les détails, pour chaque méthode de migration, sont disponibles sur le lien suivant :

/fr-fr/azure/sql-database/sql-database-managed-instance-migrate

 

Attention aux 2 points suivants :

  • SQL Database Managed Instance doit être déployé au sein d'un réseau virtuel. L'article suivant donne les détails de configuration : /fr-fr/azure/sql-database/sql-database-managed-instance-vnet-configuration

  • La première création du service peut prendre jusqu'à 6h. J'ai réalisé un test dans la région Canada Central, et la première création à durée environ 3h15.

 

Migration vers une machine virtuelle Azure avec SQL Server (IaaS)

Dans le cas où il n'est pas encore possible de migrer vos bases SQL server 2008 vers SQL Server 2017, et pour rester couvert par le support, il existe la possibilité de déplacer vos bases de données vers un serveur SQL 2008 hébergé dans une machine virtuelle Azure. Pour cela, il est possible de provisionner directement, à partir d'un modèle existant, une machine virtuelle avec SQL Server 2008. Cela permet de gagner du temps et d'être certain d'avoir la bonne base technologique pour assurer le déplacement de vos bases de données.

Ci-dessous un exemple des modèles disponibles depuis le portail Azure.

 

 

Une fois la machine virtuelle provisionnée depuis les modèles proposés, il ne s'agit, ni plus ni moins, d'une migration vers un autre serveur SQL, avec une différence quand même, c'est qu'il va falloir transférer les données vers Azure, afin qu'elles soient accessibles par la machine virtuelle. Mais sinon, toutes les méthodes ci-dessous sont possibles pour bouger vos bases de données vers une machine virtuelle Azure hébergeant SQL Server :

  • Effectuer une sauvegarde locale par compression et copier manuellement le fichier de sauvegarde dans la machine virtuelle Azure
  • Effectuer une sauvegarde vers une URL et exécuter une restauration dans la machine virtuelle Azure à partir de cette URL
  • Détacher, puis copier les fichiers journaux et de données vers le stockage d'objets blob Azure, puis les rattacher à SQL Server dans la machine virtuelle Azure depuis une URL
  • Convertir une machine physique locale en disque dur virtuel Hyper-V, effectuer un téléchargement vers le stockage d'objets Blob Azure, puis exécuter un déploiement en tant que nouvelle machine virtuelle en utilisant le disque dur virtuel téléchargé
  • Expédition du disque dur avec le Service d'importation/exportation Windows : https://docs.microsoft.com/fr-fr/azure/storage/common/storage-import-export-service
  • Si vous disposez d'un déploiement AlwaysOn local, utilisez l' Assistant Ajout d'un réplica Azure pour créer un réplica dans Azure, puis basculez en dirigeant les utilisateurs vers l'instance de base de données Azure
  • Utiliser la réplication transactionnelle de SQL Server pour configurer l'instance Azure SQL Server en tant qu'abonné, puis désactiver la réplication en dirigeant les utilisateurs vers l'instance de base de données Azure

Toutes les méthodes énoncées ci-dessus sont détaillées dans l'article suivant :

/fr-fr/azure/virtual-machines/windows/sql/virtual-machines-windows-migrate-sql

 

J'aimerai terminer cet article par un grand merci à Frédéric Pichaut et Nicolas Soukoff qui ont complété et détaillé la partie prérequis, fort de leur grande expérience avec SQL Server. One MS Power ! Merci les gars !

Pour ceux qui seront à Montréal, je vous donne rendez-vous le 28 novembre 2018 au Tech Summit : https://www.microsoftevents.com/profile/web/index.cfm?PKwebID=0x1023303abcd&wt.mc_id=AID737011_QSG_SCL_276355

 

Franck Mercier