Les billets précédents évoquaient l’amélioration de performances d’un site web grâce à un astucieux montage basé sur plusieurs machines virtuelles. Aujourd’hui, nous allons parler de benchmarking de site web.

Quelques rappels

L’expression « benchmarking » est devenue très populaire dans le milieu professionnelle comme de nombreux autres termes anglais cherchant à démontrer un dynamisme et une originalité. Nous parlerons ici que de sa signification originale qui est la mesure de performances.

Sur l’Internet, l’utilisateur ne demande plus rien d’autre que de l’instantané. Si votre site met plus de quelques secondes à s’afficher, l’utilisateur passera probablement son chemin malgré la qualité éventuelle du contenu.

Les outils pour mesurer les performances des sites web ne manquent pas à l’appel. On en trouve de nombreux en ligne et sous forme d’applications. Certains présentent une originalité intéressante alors que d’autres se cantonnent à des fonctionnalités basiques. L’outil le plus connu est probablement « ab » car il est souvent installé en même temps qu’Apache. Cet outil dispose de fonctionnalités intéressantes mais relativement basiques.

Tsung

Comme l’indique le titre, nous allons nous intéresser à Tsung. Il s’agit d’un projet Open Source Français développé par Nicolas Niclausse. Cette application ne se limite pas aux sites web via HTTP mais peut également benchmarker les applications Webdav, SOAP, MySQL, PostgreSQL, LDAP et Jabber/XMPP. La mesure de performances peut se faire d’une seule machine ou de tout un cluster.

Tsung permet de générer et d’exécuter des scénarios de test. Cela signifie qu’il ne se limite à charger une page web selon une fréquence définie. Vous allez pouvoir lui faire naviguer votre site et utiliser diverses fonctionnalités.

Fonctionnement

L’enregistrement de scénarios est très simple. Il vous suffit de lancer le « tsung_recorder » et de le paramétrer en tant que proxy de votre navigateur. Les actions que vous allez ensuite effectuer dans votre navigateur vont être enregistrées. Vous aurez ainsi créé une suite d’actions.

Une fois la suite d’actions créée, il sera nécessaire de paramétrer les informations relatives au scénario,  à savoir l’IP du serveur à tester, la fréquence d’exécution, etc. La documentation de ce projet est claire à l’exception du chapitre sur les fichiers de configuration de scénario. Pour cela, je vous donne un fichier de configuration de scénario complet et fonctionnel qui devrait vous permettre d’y voir un peu plus clair.

Une fois la configuration terminée, il ne vous restera plus qu’à l’exécuter et observer votre serveur travailler.

Analyse des résultats

L’exécution d’un scénario de benchmarking est une chose mais l’interprétation des résultats est essentielle. Tsung a tout prévu pour vous.

Grâce à l’utilitaire « tsung_stats », vous allez pouvoir générer une série de graphiques traduisant les résultats du test. Cet utilitaire prendra même le soin de les mettre en page dans une page web. L’image ci-dessous est un exemple (en version réduite) des graphiques en question. Un fichier vectoriel est également généré si vous souhaitez disposer d’un visuel plus flexible.

Si vous souhaitez comparer les résultats, Tsung met à votre disposition l’outil « tsplot » qui vous génèrera des graphiques comparant les différents tests que vous avez exécuté. L’image ci-dessous est un exemple de graphique généré par tsplot.

Au final, Tsung est un excellent outil permettant de créer simplement des scénarios de benchmarking complexes et de visualiser ces résultats à travers des graphiques clairs. Seul bémol, il ne s’agit pas d’un logiciel particulièrement simple à utiliser car tout se fait en ligne de commande. Cependant, un utilisateur de Linux un peu aguerri devrait pouvoir s’en sortir.

Rappels

Historiquement, les proxy HTTP ont été mis en place afin d’accélérer les chargements des pages web. A une certaine époque l’acronyme WWW pouvait avoir pour signification « World Wide Wait ». La solution apportée à ce problème a été de mettre en cache les contenus au plus proche de l’utilisateur par le biais de proxy.

