Détails

Écrit par Milosz Szot

Catégorie : DevOps

Publication : 28 août 2014

Niveau : expert

En quelques années, le métier de sysadmin a beaucoup changé.
D'abord, grâce aux progrès de la virtualisation (si le nombre de machines physiques n'a pas forcément évolué, le nombre de machines virtuelles, lui, a explosé).
Et ensuite, grâce à son évolution logique, le Cloud Computing.

En conséquence de quoi, les utilisateurs des moyens informatiques en entreprise s'attendent à avoir un serveur en quelques minutes, contre plusieurs jours / semaines il y a dix ans.
Pire encore, encore trop peu d'entreprises qui ont migré vers le Cloud utilisent la "flexi-sécurité" qu'offre cette technologie, alors que c'est son plus grand atout : pouvoir déployer et détruire automatiquement les instances, en fonction de la charge applicative et du coût sur la place de marché EC2 d'Amazon !
Contrairement à une idée reçue, dans le Cloud, on ne paie pas ce que l'on utilise, mais ce que l'on provisionne ...

L'automatisation est donc logiquement devenue un objectif stratégique dans les entreprises qui ont un département IT interne et chez les prestataires de services spécialisés, de la même façon qu'elle a été toujours été au cœur des préoccupations pour les fournisseurs de cloud.

Au-delà d'une certaine nostalgie d'une informatique à la Papa, je pense que les nouvelles attentes sont légitimes, et même si les équipes IT ont rétréci, les nouvelles méthodologies ont au moins l'avantage d'élever les compétences de l'administrateur, et ne doivent pas être vues comme ennemies mais comme génératrices de valeur ajoutée : l'auto-déploiement, les "Software-Defined Technologies" (SDx, Networking et Storage), la gestion de configuration centralisée, ne sont pas un simple buzz commercial, mais les briques élémentaires qui permettent de construire des architectures informatiques plus efficientes, tant du point de vue économique que fonctionnel.

Dans le cadre de la modernisation d'une infrastructure existante, le plus simple est de commencer par automatiser la configuration initiale des serveurs, le déploiement de logiciels et de nouvelles configurations, ce qui permet aux équipes de se focaliser sur la gestion des vrais incidents et de libérer du temps d'installation, qu'elles pourront alors consacrer à des tâches autrement plus intéressantes intellectuellement (et professionnellement).

Il existe plusieurs outils Open Source / gratuits à cette fin, les plus connus étant Puppet, Chef, CFEngine, Ansible et SaltStack.
Je présenterai aujourd'hui l'installation de Puppet, qui est certainement le plus aisé à prendre en main, et qui convient bien aux infrastructures de taille petite et moyenne (nous parlons d'une limitation à 10000 voire 100000 machines, tout de même !)

"Resistance is futile" - les Borgs, Star Trek

Détails

Écrit par Milosz Szot

Catégorie : Technologies web

Publication : 25 août 2014

Niveau : intermédiaire

J'ai présenté dans un précédent article le service Memcached, qui est un outil extraordinaire pour accélérer les accès aux sites web (et aux applications tout court, puisque des librairies sont disponibles pour les langages "non web" les plus courants).
Ensuite, j'ai expliqué comment intégrer l'utilisation de Memcached à Joomla, un CMS moderne, et plus sécurisé que Wordpress.

Pour résumer Memcached, pour ceux qui ne le connaitraient pas, c'est un service qui stocke les données (clé-valeur) en mémoire vive, ce qui en fait un moyen extrêmement performant pour le cache applicatif et les valeurs temporaires (le stockage permanent doit toujours passer par un SGBD, en parallèle).

Maintenant que nous avons les bases pour l'installer et pour l'interfacer avec un framework, nous allons nous intéresser au benchmarking du service, via l'outil "Memcslap", ce qui nous donnera les connaissances pour bâtir une architecture cohérente.

Détails

Écrit par Milosz Szot

Catégorie : Stockage

Publication : 26 février 2014

Niveau : intermédiaire

La plupart du temps, le terme que j'entends en entreprise, c'est "dimensionner" un serveur de stockage.
Ce terme me dérange puisqu'il fait appel à la notion de dimension d'un disque dur, sa capacité.
Pourtant, tant qu'il reste de la place, ce n'est pas l'espace de stockage qui importe, mais ses performances.
Pas assez, et l'infrastructure est directement limitée par les performances des disques durs.
Trop, et l'entreprise jette son argent par la fenêtre.
Je préfère pour ma part le terme "provisionner", c'est à dire mettre à disposition de nouvelles ressources, pour un usage immédiat ou futur.

Si dans un premier temps, l'administrateur apprend à juger des besoins "à l’œil" (un SSD ou un 15K rpm pour une base de données, un 7200 rpm de l'archivage), il est impossible, même pour un senior, d'évaluer les besoins exacts de ses serveurs, d'une façon chiffrée.
Pour faire une évaluation correcte, il faut faire appel à une méthode rationnelle, scientifique, et prendre la peine de mesurer les performances, de les monitorer sur une durée conséquente, tout le long de l'année, pendant les creux, comme pendant les pics d'activité.

"You Can’t Improve What You Can’t Measure" - Stefan Olander, Vice-Président Digital Sports, Nike

Détails

Écrit par Milosz Szot

Catégorie : Monitoring

Publication : 24 février 2014

Niveau : intermédiaire

Nagios n'a pas de moniteur pour mesurer les IOPS, par défaut, comme la plupart des logiciels de monitoring d'ailleurs.
Nous allons donc modifier le moniteur "Check DiskIO via SNMP" écrit par Herbert Stadler, qui correspond à peu près à nos besoins.