Configuration: Modélisation ou Scripting ?

October 9th, 2014

 

Quel est la différence entre un langage descriptif et un langage déclaratif ? Prenons un exemple… Si vous cherchez une voiture, vous allez dire, je veux 5 place, un grand coffre, le gps, l’iphone etc… vous n’allez pas demander si la roue est installé par une machine XYZ et un tournevis cruciforme ?

Et bien, c’est cela la différence ! Dans un cas, le langage déclaratif, vous indiquer dans quel état vous souhaitez que le système soit tandis que dans l’autre vous explicitez quels sont les étapes pour y arriver.

Dans le cas de la gestion de configuration, cette différence est important.  En effet, dans un cas vous dite juste, je veux un serveur apache/tomcat, dans l’autre vous dite, il faut récupérer le rpm apache, puis l’installer, puis activer mod_http puis … etc !

Dans le premier cas on modélise l’état que l’on veux avoir, alors que dans le second il faut faire attention a toutes les variantes que l’on pourrait trouver, genre, zut, il y a déjà un apache, je doit vérifier la version etc …

Conclusion

On peut lister ainsi les bénéfices d’une gestion de configuration déclarative :

* c’est répétable : chaque exécution donnera le même résultat quelque soit l’état de départ.

* c’est consistent :encore une fois , quelques soit l’état de départ, l’état d’arrivé sera celui désiré.

* c’est auto-documenté : en général les langages déclaratif sont très simple et facilement compréhensible contrairement à des scripts et en général beaucoup plus concis/compact. Et de fait, devient un atout pour l’auditabilité.

exemple d’outils déclaratif :

* puppet, salt, confsolve, lcfg, bcfg2

exemple d’outils non déclaratif :

* fabric, chef,

That’s Not My Problem - I’m Renting Them

October 9th, 2014

 

Cette petite phrase de Adrian Cockroft “That’s not my problem, I’m renting them.”, c’est la réponse un peu imagé qu’il a faite lorsque quelqu’un l’a interrogé sur la fiabilité des SSD !

Un peu imagé, pourquoi ? Parce qu’en fait c’est l’illustration même de l’abstraction qu’offre le cloud. Et c’est bien comme ça qu’il faut voir les choses aujourd’hui. le cloud et plus généralement la virtualisation offre un tel niveau d’abstraction qu’il ne faut plus se préoccuper des ces aspects matériels sauf bien sur si vous en êtes le fournisseur et non l’utilisateur.

vmware et les “large pages”

October 7th, 2014

 

VMWare comme la plupart des OS à une gestion de mémoire qui s’adapte en fonction des usages.

L’un des paramètres sur lequel on peut influer pour affiner ses algorithme s’appelle le “LPageAlwaysTryForNPT”  ou encore l’allocation de pages larges.  Mais Kesako ?

In the cases where host memory is overcommitted, ESX may have to swap out pages. Since ESX will not swap out large pages, during host swapping, a large page will be broken into small pages.

En fait tout part du fait que VMware afin d’optimiser la mémoire utilise une technique dite de Transparent Page Sharing (aka TPS) qui permet de partager des pages mémoires identiques afin de libérer de la mémoire. Une sorte de deduplication. A l’origine de ça, les ESX scan régulièrement leurs page de 4Ko afin de trouver de nouveau candidat. D’un autre côté, si le hardware le permet et que l’OS de la VM le demande, ESX préfère utiliser ce que l’on appelle des “larges pages”  soit 2Mo au lieu de 4Ko, mais dans ce cas il va rarement trouver de bon candidat au partage !

A côté de cela, l’ESX comme tout OS va éventuellement swapper la mémoire au besoin. Dans ce contexte, lorsque l’ESX va swapper une page il va devoir la “casser” en petit morceau de 4Ko et va profiter de l’occasion pour tenter de trouver de nouveau candidat au partage. On peut résumer cet effet par “partager avant de swapper”.

Parmi les impacts que cela à, c’est celui de retarder le partage de page.

