Partager via

Connect() ; Spécial problème 2018

Volume 33, numéro 13

Base de données SQL Azure - présentation de très grande échelle de la base de données SQL Azure

Par Kevin Farlee ; Spécial problème 2018

Lors de la conférence Ignite, nous avons annoncé la préversion publique de Hyperscale de base de données SQL Azure, une nouvelle architecture de stockage en fournissant une SQL et le niveau de service hautement évolutif pour les bases de données qui s’adapte à la demande pour les besoins de votre charge de travail. Avec une très grande échelle de la base de données Azure SQL, bases de données peuvent rapidement à l’échelle automatique jusqu'à 100 To, éliminant la nécessité de préconfigurer des ressources de stockage et l’étendre de manière significative le potentiel de croissance de l’application sans limitation de taille de stockage.

Par rapport aux niveaux de service de base de données SQL Azure en cours, Hyperscale de base de données SQL Azure fournit les fonctionnalités supplémentaires suivantes :

  • Prise en charge de la taille de base de données de 100 To +
  • La mise à l’échelle rapide haut/bas et restauration de point-à-temps, indépendamment de la taille de la base de données
  • Moins d’opérations de données de taille
  • Débit de journal plus élevé que les niveaux de service en cours
  • Montée en puissance en lecture seule charge de travail avec des réplicas en lecture à l’échelle sans copie des données

Nouvelle architecture

Très grande échelle de base de données SQL Azure est un remaniement fondamentales du moteur de stockage au sein de la base de données SQL qui a été effectuée sans apporter de modifications dans le moteur de requête qui traite les requêtes et détermine les comportements. Par conséquent, nous avons ajouté de nouvelles possibilités significatives sans introduire des problèmes de compatibilité entre.

L’architecture Hyperscale de base de données SQL Azure s’arrête le moteur SQL monolithique en plusieurs microservices conçus pour l’environnement de cloud. Ces services découpler le calcul, de journal et de stockage.

Comme indiqué dans Figure 1, le modèle Hyperscale de base de données SQL Azure comprend trois composants principaux :

  • Calcul est le moteur de requête à partir de SQL Server, la partie du moteur de base de données qui exécute la logique de requête et lorsque la requête est évaluée pour déterminer la compatibilité avec d’autres implémentations de SQL, ainsi que les comportements.
  • Page serveurs est une nouvelle architecture de montée en puissance pour stocker les données qui prend le composant du moteur de stockage traditionnel et le divise en un ensemble de montée en puissance des services, chacun d’eux gère un ensemble défini de pages de données (nominalement pour un total de pages de données de 1 To).
  • Ouvrir une session Service est une nouvelle architecture de journalisation qui gère le flux de données pour les données de journal, en garantissant que les mises à jour connectés aux données obtient propagées vers tous les réplicas d’une page modifiée et rendues persistantes durablement pour des besoins futurs.

La nouvelle Architecture de très grande échelle de base de données SQL Azure
Figure 1 la nouvelle Architecture de très grande échelle de base de données SQL Azure

Nœuds de calcul

Les nœuds de calcul rechercher comme traditionnelles de SQL Server, mais sans les fichiers de données locaux ou des fichiers journaux. Nœuds de calcul sont « server » qui applications et les utilisateurs interagissent avec, si des nœuds de calcul de la mise à jour les données (via le nœud de calcul principal) ou pour effectuer des transactions strictement en lecture seule via une de la base de données secondaire accessible en lecture.

