Linux on Zwindler's Reflection

Touraine Tech 2026 - Récap du jour 2

Fri, 13 Feb 2026 18:00:00 +0200

Jour 2 - C’est reparti !

Me voici dans le train du retour et je prend un peu de temps pour mettre en forme mes notes de la journée. C’est parti pour le récap du jour 2 de Touraine Tech 2026 !

Après une soirée speakers très sympa dans un bar à jeux, je me suis levé un poil trop tard et j’ai loupé la keynote… Dommage 😅.

Lorsqu’un simple bug réseau vous emmène dans les entrailles de Linux

Florian Forestier nous a raconté une histoire de debugging épique.

Le contexte : une équipe de 3 devs en mode “You build it, you run it”, avec une stack Golang/Svelte. Tout va bien, quand soudain arrive un manager qui dit “ça marche PAS”. La PKI est en panne, sur du hardware custom… provenant de matériel reconditionné tchèque (pour la modique somme de 200k€ tout de même).

Le matériel incriminé : des DL380 Gen 10 avec des cartes QLogic FastlinQ 45000. Il y en a 8, et aucune ne fonctionne.

L’enquête commence :

Les cartes sont visibles dans le BIOS ✓
lspci les détecte ✓
Mais ip link ne les voit pas ✗
dmesg affiche des erreurs sur les drivers qed/qede

Testé avec Ubuntu, CentOS, Alpine Linux -> KO partout. Impossible d’avoir des drivers pour des kernels récents compatibles avec Proxmox.

Après une semaine d’échecs collectifs, Florian a une “idée à la con” : installer une vieille Ubuntu 18.04. Moi ça me fait rire, parce que j’aurais commencé par là ! Quand on a du vieux matériel, on teste avec un OS contemporain du matériel.

Bingo ! Ça fonctionne.

À partir de là, investigation par dichotomie : Debian 12 avec le kernel 4.15 de Ubuntu -> OK. Bug présent en 4.17, absent en 4.16, puis rechercher le commit dans les modifications sur les pilotes qed/qede.

La solution : un code “non supporté” pas pris en compte dans une fonction ajoutée en 4.16. 3 lignes de fix.

Pour reverser le correctif dans le kernel Linux, il a fallu écrire sur la bonne mailing-list, avec ses 8 pages de règles. 3 semaines entre l’envoi du mail et le merge (habituellement 1-2 semaines).

Un beau REX de debugging bas niveau ! J’étais vraiment content de l’avoir vu :).

L’ampoule qui en savait trop : voyage au cœur de la sécurité des objets connectés

Paul Pinault nous a plongé dans le monde de la sécurité IoT.

Quelques chiffres pour poser le contexte : 300 millions d’ampoules connectées vendues chaque année, dont 60% en WiFi (vs Zigbee/ZWave). Et côté réglementation, ça bouge :

RED (août 2025) : garantie sécurité cyber EN18031, mises à jour possibles et sécurisées, communications chiffrées, données personnelles nettoyées, plus de mots de passe par défaut
Cyber Resilience Act (2026-2027) : SBOM obligatoire, MAJ pendant 10 ans minimum

Paul a donc disséqué (à la DREMMEL 🤣) une ampoule connectée équipée d’un ESP32-U4WD, avec ses 2 oscillateurs RTC/horloge et son eFuse, pour voir s’il pouvait la compromettre.

Les vecteurs d’attaque analysés :

Port série et JTAG : désactivés post-usine
Pairing WiFi : pas RED-compliant (HTTP car pas d’Internet au moment du pairing = pas de certificat, WiFi ouvert)
BLE Pin : pas possible sur une ampoule
BLE pairing : la voie privilégiée

Point rigolo : pour que les télécommandes soient CRA/RED compliant, l’ampoule doit aussi devenir une gateway BLE vers Internet (sinon, pas de mise à jour).

Au secours ! Mes images pourrissent mes perfs

Antoine Caron et Mathieu Mure nous ont parlé d’un sujet crucial pour les performances web : les images.

Un peu d’histoire… En 1992, la toute première image est affichée sur le web : les Cernettes (du CERN, évidemment).

Aujourd’hui, 99.9% des sites web ont au moins 1 image, et 68% des pages mobiles ont leur LCP (Largest Contentful Paint) lié à une image.

Le royaume des formats :

Morts/vieillissants : BMP, GIF, JPEG, PNG
Modernes : WebP, AVIF, SVG, JPEG XL

Après une chouette explication de comment ça fonctionne “en théorie”, Antoine et Mathieu nous on montré qu’à compression égale, les formats récents prennent moins de place, mais surtout, affichent des artefacts visuels bien moindres dans les hauts niveaux de compression (notamment AVIF).

Les bonnes pratiques présentées :

Taille adaptative avec srcset pour laisser le navigateur choisir la meilleure taille
Balises <picture> avec plusieurs <source> pour gérer différents formats
fetchpriority="high" au-dessus de la ligne de flottaison
loading="lazy" en dessous
Sharp en JS pour le traitement côté serveur
Git LFS pour éviter de commit des fichiers lourds
Cache de build pour éviter de reconstruire chaque image à chaque CI

Bref, j’ai du boulot sur ce blog (je le savais…).

Makers de Père en Fils

Matthias et Sylvain Gougouzian nous ont présenté un talk bonbon sur leurs projets makers en famille.

Un duo pétillant, pour ne pas dire explosif 😂 ! Matthias (le fils) est super cash (pour rester poli), c’était très rigolo à voir.

L’idée de Sylvain : initier ses enfants à l’électronique, comme nous à l’époque en cours de techno. Objectif : faire 1 à 2 projets par an ensemble.

Après découverte de Scratch (apprendre le code par blocs), Pyrates (approfondir avec Python), Micro:Bit (code visuel avec accéléromètres et boutons), TinkerCAD (conception 3D de projets physiques), Sylvain s’est dit que c’était le moment de passer à un vrai projet DE ZERO. Recréer un équivalent du Nabaztag !

Ils ont utilisé la méthode MoSCoW pour prioriser :

Must have : Météo (LEDs), Moteurs
Should have : Écran, GreenIT
Could have : Micro, HP, Carte SD
Won’t have : Bourse, Traffic

Choix techniques : ESP32/Raspberry Pico avec MicroPython.

Le moment touchant du talk : apprendre à se dire les choses. Matthias n’osait plus parler à son père quand une tâche était trop grosse, par peur de décevoir. C’est un point qu’en tant que parent, on peut trop facilement oublier…

Une fois les problèmes de communication réglé, ils ont pu découper en étapes : PoC d’abord (NeoLED, écran, servomoteur, bouton, carte microSD), puis passage au MVP avec la forme physique sur TinkerCAD.

Un bel exemple de transmission intergénérationnelle.

Another World, une belle leçon d’architecture logicielle

Olivier Poncet nous a fait découvrir les entrailles d’un jeu cultissime (bon, moi je le connaissais pas 🫣) : Another World.

Un talk que je voulais voir depuis longtemps, mais comme je savais que je le verrai à TNT26, j’avais décidé de ne pas regarder le replay !

Another World, c’est un jeu vidéo d’aventure/action cinématique sorti en 1991, fait par une seule personne (sauf la musique) : Eric Chahi, pionnier du jeu vidéo français des années 80-90.

Les specs impressionnantes :

Exécutable de 24 Ko
Assets de 1.2 Mo (images et sons)
Un moteur graphique polygonal 2D (pour les animations fluides et séquences cinématiques)
Un moteur sonore 4 pistes PCM
Une machine virtuelle pour tout gérer !

Le matériel de l’époque : Amiga 500 avec 1 Mo de RAM et un HDD de 20 Mo, augmenté d’un Genlock (caméscope/magnétoscope) et d’un magnétophone. Eric Chahi a créé ses propres outils en GFA Basic. Il a utilisé la rotoscopie : capturer une image vidéo, détourer les assets pour créer les animations. Toutes les peintures et graphismes sont faits à la main.

Les données sont compressées avec l’algo ByteKiller, répandu sur Amiga, économe en RAM.

La VM est impressionnante agit comme une vrai machine : 64 threads, 256 registres, 29 instructions / 200+ opcodes. Olivier est rentré dans les détails de l’implémentation des opcodes et de leur conception.

Le moteur vidéo utilise des framebuffers avec 4 pages (2 backgrounds + 2 fenêtres principales, 2 actives et 2 inactives). Les polygones sont hiérarchisés dans des “bounding boxes” pour gérer l’affichage et les collisions. Les backgrounds, trop complexes pour être calculés en temps réel, sont pré-dessinés et mis en “cache”.

Difficile de tout retranscrire, Olivier nous a montré 1001 autres annecdotes sur les optimisations et autres astuces malines dans ce jeu. Olivier n’avait plus de temps pour nous montrer sa réimplémentation du jeu en C++ (qui fonctionne dans un navigateur avec WASM, si je ne dis pas de bêtises).

Une vraie leçon d’ingénierie avec les contraintes de l’époque !

Communauté et remerciements

Comme toujours, le meilleur d’une conférence reste les rencontres.

Je retiens surtout les longues (très longues) discussions avec Horacio et Yannick de Clever Cloud. J’ai aussi enfin pris le temps de papoter avec Estelle, Geoffrey, Julien (x3, décidément 🙃), Valentin, Stéphane (x2), Aurélie, Florian, Jérôme, et sûrement plein d’autres que j’ai oubliés dans le “blur” de la conférence.

Un grand merci à l’équipe d’organisation de Touraine Tech pour cette édition 2026 réussie. Le passage sur 2 jours et le changement de lieu ont été de bonnes décisions. À l’année prochaine !

Créer un cluster Kubernetes sur Clever Cloud avec les apps Linux

Sat, 19 Jul 2025 13:00:00 +0200

Introduction

Après avoir testé les apps statiques chez Clever Cloud, j’ai voulu pousser plus loin l’exploration des nouvelles fonctionnalités.

Clever Cloud a en effet lancé récemment un nouveau type d’application : les apps Linux. Ces dernières permettent de déployer des applications génériques sur une machine Linux, sans runtime prédéfini. Un peu comme avoir sa propre VM, mais managée par Clever Cloud.

Du coup, pour “rigoler” (et par pure curiosité technique), j’ai décidé de créer un control plane Kubernetes complet sur ce type d’instance. Pourquoi ?

