SQL Server 2019 est disponible

Il fallait s’y attendre compte tenu des évènements Microsoft en cours, que ce soit Ignite à Orlando ou bien le PASS Summit à Seattle où je suis actuellement.

 

L’annonce a été faite aujourd’hui (le 4 novembre), SQL Server 2019 est en General Availability, cela revient à dire que l’on peut télécharger une version RTM du produit, par exemple depuis votre abonnement MSDN.

 

Je ne vais pas détailler dans ce billet la liste des nouveautés de SQL Server 2019, mais la fonctionnalité phare reste sans conteste le « Big Data Cluster » qui mêle les fonctionnalités de tables externes Polybase avec un cluster Hadoop colocalisé avec SQL Server dans des Pods Kubernetes.

J’ai abordé ces points lors d’une pré conférence au SQLSaturday 2019 à Paris en Juin et j’aurais également la chance d’en parler au SQLSaturday à Lisbonne fin Novembre. N’hésitez pas à faire le déplacement …

Une image officielle SQL Server pour Red Hat a aussi vu le jour. Cela dit en passant, certaines fonctionnalités manquantes sous Linux sont à présent disponibles avec SQL Server 2019 : MSDTC, Marchine Learning, support de la réplication.

Le buffer pool hybride, le Rapid Recovery, le Static Data Masking, la gestion des certificats, la capacité de suspendre et de reprendre le chiffrement TDE d’une base de données font partie des nouveautés et devraient faire l’objet de futurs articles sur ce blog.

On peut aussi noter des améliorations au niveau des Graph Databases et de l’intelligent Query Processing

La base TempDB n’a pas été oubliée, les tables systèmes qui parfois souffraient d’une forte contention sont désormais hébergées dans le moteur Hekaton, le moteur InMemory OLTP sans lock et sans latches.

Sujet de prédilection en ce qui me concerne, la haute disponibilité voit se belles améliorations / nouveautés pour les groupes de disponibilité :

  • Une redirection du secondaire vers le primaire
  • La possibilité de disposer de 5 réplicas synchrones
  • La possibilité de créer un groupe de disponibilité mêlant bases systèmes et base utilisateur (attention, 1 seul) afin de gommer les lacunes de duplication de jobs, de logins et autres informations liées au bases Master et MSDB

 

Bref, de belles nouveautés qui vont, à n’en pas douter, accélérer l’adoption de SQL Server comme plateforme / Hub de données.

Happy SQL Server 2019 !

 

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

MicroK8s : cluster Kubernetes de test et développement

Afin de poursuivre une série de billets liées à Docker et Kubernetes, je vous propose d’aborder MicroK8s.

Un cluster K8s n’est pas forcément très simple à installer. L’environnement de production doit faire l’objet de toutes les attentions, mais pour le développeur qui souhaite disposer d’un bac à sable, éventuellement sur son poste, des solutions simples existent …

Deux alternatives semblent se démarquer à l’heure actuelle :

Minikube me parait être une solution un peu lourde, d’un point de vue mise en œuvre, si l’on souhaite s’adresser à un public de développeur. Il faut en effet passer par une machine virtuelle. Mais sachant que dans le monde OpenSource et / ou Conteneurisation en évolution / révolution permanente, il est fort probable que d’autres solutions verront le jour.

J’ai fait allusion aux développeurs et à leur poste de travail, et ce n’est pas sans raisons. Canonical, que vous connaissez probablement pour la distribution Ubuntu, se cache derrière MicroK8s et affiche clairement le crédo du produit : « A single package of k8s that installs on 42 flavours of Linux. Made for developers and great for appliances. ». Clairement Canonical semble fournir le moyen le plus simple pour provisionner un cluster Kubernetes à nœud unique à destination des développeurs pour tester leurs pipelines de CI/CD ou tout simplement pour permettre aux IT Pros et aux développeurs de se former à Kubernetes.

Bien que sponsorisé par Canonical, il est possible d’installer MicroK8s sur d’autres distributions que Ubuntu, comme le montre le site web de SnapCraft (également dans le giron de Canonical). Snap n’est autre qu’un magasin d’applications pour Linux.

Beaucoup de postes clients sous Linux exploitent Ubuntu, j’ai choisi pour ma part de faire cette démo sous CentOS. J’ai également des postes de test sous Fedora, plus orienté poste client que CentOS, mais il ne devrait pas y avoir de différences notables, y compris au travers de l’installation qui se fait au travers de l’utilitaire snap.

