SQL Saturday Paris – 15 juin 2019 – inscriptions ouvertes

Les inscriptions au SQLSaturday sont ouvertes.

image

Pour mémoire, ce SQL Saturday sera couplé à deux autres évènements afin de vous proposer une journée abordant à la fois des sujets Sharepoint, Office, SQL Server Data et BI.

image

Le nombre de places étant limité, pensez à vous inscrire rapidement sur le site du SQLSaturday : https://www.sqlsaturday.com/872/eventhome.aspx

L’évènement est gratuit et ouvert à tous. Une participation facultative de 10 euros vous est demandée sur vous souhaitez prendre votre repas en compagnie de speakers et continuer d’échanger sur les sujets data.

Et pourquoi ne pas proposer une session ? Chacun à une expérience à partager, un sujet qui le passionne et don’t vous souhaitez parler. N’hésitez pas. Toutes les sessoins sont les bienvenues. Si vous souhaitez un peu d’aide ou de coaching, contactez moi.

Save the date …

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

Azure Container Instance et SQL Server

 

Si l’on regarde la liste des services Azure, il peut parfois être compliqué de choisir la bonne option, le bon service, pour héberger SQL Server. D’un côté le classicisme au travers d’une VM (Windows ou Linux), d’un autre côté une architecture serverless avec SQL Azure (en single database ou bien en mode pool élastique), ou bien une instance managée. Ceux qui suivent ce blog ou qui ont assisté à une session lors d’un SQL Saturday savent que je m’intéresse de près à la version 2.0 de la virtualisation : les conteneurs.

Azure offre différents services de conteneurs, nous allons dans un premier temps aborder Azure Container Instance.

Il s’agit très certainement du moyen le plus simple pour déployer et exécuter des conteneurs Docker dans Azure. Pas de serveur à gérer. Pas de VM à déployer, pas d’orchestrateur type Kubernetes. Un nom réseau pleinement qualifié pour y accéder. Bref, simple, efficace.

Let’s go.

Lorsque l’on se connecte sur le portail, il suffit de sélectionner le bon service et de débuter l’assistant d’installation.

image

Il est possible de spécifier une image sur le Hub Docker ou bien sur le repository Microsoft.

image

On spécifie ensuite le ressources dont on souhaite disposer, le nom DNS, le port TCP et les variables d’environnement comme on le ferait dans un fichier DOCKERFILE ou en ligne de commande.

image

image

Après quelques secondes, le conteneur est créé et démarré.

image

On peut accéder à la configuration de celui-ci, sans toutefois pouvoir modifier quoi que ce soit. On note au passage l’effort qui a été fait pour présenter les métriques systèmes liées à ce conteneur.

image

 

image

image

Tout comme l’on pouvait voir la log du conteneur sous docker, un onglet spécifique nous fourni la même expérience utilisateur.

image

On dispose même d’un shell afin d’interagir avec le “système”, l’OS du conteneur. Notez au passage que le volume disponible dans le contenreur est relativement réduit : un peu plus de 40GB.

image

Au final, la connexion depuis SSMS (ou une application) se fait très simplement en utilisant le FQDN.

image

Simple, pragmatique, efficace.

MAIS

On est dans la vrai logique des conteneurs. A savoir que l’on est stateless. Dès que le conteneur est stoppé, ou redémarré depuis le portail Azure, tout ce qui a été fait dans le conteneur est perdu. Absolument tout. Donc … les bases. Ce qui va de fait limiter les scénarii possibles avec ACI et SQL Server.

  • En production : compliqué, à moins de conserver le conteneur Up And Running tout au long du cycle de vie de l’application. J’ai déjà au le cas de figure, il suffirait de définir sa propre image qui serait exécutée comme un environnement vierge à chaque démarrage. Une fois le job terminé, on jette. Les ressources sont elles aussi limitées. En mémoire et nombre de CPU, tout comme le volume total des bases.
  • En test : pourquoi pas. Le côté stateless devient cette fois un avantage, car on peut reprendre les tests depuis une configuration vierge. Et le mode de tarification n’y serait finalement pas trop mal adapté.
  • En dev : avis très partagé. J’ai encore du mal à me faire une idée définitive. Si le fait de stopper le conteneur fait “perdre” les bases de dev ne me parait pas très productif. Certes il y a un gestionnaire de code source qui peut l’héberger et on peut tout recréer, mais bon … Et quid des données de test …. A bien y réfléchir, je pense que je n’y mettrais pas mes bases de dev.
  • En démo : pourquoi pas. A voir si le tarif est plus intéressant sur du très court terme par rapport à une single database SQL Azure, ou une VM … mais le coté rapidement disponible, pourquoi pas. Même si une instance développeur sur ma machine gardera toute ma préférence.

