Azure Managed instances–Tarification pour des instances de dev/test

Pour ceux qui ne connaissent pas les instances managées, il s’agit ni plus ni moins que l’étape intermédiaire concernant SQL Server entre le IaaS et le PaaS. En IaaS, vous devez gérer votre VM, l’installation et la configuration de SQL Server, les sauvegardes, en bref, tout, comme à la maison, mais dans un cloud Public. Le PaaS vous propose une instance SQL Server totalement gérée par Microsoft. Vous n’avez qu’a créer une base, créer vos objets, gérer votre sécurité, vous connecter et …. c’est tout. Enfin, presque … SQL Azure (en déclinaison single database ou elastic pool) ne vous propose pas l’intégralité des services liés à SQL Server, en premier lieu l’agent SQL. D’où quelques billets traitant du sujet publiés ici.

Il manquait donc une étape intermédiaire, une instance SQL Server totalement gérée. C’est bien de cela dont on parle ici : Azure SQL Database Managed Instance. Certes, ce n’est pas parfait, mais, pour moi, il s’agit d’une offre extrêmement intéressante car le DBA retrouve certaines choses qui lui faisaient défaut (des requêtes multi bases entre autre, un agent SQL, …). Les fonctionnalités proposées sont proches de ce qui est proposé par SQL Server :

Vos habitudes liées à Azure (Scale Up et Scale Down) sont conservées.

La mise à disposition prends plus de temps qu’une VM Azure, ce qui peut se comprendre par l’architecture choisie par Microsoft. Il s’agit de plusieurs VMs pour la partie database, ainsi qu’une VM de gestion sur laquelle on peut utiliser SSMS par exemple car un des freins à la mise en place que j’avais rencontré au moment où l’offre était en phase de test était liée à la “complexité” de connexion, liée au réseau / VNets. Il faudrait que je vois si cela a évolué depuis la GA.

Restait un point délicat à traiter : le pricing.

image

Pas vraiment cheap comme solution en business critical comme vous pouvez le voir. Ce niveau permet cependant de meilleurs performances grâce à des disques locaux SSD à faible latence.

En génération 5 “classique”, on retrouve un niveau tarifaire plus accessible :

image

Quel que soit le mode choisi, sachant que le compute et le stockage sont dé corrélés, il faudra aussi passer à la caisse pour le le stockage:

  • premier 32 GB gratuits
  • 0.232 € /GB en business critical
  • 0.1067€/GB en general purpose

Pour ce prix, l’espace de stockage liée aux sauvegardes (qui sont gérées) est inclus. Par contre, il ne s’agit pas des backup “classiques” SQL Server, ceux que vous pouvez utiliser pour restaurer votre base sur un environnement de test ou de développement.

Restait donc à traiter le problème des instances dédiées au test ou au développement. Rien n’était prévu jusque là pour offrir une option tarifaire descente.

L’offre promet 55% de réduction. J’avoue tout de même que l’interface de calcul n’a pas adapté le prix, que je sélectionne l’option ou non…. On m’informe que le niveau tarifaire a été ajouté, sans pour autant que je le trouve. Hum. No comment.

image

L’information date un peu, certes, mais les fêtes de fin d’années sont passées par là. On allonge la ToDo list, on empile les post-it virtuels Windows 10 qui se synchronisent entre les différents PC utilisés en espérant trouver un moment pour traiter et relayer l’information.

Si vous n’êtes pas découragé par le niveau tarifaire et que vous souhaitez passer en production, n’hésitez pas à me contacter.

Happy MI

Publicités
Publié dans SQL Azure | Tagué | Laisser un commentaire

Planification Azure SQL Databases–Azure RunBook

Pour donner suite à un premier article sur la planification de travaux SQL Server dans Azure, qui utilisait les fonctions Azure, voici à présent une version plus “administrateur système” car à base de PowerShell.

Ceux d’entre vous qui doivent gérer des environnements hétérogènes, ou bien des planifications de travaux complexes faisant intervenir plusieurs systèmes / serveurs ont probablement entendu parler de Microsoft Orchestrator. Il existe bien entendu d’autres produits de ce type sur le marché. L’idée ici, sur Azure, est similaire, certes l’interface graphique glisser / déplacer en moins perfectionnée, il faut l’avouer.

Azure automation peut donc implémenter un workflow base sur du PowerShell. En bon DBA que vous êtes (devriez être), j’espère que vous vous êtes déjà penché sur PowerShell. Cela doit clairement faire partie de votre panoplie de compétences, ne serait ce que pour automatiser le déploiement de SQL Server, sa configuration voire la migration (suivez mon regard vers dbatools.io) ou différents checks de configuration ou santé (dbachecks).

En premier lieu il faut créer un compte de type automation :

image

2018-10-10_20-32-07

2018-10-10_20-36-34

Une fois terminé, un écran vue d’ensemble permet de suivre l’activité des différentes tâches.

2018-10-10_20-37-30

Je vous conseille en premier lieu de stocker de manière indépendante et sécurisée les crédentials pour accéder à votre base de donnée. Je trouve cela particulièrement judicieux et approprié, cela évite de diffuser un mot de passe administrateur et ainsi déléguer à certains personnes le droit de créer des RunBooks sans pour autant leur fournir toutes les informations d’indentifications. Voyez cela comme un couple credential / proxy dans l’agent SQL Server.

Je n’avais pas trouvé dans l’utilisation des fonctions Azure de fonction équivalente et aussi simple à mettre en œuvre. Il suffit d’aller dans le menu Information d’identification et de cliquer “Ajouter …”.