Snap est disponible pour CentOS version 7.6+. Pour vérifier la version de CentOS :

cat /etc/centos-release

Ensuite il faut installer Snap :

sudo yum install epel-release
sudo yum install snapd
sudo systemctl enable –now snapd.socket
sudo ln -s /var/lib/snapd/snap /snap

Une fois terminé, on peut procéder à l’installation de MicroK8s (il est préférable de disposer de 2GB de RAM au minimum sans quoi même si les conteneurs se lancent, ils restent en état pending).

sudo snap install microk8s –classic


Le processus d’installation, extrêmement simple, est vraiment appréciable et devrait convaincre bon nombre de personnes.

Une fois redémarré la session utilisateur, il est possible de vérifier la configuration du cluster K8s. Pour ceux qui ont l’habitude de travailler avec Kubernetes, vous utilisez l’utilitaire kubectl. Pour MicroK8s, il faudra utiliser microk8s.kubect. Simple et efficace.

kubectl cluster-info
microk8s.kubectl cluster-info
microk8s.kubectl get all -o wide –all-namespaces

Afin de garder les mêmes commandes que vous avez l’habitude d’utiliser, je vous suggère de créer un alias :

alias kubectl=’microk8s.kubectl’
kubectl version –short

Sachant qu’il s’agit d’un « cluster » Kubernetes de test/dev, un seul Node est nécessaire. Ce qui n’empêchera pas de jouer avec le scaling (l’ajout de réplicas). Les Pods seront seulement hébergés sur le même Worker.

Le déploiement d’une application est strictement identique à un « vrai » cluster K8s. Je vais réutiliser le déploiement de l’application Nginx de l’article précédent, fichier « deployment-definition.yaml ».

apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
spec:
selector:
matchLabels:
app: myapp
replicas: 1
template:
metadata:
labels:
app: myapp
type: front-end
spec:
containers:
– name: web
image: nginx
ports:
– containerPort: 80

kubectl create -f ./deployment-definition.yaml
kubectl get pods -o wide

De la même manière, il est possible de changer le nombre de réplicas :

kubectl scale deploy myapp-deployment –replicas 2
kubectl get pods -o wide

Aucune différence perçue avec le cluster Kubernetes utilisé précédemment. Contrat rempli !

Sachant que l’objectif est clairement de se positionner sur les postes développeurs, sur une machine virtuelle, on utiliserait la notion de snapshot de VM afin de reseter totalement la configuration. MicroK8s propose une fonctionnalité équivalente qui va détruire toute la configuration et mettre à disposition un « cluster » fresh copy (suppression des deployments, pods, services, images, …)

microk8s.reset

L’avenir nous dira si des produits équivalents seront disponibles afin de faciliter au maximum la vie des développeurs, mais nul doute qu’à l’heure où ce billet est écrit, MicroK8s fait forte impression…

Happy Micro Kubernetes !

Publié dans Containers, Docker, Kubernetes, Linux | Laisser un commentaire

Les compétences du DBA moderne : Kubernetes

Dans un précédent article nous avons abordé la nécessite de se former sur les conteneurs Docker.

Docker permet d’encapsuler un logiciel, un service, du code et ses dépendances. Une image correspond donc à un package exécutable, très léger, permettant l’exécution d’une application. Un conteneur, lui n’est qu’une instance en cours d’exécution de cette image. Plusieurs conteneurs issus de la même image, peuvent cohabiter sur un même moteur Docker.

Voici une infographie extraite du site Web de Kubernetes qui résume parfaitement l’évolution dans le temps :

Ce moteur est quant à lui multi-plateforme et compatible avec de nombreux cloud providers.

Mais, seul, le moteur Docker rends certes des services mais il manque une pierre à l’édifice, du moins pour passer sereinement en production : l’orchestration de conteneurs.

C’est à ce niveau qu’intervient Kubernetes qui va avoir la charge de l’automatisation du déploiement, de la gestion de la montée en charge, de la disponibilité de conteneurs.

D’un point de vue étymologique, Kubernetes est issu du grec κυβερνήτης signifiant pilote, ou timonier, fréquemment nommé dans sa forme courte K8s, un K puis 8 lettres dont on se moque et un « s » pour terminer. Plutôt que de plagier, je vous laisse lire la page Wikipedia si vous êtes intéressé par l’origine de ce projet dont Google est le grand artisan.

