Commodity

Hardware
 ARCHITECTURE / COMMODITY HARDWARE

Description
Bien quinvisibles depuis nos navigateurs, des millions de serveurs
fonctionnent continuellement pour que le Web reste disponible 24h/24.
Mme si les chiffres restent confidentiels, certains grands acteurs du
Web peuvent avoir des dizaines, des centaines de milliers de machines
comme EC2[1] voire aux alentours de un million chez Google[2]. La
mise en uvre dun si grand nombre de machines reprsente un dfi
technique mais surtout conomique.
La grande majorit de ces acteurs ont relev ce dfi en utilisant
du matriel de grande srie, du commodity hardware
terme que nous allons prciser par la suite.

Cest lune des raisons qui conduit les gants du Web utiliser un
agencement de nombreuses machines de grande srie la place dun seul
grand systme. Un seul service aux utilisateurs, une seule application,
peut ainsi sexcuter sur des centaines de machines. On parle ce
niveau-l de Warehouse Scale Computer[3], des centaines de machines
prenant la place dun seul serveur.

Les besoins mtiers

Les gants du Web ont en commun un certain nombre de problmatiques,

voques dans divers autres chapitres[4] :

Un business model li lanalyse dnormes quantits de donnes

par exemple indexer le Web (soit prs de 50 milliards de pages).

Des enjeux forts de performance pour que les temps de rponse

restent faibles.

Une rmunration indpendante de la quantit de donnes

stockes : publicit, facturation de lutilisateur au forfait.

[1] Source SGI.

[2] L encore, les estimations restent complexes.
[3] Ce concept a t largement dcrit par ce trs long papier Data Center as a Computer dont
nous ne reprenons ici que quelques concepts.
[4] cf. en particulier Sharding , p. 163.

> retour table des matires

153
LES GANTS DU WEB

Les revenus comme la publicit ne sont pas linaires avec le nombre

de recherches et, ramens une requte unitaire, restent faibles[5].
Comparativement, les cots unitaires sur des grands serveurs traditionnels
restent trop levs. Lenjeu est donc fort de trouver les architectures avec
les cots par transaction les plus faibles.

Enfin, les ordres de grandeur des traitements mis en uvre par les gants
du Web sont sans commune mesure avec les traitements traditionnels
dinformatique de gestion dont le nombre dutilisateurs tait jusque-l
born par le nombre demploys. Aucune machine, aussi grosse soit-elle,
ne sera en mesure de rpondre leurs besoins.

En somme, ces acteurs ont besoin de scalabilit (cot marginal par

transaction constant), ce cot marginal devant rester faible.

Machine de grande srie contre serveur haut de gamme

Lorsque la question de la scalabilit se pose, deux grandes alternatives

sopposent :

Le scale-up, ou croissance verticale, consiste utiliser une machine

plus performante. Cette approche a t historiquement utilise du
fait de sa simplicit de mise en uvre et parce que la loi de Moore
permettait aux constructeurs doffrir rgulirement des machines
plus puissantes pour un prix constant.

Le scale-out, ou scalabilit horizontale, consiste mettre en

commun les ressources de plusieurs machines qui peuvent tre
unitairement moins puissantes. Il ny a alors plus de limite lie la
taille de la machine.

Or, les composants, technologies et architectures issus du monde du PC

offrent un ratio puissance/prix trs avantageux. Leur relativement faible
puissance de calcul par rapport des architectures plus efficientes telles que
les architectures RISC est compense par des prix plus faibles du fait de la
production en grande srie. Ainsi une tude mene partir de rsultat du
TPC-C[6] montre un cot relatif la transaction trois fois moins lev pour un
serveur dentre de gamme que pour un serveur haut de gamme.

[5] Early on, there was an emphasis on the dollar per (search) query, [Urs] Hoelzle said. We
were forced to focus. Revenue per query is very low. > http://news.cnet.com/8301-1001_3-
10209580-92.html
[6] Ibid, [3] page prcdente.

> retour table des matires

154
 ARCHITECTURE / COMMODITY HARDWARE

Aux chelles mises en uvre par les gants du Web plusieurs milliers de
machines coordonnes pour excuter une seule fonction dautres cots
deviennent extrmement importants : puissance lectrique, climatisation,
m. Le cot par transaction doit englober ces diffrents aspects.

Ce sont ces constats qui ont amen les gants du Web privilgier la
croissance horizontale (scale-out) base de commodity hardware.

Chez qui a fonctionne ?

La quasi-totalit des gants du Web : Google, Amazon, Facebook,
LinkedIn utilisent aujourdhui des serveurs de type x86 et du commodity
hardware. Cependant lutilisation de tels composants introduit dautres
contraintes et ces Data Centers As A Computer ont des contraintes
dchelle diffrentes de nos datacenters. Cest ce sur quoi nous allons
nous pencher plus en dtail.