2018-10-10_20-46-19

Un nouvel écran est proposé permettant de saisir un nom d’utilisateur et un mot de passe, ceux là même que vous aurez préalablement ajouté en tant qu’administrateur de votre base de donnée, ou du moins en capacité d’effectuer les tâches de maintenance ou les actions de votre RunBook.

2018-10-10_20-48-58

Reste ensuite à créer le RunBook. Dans le menu adéquat, sélectionner Créer un RunBook.

2018-10-10_20-38-20

2018-10-10_20-51-05

Donnez lui un nom suffisamment explicite, choisissez en suite votre langage de prédilection, PowerShell dans mon cas.

2018-10-10_20-52-24

Le RunBook a présent créé, il suffit de cliquer sur Edition.

2018-10-10_20-53-05

Et saisir le code Powershell. Notez au passage la syntaxe Get-AutomationPSCredential pour lire les valeurs et ensuite leur utilisation dans le SQLCMD.


$AzureSQLDatabaseName = "AdventureWorks"
$AzureSQLServerName = "sqlagent.database.windows.net"
$Cred = Get-AutomationPSCredential -Name "MaintenanceUser"

$SQLOutput = $(Invoke-Sqlcmd -ServerInstance $AzureSQLServerName `
                             -Username $Cred.UserName -Password $Cred.GetNetworkCredential().Password `
                             -Database $AzureSQLDatabaseName `
                             -Query "exec [dbo].[IndexOptimize] @Databases ='$AzureSQLDatabaseName'" `
                             -QueryTimeout 65535 -ConnectionTimeout 60 -Verbose) 4>&1
 
Write-Output $SQLOutput

2018-10-10_20-59-26

Si vous êtes impatients, il y a de fortes chances que vous cliquiez sur Test. Malheureusement, vous avez de grandes chance de tomber sur une erreur de type commande non reconnue.

2018-10-10_21-01-44

En fait il manque simplement l’ajout d’une dépendance, l’équivalent d’un import module en quelques sortes.

Rendez vous dans le menu Modules, dans lequel on va simplement rechercher sqlserver dans la galerie

2018-10-10_21-06-35

2018-10-10_21-07-11

Vous sélectionnez et cliquez sur Importer

2018-10-10_21-07-38

Wait …. Et une fois terminé, on peut relancer le test.

2018-10-10_21-08-12

Celui ci devrait parfaitement se dérouler à présent, sauf s’il subsiste des erreurs de login ou autre.

image

Lorsque l’on revient sur la vue d’ensemble, il est possible de sélectionner une exécution et d’en voir la sortie :

2018-10-10_21-16-42

2018-10-10_21-12-17

2018-10-10_21-14-53

Reste à présent à planifier ce RunBook :

2018-10-10_21-17-10

2018-10-10_21-17-51

2018-10-10_21-25-27

Rien de plus à faire, le “Job” va s’exécuter automatiquement suivant votre planification.

Happy scheduling

Publié dans Azure Runbook, SQL Azure | Tagué , | 1 commentaire

SQL Server 2008 et SQL Server 2008R2 – fin de support étendu

Pour un logiciel, il y a des dates qui comptent …

Autant les premières préversions sont attendues avec impatience, autant l’annonce de la RTM permet de planifier des projets et la General Availability de lancer les mises en production, autant la fin de support est redoutées … Le 9 juillet 2019 marque la fin du support étendu pour SQL Server 2008 et SQL Server 2008 R2.

Pas de panique, votre base de données ne va pas s’arrêter de fonctionner. Rien ne va changer … tant que vous n’avez pas à faire appel au support. C’est là que tout pourrait se compliquer.

Quoi qu’il en soit, je vous conseille tout de même d’envisager une migration si vous êtes concernés.

La première question qui se pose forcément tient à la compatibilité. Pour faire simple, on ne devrait pas certifier un produit ou un logiciel sur une version de SQL Server mais plutôt, si c’est un impératif, certifier sur un niveau de compatibilité. Cela permet de rester à jour au niveau des binaires de SQL Server.

Historiquement limité aux versions N-1 et N-2, les niveaux de compatibilité remontent à présent … à SQL Server 2008 ! Quelle que soit la version de SQL Server, 2019 y compris !

image

Aucune raison donc de redouter une migration.

D’autant plus que vous bénéficierez des dernières fonctionnalités liées à SQL Server, et depuis SQL 2008(R2) elles sont légions :

Et c’est sans compter sur les Big Data Clusters annoncés pour SQL Server 2019 qui vont permettre d’installer dans un même POD (linux Kubernetes) à la fois un moteur relationnel et un moteur Spark pour les données structurées et non structurées, tout cela en lien avec Polybase.

image

 

Bref, la liste est suffisamment longue pour que j’en oublie forcément. Quitte à migrer, autant éviter les versions 2012 et 2014 et passer directement à SQL Server 2017 ce que je vous souhaite. Pour plus de détail :

Il est donc temps de préparer une migration. N’hésitez pas à vous faire accompagner au moins sur les phases de préparation de votre nouvelle infrastructure, de choix de la plateforme cible (Azure, OnPrem, Hybride), de la méthode de migration, …

Pensez également à la formation, autant des administrateurs que des développeurs. J’ai élaboré des plans de cours sur des sujets spécifiques sur une durée réduite, ce qui permet de ne pas s’éloigner trop longtemps de la production.

Winter is coming for SQL 2008/R2…, need help ?

Happy migration !

Publié dans SQL Server | Tagué , , | Laisser un commentaire