Le paramètre LPageAlwaysTryForNPT, va permettre de favoriser le page sharing en demandant à l’ESX de n’allouer des large pages que lorsque c’est demandé explicitement par l’OS (par exemple avec MySQL ou Oracle). L’avantage c’est que le reste du temps on aura des pages plus petite (4Ko) et l’action du TPS et donc plus de partage de page.

L’effet va donc dépendre de la workload, si vous avez un système avec de nombreuse “petite” vm, ce sera avantageux car il y aura plus de partage, la consommation mémoire va diminuer et vous pourrez poussez plus loin la consolidation. D’un autre coté si vous avez des grosses VM avec des applications demandant beaucoup de mémoire et donc très probablement des large pages (tel que MysQL ou Oracle ) il y aura plutôt un effet négatif.

Sachez aussi que le paramètre se situe au niveau Host mais aussi au niveau vm (sched.mem.alwaysTryLPageAlloc).

Il faut aussi noter que lors d’un vmotion, l’ESX transfert des pages de 4K, et les regroupe ensuite à nouveau en large page.

Xen,la faille XSA-108 et la résilience…

October 3rd, 2014

 

 Christos Kalantzis

#AWS Reboot-Apocalypse? #Netflix runs #Cassandra. Bring it on!

 

Ces dernières semaines un faille Xen à prit de cours beaucoup de fournisseurs de cloud basé sur Xen (AWS, rackspace et quelques autres)  (note: c’est la faille XS-108 dévoilé officiellement le 1 octobre). Ceux-ci se sont engagés dans une espèce de course contre la montre en quelques semaines pour mettre à jours leurs serveurs. Et pourtant à travers les tempêtes de reboot, assez peu de services ont été impactés, les meilleurs n’ayant même pas eu d’impact client !

Parmi ceux-ci, l’un d’eux, qui fait ça pub en ce moment en France a expliqué les raisons de cet état de résilience. Il est en particulier, notoirement connus qu’ils utilisent ce qu’il ont nommé eux même le “Chaos Monkey” et une stratégie dite de Chaos  Engineering qui à pour effet de mettre régulièrement à mal leur architecture de production. Cette best-practice, leur à permis, par exemple, d’être serein sur les reboot de serveurs (VM) impacté lors des mise à jours mais aussi, que le dit reboot n’impact pas le service en lui-même, deux choses primordiales.

Parmi les autres atouts, c’est leur choix de Cassandra, qui privilégie la tolérance au partitionnement versus la consistance, qui permet aussi un grande résilience lors de tous ces reboots, voulut ou non, avec comme autre choix le remplacement automatique de tout nœud défaillant plutôt que sa réparation, ce que permit ce choix de BDD. Pour ce que les chiffres intrigue : il y a eu 218 serveurs Cassandra, 22 ont eu un problème de reboot et on été remplacé avec 0 interruption pour le service.

On peut en tirer comme leçon que les tests répétés, voire continuel, sur toutes les couches (même sur la persistance) sont un des meilleurs atouts pour une bonne résilience. Mais, aussi, que les choix d’architecture permette d’y répondre d’une manière efficace.

docker and xen, complementary not enemies

October 1st, 2014

 

Often seen as competing, containers a la Dockers and hypervisor a la Xen are more complementary than enemies !

By using both technologies we can be more efficient.

let’s see some examples. Dockers mains advantages are a fast boot, simple usage, little (or no) overhead and high density per host but they rely on same kernel/OS which is bad for security and isolation., and well, some “battle” between devs and ops ;-)

ON the other side, Xen let’s you have different OS/kernels,  have more overhead and have a more traditional/mature approach.

Why not use both world ?

Let VM run in a hypervisor with a define set of resources. it offer you (dev) rollback, snapshot and so on easily, considering it as a sandbox.

For the sysadmin, and easy way to handle/extend/replicate resources of VM, even in live with some hypervisor.xen-docker

Ne pas confondre Configuration et Provisionning

September 25th, 2014

 

