Best Practices on Zwindler's Reflection

Retrouvez-moi à Devoxx France 2022

Mon, 18 Apr 2022 12:00:00 +0000

J’ai 10 ans 🎶

Devoxx France revient après deux ans de Covid (chaotique pour tout le monde) en présentiel total. Et ce n’est pas n’importe quelle édition de Devoxx, c’est l’année des 10 ans !

Pour ceux qui ne sont pas familiers de cette conférence, Devoxx c’est :

Conférence pour développeurs organisée par Quantixx au Palais des Congrès, à Paris. 60 exposants pendant 3 jours. 3000 visiteurs. 260 orateurs, 220 présentations, ateliers et plénières.

Et cette fois-ci, je serai présent sur les 3 jours, en particulier le jeudi puisque je donnerai mon talk “Ciel, mon Kubernetes mine des bitcoins” (slides ici, comme d’habitude). Je donnerai la conférence le jeudi à 14:30 en salle 243.

J’en parle dans mon billet sur le temps que je mets à préparer une conférence, être sélectionné à des conférences, c’est compliqué, mais à Devoxx encore plus. Il y a beaucoup de speakers expérimentés et de nombreux talks passionnants en simultanée.

Je suis donc particulièrement content de faire partie des heureux élus :). Une superbe occasion de revoir (ou rencontrer IRL) des copains des Internets et des anciens collègues (va même falloir faire une liste je crois 😅).

Comment on fait pour venir ?

Evidemment, il est trop tard pour prendre un billet pour les conférences (ça part en quelques heures), mais cette année il est possible d’accéder au salon et aux stands d’exposants gratuitement, et même d’accéder à certaines conférences, le jeudi soir.

Seule condition, avoir un billet (gratuit du coup je le répète) pour avoir accès aux stands ou aux BOF (événement terminé).

Dans tous les cas, que vous ayez un billet conférence, speaker ou “salon”, n’hésitez pas à me pinger sur Bluesky, Mastodon (@zwindler@framapiaf.org) ou LinkedIn si vous voulez me faire un coucou 👋, ça sera avec grand plaisir !

Le pitch de mon talk

A tort ou à raison, Kubernetes s’est imposé, ces 4 dernières années, comme un des nouveaux standards dans la gestion des architectures microservices modernes.

Cependant cet outil, riche plus que complexe, amène son lot de pièges dans lesquels les débutants ne manqueront pas de tomber… Et ce n’est pas l’apparente facilité apportée par les offres Kubernetes as a Service qui va arranger les choses !

Après un rapide tour de l’actualité sécurité autour de Kubernetes, je vous donnerai les clés pour éviter de vous faire voler (trop facilement) vos cycles CPU.

Récap’ du RabbitMQ Summit 2019

Tue, 05 Nov 2019 12:45:09 +0000

Des lapins partout, nous étions au RabbitMQ Summit !

Dimanche soir, je suis arrivé à Londres pour participer, avec deux de mes collègues, au RabbitMQ Summit 2019. Cette journée est dédiée à mon broker de messages préféré, RabbitMQ (et non ce n’est pas Kafka - ceci est un troll gratuit pour mes collègues).

Pour ceux qui n’auraient pas suivi, j’ai déjà écris quelques articles sur le sujet dont une introduction si vous débutez.

Cette journée a été l’occasion de pouvoir faire le plein de bonnes pratiques, REX, et autres protips pour optimiser nos clusters.

Keynote

Sans surprise, la keynote d’introduction était réalisée par des membres de la core team de RabbitMQ (Diana ParraCorbacho et Michael Klishin), qui ont parlé de l’actualité du Broker.

Une version majeure de RabbitMQ est sortie en octobre (la 3.8) et de nombreuses des features annoncées l’an dernier sont maintenant utilisables.

Je suis particulièrement enthousiaste à propos des quorum queues et des métriques Prometheus natives, qui sont clairement les deux stars de cette édition, avec plusieurs talks dédiés ou y faisant référence.

L’ajout de features flags pour faciliter les mises à jours (présents à partir de la 3.7.20+ ou 3.8+) est clairement un autre gros point positif. Michael Klishin a officiellement indiqué que le blue/green deployment n’était désormais plus la seule méthode supportée pour mettre un cluster à jour.