La gestion du cache HTTP doit être géré du coté du fournisseur de contenu, à savoir le serveur web. En théorie, ce dernier a autorité sur les données du site qui pourront être mises en cache ou non. Ces informations sont transmises dans les en-têtes HTTP par le biais de divers champs que nous ne détaillerons pas tous ici. Un champ particulièrement intéressant est la durée de rétention dans le cache.

Par défaut, Apache n’envoie pas d’informations quant à la mise en cache du contenu ce qui signifie donc qu’en théorie les données de notre site ne seront pas mises en cache. Dans notre situation, cela signifie que Squid ne met rien en cache tant que nous n’avons pas configuré Apache pour lui indiquer qu’il est possible de le faire.

Configuration d’Apache

Nous allons donc devoir paramétrer Apache pour utiliser les en-têtes contrôlant la mise en cache de nos pages web. Ainsi, notre serveur Squid pourra prendre une partie de la charge de notre serveur web et ainsi le soulager.

Le module Apache qui nous intéresse plus particulièrement est mod_expires. Son activation est simple et, dans le cas de Debian, il est packagé avec Apache. Il suffit donc de l’activer comme suit.

# a2enmod expires

# /etc/init.d/apache2 restart

Une fois ce module activé, nous allons pouvoir le configurer.

Configuration de mod _expires

Nous allons pouvoir configurer mod_expires par le biais de fichiers .htaccess comme il est possible de le faire pour bon nombre d’autres modules. Ce module nous permet de gérer assez finement la mise en cache des fichiers. La syntaxe est simpliste mais efficace. Si vous souhaitez obtenir une explication exhaustive dans la syntaxe et de ses fonctionnalités, je vous recommande de consulter la documentation.

Pour ce site, j’ai choisi la politique suivante de mise en cache.

ExpiresActive On
ExpiresByType image/gif « access plus 1 week »
ExpiresByType image/jpeg « access plus 1 week »
ExpiresByType image/png « access plus 1 week »
ExpiresByType text/css « access plus 1 days »
ExpiresByType application/x-shockwave-flash « access plus 1 hour »

Ensuite, c’est à vous de voir ce que vous voulez que Squid mette en cache ou pas en fonction des fonctionnalités de votre site.

Vérification

Afin de vérifier si tout fonctionne correctement, je vous invite à consulter les log d’accès à votre serveur Squid. Des lignes comportant « TCP_HIT » s’afficheront lorsque Squid servira des données du cache à la place d’Apache. Si vous n’avez que des « TCP_MISS », il doit probablement manquer un élément à votre configuration.

Au final, cette méthode permet d’accélérer significativement son site web et ainsi d’améliorer son référencement sur Google. Dans mon cas, le temps de chargement de ce site a été divisé par un facteur 2 à 3 ce qui est tout de même très intéressant. Des lecteurs m’ont fait remarquer qu’il existait une alternative plus moderne à Squid, Varnish qui permettrait de définir des politiques de mise en cache plus fine. Je vous laisse donc y jeter un coup d’œil !

Contexte

L’affichage de ce blog était relativement lent. Il pouvait mettre plus de 5 secondes pour s’afficher complètement ce qui n’est pas un temps d’affichage très bon. J’ai donc entrepris de trouver une solution à ce problème.

Ce site est hébergé sur une machine virtuelle Xen dont le système d’exploitation est OpenSolaris 2009.06. Elle est globalement assez lente car relativement peu de mémoire lui est alloué. De plus, la cohabitation d’Apache et de MySQL sur le même système ne favorise clairement pas les choses. Certains médisants diront que WordPress et/ou PHP sont des facteurs de lenteur. Ils auront raison mais je n’ai aucune intention d’utiliser autre chose que WordPress car c’est un réel plaisir à l’utiliser.

Un peu de théorie