Test d’IOPS dans une VM Microsoft Azure

Après avoir testé les IOPS sur des VMs Amazon EC2, le billet d’aujourd’hui tend à créer un parallèle sur l’environnement Azure. Et, finalement, ce n’est pas si simple que cela de reproduire des tests à l‘identique. Le modèle Amazon est sérieusement amélioré par la présence du bucket d’IOs disponible en mode burst. Normalement, un disque standard GP2 a une capacité de 3 IOPS/GB. Mais en ajoutant l’effet burst IO disponible pour des volumes inférieurs à 1 TB, on dispose pour une période donnée de 3000 IOPS, quelle que soit la volumétrie du disque. Intéressant lorsque l’on maitrise son workload et que celui ci ne consomme pas 100% du temps ces 3000 IOPS. Cela permet de faire de sérieuses économies sur le stockage pour un compromis performance tout a fait acceptable.

Qu’en est-il chez Microsoft, sur la plateforme Azure ?

3 types de volumes SSD  sont disponibles : les disques standard, premium, et en encore en test les disques ultra SSD.

Note : tous les tests ont été effectués sans cache lecture ou écriture.

Les disques standard SSD managés proposent déférents volumétries. Certes vous pouvez au moment de la création du volume opter pour une volumétrie adaptée à vos besoins, MAIS gardez à l’esprit que le prix n’est pas vraiment proportionnel à la volumétrie. Par exemple, si vous créez un volume de 1100 GB, vous serez facturé  au tarif du 2TB. Il en est de même pour les autres types de volumes SSD.

image

Hum, jusqu’à 500 IOPS là ou un AWS GP2 sons burst IO est à 384 IOPS.

image

OK, contrat respecté. On plafonne clairement aux 500 IOPS promis. Mais rien ne garantit ce niveau de performance dans le temps, car les IOs ne sont pas provisionnés. Par contre la latence pique un peu les yeux. Incompatible avec du workload SQL Server. AWS faisait mieux de ce côté là.

Si l’on strippe les volumes (RAID0 dans mon cas car je n’ai pas la nécessité d’avoir de la redondance), le test de performance est sans surprise :
image

Mais la latence est clairement meilleure. Je ne vais pas encore sauter au plafond vu la latence, mais c’est mieux et les 2 000 IOPS peuvent convenir à bon nombre de charge de travail SQL.

Est-ce que la passage du des volumes SSD premium permet un réel gain ?

image

Pour être totalement honnête, j’avoue que les volumes P4 et P6 m’ont réellement déçu. 120 et 240 IOPS théoriques. Pas mieux sur le papier, sans parler de la latence.

image

J’avoue ne pas comprendre l’intérêt de ces volumes. A proscrire donc en production. Passons.

Le test d’un p10 est encore une fois sans surprise :
image

On a dit 500 mon bon monsieur. Pas trop de rabe. Moins que les disque standard finalement !!! Bon OK, on me propose des IOs provisionnés, mais alors pourquoi une telle latence ! Impossible de travailler avec un sous système disque aussi lent.

image

Dès que l’on strippe les volumes, la latence diminue également. Mais si l’on est OK pour upgrader vers un P40 (2TB et 285$ / mois) on a des IOs et peu de latence.

image

Mais encore une fois pourquoi une telle volumétrie. Un disque IO1 AWS provisionné à 7500 IOPS a une taille de 150 GB. Et si je strippais 3 volumes de 650 GB, proche des 2TB Azure, le calcul théorique monte à 97500 IOPS, en admettant que l’on ne soit pas limité par la VM.

Car oui, il faut aussi tenir compte de ce facteur. Certaines VMs sont limitées en nombre d’IOPS. la VM DS13_V2 que j’ai utilisée est théoriquement limitée à 25 000 IOPS. Pourtant, en agrégeant 4 volumes P40 je devrais être bloqué par cette limite.

image

De manière surprenante on dépasse ce plafond ! Et faible latence, enfin     Sourire 

Mais si je change la taille de la VM pour utiliser une DS14_V2, les IOPS sont encore plus élevés, comme quoi la VM a aussi son importance:

image

Notez que pour des IOs en 256 Kb, on double le nombre d’IOs en divisant par 2 la latence …

Difficile d’établir un comparatif entre Azure et AWS d’un point de vue prix pour une volumétrie donnée. AWS est plus souple quand à la taille des volumes.

Disques, avec IOPS provisionnés :

AWS Azure
1 x io1 de 200 GB

  • 10 000 IOPS réels
  • 320 MB de bande passante
  • 747 US$ par mois

 

Mais

3 x io1 de 650 GB

  • ~ 97 000 IOPS réels
  • 960MB de bande passante théorique !
  • 6 200 US$ par mois !!!!
1 x P15 de 256 GB

  • ~ 1 100 IOPS réels
  • 125 MB de bande passante
  • 42 US$ par mois

ou bien pour comparer en IOPS :

2 x P30 –> 2 TB

  • ~ 10 000 IOPS réels
  • 400 MB de bande passante
  • ~300 US$ par mois

Autant dire que Microsoft pousse à la “surconsommation’’ en terme d’espace disque. Pour autant cela semble revenir moins cher, a moins d’une erreur de ma part.

Quid des disques SSD sans IOPS provisionnés, sachant que je ne peux pas faire d’équivalent en terme de volumétrie, encore une fois :

AWS Azure
1 EBS GP2 de 200 GB

  • 3 000 IOPS avec Burst IO
  • 600 IOPS sans Burst IO
  • 150 MB de bande passante
  • 20 US$ par mois