D’abord parce que je parle tout le temps de Kubernetes. Et ensuite, pour faire un petit clin d’œil aux copains de chez Clever Cloud : ils annoncent depuis des mois leur offre Kubernetes managée qui devrait sortir (soon™).

Et en poussant les runtimes Linux dans leurs retranchements, ça m’a permis de découvrir pas mal de fonctionnalités que (j’avoue) je ne connaissais pas chez Clever.

Disclaimer : ce projet est purement éducatif et expérimental. Ne l’utilisez pas, même pour un usage personnel !

Le projet : k8s-on-clever-linux

J’ai créé un dépôt GitHub dédié à ce projet : k8s-on-clever-linux.

Le principe est simple : déployer tous les composants du control plane Kubernetes (etcd, kube-apiserver, kube-controller-manager, kube-scheduler) comme des processus sur une app Linux Clever Cloud.

Le projet s’inspire fortement de mon tutoriel demystifions-kubernetes. Et d’ailleurs, pour tester le proof of concept, c’est ce que j’ai bêtement déroulé, pour valider la faisabilité.

Cependant, dans le cas de Clever, plutôt que de lancer tous les composants un par un en déroulant un script bash (ce qui est fait dans github.com/zwindler/demystifions-kubernetes), j’ai fait un poil plus rusé…

Découverte de Mise.

Mais d’abord un peu de contexte :

Clever Cloud platform provides a multi-runtime environment, including many tools to deploy and run your applications. The Linux runtime is a versatile solution to build and deploy any kind of application. The Mise package manager helps you to install and manage any supported dependencies Clever Cloud doesn’t provide by default such as Dart, Gleam, Zig for example.

Documentation officielle des Linux runtimes chez Clever Cloud

Déjà, ça parle d’un truc qui s’appelle Mise package manager. C’est quoi ça ?

Il s’agit d’un projet de Jeff Dickey (jdx.dev). Sur nos apps Linux, ça va nous permettre d’installer une partie des dépendances d’une part, et d’ordonnancer le lancement de commandes pour build, puis pour run notre projet dans l’instance Linux

mise.jdx.dev

Découpage de l’application

Maintenant qu’on en sait plus, voilà comment j’ai découpé l’application avec Mise :

Initialisation (mise.toml)

Même si tous les prérequis ne sont pas tous disponibles dans Mise, je peux quand même déléguer le téléchargement d’une partie d’entre eux, ce qui va alléger le script de téléchargement des dépendances par rapport à démystifions kubernetes. C’est toujours bon à prendre :

[tools]
cfssl = "latest"
etcd = "latest"
kubectl = "latest"
helm = "latest"

Phase de build (.mise-tasks/build)

Télécharge tous les binaires Kubernetes
Génère les certificats pour l’authentification des composants
Configure les paramètres statiques
Mise en cache : cette phase n’est exécutée que lors des changements de code

De cette manière, en cas de reboot de l’application, on ne perd pas les certificats et on gagne un peu de temps pour le redéploiement.

Phase de run (.mise-tasks/run)

Lancer tous les composants de notre control plane Kubernetes
Génère un bootstrap token pour ajouter des Nodes
Lance un serveur HTTP qui écoute sur le port 8080 et ne sert… rien.

Pourquoi un serveur HTTP ? Eh bien tout simplement parce que

Linux runtime only requires a CC_RUN_COMMAND to execute, with a working web application listening on 0.0.0.0:8080.

Si je ne mets rien en écoute sur le port 8080, Clever va logguer que mon app est en panne (alors que non).

Focus sur Mise pour installer les dépendances

Concrêtement, comment ça se présente quand on lance une app dans Clever Cloud avec un mise.toml ?

Ben tout simplement comme ça :

2025-07-20T15:54:04.304Z mise etcd@3.6.2 install
2025-07-20T15:54:05.302Z mise etcd@3.6.2 download etcd-v3.6.2-linux-amd64.tar.gz
2025-07-20T15:54:06.403Z mise etcd@3.6.2 checksum etcd-v3.6.2-linux-amd64.tar.gz
2025-07-20T15:54:06.422Z mise etcd@3.6.2 extract etcd-v3.6.2-linux-amd64.tar.gz
2025-07-20T15:54:06.705Z mise etcd@3.6.2 ✓ installed

La liste des tools disponibles avec mise est ici :

mise.jdx.dev/registry

Et on peut remarquer que les tools viennent de différentes sources telles qu’aqua, pipx, ubi, asdf… Ça me donne envie de tester ça pour les dépendances qui me manquent donc attendez-vous à un prochain article sur le sujet :).

Mais… ils sont où les binaires du control plane de Kubernetes ?

Initialement, j’avais mis tout ça dans la phase de run. Sauf que David m’a proposé de découvrir une autre fonctionnalité de Clever Cloud que je n’avais jamais utilisée : les Workers.

Les Workers sont des processus en arrière-plan qui tournent en parallèle de votre application principale.

Pour notre cluster Kubernetes, c’est parfait ! Plutôt que de lancer tous les composants dans un script bash, chaque composant du control plane devient un worker dédié :

Worker 0: ./run-scripts/start-etcd.sh
Worker 1: ./run-scripts/start-kube-apiserver.sh
Worker 2: ./run-scripts/start-kube-controller-manager.sh
Worker 3: ./run-scripts/start-kube-scheduler.sh
Worker 4: ./run-scripts/post-boot.sh - bootstrap tokens, RBAC, worker scripts

Avec en bonus la possibilité de configurer le comportement de redémarrage :

CC_WORKER_RESTART=on-failure (par défaut) : redémarre seulement en cas d’erreur
CC_WORKER_RESTART=always : redémarre toujours
CC_WORKER_RESTART_DELAY=1 : délai en secondes avant redémarrage

Installation et configuration

Bon, clairement, cette partie n’est pas la plus user-friendly du tutoriel. Si vous voulez plus de détails sur ce qui est fait et pourquoi, vous pouvez aller jeter un œil directement sur le dépôt github.com/zwindler/k8s-on-clever-linux.

Les grandes étapes sont :

Créer l’app Linux clever create --type linux --github zwindler/k8s-on-clever-linux
Configuration de la redirection TCP

Linux runtime only requires a CC_RUN_COMMAND to execute, with a working web application listening on 0.0.0.0:8080.

Pour rappel, Clever Cloud s’attend à ce qu’on expose une app en HTTP non sécurisé sur le port 8080. Sauf que moi, je veux exposer l’API server Kubernetes en HTTPS. On va donc activer la “redirection TCP” : Clever Cloud attribue un port aléatoire (dans les 5XXX) qui redirige vers le port 4040 de votre application (et donc je dois dire à l’API server de ne pas écouter sur le 6443, mais 4040) :

$ clever tcp-redirs add --namespace default
Successfully added tcp redirection on port: 5131

Configuration du domaine

Une fois le port TCP connu, on peut configurer notre domaine.

clever domain add k8soncleverlinux.domain.org

Dans mon cas, l’API server sera accessible sur le domaine k8soncleverlinux.zwindler.fr et sur le port 5131. Comme ces deux valeurs seront différentes pour vous, j’ai vite codé un script qui permet de prendre les valeurs par défaut pour moi, mais vous permettre de les écraser si vous spécifiez des valeurs sur VOTRE app Clever Cloud :

clever env set K8S_DOMAIN k8soncleverlinux.zwindler.fr
clever env set K8S_TCP_PORT 5131

Je suis vraiment sympa.

Configuration des workers : pour ça j’ai fait un script ./setup-clever-workers.sh

Ce script configure 5 workers dont j’ai parlé plus haut et qui sont gérés par systemd.

Déploiement et test

Si tout s’est bien passé, l’app devrait correctement se lancer, Mise devrait lancer la phase de build (surtout télécharger les dépendances qui manquent), puis la phase de run (les dépendances connues de Mise, et les workers une fois que run se termine) :

2025-07-19T13:10:45.130Z Successfully deployed in 0 minutes and 18 seconds

Les workers en tâche de fond devraient démarrer tous les composants de notre control plane Kubernetes. Au bout de quelques secondes (1 minute max), on devrait avoir un control plane fonctionnel, et tout un tas de certificats et autres secrets.

Mais comment le tester ? Via SSH sur l’instance Clever Cloud ! Car oui, on peut SSH sur cette instance :)

$ clever ssh
Last login: Fri Jul 18 20:17:00 UTC 2025 on pts/0

$ kubectl version
Client Version: v1.33.2
Kustomize Version: v5.6.0
Server Version: v1.33.2

🎉 Ça marche ! On a bien un control plane Kubernetes qui tourne sur Clever Cloud !

Et si vous avez bien travaillé (c’est à dire correctement configuré votre domaine et le port), on peut même l’utiliser depuis l’extérieur en copiant le fichier admin.conf localement et en modifiant l’endpoint dans le YAML :

$ kubectl cluster-info
Kubernetes control plane is running at https://k8soncleverlinux.zwindler.fr:5131

Ajout d’un worker node

Deuxième hic dans mon histoire. Un control plane sans worker, c’est pas terrible.

Et je ne peux pas utiliser l’app de type Linux de chez Clever car je n’ai pas assez de privilèges pour changer les options kernel (routage) et installer containerd.

Mais je n’allais pas en rester là. Dans mon projet “Démystifions Kubernetes”, j’installe un worker directement sur la machine du control plane et j’utilise le admin.conf (cluster-admin) pour enrôler l’hôte courant en tant que Node.

C’est cracra, mais quand je suis en conf et que j’ai 20 minutes pour speedrun, c’est acceptable.

Ici, j’ai fait l’effort d’aller regarder comment faire pour enrôler des Nodes avec un bootstrap token et c’est assez intéressant.

La doc officielle de kube est plutôt bien faite et je ferai peut-être un article à part sur le sujet, c’est assez facile en fait, avec un flag à ajouter dans l’API server, quelques RBAC et un secret bien spécifique à générer.

https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/

Je vous épargne les détails, le projet va générer automatiquement un script pour ajouter des nodes externes :

2025-07-19T13:51:47.848Z ✓ Worker setup script generated: setup-worker-node.sh
2025-07-19T13:51:47.849Z 📋 Next steps:
2025-07-19T13:51:47.849Z 1. Copy setup-worker-node.sh to your external worker node
2025-07-19T13:51:47.849Z 2. (Optional) Edit NODE_NAME_OVERRIDE and NODE_IP_OVERRIDE if auto-detection is incorrect
2025-07-19T13:51:47.849Z 3. Ensure your worker node has sudo privileges and internet access
2025-07-19T13:51:47.849Z 4. Run the script on your worker node: sudo ./setup-worker-node.sh
2025-07-19T13:51:47.849Z 5. Check the node joined with: kubectl get nodes