Le nœud de calcul principal écrit les enregistrements du journal des transactions dans la Zone d’accueil du service de journal et extrait les pages de données à partir de serveurs de la page si elles ne sont pas trouvées dans le cache de données local ou d’une Extension de Pool résilientes mémoire tampon (RBPEX). Il s’agit où toute la logique d’exécution de requête se trouve, et que la logique est inchangée depuis d’autres modes de déploiement SQL. En conservant cette couche supérieure du moteur SQL en grande partie inchangés, vous pouvez maintenir une compatibilité totale avec les autres modes de déploiement de SQL tout en vous fournissant les nouvelles fonctionnalités révolutionnaires qu'offrent les composants de stockage distinct. Étant donné que nous avons réparti les nœuds de calcul qui contient le moteur de requête à partir du stockage, ils sont effectivement sans état, ce qui signifie que vous risquez de perdre un nœud de calcul sans mettre en danger les données du tout. Cela signifie également que vous pouvez monter en puissance les ressources de calcul, ou vers le bas sans déplacer toutes les données, qui fournit l’agilité inégalée pour les adaptant ressources à seront.

J’aborderai plus tard plus de fonctionnalités de haute disponibilité (HA).

Service de journalisation

Le service de journal externalise le journal des transactions d’une base de données de très grande échelle. L’instance de calcul principal écrit les enregistrements du journal directement dans le stockage Premium Azure géré par le service de journal (la « Zone d’accueil » dans Figure 1). Le service de journal récupère les enregistrements de journal à partir de la zone d’accueil et rend disponible pour les serveurs de la page et le calcul secondaire. Le service de journal décharge également des enregistrements de journal vers le stockage à long terme plus chères pour prendre en charge la restauration de point-à-temps.

Étant donné que la zone de destination est un stockage Premium Azure, qui propose la résilience et haute disponibilité intégrée, enregistrements de journal sont persistants et sécurisés dès qu’ils sont écrits dans la zone de destination. Avec le comparables AlwaysOn disponibilité groupes à haute disponibilité architecture pour local SQL Server, une validation de transaction doit être envoyé à un quorum de réplicas secondaires via le protocole réseau et un accusé de réception reçue de quorum de réplicas avant le transaction permettre être considérés comme terminée et la réussite est retourné à l’application appelante. Cela peut prendre une période beaucoup plue de temps qu’avec l’architecture de très grande échelle. Vous pouvez avoir à haute disponibilité complète sans attendre que les nœuds secondaires à accuser réception des enregistrements de journal. Cela signifie que même avec haute disponibilité complète, vous disposez des latences de journal de bout en bout dans les 2 MS plage. Lorsque la technologie de stockage SSD Ultra Azure devient disponible, cette latence est réduit à partir de 2.5ms à autour 0.4ms pour stocker des données à distance, entièrement durables et résilientes.

Enfin, les enregistrements de journal sont conservés dans le stockage Azure Standard pour le stockage à long terme, et l’espace dans la zone de destination est récupéré. Les enregistrements de journal dans le stockage Azure sont conservées tant que la période de rétention de sauvegarde configurée pour la base de données, par conséquent, il est inutile d’effectuer des sauvegardes de fichier journal. Vous gardez simplement les données de journal en ligne, ce qui vous donne en effet un journal des transactions infinie (dans les limites de la période de rétention de sauvegarde configurés par l’utilisateur).

Serveurs de la page

Les serveurs de la page hébergent et gérer les fichiers de données. Ils consomment le flux du journal du service de journalisation et appliquent les modifications de données décrites dans le flux de journal pour les fichiers de données. Demandes de lecture de pages de données qui ne se trouvent dans le cache de données local ou de RBPEX les ressources de calcul sont transférés vers les serveurs de page qui possèdent les pages concernées. Dans les serveurs de la page, les fichiers de données sont conservés dans le stockage Azure et sont largement mises en cache via leurs propres caches basée sur des disques SSD de RBPEX.

Chaque serveur de pages gère les pages qui représente environ 1 To de données, pour les serveurs de page sont mis à l’échelle horizontalement en unités d’environ 1 To. Le moteur de nœuds de calcul/requête modélise chaque serveur de pages dans un 1 To de données de fichiers, à partir de l’ID de page (ID de fichier : Page dans le fichier), vous savez exactement quel serveur de la page héberge la page demandée.