Il est possible d’utiliser un stockage persistant en montant un partage réseau dans un conteneur. Mais cela complexifie un peu l’affaire. Même en passant par du script.

az container create \
    --resource-group conseilit-fr \
    --image mcr.microsoft.com/mssql/server:2017-latest \
    --name sqlserver2017 \
    --ports 1433 \
    --vnet-name aci_vnet1 \
    --vnet-address-prefix 10.0.0.0/16 \
    --subnet aci_subnet1 \
    --subnet-address-prefix 10.0.0.0/24 \
    --environment-variables ACCEPT_EULA=Y SA_PASSWORD=Password1
    --azure-file-volume-account-name $ACI_PERS_STORAGE_ACCOUNT_NAME \
    --azure-file-volume-account-key $STORAGE_KEY \
    --azure-file-volume-share-name $ACI_PERS_SHARE_NAME \
    --azure-file-volume-mount-path /mssql/

Il faudra ensuite donner les droits à SQL d’utiliser cet emplacement, … Quitte à créer une image basée sur l’image officielle. Bref, pas forcément très simple comme mise en oeuvre pour un service don’t la philosophie semble être “create – start – run – stop – delete” dans un laps de temps relativement faible.

Et si le conteneur doit avoir de la persistance et une durée de vie longue, autant le donner en gestion à un K8s, ce que l’on abordera dans un prochain billet.

Côté tarification, la facturation débute au moment où l’on commence le pull de l’image et se termine lorsque l’on stoppe le conteneur. Adapté donc à un workload qui durerait peu de temps, mais qui serait exécuté à intervalles réguliers.

Si l’on devait exécuter le conteneur toute une journée, cela reviendrait à 5.38$ soit un peu plus de 160$ par mois. Raisonnable donc.

 

image

A mon avis, l’intérêt indéniable de la solution consiste à démarrer des conteneurs, plutôt orientés traitements, à la demande, sachant également qu’il reste possible d’utiliser le co-scheduling qui va exécuter plusieurs conteneurs sur le même hote.

SQL Server ne semble pas être la cible prioritaire des container instances. Let’s play with K8s !

Happy ACI …

Publié dans Azure, Containers, SQL Server | Tagué , | 1 commentaire

SQL Saturday Paris–15 juin 2019

Le SQLSaturday Paris 2019 vous présente l’état de l’art de la plate-forme de données Microsoft en 2019 et au-delà.

sqlsat872_web

Moderne, Hybride, multi-usages, relationnelle ou non structurée, multi-langages, etc., les plates-formes de données ont grandement évolué ces dernières années.

Quotidiennement confrontés aux challenges historiques, les professionnels de la données doivent ajouter de nouvelles cordes à leur arc. Pour preuve les intitulés des postes Data aujourd’hui :  Data Architect, Data Engineer, Data Analyst ou encore Data Scientist.

La communauté Data vous accompagne dans cette transformation et le SQLSaturday 2019 vous propose d’embrasser l’évolution des métiers de la donnée.

Les sessions qui figureront à l’agenda de cette journée, ciblant autant développeurs qu’administrateurs ou contrôleurs de gestion / analyses financiers, aborderont l’évolution de nos métiers et des plates-formes de données, en particulier autour des technologies Microsoft et Azure.

Les professionnels  comme les nouveaux-venus, vont pouvoir découvrir les nouveautés et les dernières technologies (Databricks, SQL Server 2019, etc.) ainsi qu’aborder les sujets de modernité (intelligence artificielle, big compute, etc.) ou de rupture (multi-cloud, multi-techno).

Un évènement pouvant en cacher un autre, ce SQL Saturday sera couplé à deux autres évènements afin de vous proposer une journée abordant à la fois des sujets Sharepoint, Office, SQL Server Data et BI.

image

Power

Ce ne sont pas moins de 3 communautés qui s’unissent, le GUSS, la Communauté aOS et le Club Power BI pour vous offrir une conférence autour des technologies Microsoft.

