Fichiers de données SQL Server dans Microsoft Azure

S’applique à :SQL Server

Les fichiers de données SQL Server dans Microsoft Azure permettent une prise en charge native des fichiers de base de données SQL Server stockés en tant qu’objets blob. Cela vous permet de créer une base de données dans SQL Server s’exécutant localement ou sur une machine virtuelle dans Microsoft Azure, avec un emplacement de stockage dédié pour vos données dans le service Stockage Blob Azure de Microsoft. Cela simplifie également le processus de déplacement des bases de données entre les machines. Vous pouvez détacher des bases de données d’une machine pour les attacher à une autre machine. En outre, elle fournit un autre emplacement de stockage pour les fichiers de sauvegarde de base de données, ce qui permet de restaurer ces fichiers depuis ou vers le service Microsoft Azure Storage. Par conséquent, elle permet plusieurs solutions hybrides en offrant différents avantages en matière de virtualisation des données, de déplacement des données, de sécurité et de disponibilité, le tout à des coûts et une maintenance réduits pour une mise à l'échelle élastique et une haute disponibilité.

Cet article présente les concepts et considérations qui sont essentiels au stockage des fichiers de données SQL Server dans le service de stockage Microsoft Azure.

Pour obtenir une expérience pratique sur l’utilisation de cette fonctionnalité, consultez Tutoriel : Utilisation du Stockage Blob Microsoft Azure avec des bases de données SQL Server.

Pourquoi utiliser des fichiers de données SQL Server dans Microsoft Azure ?

• Migration facile et rapide : cette fonctionnalité simplifie le processus de migration en déplaçant une base de données à la fois entre les ordinateurs locaux ainsi qu’entre les environnements locaux et le cloud, sans aucune modification de l’application. Par conséquent, elle prend en charge une migration incrémentielle tout en conservant l'infrastructure locale existante. En outre, avoir accès à un stockage de données centralisé simplifie la logique d'application lorsqu'une application doit s'exécuter à plusieurs emplacements dans un environnement local. Dans certains cas, vous devrez peut-être configurer rapidement des centres informatiques dans des emplacements géographiquement dispersés, qui collectent des données provenant de nombreuses sources différentes. Avec Azure Data Files, au lieu de déplacer des données d’un emplacement à un autre, vous pouvez stocker un grand nombre de bases de données en tant qu’objets blob de page Microsoft Azure, puis exécuter des scripts Transact-SQL pour créer des bases de données sur les ordinateurs locaux ou les machines virtuelles.

• Coûts réduits et stockage illimité : cette fonctionnalité vous permet de bénéficier d’un stockage hors site illimité dans Microsoft Azure tout en tirant parti des ressources de calcul locales. Lorsque vous utilisez Microsoft Azure comme emplacement de stockage, vous pouvez aisément vous concentrer sur la logique d'application sans surcharge pour la gestion du matériel. Si vous perdez un nœud de calcul local, vous pouvez en configurer un autre sans aucun déplacement des données.

• Haute disponibilité et récupération d'urgence : la fonctionnalité Fichiers de données SQL Server dans Microsoft Azure peut simplifier les solutions de haute disponibilité et de récupération d'urgence. Par exemple, en cas de plantage d’une machine virtuelle dans Microsoft Azure ou d’une instance de SQL Server, vous pouvez recréer vos bases de données dans une nouvelle instance de SQL Server en rétablissant simplement les liens vers les objets blob.

• Avantages en matière de sécurité : avec les fichiers de données SQL Server dans Azure, vous pouvez séparer une instance de calcul d’une instance de stockage. Vous pouvez avoir une base de données entièrement chiffrée où le déchiffrement ne concerne que l'instance de calcul, mais pas l'instance de stockage. En d’autres termes, vous pouvez chiffrer toutes les données dans un cloud public à l’aide de certificats TDE (Transparent Data Encryption), lesquels sont physiquement séparés des données. Les clés TDE peuvent être stockées dans la master base de données, qui est stockée localement dans votre ordinateur local sécurisé physiquement et sauvegardée localement. Vous pouvez utiliser ces clés locales pour chiffrer les données, qui résident dans Microsoft Azure Storage. Si les informations d'identification du compte de stockage en nuage (cloud) sont dérobées, vos données restent sécurisées dans la mesure où les certificats TDE résident toujours localement.