Un proxy ou en Français « serveur mandataire » est un serveur qui se place entre le client et le serveur. Le client va interroger le proxy qui va à son tour interroger le serveur. Le serveur répondra au proxy qui, à son tour, répondra au client. Ceci est le fonctionnement le plus classique mais on peut placer un proxy dans nombreuses configurations et donner au proxy une intelligence supplémentaire.

Dans le cas de proxys HTTP(S) classiques, on y ajoute des mécanismes de cache afin d’économiser de la bande passante. On peut également y ajouter des fonctions de filtrage d’URL afin d’éviter la consultation de certains sites.

L’exemple d’application du proxy qui nous intéresse ici est le reverse proxy. Le client n’aura aucune connaissance de la présence d’un proxy et pensera qu’il s’agit d’un serveur HTTP comme un autre. Le proxy interrogera ensuite le serveur web et la requête sera renvoyée au client. Dans cette situation, la fonctionnalité de cache du proxy est très intéressante car elle permet d’éviter le traitement de certaines requêtes au serveur HTTP. On pourrait également utiliser le proxy couplé à plusieurs serveurs HTTP afin d’effectuer du load balancing et de la redondance.

Une autre VM

La première étape a été de trouver une machine supplémentaire afin de ne pas faire cohabiter la pile LAMP et Squid sur le même serveur. Dans l’absolu, ce n’est pas impossible mais lorsqu’on a un serveur déjà surchargé, ce n’est peut être pas la meilleure idée.

Étant donné qu’OVH vient de lancer son offre miniCloud, ce projet était une parfaite excuse pour la tester. Le prix de cette offre est vraiment très bas. Pour une VM de 256Mo de RAM, cela revient à 8,5€/mois. J’ai donc crédité 10€ sur mon compte. L’interface de gestion n’est pas la plus esthétique ni la plus rapide mais elle fait l’affaire.

En une petite dizaine de minutes, j’avais donc à ma disposition une machine virtuelle Debian Lenny 64-bits. Le réel inconvénient de l’offre d’OVH est que l’IP de la machine virtuelle change à chaque fois que vous l’arrêtez par le biais de l’interface de gestion.

L’installation de la pile LAMP est très simple et je ne la détaillerai donc pas ici. Il existe des masses incroyables de documentation à ce sujet.

Squid

L’installation de Squid est très simple. Je l’ai installé sur OpenSolaris à partir des dépôts Blastwave via pkgutil. Dans le cas de Debian, un apt-get s’occupera de tout ca pour vous.

Une fois installé, nous pouvons passer à sa configuration. La configuration du reverse proxy est la suivante :

http_port 80 accel defaultsite=www.antoinebenkemoun.fr
visible_hostname vm.antoine.fr
cache_peer 178.32.yy.xx parent 80 0 no-query originserver name=myAccel
acl all src 0.0.0.0/0.0.0.0
cache_peer_access myAccel allow all
acl our_sites dstdomain antoinebenkemoun.fr www.antoinebenkemoun.fr antoinebenkemoun.com www.antoinebenkemoun.com
http_access allow our_sites

Tout d’abord, on indique à Squid d’écouter les requêtes sur le port 80 et que le site que l’on va proxy-er est « www.antoinebenkemoun.fr ». Ensuite, on lui indique l’IP du serveur web où est réellement hébergé le site. Il est ensuite nécessaire de définir un certain nombre d’ACL qui sont ici assez génériques et tout à fait simples. Dans l’exemple, nous avons autorisé le reverse proxy pour 4 sites et nous avons autorisé toutes les IP à visionner le site.

Il est également possible d’utiliser d’autres options afin de mieux régler votre reverse proxy. L’ajout d’un « access log » va vous permettre de voir les pages qui sont consultés mais surtout si le contenu est envoyé par Squid ou par votre serveur LAMP. Il est également possible de régler la quantité de mémoire vive utilisé pour le cache de pages web. L’espace mémoire utilisé pour le cache sera donc alloué en plus de l’espace mémoire du programme principal.

cache_mem 20 MB
cache_access_log /opt/csw/var/logs/access.log

