FLASH INFORMATIQUE FI



Emballages




Laurent KLING


Comment maîtriser la consommation énergétique de l’informatique ?

À l’approche des fêtes de fin d’année, recommence la ribambelle d’achats qui seront immolés au dieu Noël dans un grand sacrifice d’emballages déchirés. Un des effets bénéfiques de la Commission Européenne est d’avoir limité la taille des emballages de jeu vidéo au contenu. Avant cette réglementation, le consommateur se retrouvait devant un emballage imposant ne comportant qu’un CD d’installation !

Dans le domaine de l’informatique, il arrive souvent que certains fabricants emballent le composant dans une débauche de contenants. Le magazine électronique The Register décrit avec humour les errements de la société de l’information dans sa rubrique Odds & Sods, littéralement bric-à-brac. Un article a retenu mon attention en juillet 2009 : www.theregister.co.uk/2009/07/29/aboxalypse_now/
Avec la même joie enfantine du lendemain de Noël, imaginons l’organisation logistique qui a conduit l’envoi de 9 puces informatiques dans 9 emballages antistatiques contenus dans 9 cartons eux-mêmes contenus dans 9 boîtes finalement transportées avec beaucoup de soin dans 2 cartons.
Dans ce cas, le cadeau pour l’environnement provient de Sony. Naturellement, les autres fabricants ne sont pas en reste dans cette débauche de contenants, je vous propose de regarder avec délectation le déballage d’une carte PCI : www.theregister.co.uk/2009/07/29/aboxalypse_now/page4.html

Informatique et contenants

Cette thématique des fêtes nous renvoie à un sujet sérieux, le rapport entre le contenant et le contenu. À un point inimaginable maintenant, les romans de Dickens et de Zola nous décrivent ce ciel noir en plein jour parsemé d’escarbilles incandescentes dues à la machine à vapeur qui a profondément modifié le paysage humain du 19e siècle.
Quelle sera la vision entraînée par l’ubiquité de l’information dans notre société ?
La puissance consommée par les centres de calcul atteint des niveaux importants, particulièrement si l’on tient compte de l’énergie électrique dépensée dans l’évacuation de la chaleur.
Dans le milieu académique, nous n’imaginons pas de recherche sans informatique, dans le domaine de l’ingénierie, c’est un lieu commun d’utiliser des ressources substantielles. Il est probable qu’un des plus grands consommateurs soit la société Google ; en effet, elle a réussi l’exploit de rendre un outil indépendant du nombre d’usagers, un paradoxe ? En fait, ce détachement entre la demande et le temps de réponse (qui reste en général inférieur à 0.7 seconde pour une recherche avec Google) est bâti sur une machinerie gigantesque, des centres de calcul à l’échelle industrielle qui renvoient nos locaux serveurs à la dimension d’échoppes artisanales.
La description de cette infrastructure est un secret bien gardé, heureusement quelques bribes d’informations parviennent ici et là à percer ce voile du secret.
Jeff Dean, Google Fellow, décrit avec beaucoup de détails le fonctionnement des systèmes distribués utilisés par Google et leur mise en place : www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf.
Quelques éléments sont particulièrement intéressants à l’aune de nos besoins.

Le temps, le seul élément inéluctable

Dans la vision de Jeff Dean, cette variable immuable prend une clarté insoupçonnée, ramenez sur une échelle exponentielle l’ensemble des briques composant l’édifice informatique.

[1]Référence dans le cache primaire L10.5 ns
[2]Calcul prédictif de saut erroné5 ns
[3]Référence dans le cache secondaire L27 ns
[4]Mécanisme de synchronisation (Mutex lock/unlock)25 ns
[5]Référence dans la mémoire vive100 ns
[6]Comprimer 1Ko avec Zippy3’000 ns
[7]Envoyer 2Ko sur un réseau 1 Gbps20’000 ns
[8]Lire séquentiellement 1 Mo depuis la mémoire vive250’000 ns
[9]Temps de latence circulaire dans un centre de calcul500’000 ns
[10]Disk seek 10’000’000 ns
[11]Lire séquentiellement 1 Mo depuis un disque20’000’000 ns
[12]Envoyer un paquet aller-retour entre la Californie et les Pays-Bas150’000’000 ns

Composants et durées - Les nombres que chacun devrait connaître (Numbers Everyone Should Know)