• Sauvegarde d’instantanés : cette fonctionnalité vous permet d’utiliser des instantanés Azure pour fournir des sauvegardes quasi instantanées et des restaurations plus rapides pour les fichiers de base de données stockés à l’aide du Stockage Blob Azure. Cette fonctionnalité vous permet de simplifier vos stratégies de sauvegarde et de restauration. Pour plus d’informations, consultez Sauvegarde d’instantanés de fichiers pour les fichiers de base de données dans Azure.

Concepts et configuration requise

Les disques Azure sont compatibles avec les solutions de continuité de l’activité et de reprise d’activité après sinistre à l’échelle de l’entreprise. Si vous stockez vos bases de données directement sur des objets blob ou dans Azure Premium Files, les données ne sont pas automatiquement associées à votre machine virtuelle pour l’infrastructure, la gestion et la supervision.

Le placement des fichiers de base de données dans des objets blob de pages est une fonctionnalité plus avancée que l’utilisation des disques Azure, qui sont simples et conviviaux.

L’aide de base repose sur l’utilisation de Disques Azure, sauf dans un scénario où vous devez absolument éviter de créer une copie des données pour les sauvegardes ou d’effectuer une restauration sous forme d’opération impactant la taille des données. Pour une haute disponibilité et une reprise d’activité après sinistre, l’utilisation d’une sauvegarde régulière vers une URL ou d’une sauvegarde managée vers le Stockage Blob est également beaucoup plus utile que les sauvegardes de captures instantanées de fichiers. En effet, vous bénéficiez de la gestion du cycle de vie, de la prise en charge multirégion, de la suppression réversible et de toutes les autres fonctionnalités du Stockage Blob pour vos sauvegardes.

Concepts liés au stockage Azure

Lorsque vous utilisez la fonctionnalité Fichiers de données SQL Server dans Azure, vous devez créer un compte de stockage et un conteneur dans Azure. Ensuite, vous devez créer des informations d'identification SQL Server, qui comportent des informations sur la stratégie du conteneur ainsi qu'une signature d'accès partagé qui est nécessaire pour accéder au conteneur.

Dans Microsoft Azure, un compte de stockage Azure représente le niveau le plus élevé de l’espace de noms pour accéder aux objets blob. Un compte de stockage peut contenir un nombre illimité de conteneurs, tant que leur taille totale ne dépasse pas la limite de stockage. Pour les informations les plus récentes sur les limites de stockage, consultez Abonnement Azure et limites, quotas et contraintes du service. Un conteneur regroupe un ensemble d’objets blobs. Tous les objets blob doivent figurer dans un conteneur. Un compte peut contenir un nombre illimité de conteneurs. De même, un conteneur peut stocker un nombre illimité d’objets blob.

Il existe deux types d’objets blob qui peuvent être enregistrés dans un stockage Azure : les objets blob de blocs et les objets blob de pages. Cette fonctionnalité utilise des objets blob de pages, qui sont plus efficaces lorsque les plages d’octets dans un fichier sont fréquemment modifiées. Vous pouvez accéder aux objets blob à l’aide du format URL suivant : https://storageaccount.blob.core.windows.net/<container>/<blob>.

Considérations sur la facturation Azure