La 3.8 étant maintenant derrière nous (seulement des bugs fix sortiront à partir de maintenant), cap sur la 3.9 !

Dans les points importants, un travail va être réalisé pour rendre le core de chaque protocole identique. En effet, aujourd’hui, chaque protocole supporté par RabbitMQ est un module spécifique. Une refonte de l’UI est aussi prévue.

Dans les annonces, une version entreprise (RabbitMQ Entreprise Edition) devrait également voir le jour dans les mois qui viennent. Identique à la version communautaire dans les grandes lignes, elle intégrera des modifications supplémentaires pour faciliter l’hébergement de cluster RabbitMQ inter-connecté sur un WAN ou crossDC. Bien évidemment un support pro fera parti du package.

Le dernier point abordé, pour le futur, est le gros travail sur le “moteur de stockage” utilisé par RabbitMQ (pour la configuration et la persistance). Aujourd’hui, ce travail est réalisé par un projet annexe appelé Mnesia. Michael Klishin a insisté sur le fait que même si le code restait pertinent, la base de code était elle vieillissante.

Un nouveau projet Mnevis avait donc été lancé. Cette réécriture de 0 à pour but de mieux prendre en compte des problématiques multi DC et une meilleure reprise sur incident.

Même si Mnevis ne sera pas officiellement pas disponible pour tout de suite, (probablement pas avant la version 4) un prototype devrait être disponible avec une version modifiée de RabbitMQ. Les sources de Mnevis sont disponibles ici. On aura certainement plus d’infos au prochain RabbitMQ Summit !

Practical Advice for the Care & Feeding of RabbitMQ

La keynote passée, Gavin Roy a présenté un REX sur plus de 10 ans d’utilisation de RabbitMQ en production, avec les pièges dans lesquels lui et son équipes étaient tombés.

De soucis de code PHP qui ouvrait des connexions éphémères (coûteuses dans RabbitMQ), jusqu’à l’envoi de messages contenant des payloads (alors que AMQP propose d’ajouter des metadata), en passant par des lenteurs dues à des erreurs de configuration, le talk a été riche en bonnes pratiques (ou plutôt, mauvaises pratiques à éviter !).

Même si certaines erreurs peuvent sembler faciles à éviter (surtout avec le recul), c’est un de mes talks préférés de la journée, avec de nombreuses réflexions à venir, une fois rentré.

Prometheus Export

C’est le 2ème gros sujet de la journée. J’ai assisté à la présentation de l’ajout de métriques natives au format OpenMetrics directement dans RabbitMQ.

Un des gros soucis de l’interface de management actuelle et des métriques qu’elle expose est qu’il est nécessaire de disposer de privilèges important pour les consulter. Dans un contexte multi-équipes (ou multitenant), ce n’est pas pratique. Le second est un problème de performance. Actuellement l’interface de management (plugin de RabbitMQ) arrive parfois à saturation, nécessitant en cas de charge plusieurs dizaines de secondes à s’afficher.

Pour éviter ces soucis, certains d’entre vous utilisent peut être le rabbitmq-exporter, qui récupère les données de la management UI et les expose à Prometheus au format OpenMetrics. Cependant, ce client, tributaire de la management UI, est nécessairement également limité en cas de surcharge.

La vraie solution qui vient de sortir en 3.8 est donc l’exposition native de métriques au format OpenMetrics. Cet ajout a a priori déjà été énormément bénéfique à RabbitMQ et son écosystème, permettant de déceler plusieurs portions de code inefficientes dans le code de RabbitMQ et même dans le code de Erlang (bugs fixés depuis).

Après déjeuner, 2 talks… un peu décevant…

Les talks suivants (“Source oriented exchanges pattern to keep events in order” et “RabbitMQ MQTT versus EMQX”) ne sont pas simples à retranscrire.

Le premier était très générique, sur la façon de gérer correctement un processus nécessitant que les messages soient traités dans l’ordre.

Le second, un peu étonnant, comparait RabbitMQ avec un produit concurrent au travers du scope MQTT et sur un usecase très précis.

Quelques points que j’ai retenu :

