Les compétences du DBA moderne : Docker

Le métier de DBA est en pleine évolution, voire révolution. Tout un pan du métier a tout simplement disparu : le choix du matériel, son installation avant la mise à jour des firmware et drivers. La virtualisation (disons la virtualisation 1.0, virtualisation matérielle) a grandement simplifié la tâche des administrateurs système et donc par voie de conséquence des DBAs.

Elle permet en effet de choisir une configuration « matérielle » sans pour autant être contraint par cette même configuration durant toute la vie de l’applicatif. Il est extrêmement simple de faire évoluer les ressources dont dispose le serveur de bases de données. Ajouter de la CPU, étendre la mémoire, ajouter des volumes, autant de manipulations qui ne nécessitent que quelques secondes d’arrêt, dans le pire des cas, même s’il reste possible d’ajouter à chaud de la CPU et de la mémoire, ces options restent déconseillées pour des VMs dédies à SQL Server.

Dès 2010 / 2011 (ahhh, les JSS) je donnais des sessions liées à la virtualisation de SQL Server. Aujourd’hui, les raisons qui pousseraient à ne PAS virtualiser SQL Server ne sont pas légion. Bref, la virtualisation fait partie intégrante de la vie du produit, et donc des compétences du DBA. Je ne revendrais pas sur le sujet, bien qu’il soit important de « bien » configurer les VMs.

Depuis 2016 et le SQLSaturday #510 de Paris, je vous présente régulièrement Docker. L’idée ici n’est pas de vous transformer en administrateur système spécialisé en Docker, mais bien de vous donner les informations nécessaires et suffisantes relative à votre rôle de DBA.

Pour faire simple, la containerisation, la virtualisation (disons 2.0) est une virtualisation d’OS. On « supprime » tout simplement la couche Guest OS d’une VM. LE conteneur fit alors directement appel aux « DLL » de l’OS hôte en lieu et place de l’OS Guest.

On va installer le moteur Docker juste au-dessus de l’OS hôte (Windows OU Linux). Ce moteur va permettre la prise en charge de containers. Un container n’est ni plus ni moins que l’exécution d’une image, un template, qui encapsule un service.

L’installation de Docker peut se faire sur Linux (Ubuntu, Redhat, SUSE et les déclinaisons basées sur le jeu des distributions héritées) ou bien sur Windows. Le moteur Docker s’intègre parfaitement sur Windows Server.

Pour Linux Ubuntu :

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt-get update
sudo apt-cache policy docker-ce
sudo apt-get install -y docker-ce
sudo service docker start

Pour Windows Server :

Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
Install-Module -Name DockerMsftProvider -Force
Install-Package -Name docker -ProviderName DockerMsftProvider -Force

Pour Windows 10, c’est un peu différent, on peut télécharger Docker depuis l’adresse https://docs.docker.com/docker-for-windows/install/ et cela installe une VM Moby qui contient tout le nécessaire.

On peut ainsi créer une image contenant un applicatif, tel que SQL Server, un serveur Web, un LoadBalancer tel que NGINX ou tout service que vous auriez développé.

