Ubuntu, le gagnant discret du Cloud Computing

Le Cloud Computing, tout le monde en parle, et une simple recherche sur Google vous donnera des centaines de sociétés qui sont toutes “leader” dans ce domaine… De même, tous les ans depuis 2000, on nous promet “l’année de Linux”

Et pourtant, sans qu’on s’en rende vraiment compte, c’est Ubuntu, une distribution Linux à la base orientée “Desktop” et “simplicité d’utilisation”, qui est en train de remporter le marché du Cloud Computing.

Aujourd’hui, Ubuntu est l’OS le plus utilisé sur Amazon EC2. Et cette utilisation est en pleine croissance. Selon Cloud Market, l’une des rares sources permettant d’avoir des statistiques d’utilisation, Ubuntu est leader depuis 2009, et sa courbe d’utilisation est en plein envol. Si vous fouillez un peu ces statistiques, rappelons que “Alestic.com” fournit en fait sa propre image d’Ubuntu, et qu’il faut donc additionner les statistiques d’Alestic.com à celles de Canonical. Et Redhat, ou “Oracle Enterprise Linux”? Ils sont en quantité négligeables! Quand à Windows, il est plutôt à la traine.

Comment cela s’est il produit?

La première raison est qu’Ubuntu a commencé sa percée sur les postes de développeurs: dans la communauté Eclipse, le sondage d’utilisation de 2010 annonçait déjà la victoire d’Ubuntu: 18,3% des développeurs utilisaient Ubuntu, et l’utilisation de Linux était en pleine explosion. Or, aujourd’hui, les développeurs ont une influence de plus en plus grande sur ce qui va être utilisé en production: c’est exactement le même phénomène qui a poussé Spring à être prépondérant aujourd’hui, un phénomène expliqué de manière amusante dans cette présentation de RedMonk.

D’autre part, Ubuntu s’est positionné très tôt sur le marché du Cloud Computing, avec leur accord avec Eucalyptus. C’est l’avantage du premier entrant, et aujourd’hui Redhat ou Oracle ont du mal à rattraper leur retard.

Enfin, bien entendu, le coût est une donnée importante: les images d’Ubuntu sont gratuites, et les entreprises vont d’abord sur le Cloud pour réduire leurs coûts. Bien entendu, sur le long terme cela pose l’éternel problème de la monétisation des produits Open Source, surtout ceux d’excellente qualité: nous avons là un OS quasiment impossible à planter ou à pirater, sur des machines que l’on peut réinstaller en un clic. Pourquoi alors payer pour du support?

Et le cloud privé?

Les statistiques utilisées ici viennent d’Amazon EC2, qui est de très loin le leader du cloud privé (voir par exemple cette analyse de RedMonk). Au niveau du cloud privé, typiquement avec VMWare, les choses sont en fait très discrètes. Parmi les utilisateurs français de VMWare, nous voyions chez nos clients une utilisation prépondérante de Redhat. Mais il ne s’agit pas là d’une alliance voulue entre Redhat et VMWare: les deux géants s’affrontent sur le terrain de la virtualisation et des serveurs d’applications (chacun ayant sa propre solution).

C’est pour cette raison que VMWare a tenté de racheter récemment Suse: une bataille importante c’est jouée avec le rachat de Suse par Attachmate. Attachmate, une société que personne ne connait dans ce domaine, et dont la rumeur veut qu’elle soit financée en réalité par Microsoft (grand concurrent de VMWare, et qui aurait réussi là un très beau coup).

Au final, les machines vFabric utilisent donc si possible des serveurs Ubuntu: par exemple, les plateformes fournies pour le challenge USI 2011 par VMWare étaient sous Ubuntu.

On peut donc penser que, sur le long terme, Ubuntu va également envahir les cloud privés.

Mais Ubuntu est-il une si bonne plateforme?

Ubuntu est une plateforme tout à fait correcte pour la production, si on la compare aux autres distributions Linux.