Il y a tellement de buzz ces derniers temps autour des conteneurs comme Docker de la même manière qu’il y a quelques temps autours de la virtualisation, que l’on peut vite oublier cette notion fondamentale.

Il est bon de rappeler qu’il y a deux usages à ces technologies : la scalabilité et le déploiement.

Scalabilité :
Sur la scalabilité, ces 2 technologies sont très bonnes et les deux sont tout à fait à même d’encapsuler un service et de permettre un déploiement rapide de multiple instance avec peu ou pas d’opération post-provisionning.
Et dans ce contexte les deux se valent, et aucune n’est meilleure.

Déploiement :
Coté déploiement, la standardisation des APIs de ces outils permet de ne se focaliser, que, sur le management du container  ou de la machine virtuelle. En effet les APIs permettent de provisionner de manière aussi efficace tant de la VM que du container.
Par contre ce que ces APIs ne permettent pas c’est la Configuration une fois les dit-service provisionnés.

 La Configuration n’est pas du Provisionnement !
Et c’est cette différence qu’il faut bien avoir en tête une fois que l’on veut faire du self-service ! En effet, autant  le provisionnement que ce soit de container ou de vm peut-être une chose aisé autant la configuration des services doit  encore être faite ! Quelque soit le cas d’usage, il y a toujours un minimum d’opération de configuration à faire.
En clair, une fois notre service provisionné, il y a encore du boulot ;-) Par exemple, on ne peut pas imaginer lancer un frontal Apache,  sans définir comment (algo) et/ou sur quel(s) tomcat(s) il devra repartir les requêtes.
Et ce sont bien deux processus distinct ! On peut aussi en dire autant sur la partie monitoring ou surveiller un server ou  un container et bien différent de surveiller un service. On doit bien faire les deux !

On peut par ailleurs se rendre compte que des deux, la configuration à le plus d’impact sur le cycle de vie ! Et c’est de son optimisation que viendra le plus de bénéfice.

Building slowmoVideo on OSX

April 4th, 2014

here, I will describe how to build slowmoVideo for OSX from scratch.

you will need of course Xcode and command line tools, with cmake

will need some dependencies :

* glew (glew-1.10.0)

* ffmpeg (ffmpeg-2.2)

* jpeg (jpeg-9a)

* libpng (libpng-1.6.10)

*zlib (zlib-1.2.8)

* yasm (for ffmpeg) (yasm-1.2.0)

* opencv (opencv-2.4.8)

* qt4 (qt 4.8.5)

 

you will need source code from my own clone git repository : https://github.com/valgit/slowmoVideo

 

* you need to specify where to find some libraries for cmake :

export QTDIR=/Users/val/Documents/Sources/qt4

export FFMPEGDIR=/Users/val/Documents/Sources/ffmpeg

 

* run cmake :

cmake ../slowmoVideo/src -DCMAKE_INSTALL_PREFIX=/Users/val/Applications/slowmoVideo -DQTDIR=/Users/val/Documents/Sources/qt4 -DQT_MAKE_EXECUTABLE=/Users/val/Documents/Sources/qt4/bin/qmake -DOpenCV_DIR=/Users/val/Documents/Sources/opencv/share/OpenCV -DGLEW_INCLUDE_DIR=/Users/val/Documents/Sources/slowlib/include -DGLEW_LIBRAIRIES=/Users/val/Documents/Sources/slowlib/lib/libGLEW.a -DJPEG_INCLUDE_DIR=/Users/val/Documents/Sources/slowlib/include -DJPEG_LIBRARY=/Users/val/Documents/Sources/slowlib/lib/libjpeg.a -DFFMPEG_LIBRARY_DIR=/Users/val/Documents/Sources/ffmpeg/lib -DFFMPEG_INCLUDE_PATHS="/Users/val/Documents/Sources/ffmpeg/include"

check if cmake find all the needed part. in my case some library where not found, so I have to specify them in CMakeCache.txt directly …

they where : glew libraries and libswcale !

 

* if all is ok you can run make ; make install

you will have some warning during compilation…

