Fichiers de données SQL Server dans Azure

SQL Server Data Files dans Azure permet une prise en charge native des fichiers de base de données SQL Server stockés en tant que blobs Azure. Il vous permet de créer une base de données dans SQL Server s’exécutant localement ou dans une machine virtuelle dans Azure avec un emplacement de stockage dédié pour vos données dans stockage Blob Azure. Cette amélioration simplifie particulièrement le déplacement de bases de données entre les machines à l’aide des opérations de détachement et d’attachement. En outre, il fournit un autre emplacement de stockage pour vos fichiers de sauvegarde de base de données en vous permettant de restaurer à partir ou vers Stockage Azure. Par conséquent, il permet plusieurs solutions hybrides en offrant plusieurs avantages pour la virtualisation des données, le déplacement des données, la sécurité et la disponibilité, ainsi que tout coût et maintenance faciles pour la haute disponibilité et la mise à l’échelle élastique.

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

Pour obtenir une expérience pratique sur l’utilisation de cette nouvelle fonctionnalité, consultez Tutoriel : Fichiers de données SQL Server dans le service Stockage Azure.

Le diagramme suivant montre que cette amélioration vous permet de stocker des fichiers de base de données SQL Server en tant qu’objets blob Azure dans stockage Azure, quel que soit l’emplacement de votre serveur.

Avantages de l’utilisation de SQL Server Data Files dans Azure

• Avantages de la migration facile et rapide : Cette fonctionnalité simplifie le processus de migration en déplaçant une base de données à la fois entre les machines locales et entre les environnements locaux et cloud sans aucune modification de l’application. Par conséquent, il prend en charge une migration incrémentielle tout en conservant votre infrastructure locale existante en place. En outre, l’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. En utilisant cette nouvelle amélioration, au lieu de déplacer des données d’un emplacement vers un autre, vous pouvez stocker de nombreuses bases de données en tant qu’objets blob Azure, puis exécuter des scripts Transact-SQL pour créer des bases de données sur les machines locales ou les machines virtuelles.

• Avantages du stockage sans coût et sans limite : Cette fonctionnalité vous permet d’avoir un stockage hors site illimité dans Azure tout en tirant parti des ressources de calcul locales. Lorsque vous utilisez Azure comme emplacement de stockage, vous pouvez facilement vous concentrer sur la logique d’application sans surcharge de gestion matérielle. Si vous perdez un nœud de calcul local, vous pouvez configurer un nouveau nœud sans déplacement de données.

• Avantages de la haute disponibilité et de la récupération d’urgence : L’utilisation de SQL Server Data Files dans Azure peut simplifier les solutions de haute disponibilité et de récupération d’urgence. Par exemple, si une machine virtuelle dans Azure ou une instance de SQL Server se bloque, vous pouvez recréer vos bases de données sur une nouvelle machine en réinscrire des liens vers des objets blob Azure.

• Avantages de sécurité : Cette nouvelle amélioration vous permet de séparer une instance de calcul d’une instance de stockage. Vous pouvez avoir une base de données entièrement chiffrée avec déchiffrement uniquement sur l’instance de calcul, mais pas dans une instance de stockage. En d’autres termes, à l’aide de cette nouvelle amélioration, vous pouvez chiffrer toutes les données dans le cloud public à l’aide de certificats TDE (Transparent Data Encryption), qui sont physiquement séparés des données. Les clés TDE peuvent être stockées dans la base de données master, 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 stockage Azure. Si vos informations d’identification de compte de stockage cloud sont volées, vos données restent toujours sécurisées, car les certificats TDE résident toujours en local.

Concepts et exigences

Concepts du stockage Azure

Lorsque vous utilisez la fonctionnalité Sql Server Data Files 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 incluent des informations sur la stratégie du conteneur, ainsi qu’une signature d’accès partagé nécessaire pour accéder au conteneur.

Dans Azure, un compte de stockage 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 est inférieure à 500 To. Pour obtenir les informations les plus récentes sur les limites de stockage, consultez Les limites, quotas et contraintes d’abonnement Azure et de service. Un conteneur fournit un regroupement d'un ensemble de blobs. Tous les objets blob doivent se trouver 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 stockés dans Azure Storage : les objets blob de blocs et les objets blob de pages. Cette nouvelle fonctionnalité utilise des objets blob de pages, qui peuvent atteindre jusqu’à 1 To de taille et sont plus efficaces lorsque des plages d’octets dans un fichier sont fréquemment modifiées. Vous pouvez accéder aux objets blob au format d’URL suivant : http://storageaccount.blob.core.windows.net/<container>/<blob>.

