Antoine Benkemoun

J’avoues avoir un peu de mal à poster des billets régulièrement en ce moment. Cela s’explique en partie par une petite baisse de motivation pour le faire mais aussi la reprise des cours qui sont un peu plus nombreux que prévus.

Un autre projet qui va me prendre beaucoup de temps est l’Utt Arena. Mais qu’est ce que l’Utt Arena me diriez-vous ? Il s’agit d’une LAN Party ou, pour faire plus « marketing », un tournoi de jeux vidéo. Ce n’est pas la première fois que je m’investis dans ce projet car j’en avais été président en 2007 et 2008. Depuis, j’ai essentiellement aidé occasionnellement. Pour l’édition 2010, je me suis proposé avec l’aide d’un ami et d’un « nouveau » pour mettre en place et gérer la partie réseau de cette LAN.

Une LAN est un événement d’envergure dans lequel les joueurs ramènent chacun leur ordinateur. Le principal problème provient de ce fait. Il serait possible de croire que les joueurs ont des machines « de course » avec une installation (Windows, forcément) propre. La réalité est tout autre. Nous retrouvons les « versions » les plus exotiques de Windows remplies jusqu’aux oreilles de malware et d’applications non recommandables.

Lors des précédentes éditions, nous avons choisi la simplicité par manque de moyens matériels et humains. Tous les joueurs étaient disposés sur un même LAN (au sens IP du terme) avec un DHCP pour leur allouer des adresses IP automatiquement. L’inconvénient est que tous les ordinateurs pouvaient communiquer sans restriction. Dans de telles conditions, les partages de films interdits aux mineurs et la prolifération des malwares en tous genre sont optimaux.

De plus, il était quasiment impossible d’avoir une visibilité quelconque sur les différents flux échangés ainsi qu’une évaluation de la latence. Ah la latence, parlons-en. Les participants à une LAN ne jurent que par elle. Au dessus de 10 ms affichées par le jeu Counter-Strike, le réseau est considéré trop lent. Bien que des astuces soient possibles au niveau des serveurs de jeu afin d’optimiser l’affichage de cette latence, l’optimisation du réseau est primordiale.

Cette année, nous avons réussi à mettre la main sur une batterie d’équipements de sécurité robustes. Nous aurons à notre disposition 4 firewalls Cisco ASA 5510 ainsi que quelques routeurs Cisco 2800 Series. L’ajout d’intermédiaires de communication au niveau IP induira inéluctablement une latence supplémentaire. Cela nous permettra cependant de pouvoir réellement maitriser notre réseau et de bénéficier des fonctionnalités de QoS du Modular Policy Framework Cisco. Nous espérons sincèrement que cet ajout de latence sera minime au regard des avantages fournis par les fonctionnalités de ces équipements.

Ce billet est le premier d’une série de billets ayant pour objectif de détailler le processus de mise en place de cette architecture ainsi que des différents outils (open source, bien sur) d’évaluation des performances réseau. Elle sera clôturée par un retour d’expérience suite à l’événement qui aura lieu du 16 au 18 Avril. En attendant, je retourne éplucher les différentes documentations des ASA.

Ce billet fait suite au premier sur les dangers du cloud computing qui s’était plus orienté vers la sécurité des données placées dans le cloud. La seconde problématique que je souhaitais aborder est la celle de l’interopérabilité entre les clouds.

Lorsqu’une architecture est conçue initialement, les concepteurs disposent d’un certain nombre d’éléments motivant un choix technologique par dessus un autre. Dans le cas du cloud computing, ces éléments ne sont pas fixés depuis une durée particulièrement longue et ne sont clairement pas fixés à des échéances au delà du moyen terme. La relative nouveauté du cloud computing devrait démotiver bon nombre de concepteurs d’architecture.

Dans le cas où le choix serait fait de se baser sur une architecture intégrée au sein d’un cloud quelconque, il est nécessaire de se poser très sérieusement la question de l’interopérabilité. Lorsqu’une entité va placer son architecture,  elle confiera d’une part ses données mais aussi le travail humain lié à la conception d’une plateforme. Ce travail humain a un coût relativement important en fonction de l’architecture en question. De sérieux problèmes sont à envisager dans l’éventualité d’une faillite de la société hébergeant le cloud ou même une catastrophe quelconque mettant à mal le cloud. La non-transparence des clouds actuels rend exceptionnellement compliqué l’évaluation de ces risques.

La problématique de l’interopérabilité se pose ainsi. Dans le cas où une entité utilisatrice utilisatrice d’infrastructure cloud souhaite changer d’hébergeur pour une raison X ou Y, en a-t’elle la possibilité ? Il y a bien sur plusieurs niveaux de réponse à cette question. Nous pouvons envisager une situation dans laquelle il lui est juste possible de récupérer les données applicatives ce qui impliquerait de devoir reconstruire la quasi totalité de l’infrastructure applicative. Nous pouvons également envisager une situation où il est possible de récupérer une version « packagée » des machines virtuelles ou, à l’opposé, une situation où rien n’est prévu pour être compatible avec d’autres plateformes.