* need to update cmake to copy opencv library in working destination

* seem that deployqt4 is not working correctly so execute

~/Documents/Sources/qt4/bin/macdeployqt  ~/Applications/slowmoVideo/slowmoUI.app -verbose=2

which will copy/correct all the qt4 stuff in Frameworks directory. also copy/mov the lib directory from MacOS to Framework

execute the fixup script to correct opencv lib path

sh ~/Documents/Sources/slowmoVideo/src/fixuplib.sh slowmoUI

you should now have a working GUI application bundle for MacOS

Dropbox et 200 millions d’utilisateurs

November 7th, 2013

 

Lors d’une récente conférence, l’un des Site Reliability Engineer de Dropbox à présenté quelques éléments clef de leur infrastructure (pour la petite histoire il était précédemment chez Youtube ;_).

Pour mémoire, Dropbox est un service cloud qui permet de stocker et de partager des fichiers. Il faut aussi savoir qu’il a fallut 4 ans à Dropbox pour passer à 100 millions d’utilisateurs, mais seulement 10 mois pour les 100 millions suivant ! Avec de tels chiffres on peut aisément imaginer les impacts sur l’infrastructure.

Alors, comment Dropbox gère une infrastructure capable d’accueillir 200 millions d’utilisateur et le milliard de fichier qu’ils stockent chaque jour ?

En l’occurrence, cela représente plus de 10000 serveurs physiques et un nombre important de service Amazon. Et oui, Dropbox n’utilise pas exclusivement les services d’EC2 mais à aussi ses propres serveurs et datacenters selon un modèle souvent appelé hybride. Plus précisement, la partie metadata  est stocké sur ses propres serveurs tandis que les fichiers eux même sont stocké sur Amazon S3. Au passage des instances EC2 sont utilisé pour faire parler ces deux mondes entre-eux.

Autre point important, avec de tels volumes les changements sont à la fois énorme et de par le modèle économique incertains ! Pour Dropbox, cela implique qu’il est fondamental d’en tenir compte dans les développement afin d’être souple, mais aussi que le mixe entre hébergement interne et externe doit être toujours connus car selon eux cela requiert des outils différent pour les gérer.

Résultat ? Au lieu d’essayer de capitaliser sur des images standard de déploiement, Dropbox à préférer capitaliser sur Puppet pour unifier les installation, l’inventaire et la gestion du cycle de vie !

Cela étant, tout n’est pas rose et il reste des chalenges chez Dropbox :

* gérer efficacement les thumbnail photo : une première étape à était franchit en passant a n mode batch/http qui leur a permis en gain de performance de 40.

* améliorer le débit “client” lors des synchros, point important car directement perceptible. La encore une étape à était franchie en permettant d’utiliser plusieurs connections en parallèle (le retour du p2p ;-) ce qui à permit de gagner un facteur 2.5 (voir 4 dans certaines régions du globe !)

* dernier et non de moindre : la latence de d’Amazon S3, comme chacun le sait Amazon S3 n’offre que peut de garantie, il est donc difficile d’avoir un contrôle sur les performances dans ce contexte pourtant c’est un point important pour le perçut et l’usage du produit. Pour pouvoir avancer, Dropbox s’appuie sur un monitoring important et une gestion de connections de type pool.

Mais comme le dit le présentateur, quand on ne contrôle pas toutes les variables seul l’expérimentation fait avancer et de même dans le cadre de la scalabilité, parfois les solutions les plus évidentes ne sont pas les bonnes.

Faire de bons graphiques pour le monitoring

October 17th, 2013

Avoir des bons graphiques est important.

Un graphique c’est une fenêtre sur votre système et c’est aussi ce qui vous permet d’en avoir une représentation bâtit à partir de vos mesures…

A l’avenir, c’est aussi ce qui permettra d’automatiser votre détections d’anomalie voir de les prédire. Mais pour tous cela, il faudra être capable de définir des patterns et d’apprendre à votre système, de plus quoi que vous fassiez il restera toujours les cas aux limites pour lesquels vous aurez besoin de comprendre ce qui se passe. C’est pour toutes ces raisons qu’avoir de bons graphiques est important.