ou bien

4 EBS GP2 de 50 GB

  • 12 000 IOPS avec Burst IO
  • 600 IOPS sans Burst IO
  • 4 x 128 MB de bande passante
  • 22 US$ par mois
1 x E15 de 256 GB

  • ~ 500 IOPS réels
  • 60 MB de bande passante
  • 20 US$ par mois

ou bien :

2 x E10 –> 256 GB 

  • ~ 1 000 IOPS réels
  • 120 MB de bande passante
  • ~20 US$ par mois

ou encore pour reprendre la formule RAID avec 4 volumes :

4 x E10 –> 512 GB 

  • ~ 2 000 IOPS réels
  • 240 MB de bande passante
  • ~40 US$ par mois

Encore une fois, bien difficile de sortir une conclusion sur les disques. Sans effet Burst IO de AWS, on peut considérer que les performances et le tarif sont proches, une centaine d’IOPS de différence. La bande passant opte en faveur de AWS.

Pour ma part, je trouve l’effet burst IO vraiment bluffant. Du coup les performances de la VM en sont très grandement améliorées, pour un tarif vraiment très très raisonnable. Hors cout de VM, au final je trouve l’offre AWS plus intéressante au niveau des disques pour du IaaS même si je dois reconnaitre que les volumes SSD premium Azure me semblent plus attractifs que leurs équivalents AWS.

Et c’est sans compter avec les volumes Ultra SSD qui pointent le bout de leur nez sur le cloud Microsoft. Certes il faudra la VM qui sera capable de les supporter mais un disque de 256GB pouvant monter a 76 800 IOPS, on touche au rêve de tout DBA (voire toute admin système).

image

Probablement un test à venir … Sourire

J’ai beau chercher un moyen pragmatique de comparer les offre, je n’y arrive pas. Tant qu’ l’un calcule le prix et les IOPS sur le volume effectif (AWS) et l’autre se cantonne à des prix par tiers de performance avec volumétrie induite (Azure), je ne suis pas sur que cela soit possible.

Je vous laisse vous faire votre propre idée.

Mais je rêve tout de même du jours où l’on bénéficiera sur Azure d’un effet Burst IO à la mode AWS. Cela rééquilibrera ce test, qui pour ma part tourne à l’avantage de Amazon AWS.

Happy IOPS on Azure !

Publié dans Windows Azure | Tagué , | Laisser un commentaire

Test d’IOPS dans une VM EC2 (Amazon AWS)

Le fait de travailler avec de nombreux clients (près de 130 différents ) offre des avantages.

Le premier bénéficie à chacun d’eux. Certes les compétences sur la plateforme SQL Server (choix d’infrastructure, performance, migration, troubleshooting, virtualisation, cloud …) est bien entendu importante.

Mais, mes clients sont aussi à la recherche d’expérience. 20 ans sur SQL Server, ses différentes versions, et autant de Windows !! Et quoi que l’on en dise, tout expert que l’on se prétend être, on apprend tous les jours avec un produit tel que SQL Server. Si vous croisez un consultant vous assurant tout connaitre, je penche pour un cas de mythomanie aggravée. 20 ans que je travaille sur ce SGBD, MVP depuis 10 ans, certifié MCM (100 personnes dans le monde), je n’ai pas d’hésitation à dire que je ne connais pas tout de SQL Server. Bref, accumuler des expériences chez chacun de ces clients apporte une valeur ajoutée indéniable  qui profitera à tous ces clients, et aux nouveaux … Avoir été confronté à un problème, c’est diagnostiquer plus rapidement et avancer plus rapidement vers la solution. C’est aussi proposer l’architecture adéquate en fonction des besoins.

Tout cela pour dire que je “kiffe” mes clients. Et certains sont joueurs, pour mettre en place des infrastructures hors du commun, avec des IOPS hors norme OnPrem, des VLDS de plusieurs dizaines de TB, ou des cluster Multi Régions sur cloud public.

Et certains sont suffisamment cool pour m’autoriser à partager des tests faits durant ces missions.

Aujourd’hui, c’est le cas d’un bench IOPS sur des VMs Amazon. Ne perdez pas de vue qu’il s’agit là d’un point de vue DBA, il est probable qu’un architecte certifié AWS ait un avis légèrement différent.

Les tests effectués sont strictement pragmatiques et répondent à une question simple : comment choisir mon sous système disque pour des VMs sur AWS.

Les tests ont été réalisés à l’aide Microsoft DISKSPD, successeur de SQLIO, qui portait bien mal son nom …

.\diskspd -b8K -d30 -h -L -o8 -t16 -r -w0 -c5G r:\temp\io.dat > resultdiskpsd.txt
.\diskspd -b8K -d30 -h -L -o8 -t16 -r -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b8K -d30 -h -L -o8 -t16 -si -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b8K -d30 -h -L -o8 -t16 -si -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
 
.\diskspd -b32K -d30 -h -L -o8 -t16 -r -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b32K -d30 -h -L -o8 -t16 -r -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b32K -d30 -h -L -o8 -t16 -si -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b32K -d30 -h -L -o8 -t16 -si -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
 
.\diskspd -b64K -d30 -h -L -o8 -t16 -r -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b64K -d30 -h -L -o8 -t16 -r -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b64K -d30 -h -L -o8 -t16 -si -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b64K -d30 -h -L -o8 -t16 -si -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
 
