Nous sommes donc un fournisseur de "Cloud Computing", même si ce terme n'est pas (encore) saupoudré partout sur notre site et nos documentations, au grand dam de nos communiquants. La référence actuelle étant Amazon EC2 , nous nous sommes demandés comment nous nous situions par rapport à ces derniers.
Spoiler : nous nous situons très bien, même un peu au dessus. Ce qui est très satisfaisant puisque notre infrastructure d'hébergement est avant tout une commodité (sophistiquée et maîtrisée au bit près, certes) qui nous permet de vendre de l'adminsys surentraîné au kilo. Nous travaillons également sur des instances Amazon EC2, ce bench n'est donc pas teinté de concurrence hostile.
Configuration
Ce benchmark a fait l'objet de nombreux essais, critiques et ajustements. Il a été réalisé entre 26 janvier et le 15 mars 2011 par l'ours Valentin Schmitt (aka 'bibi ) sous l'œil critique de votre serviteur.
Benchmark est un grand mot : nous avons comparé deux instances de serveurs populaires sur une charge particulière (compilation du noyau Linux) et observé quelques métriques simples. Quelques remarques :
- Ce n'est pas notre charge typique , nous hébergeons surtout des services (web et autres) et la sollicitation est externe; mais utiliser un test de charge implique de mesurer également les capacités du réseau, et nous ne voulions mesurer qu'un élément à la fois
- Amazon et Bearstech utilisent Xen ; le premier Xen 3.1 semble-t-il, pour notre part Xen 3.2 (et déjà une poignée de 4.0 en production à l'heure où je vous parle)
- Bien entendu nous avons déployé exactement le même OS avec la même configuration dans chaque camp (Debian 5.0 "Lenny" 64 bits, base install )
- Bearstech préfère les I/O locales (SAS) pour les hautes perfs, et elles sont persistantes. Amazon ne fournit que les I/O distantes EBS (iSCSI) pour les hautes perfs et la persistence. En effectuant des mesures de débit en lecture/écriture séquentielle nous avons constaté que cette différence avait peu d'impact. Le bout de la chaîne est le déterminant : SAN ou contrôleur RAID, et bien sûr les disques.
On compare donc deux systèmes très similaires, ce qui est rare dans le monde du benchmark où l'on adore comparer les choux et les carottes. Mais on le fait avec une charge peu représentative de notre métier principal. La méthodologie et le résultat restent corrects et intéressants.
Amazon EC2 | Bearstech | |
---|---|---|
Server model | "m1.large" | Dell R410 |
CPU | 2x Xeon E5430 2.66GHz (6GB cache) | 2x Xeon L5335 2.00GHz (4GB cache) |
Memory | 7.5 GB | 7.5 GB |
Storage | EBS (SAN via iSCSI) | RAID1 SAS 10 krpm |
Nous n'avions pas les mêmes modèles de CPU en stock, nous avons pris le plus proche. Nous utilisons toujours les versions "Low voltage" des Xeon Intel afin de minimiser notre consommation d'énergie. Comme décrit plus loin, cette différence a été prise en compte dans les résultats.
Tests
Le test consiste à compiler le noyau Linux 2.6.32 avec toutes les options activées ( make allyesconfig
), avec un niveau de parallélisme variable (de 1 à 16 threads simultanés). L'idée est d'observer la " scalabilité " du serveur : soit les performances tendent vers une valeur constante quel que soit le nombre de threads simultanés (c'est bien), soit elles chutent ou s'écroulent (c'est mal).
Pour chaque test, le temps total consacré au CPU côté utilisateur ( user ), temps CPU côté noyau ( system ) et le temps passé à attendre les I/O ( wait ) ont été collectés avec la commande time
. Nous n'avons pas relevé le temps inutilisé ( idle ), il peut se lire en creux dans les diagrammes ci-dessous.
Les modèles CPU EC2 et Bearstech étant de la même marque et de la même génération, nous avons considéré qu'il était correct et pertinent de corriger les résultats obtenus de manière proportionnelle aux performances des CPUs . Nous avons pris bien soin à corriger uniquement les temps CPU (user, system) et non les temps liés aux I/O (wait). Nous publions ici la feuille de calcul complète au format Gnumeric pour vous permettre de vérifier notre approche.
Résultats
Voici sans plus attendre les résultats, avec représentés sur la même échelle les mesures Amazon EC2 puis celles des serveurs Bearstech. Les meilleurs résultats sont ceux avec les temps les plus courts .
Avant de nous intéresser aux différences, regardons les similitudes : les résultats des deux infrastructures sont très proches, autant en temps total qu'en répartition des temps passés (user, kernel, I/O wait). Amazon et Bearstech semblent faire du Cloud Computing aussi bien, ou aussi mal selon votre point de vue ! Plus sérieusement, connaissant la qualité du matériel et la disponibilité de nos ressources virtualisées, nous sommes agréablement surpris par les performances Amazon qui sont souvent sujet à caution.
Les solutions Amazon EC2 et Bearstech ont également de bonnes caractéristiques de montée en charge : en particulier lancer deux tâches en parallèle permet de diviser le temps total d'exécution par deux, c'est la définition de la "scalabilité" idéale.
La charge utilisée n'est pas entièrement parallélisable, et surtout concourt à générer des I/O sur le même volume : on ne va donc pas pouvoir généraliser la règle, au delà d'un certain niveau de parallélisme, les performances sont limitées par celles du système de stockage. C'est le cas dès 3 tâches parallèles, ce qui sous-tend que le système de stockage EBS d'Amazon est comparable au RAID1 utilisé couramment par Bearstech; mais nous pouvons également doubler les performances avec du RAID10 (tous nos serveurs ayant 4 ou 6 disques hotplugs).
Au delà de 3 tâches simultanées, il est intéressant de constater un écart significatif : l'infrastructure Bearstech permet d'améliorer ou maintenir les performances, tandis que l'instance EC2 les dégrade légèrement . Les écarts en valeur absolue se creusent alors, et l'infrastructure Bearstech est plus performante. Les applications webs étant fortement parallélisables (surtout l'interprétation de leur code, en PHP, Ruby, Python, etc.), cette propriété est très importante pour garantir les performances de nos solutions d'hébergement.
Nous avons collectées plus d'informations sur l'utilisation des CPUs et des I/O, mais elles ne donnent lieu qu'a des spéculation peu significatives en l'absence de spécifications "officielles" de l'infrastructure Amazon, en particulier EBS (bien que ce compte-rendu de panne d'EBS donne une idée).
Au delà de notre léger avantage niveau performances relevées par ce benchmark, nous souhaitons surtout mettre l'accent sur le niveau de service : nous pouvons garantir l'allocation exclusive et la disponibilité des ressources, et surtout une équipe d'adminsys/développeurs avec 5 ans d'expérience est dispo 24/7 pour s'occuper de votre plateforme. Notre expérience montre que l'indisponilité des sites est majoritairement dûe à des problèmes applicatifs (bugs, surcharge, panne de service tiers, etc.) et minoritairement à des problèmes de plateforme (serveur, réseau).