L’estimation du coût d’utilisation des services Azure est une question importante dans le processus de prise de décision et de planification. Lorsque vous stockez des fichiers de données SQL Server dans le stockage Azure, vous devez payer les coûts associés au stockage et aux transactions. De plus, l’implémentation de la fonctionnalité Fichiers de données SQL Server dans le stockage Azure nécessite implicitement un renouvellement du bail d’objets blob toutes les 45 à 60 secondes. Cela entraîne également des coûts de transaction par fichier de base de données (.mdf ou .ldf, par exemple). Utilisez les informations de la page Tarification Azure pour estimer les coûts mensuels associés à l’utilisation de Stockage Azure et de Machines virtuelles Azure.

Concepts de SQL Server

Pour utiliser les objets blob de pages Azure pour les fichiers de données SQL Server :

• Créez une stratégie sur un conteneur et générez également une signature d’accès partagé (SAP).

• Pour chaque conteneur utilisé par un fichier de données ou un fichier journal, créez des informations d’identification SQL Server dont le nom correspond au chemin du conteneur.

• Stockez les informations relatives au conteneur de stockage Azure, le nom de stratégie associé et la clé SAS dans le magasin d’informations d’identification de SQL Server.

L’exemple suivant suppose qu’un conteneur de stockage Azure a été créé, et qu’une stratégie a également été créée avec des droits d’accès en lecture, écriture et listage. La création d’une stratégie sur un conteneur génère une clé SAS, qui peut être conservée non chiffrée en mémoire, et dont SQL Server a besoin pour accéder aux fichiers d’objets blob du conteneur.

Dans l’extrait de code suivant, remplacez '<your SAS key>' par la clé SAS. La clé SAS ressemble à ce qui suit 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>'.