.\diskspd -b128K -d30 -h -L -o8 -t16 -r -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b128K -d30 -h -L -o8 -t16 -r -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b128K -d30 -h -L -o8 -t16 -si -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b128K -d30 -h -L -o8 -t16 -si -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
 
.\diskspd -b256K -d30 -h -L -o8 -t16 -r -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b256K -d30 -h -L -o8 -t16 -r -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b256K -d30 -h -L -o8 -t16 -si -w0 -c5G r:\temp\io.dat >> resultdiskpsd.txt
.\diskspd -b256K -d30 -h -L -o8 -t16 -si -w100 -c5G r:\temp\io.dat >> resultdiskpsd.txt 

Un premier test consiste à mesurer la performance des disques “General Purpuse SSD”, dit GP2 pour les intimes.

La règle de base dit : 3 IOPS par GB, jusqu’à une limite de 10 000 IOPS.

Mais à cela s’ajoute un composant qui mérite TOUTE notre attention : un crédit de 5 400 000 IOPS qui permet de “monter” à 3000 IOPS sur des petits volumes ( < 1TB ).

image

Effectivement, sur un volume de 10GB, théoriquement limité à 30 IOPS, on constate l’effet burst io :

image

Le “surcroit de puissance” est bien présent.

Dès que l’on opte pour un volume plus grand, 5TB, l’effet disparait et on retrouve la règle de 3 IOPS/GB capés à 10 000 IOPS.

image

Si l’on se base sur ces chiffres, utiliser des gros disques est donc plus performant que d’utiliser des volumes plus petits.

Dans l’ancien temps Sourire, entendez pas là OnPrem avec des bons vieux disques rotatifs, pour gagner en performance, on strippait les disques (les bons vieux RAID xx). Pour ce cas précis la redondance ne m’intéresse pas. Un RAID 0 suffit.

Faisons un calcul théorique pour une volumétrie allant jusqu’à 14 TB : on peut utiliser 1 seul volume ou bien un stripe de 4 volumes. Le tableau ci dessous présente le calcul des IOPS théoriques :

image

Si l’on pivote les données pour mesurer les différences en fonction de la volumétrie totale, on constate que les performances sont similaires pour une volumétrie inférieure ou égale à 3TB (sans burst io) et, au delà, agréger les volumes devient plus intéressant Au delà, du fait du plafond d’IOPS, agréger les volumes est plus intéressant de part le plafond de 10 000 IOPS :

image

Mais si l’on ajoute l’effet Burst IO, l’agrégation de volumes est systématiquement plus performante.

image

Donc dans tous les scénarios, utiliser l’agrégation de volumes permet un gain de performance, tant que le crédit du burst IO n’est pas épuisé !!!

La question qui se pose donc naturellement à ce moment du test est : “quelle est la durée de vie de ce crédit d’IOPS ?”

En fait, cela dépend de la volumétrie du disque :

image

Dans tous les cas, vous avez 30 minutes minimum de burst IO. Donc à moins d’être systématiquement au maximum des performances des volumes ce genre de configuration peut s’appliquer à une très grande majorité des VMs supportant SQL Server.

Une fois le crédit épuisé, il faut par contre patienter entres 40 minutes (pour un volume de 750 GB) et 15 heures pour voir le crédit totalement ré-alloué.

En fonction de votre charge de travail, vous serez peut être en mesure de fonctionner à 3000 IOPS quand cela est nécessaire, durant toute votre période ouvrée Sourire . 4 volumes de 250 vous offrent 40 minutes de Burst IO avec une attente de 2 heures pour le remplir en totalité. Probablement que 80 ou 90% des charges de travail SQL sont compatibles avec cette topologie disque.

néanmoins, pour ceux qui recherche un maximum de performance, il existe aussi la possibilité de bénéficier d’IOPS provisionnés  (io1 : 50 IOPS / GB) avec un maximum de 32 000 IOPS atteint ) 640 GB.

image

Pour ce nouveau test, sur une instance R5DXL, pour les curieux, je vérifie que mes résultats sur le volume GP2 sont bien identiques au premier tests :

image

OK, tout est correct.

On provisionne donc ce volume à 10 000 IOPS:image

Sur des IOs 8K on est proche de la limite. Correct donc.

Si l’on monte encore le niveau de performance pour provisionner 25 000 IOPS, on constate cette fois ci que le niveau de performance attendu n’est pas au rendez vous !

image

En modifiant les paramètres du test, 16 threads et une profondeur de file  à 16, les performance s’effondrent totalement, de manière incompréhensibles !

image

Un point à investiguer, donc, mais grosse déception.

Un autre point est non négligeable lors du choix de la configuration : le tarif.

Partons du principe que le besoin en volumétrie est faible (seulement pour simplifier le calcul, si cela ne vous convient pas, Excel est votre ami ….) : 200 GB:

  • 200 GB en IOPS provisionnés
    • 10 000 IOPS réels
    • 320 MB de bande passante
    • 747 US$ par mois
  • 4 EBS GP2 de 50 GB
    • 12 000 IOPS avec Burst IO
    • 4 x 128 MB de bande passante (à valider toute fois)
    • 22 US$ par mois

22 $ contre 747 $. La différence est énorme pour au final peu d’IOPS supplémentaires. Est-ce que les 10 KIOPS sont utilisés en permanence sans laisser le temps au crédit du Burst IO de se recharger ??

par contre pour une volumétrie supérieurs à 4 TB, même avec 4 volumes > à 1 TB on perd le burst IO, donc peut être cette stratégie d’IO provisionnés prend de l’intérêt, mais à quel cout ?? Bien des questions à se poser.

