Fichiers de données SQL Server dans Azure

Article
06/13/2017

SQL Server Data Files dans Azure active la prise en charge native de SQL Server fichiers de base de données stockés en tant qu’objets blob Azure. Il vous permet de créer une base de données dans SQL Server s’exécutant en local ou sur une machine virtuelle dans Azure avec un emplacement de stockage dédié pour vos données dans Stockage Blob Azure. Cette amélioration simplifie en particulier le déplacement des bases de données entre les ordinateurs, grâce aux opérations par attachement et détachement. 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, 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é.

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

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

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

intégration SQL Server à Stockage Azure

Avantages de l’utilisation de SQL Server Data Files dans 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 et 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 devez configurer rapidement des centres de calcul situés dans des emplacements géographiquement dispersés, qui rassemblent des données de nombreuses sources différentes. Grâce à cette nouvelle amélioration, au lieu de déplacer des données d’un emplacement à 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 de stockage sans limite et de coût : 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 la surcharge de 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.
Avantages de la haute disponibilité et de la récupération d’urgence : L’utilisation de SQL Server fonctionnalité 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 un instance de SQL Server se bloque, vous pouvez recréer vos bases de données dans une nouvelle machine en rétablissant simplement des liens vers des objets blob Azure.
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 où le déchiffrement ne concerne que l'instance de calcul, mais pas l'instance de stockage. En d’autres termes, grâce à 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 sur votre ordinateur physiquement sécurisé et sauvegardée localement. Vous pouvez utiliser ces clés locales pour chiffrer les données, qui résident dans stockage Azure. 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.

Concepts et configuration requise

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 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 ne dépasse pas 500 To. 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 blob. Tous les objets blob doivent figurer dans un conteneur. Un compte peut contenir un nombre illimité de conteneurs. De la même manière, un conteneur peut également 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 nouvelle fonctionnalité utilise des objets blob de pages, dont la taille peut atteindre jusqu'à 1 To, et qui sont plus efficaces lorsque les plages d'octets d'un fichier sont modifiées fréquemment. Vous pouvez accéder aux objets blob avec le format d'URL suivant : http://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. En outre, l’implémentation de la fonctionnalité Fichiers de données SQL Server dans le stockage Azure nécessite un renouvellement implicite 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). Selon nos évaluations, le coût de renouvellement des baux pour deux fichiers de base de données (.mdf et .ldf) se monte à environ 2 cents par mois d'après la grille de tarification actuelle. Nous vous recommandons de consulter les informations de la page Azure Pricing (Tarifs d’Azure) pour vous aider à estimer les coûts mensuels associés à l’utilisation du stockage Azure et des machines virtuelles Azure.

Concepts de serveur SQL

Si vous utilisez cette nouvelle amélioration, assurez-vous de procéder comme suit :

Créez une stratégie sur un conteneur et générez également une clé de signature d'accès partagé (SAS).
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 d'accès du conteneur.
Stockez les informations relatives au conteneur de stockage Azure, le nom de stratégie associé et la clé SAS dans la banque d’informations d’identification de SQL Server.

L’exemple suivant part du principe qu’un conteneur stockage Azure a été créé et qu’une stratégie a été créée avec des droits de lecture, d’écriture, de liste et de liste. La création d'une stratégie sur un conteneur génère une clé SAS qui peut rester non chiffrée en mémoire et qui est requise par SQL Server pour accéder aux fichiers d'objet blob dans le 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')

Important

s’il existe des références actives aux fichiers de données dans un conteneur, toutes les tentatives de suppression des informations d’identification SQL Server correspondantes échouent.

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.

Lorsque vous créez un conteneur pour le service de stockage d’objets 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.

Configuration requise pour l'installation

Voici les conditions préalables à l’installation lors du stockage de SQL Server Data Files dans Azuree.