# Script généré automatiquement
#!/bin/bash
# External Worker Node Setup Script for Kubernetes

API_SERVER_ENDPOINT="https://k8soncleverlinux.zwindler.fr:5131"
BOOTSTRAP_TOKEN="xxxxxx.xxxxxxxxxxxxxxxx"
# ... (configuration complète et certificats/secrets inclus)

Il suffit de copier ce script sur une VM Linux quelconque et de l’exécuter. Le script :

Installe containerd, kubelet, kube-proxy
Configure automatiquement l’authentification via bootstrap token
Démarre les services

✓ Worker node setup completed!

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
coucou1 NotReady <none> 13m v1.33.3

Le node apparaît en “NotReady” car il manque le plugin CNI. Flannel fonctionne parfaitement :

$ kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
coucou1 Ready <none> 30m v1.33.3

$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-flannel kube-flannel-ds-b65jg 1/1 Running 0 14m

Le cluster est fonctionnel 😎😎😎 !

On a maintenant un cluster Kubernetes complet avec control plane sur Clever Cloud et worker externe… Avant la sortie du kube managé de Clever.

Limitations et évolutions possibles

Le worker externe n’étant pas dans le réseau Clever Cloud, l’API server ne peut pas communiquer avec le kubelet (dans le sens api-server -> kubelet uniquement). Cela limite les fonctionnalités comme kubectl logs, kubectl exec, etc. Une solution possible serait d’utiliser les Network Groups de Clever Cloud pour créer un réseau privé sécurisé.

Si ce projet continue de m’amuser, plusieurs améliorations sont envisageables :

exploration des Network Groups (dont je viens de parler)
intégration de Kine. Cela permettrait d’utiliser les bases de données existantes de Clever Cloud (PostgreSQL, MySQL) comme DB pour Kubernetes, ce qui permettrait éventuellement de rendre cette install “HA” ce qui serait aussi débile que rigolo
création des packages aqua/ubi manquants (les binaires de kubernetes et cfssljson)

Conclusion

J’ai commencé ce projet comme une blague et j’ai finalement mis le doigt dans plein de petites fonctionnalités cools de chez Clever Cloud et dont j’ignorais l’existence (ou alors, que j’avais vu passer mais pas creusé).

Même si ça m’a pris quelques soirées, c’était super intéressant. La première itération a été très vite fonctionnelle et je me suis pris au jeu des améliorations successives.

Le code complet est disponible sur GitHub si vous voulez reproduire l’expérience ou contribuer !

Et vous, quels projets fous avez-vous envie de tester avec les apps Linux ? 😄 Moi, j’attends mon accès au k8s managé de Clever Cloud maintenant 😝 (comment ça, je suis un gros forceur ???)

Sécurité des mots de passes ESXi 5.X et 6.X

Mon, 06 Apr 2020 06:50:00 +0000

Pourquoi tu nous parles d’ESXi 5 ?

En voilà une bonne question ! Comme la majorité des blogueurs tech, j’ai dans mes brouillons une bonne 30aines d’articles en attente depuis plus ou moins longtemps (demandez à Seboss666 ce qu’il en pense).

Ca fait presque deux ans que je n’ai pas touché à un serveur VMware et pourtant, cette doc était pratiquement “prête à poster”. Tout comme “Intégrer un RHEL 7 dans un Active Directory avec Ansible” et “Mise en place de DRBD 8.4 sous CentOS 6.3”, mais c’est une autre histoire…

Et comme je n’aime pas gâcher, je “profite” du confinement pour déconfiner des vieilles docs avant qu’elles ne soient plus définitivement plus d’actualité (trop tard, vSphere 7 vient de sortir).

Les mots de passe dans vSphere

Un truc que je n’ai pas trouvé très très clair et qu’il est possible dans VMware d’avoir des comptes utilisateurs internes à l’ESXi avec des mots de passe plutôt bof complexes. En effet, il est tout à fait possible d’avoir un mot de passe avec que des lettres minuscules (voire même des chiffres ??) ce qui -nous sommes d’accord- est absolument catastrophique.

Lorsqu’on sait qu’on a parfois besoin de se loguer sur la console à distance et que l’émulation des terminaux KVM des constructeurs est une bouse intergalactique qui vous transforme votre AZERTY en un gloubiboulga à mis chemin entre le QWERTY et DVORAK, c’est parfois tentant…

Bref, j’ai voulu comprendre la logique de VMware pour l’acceptation de la longueur des mots de passe.

En fait, tout est expliqué, en fonction des versions, dans ce KB (lien mort, comme tout chez VMware).

Password quality-control PAM module

Je ne savais pas, mais VMware utilise tout simplement le module PAM Password quality-control PAM. Il permet de réaliser des contrôles simples sur la qualité des mots de passe choisi pour les utilisateurs Linux.

Globalement, on dispose, via ce module, de différents flags pour valider une politique simple de gestion de mot de passe sur un système Linux (car oui, ESXi c’est un Linux).

Les arguments retenus par VMware sont uniquement basés sur une taille minimale de mots de passe en fonction du nombre de type de caractères différents dont dispose ce mot de passe. Voilà à quoi ça ressemble :

password requisite /lib/security/$ISA/pam_passwdqc.so retry=N min=N0,N1,N2,N3,N4

Par défaut, voici ce que vous allez trouver dans vSphere 6 :

retry=3 : Un utilisateur a droit à trois tentatives pour entrer un mot de passe suffisant.
N0=12 : Le mot de passe comportant des caractères d’une seule classe doit contenir au moins 12 caractères.
N1=9 : Le mot de passe comportant des caractères de deux classes doit contenir au moins neuf caractères, mais qui n’est pas éligibles aux conditions des passphrases.
N2=8 : Le mot de passe respecte les conditions des passphrases. Il comporte des caractères de deux classes et doit contenir au moins huit caractères.
N3=7 : Le mot de passe comportant des caractères de trois classes doit contenir au moins sept caractères.
N4=6 : Le mot de passe comportant des caractères des quatre classes doit contenir au moins six caractères.

Procédure pour modifier la politique de sécurité

Si pour une raison ou pour une autre, vous souhaitez modifier ces paramètres (pour les durcir, hein !), voici la marche à suivre :

Connectez-vous au Shell ESXi et obtenez les privilèges root.
Ouvrez le fichier passwd avec un éditeur de texte.

vi /etc/pam.d/passwd

Modifiez la ligne suivante :

password requisite /lib/security/$ISA/pam_passwdqc.so retry=3 min=disabled,20,20,15,10

Cette commande vous permettra de désactiver la possibilité d’ajouter des utilisateurs dans ESXi dont les mots de passe n’ont qu’une classe de caractères et de complexifier fortement les autres types de mots de passe.

Il existe de nombreux autres paramètres. Je vous invite à aller lire la page man de ce module pour améliorer encore la sécurité des mots de passe dans vos ESXi.

Bonus GUI pour ESXi 6.0

Si vous êtes allergique à la console jaune et noire d’ESXi (ou que vous n’avez pas la main sur un KVM), sachez que depuis ESXi 6.0, il est possible de modifier directement les valeurs du module PAM depuis la console vSphere. Ça se passe dans les options avancées de l’hôte (cf cet article de Vladan).

Password Complexity Rules – change here where In previous versions of ESXi, password complexity changes had to be made by hand-editing the /etc/pam.d/passwd file on each ESXi host. In vSphere 6.0 now this can be done by adding an entry in Host Advanced System Settings, enabling centrally managed setting changes for all hosts in a cluster.

Ouah, cébo !

Sources

VMware KB 1012033 (lien mort, comme tout chez VMware)
Doc vSphere 5, en français (lien mort, comme tout chez VMware)
Page man de pam_passwdqc
Vladan : ESXi 6.0 Security and Password Complexity Changes

Transparent Hugepages : mesurer l’impact sur les performances

Mon, 24 Feb 2020 07:30:00 +0000

Encore les Transparent Hugepages ?

Il y a quelques jours, j’ai posté un article pour vous aider à désactiver les Transparent Hugepages.

A là suite de ça, Seboss666 (qui tient un super blog bien Geek/sysadmin comme j’aime) m’a fait remarquer en commentaire que j’expliquais surtout comment désactiver les THP. Mais je n’ai pas beaucoup parlé d’à quoi ça sert (à part que c’est mal aimé, comme SELinux) et si ça a vraiment un impact sur les perfs.

Il m’a passé un article hyper intéressant, en anglais, sur le sujet. Comme je ne l’aurais pas mieux écris moi-même ET que le but du blog est d’être une ressource francophone, j’ai donc proposé à l’auteur, Alexandr Nikitin, de le traduire en français. Le voilà donc.

Introduction

TL;DR ce post a pour but d’expliquer en un mot ce que sont les Transparent Hugepages (THP), décrire les techniques qui seront utilisées pour mesurer leur impact sur les performances et enfin, montrer leur effet sur une application réelle.

Il est inspiré par un thread a propos des Transparent Huge Pages sur le “Mechanical Sympathy group”. Ce thread expose les pièges, les problématiques de performances ainsi que l’état actuel dans les dernières versions du kernel. Une grosse quantité d’information peut y être trouvé.

En général, vous allez trouver beaucoup de recommendations sur Internet à propos des Transparent Hugepages. La plupart d’entre eux vous diront de désactiver totalement les THP, comme Oracle Database (lien mort), MongoDB, Couchbase (lien mort, j’utilise Internet Archive), MemSQL (lien mort), NuoDB. Certains logiciels utilise la fonctionnalité, comme par exemple PostgreSQL (la fonctionnalité hugetlbpage, pas exactement les THP) et Vertica. Il existe beaucoup de retours d’expériences de professionnels qui ont eu à se battre contre des freeze de leur système et l’ont “corrigé” simplement en désactivant les THP. 1, 2, 3 (lien mort, j’utilise Internet Archive), 4, 5, 6. Toutes ces histoires tendent à propager une vision faussée et le préjugé que cette fonctionnalité est dangereuse.

Malheureusement, je n’ai pas trouvé de post qui mesure ou montre comment mesurer l’impact et les conséquences d’activer ou de désactiver cette fonctionnalité. C’est ce que ce post va tenter de répondre.