Le test ne serait pas complet dans parler des disques éphémères, car il s’agit bien là d’un des intérêt des EC2 R5DXL, pour positionner la TempDB sur des disques locaux rapides.

Sans être au niveau attendu pour du NVMe, on est sur un cloud public et l’on doit satisfaire plusieurs clients …, il faut avouer que cela permet de donner un bol d’oxygène à SQL Server très friand d’IOs sur la TempDB.

image

C’est clairement la latence qui bénéficie de ces disques locaux.

A quelques semaines de Noel, si je devais faire ma liste au gros bonhomme en habits rouge, pour héberger du SQL Serveur, je voudrais bien une EC 2 de type R5DXL avec

  • EBS Simple pour l’OS
  • 4 volumes GP2 (General purpose SSD) en RAID 0, RAID 5 ou RAID 10 pour les data files.
  • 2 (ou 4) volumes GP2 (General purpose SSD) en RAID 0, RAID 1, (RAID 10) pour les log files.
  • Un volume éphémère pour la base TempDB.

Edit 2018-11-27 : Amazon double les IOPS provisionnés : 60 000 IOPS désormais.

Today we are announcing 2x improvement in peak performance of Provisioned IOPS SSD (io1) Volumes from 32,000 IOPS to 64,000 IOPS and from 500 MB/s to 1,000 MB/s of throughput per volume when attached to Nitro system EC2 instances.

These performance improvements make it even easier to run applications requiring high performance storage, such as large transactional databases, big data analytics, and log processing applications.

Happy IOPS on AWS !

Publié dans Amazon EC2 | Tagué , | Laisser un commentaire

Comparaison des services Microsoft Azure et Amazon AWS

Si comme moi vous êtes confrontés aux deux environnements Cloud, il arrive un moment où l’on se mélange les pinceaux entre les différents noms de services offerts par chacun des providers.

Certains de mes clients utilisent Microsoft Azure, d’autres sont des fervents adeptes de Amazon AWS. Pour être totalement honnête, je n’ai pas vraiment de préférence J. Il faut dire que les services rendus sont vraiment similaires. Il faut quand même reconnaitre à Amazon le fait d’avoir été sur le marché avant Azure. Ce qui explique aussi qu’une majorité de mes clients utilisant des solutions de Cloud public en soient clients.

Mais quand vient le moment de concevoir une architecture, de parler de services, il arrive que ma langue fourche en utilisant le nom de Lambda en lieu et place de Fonction Azure ou de disques à la place des EBS.

Bref, une « matrice » de conversion des noms est la bienvenue. Et je suis tombé par hasard sur ce document que vous pouvez télécharger ici. J’ose espérer que le document sera mis à jour fréquemment au vu de toutes les nouveautés en la matière chez chaque éditeur. Une version HTML est aussi disponible.

image

Les services sont catégorisés, le document, de 37 pages tout de même, est simple à parcourir. Une “table des matières” est même disponible, vous pouvez cliquer sur une des icones représentant les catégories.

image

Avec bien entendu la partie Data …

image

Un must have …

Publié dans Amazon EC2, Amazon RDS, SQL Azure, Windows Azure | Tagué | 5 commentaires

Planification Azure SQL Databases–Azure functions

Il y a un peu plus de 20 ans je découvrais SQL Server. Déjà, avec SQL Server 6.5 il existait des assistant dans Management Studio qui facilitaient la vie du DBA.

Tout d’abord, SQL trace ! Certains d’entre vous font l’association avec l’actuel profiler. C’est bien le cas, il s’agissait bien de l’utilitaire graphique permettant de visualiser l’activité du serveur ….

Hydra, SQL Server 6.5, a aussi vu l’apparition d’un assistant qui encore le bonheur des administrateurs : le Database maintenance Plan Wizard. Oui, les plans de maintenance ! Pas tout à fait sous leur forme actuelle. Pas d’agent SQL, mais son ancêtre SQLExecutive.

Il y a donc des tâches qui incombent encore DBA. La sauvegarde, le test d’intégrité, la gestion des index et statistiques d’index.

Et puis Azure SQL Databases vient bousculer les habitudes. Certains s’imaginent que leur métier de DBA va disparaitre. Non, il va seulement se transformer. Probablement en administrateur de données plutôt qu’en administrateur de bases de données.

Lorsque j’interviens sur ces bases « managées », il est fréquent qu’aucune maintenance ne soit effectuée. Certes les sauvegardes sont gérées par l’hébergeur, Microsoft, mais la réindexation, voire les tests d’intégrité restent à la charge du client, vous … Et qui dit pas de réindexation ou de mise à jour de statistique d’index dit problèmes de performance à venir.

Quid des performances dans Azure ? Certes il faut compter avec la latence réseau que l’on ne rencontre pas quand l’applicatif et la base de données sont hébergés dans le même datacenter, proche des utilisateurs. Mais la performance d’une requête est aussi très largement guidée par la présence d’index et par la fraicheur des statistiques d’index. N’hésitez pas à planifier des Update Stats fréquemment.

SQL Server sur Azure, ce n’est pas du SaaS, mais « seulement » du PaaS. Il reste donc des points que vous devez gérer. Comme la maintenance des index !!!

clip_image002

Historiquement les travaux sont planifiés au travers de l’agent SQL Server. Le problème étant qu’il n’y a pas d’agent SQL sur Azure !

Il faut donc trouver des solutions de contournement pour planifier la gestion des index :

  • Créer un plan de maintenance sur une instance SQL disposant d’un agent et modifier le serveur cible en désignant la base SQL Azure
  • Utiliser Azure automation
  • Créer une Azure fonction