j’ai raté un talk de Wework qui parle de sharding et qui est probablement intéressant à (re)voir (Wework’s “good enough” order guarantee, je mettrai à jour le lien)
il existe un outil appelé MZ Tool (???) qui permet de stress-tester vos infrastructures MQTT. Ce dernier peut être piloté par Ansible ou Terraform. J’ai trouvé un projet MZ-Tools qui n’a rien à voir… Je continue à chercher.

RabbitMQ at Scale

Partenaires principaux du RabbitMQ Summit, les gens de Code84 (CloudAMQP) étaient présents, en nombre ! La société est spécialisée dans l’hébergement de serveurs RabbitMQ, mais aussi de Kafka, PostgreSQL et Mosquitto en mode PaaS. La société est également connue sur son blog technique pléthorique.

Lovisa Johansson (qui a écrit la plupart des articles du blog, que je recommande chaudement) et Anders Bälter nous ont présenté le cheminement de leur société depuis 2012. En partant de simples API Heroku et de serveurs AWS, la plateforme hébergement maintenant les serveurs RabbitMQ de milliers de clients, tout en publiant des métriques, des logs, des alertes, vers la plupart des composants SaaS connus.

Ce talk a aussi été l’occasion de présenter quelques statistiques d’utilisation, notamment sur les moyennes/maximums de métriques comme le nombre de messages par secondes, le nombre de vhosts ou de policy, etc.

Feature complete: uncovering the true cost of different rabbitmq features and configurations

Le dernier talk auquel que nous avons vu a été donné par Jack Vanlightly, qui travaille maintenant chez Pivotal (l’éditeur de RabbitMQ).

Ce talk a été extrêmement riche et mérite d’être revu, à tête reposée.

Jack Vanlightly a fait une série de bench sur plusieurs types de serveurs, avec diverses compositions de producers/consumers, types d’exchanges et d’autres paramètres moins connus.

Les cas étaient parfois extrêmes, mais je pense que les différents cas qu’ils illustrent s’avéreront utiles pour tuner des comportements d’apparence anormaux dans des cas réels (quel paramètre tuner en fonction du nombre de consumers ou de la latence du réseau par exemple).

Conclusion

Malgré notre envie de rester jusqu’au bout, nous devions partir pour arriver à l’heure pour notre vol retour.

Ce RabbitMQ Summit a été l’occasion de discuter avec d’autres utilisateurs de RabbitMQ et de revoir les bonnes pratiques avec des professionnels qui en hébergent des milliers (600000 connexions actives chez CloudAMQP tout de même !).

Ça a aussi été l’occasion de voir que nous n’étions pas aussi “petits” que nous pensions dans notre usage de RabbitMQ, même si nous sommes très loin des limites de l’application dans nos cas d’usage !

Les joies du Dual Tracks ont fait que nous avons forcément raté certains talks que nous aurions voulu voir… Heureusement qu’il y aura les vidéos sur YouTube dans quelques jours/semaines !

A refaire, donc !

Best Practices pour Quorum Redhat Cluster Suite

Mon, 31 Mar 2014 13:51:11 +0000

Si vous avez déjà installé un cluster RHCS, vous saurez sûrement qu’il y a un certain nombre de paramètres qui semblent un peu arbitraires, et qui sont surtout assez mal définis chez Redhat. Je parle du totem token, du quorum_dev_poll et surtout de comment ils dépendent les uns avec les autres. Ces différentes valeurs correspondent à des durées de timeout sur les différents composants qui régissent le cluster.

C’est pourtant d’autant plus important à comprendre que, si vous laissez les valeurs initiales, vous pourrez avoir de vilaines surprises en cas de bascule multipath d’un chemin.

Personnellement, j’ai eu le cas sur un cluster hébergé chez un prestataire. Celui ci a réalisé des opérations sur son SAN, normalement transparentes, qui ont eu la fâcheuse conséquence de mettre en carafe toute l’infrastructure.

Ce qui s’est réellement passé, c’est que le timeout de multipath étant autour des 45 secondes en dur, les valeurs par défaut de perte du quorum était trop courte et le serveur se sabordait, pensant avoir perdu la cohérence du cluster.

Pour s’y retrouver, Redhat a publié un papier qui, à défaut d’expliquer ce à quoi correspond exactement chaque variable, détaille les best practices pour les fixer.