Sur le tableau ci-dessus les seuils utilisés peuvent paraître curieux, quelques explications : Le composant élémentaire est le processeur, maintenant la puce possède plusieurs copies dans le même boîtier. Au centre, se trouvent les registres et l’unité de calcul. Ils sont reliés à une mémoire ultrarapide, la mémoire-cache de premier niveau L1. Une technique de base en informatique est l’indirection, c’est-à-dire que la case de la mémoire vive ne contient pas une valeur, mais l’adresse de la valeur, c’est le pointeur familier au programmeur.
Dans ce cas, c’est la durée pour exécuter un pointeur en mémoire-cache de 1er niveau [1]. Pour le cache de 2ème niveau, qui est inclus dans le processeur, la durée est 14 fois plus longue [3]. Avec la mémoire vive, la durée est 200 fois plus longue [5]. Comme le flux d’instructions est séquentiel avec des ruptures, les processeurs peuvent prédire statistiquement quand aura lieu un saut, naturellement ce calcul peut être faux [2]. Quand vous travaillez avec des flux d’instructions simultanées, il vous faut un sémaphore qui va éviter un carambolage en utilisant un mécanisme d’exclusion mutuelle, Mutex [4].
Par principe, l’information est encodée dans un ordinateur (il ne comprend que des 0 et 1). En général, ces codages sont linéaires, par exemple les 26 lettres de l’alphabet nécessitent 26 positions. Cependant, certaines lettres sont plus souvent utilisées, les voyelles. Un algorithme utilise ce simple constat pour comprimer l’information en allouant une taille variable à chaque lettre, minimale aux lettres très utilisées, maximale aux lettres peu utilisées. Ce principe s’appelle une compression LZW et elle est particulièrement efficace sur du texte, 90% de compression [6].
Pour continuer dans la mémoire, il est intéressant de constater la différence de vitesse pour lire 1 Mo entre la mémoire vive [8] et le disque [11], 80 fois plus lent. Le disque est lui-même handicapé par la vitesse pour accéder à un bloc précis de données, le seek-time [10].
Pour le réseau, comparons la durée de transmission d’une faible quantité d’informations 2 Ko [7] avec la durée d’un signal pour parcourir le réseau informatique local qui est le temps de latence circulaire [9]. Et sur un plan planétaire un aller-retour transatlantique et trans-américain [12].

JPEG - 4.8 ko
Architectural view of the storage hierarchy
JPEG - 9.7 ko
Architectural view of the storage hierarchy

Une compréhension fine de l’architecture

À mes débuts dans l’informatique, la mémoire vive était particulièrement limitée et les vitesses de processeurs relativement faibles (mémoire de 1 Ko, vitesse de 1 MHz).
Naturellement, le seul langage disponible était le langage machine introduit en hexadécimal, l’assemblage étant réalisé manuellement. Dans cet environnement, le nombre de cycles nécessaires pour accomplir une instruction devient important, l’optimisation étant un passage obligé.
Aujourd’hui, les programmeurs utilisent des langages symboliques, apparemment la mémoire disponible est illimitée et le calcul peut utiliser des ressources réparties sur de nombreux coeurs. Cette abondance ne peut cacher que tout programme s’exécute par un déroulement séquentiel d’instructions dans un nombre limité de registres.

Une architecture hiérarchique pour le matériel

Le débit et la vitesse sont indissociables, une structure pyramidale des composants selon leurs temps d’accès et leurs écoulements permet de construire une architecture viable.
Régulièrement, j’essaye de rendre attentifs les usagers à la taille des pages Web, mais tout aussi régulièrement les créateurs de page Web tournent en dérision ces conseils, car sur leur ordinateur, le temps d’affichage est faible !
En 2005, j’ai écrit dans un article sur la méthode pour optimiser la bande passante et donc accroître la vitesse d’accès et le confort : css2 ou Gutenberg retrouvés : « Le point de comparaison ultime me paraît être Google. On est particulièrement surpris de la différence faible qui existe pour la page principale de Google, 13’130 octets, et celle obtenue après une recherche sur le mot clé STI, 13’316 octets. Ce tour de force est possible par l’absence d’objets externes autres que les 4 images GIF. L’inclusion de la feuille de style dans le fichier HTML évite le retard issu par l’appel de l’objet. »

Dans cette réalité, les conseils de Jeff Dean peuvent surprendre :

  • connaître le temps de calcul de ces composants,
  • écrire des microbenchmarks,
  • encoder et compresser les données pour économiser la bande passante,
  • construire une architecture commune,
  • maîtriser son infrastructure pour identifier rapidement les éléments qui fonctionnent et ceux qui posent problème,
  • anticiper la montée en charge, être capable d’accepter 10x ou 20x l’objectif initial.

Son attitude est à l’opposé de l’approche parfois utilisée dans des projets informatiques : à partir d’un besoin,

  • on analyse sommairement les principes sous-jacents,
  • on réutilise l’outil informatique qu’on connait déjà,
  • on propose un calendrier qui ne tient pas compte des aller-retour nécessaires,
  • on passe beaucoup de temps sur l’interface utilisateur, c’est visible, cela doit être simple !

Et au bout du compte, personne n’est content...

Naturellement mon trait est grossier, et généralement l’entreprise se déroule harmonieusement. Cependant, la méthode de Jeff Dean est particulièrement séduisante, car elle implique qu’un projet informatique réussi se base sur une architecture maîtrisée, des attentes mesurées et finalement un usager qui ne se préoccupe pas de l’infrastructure, le fonctionnement étant harmonieux.

Une manière différente de penser

Goggle possède de nombreuses briques logicielles, deux sont très intéressantes :

  • MapReduce,
  • GFS.

MapReduce


JPEG - 20.7 ko
MapReduce pour GoogleMap