Les Transparent Hugepages en bref (presque)

Pour fonctionner, presque toutes les applications et les systèmes d’exploitation nécessitent de la mémoire “virtuelle”. La mémoire virtuelle de tous les logiciels est ensuite mappée dans la mémoire physique. Ce mapping est géré par le système d’exploitation, qui maintient une structure de donnée en RAM (page table). Pour passer de l’adresse virtuelle à l’adresse physique (page table walking), on utilise un composant du CPU (la MMU). En plus de servir de table de traduction, la MMU sert également de cache des pages récemment utilisées. On appelle ce cache le Translation lookaside buffer (TLB).

Lorsqu’une adresse virtuelle doit être traduite dans une adresse physique, on cherche d’abord dans le TLB. Si un résultat est trouvé (TLB hit), l’adresse physique est retournée et l’accès à la mémoire peut continuer. Cependant, si on ne trouve pas de résultat (TLB miss), la MMU va devoir rechercher le mapping de l’adresse dans la table de pages (page table) si il existe.

Ce processus de “page table walk” est coûteux en temps car il peut nécessiter plusieurs accès à la mémoire (cependant, avec de la chance on peut retrouver la page mémoire dans un des caches L1/L2/L3 du CPU). Cependant, on ne peut pas non plus compter tout le temps sur le TLB car sa taille est limitée (généralement quelques centaines de pages, au maximum).

Les systèmes d’exploitation gèrent la mémoire virtuelle en utilisant des pages (des blocks contigus de mémoire). Généralement, la taille d’une page mémoire est de 4 Ko. Petite règle de trois, 1 Go de RAM équivaut à 256000 pages, et 128 Go à 32,7 millions de pages. Clairement, on ne va pas pouvoir tout stocker dans le TLB et nous allons donc souffrir de problèmes de performances à cause des “TLB miss”. Il y a deux façons d’améliorer cette situation. La première est d’augmenter la taille du TLB. Cependant, c’est coûteux et l’impact n’est pas significatif, surtout sur les systèmes disposant d’une très grande quantité de RAM. La seconde consiste à augmenter la taille d’une page est ainsi, avoir moins de pages à mapper. Les OS et les CPUs modernes sont typiquement capable de supporter des pages “larges” de 2 Mo, voire même de 1 Go. Ainsi, avec des pages de 2 Mo, 128 Go de RAM devient seulement 64000 pages.

Ce n’est pas pour rien que Linux supporte les Transparent Hugepages. C’est une optimisation ! Cela permet de gérer un grand nombre de pages de manière automatique et transparente pour les applications. Les bénéfices sont évidents : pas de modification à faire du coté des application, le nombre de “TLB miss” est réduit, le “page table walking” devient moins coûteux. Cette fonctionnalité peut être découpée en deux parties : allocation et maintenance.

Le THP fonctionne de la même manière pour ce qui est de l’allocation de la mémoire et nécessite que le système d’exploitation trouve des blocs alignés et contigus de mémoire. Dans ce cas précis, il souffre également des mêmes problèmes que les pages de mémoire classiques, à savoir la fragmentation. Si l’OS ne sait pas trouver de blocs de mémoire continus, il va essayer de “compacter”, réclamer les partions inutilisées ou “page out” les autres pages. Ce processus est couteux et peut provoquer de grosses latences (jusqu’à quelques secondes). Heureusement, ce problème a été adressé dans la version 4.6 du kernel Linux (avec l’option defer) ; l’OS retourne dans le mode classique (page de 4K) si jamais il ne trouve pas de place pour une hugepage.

La deuxième partie est la maintenance. Si une application ne modifie ne serait ce qu’un seul octet de mémoire, elle va consommer la taille d’une page entière, à savoir 2 Mo si on utilise des hugepages, ce qui est clairement un gaspillage de mémoire vive. Pour palier à ça, il existe une tâche de fond qui s’appelle khugepaged. Ce processus scanne les pages et essaye de défragmenter et concaténer toutes les pages presque vides dans une seule page. Cependant, même si c’est une tâche de fond, elle va bloquer les pages sur lesquelles elle fonctionne, ce qui peut aussi provoquer des pic de latence. Un dernier problème reste qu’il est parfois nécessaire de découper les grosses pages, car tous les composants de l’OS ne supportent pas les hugepages. C’est le cas de la swap par exemple. L’OS doit alors découper les grosses pages en plus petites pour ces composants là. Encore une fois, cette opération peut dans certain cas dégrader les performances et augmenter la fragmentation.

Le meilleur endroit pour apprendre comment fonctionnent les Transparent Hugepage est évidemment la documentation officielle du Kernel Linux. Cette fonctionnalité dispose de plusieurs éléments de configuration ainsi que des flags pour modifier son comportement. Ils évoluent avec le Kernel lui même.

Comment le mesurer ?

C’est probablement la partie la plus importante de ce post. Basiquement, il y a deux façon de mesurer l’impact de cette fonctionnalité : les CPU counters et les kernel functions.

CPU counters

Commençons par les CPU counters. J’utilise perf, qui est un outil génial et simple pour réaliser ce genre de mesures. Perf dispose nativement d’alias pour les événements du TLB : dTLB-loads, dTLB-load-misses pour les hit et les miss en load; dTLB-stores, dTLB-store-misses (idem mais pour les stores).

[~]# perf stat -e dTLB-loads,dTLB-load-misses,dTLB-stores,dTLB-store-misses -a -I 1000
# time counts unit events
1.006223197 85,144,535 dTLB-loads
1.006223197 1,153,457 dTLB-load-misses # 1.35% of all dTLB cache hits
1.006223197 153,092,544 dTLB-stores
1.006223197 213,524 dTLB-store-misses
...

Et la même chose pour les instructions (iTLB-load, iTLB-load-misses).

[~]# perf stat -e iTLB-load,iTLB-load-misses -a -I 1000
# time counts unit events
1.005591635 5,496 iTLB-load
1.005591635 18,799 iTLB-load-misses # 342.05% of all iTLB cache hits
...

En réalité, perf supporte seulement un petit sous ensemble de tous les événements alors que les CPUs ont des centaines de compteurs pour évaluer la performance. Pour les CPUs Intels par exemple, on peut trouver la liste de tous les compteurs disponibles sur le site Intel Processor Event Reference, dans le Intel® 64 and IA-32 Architectures Developer’s Manual: Vol. 3B ou bien encore dans les sources du Kernel Linux. Le manuel du développeur contient également des codes d’événements que nous devons passer pour analyser les performances.

Si on regarde les compteurs relatifs au TLB, voilà ce qu’on peut trouver d’intéressant :

Mnemonic	Description	Event Num.	Umask Value
DTLB_LOAD_MISSES.MISS_CAUSES_A_WALK	Misses in all TLB levels that cause a page walk of any page size.	08H	01H
DTLB_STORE_MISSES.MISS_CAUSES_A_WALK	Miss in all TLB levels causes a page walk of any page size.	49H	01H
DTLB_LOAD_MISSES.WALK_DURATION	This event counts cycles when the page miss handler (PMH) is servicing page walks caused by DTLB load misses.	08H	10H
ITLB_MISSES.MISS_CAUSES_A_WALK	Misses in ITLB that causes a page walk of any page size.	85H	01H
ITLB_MISSES.WALK_DURATION	This event counts cycles when the page miss handler (PMH) is servicing page walks caused by ITLB misses.	85H	10H
PAGE_WALKER_LOADS.DTLB_MEMORY	Number of DTLB page walker loads from memory.	BCH	18H
PAGE_WALKER_LOADS.ITLB_MEMORY	Number of ITLB page walker loads from memory.	BCH	28H

Perf supporte le compteur *MISS_CAUSES_A_WALK via un alias. Mais nous devrons trouver l’identifiant numérique des autres événements pour les passer en arguments. Point important, les numéros d’événements et les valeurs umask associées dépendent de chaque CPU. Par exemple, la liste ci dessus est spécifique à l’architecture Intel Haswell ! Il vous sera nécessaire d’adapter ces codes à votre CPU.

Une des métriques clé est le nombre de cycle CPU passés à faire du page table walking :

[~]# perf stat -e cycles \
> -e cpu/event=0x08,umask=0x10,name=dcycles/ \
> -e cpu/event=0x85,umask=0x10,name=icycles/ \
> -a -I 1000
# time counts unit events
1.005079845 227,119,840 cycles
1.005079845 2,605,237 dcycles
1.005079845 806,076 icycles
...

Une autre métrique importante est le nombre de lecture mémoire qui causent des TLB miss ; ces lectures ne profitent pas du cache CPU et sont donc coûteuses :

[~]# perf stat -e cache-misses \
> -e cpu/event=0xbc,umask=0x18,name=dreads/ \
> -e cpu/event=0xbc,umask=0x28,name=ireads/ \
> -a -I 1000
# time counts unit events
1.007177568 25,322 cache-misses
1.007177568 23 dreads
1.007177568 5 ireads
...

Kernel functions

Une autre façon surpuissante de mesurer l’impact des THP sur les performances et la latence est d’utiliser les fonctions de tracing/probing du Kernel Linux. J’utilise SystemTap pour ça, qui est un outil pour instrumenter dynamiquement les systèmes Linux en production.

La première fonction intéressante pour le cas qui nous intéresse est __alloc_pages_slowpath. Elle est exécutée lorsqu’il n’y a pas de bloc contigu de mémoire vive disponible lors d’une allocation. A son tour, cette fonction appelle la fonction de “récupération” et de “compaction” des pages, qui je le rappelle est une opération très couteuse qui peut engendrer des pics de latence.

La seconde fonction intéressante est khugepaged_scan_mm_slot. Elle est exécutée en tâche de fond par le thread khugepaged du Kernel. Ce thread scanne les hugepages et essaye de les compacter en une seule.

J’utilise un script SystemTap pour mesurer le temps d’exécution d’une fonction. Ce script stocke tous les temps d’exécution en microsecondes et affiche périodiquement un histogramme. Il ne consomme que quelques Mo par heure, en fonction du nombre d’exécutions. Le premier argument est la sonde à utiliser, le second est un nombre (en ms) pour afficher les statistiques.