Les règles définies ci-dessous permettent de positionner les différentes variables qui réglementent les différents timeout d’un cluster Redhat Cluster Suite. Ces règles sont tirées du pdf du support Redhat « rhel_cluster_qdisk.pdf »

Règles à respecter

Les valeurs mises en gras sont celles qui sont dépendantes les unes des autres

Variable token du composant Totem

La variable token du composant totem doit respecter la formule suivante

<totem token > 2 * quorumd tko * interval

Donc pour la configuration du quorumd suivante (interval en secondes)

<quorumd label="myQDisk" interval="1" tko="10" min_score="1" votes="1">

On devra avoir totem token (en millisecondes) à

<totem token="21000"/>

Variable quorum_dev_poll de CMAN

La variable quorum_dev_poll de CMAN doit être égale à la variable totem token

cman quorum_dev_poll = totem token

Dans une configuration de base on aura

<cman expected_votes="3" quorum_dev_poll="21000"/>
[…]
<totem token="21000"/>

Variables tko et interval des heuristiques

Le produit de l’interval et du tko d’une heuristique doit être inférieur ou égal au produit de l’interval et du tko-1 du quorumd.

heuristics tko*interval <= quorumd interval*(tko-1)

Dans une configuration de base on aura

<quorumd label="myQDisk" interval="1" tko="10" min_score="1" votes="1">
[…]
<heuristic program="ping -c1 -w1 192.168.2.1" score="1" interval="2" tko="4" />

De plus, une heuristique doit avoir un tko > 1

Variables expected_votes de CMAN

La variable expected_votes de CMAN doit être égale à la formule suivante

Nombre de nœuds du cluster * 2 - 1

Quand on a 2 nœuds, c’est donc 3 votes, quand on a 3 nœuds c’est 5, etc.

Variable votes de quorumd

La valeur de la variable votes du quorumd doit être égale à la formule suivante

Nombre de nœuds du cluster - 1

Quand on a 2 nœuds, c’est donc 1 votes, quand on a 3 nœuds c’est 2, etc.

Règle sur les nœuds

Tous les nœuds du cluster doivent avoir un vote

<clusternode name="node1.example.org" votes="1" nodeid="1">
[…]

Variable two_node de CMAN

Seul cas de doute pour moi, il existe une variable two_nodes de CMAN. Je ne sais pas dire si la Best Practices indique que cette valeur doit valoir 0 ou ne pas être présente…

Configurations fonctionnelles IRL

Exemple de la configuration d’origine pour un cluster à 2 nœuds

<clusternode name="node1.example.org" votes="1" nodeid="1">
[…]
<clusternode name="node2.example.org" votes="1" nodeid="2">
[…]
<quorumd label="myQDisk" interval="1" tko="10" min_score="1" votes="1">
[…]
<heuristic program="ping -c1 -w1 192.168.2.1" score="1" interval="2" tko="4" />
<cman expected_votes="3" quorum_dev_poll="21000"/>
[…]
<totem token="21000"/>

Configuration modifiée pour PowerPath sur un cluster à 2 nœuds

Lorsqu’on utilise du multipathing ou powerpath pour réduire le nombre de SPOF du cluster, il est nécessaire de s’assurer que la perte et le basculement d’un lien se fait plus rapidement que le temps fixé par le cluster pour déterminer un échec.

Le produit des attributs interval * tko de quorumd doit donc être supérieur au temps nécessaire pour une bascule complète du lien multipath.

Les autres valeurs doivent être ensuite calculées à partir de ces deux attributs et des règles définies plus haut. A priori, on trouve sur les sites de la communauté d’EMC que les chemins peuvent prendre 45 secondes pour basculer. Ces valeurs se vérifient sur mes clusters en production.

Il Je préfère donc donner 50 secondes de battement au quorum disk avant de considérer le quorum comme perdu!

<clusternode name="node1.example.org" votes="1" nodeid="1">
[…]
<clusternode name="node2.example.org" votes="1" nodeid="2">
[…]
<cman expected_votes="3" quorum_dev_poll="101000"/>
[…]
<totem consensus="4800" join="60" token="101000" token_retransmits_before_loss_const="20"/>
<quorumd label="myQDisk" interval="5" tko="10" min_score="1" votes="1">
<heuristic program="ping -c1 -w1 192.168.2.1" score="1" interval="5" tko="9" />
<quorumd>