Le chemin pour l’access log est adapté à mon OpenSolaris mais à vous de l’adapter à votre distribution. Si vous êtes sur Linux, vous voudrez surement placer les logs quelque part dans /var/log/.

Au final, nous avons installé notre serveur Squid et l’avons configuré en mode reverse-proxy. Dans le billant suivant, nous verrons les modifications qu’il faut apporter à notre serveur Apache afin d’utiliser réellement la fonctionnalité de cache du reverse proxy.

En Avril, j’avais écrit un petit billet sur la génération de certificats OpenVPN par lots ce qui est bien pratique lorsqu’on doit en générer une quantité importante. J’ai à nouveau rencontré cette problématique mais dans un contexte légèrement différent. Sous Ubuntu Server 10.04, le jeu d’outils Easy-RSA d’OpenVPN n’utilisent plus OpenSSL directement mais utilisent pkitool qui ne semble être qu’un intermédiaire de simplification.

Du coup, le script donné précédemment n’est plus valable. Il a donc fallu trouver une parade assez simple mais non moins fonctionnelle. La solution adaptée à pkitool ne tient plus qu’en un seul script qui est le suivant.

#! /bin/bash

# Make a certificate/private key pair using a locally generated

# root certificate.

export EASY_RSA= »`pwd` »

export OPENSSL= »openssl »

export PKCS11TOOL= »pkcs11-tool »

export GREP= »grep »