Considérations relatives à la facturation Azure

L’estimation du coût d’utilisation des services Azure est une question importante dans le processus décisionnel et de planification. Lorsque vous stockez des fichiers de données SQL Server dans stockage Azure, vous devez payer les coûts associés au stockage et aux transactions. En outre, l'implémentation de la fonctionnalité Fichiers de données SQL Server dans Stockage Azure nécessite un renouvellement implicite du bail de blob toutes les 45 à 60 secondes. Cela entraîne également des coûts de transaction par fichier de base de données, tels que .mdf ou .ldf. Selon nos estimations, le coût du renouvellement des baux pour deux fichiers de base de données (.mdf et .ldf) serait d’environ 2 cents par mois selon le modèle de tarification actuel. Nous vous recommandons d’utiliser les informations de la page tarification Azure pour vous aider à estimer les coûts mensuels associés à l’utilisation du stockage Azure et des machines virtuelles Azure.

Concepts de SQL Server

Lorsque vous utilisez cette nouvelle amélioration, vous devez effectuer les opérations suivantes :

• Vous devez créer une stratégie sur un conteneur et générer également une clé de signature d’accès partagé (SAP).

• Pour chaque conteneur utilisé par des données ou un fichier journal, vous devez créer des informations d’identification SQL Server dont le nom correspond au chemin d’accès du conteneur.

• Vous devez stocker les informations relatives au conteneur de stockage Azure, à son nom de stratégie associé et à la clé SAS dans le magasin d'informations d'identification SQL Server.

L’exemple suivant suppose qu’un conteneur de stockage Azure a été créé et qu’une stratégie a été créée avec des droits de lecture, d’écriture et de liste. La création d’une stratégie sur un conteneur génère une clé SAP qui est sécurisée pour conserver une clé non chiffrée en mémoire et nécessaire par SQL Server pour accéder aux fichiers blob du conteneur. Dans l’extrait de code suivant, remplacez 'your SAS key' par une entrée similaire à la suivante : 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>'. Pour plus d’informations, consultez Créer et utiliser une signature d’accès partagé