Encore une fois, tout comme c’était le cas pour l’article concernant Docker, mon but n’est pas de vous abreuver de tonnes d’informations techniques, de vous submerger de termes et de concepts pour vous transformer en ingénieur K8s (il existe de très bons articles sur le sujet sur Internet et sur les plateformes de formation en ligne) mais bien de vous donner les informations nécessaires et suffisantes pour que, dans votre rôle de DBA, vous soyez en mesure de proposer une architecture SQL Server s’appuyant sur cet orchestrateur.

J’aurais aussi bien pu parler de Docker Swarm, un « concurrent » de Kubernetes, mais, d’un point de vue pragmatique, c’est bien de dernier qui est largement utilisé en entreprise. Un prochain article sur Swarm pourrait voir le jour, on ne sait jamais. Tout comme il est probable que je poursuive cette série en abordant OpenShift, le gestionnaire de conteneurs K8s maintenu par Red Hat et qui a de fortes chances d’être présent dans des architectures OnPrem.

Kubernetes est un orchestrateur de conteneurs. A ce titre, il est responsable de la disponibilité du service fourni par un conteneur. Et donc, en toute logique, on parle de cluster Kubernetes.

Comme dans bon nombre d’architecture cluster, on retrouve la notion de Master et de Nodes.

Les Master comprenant des composants destinés à la gestion et à la surveillance du cluster. On y retrouve pelle-mêle, un serveur d’API qui permet d’interagir avec le cluster K8s au travers de lignes de commande, un service en charge de la surveillance des performances de chaque Nœud du cluster, un service en charge de maintenir un état désiré (l’exécution de conteneurs) sur le cluster en sollicitant le démarrage ou l’arrêt des conteneurs sur les différents Nodes. Les Nodes sont des serveurs sur lesquels s’exécute le moteur Docker (et quelques composants K8s) et qui vont permettre la prise en charge de vos conteneurs.

Kubectl

Kubectl est l’utilitaire en ligne de commande qui permet d’interagir avec le cluster K8s. Il y a pléthore de documentation et d’exemples sur internet, je ne vais pas m’étendre sur le sujet.

Kubectl permet de gérer les Nodes, les Pods, les Service, les Volumes, Services, etc … Bref tous les types de ressources qui existent dans un cluster K8s.

Voici quelques exemples de commandes pour les opérations courantes :

Commande Signification
kubectl get componentstatuses Renvoie l’état des composants du cluster
kubectl create|apply -f ./service.yaml Création d’une ressource
kubectl delete -f ./service.yaml Suppression d’une ressource
kubectl run nginx –image=nginx Exécute une seule instance à partir de l’image nginx
Kubectl get pods Affiche la documentation des Pods
kubectl get pods –selector=app=restexample Liste les pods qui correspondent au lable restexample
kubectl explain pods Affiche le détail de tous les Pods
kubectl get service(s) Liste tous les services créés ou celui spécifié
kubectl explain service(s) Affiche le détail de tous les Services ou celui spécifié
kubectl get deployment(s) Liste tous les deployments créés ou celui spécifié
kubectl explain deployment(s) Affiche le détail de tous les Deployments ou celui spécifié
kubectl get node(s) Liste tous les nodes ou celui spécifié
kubectl explain node(s) Affiche le détail de tous les nodes ou celui spécifié
kubectl logs <pod-name> Visualisation des logs d’un conteneur / pod
kubectl exec -it <pod-name> — bash Exécution d’une commande dans un conteneur

Je vous suggère de toujours garder sous la main un fichier contenant vos commandes les plus usitées ou bien la cheatsheet de Kubernetes.

On peut invoquer directement des ordres au travers de Kubectl, mais on peut également lui fournir en entrée un fichier … texte. Avec un formalisme spécifique certes, mais cela reste un bête fichier texte. YAML, acronyme de Yet Another Markup Language (ou YAML Ain’t Markup Language pour d’autres …), pour être précis ! le format permet la représentation de données sous forme de paires clé/valeur par une combinaison de listes, de tableaux, …

Ce fichier va être intégré par le cluster K8s comme étant du paramétrage, ou bien des choses à faire (déploiement d’une application). Le processeur YAML repose sur l’indentation, mais attention pas de tabulation, des espaces (leur nombre importe peu) …

Nodes

Il n’est pas rare de parler des Nodes en tant que Worker Node voire même Minion (oui oui les petits êtres jaunes des films …).

