« Benchmarker » son site avec Tsung

Ce blog ne déborde pas d’activité en ce moment, vous l’aurez surement remarqué. J’ai été pas mal occupé d’une part avec mon travail et mon activité en tant que bénévole à la Croix-Rouge et d’autre part mes études. J’essaye de tout concilier au mieux du coup ce blog ne déborde pas d’activité. J’ai cependant pris le temps de réparer le formulaire de contact de ce blog qui ne fonctionnait plus à cause d’un petit changement de VPN. C’est désormais réparé.

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.

Content Delivery Networks : Définition

Après avoir effectué une introduction sur les Content Delivery Networks (CDN), nous allons nous attacher à la définition de leurs spécificités. Nous nous intéresserons également à leur positionnement et aux données qu’ils vont pouvoir servir. L’objectif est ici de faire un tour d’horizon de cette large question.

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.

Content Delivery Networks : Introduction

J’ai récemment effectué un petit projet dans le cadre de mes études dans le cadre de l’unité de valeur « Services Réseaux » traitant des Content Delivery Networks (ou CDN) avec un binôme de choc. Dès que nous avons vu que ce sujet était proposé dans la liste des projets, nous l’avons immédiatement choisi. Le reste des projets était plus ou moins classique mais ce sujet ressortait du lot. Ce sujet fera l’objet d’une série de billets car un unique billet serait bien trop long.

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.

Le retour d’expérience d’OVH en matière d’infrastructure

Tout le monde connait sans aucun doute OVH. Nombre d’entre vous ont probablement déjà eu à faire à eux à travers leurs différentes offres que ce soit de l’hébergement mutualisé ou bien un serveur dédié. J’avoues ne pas toujours avoir été un fan de leurs offres.

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.

Les différents types de nuages

Après avoir tenté de définir le cloud computing et avoir évoqué les différentes technologies associés, nous allons nous intéresser aux différentes offres. Nous nous intéresserons à toutes les offres de la nature qui revendiquent un caractère de « cloud computing ».

Nous distinguerons trois types de nuages. Le premier type, également le premier à être apparu sous la dénomination « cloud », est le nuage public. Le second type est le nuage privé. Le dernier type est un mélange des deux, c’est à dire, un nuage privé-public.

Le nuage public

La dénomination de « cloud computing » est arrivée en même temps que les grands nuages publics. Ces grands systèmes informatiques ont été rendus viables grâce à une forte automatisation et une grande efficacité des couches de virtualisation.

Dans ce type de nuage, chaque client se voit attribuer plus ou moins aléatoirement une machine virtuelle dans laquelle il pourra faire ce qu’il souhaite. Ces machines virtuelles sont soumises aux contraintes définies par l’hébergeur en fonction de ses conditions générales de vente. Chaque machine virtuelle est sensée être l’égale d’une autre et le client n’a que très peu d’amplitude pour la construction d’une véritable architecture.

Les nuages publics existant aujourd’hui ont essentiellement vocation à être des plateformes d’hébergement grand public à la manière d’OVH sur le marché des serveurs dédiés. Pour que cette comparaison soit valable, il est nécessaire d’exclure la diversification des offres d’OVH avec notamment la possibilité d’obtenir un firewall Cisco ASA. Il est peu probable qu’il soit possible d’insérer un Cisco ASA dans un grand nuage public.

La présence de l’open source dans les nuages public est très forte, surtout à travers de Xen. Amazon, Gandi, 1&1 et Rackspace sont tous basés sur Xen. Le marché des grand nuages public a peu de chance de voir une réelle présence de VMWare à cause de sa tarification. Je vous laisse imaginer le prix d’un cloud public VMWare…

Le nuage privé

Les nuages privés sont clairement orientés vers les entreprises. Il parait particulièrement improbable de voir une quelconque entreprise confier la totalité de ses données et de l’infrastructure informatique à une nébuleuse telle qu’Amazon.

Il me semble que la notion de nuage privé est quasiment équivalente à la notion de plateforme de virtualisation interne à une société. Dans ce type de nuage, la notion de « cloud computing » semble floue et la distinction avec une plateforme de virtualisation semble mince voire inexistante.

L’open source a un rôle à jouer sur ce type de nuages mais l’état actuel des choses ne le facilite pas. L’automatisation d’une plateforme Xen ou KVM nécessite un travail de développement conséquent même si des outils tels que le Xen Cloud Platform vont dans le bon sens. VMWare est désormais très présent sur le marché avec ses produits d’administration et d’automatisation VSphere et Virtual Center.