Afin de rester cohérant avec la philosophie PaaS, je vais présenter en priorité les solutions serverless. Au passage, si vous êtes en phase de conception d’une nouvelle application, je vous encourage fortement à vous intéresser à ce type d’architecture, plutôt basée micro services (par opposition aux applications monolithiques que l’on rencontrait par le passé).

Dans ce billet, nous allons aborder les fonctions Azure, de manière simple, dans le but d’exécuter du code dans une base de données à intervalle planifié, un job en quelques sortes Smile. Et quoi de plus logique que de planifier la réindexation et la mise à jour des statitiques.

Pour cela, j’ai créé un environnement de test depuis le portail Azure. Un serveur de bases de données, en France puisque la région est à présent disponible, et une base de données.

Un point important à ne pas oublier au sujet de Azure SQL Databases : il n’est pas possible d’exécuter du code Cross-Database. Autrement dit, on ne peut pas généraliser la procédure à l’ensable des bases du « serveur ».

A titre personnel, je préconise et utilise les scripts de Ola Hallengren comme scripts de maintenance. Que ce soit pour les sauvegardes, la gestion des index ou des tests d’intégrité.

Il faudra donc déployer les scripts, en fait les fichiers CommandLog, CommandExecute et IndexOptimize, dans chaque base.

  clip_image003

La tarification et les performances sont liés à la base, il parait logique que les ressources consommées pour la réindexation soient aussi à la charge de la base et non pas liées à une base système ou utilisateur prévue à cet effet.

Etant donné que les bases partiellement contenues sont disponibles dans Azure, nous allons créer un User with Password:

CREATE USER [Maintenance.User] 
WITH PASSWORD = '<str0ng_p@ssw0rd>'
GO
EXEC sp_addrolemember N'db_owner', 
                      N'Maintenance.User'
GO

Il reste à présent à configurer la fonction Azure pour appeler la procédure stockée.

Depuis le portail Azure, il suffit de rechercher le mot clé « Function »

image

Et de démarrer la configuration

clip_image006

Une fois terminé l’app service est présent.

image

Il faut maintenant configurer la fonction en y ajoutant le code que l’on souhaite exécuter, comme nous y invite l’interface graphique.

clip_image010

L’assistant nous propose différentes options pour coder la fonction. Il est possible d’utiliser Visual Studio ou Visual Studio Code, ou bien de passer par l’éditeur de Azure.

clip_image012

S’agissant d’une fonction, il est possible d’opter pour un déclanchement au travers d’un appel HTTP ou bien d’utiliser un déclencheur basé sur un minuteur. C’est cette dernière option que nous choisirons.

clip_image014

Et d’utiliser quelques lignes de C# :

#r "System.Configuration"
#r "System.Data"

using System;
using System.Text;
using System.Configuration;
using System.Data;
using System.Data.SqlClient;
using System.Threading.Tasks;

public static void Run(TimerInfo myTimer, TraceWriter log)
{
    log.Info($"C# Timer trigger function executed at: {DateTime.Now}");
    var str = "Server=tcp:sqlagent.database.windows.net,1433;Initial Catalog=AdventureWorks;Persist Security Info=False;User ID=Maintenance.User;Password=;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;";
    using (SqlConnection conn = new SqlConnection(str))
    {                    
        StringBuilder sb = new StringBuilder();                    
        sb.Append("exec [dbo].[IndexOptimize] @Databases ='AdventureWorks'");
        String sql = sb.ToString();                    
        using (SqlCommand command = new SqlCommand(sql, conn))
        {
            command.Connection.Open();
            command.ExecuteNonQuery();
        }                                   
    }
}

clip_image016

Il est possible de tester la fonction au travers du bouton exécuter.

clip_image018

Une fois le test effectué, vient l’étape de la planificiation.

image

Le format utiliser est similaire au Crontab que connaissent les Linuxiens. Heureusement pour nous, une aide précieuse est disponible dans l’interface, ou bien une recherche dans votre moteur favoris vous en dira plus.

Il est possible de désactiver la planification au travers d’un switch spécifique :

image

La fonction, elle, peut être stoppée, comme si l’on stoppait le site Web.

Deux principaux inconvénients quant à l’utilisation des fonctions :

  • Une durée d’exécution limitée même s’il est possible de modifier les 5 minutes par défaut (un peu juste pour de la réindexation sur de grosses bases)
  • Par défaut, pas de possibilité de stocker les crédentials de la chaine de connexion et donc de devoir avoir les informations en clair.

Happy scheduling

Publié dans Azure Function, SQL Azure | Tagué | 2 commentaires

Export de la structure d’une base de donnes SQL Server

Pourquoi un billet sur ce qui est à priori une problématique simple dans SQL Server ?

Oui, pourquoi ne pas simplement utiliser l’assistant de SSMS qui permet de scripter une base de données, la structure de tous les objets ?

Tout simplement parce qu’il est cas où l’on veut planifier de manière régulière cette opération. Il est donc hors de question que cela soit une opération manuelle dans SQL Server Management Studio.

Pourquoi ne pas simplement faire un backup de la base de donnes ?
Lorsque la taille des bases de données devient importante (500GB, 1TB) on se trouve confrontés à des problématiques d’espace sur les volumes de backup, de rétention, le temps de sauvegarde et de restauration. Certaines bases voient 95% du contenu être rafraichi tous les jours !