De plus, ce n’est pas parcqu’il est possible de récupérer une machine virtuelle qu’il sera possible de l’exécuter sur une autre plateforme sans devoir se plonger dans les méandres du système d’exploitation pour peu que celà soit même possible.

Au final, l’interopérabilité est un enjeu majeur de toute plateforme informatique et suscite de nombreux débats habituellement. Les problématiques d’interopérabilité dans le cloud computing ne semblent pas encore avoir passioné grand monde ce qui est dommage car elle est bien réelle et existante. Le logiciel libre a clairement un rôle à jouer dans le cadre de cette standardisation avec les acteurs majeurs de l’industrie associée.

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.

Cela faisait quelques temps que je ne vous avais pas recommandé de livre. La dernière fois remonte tout de même à Octobre avec le livre sur Xen. Cette fois-ci, je ne vous recommanderais pas un livre parlant de Xen ou même de virtualisation, mais plutôt de sécurité informatique.

J’ai pu emprunter ce livre deux semaines à la Bibliothèque des Sciences et de l’Industrie située à l’intérieur de la Cité des Sciences. Je me suis tourné vers cette bibliothèque car il s’agissait de la plus proche de mon lieu de travail avant la reprise des cours. J’y ai cependant trouvé un large choix de livre récents traitant de nombreux sujets informatiques. J’avais plutôt été habitué aux livres poussiéreux des bibliothèques classiques. Je vous recommande donc ce lieu si vous passez dans le coin !

« Menaces sur le réseau » est un ouvrage traitant de la sécurité informatique au sens très large. Il a été écrit par un chercheur en sécurité informatique polonais qui explique les différents concepts avec une pédagogie exceptionnelle. Ce livre reprend rapidement les bases théoriques nécessaires à la compréhension des éléments techniques et vous explique différentes techniques d’attaques. Il est donc à lire si vous avez certaines bases en systèmes d’exploitation et en réseaux IP.

Ce livre permet de comprendre plus concrètement le monde de la sécurité informatique. Un exemple est l’explication du fingerprinting de systèmes d’exploitation dont l’auteur semble particulièrement friant. Vous comprendez quelles sont les traces laissées par les systèmes d’exploitation dans tous les paquets IP qu’ils émettent. Un autre exemple est le fingerprinting d’OS en se basant uniquement sur les ID des paquets IP, ce qui est pour le moins créatif mais surtout impressionnant. Grâce à une analyse statique graphique, l’auteur arrive à démontrer la possibilité de cette technique, intimement liée au fait que les ID ne sont pas générés tout à fait aléatoirement.

Au final, ce livre est à lire absolument pour tous ceux qui souhaitent s’intéresser à la sécurité dans le domaine des systèmes d’exploitation et des réseaux et qui ont quelques bases dans ces domaines. Pour ceux qui souhaitent s’intéresser aux aspects « management » de la sécurité, passez votre chemin.

Ce billet fait suite aux précédents billets ayant pour objectif de présenter sur différents niveaux le cloud couputing. Je vais continuer cette série de billets en parlant des dangers liés à cette technologie.

Les dangers liés au cloud computing sont la conséquence directe de la dématérialisation des infrastructures physiques.

Tout d’abord, la première problématique est la localisation des données. L’abstraction des infrastructures physiques rend la localisation de données spécifiques significativement plus compliquée. Cette incertitude induit une sécurité pas forcément amoindrie mais certainement considérablement complexifiée.

Cette première problématique est évidente dans le cas des clouds publics ou privés-publics. Le client des infrastructures de cloud computing accorde une confiance totale aux prestataires en lui livrant toutes ses données. Bien que la plupart des argumentaires commerciaux mettent en avant une sécurité des données et, le plus souvent, un chiffrement, il est impossible de vérifier cela. Le client devient spectateur de la sécurisation de ces données.

Nous pouvons faire une exception à cette problématique dans le cas de clouds privés-publics. Ce cloisonnement reste tout à fait relatif. Ce cloisonnement peut être, dans le cas d’infrastructures « bas de gamme » seulement un mécanisme réseau tel que les VLAN. Ce mécanisme peut difficilement être considéré en tant que mécanisme de cloisonnement de données efficace.

Dans le cas d’infrastructures « haut de gamme », nous pouvons imaginer une architecture de type « cloud computing » exclusive à chaque client. Cette alternative se place dans le haut de gamme par le coût que cela engendre. Ce type d’offre permettrait, au passage, une plus grande flexibilité dans l’architecture à tous les niveaux.

Au final, la sécurité des données est une réelle problématique du cloud computing. Nous nous intéresserons plus tard aux problématiques d’interopérabilité des plateformes.

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.