#! /usr/bin/env stap
global start, intervals
probe $1 { start[tid()] = gettimeofday_us() }
probe $1.return
{
t = gettimeofday_us()
old_t = start[tid()]
if (old_t) intervals <<< t - old_t
delete start[tid()]
}
probe timer.ms($2)
{
if (@count(intervals) > 0)
{
printf("%-25s:\n min:%dus avg:%dus max:%dus count:%d \n", tz_ctime(gettimeofday_s()),
@min(intervals), @avg(intervals), @max(intervals), @count(intervals))
print(@hist_log(intervals));
}
}

Voici un exemple avec la fonction __alloc_pages_slowpath :

[~]# ./func_time_stats.stp 'kernel.function("__alloc_pages_slowpath")' 1000
Thu Aug 17 09:37:19 2017 CEST:
min:0us avg:1us max:23us count:1538
value |-------------------------------------------------- count
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 549
1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 541
2 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 377
4 |@@@@ 54
8 |@ 12
16 | 5
32 | 0
64 | 0
...

Il est également intéressant de savoir observer l’état général de l’OS. Un bon exemple peut être la fragmentation de la mémoire. /proc/buddyinfo est un outil utilise pour aider au diagnostic dans ce genre de cas. Buddyinfo va nous donner des pistes pour estimer la taille maximale que l’on peut allouer sans risque, ou pourquoi la précédent allocation a échoué par exemple. De même, on peut aussi trouver des informations utiles dans /proc/pagetypeinfo.

cat /proc/buddyinfo
cat /proc/pagetypeinfo

Vous pouvez en apprendre plus en lisant la documentation officielle (lien mort, j’utilise Internet Archive) ou alors en lisant cet article.

JVM

La JVM supporte les Transparent Hugepages via l’ajout de l’option -XX:+UseTransparentHugePages. Cependant, on aura alors un message d’avertissement contre de possibles problèmes de performance :

-XX:+UseTransparentHugePages On Linux, enables the use of large pages that can dynamically grow or shrink. This option is disabled by default. You may encounter performance problems with transparent huge pages as the OS moves other pages around to create huge pages; this option is made available for experimentation.

Il est intéressant d’activer l’usage des large pages pour le “Metaspace” :

-XX:+UseLargePagesInMetaspace Use large page memory in metaspace. Only used if UseLargePages is enabled.

De plus, utiliser l’option -XX:+AlwaysPreTouch avec les hugepages peut être une bonne idée. Cela permet de réallouer toute la mémoire physique utilisé par le tas (heap) et ainsi éviter une surcharge supplémentaire due à l’initialisation ou à la compaction. Cependant, cela induira une augmentation du temps nécessaire pour initialiser la JVM.

-XX:+AlwaysPreTouch Enables touching of every page on the Java heap during JVM initialization. This gets all pages into the memory before entering the main() method. The option can be used in testing to simulate a long-running system with all virtual memory mapped to physical memory. By default, this option is disabled and all pages are committed as JVM heap space fills.

Aleksey Shipilёv montre l’impact sur la performance dans son article de post JVM Anatomy Park #2: Transparent Huge Pages.

Un exemple de la vie réelle : une JVM très chargée

Regardons maintenant quel impact ont réellement les Transparent Hugepages sur une application réelle. Prenons une application lancée dans une JVM : un serveur TCP basé sur netty et recevant un trafic important. Le serveur reçoit jusqu’à 100k requêtes par secondes, analyse chaque requête, effectue un appel réseau à une base de données pour chacun des appels, fait un certain nombre de calculs dessus, puis retourne un réponse. L’application en question possède une heapsize de 200 Go. Les mesures ont été réalisées sur des serveurs de production, ainsi que la charge réelle de production. Les serveurs n’étaient pas surchargés et recevaient 50% du nombre maximal de requêtes qu’ils étaient capables de traiter.

Transparent Hugepages désactivées

Désactivons les THP :

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

La première chose à faire et de mesurer les TLB misses. Ici on a environ 130 millions de TLB misses. Le ratio Miss/Hit est de 1% (ce qui ne semble pas énorme, au premier abord).

[~]# perf stat -e dTLB-loads,dTLB-load-misses,iTLB-load-misses,dTLB-store-misses -a -I 1000
# time counts unit events
...
10.007352573 9,426,212,726 dTLB-loads
10.007352573 99,328,930 dTLB-load-misses # 1.04% of all dTLB cache hits
10.007352573 26,021,651 iTLB-load-misses
10.007352573 10,955,696 dTLB-store-misses
...

Cependant, regardons plus précisément combien nous ont coûté en temps CPU ces TLB misses :

[~]# perf stat -e cycles \
> -e cpu/event=0x08,umask=0x10,name=dcycles/ \
> -e cpu/event=0x85,umask=0x10,name=icycles/ \
> -a -I 1000
# time counts unit events
...
12.007998332 61,912,076,685 cycles
12.007998332 5,615,887,228 dcycles
12.007998332 1,049,159,484 icycles
...

Oui, vous avez bien vu ! Plus de 10% des cycles CPUs sont utilisés pour parcourir la page table.

Le compteur suivant montre que nous avons 1 million de lectures RAM causées par des TLB misses (sachant que chacunes de ces lectures coûtent 100 ns chacunes) :

[~]# perf stat -e cpu/event=0xbc,umask=0x18,name=dreads/ \
> -e cpu/event=0xbc,umask=0x28,name=ireads/ \
> -a -I 1000
# time counts unit events
...
6.003683030 1,087,179 dreads
6.003683030 100,180 ireads
...

Tous les nombres que je viens de vous montrer sont intéressants, mais ils ne sont pas vraiment “exploitables”. Les métriques les plus importantes pour un développeur d’application sont les métriques de l’application elle-même. Regardons donc comment la métrique de la latence end-to-end de l’application. Voilà les mesures (en microsecondes) qui ont été récoltées pendant quelques minutes :

"max" : 16414.672,
"mean" : 1173.2799067016406,
"min" : 52.112,
"p50" : 696.885,
"p75" : 1353.116,
"p95" : 3769.844,
"p98" : 5453.675,
"p99" : 6857.375,

Transparent Hugepages activées

Maintenant on va pouvoir commencer à faire des comparaisons ! Activons les THP :

echo always > /sys/kernel/mm/transparent_hugepage/enabled
echo always > /sys/kernel/mm/transparent_hugepage/defrag # consider other options too

Et lançons la JVM avec les options -XX:+UseTransparentHugePages, -XX:+UseLargePagesInMetaspace et -XX:+AlwaysPreTouch.

La première métrique que nous avions collecté (les TLB misses) ont été divisés par 6, passant de 130 millions à environ 20 millions. Mathématiquement, le ratio miss/hit tombe de 1% à 0,15%. Voici les nombres exacts :

[~]# perf stat -e dTLB-loads,dTLB-load-misses,iTLB-load-misses,dTLB-store-misses -a -I 1000
# time counts unit events
1.002351984 10,757,473,962 dTLB-loads
1.002351984 15,743,582 dTLB-load-misses # 0.15% of all dTLB cache hits
1.002351984 4,208,453 iTLB-load-misses
1.002351984 1,235,060 dTLB-store-misses

Les cycles CPU passés à parcourir la page table ont également diminué d’un facteur 5, d’environ 6,7 milliards à 1,3 milliards. Cette fois ci, nous avons donc utilisé seulement 2% de notre CPU à réaliser du “page table walking” :

[~]# perf stat -e cycles \
> -e cpu/event=0x08,umask=0x10,name=dcycles/ \
> -e cpu/event=0x85,umask=0x10,name=icycles/ \
> -a -I 1000
# time counts unit events
...
8.006641482 55,401,975,112 cycles
8.006641482 1,133,196,162 dcycles
8.006641482 167,646,297 icycles
...

Et enfin, le nombre de lecture en RAM a diminué de 1 million à 350k

[~]# perf stat -e cpu/event=0xbc,umask=0x18,name=dreads/ \
> -e cpu/event=0xbc,umask=0x28,name=ireads/ \
> -a -I 1000
# time counts unit events
...
12.007351895 342,228 dreads
12.007351895 17,242 ireads
...

Tout ça c’est bien beau, mais, une fois encore, les nombres qui vont le plus nous intéresser, c’est l’effet réel que ça va avoir sur notre application. Voici les chiffres de la latence end-to-end de l’application :

"max" : 16028.281,
"mean" : 946.232869010599,
"min" : 41.977000000000004,
"p50" : 589.297,
"p75" : 1080.305,
"p95" : 2966.102,
"p98" : 4288.5830000000005,
"p99" : 5918.753,

La différence entre les deux runs sur les 95 percentiles est quasiment de 1 milliseconde ! Voici ce que cela représente visuellement :

Source : https://alexandrnikitin.github.io/blog/images/transparent-hugepages-measuring-the-performance-impact/grafana.png

Nous venons donc de mesurer l’amélioration apportée par l’activation des Transparent Hugepages. Cependant, nous savons que l’activation des THP peut avoir un impact sur les performances (à cause de l’overhead de la “maintenance” que nous avons expliqué plus haut) ainsi que les risques de pic de latence. Nous devons donc également les mesurer. Regardons le thread kernel khugepaged qui s’occupe de la défragmentation des hugepages. La mesure qui suit a été réalisée sur une durée d’environ 24 heures. Comme vous pouvez le constater, le temps maximum d’exécution est de 6 millisecondes et il y a de nombreuses exécutions qui ont pris moins d’une milliseconde. Si ce processus est en tâche de fond, mais il bloque les pages concernées pendant qu’il travaille dessus. Voici l’histogramme :

[~]# ./func_time_stats.stp 'kernel.function("khugepaged_scan_mm_slot")' 60000 -o khugepaged_scan_mm_slot.log
[~]# tail khugepaged_scan_mm_slot.log
Thu Aug 17 13:38:59 2017 CEST:
min:0us avg:321us max:6382us count:10834
value |-------------------------------------------------- count
0 |@ 164
1 |@ 197
2 |@@@ 466
4 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 6074
8 |@@@@@@ 761
16 |@@ 318
32 | 65
64 | 13
128 | 1
256 | 3
512 |@@@ 463
1024 |@@@@@@@@@@@@@@@@@@ 2211
2048 | 85
4096 | 13
8192 | 0
16384 | 0

Une autre fonction important du kernel est __aloc_pages_slowpath. Cette fonction aussi peut provoquer des pics de latence si un block contigue de mémoire n’est pas disponible. Lors de la mesure, l’histogramme est bien meilleur ici. Le temps maximum d’allocation était de 288 microsecondes. Même en le faisant tourner pendant des heures voire même des jours, nous sommes devenus confiant dans le fait que cette fonctionnalité n’allait pas provoquer de longs pics de latence.