Chaque Worker exécute un Kubelet, lui-même sous forme de conteneur, qui est chargé de l’exécution des Pods sur ce Node. Il reçoit les messages demandant le démarrage ou l’arrêt des conteneurs. Mais le Kubelet gère aussi de la surveillance des conteneurs tout comme la surveillance du Node. Si le Minion semble avoir un problème, cette information est remontée vers le Master qui va alors envoyer un message à un Kubelet sur un Worker différent afin de démarrer les conteneurs qui étaient en cours d’exécution sur le nœud défaillant.

Le Kube-Proxy est un composant présent sur chaque Node. Il permet de gérer le trafic vers les Pods.

kubectl get nodes -o wide

Pod

Un conteneur « vit » dans un Pod. Il s’agit là de la plus petite unité gérée par K8s. Le Pod est à Kubernetes ce qu’un conteneur est à Docker. Un Pod peut contenir un ou plusieurs conteneurs qui ont l’assurance de s’exécuter sur un même nœud du cluster.

On constate que par défaut un certain nombre de Pods (les composant système de K8s) sont en cours d’exécution sur le cluster.

kubectl get pods -o wide –all-namespaces

Le Pod ne disposant que d’une seule adresse IP, si plusieurs conteneurs et donc plusieurs services sont hébergés, il faut donc utiliser plusieurs ports TCP.

Si vous souhaitez exécuter plusieurs instances d’une application containerisée, il faut alors exécuter plusieurs Pods contenant chacun le(s) conteneur(s) en question et non pas un seul Pod avec plusieurs conteneurs identiques.

Le Pod possède aussi des Labels, des informations textuelles sous forme de paires clé/valeur. En particulier le Label Selector permettra per exemple la recherche de tous les Pods. Les annotations ne sont que des metadata, des propriétés destinées à être lues. Pas de formalisme spécifique. Vous pouvez très bien les utiliser pour stocker la branche Git utilisée, le nom du développeur, etc …

Il est possible de créer un Pod au travers d’un fichier YAML (ou JSON) :

apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
app: myapp
type: front-end
spec:
containers:
– name: web
image: nginx
ports:
– name: web
containerPort: 80
protocol: TCP

kubectl create -f ./pod-definition.yaml

L’image du conteneur Nginx est téléchargée depuis le repository Docker Hub si elle n’est pas présente sur le Node sur lequel K8s a choisi de démarrer le Pod. Ensuite le conteneur va démarrer.

Le Deployment, que l’on abordera un peu plus tard, surclasse la création de Pod manuelle.

Service

Un Service permet d’exposer l’application. Il s’agit d’une abstraction logique d’un ou plusieurs Pods. Chaque Pod disposant d’une adresse IP interne au cluster Kubernetes. Le Service permet de router le trafic vers votre application. Le service ne va pas forcément exposer les ports de tous les conteneurs de votre Pod. Imaginez par exemple une application de type Web avec un FrontEnd et un BackEnd pour hébrger une base de données par exemple. Il est tout à fait imaginable que la base de données ne soit pas accessible depuis l’extérieur, donc pas de service, alors que le site Web lui doit répondre sur HTTP et/ou HTTPS (un service peut très bien être de type multi-port).

Plusieurs types de services existent :

  • ClusterIP, qui est la valeur par défaut, et qui n’expose le service qu’à l’intérieur du cluster K8s. La ressource n’est pas joignable depuis l’extérieur.
  • NodePort expose le service avec un port statique sur chaque nœud. Il est possible de joindre le service depuis l’extérieur au travers de la syntaxe <NodeIP>:<NodePort>. Le service est créé sur tous les nodes de manière identique donc peu importe quelle IP sera utilisée depuis l’extérieur, le service répartira la charge entre les différents Pods et Nodes du cluster.
  • ExternalName permet de mapper le service sur un nom externe de type FQDN. Il permet seulement de retourner un CNAME qui existe en dehors du cluster mais n’est pas mappé à un service / port spécifique relatif à une ressource du cluster K8s
  • LoadBalancer permet d’exposer les services des Pods à l’extérieur du cluster dans le cadre d’un provider Cloud comme Azure, AWS ou Google. Chaque LoadBlancer va automatiquement créer un service NodePort et un service ClusterIP. Des routes vont automatiquement être créés dans le cluster K8s pour permettre d’atteindre les conteneurs.

kubectl get services -o wide –all-namespaces