Il est également possible de télécharger (commande DOCKER PULL) une image depuis une registry. Cette registry peut être publique, telle la registry de Docker ( http://hub.docker.com ) ou de Microsoft ( http://mcr.microsoft.com ) mais également privée, sur vos serveurs OnPrem ou bien chez un fournisseur Cloud (Azure, AWS, …). Certaines images sont officielles (crées par l’éditeur lui-même) comme c’est le cas pour SQL Server de la part de Microsoft, mais vous pouvez également créer vos propres images en « dérivant » une autre image. Vous avez alors la possibilité de publier cette image (commande DOCKER PUSH) vers une registry.

La construction d’une image se fait au travers d’un ficheri DOCKERFILE, un fichier qui contient les scripts que doit exécuteur le moteur DOCKER pour construire (commande DOCKER BUILD) une nouvelle image. La fichier Dockerfile contient la référence d’une image sur laquelle on se base et ensuite une suite de commande a exécuter.

Une fois votre image prête à l’emploi, il vous suffit d’instancier une image et d’exécuter le conteneur (commande DOCKER START). D’un point de vue exécution, il est important de noter que le conteneur n’est pas visible depuis le réseau. En effet, il va falloir rediriger un port TCP de l’OS hôte vers un port du conteneur.

Un conteneur est stateless. Si vous souhaitez conserver les données liées à votre conteneur, ce qui dans el cas de SQL Server est … plutôt une bonne chose, il convient d’effectuer une redirection de stockage. Soit en utilisant une redirection de répertoires soit en utilisant la notion de volumes docker. Quel que soit l’environnement d’exécution, Docker, au travers de la ligne de commande, permet une expérience utilisateur identique, comme on peut le voir sur l’exemple suivant. Le démarrage d’un conteneur SQL Server sur Windows ou Linux est similaire, la seule différence tenant au nom de l’image à démarrer.

Une fois démarré, ce qui est bien plus rapide que le démarrage d’une VM, votre conteneur est prêt à recevoir les connexions.

Pour stopper un conteneur, il suffit de lancer la commande DOCKER STOP. DOCKER RM quant à lui permet la suppression d’un conteneur. Le tableau suivant présente un parallèle entre la gestion et l’installation d’un logiciel dans le monde traditionnel et dans le monde Docker.

L’utilisation de Docker, et par voie de conséquence l’utilisation de SQL Server au travers de Docker s’inscrit dans la tendance actuelle de développements : les micro-services. Il est temps de mettre au placard les « vieux » développements monolithiques comme on a pu les connaitre (et les coder) durant les 20 dernières années. Ce genre d’application est relativement difficile à maintenir, car à chaque changement il fallait effectuer une batterie de tests de non-régression.

Alors qu’un modèle de développement basé sur des micro-services dialoguant entre eux sous est plus simple à maintenir et faire évoluer.

Une application devient alors l’assemble, simple, de briques applicatives. Docker compose (commande DOCKER-COMPOSE UP) permet alors de créer et de démarrer la notion d’application multi conteneur.

Un fichier YAML va décrire les différences services, comprenez par-là différents conteneurs, qui composent l’application. Chaque conteneur peut être créé via un fichier Dockerfile, ou bien en se basant directement sur une image.

Et cela s’intègre encore plus facilement dans un modèle de développement CI/CD avec de la mise en production automatique ou quasi automatique au travers de Wokflows supportés par des produits tels que ANSIBLE, JENKINS et d’autres.

Les avantages indéniables de travailler avec des conteneurs se résument en quelques points :

  • Légèreté : un conteneur est plus léger qu’une VM, nécessite moins de ressources et moins de mises à jour (pas de patching de l’OS guest), et offre une plus grande efficacité du Host
  • Simplicité : la mise en œuvre est simple. On créé une image une seule fois et on peut la déployer sur plusieurs environnements avec l’assurance que cela va s’exécuter exactement de la même manière, on évite le problème du « Ca marchait pourtant très bien sur mon PC mais en prod on a des problèmes … ». La même image peut être déployée en Dev, test et Prod.
  • la rapidité de mise en oeuvre
  • L’expérience utilisateur similaire sur Windows, Linux ou MacOS
  • Et certainement bien d’autres que j’oublie à cet instant

Je vous suggère les lectures suivantes :

 

L’utilisation de conteneurs est une tendance forte du marché. Pour le passage en production il faut tout de même s’équiper un peu, principalement d’un orchestrateur (Kubernetes, Swarm), ce que nous verrons dans un prochain article.

Je vous encourage fortement à tester Docker. Cela fonctionne parfaitement pour SQL Server et pourrait vous rendre bien des services. De plus il y a fort à parier que dans le futur vous soyez confronté à cette technologie. Autant jouer avec dès maintenant.

Happy Docker !

Publicités
Publié dans Containers, Docker, Linux, Non classé | Laisser un commentaire

Renouvèlement MVP

Je ne pensais pas avoir la possibilité de publier ce type de message une nouvelle fois, mais je suis renouvelé MVP DataPlatform, pour un an de plus tout du moins.

Je m‘étais fait à l’idée de ne plus être dans le programme mais il va falloir me supporter un an de plus…

Happy MVP day !

Publié dans CV | 1 commentaire

SQL Server 2019 CTP 3.0

SQL Server 2019 CTP3 est disponible depuis quelques heures, avec quelques nouveautés à la clé.
Il semble de plus en plus évident que les compétences du DBA sont en plein évolution / révolution. Il est temps d’ouvrir un nouveau chapitre de votre vie de DBA.
Prenez de l’avance et venez partager avec nous une journée de formation autour des compétences du DBA moderne lors du #SQLSatParis :

Inscriptions sur le site weezevent

Publié dans Non classé, SQL Server | Laisser un commentaire

Azure Files – Partage de fichier SMB3

Il y a des services Azure qui attirent la lumière et les artices : Azure SQL Databases, Azure Kubernetes Services (aka AKS), les machines virtuelles, les fonctions, ….

Et il y a des services dont la parution ne déclenche pas une avalanche de posts. Et pourtant …

Aujourd’hui, je vous propose d’aborder Azure File Share, un service de partage de fichiers sur protocole SMB3. Imaginez simplement votre partage de fichier que vous utilisez au bureau (ou sur votre réseau local privé à domicile) en mode cloud, tout simplement un cloud file system.

Quel rapport avec mon métier lié à la base de données ? Pas si évident que cela, sauf si vous imaginez un système simple, pragmatique et efficace de migration de bases OnPrem vers une machine virtuelle Azure. 

Direction le portal Azure pour créer le partage réseau …
Tout d’abord, il faut créer un compte de stockage, si vous n’en n’avez pas déjà un.

Le déploiement du compte de stockage prends quelques minutes…

Une fois terminé, il est possible d’aller de créer un service de type Files :

En spécifiant un nom et un quota de stockage.

La partage SMB3 est à présent opérationnel. Vous pouvez uploader des fichiers via le navigateur :

Mais l’idée est quand même d’utiliser le partage réseau depuis un explorateur de fichier ou bien depuis un applicatif…

Depuis le navigateur, il suffit de cliquer le sur bouton Connect pour que les commandes PowerShell pour monter le drive soient automatiquement préparées !

Un simple copier / coller dans PowerShell_Ise pour exécuter les commandes de test et de sauvegarde des credentials afin de pouvoir se reconnecter plus tard.
Il n’est pas nécéssaire / obligatoire de créer un lecteur (Z dans le bout de code qui suit) pour utiliser le partage SMB.

On peut se connecter directement sur le partage en utilisant le chemin UNC, comme vous le feriez sur un partage d’un serveur de fichier de votre ré »seau local :

La copie des fichiers peut se faire via powershell ou via l’explorateur de fichier …

Simple, efficace, à tester d’urgence …

La liste des scénarios suceptibles d’utiliser le service de partage de fichier est assez longue. A vous de l’utiliser selon vos besoins. Mais, de mon côté, cela va me servir lors de process de migration de bases de données vers des VMs dans Azure.

Happy SMB!

Publié dans Azure | Tagué | Laisser un commentaire

SQL Server Management Studio 18 disponible

Depuis quelques jours il est possible de télécharger la dernière version de SQL Server management Studio (aka SSMS).

La version ne supporte pas de mise à jour depuis une 17.x, Fresh install à prévoir donc. Ou bien installation Side-By-Side, à vous de voir.

La version 18 de SSMS supporte SQL Server 2008 jusqu’à SQL Server 2019 (encore en preview au moment de l’écriture de ce billet), ainsi que Azure SQL Managed Instance. Mais pas grand chose en ce qui concerne SQL 2019 Big Data Cluster, qui semble pour le moment réservé à Azure Data Studio, du moins pour la partie HDFS

La scission avait déjà commencé par le passé, mais à présent SQL Server et SSMS ne comportent plus de composants en commun.

Voici les liens pour le téléchargement : version en-us et version fr-fr.

Difficile de faire plus simple côté installation :

imageimage

Notez cependant que le module PowerShell spécifiques à SQL Server ne sont plus installés. Si vous souhaitez l’ajouter, dans une invite de commande PowerShell Run Ad Administrator:

Install-Module -Name SqlServer

Une fois l’installation terminée, on reste en terrain connu, pas vraiment de changements. Je trouve très pratique le subtil changement d’icone de l’instance SQL trahissant l’emploi d’un OS Linux !

image

Quelques écrans ont aussi été corrigés pour prendre en compte les évolutions de SQL Server  mais également la suppression des diagrammes de bases de données Sourire

image image

Il est probable que je découvre de nouvelles différences à l’usage !

Happy SSMS !

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

Les compétences du DBA moderne

Lors du #PowerSaturday / #SQLSatParis 2019 je vous propose une pré conférence traitant des compétences du DBA moderne. Accompagné de David (aka @MikeDavem) et d’un invité surprise, la journée s’articule autour de différents thèmes, allant de la migration et des outils adaptés, au choix de la plateforme, en passant par Docker et K8s, sans oublier SQL Server 2019 et les Big Data Cluster.

Bref, grosse journée en prévision.

image

Les inscriptions sont ouvertes à l’adresse :

https://www.weezevent.com/power-saturday-2019-les-competences-du-dba-moderne

Attention, nombre de place limité et tarif early-bird accessible pour quelques jours encore ….

Publié dans Conférence, SQL Azure, SQL Server | Tagué | Laisser un commentaire

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 …

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