[~]# ./func_time_stats.stp 'kernel.function("__alloc_pages_slowpath")' 60000 -o alloc_pages_slowpath.log
[~]# tail alloc_pages_slowpath.log
Tue Aug 15 10:35:03 2017 CEST:
min:0us avg:2us max:288us count:6262185
value |-------------------------------------------------- count
0 |@@@@ 237360
1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 2308083
2 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 2484688
4 |@@@@@@@@@@@@@@@@@@@@@@ 1136503
8 |@ 72701
16 | 22353
32 | 381
64 | 7
128 | 105
256 | 4
512 | 0
1024 | 0

Alors comment se fait il que les Transparents Hugepages fonctionnent aussi bien dans ce cas précis ? D’abord, on remarque un amélioration significative de la performance car dans ce cas précis on travaille avec une grande quantité de RAM. De même, on ne remarque pas de pics de latences car il n’y a pas de surcharge en terme de RAM sur le serveur. Il y a beaucoup de RAM (256 Go), la JVM sait tirer partie des THP, pré-alloue la totalité des 200 Go de heap dès le démarrage et ne la redimensionne jamais.

Conclusion

Ne suivez pas aveuglément les recommandation que vous trouvez sur Internet ! Mesurez, mesurez, mesurez encore !

Les Transparent Hugepages sont une optimisation et qui peut avoir de réelles conséquences positives sur la performance, mais avec des inconvénients et des risques qui peuvent entrainer des conséquences imprévues. Le but de ce post était de donner les clés pour mesurer les gains potentiels et gérer les risques. Le Kernel Linux et ces fonctionnalités évoluent et certains des problèmes des THP ont été adressés dans les dernières versions, comme par exemple l’option “defer” de la défragmentation, qui permet à l’OS de repasser sur une allocation de taille normale, si jamais il n’est pas possible d’en allouer une large.

Note de zwindler : Encore merci à l’auteur (Alexandr Nikitin) pour son article, qui m’a appris beaucoup de choses !

Redis, MongoDB, RabbitMQ, désactiver les Transparent Huge Pages

Mon, 10 Feb 2020 07:30:00 +0000

Transparents Huge Pages

Les THP et moi, ça remonte à quelques années (i.e.n un brouillon qui traîne depuis longtemps); Mais j’ai de nouveau eu besoin de toucher aux Transparent Huge Pages il y a peu donc c’est une bonne occasion de m’y remettre.

Redis, MongoDB, RabbitMQ, Kafka… Tout ces logiciels vous demandent, à l’installation ou dans la documentation, de désactiver ce paramètre système de vos serveurs Linux.

01-07-2020 03:46:32.730 +0000 WARN ulimit - ulimits: This instance is running on a machine that has kernel transparent huge pages enabled. This can significantly reduce performance and is against best practices. Turn off kernel transparent huge pages using the method that is most appropriate for your Linux distribution. Même dmesg me dit de le désactiver :'(

Dans cet article, je vais vous montrer à quoi ça sert, mais surtout comment on va faire pour le désactiver (le plus proprement possible).

Mais au fait, c’est quoi ?

Avant de lui couper la chique, le mieux c’est quand même peut-être de savoir de quoi il s’agit avant de respecter les précos des éditeurs.

Note : Ca me fait penser à SELinux, la première chose qu’on nous demande de désactiver quand on installe un progiciel sur RHEL et qu’on connaît au final assez mal…

Pour faire bref, la gestion de la mémoire par le CPU passe par une couche d’abstraction : la mémoire est découpée en pages de taille fixe (par défaut 4ko) et le CPU garde une table de correspondance de ces pages dans la MMU.

Pour des raisons de performance, il peut être intéressant, sur nos systèmes récents ayant beaucoup de RAM, d’avoir des pages plus grosses pour faciliter le travail du CPU (aka des “huge pages”). Cependant, il est nécessaire de modifier le code de l’application pour tirer parti des HugePages. Arrive alors une autre couche d’abstraction, les Transparent Huge Pages. Vous avez deviné, pour faire ça de manière transparente !

Je vous met en bas de l’article quelques liens pour comprendre en détail de quoi on parle.

Oneshot

Maintenant qu’on sait ce que c’est, on peut le désactiver en tout quiétude.

Déjà, on va commencer par vérifier l’état de notre OS, pour savoir un peu où on en est au niveau des THP. Pour ça, un simple cat de /sys/kernel/mm/transparent_hugepage/enabled nous donnera l’info :

cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Il existe 3 valeurs possibles pour ce paramètre : always, madvise et never. always et never sont simples à comprendre, et pour ce qui est de madvise, il s’agit d’un paramètre intermédiaire qui dit que par défaut, les THP sont désactivées, mais que les applications peuvent utiliser un appel “madvise” pour allouer des THP dans la zone mémoire réservée pour ça.

Ici, on va donc vouloir désactiver les THP totalement (donc never).

Pour se faire, on peut simplement utiliser la commande suivante :

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Attention cependant, le paramètre ne sera pris en compte que jusqu’au prochain reboot.

Les méthodes classiques pour désactiver durablement les THP

A partir de là, on va vouloir le désactiver pour les prochains boots. On va donc devoir indiquer d’une manière ou d’une autre à l’OS qu’il faut désactiver ce paramètre, activé par défaut.

La plupart des logiciels vous conseillent de faire un service qui ne fait que ça et qui sera lancé au démarrage de votre machine (ex. vertica, couchbase, …).

Je suis pas fan, je trouve que modifier un paramètre au démarrage ne devrait pas se faire comme ça.

La façon la plus “propre” de le faire est probablement de modifier la configuration du bootloader (souvent GRUB). Si vous avez GRUB, c’est assez facile de le faire puisque c’est une option à ajouter dans le grub :

cat /etc/default/grub
[...]
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300"
GRUB_CMDLINE_LINUX=""
[...]
## APRES
cat /etc/default/grub
[...]
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300 transparent_hugepage=never"
GRUB_CMDLINE_LINUX=""

Cependant, cette méthode nécessite de reconstruire votre fichier grub (avec grub2-mkconfig) donc j’imagine que c’est pour cela que cette méthode n’est pas mise en avant.

Une méthode alternative pour désactiver les transparent Huge Pages

Si vous ne vous sentez pas de modifier votre bootloader et que vous n’aimez pas, comme moi, l’idée de faire un service pour faire un echo au boot, il reste une dernière possibilité.

apt install sysfsutils
echo "kernel/mm/transparent_hugepage/enabled = never" >> /etc/sysfs.conf
echo "never" >> /sys/kernel/mm/transparent_hugepage/enabled

L’avantage, c’est que, contrairement à la modif du GRUB, ça va être ultra simple du coup d’automatiser ça avec Ansible. Je vais pouvoir intégrer la modification dans mes playbooks d’installation des logiciels cités en début d’article !

---
- hosts: all
become: yes
tasks:
- name: "Install sysfsutils"
apt:
name: "{{item}}"
state: present
loop:
- sysfsutils
- name: "Disable permanently Transparent Huge Pages"
lineinfile:
path: /etc/sysfs.conf
line: kernel/mm/transparent_hugepage/enabled = never
- name: "Disable THP for this boot"
shell: "echo 'never' >> /sys/kernel/mm/transparent_hugepage/enabled"

Et voilà :D

Sources

Erreur multipath « Path not correctly configured for failover »

Wed, 24 May 2017 14:15:45 +0000

Path not correctly configured for failover

Il y a quelque temps, nous avons du décommissionner une vieille baie HP EVA (qui nous coutait plus cher en maintenance que d’acquérir une baie neuve) et migrer les LUNs vers une baie EMC VNX, elle encore sous maintenance. Cependant, lorsque la migration a été faite, le consultant qui s’est chargé de reconfigurer multipath pour migrer d’une baie à l’autre l’a un peu fait « rapidement ».

Quelques mois plus tard, lors d’une maintenance classique sur une des baies EMC, de grosses anomalies ont été détectés. Lors de la coupure d’un contrôleur pour mise à jour, certains serveurs hébergeant une partie de nos progiciels, encore sous Redhat 4, se bloquaient au niveau I/O au lieu de basculer sur les chemins encore disponibles. L’occasion rêvée pour refaire un peu de multipath !

Dans cet article, je vais donc passer en revue quelques unes des erreurs que j’ai pu rencontrer, et comment les corriger.

Liloo Dallas Multipath ?

D’abord un bref rappel.

Pour ceux qui ne connaissent pas multipath, il s’agit d’un module de Linux qui permet de gérer les chemins multiples vers une même disque. On l’utilise sur des réseaux de stockage d’entreprises qui disposent de plusieurs niveaux de tolérance aux pannes.

Chacun des chemins SAN menant à un même disque (LUN A sur le schéma ci dessus) sont indexés côté OS par leur propre special device du type /dev/sd[n] (4 chemins : sde, sdf, sdg et sdh dans l’exemple).

On ne peut pas directement les utiliser puisqu’on utiliserait dans ce cas là qu’un seul des chemins disponibles. Et écrire en direct sur 2 chemins menant vers un même disque en même temps serait catastrophique.

Heureusement, Multipath détecte de lui même (via l’UUID du disque) que les chemins sont en fait un même périphérique et créé pour nous un fichier spécial /dev/dm-[n] qui permet de pointer vers le disque via l’ensemble de ses chemins.

Vérifier le plus évident

Initialement, l’anomalie n’était pas visible car les vérifications de l’état de multipath n’avaient été faites qu’avec le niveau de détail standard : les chemins sont bien déclarés, visibles et fonctionnels… RAS de ce côté.