Un fichier YAML permet de créer un service, le plus simple étant le service de type NodePort. L’exemple suivant permet de joindre un Pod

  • du Selector myapp (le Pod correspondant à un conteneur exécutant nginx créé précédement)
  • nodeport représente le port TCP associé à l’adresse IP du Node. La valeur doit être comprise entre 30000 et 32767.
  • port représente le port TCP associé à l’adresse IP du service
  • targetport représente le port TCP associé à l’adresse IP du Pod
  • les informations présentes dans le Selector sont celles qui étaient inscrites dans la section labels de la définition du Pod.

apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: NodePort
ports:
– nodePort: 30080
port: 80
targetPort: 80
selector:
app: myapp
type: front-end

kubectl create -f ./service-definition.yaml

Un rapide test au travers de curl sur l’IP de l’un des Nodes permet de vérifier que le service a été créé avec succès :

Tester l’IP du second Node (192.168.1.222 dans mon cas) renvoie le même résultat.

Deployment

La notion de Deployment surclasse la notion de Pod. La déclaration d’un fichier de déploiement est similaire à celle du Pod que l’on a vu précédemment. Gardez bien en mémoire que l’orchestration et la gestion des conteneurs (des Pods) dans Kubernetes est régie par la notion d’état désiré.

Cet état désiré est exprimé au travers d’un fichier YAML encore une fois.

apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
spec:
selector:
matchLabels:
app: myapp
replicas: 2 # exécuter 2 pods correspondant au template
template:
metadata:
labels:
app: myapp
type: front-end
spec:
containers:
– name: web
image: nginx
ports:
– containerPort: 80

Ce fichier va donc décrire votre service au travers de méta données (nom, …) et d’une spécification (le(s) conteneurs qui le compose(ent)). Un des points importants est matérialisé par la balise replicas qui va de pair avec la notion de ReplicaSet. Elle va définir le nombre d’exemplaires de votre application. Cela se traduit par un nombre de Pods.

Si vous spécifiez 3 réplicas, alors, l’état désiré est d’avoir 3 Pods exécutant votre application. Et Kubernetes va en permanence comparer l’état désiré avec l’état actuel. Si un Pod (ou un Node) qui a subir une avarie, alors l’état actuel (2 réplicas) ne correspond plus à l’état désiré (3 réplicas), l’orchestrateur va donc automatiquement démarrer un nouveau Pod pour rétablir la configuration désirée.

kubectl create -f ./deployment-definition.yaml

On peu recréer le service qui cette fois ci va automatiquement répartir les requêtes sur les 2 Pods.

kubectl create -f ./service-definition.yaml

La notion d’upgrade de version d’application sans coupure de service est également gérée ! Vous spécifiez un nouveau déploiement, avec la V2 de votre application, voici ce qu’il va se passer :

  • En version 1, votre application possède 3 réplicas
  • K8s maintient donc 3 réplicas (état désiré)
  • On commence avec un premier Pod en V1 :
    • Un 4eme Pod va être instancié sur le cluster et attendre que le liveness check et le readiness check soient satisfaits
    • Une fois le readiness satisfait, le load balancer peut distribuer le trafic vers ce Pod
    • Mais l’état désiré ne fait mention que de 3 replicas, K8s va donc « tuer » un Pod en version 1. Pas de manière brutale. Il commence par interdire toute nouvelle connexion et attendre que le « termination grace period » (30 secondes par défaut) se termine pour être supprimé. Cela permet aux requêtes en cours sur ce Pod de se terminer.
    • Une fois la période de grâce terminé, le Pod est supprimé. On retrouve l’état désiré.
  • On enchaîne sur le second Pod en V1 :
    • Un 4eme Pod va être instancié sur le cluster et attendre que le liveness check et le readiness check soient satisfaits
    • Une fois le readiness satisfait, le load balancer peut distribuer le trafic vers ce Pod
    • Mais l’état désiré ne fait mention que de 3 replicas, K8s va donc « tuer » un Pod en version 1. Pas de manière brutale. Il commence par interdire toute nouvelle connexion et attendre que le « termination grace period » (30 secondes par défaut) se termine pour être supprimé. Cela permet aux requêtes en cours sur ce Pod de se terminer.
    • Une fois la période de grâce terminé, le Pod est supprimé. On retrouve l’état désiré.
  • On termine avec le troisième Pod en V1 :
    • Un 4eme Pod va être instancié sur le cluster et attendre que le liveness check et le readiness check soient satisfaits
    • Une fois le readiness satisfait, le load balancer peut distribuer le trafic vers ce Pod
    • Mais l’état désiré ne fait mention que de 3 replicas, K8s va donc « tuer » un Pod en version 1. Pas de manière brutale. Il commence par interdire toute nouvelle connexion et attendre que le « termination grace period » (30 secondes par défaut) se termine pour être supprimé. Cela permet aux requêtes en cours sur ce Pod de se terminer.
    • Une fois la période de grâce terminé, le Pod est supprimé. On retrouve l’état désiré.
  • L’état désiré est satisfait avec 3 Pods en V2