Les données pour chaque serveur de la page sont finalement conservées dans le stockage Azure Standard, qui fournit la disponibilité et la résilience complète.  Par conséquent, vous pouvez survivre à la perte d’un serveur de la page entière sans risquer de perdre de données, comme les données sont entièrement disponibles à partir du stockage Azure, et vous pouvez reconstruire entièrement le serveur de la page à partir de ces données si nécessaire.

Les données pour chaque serveur de la page sont entièrement mis en cache dans son propre cache SSD RBPEX, donc dans l’opération, aucune requête de données n’est redirigée vers le stockage Azure, le serveur de la page, la sauvegarde, car il peut toujours être satisfaite dans le cache local de RBPEX.

Plusieurs serveurs de la page seront créés pour une base de données volumineux. Lorsque la croissance de la base de données et l’espace disponible dans les serveurs de page existants est inférieur à un seuil, un nouveau serveur de la page est automatiquement ajouté à la base de données. Étant donné que les serveurs de la page travaillez de manière indépendante, vous pouvez développer la base de données sans aucune contrainte de ressource locale.

Haute disponibilité et récupération d’urgence (DR)

Sauvegarde et restauration de Point-à-temps automatisées dans une base de données de très grande échelle, des captures instantanées des fichiers de données sont effectuées à partir des serveurs de page, en tirant parti des capacités de stockage d’objets blob Azure périodiquement pour remplacer la diffusion en continu traditionnelle sauvegarde. Cela vous permet de sauvegarder les bases de données très volumineuses en seulement quelques secondes sans aucun impact à la charge de travail en cours d’exécution. Avec les enregistrements de journal stockées dans le service de journal, vous pouvez restaurer la base de données à n’importe quel point dans le temps au cours de la rétention, qui est de sept jours en version préliminaire publique et sera configurable jusqu'à 35 jours à disponibilité générale (GA), dans une durée très courte , quelle que soit la taille de la base de données. Données du serveur de chaque page sont convertis en instantanés indépendamment, sans avoir à synchroniser les captures instantanées, donc cette source potentielle de délai est éliminée, ainsi.

Hautement disponible composants chacun des composants dans l’architecture Hyperscale de base de données SQL Azure est conçu pour être hautement disponible afin qu’il n’y aura aucune interruption dans l’accès de base de données :

  • Nœuds de calcul chacun avoir au moins un réplica en cours d’exécution et à chaud à tout moment. En cas de défaillance de nœud de calcul ou le basculement, le réplica prendrait immédiatement sur le rôle principal, en conservant la base de données en ligne et disponible. Une réplique de remplacement peut être démarrée très rapidement et peut préparer ses mémoires cache comme une tâche en arrière-plan sans affecter les performances de production. Autres réplicas peuvent être configurés pour la lecture à des fins de montée en puissance. Avec cette architecture, les nœuds de calcul sont effectivement sans état.
  • Serveurs de la page chaque présentent un réplica en attente en ligne de leur cache RBPEX entièrement remplie, donc ils sont disponibles pour le serveur de la page active en cas de défaillance. Là encore, car ils sont sans état en dehors des données mises en cache, un remplacement peut être en ligne très rapidement, sans risque de perte de données.
  • Le service de journal n’a pas un serveur de secours, mais cela n’est pas nécessaire que le service de journal ne comporte aucune donnée mise en cache et peut être remplacé plus vite vous pouvez basculer vers un réplica en attente. Les données qui sont gérées par le service de journal résident tout d’abord dans la zone d’accueil, qui est le stockage Premium résilientes Azure (bientôt un stockage SSD Ultra) et est finalement rendu persistant dans le stockage Azure Standard pour la rétention à long terme.

Par conséquent, comme vous pouvez le voir, il n’existe aucun composant qui représente un point de défaillance unique. Tous les composants de très grande échelle ont mises en veille actives, à l’exception du service de journal, et toutes les données est sauvegardée par le stockage Azure complètement résilient.

Création de votre propre base de données de très grande échelle