# multipath -l
mpath9 (36006016067302f00e4588d06345ee111)
[size=100 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [active]
\_ 0:0:5:3 sdd 8:48 [active]
\_ 1:0:5:3 sdh 8:112 [active]
\_ round-robin 0 [enabled]
\_ 0:0:4:3 sdc 8:32 [active]
\_ 1:0:4:3 sdg 8:96 [active]
[…]

De même les modules multipath étaient bien chargés dans le kernel :

# lsmod |grep dm
dm_mirror 32585 0
dm_round_robin 5185 1
dm_emc 7745 1
dm_multipath 22865 3 dm_round_robin,dm_emc
dm_mod 76585 7 dm_mirror,dm_multipath

Cependant, le démon multipathd qui permet de gérer les bascules de chemins est lui hors service…

# service multipathd status
multipathd est arrêté

ATTENTION : Le démarrage du démon multipath peut éventuellement provoquer une coupure des chemins, ce qui va planter le serveur et les traitements en cours. Il faut donc bien prendre garde que le serveur ne soit pas utilisé lors de son activation.

chkconfig multipathd on
chkconfig --add multipathd

Doublons dans les user-friendly device names

Une fois les problèmes basiques réglés, nous avons remarqué que le consultant en question ne s’était pas trop embêté avec les user-friendly names. Voici ce que la commande suivante renvoyait :

# multipath -v2
remove: mpath9 (dup of mpath2)
mpath9: map in use
remove: mpath23 (dup of mpath2)
mpath23: map in use

Bien que non bloquant, ceci est clairement peu élégant ;-).

Comme je l’explique plus haut, multipath agrège les /dev/sd[n] en un seul et unique /dev/dm-[n]. Cependant, il est déconseillé d’utiliser directement le fichier /dev/dm-[n]. En effet, tout comme les /dev/sd[n] (que ce soit dans le cadre de multipath ou pas d’ailleurs), les fichiers /dev/dm-[n] sont susceptibles de changer au cours de la vie du serveur ! De quoi avoir une mauvaise surprise après maintenance…

Pour résoudre ce problème, plusieurs solutions sont conseillées. Soit on utilise le WWID du disque qui est garanti unique, soit on utilise le device mapper qui transpose ce dm-[n] un user-friendly name du type /dev/mpath[n].

Dans le cas présent, au gré de la migration, les WWID avaient générés plusieurs mpath pour un même disque et il n’y avait plus de cohérence !

Pour régler le problème, le plus simple est de couper toutes les applications, puis d’effacer la configuration (pas les données, hein, juste les chemins et la table de correspondance) pour repartir de zéro. On récupère les WWID de chaque disques, puis on supprime tous les chemins courants avec les commandes suivantes :

multipath -ll #affiche les chemins et leurs informations
multipath -F #flush de tous les chemins enregistrés

Une fois les chemins supprimés, il faut modifier le fichier de configuration /etc/multipath.conf pour y ajouter en fin de fichier la déclaration des WWID à associer à des friendly_names fixés manuellement :

[...]
multipaths {
multipath {
wwid "360060160da302f009cd38abe2f5ee111"
alias mpath0
}
multipath {
wwid "36006016067302f00e458ad06345ee111"
alias mpath2
}
}

En enfin, on peut les réenregistrer à l’aide de la commande :

multipath -v2

Mode ALUA 4/PNR 1 pour les LUNs

Pour autant, la vraie cause de l’anomalie n’a pu être détectée que lorsque le mode de détails supérieur a été utilisé pour afficher les chemins (option -ll). Plusieurs messages d’erreurs relativement explicites se sont affichés, et notamment :

la mention Path not correctly configured for failover
les chemins en « [active][faulty] »

multipath -ll
Path not correctly configured for failover
Path not correctly configured for failover
Path not correctly configured for failover
Path not correctly configured for failover
mpath9 (36006016067302f00e4588d06345ee111)
[size=100 GB][features="1 queue_if_no_path"][hwhandler="1 emc"]
\_ round-robin 0 [active]
\_ 0:0:5:3 sdd 8:48 [active][faulty]
\_ 1:0:5:3 sdh 8:112 [active][faulty]
\_ round-robin 0 [enabled]
\_ 0:0:4:3 sdc 8:32 [active][faulty]
\_ 1:0:4:3 sdg 8:96 [active][faulty]

Après consultation de ressources en lignes et du « [Host Connectivity Guide for Linux][3] », il apparait que le mode « ALUA 4 actif actif» n’est pas supporté sur les serveurs Redhat Entreprise Linux 4. Il faut utiliser le mode « PNR 1 actif passif» qui lui est bien certifié.

Dans notre cas, c’est pourtant bien ce mode « ALUA 4 » qui avait été déclaré côté baie EMC pour les chemins vers l’hôte. A l’inverse, la configuration qui avait été appliquée côté serveur était bien en mode « PNR 1 ». Il y avait donc une incohérence de ce côté-là.

Changer le mode des LUNs sur une baie VNX

La modification du type de Failover pour un LUN donné peut se faire depuis la console Unisphere mais ce n’est pas évident à trouver !

Une fois connecté, il faut choisir une des baies, ouvrir le menu « Hosts » puis « Host List ». Sélectionner le serveur concerné dans la liste, puis ouvrir l’onglet « Initiators » en bas de page.

Sélectionner un port, puis cliquer sur « Edit », et reconfigurer les 4 chemins.

Valider, et recommencer l’opération autant de fois que nécessaire.

Le mot de la fin

Dans notre cas, beaucoup d’erreurs avaient été faites lors de la configuration des LUNs, de la baie de disques et de multipath. Ça donne donc un bon tour d’horizon des premières choses à vérifier si jamais votre multipath sous Linux fonctionne mal.

Lorsque vous avez comme nous des baies EMC, j’aimerais insister sur le fait que le Host Connectivity Guide for Linux (lien mort, j’utilise Internet Archive) est vraiment un document très important, qui vous aidera à correctement tout configurer. N’hésitez pas à le lire en détail !

Administrer des serveurs Windows avec Ansible

Tue, 15 Nov 2016 13:00:11 +0000

Ansible sur Windows

Depuis que j’ai découvert Ansible, ma vie d’Ops a changée.

Tout doit pouvoir être géré par Ansible. Tous les playbooks doivent être idempotent (je reviendrais la dessus très probablement). Et du coup, ça vaut aussi pour les serveurs Windows qu’il nous reste !

Il n’existe pas encore de version compatible Windows pour l’exécution locale des playbooks. Cependant, il existe tout de même des modules pour administrer via PowerShell remoting des serveur Windows.

La liste des modules pour Windows est disponible sur cette page. La plupart ne sont pas intégrés au cœur d’Ansible mais font partis des extra-modules.

Prérequis côté serveur

Configuration de base (connexion distante avec des comptes locaux)

Il est nécessaire d’installer un module Python permettant la connexion aux Windows via PowerShell sur le serveur Linux qui servira a exécuter les playbooks.

pip install "pywinrm>=0.1.1"

Configuration Kerberos (connexion distante avec des comptes de domaine AD)

La configuration de base ne permet pas d’utiliser des comptes de domaine. Dans un environnement d’entreprise, la plupart des serveurs Windows sont intégrés à un domaine Active Directory.

Il est donc intéressant d’installer les clients kerberos qui permettront au serveur Linux avec Ansible de s’authentifier sur un domaine AD.

yum -y install python-devel krb5-devel krb5-libs krb5-workstation
pip install kerberos

On peut ensuite configurer le fichier /etc/krb5.conf en fonction du contexte. Voici les variables à renseigner :

[...]
[realms]
ZWINDLER.INFO = {
kdc = dc01.zwindler.info
kdc = dc02.zwindler.info
kdc = dc03.zwindler.info
}
[domain_realm]
.zwindler.info = ZWINDLER.INFO

On peut tester que la configuration fonctionne avec la commande kinit

kinit zwindler@ZWINDLER.INFO
Password for zwindler@ZWINDLER.INFO:

ATTENTION : Il faut obligatoirement donner le nom du domaine en majuscules, et indiquer le nom complet du domaine et pas le nom Netbios. Ca vaut pour le fichier de configuration krb5.conf ET lors de l’appel de la commande kinit.

La commande ne doit pas retourner d’erreur et on peut vérifier que tout fonctionne avec la commande klist

klist
Default principal: zwindler@ZWINDLER.INFO
Valid starting Expires Service principal
23/08/2016 15:15:33 24/08/2016 01:15:33 krbtgt/ZWINDLER.INFO@ZWINDLER.INFO
renew until 30/08/2016 15:15:30

Ajout d’un serveur Windows

Méthode 1 : Compte local, variables de connexion dans un fichier chiffré

A la différence d’Ansible sous Linux où l’authentification peut se faire sans mot de passe à l’aide de certificats, sous Windows, il sera nécessaire de stocker à un moment donné le mot de passe d’un compte qui pourra se connecter sur les serveurs Windows.

On ajoute d’abord les serveurs windows dans le fichiers hosts dans un groupe séparé

[zwindler_windows_prod]
antivirus
wsus
[zwindler_prod:children]
zwindler_ansible_prod
zwindler_linux_prod
zwindler_windows_prod
[zwindler_windows:children]
zwindler_windows_prod

On sécurise l’accès au fichier des variables qui contiendra les comptes d’accès aux machines Windows avec l’utilitaire ansible-vault. Le fichier ne pourra alors être lu/édité qu’avec le mot de passe.

ansible-vault create group_vars/zwindler_windows.yml
New Vault password:
cat group_vars/zwindler_windows.yml
$ANSIBLE_VAULT;1.1;AES256
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
1111
ansible-vault edit group_vars/zwindler_windows.yml
Vault password:
---
ansible_user: local_admin
ansible_password: xxxxxxxx
ansible_port: 5986
ansible_connection: winrm
#Decommenter si vous utiliser Python 2.7.9+ et des certificats WinRM autosignes (defaut)
#ansible_winrm_server_cert_validation: ignore

Comme les serveurs qui ont été ajoutés dans le groupe zwindler_windows_prod héritent des variables définies pour zwindler_windows dans group_vars/zwindler_windows.yml, Ansible les utilisera pour s’y connecter.

Méthode 2 : utiliser kinit pour la connexion

Plutôt que d’utiliser un compte local et stocker le mot de passe dans des variables (de préférence chiffré donc) mais quand même devoir taper le mode de passe du vault à chaque fois, il est possible d’utiliser le binaire kinit pour gérer l’authentification AD via un ticket Kerberos.

# kinit domain_admin@ZWINDLER.INFO
Password for domain_admin@ZWINDLER.INFO:
# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_B82OOxI
Default principal: domain_admin@ZWINDLER.INFO
Valid starting Expires Service principal
23/08/2016 16:37:37 24/08/2016 02:37:37 krbtgt/ZWINDLER.INFO@ZWINDLER.INFO
renew until 30/08/2016 16:36:57