Alors, c’est quoi un bon graphique et comment le créer ?

Un bon graphique est une représentation de l’état du système qui donne une description significative, maximise la compréhension et la vision du phénomène, et permet d’inspecter facilement et de détecter les problèmes, et être motivé pour lancer les actions et résoudre des problèmes (sic). On le comprend c’est donc un système complexe à construire donc les principes fondamentaux font appels aux techniques de visualisation des données mais aussi à l’utilisateur.

Revoyons donc quelques un de ces fondamentaux :

  • Il doit être consistent.

Cela veut dire que l’objet suivit et sa représentation doivent être cohérente. Il est des cas, ou par exemple, une ligne ne donne pas une bonne indication de ce que l’on mesure (ex: stacked area vs ligne). On doit aussi retrouver des unités cohérentes pour des mesures semblables.

  • On doit avoir un contexte

En général, la première question c’est « qu’est-ce que je regarde », ou bien « ou est-t-on » ? Il est en effet important que l’on ne soit pas perdu dans la masse de donnée et que l’on ait assez d’indicateurs visuels pour ne pas devoir faire des efforts pour se rappeler ce que l’on regarde.

Le moyen le plus simple pour cela, c’est d’avoir un affichage hiérarchique clair et une convention de nommage cohérente et constante. (ex : network>>eth0>>all )

L’autre point qui facilite cela : afficher le maximum d’information possible, sans toutefois compromettre la lisibilité !

  • La lisibilité, parlons-en !

Vous avez un écran 32 pouces et pourtant pas encore assez de place ?  Quoi que vous fassiez la place sera toujours limitée vis-à-vis du nombre d’éléments. Il faudra donc faire des choix entre niveau de détail et quantité d’objet. Une solution qui peut aider dans un grand nombre de cas : les « horizon graph ». Un « horizon graph » est un moyen efficace en espace pour analyser et comparer plusieurs ensembles de données de séries chronologiques, typiquement ce qui arrive le plus fréquemment en monitoring. Pour cela, l’axe y est divisé de façon uniforme en bande.

Autre moyen, simple, pour améliorer les choses : éliminer les éléments inutiles. Comment ? Si vous n’êtes pas sûr que cela serve : ne le mettez pas !

  • La mise en perspective, « il y a un pic, et alors ? ».

Une mesure à elle toute seule ne nous dit rarement quelque chose, elle fait souvent partie d’un tout et il est important de voir l’ensemble. Les évènements qui ont eu lieu au même instant voire à plus grande échelle sur plusieurs systèmes sont souvent important. Pour cela, il faut pouvoir mettre les graphiques en perspective (après l’horizon-;-), les regrouper afin de voir les relations. Pour cela il est important de pouvoir aligner des graphiques sur le même axe de temps afin de les parcourir simultanément. Idéalement, il faudrait pouvoir afficher toutes les mesures en un point du temps donné durant ce parcours.

  • Dernier paramètre et non des moindres : l’utilisateur.

Regarder des graphiques c’est rarement marrant, c’est même souvent lassant. Il faut donc que ce soit agréable à faire, et oui ! Une interface bien designé fera que l’on sera plus enclin à l’utiliser. En effet, même pour afficher des graphiques les règles de base du design son valable :

  1. Avoir des blocs clair
  2. Une consistance dans les formes, les fontes, les graphiques …
  3. Un cheminement simple (ex: haut -> bas, gauche -> droite)
  4. Du contraste pour mettre en avant les informations importantes et pour le coup un chalenge important : la gestion des couleurs dans les graphiques

Si l’on résume ce que l’on a besoin : consistance entre mesure et objet, une mise en perspective des mesures avec un bon contexte, le tout dans une interface clair et facile d’utilisation et vous aurez le système de visualisation de votre monitoring parfait !

 

Pour ceux qui voudrait en savoir plus sur les horizon graph :