-- Create a credential  
CREATE CREDENTIAL [https://testdb.blob.core.windows.net/data]  
WITH IDENTITY='SHARED ACCESS SIGNATURE',  
SECRET = 'your SAS key'  
  
-- Create database with data and log files in Azure container.  
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')

Sécurité

Voici quelques considérations et exigences de sécurité lors du stockage de fichiers de données SQL Server dans stockage Azure.

• Lors de la création d’un conteneur pour le service stockage Blob Azure, nous vous recommandons de définir l’accès privé. Lorsque vous définissez l’accès aux données privées, conteneur et blob peuvent être lues uniquement par le propriétaire du compte Azure.

• Lorsque vous stockez des fichiers de base de données SQL Server dans Stockage Azure, vous devez utiliser une signature d’accès partagé, un URI qui accorde des droits d’accès restreints aux conteneurs, aux objets blob, aux files d’attente et aux tables. En utilisant une signature d’accès partagé, vous pouvez autoriser SQL Server à accéder aux ressources de votre compte de stockage sans partager votre clé de compte de stockage Azure.

• En outre, nous vous recommandons de continuer à implémenter les pratiques de sécurité locales traditionnelles pour vos bases de données.

Conditions préalables à l’installation

Les conditions préalables à l’installation suivantes sont requises lors du stockage de fichiers de données SQL Server dans Azuree.

• SQL Server local : La version de SQL Server 2014 inclut cette fonctionnalité. Pour savoir comment télécharger SQL Server 2014, consultez SQL Server 2014.

• SQL Server s’exécutant sur une machine virtuelle Azure : si vous installez SQL Server sur une machine virtuelle Azure, installez SQL Server 2014 ou mettez à jour votre instance existante. De même, vous pouvez également créer une machine virtuelle dans Azure à l’aide de l’image de plateforme SQL Server 2014. Pour savoir comment télécharger SQL Server 2014, consultez SQL Server 2014.

Limites

• Dans la version actuelle de cette fonctionnalité, le stockage des FileStream données dans Stockage Azure n’est pas pris en charge. Vous pouvez stocker des Filestream données dans une base de données locale intégrée avec Azure Storage, mais vous ne pouvez pas déplacer des données Filestream entre des machines en utilisant Azure Storage. Pour FileStream les données, nous vous recommandons de continuer à utiliser les techniques traditionnelles pour déplacer les fichiers (.mdf, .ldf) associés à Filestream entre différents ordinateurs.

• Actuellement, cette nouvelle amélioration ne prend pas en charge plusieurs instances SQL Server accédant aux mêmes fichiers de base de données dans stockage Azure en même temps. Si ServerA est en ligne avec un fichier de base de données actif et si ServerB est démarré accidentellement et qu’il a également une base de données qui pointe vers le même fichier de données, le deuxième serveur ne démarre pas la base de données avec un code d’erreur 5120 Impossible d’ouvrir le fichier physique «%.*ls ». Erreur du système d’exploitation %d: «%ls».

• Seuls les fichiers .mdf, .ldf et .ndf peuvent être stockés dans stockage Azure à l’aide de la fonctionnalité SQL Server Data Files dans Azure.

• Lorsque vous utilisez la fonctionnalité SQL Server Data Files 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éo-basculement s’est produit, un endommagement de la base de données peut se produire.

• Chaque objet blob peut avoir une taille maximale de 1 To. Cela crée une limite supérieure sur les données de base de données individuelles et les fichiers journaux qui peuvent être stockés dans stockage Azure.

• Il n’est pas possible de stocker les données OLTP In-Memory dans l’objet Blob Azure à l’aide de la fonctionnalité SQL Server Data Files dans Stockage Azure. Cela est dû au fait que In-Memory OLTP a une dépendance sur FileStream, et dans la version actuelle de cette fonctionnalité, le stockage des données FileStream dans le stockage Azure 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.

• AlwaysOn Availability Groups sont pris en charge tant que vous n’ajoutez pas de nouveaux fichiers de base de données à la base de données primaire. Si une opération de base de données nécessite la création d’un fichier dans la base de données primaire, désactivez d’abord les groupes de disponibilité AlwaysOn dans le nœud secondaire. Ensuite, effectuez l’opération de base de données sur la base de données primaire et sauvegardez la base de données dans le nœud principal. Ensuite, restaurez la base de données sur le nœud secondaire et activez les groupes de disponibilité AlwaysOn dans le nœud secondaire. Notez que les instances de cluster de basculement AlwaysOn ne sont pas prises en charge lors de l’utilisation des fichiers de données SQL Server dans Azure.

• 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 se bloque et qu’une autre instance de SQL Server configurée pour utiliser les mêmes objets blob est démarrée, la nouvelle instance attend jusqu’à 60 secondes pour que le bail existant sur l’objet blob expire. Si vous souhaitez attacher la base de données à une autre instance et que vous ne pouvez pas attendre que le bail expire dans les 60 secondes, vous pouvez interrompre explicitement le bail sur le Blob afin d’éviter toute défaillance des opérations d’attachement.

Support de référence pour les outils et la programmation

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

Prise en charge dans PowerShell

Dans SQL Server 2014, vous pouvez utiliser des applets de commande PowerShell pour stocker des fichiers de données SQL Server dans le service Stockage Blob Azure en référençant un chemin d’URL de stockage Blob au lieu d’un chemin d’accès de fichier. Vous pouvez accéder aux objets blob au format: http://storageaccount.blob.core.windows.net/<container>/<blob> d’URL suivant.

Support des compteurs d'objets et de performance de SQL Server

À compter de SQL Server 2014, un nouvel objet SQL Server a été ajouté pour être utilisé avec les fichiers de données SQL Server dans la fonctionnalité Stockage Azure. Le nouvel objet SQL Server est appelé SQL Server, HTTP_STORAGE_OBJECT et il peut être utilisé par System Monitor pour surveiller l’activité lors de l’exécution de SQL Server avec 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, vous pouvez taper le chemin d’URL du conteneur de stockage, tel qu’un https://teststorageaccnt.blob.core.windows.net/testcontainer/chemin d’accès dans plusieurs fenêtres de dialogue, telles que nouvelle base de données, attacher une base de données et restaurer une base de données. Pour plus d’informations, consultez Tutoriel : Fichiers de données SQL Server dans le service Stockage Azure.

Prise en charge des objets d’administration SQL Server

Lorsque vous utilisez la fonctionnalité SQL Server Data Files 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 au lieu 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.

support Transact-SQL

Cette nouvelle fonctionnalité a introduit la modification suivante dans la zone de surface d'Transact-SQL :

• Nouvelle colonne int , credential_id, dans la vue système sys.master_files . La colonne credential_id est utilisée pour que les fichiers de données activés pour le stockage Azure puissent être référencés à nouveau vers sys.credentials pour les informations d’identification créées. Vous pouvez l’utiliser pour résoudre les problèmes, comme les informations d’identification ne peuvent pas être supprimées lorsqu’il existe un fichier de base de données qui l’utilise.

Résolution des problèmes liés aux fichiers de données SQL Server dans Azure

Pour éviter les erreurs en raison de fonctionnalités ou de limitations non prises en charge, passez d’abord en revue les limitations.

La liste des erreurs que vous pouvez obtenir lors de l’utilisation des fichiers de données SQL Server dans la fonctionnalité Stockage Azure est la suivante.

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 : cette erreur peut s’afficher lorsque vous essayez de supprimer des informations d’identification qui sont toujours utilisées par un fichier de base de données actif dans stockage Azure. Pour supprimer les informations d’identification, vous devez d’abord supprimer l’objet blob associé qui contient ce fichier de base de données. Pour supprimer un objet blob disposant d’un bail actif, vous devez d’abord rompre 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 : Fichiers de données SQL Server dans le service Stockage Azure.

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

Erreurs d’objet blob de bail :

• Erreur lors de la tentative de démarrage de SQL Server après qu'une autre instance utilisant les mêmes fichiers blob est tombée en panne. 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 se bloque et qu’une autre instance de SQL Server configurée pour utiliser les mêmes objets blob est démarrée, la nouvelle instance attend jusqu’à 60 secondes pour que le bail existant sur l’objet blob expire. Si vous souhaitez attacher la base de données à une autre instance et que vous ne pouvez pas attendre que le bail expire dans les 60 secondes, vous pouvez interrompre explicitement le bail sur le Blob afin d’éviter toute défaillance des opérations d’attachement.

Erreurs de base de données

1. Erreurs lors de la création d’une base de données
   Résolution : passez en revue les instructions fournies dans la leçon 4 du tutoriel : Fichiers de données SQL Server dans le service Stockage Azure.

2. 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. Lorsque vous copiez les fichiers de données vers le stockage Azure, créez toujours un objet blob de pages et non un objet blob de blocs. Sinon, ALTER Database échoue. Passez en revue les instructions fournies dans la leçon 7 du didacticiel : Fichiers de données SQL Server dans le service Stockage Azure.

3. Code d’erreur 5120 Impossible d’ouvrir le fichier physique «%.*ls ». Erreur du système d’exploitation %d: «%ls»
   Résolution : Actuellement, cette nouvelle amélioration ne prend pas en charge plusieurs instances SQL Server accédant aux mêmes fichiers de base de données dans stockage Azure en même temps. Si ServerA est en ligne avec un fichier de base de données actif et si ServerB est démarré accidentellement et qu’il a également une base de données qui pointe vers le même fichier de données, le deuxième serveur ne démarre pas la base de données avec un code d’erreur 5120 Impossible d’ouvrir le fichier physique «%.*ls ». Erreur du système d’exploitation %d: «%ls».

   Pour résoudre ce problème, commencez par déterminer si vous avez besoin de ServerA pour accéder au fichier de base de données dans stockage Azure ou non. Si ce n’est pas le cas, supprimez simplement une connexion entre ServerA et les fichiers de base de données dans Stockage Azure. Pour ce faire, procédez comme suit :

   1. Définissez le chemin du fichier du serveur A sur un dossier local à l’aide de l’instruction ALTER Database.

   2. Définissez la base de données hors connexion dans le serveur A.

   3. Ensuite, copiez les fichiers de base de données à partir du stockage Azure vers le dossier local du serveur A. Cela garantit que ServerA dispose toujours d’une copie de la base de données localement.

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

Voir aussi

Tutoriel : Fichiers de données SQL Server dans le service Stockage Azure