Le nuage privé-public

Le nuage privé-public est un nuage privé inséré dans une plateforme public. Ce type d’offre est encore relativement rare car le concept est plutôt récent.

Cette notion semble relativement équivalente à la notion de nuage privé placé dans le cadre d’une offre d’infogérance. Bien que les offres placées sous la dénomination « nuage privé-public » sont rares, les plateformes de virtualisation infogérées sont monnaie courante aujourd’hui.

Au final, je pense avoir fait le tour des différentes configurations de « cloud computing » que l’on peut retrouver aujourd’hui. Je pense également que toutes ces offres ne sont pas réellement révolutionnaires contrairement à ce que bon nombre de commerciaux souhaiteraient nous faire croire.

Quelques outils de diagnostic DNS

Le DNS (Domain Name System) est un service exceptionnellement critique de n’importe quel réseau et de l’Internet. Cette semaine, j’ai eu l’occasion de plancher sur de nombreuses problématiques DNS dans le cadre de la fusion de deux serveurs DNS assez conséquents.

Dans cet article, je parlerais uniquement de BIND car il s’agit de la référence en terme de serveurs DNS. Je supposerais également que vous utilisez Linux. Et oui, BIND ça fonctionne également sous Windows. Je l’ai même déjà en production sur du Windows… Cela fait un petit pincement au coeur je vous assure.

dig

Le premier outil totalement indispensable est la commande dig. Elle permet d’interroger sélectivement des serveurs DNS. De plus, elle affiche une bonne quantité d’information quant à la requête effectuée. Cette commande sera donc particulièrement utile pour vérifier le bon fonctionnement de votre serveur DNS.

antoine@ks:~$ dig @ns0.infoclip.fr www.infoclip.fr
; <<>> DiG 9.3.4-P1.2 <<>> @ns0.infoclip.fr www.infoclip.fr
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47195
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; QUESTION SECTION:
;www.infoclip.fr.               IN      A
;; ANSWER SECTION:
www.infoclip.fr.        86400   IN      A       217.25.177.18
;; AUTHORITY SECTION:
infoclip.fr.            86400   IN      NS      ns0.infoclip.fr.
infoclip.fr.            86400   IN      NS      ns1.infoclip.fr.
;; ADDITIONAL SECTION:
ns0.infoclip.fr.        86400   IN      A       217.25.176.28
ns0.infoclip.fr.        86400   IN      AAAA    2001:1650:0:1001::2
ns1.infoclip.fr.        86400   IN      A       194.29.206.67
;; Query time: 5 msec
;; SERVER: 217.25.176.28#53(217.25.176.28)
;; WHEN: Fri Feb 12 10:23:54 2010
;; MSG SIZE  rcvd: 145

host

La commande host est un outil particulièrement utile pour créer des scripts utilisant des informations DNS. Elle permet d’afficher très simplement des informations en rapport avec un nom de domaine telles que les serveurs DNS d’autorité, les MX ou le SOA.

antoine@ks:~$ host -t MX lemonde.fr

lemonde.fr mail is handled by 5 smtp0.lemonde.fr.

lemonde.fr mail is handled by 10 smtp1.lemonde.fr.

antoine@ks:~$ host -t ns lemonde.fr

lemonde.fr name server nsc.bookmyname.com.

lemonde.fr name server nsa.bookmyname.com.

lemonde.fr name server nsb.bookmyname.com.

antoine@ks:~$ host -t soa lemonde.fr

lemonde.fr has SOA record nsa.bookmyname.com. hostmaster.bookmyname.com. 1265963399 43200 3600 604800 3600

named-checkconf

L’outil named-checkconf est fourni avec BIND par défaut mais semble relativement peu connu. Cet utilitaire permet de vérifier la syntaxe d’un fichier de configuration. En sachant que BIND est assez peu tolérant des erreurs, cet outil vous évitera quelques mauvaises surprises.

named-checkconf /etc/named.conf

named-checkzone

Une fois que la configuration de BIND est correcte, il est intéressant de vérifier les zones. Je pense que cette vérification doit être périodique car les erreurs passent facilement inaperçue dans les zones. Cet utilitaire va vérifier la syntaxe de vos zones.

named-checkzone domaine.tld /var/named/domaine.tld

Au final, je pense que ces quelques outils devraient vous permettre de pouvoir mieux diagnostiquer d’éventuels soucis de résolutions de noms de domaine.