SQL Server local : SQL Server 2014 comprend cette fonctionnalité. Pour savoir comment télécharger SQL Server 2014, consultez SQL Server 2014.
SQL Server s'exécutant sur un ordinateur virtuel Azure : si vous installez SQL Server sur un ordinateur virtuel 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 SQL Server image de plateforme 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 de Stockage Azure, mais vous ne pouvez pas déplacer de données Filestream entre des machines à l’aide du Stockage Azure. Pour les données FileStream, nous vous recommandons de continuer à utiliser les méthodes traditionnelles pour déplacer des fichiers (.mdf, .ldf) associés à Filestream entre différents ordinateurs.
Actuellement, cette nouvelle amélioration ne prend pas en charge l’accès simultané de plusieurs instances SQL Server aux mêmes fichiers de base de données dans le Stockage Azure. 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 parvient pas à démarrer la base de données avec le 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 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.
La taille d'un objet blob peut atteindre 1 To au maximum. Cette limite supérieure s’applique à chaque fichier journal ou fichier de données de base de données pouvant être enregistré dans le stockage Azure.
Il est impossible d’enregistrer des données de l’OLTP en mémoire dans un objet blob Azure à l’aide de la fonctionnalité Fichiers de données SQL Server dans le stockage Azure. En effet, In-Memory OLTP a une dépendance sur FileStream et, dans la version actuelle de cette fonctionnalité, le stockage de FileStream données dans stockage Azure n’est pas pris en charge.
Lorsque vous utilisez SQL Server fonctionnalité Fichiers de données dans Azure, SQL Server effectue toutes les comparaisons d’URL ou de chemins de fichier à l’aide du jeu Classement dans la master base de données.
Les 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 nouveau fichier dans la base de données primaire, désactivez d'abord les groupes de disponibilité AlwaysOn dans le nœud secondaire. Puis, effectuez l'opération de base de données dans 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, puis 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 de la fonctionnalité SQL Server Data Files dans Azure.
En mode de fonctionnement normal, SQL Server utilise des baux temporaires pour réserver des objets blob pour le stockage, avec un renouvellement du bail de chaque objet blob toutes les 45 à 60 secondes. En cas de défaillance d'un serveur et du démarrage d'une autre instance de SQL Server configurée pour utiliser les mêmes objets blob, la nouvelle instance attend jusqu'à 60 secondes, le temps que le bail existant sur l'objet blob expire. Si vous voulez attacher la base de données à une autre instance et que vous ne pouvez pas attendre l'expiration du bail pendant 60 secondes, vous pouvez résilier explicitement le bail sur l'objet blob afin d'éviter les erreurs dans les opérations d'attachement.

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 de PowerShell

Dans SQL Server 2014, vous pouvez utiliser des applets de commande PowerShell pour stocker SQL Server fichiers de données dans Stockage Blob Azure service en référençant un chemin d’URL de stockage Blob plutôt qu’un chemin d’accès de fichier. Vous pouvez accéder aux objets blob avec le format d'URL suivant :: http://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, vous pouvez taper le chemin d'accès de l'URL du conteneur de stockage, tel que https://teststorageaccnt.blob.core.windows.net/testcontainer/ sous la forme d'un Chemin d'accès dans plusieurs fenêtres de dialogue, telles que Nouvelle base de données, Attacher la base de donnéesou Restaurer la base de données. Pour plus d’informations, consultez Tutoriel : SQL Server Fichiers de données dans le service Stockage Azure.

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 SQL Server Management Objects (SMO), consultez SQL Server Guide de programmation SMO (SQL Server Management Objects) dans SQL Server documentation en ligne.

Prise en charge de Transact-SQL

Cette nouvelle fonctionnalité a apporté le changement suivant dans la surface d'exposition de Transact-SQL :

Une nouvelle colonne int , credential_id, dans la vue système sys.master_files . La colonne credential_id permet aux fichiers de données prenant en charge le Stockage Microsoft Azure d'être référencés dans sys.credentials concernant les informations d'identification créées à leur intention. Vous pouvez l'utiliser pour le dépannage, par exemple dans le cas où des informations d'identification ne peuvent pas être supprimées parce qu'elles sont utilisées par un fichier de base de données.

Résolution des problèmes liés aux fichiers de données SQL Server dans 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 : Cette erreur peut s’afficher lorsque vous tentez de supprimer des informations d’identification 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 résilier 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 : SQL Server Fichiers de données dans le service Stockage Azure.
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 : SQL Server Fichiers de données dans le service Stockage Azure.

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 : en mode de fonctionnement normal, SQL Server utilise des baux temporaires pour réserver des objets blob pour le stockage, avec un renouvellement du bail de chaque objet blob toutes les 45 à 60 secondes. En cas de défaillance d'un serveur et du démarrage d'une autre instance de SQL Server configurée pour utiliser les mêmes objets blob, la nouvelle instance attend jusqu'à 60 secondes, le temps que le bail existant sur l'objet blob expire. Si vous voulez attacher la base de données à une autre instance et que vous ne pouvez pas attendre l'expiration du bail pendant 60 secondes, vous pouvez résilier explicitement le bail sur l'objet blob afin d'éviter les erreurs dans les opérations d'attachement.

Erreurs de base de données

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 : SQL Server Fichiers de données dans le service Stockage Azure.
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 : SQL Server Fichiers de données dans le service Stockage Azure.
Code d'erreur 5120 Impossible d'ouvrir le fichier physique « %.*ls ». Erreur %d du système d'exploitation : « %ls »
Résolution : Actuellement, cette nouvelle amélioration ne prend pas en charge l’accès simultané de plusieurs instances SQL Server aux mêmes fichiers de base de données dans le Stockage Azure. 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 parvient pas à démarrer la base de données avec le 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, 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. Si vous n’en avez pas besoin, supprimez simplement toute connexion entre le serveur A et les fichiers de base de données dans le stockage Azure. Pour ce faire, procédez comme suit :
1. Définissez le chemin d'accès du serveur A sur un dossier local à l'aide de l'instruction ALTER Database.
2. Mettez la base de données hors connexion sur le serveur A.
3. Puis, copiez les fichiers de base de données du stockage Azure dans le dossier local du serveur A. Cela garantit que le serveur A dispose toujours d’une copie de la base de données localement.
4. Mettez la base de données en ligne.

Voir aussi

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

Partager via