Sachant que l’on ne spécifie à aucun moment lors d’un kubectl create ce que l’on va créer, la balise kind du fichier YAML dit au moteur quel type de ressource il doit créer / détruire. Ce qui veut dire qu’il est possible de cumuler dans un même fichier à la fois la création d’un Deployment et d’un service. Il faut simplement séparer les objets par — (3 tirets).

La big picture

Maintenant qu’un certain nombre de termes et de principes sont établis, je peux vous présenter sans risque de provoquer un arrêt cardiaque la Big Picture d’un cluster Kubernetes.

  1. On communique au travers d’API avec Kubernetes pour lui soumettre des ordres comme déployer un service au moyen d’un fichier YAML, ou bien stopper ce service, ajouter des replicas, etc …
  2. L’état désiré spécifié dans le deployment va être envoyé aux Worker Nodes pour application au travers du Kubelet
  3. La communication inter conteneurs est assuré au sein du minion tout comme la communication inter Pods.
  4. Les requêtes externes sont acceptées par le kube-proxy qui reçoit le flux (ClusterIP et NodePort crées par le LoadBalancer)

Rien oublié ?

En tant que DBA, à ce moment du billet, une petite voix dans votre tête devrait vous dire qu’il manque quelque chose ….

Souvenez-vous d’un des principes de base de Docker : les conteneurs n’ont pas de stockage persistant. Lorsque le conteneur est détruit, on perd les données, sauf à avoir comité l’image. Donc, lorsque mon conteneur est hébergé dans un cluster Kubernetes et que l’état désiré n’est plus satisfait, un Pod va être crée sur un autre node … Et donc perte de données !!!!

La mise à disposition d’un stockage persistant est une des tâches confiées à l’orchestrateur.

Tout comme pour les clusters d’hyperviseurs, gérer le stockage est un problème distinct de la gestion du compute. Sur un hyperviseur on peut utiliser du stockage partagé (baie de disque connectée en NFS, iSCSI, Fiber Chanel) ou une solution de type Software defined storage comme le S2D ou vSAN. Il en va à peu près de même pour un cluster Kubernetes. Les volumes persistants sont une abstraction di stockage faire par des APIs. On retrouve les types de stockages liés à la virtualisation, mais d’autres possibilités existent. Ce qui m’a donné l’occasion de découvrir GlusterFS, solution qui se rapproche du S2D chez Microsoft. Historiquement, la performance du stockage a un impact important sur les performances de SQL Server, nul doute que les choix qui seront fait pour les volumes persistants seront cruciaux.

Les volumes sont rattachés à un Pod, et le(s) volume(s) peu(ven)t être monté dans un seul ou bien dans tous les conteneurs de ce Pod.

Et maintenant ?

Posons-nous pendant une « termination grace period » secondes (30 secondes pour ceux qui auraient lu en diagonale les § précédents).

En tant que DBA, est-ce que je dois maitriser tout cela ? Je ne pense pas. Mais tout comme il est demandé » à un DBA de connaitre son OS (Windows, Linux), il est important de disposer du vocabulaire et des concepts pour aborder sereinement l’avenir. Nul doute que la conteneurisation que je me plais à appeler « virtualisation v2 » va concerner les bases de données, et donc SQL Server. Et à ce titre, le DBA se doit de faire évoluer ses compétences dans ce sens.

Pour autant, on parle de virtualisation, donc tout cela devient abstrait, voire Server Less. Vous connaissez le principe du Server Less : je place une fonction quelque part sur un cloud public et cette fonction s’exécute quand je l’appelle. Je n’ai plus à gérer de VM, d’OS, ni quoi que ce soit. Je me focalise sur le métier, pas sur l’infrastructure. Pourquoi ne pas faire de « Server Less Kubernetes » et ne plus avoir à gérer toute cette complexité dans l’infrastructure ?