Cependant ce n’est pas suffisant. Pour que l’authentification Kerberos soit tentée par Ansible, il est tout même nécessaire que les variables ansible_user, ansible_port et ansible_connection soient renseignées (bizarrement…).

On doit dont créer un fichier de variable similaire à celui de la méthode précédente, mais sans pour autant nécessiter de le chiffrer puisqu’on ne stockera pas le mot de passe.

vi group_vars/zwindler_windows.yml
---
ansible_user: auth@by.kerberos
ansible_port: 5986
ansible_connection: winrm
#Decommenter si vous utiliser Python 2.7.9+ et des certificats WinRM autosignes (defaut)
#ansible_winrm_server_cert_validation: ignore

A noter, la valeur ansible_user n’est pas du tout utilisée. C’est écrit sur le site d’Ansible :

Ansible will first attempt Kerberos authentication. This method uses the principal you are authenticated to Kerberos with on the control machine and not ‘ansible_user’.

Prérequis côté client

Pour pouvoir se connecter il est également nécessaire de réaliser des modifications sur les serveurs que l’on souhaite administrer avec Ansible.

La commande win_ping permet de vérifier la connectivité avec les serveurs Windows. Ici la commande échoue car l’exécution de commande PowerShell à distance nécessite l’autorisation explicite sur l’ensemble des serveurs concernés.

ansible wsus03 -m win_ping --ask-vault-pass
Vault password:
wsus03 | UNREACHABLE! => {
"changed": false,
"msg": "kerberos: 500 WinRMTransport. [Errno 111] Connection refused, ssl: 500 WinRMTransport. [Errno 111] Connection refused",
"unreachable": true
}

De plus, les serveurs dont le pare-feu est activés doivent laisser passer les connexions vers le port 5986 défini dans le fichier group_vars/zwindler_windows.yml

Powershell 3 (pour Windows 2008)

Sur les serveurs antérieurs à Windows 2012, seul Powershell 2 est installé et c’est Powershell 3 qu’il faut !

Ansible fournit un script pour aider à l’installation si la machine a accès à Internet

powershell https://raw.githubusercontent.com/cchurch/ansible/devel/examples/scripts/upgrade_to_ps3.ps1

(Optionnel) ajouter une exception au pare-feu pour le port 5986

Cette exception n’est plus nécessaire car le script Ansible qui suit l’ajoute de lui même. Cependant si vous souhaitez gérer cela vous même, voici quoi faire.

Se connecter sur le serveur, puis lancer un prompt Powershell avec les droits administrateurs

netsh advfirewall firewall add rule name="WinRM pour Ansible" dir=in localport=5986 protocol=TCP action=allow

Autoriser Ansible à réaliser des actions à distance (WinRM)

Récupérer le script disponible sur la branch « devel » et l’exécuter sur le serveur en question via un prompt Powershell administrateur.

github.com/ansible/ansible-documentation/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1

Autoriser l’exécution de script Powershell si nécessaire.

Set-ExecutionPolicy Unrestricted

Tests et troubleshooting

ansible wsus03 -m win_ping --ask-vault-pass
Vault password:
wsus03 | SUCCESS => {
"changed": false,
"ping": "pong"
}

Dans le cas où on souhaite réinitialiser les tickets kerberos pour valider le bon fonctionnement, on peut utiliser les commandes klist et kdestroy

klist
Ticket cache: KEYRING:persistent:0:krb_ccache_B82OOxI
Default principal: domain_admin@ZWINDLER.INFO
Valid starting Expires Service principal
23/08/2016 16:38:45 24/08/2016 02:37:37 HTTP/wsus03.zwindler.info@ZWINDLER.INFO
renew until 30/08/2016 16:36:57
23/08/2016 16:37:37 24/08/2016 02:37:37 krbtgt/ZWINDLER.INFO@ZWINDLER.INFO
renew until 30/08/2016 16:36:57
kdestroy -A
klist

Have fun !

Sources

[En bref] Agrandissement de swap sous Linux

Sat, 06 Feb 2016 11:30:44 +0000

Agrandir la swap, pourquoi faire ?

Avec la montée en puissance de l’extension à chaud de RAM sur les machines virtuelles et l’explosion des tailles de JVM délirantes (20 Go pour un outil de gestion de projet pour 100 personnes. Allo…) il est de plus en plus simple de se dire :

Tiens, le vent souffle aujourd’hui, j’vais rajouter un peu de RAM à mes VMs.

Sauf qu’il arrive d’oublier les bonnes pratiques en vigueur dans votre propre contexte professionnel : 1 fois la RAM, 1,5 fois la RAM, 2 fois la RAM, 0,5 fois la RAM si on a plus de 8Go, 2Go quoiqu’il arrive (rayez les mentions inutiles).

Ça et les templates, pour qui on ne différencie pas toujours les gros des petits serveurs, par flemme.

Du coup, je me retrouve régulièrement à nettoyer des serveurs pour qui on a oublié d’agrandir la RAM après une extension. Et du coup, j’aime bien avoir sous la main la procédure pour le faire rapidement.

Les commandes pour le faire sous Linux (RHEL 6 en l’occurrence)

Afficher des informations sur la swap

swapon -s

Récupérer/retrouver le device qui porte la swap dans la fstab

grep swap /etc/fstab
/dev/VolGroup00/LogVol01 swap swap defaults 0 0

Vérifier que la swap n’est pas utilisée, ou à défaut, que toutes les pages swapées peuvent être stockées en mémoire sinon …!

free -m

Désactivation de la swap

swapoff -a

Agrandir le LV (si on a fait du LVM, sinon il faut agrandir ou créer une nouvelle partition ce qui peut être un peu plus casse pied) puis recréer le volume de swap à la nouvelle taille :

lvextend -L +4G /dev/VolGroup00/LogVol01
mkswap /dev/VolGroup00/LogVol01

Réactiver la swap

swapon -a

Vérifier la prise en compte

swapon -s
cat /proc/swaps #affiche la même chose mais j'aime bien

Bonus : techniques barbares pour faire le ménage

Je me rend le plus souvent compte que les serveurs n’ont pas les bonnes tailles de swap lorsque j’ai une alerte dans ma supervision.

Cycle en V : recherche des coupables

Souvent, les gros systèmes taillés au plus juste swappent un peu, quelques centaines de Mo de temps en temps, lorsqu’un gros traitement se déclenche et qu’on dépasse la quantité de mémoire totale prévue. Mais parfois cela peut assi être un processus qui perd la boule et qui se met à consommer un max de mémoire (avec la réduction drastique des performances qui vont avec en cas de swap).

Pour déterminer quel processus consomme le plus de swap sous Linux, on peut utiliser les commandes suivantes :

free -m
------total        used        free        shared        buffers        cached
Mem:           3948      3186         761                 0                 17             1593
-/+ buffers/cache:      1575      2372
Swap:           4000              0      4000

3948 la quantité totale de RAM du système
3186 et 761 représentent respectivement les quantités de RAM utilisée et disponible, sans tenir compte de ce qui est utilisable en cache/buffer
2372 représente la quantité réelle de mémoire disponible (soit pas du tout utilisée, soit dans un cache qui pourra être libéré si nécessaire)
1575 représente la quantité réellement utilisée par les processus

Si votre système est récent (procps-ng) l’affichage sera un peu différent car les buffers et le cache ont été regroupés dans une même colonne, sur la même ligne que la mémoire. Et c’est tant mieux car c’est plus clair comme ça, je trouve :

free -m
------total        used        free      shared  buff/cache   available
Mem:               993         353       329              37              309           447
Swap:            2079             0       2079

993 la quantité totale de RAM du système
353 représente la quantité réellement utilisée par les processus
329 représente la quantité de mémoire pas du tout utilisée (ni par des processus, ni par des caches)
447 représente une estimation de la quantité réelle de mémoire disponible pour d’autres processus avant que le système ne se mette à swaper (soit pas du tout utilisée, soit dans un cache qui pourra être libéré si nécessaire)

Dans certaines versions de top, il est possible d’obtenir un tri par processus de l’utilisation de la swap, notamment avec RHEL/CentOS, jusqu’à version 6 qui utilise procps :

top
O #o majuscule
p #p minucule
[touche entrée]

La commande top devrait alors lister les processus en fonction de leur utilisation de SWAP

PID USER PR VIRT NI SHR SWAP S %CPU %MEM TIME+ RES COMMAND
4390 root 18 2449m 0 2276 2.0g S 0 9.3 185:11.98 367m mrmonitord
4316 root 34 1566m 19 1976 1.1g S 0 10.7 4:15.62 423m yum-updatesd
4385 root 18 1141m 0 1476 1.1g S 0 0.6 423:19.03 23m java
22009 apache 15 385m 0 4708 360m S 0 0.6 0:20.40 25m httpd

Cependant, cet affichage n’est pas totalement exact et c’est pour cela que cette fonction n’existe pas toujours dans top. C’est notamment vrai pour les dernières versions de Debian/Ubuntu et de RHEL 7 qui utilisent procps**-ng**.
Personnellement je trouve que ça donne un bon aperçu des processus qui sont en train de swapper en cas de recherche d’un coupable. Si vous voulez plus d’information là dessus, je vous conseille de lire la partie « A note about top command » de cet article.

Faire un peu de ménage

Certains d’entre vous trouveront peut être plus simple de le relancer (quand cela est possible). Ceci pourrait rendre de la mémoire au serveur qui se mettra à arrêter de swapper. Pour autant, la mémoire swappée ne sera pas forcément rendue, et l’alerte en supervision restera présente même si l’incident est terminé…

Du coup, voici quelques tips supplémentaires pour faire du ménage dans les caches pour libérer la mémoire réservée mais pas forcément nécessaire :

Libération du pagecache

echo 1 > /proc/sys/vm/drop_caches

Libération des dentries et des inodes

echo 2 > /proc/sys/vm/drop_caches

Tout libérer d’un coup

echo 3 > /proc/sys/vm/drop_caches

Tout péter

Si vous vous sentez d’humeur guerrière et que vous pensez que tout ce qui est dans la swap peut re-rentrer en RAM, vous pouvez toujours désactiver la swap. Ceci aura pour effet de vider complètement la swap et donc de tout rappatrier en RAM. Il va sans dire que si vous vous êtes trompé, le système se bloquera et vous pourrez appuyer longuement sur le bouton « Power ».

swapoff -a #extinction de la swap
swapon -a #relance de la swap

Vous voilà prévenus ;)