L’événement se divise en 2 journées, indépendantes.

Une journée de Workshops Premium le vendredi, pour découvrir et approfondir concrètement avec des experts reconnus. Une journée de conférences communautaires le samedi pour parcourir les sujets qui vous touchent au plus près lors de sessions d’une heure.

Cette année nous gardons le format et nous le rendons transverse à nos communautés pour vous offrir la possibilité d’élargir votre agenda.

Saturday

Un « Saturday » est une journée de conférences communautaires autour d’une technologie « SQLSaturday » « SharePoint Saturday », etc. dans un format reconnu partout dans le monde.

Ce jour de la semaine est l’occasion de profiter au maximum des échanges avec les conférenciers et les membres de la communauté dans un contexte plus détendu. Pas d’emails ou d’appels téléphoniques à traiter.

Vous y retrouvez des experts locaux et internationaux. Une occasion parfaite pour découvrir, apprendre, approfondir, partager et rencontrer des gens animés des mêmes passions.

Vendredi 14 juin: workshops

Vous avez le choix entre l’un des 5 Workshops proposés:

  • Initiation Power Platform
  • Power BI : usages avancés
  • PowerApps et Flow: usages avancés
  • Office 365
  • Data Platform

Prix : 150€

Le prix comprend la journée de conférence, le repas de midi et une invitation pour la journée communautaire du samedi

Samedi 15 juin : conférence communautaire

  • 6×6 sessions de 60 minutes en parallèle sur les différents sujets.
  • Des parcours pour coller aux attentes de chacun, qu’il soit technique ou métier
  • Un espace de réseautage et de rencontre
  • Un coin “ask the experts”

Prix : La participation à l’évènement est gratuite. Pour ceux qui souhaient partager la pause déjeuner avec les speakers et sponsors, une participation de 10€ pour le repas est demandée. Cet événement est communautaire et sans profit, les speakers et volontaires sont tous bénévoles.

Les Call For Speakers sont ouverts via Sessionize et le site du SQLSaturday.

Certes les speakers historiques seront probablement au rendez vous, mais chacun peut proposer une ou plusieurs sessions. Ne soyez pas timide. Et si vous souhaitez un peu de coaching, n’hésitez pas à nous le faire savoir, on vous accompagnera !

Marquez les dates dans vos agendas, 14 et 15 juin …

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

Planification Azure SQL Databases–Azure Elastic Jobs

Après avoir abordé par deux fois déjà la planification de Jobs sur SQL Azure au travers de Azure Runbook et et Azure Functions, il est temps d’aborder une méthode toujours en preview : les jobs élastiques.

On attend toujours la GA de cette feature qui permet en “relative” simplicité d’automatiser l’exécution de jobs sur plusieurs bases, voire des bases sur plusieurs “serveurs” SQL Azure. Malgré le nom Elastic Jobs, cette fonctionnalité n’est pas réservée aux bases de données contenues dans un elastic pool. On peut très bien planifier une tâche dans une base stand alone.

En résumé, il s’agit d’un service SaaS (???) qui va centraliser les jobs et leur planification, ainsi que les connexions nécessaires pour accéder aux bases, stocker le résultat de l’exécution, voire même le résultat de requêtes exécutées dans les étapes de ce job.

On retrouve finalement le fonctionnement de l’agent SQL Server. Et c’était bien là le but. Et comme pour l’agent SQL Server qui s’appuie sur la base MSDB, in va nous falloir disposer d’une base de donnée qui sera dédiée à la gestion de ces jobs.

image

Une fois cette base de donnée créé, il suffit de se déplacer dans la section dédiée aux travaux élastiques :

image

Une fois n’est pas coutume, j’avoue être assez fan de l’icone présente au dessus du bouton nous invitant à créer un agent. Vraiment représentatif su service fourni.

Le fait de pouvoir créer plusieurs agent est un peu déconcertant, mais en y réfléchissant bien cela peut aussi permettre de cloisonner les choses. Garder de côté les jobs plutôt dédiés à la maintenance et avoir un autre agent dans lequel des utilisateurs pourraient planifier des opérations davantage orientées business.

Ah, oui, on vous a bien prévenu, c’est du preview … Toujours sur de vouloir continuer ???

image

Il suffit alors de sélectionner la base servant de réceptacles à la fonctionnalité :