Time on the horizon :  http://www.perceptualedge.com/articles/visual_business_intelligence/time_on_the_horizon.pdf

Sizing the horizon : The Effects of Chart Size and Layering on the Graphical Perception of Time Series Visualizations : http://vis.berkeley.edu/papers/horizon/2009-TimeSeries-CHI.pdf

quelques différences d’architecture entre Hyperviseur

March 13th, 2013

Dans cet article je vais tenter d’expliquer les différence entre les hyperviseurs les plus courant du marché, en l’occurence VMWare ESX, hyper-v et Xen.

Premier point à savoir, les 3 sont ce que l’on appel des “bare metal” hypervisor, c’est à dire qu’ils n’ont besoin d’aucun OS pour fonctionner (par comparaison le classique VMWare Player lui à besoin de windows ou linux). Malgré tout on verra que ce n’est pas aussi simple.

Autre élément, Xen et Hyper-V sont aussi ce que l’on appel de “paravirtualiseur”, ce qui veut dire qu’ils peuvent faire tourner des invités modifié, utilisant des APIs dédiés dans le but d’amélioré les performances de virtualisation (cela permet par exemple d’utiliser des processeurs qui n’ont pas de jeux d’instructions dédié à la dite virtualisation comme “vt-x” ). Dans le cas de Xen on parle de mode PV ou HVM (Hardware Assisted Virtualization)

la ou les différences apparaisse c’est sur la mise en œuvre de ce fameux “bare-metal”.

Dans le cas d’Hyper-v, on va avoir un noyau qui va crée une première partition (ou invité, dom0 en langage Xen) dans lequel on va retrouver tous les drivers et en l’occurrence ce sera un windows bien sûr. Dans le cas de VMware on va également trouver un noyau (le vmkernel), c’est également lui qui va charger les driver, mais cette fois ils vont se retrouver dans une zone utilisateur dédié et sans privilège. Dans Xen, on va retrouver le comportement d’Hyper-V : l’hyperviseur va crée un premier invité le fameux dom0) dans lequel les drivers seront chargés, par contre à la différence d’hyper-v l’OS n’est pas imposé même si en pratique c’est en majorité du Linux. En pratique, quelle différence cela fait-il ? Et bien se qui peux se passer, c’est que votre partition principale plante pour une raison quelconque. Dans ce cas, vous perdez toutes communication avec le monde extérieur, dans le cas de VMware ce sont des processus séparés, donc tout n’est pas perdu…D’ailleurs pour palier à ce problème, les utilisateurs avancé de Xen crée de plus en plus de invités dédié à chaque driver, on se rapproche ainsi du comportement de VMware avec un avantage supplémentaire dans ce cas : si un invité-driver plante on peut le relancer facilement, voir faire des mise a jours des drivers en live (si, si ça marche ! )

 compare

Dans la serie de différences, due à ce comportement on va trouver aussi un autre point. Ce que l’on peux qualifier d”’”administrative OS”, ce qui représente plus ou moins le moyen que l’on a d’interagir/configurer le noyau de l’hyperviseur. Comme on a pus le constater avec Hyper-v, ce moyen passe par la partition première qui est aussi un OS complet… On voit tout suite ici ce que cela peut impliquer en terme de sécurité d’autant plus que l’on peut y installer n’importe quelle application sans restriction.  Du coté de Xen c’est un peu le même combat, on l’a vus précédement, cependant son coté OS indépendant limite un peu plus ce mauvais point. Du coté de ESX, le point d’entré est une console intégré dans sa propre partition complètement indépendante (au passage pour la petite hisoire, un ESX utilise un boot loader de type redhat, mais dans le processus d’init du kernel RHEL il charge son code en mémoire, puis switch dans celui-ci, crée une première machine virtuel et y place toute la partie bootstrap ainsi que sa console, yep !), il ne reste donc d’accessible que les commandes d’administration (un peu à la manière d’un switch ou d’un busybox)

voila vous en savez un peu plus, pour mieux comprendre ce qui se passe.