C’est ce que vous proposent les acteurs majeurs du cloud (Microsoft, Amazon et Google) avec leurs services Kubernetes Managés (Azure AKS, AWS ECS et Google GKE). Il ne reste que les applications à déployer.

Pour ceux que le cloud public effraie / rebute, il est tout à fait possible de monter son propre cluster Kubernetes OnPrem. Cela devient le pendant d’un cluster d’Hyperviseurs. On n’est plus trop dans le rôle et les compétences du DBA mais cela reste un exercice assez intéressant.

Pour aller à l’essentiel, je vous suggère de commencer par :

Mais rien n’empêche de construire son propre cluster, comme je l’ai fait. Je pense revenir sur les étapes dans un prochain billet. Celui-ci étant plutôt destiné à aborder l’architecture et les concepts.

Il est aussi possible de monter une plateforme OpenShift (Red Hat) qui semble devenir un standard pour un cluster Kubernetes OnPrem. Toujours Docker et K8s, mais on ajoute quelques fonctionnalités de gestion de code source, de gestion d’images, d’applications …

Dans un premier temps, la solution cloud public reste clairement l’option la plus simple et la plus rapide à mettre en œuvre.

Par exemple, pour Microsoft Azure, quelques lignes de code AZ Cli permettent de déployer un cluster pleinement fonctionnel :


az account set –subscription « xxxxxxx »
az group create –name rgk8scluster –location westeurope
az aks create –name aksk8scluster \
–resource-group rgk8scluster \
–generate-ssh-keys \
–node-vm-size Standard_L8s \
–node-count 2 \
–kubernetes-version 1.12.6

Il ne reste plus ensuite qu’à déployer vos services …

Happy K8s !

Publié dans Docker, Kubernetes, Linux | Laisser un commentaire

SQL Server sous Linux : Active Directory et authentification Kerberos

Vous le savez probablement, SQL Server, à compter de la version 2017, est disponible sous Linux et Docker. J’ai déjà écrit plusieurs articles et donné des conférences à ce sujet.

Si vous vous remémorez les écrans d’installation de SQL Server sous Windows (ou bien la ligne de commande de l’installation de SQL Server), vous devez spécifier le mode d’authentification. Pour rappel, l’authentification correspond à la phase de Login dans SQL Server où vous vous présentez avec une identité, vous devez prouvez qui vous êtes.

Pour SQL Server, il existe deux possibilités pour s’authentifier :

  • Authentification SQL : la vérification du mot de passe est faite par SQL server. Celui-ci doit stocker à la fois le nom de connexion (le login) et le mot de passe. Lorsqu’une demande de connexion, c’est SQL Server qui a la charge de la vérification de conformité du couple Login / Password.
  • Authentification Windows : Dans ce mode, l’authentification est faite par un acteur tiers, Windows dans notre cas. Soit au travers de la SAM locale soit au travers de Active Directory (NTLM ou Kerberos). Dans ce cas, SQL Server ne connait que le login et accepte la connexion car la vérification de l’identité de la connexion s’est faite au niveau infrastructure, en amont.

Cela se traduit par les options d’installation / configuration :

  • Mode Windows seulement : seul les logins authentifiés Windows peuvent se connecter à SQL Server
  • Mode Mixte : les connexions authentifiées par Windows et les connexions SQL sont autorisées.

Le fait que SQL Server s’exécute sous Linux ne signifie pas forcément que l’on doive exclure les clients souhaitant s’authentifier au travers d’Active Directory. L’ajout de quelques packages et quelques lignes de commandes suffisent.

Pour la démonstration, j’ai choisi d’installer (rapidement) SQL Server 2017 sur CentOS au travers du code suivant :

sudo curl -o /etc/yum.repos.d/mssql-server.repo https://packages.microsoft.com/config/rhel/7/mssql-server-2017.repo

sudo yum install -y mssql-server

sudo /opt/mssql/bin/mssql-conf setup

 

On peut confirmer que tout fonctionne au niveau du service

systemctl status mssql-server

Il est également possible de se connecter via SSMS :

 

Tout comme pour Windows, le prérequis pour joindre une machine au domaine consiste à spécifier le serveur DNS lié à votre AD. Dans mon cas, CentOS a récupéré une @IP via un serveur DHCP mais le serveur DNS paramétré dans le scope DHCP n’est pas mon contrôleur de domaine. Il me faut donc modifier légèrement ma configuration IP dans CentOS pour donner les bonnes valeurs.

sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0

pour ajouter les lignes suivantes :

PEERDNS=no

DNS1=192.168.1.101

Ensuite, je positionne le bon suffixe DNS

sudo hostnamectl set-hostname SQL14CentOS.conseilit.local

hostname

On applique les modifications, puis on vérifie le tout :

sudo systemctl restart network

sudo cat /etc/resolv.conf


 

Il faut à présent ajouter quelques packages pour se joindre au domaine :

sudo yum install realmd krb5-workstation samba-common-tools sssd oddjob oddjob-mkhomedir adcli oddjob oddjob-mkhomedir adcli -y

La commande REALM permet ensuite de joindre la machine au domaine.

sudo realm join conseilit.local

cat /etc/krb5.conf


Il est possible de vérifier le bon enregistrement dans le domaine au travers de NSLOOKUP :


Tout comme il est possible de vérifier directement dans le DNS et dans Active Directory


Pour les curieux, l’OS est bien renseigné en tant que RedHat Linux …

 

On peut aussi vérifier qu’il est possible d’acquérir un ticket Kerberos de la part du serveur Active Directory :

kinit administrator@CONSEILIT.LOCAL

klist

Tout semble donc opérationnel. Cependant, il faut que le compte de service SQL soit également un compte de l’AD pour que l’authentification fonctionne.

Pour cela nous allons créer un compte de service et créer un SPN pour le service SQL. Cela s’effectue par exemple en PowerShell sur le contrôleur de domaine.

New-ADUser mssql-AccountPassword (Read-Host -AsSecureString « Enter Password ») -PasswordNeverExpires $true -Enabled $true

setspn -a MSSQLSvc/SQL14CentOS.conseilit.local:1433 mssql

setspn -L SQL14CentOS

setspn -L mssql

Ensuite, il faut obtenir le ticket kerbéros pour le compte de service, sur le serveur SQL

kinit mssql@CONSEILIT.LOCAL

klist -A

Pensez à récupérer le numéro de version dont nous aurons besoin plus tard :

kvno MSSQLSvc/SQL14CentOS.conseilit.local:1433

Pour ma part, la version 2 est retournée, je l’ai donc positionné à la suite du paramètre -k dans les lignes de code du ktutil pour créer un fichier keytab.

addent -password -p MSSQLSvc/SQL14CentOS.conseilit.local:1433@CONSEILIT.LOCAL -k 2 -e aes256-cts-hmac-sha1-96

addent -password -p MSSQLSvc/SQL14CentOS.conseilit.local:1433@CONSEILIT.LOCAL -k 2 -e rc4-hmac

wkt /var/opt/mssql/secrets/mssql.keytab

rkt /etc/krb5.keytab

list

Il faut à présent supprimer les entrées n’étant pas au format « computername$@domain.com. ». Pour la capture d’écran précédents, il ne doit rester que les entrées encadrées de rouge.

Pour supprimer les lignes : delent [slot]

J’ai opté pour une stratégie « à partir de la fin » pour éviter de supprimer les slots que je dois conserver. Pour l’exemple, regardez les 2 delent de la fin qui sont tous les deux sur le slot 1…

Attention : clear supprime toutes les entrées. Si vous supprimez trop d’information, pas de panique. Reprenez à l’étape addent …

On écrit valide le fichier keytab (commande wkt) et on vérifie que tous est correct :

wkt /var/opt/mssql/secrets/mssql.keytab

rkt /var/opt/mssql/secrets/mssql.keytab

list

quit

On donne à présent les permissions et le propriétaire du fichier keytab pour automatiser la signature dans le domaine à chaque démarrage :

sudo chown mssql:mssql /var/opt/mssql/secrets/mssql.keytab

sudo chmod 400 /var/opt/mssql/secrets/mssql.keytab

sudo /opt/mssql/bin/mssql-conf set network.kerberoskeytabfile /var/opt/mssql/secrets/mssql.keytab

sudo systemctl restart mssql-server

Une fois que le service SQL a redémarré, il est alors possible de se connecter à l’instance via une authentification Windows alors que SQL server est hébergé sur Linux.

Je ne vous cacherai pas que la procédure me parait assez fastidieuse, mais parfaitement fonctionnelle. 

Happy SQL Kerberos Linux

 

 

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

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 !

Publié dans Containers, Docker, Linux, Non classé | 1 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