C’est là ma problématique. Une base de type DataWharehouse de volumétrie vraiment conséquente et donc les données sont réintégrées en totalité toues les nuits. Le backup ne me “sert” finalement pas à grand chose. Car une fois la restore effectuée, on relance les scripts d’importation de données depuis divers environnements.

Au final il est apparu que seule la structure de la base était utile, d’un point de vue sauvegarde. D’où la question : comment exporter la structure d’une base ?

Alors, oui, en puriste, je devrais dire qu’il y a un gestionnaire de code source avec son versionning qui détient LA bonne version. mais dans la vraie vie ….

S’offre alors à nous plusieurs solutions …

J’avais par le passé travaillé avec du PowerShell et l’objet Scripter de SMO.

 $Scripter.Options.DriAll=$False ;
 $Scripter.Options.IncludeHeaders=$False ;
 $Scripter.Options.ToFileOnly=$True ;
 $Scripter.Options.WithDependencies=$True  ;
 $Scripter.Options.FileName=$Sqlfile ;
 $Scripter.Options.ScriptDrops=$False ; 
 $Scripter.Options.IncludeIfNotExists=$False ; 
 $Scripter.Options.AppendToFile=$True ;

Il suffisait ensuite de boucler ave du ForEach sur les différents objets pour obtenir le résultat escompté.

On peut aussi utiliser le Data-tier Application Framework (DACFx). Il suffit alors de créer un DacPac (attention, pas le BacPac, qui, lui contient aussi les données … ). Encore une fois, cette opération est manuelle dans SSMS. Mais avec un peu d’imagination on peut tout a fait programmer tout cela via du PowerShell et l’ordonnancer avec un Agent SQL ou autre.
J’avoue que je ne suis pas vraiment fan de cette solution (tout n’est pas supporté d’un point de vue de la structure) même si au travers des modules fournis dans l’incontournable pack @psdbatools (http://dbatools.io) il est simple d’appeler la commande Export-DbaDacpac pour ensuite l’automatiser.

Export-DbaDacpac -sqlinstance MyInstance -Database MyDatabase  -Path C:\temp 

Une dernière possibilité s’offre à nous … très simple à mettre en œuvre!

Tout d’abord il suffit de faire appel à la commande DBCC CLONEDATABASE qui permet de créer un clone de la base de données … sans les données. On obtient donc la structure. A nous de juger si les valeurs de statistiques d’index sont pertinentes ou pas. J’avais déjà présenté cette fonctionnalité qui est a présent disponible dans toutes les versions de SQL Server à compter de SQL Server 2012 SP4.

DBCC CLONEDATABASE (MyDatabase, MyClone) WITH NO_STATISTICS

ou bien, au travers des dbaTools :

Invoke-DbaDatabaseClone -SqlInstance MyInstance -Database MyDatabase -CloneDatabase MyClone 

Une fois le clone terminé, il ne reste plus qu’à sauvegarder cette base comme une base lambda.

Et le tour est joué. Certes, ce n’est pas du script de base à proprement parler, mais pour qui veut archiver la structure d’une base sans ses données, la solution reste élégante. On peut ensuite restaurer cette base sur n’importe quel serveur et en extraire les scripts au besoin.

Happy scripting

Publié dans SQL Server | Laisser un commentaire

SQLSatParis–Installation de SQL Server sous Docker

Lors de ma session “SQL Server & Docker, les premiers pas”, une erreur était survenue lors de l’installation manuelle de SQL Server dans un conteneur Windows Server Core démarré en mode interactif.

Cette démo relativement simple et sans surprise avait parfaitement fonctionné lors de plusieurs Events. J’ai pensé en premier lieu que le problème était dû à une mise à jour de l’image Windows Core (1709 ou 1803 ?).

image

Le détail de l’erreur ne permet pas spécialement de se prononcer sur la root cause. J’ai vu ce genre de message quand le chemin d’installation était relativement long. Ce qui n’était pas le cas ici.   

J’ai pris quelques minutes pour rejouer la démo. Et aucune erreur n’est survenue. Tout a parfaitement fonctionné.

image

Peut-être une erreur sporadique, difficilement reproductible, peut-être que l’image de Windows que j’ai utilisée aujourd’hui, publiée il y a 6 jours, a corrigé quelque chose. Malheureusement, je n’aurais pas encore le fin mot de l’histoire.

Si vous rencontrez un problème, n’hésitez pas à m’envoyer un message.

Publié dans Evènements | Tagué | Laisser un commentaire

SQLSaturday #762 – Paris 2018–SQL Server et Docker, les premiers pas–les slides

Samedi 7 juillet se tenait à Paris l’édition 2018 du SQL Saturday. Beau temps, bonne humeur et des speakers passionnés étaient au rendez-vous.

Malheureusement, moins de participants qu’à l’accoutumée. Certes il est compliqué de se mobiliser en période estivale, de surcroit pendant la coupe du monde et après une première édition du Power Saturday. Allez, gageons que la prochaine édition sera un vrai succès. N’hésitez pas à nous faire part (nous, organisateurs bénévoles) de vos remarques pour faire que ces évènements répondent à vos attentes et soient un vrai succès communautaire. Nous sommes attentifs à tous les retours positifs ou négatifs.

Pour ma part, j’ai eu le plaisir d’animer une session décrivant les premiers pas de SQL Server et Docker, une session de découverte pour DBA soucieux de se préparer à la virtualisation version 2.0.

image

Les slides et les démonstrations sont téléchargeable sur mon OneDrive ainsi que sur le site du SQL Saturday.

Enjoy !

Publié dans Evènements | Tagué , | Laisser un commentaire