Comme souvent, Ubuntu nécessite pas mal de tuning pour pouvoir tourner de manière optimale (enlever le Swap si vous faites du Java, augmenter le nombre de file descriptors, etc…). De même, il n’y a pas de fioritures pour le firewall (on utilise iptables tout bêtement) ou pour installer un service (pas de chkconfig comme sous Redhat). Un Linux simple et sans surprises, en quelque sorte.

On retiendra donc deux avantages principaux:

  1. Les performances: on arrive facilement à une machine bootant en moins de 20 secondes, et consommant par défaut moins de 128 Mo de RAM
  2. C’est une plateforme facilement utilisable pour les développeurs sur leurs postes: cela permet donc d’avoir moins de risques lors d’une mise en production (c’est toujours mieux de développer dans un environnement proche de la production)

Vite, testons Ubuntu!

Ubuntu est donc connu comme un OS “grand public” sur le desktop, mais il est surtout en train de devenir l’OS incontournable du Cloud Computing. Ce qui fait qu’il est important de s’y intéresser. Pour avoir un premier aperçu d’Ubuntu server sur Amazon EC2, Canonical vous permet justement de l’essayer gratuitement, alors vous n’avez plus d’excuse pour ne pas démarrer!

TwitterFacebookGoogle+LinkedIn
  • jfasrc

    “enlever le Swap si vous faites du Java”
    Est il possible d’avoir une précision ou un lien sur ce point ?

    • Julien Dubois

      Le Swap ne devrait plus être utilisé de toute manière sur une machine moderne, vu le prix de la RAM aujourd’hui.
      Donc, déjà, si vous avez un serveur “normal”, vous n’avez pas de problème de RAM, donc autant virer totalement le Swap: sinon l’OS a toujours tendance à l’utiliser un peu, ce qui bousille les performances sans raison.
      Avec Java, le problème est pire qu’avec une application en C/C++, car on a tendance à utiliser plein de RAM le temps que le GC passe. La conséquence, c’est que sans tuning particulier une application Java a tendance à utiliser le Swap, et que quand le GC passe on a alors des performances horribles (comparez les temps d’accès de la RAM à ceux d’un disque dur…).
      Si vous avez vraiment des contraintes de RAM (vous êtes en interne dans une boîte où la prod a 5 ans de retard), c’est compliqué: essayez des pauses très courtes du GC et un Xmx qui fait tenir le process Java dans la RAM. Mais pour moi c’est justement ce type de comportement des gens de la prod qui va conduire à leur perte: si avoir un serveur avec 32 Gigas de RAM c’est super facile sur le cloud, et qu’en interne c’est impossible, à un moment le métier va s’en rentre compte et va finir par trancher… et ça ne sera pas en faveur de la prod.

  • http://twitter.com/samkiller Sam BESSALAH

    Interessant article. Mais peut on avoir une explication sur l’interet d’enlever le swap lorsqu’on utilise du Java?

  • Antoine Büsch

    Depuis 2000, c’est l’année de Linux *sur le Desktop* qu’on nous promet… Côté serveur, ça fait bien longtemps que Linux a gagné la bataille.

  • Pierre-Alain RIVIERE

    Je trouve ça quand même un peu gros le coup du “On a bcp de RAM, enlevons la swap”. Des benchs à l’appui? Et même si on me prouve que le gain de performance est important, j’aurai des scrupules à appliquer…

    Pour le reste :
    * Redhat et toutes les distributions que je connais utilisent iptables (ils sont un peu obligés). Et d’ailleurs, Ubuntu se démarque là dessus en proposant sa propre surcouche : ufw
    * De mon point de vue, la création d’un script d’init sous Redhat et sous Ubuntu était _strictement_ identique : un script start|stop à placer dans /etc/init.d et hop on fait péter les liens symboliques où on le désire : System-V quoi. Ensuite chacun a ces particularités : là où on a chkconfig d’un côté, on trouvera update-rc.d de l’autre. Mais là encore, Ubuntu a décidé de diverger. Maintenant, on a upstart.

    • Julien Dubois

      * Pour le Swap, c’est quelque chose qu’on retrouve de manière récurrente dans les conseils de perf (par exemple ici: http://ehcache.org/documentation/offheap_store.html#Avoiding_OS_Swapping ). Personnellement, cela me parait assez évident que la RAM est plusieurs ordres de grandeurs de fois plus rapide que le disque dur, donc je mets mon swapiness à 1 (je ne vire pas non plus totalement le Swap). Il faut dire qu’avec le temps c’est quelque chose qui s’accentue: les disques durs (hors SSD) plafonnent depuis des années, alors que la RAM va de plus en plus vite.
      * Pour iptables et etc/init.d, c’est clair que tout le monde fait pareil (Ubuntu compris), il n’y a pas le choix. Par contre on peut avoir des outils plus ou moins sympas au dessus, et je voulais juste dire qu’avec Ubuntu c’était pas terrible. C’est du basique, mais du classique, sans chichi. Personnellement ça me va bien.

      • Pierre-Alain RIVIERE

        Avec ces précisions je suis d’accord avec toi.

  • LUDE

    Intéressant.
    Par contre, corrigez-moi si je me trompe mais je ne suis pas sûr que les stats du site cloudmarket en référence dans l’article veulent dire grand chose sur la part d’Ubuntu dans les clouds EC2, car:
    1. Les stats sont les stats des images et pas des instances de VM qui tournent.
    2. On voit que Canonical est le + grand propriétaire de fichiers images : sûrement lié à leur offre de cloud; et beaucoup des images Ubuntu sont des images de test (sans doute utilisées pour la validation de leur distribution avec différents noyaux, outils,etc).

  • http://twitter.com/sylvain_avril Sylvain Avril

    Sous Debian/Ubuntu, on a les commandes sysv-rc-conf et update-rc.d qui font bien mieux le boulot que la commande chkconfig de redhat.

    Par contre, pour le choix d’ubuntu comme distribution serveur, cela me semble un choix plus que discutable (car rarement basé sur un choix technique). Ubuntu hors version LTS ne devrait jamais être utilisé en production tellement elle est instable. Debian est une distribution bien plus stable, avec des mises à jour de sécurité plus rapide et un support plus efficace (même s’il n’y a pas de société possédant cette distribution), en tout cas avec mon expérience. Et on peut avoir du support payant avec une entreprise derrière. J’ai par exemple rencontré un bug avec le kernel fourni sur la version testing, 8h après j’ai eu la surprise de voir un nouveau kernel lors de l’update du système avec mon bug corrigé. J’étais scié. Aucune boite commerciale n’a jamais été aussi réactive au niveau support (là aussi avec mon expérience).

    Sinon pour le swap avec les VMs, il faut se méfier. Bien qu’on le supprime au niveau de la VM (choix que j’approuve dans le cas de Java), cela ne veut pas dire qu’on ne va pas swapper au niveau de la machine hôte de la VM. L’hyperviseur peut en effet swapper une partie de la RAM peu utilisée des VMs (code du kernel pas utilisé, …) pour faire en quelque sorte du surbooking. Bien sûr si le swap est mal géré (ou pas géré du tout…), on peut faire flancher les perfs de toutes les VMs. Heureusement en combinant cette techno avec des disques SSD, on sauve les meubles, une diminution seulement par 10 des débits mémoire. Pour avoir vu les perfs de VMs Java fluctuer, je suis assez suspicieux vis à vis de cela.

    La plupart des fournisseurs de cloud utilisent cette techno.

    Suivant le sérieux des acteurs ils peuvent l’utiliser peu ou jusqu’à 50-50 ! Il faut penser à tester la qualité des fournisseurs avant de faire son choix, sinon c’est vraiment le brouillard. Ce qui n’est pas étonnant vu qu’on achète du virtuel :-) Mais il faut savoir à combien de “réel” ça correspond.