image

Il suffit de patienter un peu pour que le système configure cette base.

image

Ah, oui, j’ai oublié de vous dire, c’est encore une version Preview … Sourire L’interface graphique s’arrête donc là !

En effet, tout ce que vous trouverez dans le portal est en lecture seule! Vous pourrez donc seulement consulter vos Jobs, Cedentials , …

La configuration consiste à créer un ensemble de tables, vues et procédures stockées qui permettront de “retrouver” nos petites habitudes liées à l’agent SQL …  Avec entre autre les procédures stockées permettant de créer un job, une étape (jobstep), démarrer un travail et le stopper

imageimage

A présent il va falloir … coder. Au choix : PowerShell, ou bien T-SQL. Le plus  simple dans un premier temps est de conserver le langage natif de SQL Server, mais ceux pour qui l’automatisation est une priorité se pencheront naturellement vers du PowerShell.

La première étape consiste à travailler la sécurité. Il faut alors définir :

  • une identité permettant de lister les bases du “serveur” Azure (souvenez vous, j’ai déjà mentionné le fait que l’on pouvait exécuter des jobs multi serveurs)
  • une identité permettant d’exécuter le job dans chaque base de données.

Elastic Jobs credentials

D’abord les Logins (pensez bien à rester sur ma base “master” de votre instance)

image


CREATE LOGIN ElasticJobMasterUser WITH PASSWORD = N'R3@lly$tr0ngP@$$w0rd!';
GO
CREATE LOGIN ElasticJobJobUser WITH PASSWORD = N'R3@lly$tr0ngP@$$w0rd!';
GO

Ensuite, créer le User correspondant au Job Master dans votre base MSDB …

image

CREATE USER ElasticJobMasterUser FOR LOGIN ElasticJobMasterUser
GO
ALTER ROLE db_owner ADD MEMBER ElasticJobMasterUser;  
GO

Il faut a présent créer les credentials qui permettrons de se connecter aux bases cible :

image

CREATE MASTER KEY ENCRYPTION BY PASSWORD='An0therR3@lly$tr0ngP@$$w0rd!';  
GO

CREATE DATABASE SCOPED CREDENTIAL ElasticJobMasterUserCredential 
WITH IDENTITY = 'ElasticJobMasterUser', SECRET = 'R3@lly$tr0ngP@$$w0rd!'; 
GO

CREATE DATABASE SCOPED CREDENTIAL ElasticJobJobUserCredential 
WITH IDENTITY = 'ElasticJobJobUser', SECRET = 'R3@lly$tr0ngP@$$w0rd!'; 
GO 

 

Une fois fait, dans chaque base cible des jobs, il faut créer le User JobUser (DB01 et  DB02 dans cet exemple) :

image

Les permissions données dépendant alors des tâches que vous souhaitez effectuer via le job. db_datareader, db_datawriter peuvent suffire, ou mieux, travaillez directement au niveau de chaque Schéma …

CREATE USER ElasticJobJobUser FOR LOGIN ElasticJobJobUser
GO
ALTER ROLE db_owner ADD MEMBER ElasticJobJobUser;  
GO

 

L’idée suivante consiste à créer un TargetGroup : tout simplement une liste de bases sur lesquelles les jobs vont être exécutés.

Une fois le groupe créé, plusieurs options sont alors possibles pour ajouter des membres au groupe (des bases de données tout simplement). La procédure stockée sp_add_target_group_member permet:

  • d’ajouter toutes les bases de l’instance par le couple de paramètres target_type = ‘SqlServer’ et server_name = ‘xxx” »’. Dans ce cas, le login JobMaster va être utilisé pour lister les bases présentes
  • d’ajouter unitairement une ou plusieurs bases au travers des paramètres target_type = ‘SqlServer’ et server_name=”xxx”  et database_name= “xxx”
  • d’exclure (ou inclure) une base a postériori, ou dans le cas d’une selection complète de bases au travers des parametres membership_type = ‘Include/Exclude’ et datbase_name = ‘xxx’
  • de travailler au niveau d’un Elastic Pool avec target_type = ‘SqlElasticPool’ suivi du nom du serveur et du nom du pool.

Des options qui permettent de moduler facilement la portée du job, ou de planifier à différents horaires des actions sur des Pools Elastiques distincts avec un seul job mais plusieurs targets.