Dans notre vision classique des structures de données, nous bâtissons une architecture organisée autour des points suivants :

  • récolter les données,
  • les caractériser,
  • les conserver dans des tables,
  • créer les index nécessaires,
  • générer une requête,
  • obtenir le résultat,
  • le trier,
  • présenter le résultat.

La vision de MapReduce est fondamentalement différente :

  • lire beaucoup de données peu ou pas structurées,
  • Map : extraire les données nécessaires,
  • les trier,
  • Reduce : réduire et agréger les données utiles,
  • écrire le résultat.

Naturellement, cette approche ne convient pas pour tous les types de données, mais elle est particulièrement efficace dans le cas d’une recherche non structurée !

GFS

La conservation des données est un élément essentiel de notre vie numérique. Traditionnellement, le périphérique de stockage est le disque dur. Chaque disque dur contient au moins :

  • une tête de lecture-écriture,
  • un plateau divisé en secteurs et en pistes.

L’unité élémentaire de mesure de cette architecture est un bloc de 512 octets. Sur cette infrastructure physique, le système d’exploitation va écrire une organisation logique, un filesystem, cette action est appelée formater, même si maintenant le formatage ne se fait pas au niveau physique. Chaque filesystem est spécifique, il permet de gérer au mieux l’entassement des données dans le support. Naturellement on espère que l’opération inverse va se dérouler correctement !
En pratique, le même support conserve les données et les structures, la taille des blocs logiques est petite (de 1 à 32 blocs disque). Les données sont présentées hiérarchiquement sous la forme de dossiers et fichiers similaires à un classement humain. En général, le filesystem ne possède pas d’informations sur la qualité des données (métadonnées).
De par sa nature mécanique, malgré des progrès prodigieux en fiabilité, le disque dur peut tomber en panne. Un informaticien chevronné va même écouter le disque pour vérifier que le fonctionnement est harmonieux. Pour se prémunir contre une défaillance d’un disque, on met en place des systèmes de tolérance de panne.
Dans le cas de la recherche sur Internet, le volume de données est considérable, Google File System utilise une approche différente :

  • les blocs logiques sont très volumineux, 64 Mo,
  • chaque bloc logique possède un identifiant unique,
  • chaque bloc est dupliqué sur 2 disques différents,
  • les métadonnées ne sont pas conservées avec les blocs logiques,
  • dès qu’un disque est défaillant, tous les blocs logiques du disque sont répliqués sur 2 autres disques.

Cette architecture est conçue par nature pour être utilisée dans un cluster.

Cette organisation différente résout trois problèmes simultanément :

  • la défaillance des disques, par la réplication des données,
  • une organisation trop rigide, par l’absence d’organisation préalable,
  • la corruption de la hiérarchie, par la conservation des métadonnées dans une structure indépendante.

La limite serait la vitesse d’accès à une donnée, il est plus aisé de lire un bloc particulier de 512 octets que 64 Mo, mais MapReduce offre une solution adaptée à GFS.
Au deuxième niveau, on peut imaginer que les métadonnées soit elles-mêmes des données de structure, ainsi le bloc de GFS se mue en structure de stockage sur disque directement adapté à ses besoins !
Les données sont conservées compressées, car cela économise de la place et du temps de calcul par des transferts plus courts.

Conclusion, un emballage adapté à nos besoins

Ces nouvelles méthodes pour traiter les données sont séduisantes, malheureusement elles se heurtent à un seuil élevé de contraintes ; maîtriser l’ensemble du cycle de développement du logiciel, de l’analyse au code source jusqu’à son implémentation. Les nuages de calculs nous confrontent à un dilemme similaire, une interface de programmation spécifique (API) qui nécessite de nouveau un code source adapté...
La majorité des applications utilisées en ingénierie sont commerciales, mais quelle est l’architecture optimale pour répondre à ces besoins grandissants ? Cet emballage doit répondre à des critères contradictoires :

  • être multiplateformes, au minimum Linux et Microsoft,
  • héberger des applications métier,
  • fournir une puissance de calcul à la demande,
  • être économique.

Une solution serait un environnement virtuel qui permette :

  • à l’usager d’installer son application,
  • de déployer cette instance sur plusieurs serveurs,
  • de facturer son utilisation.

Finalement, l’application peut être archivée pour être réutilisée. Avec la multiplication des systèmes de virtualisation, l’émergence d’API standard, une telle solution est envisageable et permettrait de combler le fossé existant entre les clusters de calcul et le serveur isolé.
À la suite de ce raisonnement, on peut même envisager que la brique élémentaire, le serveur virtuel, suive la consommation effective des ressources plutôt que d’être pré-alloué.
La mise en place d’environnements de calcul à la demande nous oblige à mettre en place un urbanisme des salles serveur. Ce schéma directeur doit dépasser l’accumulation de ressources informatiques dans un espace restreint pour offrir des services qui présentent une empreinte écologique raisonnable. Il est probable que la prochaine limite des systèmes de calcul ne soit pas technique, mais énergétique, seule une vision intégrée des algorithmes et de leur implémentation avec une mesure des performances serait viable. Ainsi, l’explosion de la demande avec son corolaire environnemental, une consommation électrique excessive pourrait être contenue.



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.