juillet
2008
Aujourd’hui plus que jamais, les serveurs sont les pierres angulaires de la toile mondiale. Le plus petit chaos physique (pannes d’électricité dans un DataCenter) a des répercussions de grandes ampleurs sur le nuage (nb. Internet).
Pour palier à ces problèmes les entreprises mettent en place des architectures redondantes extrêmement onéreuses, autant à l’achat qu’a l’entretien (Par exemple la firme Google totalisera bientôt près d’un million de serveurs (d’ici a 2011), tandis que Microsoft de son côté mets des milliers de nouveaux serveurs en ligne chaque mois pour supporter ses applications).
De même, l’espace de stockage et la bande passante nécessaires sur les serveurs sont de plus en plus importants car les applications lourdes augmentent les coûts de l’infrastructure. C’est pourquoi un nombre croissant d’entreprises se tournent vers les réseaux décentralisés, pour leurs applications secondaires (mise à jour ou autre) sachant que la technologie n’est pour le moment pas bien maitrisée pour des applications exigeantes.
Plusieurs exemples de réseaux décentralisés sont utilisés par beaucoup (en le sachant ou pas) :
– Mise à jour de beaucoup de jeux en ligne
– Emule et autres logiciels de partage communautaire (DC, le défunt Kazaa,…)
– Le téléchargement de beaucoup de fichier lourd (release Linux, démo,…)
– La voix sur les jeux supportés par la plate-forme Steam (cf Valve)
Ainsi on peut prédire le meilleur pour cette technologie, qui permet de réduire grandement l’utilisation serveur, et ainsi réduire son parc serveur.
Une petite explication sur le système s’impose alors :
Dans un réseau décentralisé, la majorité des données sont échangées directement entre utilisateurs et ne transitent pas (ou peu) par le serveur. On a ainsi le plan suivant :
Comme vous pouvez le constater les interactions ne sont pas les même dans ces deux schémas. Ce c’est justement cette différence qui permet au système de réseau décentralisé de consommer 10x moins de ressources serveurs. Un exemple simple : si 100 personnes souhaitent télécharger un fichier, sur un système centralisé le serveur va lui-même redistribuer le fichier aux 100 personnes (si le fichier fait 100Mo, cette opération va consommer 10Go de bande passante et occuper le serveur pendant un bon moment (accès disque, traitement des requêtes,…)). Tandis qu’avec un système décentralisé, le serveur aurait coupé le fichier en 10 parties, qu’il aurait distribué à 10 personnes, et ces 10 personnes se seraient alors échangé les parties afin de reconstituer le fichier entier.
Donc, dans l’absolue théorie, le serveur n’aurait diffusé qu’une fois le fichier, et 100 personnes l’auraient eu (utilisation minime du disque et de la bande passante serveur, mais utilisation de la bande passante client qui est la plupart du temps inutilisé dans le sens montant/upload).
Ce système est de plus en plus efficace avec l’avènement du haut débit en France (et bientôt très haut débit), avec plus de 1Mbit/s d’upload dans la plupart des offres (soit 128 ko/s). Ce n’est pas grand-chose me direz-vous mais la force d’un réseau décentralisé est la communauté connectée, ainsi lorsque 100 utilisateurs ont acquis le fichier, la bande passante disponible est équivalente à celle d’un serveur de production.
Principal exemple (on y revient souvent pour la présentation car cela parle à de nombreuses personnes) : le réseaux eDonkey, avec ses serveurs dépassant la barre du million d’utilisateurs connectés sur un seul nœud (serveur) ce qui est impensable sans cette technologie. Dans ce cas précis le serveur ne fait que rediriger les clients les uns vers les autres en fonctions des fichiers demandés, ensuite le transfert de fichier ne passe pas par le serveur (et le flux de données est bien plus important que s’il passait par celui-ci : plusieurs TB/s).
Maintenant que l’idée générale est posée, et que celle-ci est claire (je l’espère, sinon posez vos questions en commentaire) dans l’esprit de tous nous allons voir les avantages et les inconvénients de ce système et optionnellement comment y remédier.
Le principal avantage est, comme dit précédemment, qu’il permet un fort gain de bande passante (car celle-ci n’est pas illimités, la liaison inter-atlantique à une limite fixe, et il est très onéreux de « tirer » de nouveaux câbles au travers d’un océan).
Viens ensuite le fait qu’une panne de serveur ne pénaliserait pas forcément les services hébergés (grâce à la persistance due au cache de tous les utilisateurs connectés). Les données seraient alors encore disponible le temps de repérer la panne.
Bien sur, tout n’est pas rose dans le monde merveilleux du décentralisé. La sécurité, l’intégrité des données et la validité des clients sont les principaux inconvénients/problèmes techniques que le système pose. Mais comme tout à une solution, nous verrons plus tard comment palier à ces problèmes.
Parlons maintenant applicatif (en toute théorie) afin que l’image de ce système n’en soit que plus forte dans votre esprit :
Comme vous le savez certainement, les MMOx (jeux permettant de jouer avec des milliers de joueurs simultanément) demande une infrastructure importante.
L’utilisation en bande passante serveur est titanesque, alors que les clients, eux n’utilisent que 2-5ko/s de leur bande passante montante (upload) soit moins 10%.
Le but dans cette application serait de se dire, aucune bande passante ne doit être perdue. Ainsi lorsqu’un millier de joueurs seraient connectés la bande passante disponible serait largement supérieur à ce qui est nécessaire, et les serveurs serait ainsi plus qu’allégés. (Économie de plusieurs To de bande passante).
Autre application possible, directement liée au web, faire un navigateur qui partagerai le cache des utilisateurs. Ainsi lorsqu’un serveur serait surchargé, il suffirait de demandé à la communauté qui a consulté cette page dernièrement afin qu’il nous l’envoi.
Enfin bref, passons sur toutes les possibilités (utopique ?) offerte par cette technologie, elle a un autre atout de taille : savez combien d’énergie utilise une ferme de serveur (autant pour tourner que pour refroidir ?) ? Il ne vaut mieux pas le savoir.
Donc si l’on peut réduire le parc de serveur mondial (ou continuer à développer le web sans pour autant étendre ce parc), d’énorme économie peuvent être réalisée.
Voila, c’est la fin de cette petite présentation (généraliste) de ce système.
Nous verrons les aspects plus techniques (sous plateforme .net) dans les billets qui viendront.
Si vous avez des questions n’hésitez pas !
EDIT : Merci à nouknouk pour ses critiques éclairées.
Effectivement j’ai oublié de préciser que le P2P n’est valide que pour du contenu « statique », donc pour du contenu dynamique il faut tout d’abord demander une validation sur le contenu de la page (par exemple pour un forum savoir si une discussion a évoluée).
Il m’a aussi fait remarquer à juste titre que pour les MMOx, ce système engendrait des incohérences, mais je m’expliquerais sur cela plus tard, car il y a aussi une solution.
Voici le plan des prochains articles : (je le met en commentaire pour ne pas « polluer l’article ».
Article 2 : Problème de sécurité lié à la décentralisation.
Article 3 : Intégrité des données avec la décentralisation ? C’est possible !
Article 4 : Topologie des réseaux et solutions automatique.
Article 5 : Utilisation de la mémoire collective dans un réseau décentralisé.
Article 6 : Persistance du réseau.
Article 7 : Application directe dans les jeux vidéo (+exemples .net)
Article 8 : Un peu de suspens quand même non ?
Bien sur tout cela est soumis aux aléas de mes humeurs journalières