Des caractristiques matrielles impactantes pour la

programmation
Les architectures serveurs traditionnelles visent, autant que le permet
le hardware, prsenter au dveloppeur une architecture thorique
avec un processeur, une mmoire centrale contenant le programme et les
donnes, et un systme de fichiers[7].

La programmation que lon connat base de variables, dappels de

fonctions, de threads et de processus ncessite de faire cette hypothse.

Autant les architectures des grands systmes sont proches de cette

architecture thorique , autant un ensemble de machines dans un
datacenter sen loigne.

Les machines de type SMP (Symetric Multi Processor), utilises dans une
optique de scale-up, permettent aujourdhui dutiliser la programmation
standard (avec accs toute la mmoire et tous les disques de faon
uniforme).

[7] Cette architecture est connue sous le nom darchitecture de Von Neumann.

> retour table des matires

155
LES GANTS DU WEB

Figure 1 (modifie). Source RedPaper 4640, page 34.

En effet, les chiffres sur le schma montrent leffort fait pour que les dbits
et les latences soient sensiblement identiques entre un processeur, sa
mmoire et ses disques, quils soient connects directement, connects
sur le mme processor book[9] ou sur des processor books diffrents. Sil
reste une caractristique NUMA (Non Uniform Memory Access : un accs
la mmoire proche est plus rapide que laccs la mmoire dans une
autre partie du systme), celle-ci se concentre sur la mmoire centrale
avec des diffrences de latence et de bande passante dans un ratio 1

[9] Un processor book est un compartiment regroupant processeurs, mmoire et connecteurs

dentre sortie, comparable en premire approche une carte mre. Les grands systmes
SMP sont constitus dun ensemble de ces compartiments relis entre eux par une seconde
carte : le midplane.

> retour table des matires

156
 ARCHITECTURE / COMMODITY HARDWARE

2. Les systmes dexploitation et middlewares comme Oracle prennent

leur charge ces disparits.

Dans une optique de scale-out, un programme sexcutera non plus

sur un seul grand systme mais sur un ensemble de machines que ce
programme coordonnera pour remplir cet objectif. Cet agencement de
machines de commodity hardware offre une vue bien diffrente dune
architecture thorique pour le dveloppeur :

Figure 2. Source Data Center As A Computer page 8

L1$ : cache de niveau 1, L2$ : cache de niveau 2.

> retour table des matires

157
LES GANTS DU WEB

Ainsi, ds que lon passe par le rseau pour accder une donne sur
un autre serveur, les temps daccs augmentent et le dbit diminue dun
rapport 1.000. Par ailleurs, les quipements rseau en entre du datacenter
constituent le facteur limitant par rapport la bande passante agrge de
toutes les machines.

Par consquent, pour optimiser les temps daccs et les dbits au sein
du datacenter, il faut rpartir de faon pertinente les donnes et les
traitements entre les serveurs (notamment pour viter de distribuer des
donnes couramment accder ensemble entre plusieurs machines). Or,
les systmes dexploitation et les couches middleware traditionnelles ne
prennent pas en charge ce type de fonctionnement. Il est donc ncessaire
de les traiter au nouveau applicatif. Cest prcisment l quinterviennent
les stratgies de sharding[10].

La partie frontale des services, servir les pages Web, saccommode assez
facilement de ces contraintes du fait du caractre sans tat et facilement
routable des requtes HTTP entre plusieurs machines. Les autres applicatifs
devront par contre, grer explicitement les changes rseau ou se baser
sur des nouvelles couches middleware spcifiques. Les problmatiques
de stockage sur ce genre de matriel sont mises en uvre chez les gants
du Web galement avec des techniques de sharding.

La prise en charge de la tolrance aux pannes

La seconde diffrence marquante entre les grands systmes et les

Warehouse Scale Computers concerne la tolrance aux pannes. Les grands
systmes ont au fil des dcennies propos des mcanismes avancs au
niveau hardware pour rduire au maximum le nombre de pannes (RAID,
changement chaud de matriel, rplication au niveau SAN, correction
derreur et failover au niveau mmoire et I/O, etc.). Un Warehouse Scale
Computer possde la caractristique inverse pour deux raisons :

Les composants commodity hardware sont moins fiables,

La disponibilit globale dun systme mettant en uvre

simultanment plusieurs machines est le produit de la disponibilit
de chaque serveur[11].

[10] cf. sharding , p. 163.

[11] Ainsi si chaque machine a une indisponibilit annuelle de 9 heures, la disponibilit de 100
serveurs sera au mieux de 0,999100 0,90%, soit 36 jours dindisponibilit par an !

> retour table des matires

158
 ARCHITECTURE / COMMODITY HARDWARE