CREATE CREDENTIAL [https://testdb.blob.core.windows.net/data]  
WITH IDENTITY='SHARED ACCESS SIGNATURE',  
SECRET = '<your SAS key>'  
  
CREATE DATABASE testdb   
ON  
( NAME = testdb_dat,  
    FILENAME = 'https://testdb.blob.core.windows.net/data/TestData.mdf' )  
 LOG ON  
( NAME = testdb_log,  
    FILENAME =  'https://testdb.blob.core.windows.net/data/TestLog.ldf')  

Pour plus d'informations, consultez Gérer l'accès aux ressources Azure Storage.

Sécurité

Vous trouverez ci-dessous les considérations de sécurité et la configuration requise pour le stockage de fichiers de données SQL Server dans le stockage Azure.

• Quand vous créez un conteneur pour le Stockage Blob Azure, nous vous recommandons de définir l’accès sur Privé. Lorsque vous définissez l’accès privé, le conteneur et les données blob ne peuvent être lus que par le propriétaire du compte Azure.

• Lors de l’enregistrement des fichiers de base de données SQL Server dans le stockage Azure, vous devez utiliser une signature d’accès partagé, un URI qui octroie des droits d’accès restreints aux conteneurs, aux objets blob, aux files d’attente et aux tables. À l’aide d’une signature d’accès partagé, vous pouvez autoriser SQL Server à accéder aux ressources dans votre compte de stockage sans partager votre clé de compte de stockage Azure.

• De plus, nous vous recommandons de continuer de suivre les pratiques de sécurité locales habituelles pour vos bases de données.

Conditions requises préalables à l’installation

Vous trouverez ci-dessous les conditions préalables à l’installation pour le stockage de fichiers de données SQL Server dans le stockage Azure.

• SQL Server local : SQL Server 2016 et ultérieur comprend cette fonctionnalité. Pour savoir comment télécharger la dernière version de SQL Server, consultez SQL Server.

• SQL Server s’exécutant sur une machine virtuelle Azure : si vous installez SQL Server sur une machine virtuelle Azure, installez SQL Server 2016 ou mettez à jour votre instance existante. De la même manière, vous pouvez aussi créer une nouvelle machine virtuelle dans Azure à l’aide de l’image de la plateforme SQL Server 2016.

Limitations

• En raison des caractéristiques de performances des charges de travail SQL Server, les fichiers de données SQL Server sont implémentés en tant qu’objets blob de pages dans le Stockage Blob Azure. D’autres types de stockage d’objets blob, tels que les objets blob de blocs ou Azure Data Lake Storage, ne sont pas pris en charge.

• Dans la version actuelle de cette fonctionnalité, l’enregistrement de données FileStream dans le stockage Azure n’est pas pris en charge. Vous pouvez stocker des données FileStream dans une base de données qui contient également des fichiers stockés dans le stockage Azure, mais tous les fichiers de données FileStream doivent se trouver sur le stockage local. Comme les données FileStream doivent résider sur un stockage local, il est impossible de les déplacer entre des ordinateurs à l’aide du stockage Azure. Nous vous recommandons donc d’utiliser les techniques traditionnelles pour déplacer les données associées à FileStream entre différents ordinateurs.

• Actuellement, une seule instance SQL Server peut accéder à un fichier de base de données spécifique dans Stockage Azure à un moment donné. Si InstanceA est en ligne avec un fichier de base de données actif et si InstanceB est démarré accidentellement et qu’elle a également une base de données qui pointe vers le même fichier de données, la deuxième instance ne parvient pas à démarrer la base de données avec un code 5120 Unable to open the physical file "%.\*ls". Operating system error %d: "%ls"d’erreur.

• Seuls les fichiers .mdf, .ldf et .ndf peuvent être enregistrés dans le Stockage Azure à l’aide de la fonctionnalité Fichiers de données SQL Server dans Azure.

• En cas d’utilisation de la fonctionnalité Fichiers de données SQL Server dans Azure, la géoréplication de votre compte de stockage n’est pas prise en charge. Si un compte de stockage est géorépliqué et qu'un géobasculement a lieu, la base de données risque d'être endommagée.

• Pour les limites de capacité, consultez Présentation du Stockage Blob.

• Il est impossible de conserver des données OLTP en mémoire dans le Stockage Blob à l’aide de la fonctionnalité Fichiers de données SQL Server dans le stockage Azure. Cela s’explique par le fait que l’OLTP en mémoire compte une dépendance sur FileStream et que, dans la version actuelle de cette fonctionnalité, l’enregistrement de données FileStream dans Azure Storage n’est pas pris en charge.

• Lors de l’utilisation de FICHIERS de données SQL Server dans la fonctionnalité Azure, SQL Server effectue toutes les comparaisons de chemins d’accès d’URL ou de fichier à l’aide du classement défini dans la master base de données.

• Lesgroupes de disponibilité AlwaysOn sont pris en charge tant que vous n’ajoutez pas de nouveaux fichiers de base de données au réplica principal. Si une opération de base de données nécessite la création d’un fichier dans la base de données sur le réplica principal, désactivez d’abord les groupes de disponibilité dans le nœud secondaire. Puis, effectuez l’opération de base de données dans la base de données et sauvegardez la base de données dans le réplica principal. Restaurez ensuite la base de données sur le réplica secondaire. Une fois que vous avez fini, réactivez les groupes de disponibilité Always On dans le nœud secondaire.

  Note

  Les instances de cluster de basculement Always On ne sont pas prises en charge en cas d’utilisation de la fonctionnalité Fichiers de données SQL Server dans Azure.

• En mode de fonctionnement normal, SQL Server utilise des baux temporaires afin de réserver des objets blob pour le stockage avec un renouvellement de bail de chaque objet blob toutes les 45 à 60 secondes. Si un serveur plante et si une autre instance de SQL Server configurée pour utiliser les mêmes objets blob démarre, la nouvelle instance attend jusqu’à 60 secondes, le temps que le bail existant sur l’objet blob expire. Si vous souhaitez attacher la base de données à une autre instance et si vous ne pouvez pas attendre l’expiration du bail pendant 60 secondes, vous pouvez libérer explicitement le bail sur l’objet blob.

Prise en charge des bibliothèques de référence de programmation et des outils

Cette section décrit les bibliothèques de référence de programmation et les outils qui peuvent être utilisés lors du stockage de fichiers de données SQL Server dans le stockage Azure.

Prise en charge dans PowerShell

Utilisez les applets de commande PowerShell pour stocker des fichiers de données SQL Server dans le service Stockage Blob en référençant une URL vers Stockage Blob à la place d’un chemin de fichier. Accédez aux objets blob à l’aide du format URL suivant : https://storageaccount.blob.core.windows.net/<container>/<blob>.

Prise en charge des compteurs de performances et des objets SQL Server

Depuis SQL Server 2014, un nouvel objet SQL Server a été ajouté pour être utilisé avec la fonctionnalité Fichiers de données SQL Server dans le stockage Azure. Le nouvel objet SQL Server est appelé SQL Server, HTTP_STORAGE_OBJECT et il peut être utilisé par le Moniteur système pour surveiller l’activité lors de l’exécution de SQL Server avec le Stockage Azure.

Prise en charge de SQL Server Management Studio

SQL Server Management Studio vous permet d'utiliser cette fonctionnalité via plusieurs fenêtres de dialogue. Par exemple, https://teststorageaccnt.blob.core.windows.net/testcontainer/ représente l’URL d’un conteneur de stockage. Vous pouvez voir ce chemin dans plusieurs fenêtres de boîte de dialogue, telles que New Database, Attach Database et Restore Database. Pour plus d’informations, consultez Tutoriel : Utiliser Stockage Blob Azure avec des bases de données SQL Server.

Prise en charge d’objets SMO (SQL Server Management Objects)

Quand vous utilisez la fonctionnalité Fichiers de données SQL Server dans Azure, tous les objets SMO (SQL Server Management Objects) sont pris en charge. Si un objet SMO nécessite un chemin d'accès de fichier, utilisez le format d'URL BLOB à la place d'un chemin d'accès de fichier local, tel que https://teststorageaccnt.blob.core.windows.net/testcontainer/. Pour plus d’informations sur les objets SMO (SQL Server Management Objects), consultez le Guide de programmation SMO (SQL Server Management Objects) dans la documentation en ligne de SQL Server.

Prise en charge de Transact-SQL

L’ajout de cette fonctionnalité a introduit le changement suivant dans la surface d’exposition de Transact-SQL :

• Nouvelle colonne int , credential_iddans la sys.master_files vue système. La credential_id colonne est utilisée pour permettre aux fichiers de données stockage Azure de revenir à sys.credentials des références croisées pour les informations d’identification créées pour elles. Vous pouvez vous en servir pour résoudre des problèmes, par exemple quand des informations d’identification ne peuvent pas être supprimées, car elles sont utilisées par un fichier de base de données.

Résoudre les problèmes liés aux fichiers de données SQL Server dans Microsoft Azure

Pour éviter des erreurs attribuables à des limitations ou à des fonctionnalités non prises en charge, passez d'abord en revue Limitations.

Voici la liste des erreurs possibles lorsque vous utilisez la fonctionnalité Fichiers de données SQL Server dans le stockage Azure.

Erreurs d'authentification

• Impossible de supprimer les informations d’identification '%.*ls', car elles sont utilisées par un fichier de base de données actif.
  Résolution : vous pouvez voir cette erreur lorsque vous tentez de supprimer des informations d’identification encore utilisées par un fichier de base de données actif dans le stockage Azure. Pour supprimer les informations d'identification, vous devez d'abord supprimer l'objet blob associé qui comporte ce fichier de base de données. Pour supprimer un objet blob dont le bail est actif, vous devez d’abord libérer le bail.

• La signature d'accès partagé n'a pas été créée correctement sur le conteneur.
  Résolution : vérifiez que vous avez créé correctement une signature d'accès partagé sur le conteneur. Passez en revue les instructions fournies dans la leçon 2 du tutoriel : Utiliser Stockage Blob Azure avec des bases de données SQL Server.

• Les informations d'identification de SQL Server n'ont pas été créées correctement.
  Résolution : vérifiez que vous avez utilisé une « signature d'accès partagé » pour le champ Identité et que vous avez créé un secret correctement. Passez en revue les instructions fournies dans la leçon 3 du tutoriel : Utiliser Stockage Blob Azure avec des bases de données SQL Server.

Erreurs de bail d'un objet blob :

• Erreur lors de la tentative de démarrage de SQL Server après la défaillance d'une autre instance utilisant les mêmes fichiers d'objets blob. Résolution : pendant l’opération normale, SQL Server utilise des baux temporaires pour réserver des objets blob pour le stockage avec un renouvellement de chaque bail d’objet blob toutes les 45 à 60 secondes. Si un serveur plante et si une autre instance de SQL Server configurée pour utiliser les mêmes objets blob démarre, la nouvelle instance attend jusqu’à 60 secondes, le temps que le bail existant sur l’objet blob expire. Si vous souhaitez attacher la base de données à une autre instance et si vous ne pouvez pas attendre l’expiration du bail pendant 60 secondes, vous pouvez libérer explicitement le bail sur l’objet blob pour éviter les erreurs dans les opérations d’attachement.

Erreurs de base de données

Erreurs lors de la création d’une résolution de base de données : passez en revue les instructions fournies dans la leçon 4 du tutoriel : Utiliser Le Stockage Blob Microsoft Azure avec des bases de données SQL Server.

Erreurs lors de l'exécution de l'instruction Alter Résolution : veillez à exécuter l'instruction Alter Database lorsque la base de données est en ligne. Lors de la copie des fichiers de données vers le stockage Azure, créez toujours un objet blob de pages, et non un objet blob de blocs. Sinon, la modification de la base de données avec l'instruction ALTER échouera. Passez en revue les instructions fournies dans la leçon 7 du tutoriel : Utiliser le Stockage Blob Microsoft Azure avec les bases de données SQL Server.

Code d’erreur - 5120 Impossible d’ouvrir le fichier physique « %.*ls ». Erreur %d du système d'exploitation : « %ls »

Résolution : cette fonctionnalité ne prend pas en charge l’accès simultané de plusieurs instances SQL Server aux mêmes fichiers de base de données dans Stockage Azure. Si InstanceA est en ligne avec un fichier de base de données actif et si InstanceB est démarré, et qu’elle a également une base de données qui pointe vers le même fichier de données, la deuxième instance ne parvient pas à démarrer la base de données avec un code 5120 Unable to open the physical file "%.\*ls". Operating system error %d: "%ls"d’erreur.

Pour résoudre ce problème, déterminez d’abord si vous avez besoin du serveur A pour accéder au fichier de base de données dans le stockage Azure. Sinon, supprimez les connexions entre InstanceA et les fichiers de base de données dans Stockage Azure. Pour cela, procédez comme suit :

1. Définissez le chemin d’accès du fichier InstanceA sur un dossier local à l’aide de l’instruction ALTER Database.

2. Mettez la base de données hors connexion sur InstanceA.

3. Puis, copiez les fichiers de base de données du Stockage Azure vers le dossier local dans InstanceA. Cela garantit que InstanceA dispose toujours d’une copie de la base de données localement.

4. Mettez la base de données en ligne.

Code d’erreur 833 - L’exécution des demandes d’E/S dure plus de 15 secondes

Cette erreur indique que le système de stockage n’est pas en mesure de répondre aux demandes de la charge de travail SQL Server. Diminuez l’activité d’E/S de la couche d’application ou augmentez la capacité de débit sur la couche de stockage. Pour en savoir plus, consultez Erreur 833. Si les problèmes de performances persistent, envisagez de déplacer les fichiers vers un autre niveau de stockage, par exemple Premium ou UltraSSD. Pour SQL Server sur les machines virtuelles Azure, consultez Optimisation des performances de stockage.

Étapes suivantes

• Créer une base de données