Vous pouvez créer une nouvelle base de données de très grande échelle de la même manière que vous créez n’importe quel autre Azure SQL Database, à un portail Microsoft Azure, PowerShell ou Azure Resource Manager (ARM).

Ici, vous expliquerai la méthode pour créer une base de données de très grande échelle à l’aide de PowerShell. Notez que cela vaut à partir du script standard pour la création d’une base de données Azure SQL à l’exception du paramètre - RequestedServiceObjectiveName. Dans l’exemple qui suit, je vais utiliser HS_Gen5_8, qui est une base de données SQL de très grande échelle, sur du matériel de génération 5, avec huit cœurs. Bien sûr, si vous avez déjà un groupe de ressources et un serveur logique, vous pouvez ignorer ces parties du script.

La première chose que vous devez effectuer consiste à lancer Azure Cloud Shell. Cloud Shell est un interpréteur de commandes gratuite et interactive que vous pouvez utiliser pour exécuter les étapes mentionnées dans cet article. Il possède des outils Azure courants préinstallés et configurés pour utiliser avec votre compte. Vous pouvez simplement cliquer sur le bouton Copier pour copier le code, puis collez le code dans l’interpréteur de commandes et appuyez sur ENTRÉE pour l’exécuter.

Il existe plusieurs façons de lancer Cloud Shell. Parmi le sont le plus simple pour l’ouvrir Cloud Shell dans votre navigateur en accédant à shell.azure.com/powershell et cliquez sur lancer Cloud Shell bouton, ou en cliquant sur le Cloud Shell situé dans le menu dans le coin supérieur droit du portail Azure. Je vous recommandons de qu'utiliser la seconde méthode. Connectez-vous au portail Azure à portal.azure.com en utilisant le compte qui a accès à votre abonnement Azure. Puis cliquez sur le lien, comme indiqué dans Figure 2.

Lancer Cloud Shell à partir du portail Azure
Figure 2 lancer Cloud Shell à partir du portail Azure

Vous pouvez ensuite coller le script indiqué dans Figure 3 dans la fenêtre Cloud Shell et exécutez-le pour créer un groupe de ressources, un serveur logique SQL et une base de données. Notez que le nom de groupe de ressources est défini sur « myResourceGroup- » et un nombre aléatoire, par exemple « MyResourceGroup-2088327474. » Autres objets sont nommés de la même façon. Toutefois, vous pouvez personnaliser ces noms s’il est plus pratique.

Figure 3 Création d’un groupe de ressources, le serveur logique SQL et la base de données