Cela conduit les gants du Web considrer que le systme doit pouvoir
fonctionner continuellement avec certains composants en panne. L
encore, la couche applicative est responsable dassurer cette tolrance
aux pannes (cf. Design for Failure p. 189).

Quels sont les critres de choix de ces machines ?

Pour autant, les machines retenues par les gants du Web ne

ressemblent pas toujours nos PCs ni mme aux serveurs x86 des
grands constructeurs comme HP ou IBM. Google est sans doute
lexemple le plus marquant dans le sens o il fabrique lui-mme ses
machines. Les autres grands acteurs, comme par exemple Amazon,
font appel des constructeurs plus spcialiss comme SGI[12].

Le premier critre de choix de leurs serveurs est bien sr le prix.

Lajustement des composants au plus prs de leurs besoins et le grand
nombre de serveurs achets permet aux gants du Web davoir un fort
pouvoir de ngociation. Bien que les chiffres restent confidentiels, on
estime que le prix dun serveur peut descendre jusqu 500 $ chez eux.

Le second critre de choix est li la consommation lectrique. Aujourdhui

du fait du trs grand nombre de serveurs utiliss, la consommation
lectrique devient lun des postes de dpense les plus importants.
Rcemment Google communiquait sur une puissance moyenne denviron
260 millions de watts soit une facture de lordre de 30.000 $ par heure.
Le choix des composants mais galement la capacit paramtrer trs
finement la consommation de chaque composant permet dconomiser
des montants considrables.

Au final, mme sils sont constitus de composants issus du monde

du PC, la composition et le paramtrage de ces serveurs sont assez
diffrents. Hormis quelques initiatives comme OpenCompute de la part
de Facebook, ces dtails restent jalousement gards par les gants du
Web. Tout au plus peut-on savoir que, chez Google, ils ont remplac
les onduleurs centraliss de courant continu par des batteries de 12V
directement au niveau des serveurs[13].

[12] SGI est aujourdhui issu de la fusion de Silicon Graphics, Cray et surtout Rackable qui
possdait lexpertise dans les serveurs x86.
[13] > http://www.youtube.com/watch?v=Ho1GEyftpmQ

> retour table des matires

159
LES GANTS DU WEB

Exceptions !
Les exemples de gants du Web communiquant sur des technologies
hors x86 sont quasi inexistants. Si lon remontait un peu dans le temps, on
pourrait trouver un logo Powered By Sun chez Salesforce[14].

Et chez moi ?
Le down sizing[15] cest--dire la volont de remplacer les serveurs
centraux par des machines plus petites a connu son heure de gloire dans
les annes 90. Lobjectif nest pas ici de plbisciter de la mme faon le
commodity hardware mme si au premier abord on pourrait penser que le
x86 a envahi toute lentreprise. Le choix extensif du commodity hardware
va plus loin que cela en transfrant sur lapplicatif la responsabilit de la
scalabilit et de la tolrance aux pannes.
trs grande chelle, comme chez les gants du Web, lorsque les cots
lectriques et dinvestissement deviennent dterminants, il sagit de la
seule solution viable. Pour des applications existantes pouvant se conten-
ter des ressources dun seul gros serveur multiprocesseurs, le cot du (re-)
dveloppement en systme distribu et le cot du hardware viennent par-
fois squilibrer dans les SI.

Lutilisation du commodity hardware dans votre entreprise doit donc sins-

crire dans un choix darchitecture global : privilgier le dveloppement
existant avec des machines plus haut de gamme ou ladapter pour migrer
(entirement) sur du commodity hardware. En pratique des applications
conues pour la distribution telles des frontaux Web migreront facilement.
linverse des applications fortement intgres comme des progiciels
ncessiteront forcment une infrastructure spcifique avec redondance
des disques peu compatible avec un datacenter commodity hardware tel
que ceux conu chez les gants du Web.

[14] > http://techcrunch.com/2008/07/14/salesforce-ditch-remainder-of-sun-hardware

[15] > http://fr.wikipedia.org/wiki/Downsizing_(informatique)

> retour table des matires

160
 ARCHITECTURE / COMMODITY HARDWARE

Patterns connexes
Linformatique distribue est donc indispensable lutilisation du commodity
hardware. Des patterns comme le sharding (cf. Sharding p. 163) doivent
ncessairement tre implments dans le code pour pouvoir mettre en
uvre du commodity hardware pour le stockage de la donne.

Lutilisation de trs nombreuses machines complexifie galement

ladministration des serveurs, rendant ncessaire des patterns comme
DevOps (cf. DevOps p. 63).
Enfin, cette propension quont les gants du Web concevoir des
ordinateurs ou plutt des datacenters adapts leurs besoins renvoie
bien sr la prfrence build vs buy (cf. Build vs Buy p. 19).

> retour table des matires

161