export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`

export KEY_DIR= »$EASY_RSA/keys »

export PKCS11_PIN= »dummy »

export KEY_SIZE=1024

export CA_EXPIRE=3650

export KEY_EXPIRE=3650

export KEY_COUNTRY= »FR »

export KEY_PROVINCE= »FR »

export KEY_CITY= »Paris »

export KEY_ORG= »Antoine-Corp »

export KEY_EMAIL= »me@myhost.mydomain »

export KEY_CNAME=$1

export EASY_RSA= »${EASY_RSA:-.} »

« $EASY_RSA/pkitool » $*

Le tour est joué ! Vu que WordPress (ou plutôt de ces modules/thèmes) remplace les quotes par des guillemets impossibles à copier/coller dans un shell, je vous mets à disposition une version en texte brut jusqu’à ce que j’ai réussi à résoudre ce problème assez agaçant.

Au final, ce script devrait vous être utile pour générer rapidement des certifications OpenVPN à la pelle et ainsi vous simplifier la vie.

Vous le savez surement déjà, SNMP (Simple Network Management Protocol) est un protocole très utile pour la supervision d’équipements informatiques que ce soit des serveurs, des équipements réseau, des sondes de température, etc. Il s’agit de la référence en la matière. Sa structure est quelque peu archaïque vis à vis des tendances actuelles mais sa pertinence est toujours d’actualité. Il existe de nombreuses ressources sur Internet au sujet de SNMP, je ne reprendrai donc pas la théorie de ce protocole.

La supervision est un domaine très vaste et surtout très compliqué. Chaque configuration et chaque équipement va avoir ses petites spécificités. De plus, chaque situation va nécessiter la supervision d’une métrique X ou Y. Concrètement, les informations que l’on souhaite superviser ne sont pas forcément présentes dans une MIB SNMP existante.

Les solutions alternatives sont nombreuses. On peut choisir de développer une application spécifique ce qui implique un travail assez colossal et une intégration dans l’application de supervision. Une autre solution est de « customiser » le serveur SNMP afin de nous envoyer des informations spécifiques. Ces informations ne feront pas partie d’une MIB standardisée mais pourront nous être très utiles. Les manipulations concernent uniquement snmpd sous Unix.

Le démon snmpd que nous utilisons comme agent SNMP sur les plateformes Unix/Linux nous renvoit par défaut un grand nombre d’informations. Il supporte également l’ajout d’informations récoltées par l’exécution de scripts tierces. Les informations renvoyées par ces scripts seront placés dans la branche « .1.3.6.1.4.1.2021.8  » de la MIB standard.

Il est nécessaire de spécifier l’exécution d’un script dans le fichier de configuration snmpd.conf. Voici un exemple de script :

exec railsversion « /bin/bash /etc/snmp/railsversion.sh »

Lors des tests que j’ai effectué, j’ai remarqué qu’il n’était pas possible d’utiliser des « pipes » dans cette commande ce qui est fort dommage. Une fois que vous avez ajouté cette ligne dans votre fichier de configuration snmpd, il est nécessaire de le redémarrer pour qu’elle soit prise en compte.

Si nous effectuons un snmpwalk sur la branche SNMP mentionnée précédemment, nous remarquons que les informations retournées par ce script son bien présentes.

root@dev:~# snmpwalk -v2c -cpublic 10.8.0.6 .1.3.6.1.4.1.2021.8
UCD-SNMP-MIB::extIndex.1 = INTEGER: 1
UCD-SNMP-MIB::extNames.1 = STRING: railsversion
UCD-SNMP-MIB::extCommand.1 = STRING: /bin/bash /etc/snmp/railsversion.sh
UCD-SNMP-MIB::extResult.1 = INTEGER: 0
UCD-SNMP-MIB::extOutput.1 = STRING: 2.1.0-7
UCD-SNMP-MIB::extErrFix.1 = INTEGER: noError(0)
UCD-SNMP-MIB::extErrFixCmd.1 = STRING:

Nous avons donc réussi à intégrer nous-même des informations dans SNMP. Ces informations ne sont pas standardisées bien évidemment mais vous permettent d’adapter votre solution à vos besoins. Il est ensuite possible de réutiliser ces informations dans Nagios par le biais de plugins « maison » assez aisément. J’en reparlerai ultérieurement.

Au final, cette petite astuce assez simple permet de se confectionner un bout de MIB personnalisé simplement et efficacement. Cette solution est largement plus efficace que le développement d’une application spécifique.

Définition

Les réseaux de distribution de contenu sont des réseaux qui ne ressemblent pas aux réseaux traditionnels. Traditionnellement, un réseau est présent dans un endroit ou dans plusieurs. Pour les réseaux d’entreprise, ils sont présents sur le siège social, les diverses succursales et éventuellement un centre de données. Dans le cas des réseaux d’opérateur, ils couvrent un pays ou bien plusieurs avec plusieurs points d’interconnexions dans le monde.

Les réseaux de distribution de contenu sont éclatés à travers le monde. Leur objectif est d’être présent dans le plus d’endroits possibles afin de fournir du contenu au plus proche de l’utilisateur. Nous avons donc à faire à des réseaux multi-localisés.

Positionnement stratégique

L’intérêt même des réseaux de distribution de contenu est leur présence dans les endroits « stratégiques » de l’Internet. Leur objectif est de réduire les coûts de distribution de contenu en se rapprochant de l’utilisateur final. Il leur est donc très intéressant de se rapprocher des noeuds d’interconnexion de l’Internet mais également des fournisseurs d’accès à Internet.

Leur présence dans les locaux des fournisseurs d’accès permet une très forte réduction des coûts de bande passante. Du point de vue du fournisseur d’accès à Internet, il ne crée pas de trafic supplémentaire avec le reste du monde. C’est précisément ce type de trafic réseau vers le reste du monde qui est couteux. Le FAI ont donc tout intérêt à intégrer des CDN dans son réseau. Au lieu d’envoyer n-fois un contenu sur un lien interocéanique, il suffira de l’envoyer une fois et il sera ensuite redistribué à partir du réseau du FAI.

La proximité géographique n’est pas forcément synonyme de proximité au niveau de l’Internet. Les nœuds de l’Internet ne répondent aux mêmes logiques de proximité que les réseaux routiers. Les grands nœuds d’interconnexion européens sont Londres et Amsterdam. Il sera donc parfois plus rapide voire nécessaire de router un flux via ces villes pour accéder un pays voisin ce qui est contraire à la simple proximité géographique.

Données statiques

Les réseaux de distribution de contenu distribuent essentiellement des données statiques. Par données statiques, j’entends des données qui ne varient pas dans le temps. La vidéo peut donc être considéré comme un contenu statique dans le cas de vidéos Youtube par exemple. Les CDN ne disposent normalement pas de ressources de calcul de scripts type PHP, ASP ou autre.

L’exception à cette affirmation est le contenu vidéo diffusé en direct. Les CDN peuvent être utilisés pour diffuser ce type de contenu. Mais il reste invariant du point de vue des utilisateurs. Chaque utilisateur reçoit le même contenu avec un décalage minimal.

Au final, nous avons réussi à faire un tour rapide de la définition des réseaux de distribution de contenu. Il serait possible de s’étendre longuement sur ce sujet mais ce n’est pas le but ici. Nous verrons par la suite les techniques d’accès au contenu et de répartition de charge.

Avant de rentrer dans le vif du sujet, la présentation que nous avons effectué est disponible sur Slideshare. L’affichage des animations est quelque peu fastidieux par le biais de la visionneuse Slideshare mais ca reste assez lisible. Il s’agit d’une présentation Keynote contenant assez peu de détails car la plupart du sujet a été traité à l’oral. Pour le détail, il faudra lire les articles de cette série de billets.

Tout d’abord, nous pouvons traduire le terme « Content Delivery Network » par « Réseau de distribution de contenu ». L’adaptation de ce terme en Français me semble tout à fait satisfaisante. J’utiliserais ce terme pour la suite des billets et les autres billets à venir. Je ferais une exception pour le titre mais ça c’est pour l’indexation Google.

Les réseaux de distribution de contenu ont été conçus pour répondre à des problématiques très concrètes rencontrées sur Internet. Lors de cette introduction, nous nous attacherons à identifier ces problématiques et à les détailler. Nous distinguerons deux types de problématiques : les nouvelles problématiques et les problématiques historiques.

Nouvelles problématiques

L’utilisation de l’Internet a beaucoup évolué depuis ces dix dernières années et ces évolutions ont amené de nombreuses nouvelles problématiques.

La première grande révolution est l’introduction de la vidéo dans le navigateur web. Ceci peut paraitre tout à fait « normal » aujourd’hui mais l’intégration de contenus vidéos était quelque chose de rare il y a une dizaine d’années. Le lecteur Real Player avait permis de faire les premiers pas vers cette intégration mais son utilisation était exceptionnellement pénible. Ceux qui l’ont utilisé se souviendront probablement du casse tête entre les version gratuites et payantes ainsi que les publicités associées. Cette révolution a permis au plus grand monde d’accéder à des quantités de contenu astronomiques.

La seconde révolution est le haut débit par le biais des technologies de transmission ADSL et câble. Chaque utilisateur connecté derrière la box de son fournisseur d’accès à Internet obtient ainsi la possibilité de récupérer des données à une vitesse particulièrement élevée. Aujourd’hui, la quasi totalité des accès ADSL/Câble classiques disposent de plusieurs Mégabits de débit.

La troisième révolution a été les réseaux sociaux. Dans l’absolu, les réseaux sociaux ne sont que des sites comme des autres. Leur particularité réside dans le fait que la quantité de contenu qui y est ajouté chaque heure est colossale. De plus, ces contenus sont consultés de manière régulière par de nombreuses personnes à longueur de journée.

Pour résumer, le contenu distribué sur Internet a largement grossi à cause de la vidéo mais les utilisateurs ont également la possibilité de le récupérer à des vitesses élevés. Au final, il était nécessaire de trouver un solution efficace et le moins cher possible car tous ses contenus sont accessibles gratuitement.

Problématiques historiques

Nous venons de voir un certains nombre de facteurs récents qui ont modifié l’utilisation de l’Internet. Nous allons maintenant nous intéresser aux problématiques qui ne sont elles pas récentes.

La première problématique est le coût de la mise en place des liaisons transocéaniques et transcontinentales. L’investissement initial est élevé et la maintenance sur ces câbles est exceptionnellement compliquée. Les procédés de fabrication des fibres ont été améliorés et leur utilisation a été optimisé mais il reste nécessaire de faire traverser l’océan par un navire câblier ou bien de creuser les trous pour enfouir les fibres. Cette problématique induit le fait que plus le trafic réseau parcourt de la distance, plus les couts sont élevés.

La seconde problématique est la vitesse de la lumière. Transcrit en des termes plus informatiques, la seconde problématique est la latence. Cette dernière est bornée inéluctablement par la vitesse de propagation d’un signal dans une fibre optique qui dépend de la vitesse de la lumière. Les utilisateurs veulent non seulement du contenu mais le veulent rapidement. La latence peut devenir un problème dans le cas de liaisons transocéaniques. Des chiffres donnés par Akamai évoquent une latence de 1,6 ms pour du contenu situé à 160 Km et une latence de 96 ms pour du contenu situé sur un autre continent.

Au final, ces deux jeux de problématiques s’additionnent et viennent compliquer la vision traditionnelle de la distribution de contenu sur Internet. Les réseaux de distribution de contenu ont été créé dans l’objectif de résoudre au mieux à toutes ces problématiques.

La méthode la plus simple consiste à utiliser les outils easy-rsa en ligne de commande. Ces outils simplifient réellement la tâche par rapport à l’utilisation directe d’OpenSSL. Le problème avec l’utilisation de ces outils est la nécessité d’interagir avec le terminal. Cet outil va vous demander bon nombre de renseignements tels que le pays, la ville, l’adresse email, etc. Cette interaction rend compliquée la création par lots de certificats.

Une méthode plus compliquée, mais plus efficace, consiste à adapter les scripts easy-rsa afin de rendre leur utilisation plus linéaire et non interactive afin qu’un script puisse les exécuter. De plus, j’ai souhaité donner la possibilité de spécifier la durée de validité du certificat au cas par cas, ce qui n’est pas possible par défaut.

Le premier script, build-key-batch, permet de créer une clé en spécifiant une durée de validité. Il n’y a qu’une toute petite modification qui permet de récupérer la durée de validité passée en argument.

#!/bin/sh

if test $# -ne 2; then
     echo « usage: build-key-batch <name> <duree> »;
     exit 1
fi

if test $KEY_DIR; then
     cd $KEY_DIR && \
     openssl req -days $2 -nodes -new -keyout $1.key -out $1.csr -batch -config $KEY_CONFIG && \
     openssl ca -days $2 -out $1.crt -in $1.csr -batch -config $KEY_CONFIG && \
     chmod 0600 $1.key
else
     echo you must define KEY_DIR
fi

Par défaut, easy-rsa nécessite d’exécuter le fichier vars dont le rôle est d’exporter un certain nombre de variables d’environnement utilisées par les scripts de génération de clé. Cela ne me convenait pas car je souhaitais exécuter un seul fichier contenant toutes les informations dont je pouvais avoir besoin. J’ai donc créé un script nommé build-batch qui contient toutes les options.

#!/bin/sh
if test $# -ne 2; then
     echo « usage: batch-build <name> <duree> »;
     exit 1
else
     # Definition des variables
     export D=`pwd`
     export KEY_CONFIG=$D/openssl.cnf
     export KEY_DIR=$D/keys
     export KEY_SIZE=1024
     export KEY_COUNTRY=FR
     export KEY_PROVINCE=XX
     export KEY_CITY=Paris
     export KEY_ORG= »Keeyyyy »
     export KEY_EMAIL= »$1″
     export KEY_CNAME=$1
     ./build-key-batch $1 $2
fi

Ce script nécessite une petite modification du fichier openssl.cnf présent dans le dossier easy-rsa qui est la suivante :

commonName = Common Name (eg, your name or your server\’s hostname)
commonName_max = 64
++ commonName_default = $ENV::KEY_CNAME

Le script a exécuter afin de générer un certificat est donc build-batch suivi de deux arguments qui sont le nom du certificat et la durée de validité. Vous pourrez ainsi générer des certificats pour OpenVPN simplement et efficacement sans nécessiter une intervention humaine.

Source : insights

Lorsqu’une architecture est conçue initialement, les concepteurs disposent d’un certain nombre d’éléments motivant un choix technologique par dessus un autre. Dans le cas du cloud computing, ces éléments ne sont pas fixés depuis une durée particulièrement longue et ne sont clairement pas fixés à des échéances au delà du moyen terme. La relative nouveauté du cloud computing devrait démotiver bon nombre de concepteurs d’architecture.

Dans le cas où le choix serait fait de se baser sur une architecture intégrée au sein d’un cloud quelconque, il est nécessaire de se poser très sérieusement la question de l’interopérabilité. Lorsqu’une entité va placer son architecture,  elle confiera d’une part ses données mais aussi le travail humain lié à la conception d’une plateforme. Ce travail humain a un coût relativement important en fonction de l’architecture en question. De sérieux problèmes sont à envisager dans l’éventualité d’une faillite de la société hébergeant le cloud ou même une catastrophe quelconque mettant à mal le cloud. La non-transparence des clouds actuels rend exceptionnellement compliqué l’évaluation de ces risques.

La problématique de l’interopérabilité se pose ainsi. Dans le cas où une entité utilisatrice utilisatrice d’infrastructure cloud souhaite changer d’hébergeur pour une raison X ou Y, en a-t’elle la possibilité ? Il y a bien sur plusieurs niveaux de réponse à cette question. Nous pouvons envisager une situation dans laquelle il lui est juste possible de récupérer les données applicatives ce qui impliquerait de devoir reconstruire la quasi totalité de l’infrastructure applicative. Nous pouvons également envisager une situation où il est possible de récupérer une version « packagée » des machines virtuelles ou, à l’opposé, une situation où rien n’est prévu pour être compatible avec d’autres plateformes.

De plus, ce n’est pas parcqu’il est possible de récupérer une machine virtuelle qu’il sera possible de l’exécuter sur une autre plateforme sans devoir se plonger dans les méandres du système d’exploitation pour peu que celà soit même possible.

Au final, l’interopérabilité est un enjeu majeur de toute plateforme informatique et suscite de nombreux débats habituellement. Les problématiques d’interopérabilité dans le cloud computing ne semblent pas encore avoir passioné grand monde ce qui est dommage car elle est bien réelle et existante. Le logiciel libre a clairement un rôle à jouer dans le cadre de cette standardisation avec les acteurs majeurs de l’industrie associée.

Qu’on apprécie OVH ou non, le nombre de serveurs qu’ils hébergent est réellement impressionant. Selon leurs dires, ils hébergeraient pas moins de 70.000 serveurs aujourd’hui et visent 100.000 d’ici à la fin de l’année. Selon Wikipedia, il s’agirait même du 5ème hébergeur mondial en terme de quantité de serveurs.

Leur succès est lié à leurs prix qui défient toute concurrence sur le marché des serveurs dédiés. Je ne connaissais absolument pas l’histoire d’OVH et ce qui faisait leur succès. La présentation suivante est une présentation faite par deux responsables d’OVH qui retrace l’histoire de leur société. Elle est particulièrement intéressante car elle détaille toutes les « astuces » qu’ils ont utilisé afin de pouvoir grandir au fur et à mesure. Vous y apprendrez par exemple que la quasi totalité des serveurs OVH sont refroidis par un système à eau.

FRnOG 15 – Comment héberger 70000 serveurs ? (part 1)

FRnOG 15 – Comment héberger 70000 serveurs ? (part 2)

Cette présentation est un bel exposé d’audacité et d’ingéniosité comme il en faudrait, surement, plus souvent. Il y a en tout une bonne heure de vidéo. Ceci est extrait d’une conférence FRnOG qui regroupe tous les grands opérateurs Français.