Sachant également qu’il peut y avoir plusieurs targets dans le même target group, on peut donc exécuter un job sur plusieurs serveurs et / ou  plusieurs elastic pools d’un seul appel.

image

Pour l’exemple, j’ai choisi de ne travailler que sur 2 bases, non contenue dans un elastic pool, de mon serveur en France, avec donc une exclusion.

-- Add a target group containing server(s)
EXEC [jobs].sp_add_target_group N'ServerGroup'
GO

-- Add a server target member
EXEC [jobs].sp_add_target_group_member
	@target_group_name = N'ServerGroup',
	@target_type = N'SqlServer',
	@refresh_credential_name=N'ElasticJobMasterUserCredential', 
	@server_name=N'conseilit-fr.database.windows.net'
GO

--Exclude a database target member from the server target group
EXEC [jobs].sp_add_target_group_member
	@target_group_name = N'ServerGroup',
	@membership_type = N'Exclude',
	@target_type = N'SqlDatabase',
	@server_name = N'conseilit-fr.database.windows.net',
	@database_name =N'SQLAgent1'
GO

une requête sur target_group_member permet de visualiser le contenu des groupes:

image

Reste à présent à …. créer un job ! On retrouve les bonnes vieilles habitudes au travers de sp_add_job et sp_add_jobstep, même s’ile ne s’agit bien évidement pas du même code behind.

Comme pour les tests précédents, j’ai opté pour la procédure stockée de Ola Hallengren pour la gestion des index (Rebuil / Reorganize / Update Statistics) : Oui, cela reste à votre charge sur SQL Azure (PaaS et non SaaS !!). Les objets ont été créés dans chaque base cible.

image

EXEC jobs.sp_add_job 
	@job_name='IndexManagement', 
	@description='Index rebuild, index reorg, update statistics'


EXEC jobs.sp_add_jobstep 
	@job_name='IndexManagement',
	@command='exec [dbo].[IndexOptimize]',
	@credential_name='ElasticJobJobUserCredential',
	@target_group_name='ServerGroup'

Reste plus qu’à tester …

image

EXEC jobs.sp_start_job 'IndexManagement'

Il est possible de “suivre” l’exécution des jobs via des requêtes SQL, car il n’existe rien depuis le portail …

--View top-level execution status for the job named 'IndexManagement'
SELECT * FROM jobs.job_executions 
WHERE job_name = 'IndexManagement' and step_id IS NULL
ORDER BY start_time DESC

--View all top-level execution status for all jobs
SELECT * FROM jobs.job_executions WHERE step_id IS NULL
ORDER BY start_time DESC

--View all execution statuses for job named 'IndexManagement'
SELECT * FROM jobs.job_executions 
WHERE job_name = 'IndexManagement' 
ORDER BY start_time DESC

-- View all active executions
SELECT * FROM jobs.job_executions 
WHERE is_active = 1
ORDER BY start_time DESC	

En cours d’exécution :

image

et une fois le job terminé :

image

Une fois que tout est validé, il est possible de planifier le job. Contrairement à SQL Server “classique” il n’est pas possible de disposer de plusieurs planifications par job. La planification est directement rattachée au job et se paramètre via la procédure sp_update_job. Les possibilités sont moins étendues que pour un SQLAgent, mais devrait néanmoins couvrir les cas les plus fréquents.

image

DECLARE @StartTime DateTime
SET @StartTime = DATEADD(hour,1,CONVERT(DateTime,CONVERT(Date,GetDate())))

EXEC jobs.sp_update_job
	@job_name='IndexManagement',
	@enabled=1,
	@schedule_interval_type='Days',
	@schedule_interval_count=1,
	@schedule_start_time=@StartTime

image

Après quelques exécutions planifiées, on peut consulter le résultat des exécutions dans jobs.job_executions.

image

SELECT job_name,step_name,lifecycle,start_time,end_time,last_message,target_type,target_server_name,target_database_name 
FROM [jobs].[job_executions]
ORDER BY current_attempt_start_time desc 

Mais toujours rien depuis le portail Azure.

image

Un peu frustrant, espérons que lors de la General Availability un effort sera fait de ce côté là. Sinon, gageons que des éditeurs tiers fourniront une IHM adaptée.

Happy scheduling !

Publié dans Elastic Jobs, SQL Azure | Tagué , | Laisser un commentaire

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

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