# Set the resource group name and location for your server
$resourcegroupname = "myResourceGroup-$(Get-Random)"
$location = "westus2"
# Set an admin login and password for your server
$adminlogin = "ServerAdmin"
$password = "ChangeYourAdminPassword1"
# Set server name - the logical server name has to be unique in the system
$servername = "server-$(Get-Random)"
# The sample database name
$databasename = "mySampleDatabase"
# The IP address range that you want to allow to access your server
$startip = "0.0.0.0"
$endip = "0.0.0.0"
# Create a resource group
$resourcegroup = New-AzureRmResourceGroup -Name $resourcegroupname -Location $location
# Create a server with a system-wide unique server name
$server = New-AzureRmSqlServer -ResourceGroupName $resourcegroupname `
  -ServerName $servername `
  -Location $location `
  -SqlAdministratorCredentials $(New-Object -TypeName
    System.Management.Automation.PSCredential -ArgumentList $adminlogin,
    $(ConvertTo-SecureString -String $password -AsPlainText -Force))
# Create a server firewall rule that allows access from the specified IP range
$serverfirewallrule = New-AzureRmSqlServerFirewallRule
  -ResourceGroupName $resourcegroupname `
    -ServerName $servername `
    -FirewallRuleName "AllowedIPs" -StartIpAddress $startip -EndIpAddress $endip
# Create a blank database with the Hyperscale, Gen5, two-core performance level
$database = New-AzureRmSqlDatabase  -ResourceGroupName $resourcegroupname `
  -ServerName $servername `
  -DatabaseName $databasename `
  -RequestedServiceObjectiveName "HS_Gen5_2" `
  -SampleName "AdventureWorksLT"
Echo $servername
# Clean up deployment
# Remove-AzureRmResourceGroup -ResourceGroupName $resourcegroupname

Dans le script, le serveur est créé dans la région WestUS2. À ce stade, très grande échelle n’est pas disponible dans toutes les régions Azure, afin de conserver dans WestUS2, qui est active, ou essayez une autre région. Si vous recevez une erreur que le « Specified edition n’est pas disponible. Choisissez une autre édition, » cela indique que la région que vous avez choisi n’a pas encore activé Hyperscale. Vous pouvez essayer une autre région, ou utiliser WestUS2.

Un autre objet qui est configuré pour vous est la règle de pare-feu qui accorde l’accès à votre serveur. L’exemple de script définit startip et endip sur 0.0.0.0, ce qui n’autorise pas l’accès. Vous pouvez ajouter l’adresse pour votre ordinateur spécifique en recherche le nouveau serveur dans le portail, en cliquant sur « Afficher les paramètres de pare-feu » puis en cliquant sur « Ajouter adresse IP du client, » qui ajoute une règle de pare-feu autorisant votre ordinateur actuel pour se connecter à la base de données.

Une fois que votre base de données et le serveur sont créés, et les règles de pare-feu sont ajustées, vous pouvez vous connecter à votre base de données à l’aide de SQL Server Management Studio (SSMS). Le script imprime le nom qu'il affecté à SQL Server. Ajoutez simplement «. database.windows.net » au nom du serveur lorsque vous vous connectez. Le nom d’utilisateur et le mot de passe sont contenus dans ce script (bien entendu, vous pouvez et devez les remplacer par quelque chose que vous seul connaissez). À ce stade, vous êtes connecté à votre nouvelle base de données de très grande échelle.

Vous trouverez les autres méthodes de création de bases de données SQL Azure Hyperscale à bit.ly/2QoTLbj.

L’Architecture de base de données nouvelle génération

Avec cette brève présentation, vous avez vu que Hyperscale de base de données SQL Azure est une nouvelle architecture révolutionnaire qui a l’avantage unique de fournir une compatibilité totale avec les précédentes générations de moteurs SQL. Très grande échelle de base de données SQL Azure est véritablement issues du cloud et présente des avantages importants dans la mise à l’échelle, les performances et la facilité de gestion. En éliminant les opérations courantes de taille de données, il est en mesure de fournir des fonctionnalités de base de données très volumineuses (VLDB) sans les défis VLDB. Pour plus d’informations, reportez-vous à la page « Hyperscale Service niveau (version préliminaire) pour jusqu'à 100 To » à bit.ly/2TTJkeK.

Kevin Farleea plus de 30 ans dans l’industrie, dans le logiciel de gestion de base de données et de stockage. Dans son poste actuel en tant que responsable de programme principal de l’équipe Microsoft SQL Database, il est engagé à développer les fonctionnalités Hyperscale VLDB de base de données SQL Azure.

Merci aux experts techniques Microsoft suivants d'avoir relu cet article : Alain Dormehl, Xiaochen Wu
Alain Dormehl est responsable de programme Senior avec l’équipe de la base de données SQL Azure chez Microsoft, basée à Redmond. Il a occupé différents rôles chez Microsoft et travaille actuellement sur le développement de fonctions et de produits pour les bases de données SQL Azure. Il a plus de dix ans d’expérience avec SQL Server et a été un précurseur et un promoteur pour Azure. Vous pouvez le suivre sur Twitter @APSolutely

Xiaochen Wu est responsable de programme senior au sein de team SQL chez Microsoft. Il a travaillé sur plusieurs fonctionnalités et produits dans SQL Server et les bases de données SQL Azure au cours des 10 dernières années. Vous pouvez le suivre sur Twitter @allenwux

Discuter de cet article sur le forum MSDN Magazine

  • Last updated on