FAH-Addict

Le plan :
1. Introduction
2. Les paramètres de corrélation
3. Le fonctionnement de la décorrélation
4. Conclusion

1. Introduction

Le projet Storage@Home nécessite une bonne disponibilité des données et une fiabilité sans faute du stockage. La réponse la plus évidente à cette contrainte est la redondance. D'après l'article d'Adam Beberg de 2007, cette redondance à été fixée à 4 copies pour chaque lot de données. Toutefois, cette redondance ne fait pas tout …
Beberg prend pour exemple le 26 décembre 2006, lorsqu'un tremblement de terre proche de Taiwan avait coupé l'accès à Internet de 6 pays asiatiques en même temps. Si par hasard, des données avaient été regroupées sur 4 ordinateurs asiatiques, les données auraient été indisponibles et peuvent être même perdues ! On peut modéliser les utilisateurs d'un projet comme SAH suivant un certain nombre de paramètres. Si plusieurs utilisateurs ont des paramètres à la même valeur, ils sont dits fortement corrélés, ce qui peut signifier que les données sont plus en danger. Voici quelques paramètres que Beberg a déjà isolés.

2. Les paramètres de corrélation

Nous avons donc commencé avec la géographie, mais comment géolocaliser une IP ? C'est en fait très simple ! L'Internet Corporation for Assigned Names & Numbers (ICANN) qui attribue les lots d'adresses IP de l'Internet entretient une base de données de correspondance entre des plages d'IP et le coordonnées réelles de leurs propriétaires, comme par exemple leur nationalité. Ensuite, un simple abaque donne la distance en kilomètre entre ces pays. Plus ils sont éloignés, plus le risque d'un incident climatique/géologique/géopolitique commun à ces deux pays est faible, plus les données sont en sécurité.
Mais cette logique peut être poussée plus loin ! Chaque IP de particulier appartient donc à un fournisseur d'accès à Internet. SAH contrôle que les données sont le moins possible distribuées chez des membres du même FAI, ce qui réduit le risque d'une panne généralisée chez un opérateur qui mette à mal des données. (ndlr : Quid des opérateurs virtuels qui utilisent le réseau d'un autre FAI ? Il faudra poser la question à Adam Beberg)

Les systèmes d'exploitation sont un autre point important. La population mondiale de PC est à plus de 90% équipée de Microsoft Windows, 7% de PC sous Mac OS et environ 1% de Linux/Unix. Cette position dominante de Microsoft est un risque potentiel pour SAH. Imaginons qu'une faille « 0 day » est dévoilée et exploitée dans la foulée par un virus destructeur, les souvenirs du worm Blaster (qui n'étaient pas une faille 0 day) peuvent nous montrer à quel point ce genre de menace peut faire tomber un grand nombre de machine en très peu de temps.
Il sera donc important que les données ne soient jamais toutes sur le même OS, mais qu'au strict minimum une machine Mac OS, Linux ou Unix soit disponible.
De même, exploiter la diversité des versions de Windows pourrait être un point positif.
Deuxième point important à propos des OS, et surtout de Windows, ne pas être sur le même fuseau horaire. Pourquoi ? Car le deuxième mardi de chaque mois, à 3H du matin (heure locale) Windows Update met à jour automatiquement un grand nombre de machines, puis les fait rebooter. Ce qui pourrait mettre à mal le projet.
Il existe peut être d'autres paramètres de corrélation entre les utilisateurs, qui pour le moment n'ont pas été identifié par Stanford. L'équipe recherche de nouveaux paramètre de corrélation pour s'assurer de toujours mieux répartir ses données dans les meilleures conditions.

3. Le fonctionnement de la décorrélation

Voici les données et paramètres de Stanford utilisés en 2007 pour rédiger l'article :

• Upload moyen d'un utilisateur : 384 kbps (environ 30ko/s)
• Nombre d'utilisateurs espéré : 100.000
• Espace de stockage de chaque utilisateur : 10 Go
• Nombre d'utilisateurs dans une grille d'utilisateurs : 10
• Nombre de réplique d'un bloc de données : 4
• Taille d'un bloc de données : 100 Mo
• Nombre de bloc par utilisateur : 100
• Nombre total d'utilisateur tombant en panne chaque jour : <1000
• Temps moyen entre 2 pannes : 86 secondes
• Opérations de réparation par jour : 1 million
• Opération de réparation par seconde : 12
• Durée d'utilisation moyenne du réseau pour un utilisateur par jour : 10*5.5 Minutes
• Upload utilisé pour des réparations par jour et par utilisateur : 100 Mo
• Nombre moyen d'opération de réparation à la volée : ~4000
  

Prenons l'exemple simplifié de 10 utilisateurs dans une grille, qui peuvent chacun stocker 2 blocs de données :

Cette grille est assez uniformément répartie dans le monde. Il y a une grosse concentration d'OS non Windows. Imaginons que le malheureux contributeur Japonais subit un tremblement de terre de forte magnitude qui rende son accès à Internet inopérant :

Très vite, les serveurs se rendent compte de la disparition du contributeur Japonais, un utilisateur Bresilien est ajouté à la grille, le premier bloc est dupliqué sous l'ordre du serveur depuis l'utilisateur Américain, Chinois et Français.

Puis c'est la duplication du second bloc à partir des utilisateurs Koréen, Marocain et Canadien.

L'utilisateur Japonais n'est plus membre de la grille, s'il revient après réparation de sa ligne Internet, il sera intégré à une nouvelle grille. L'utilisateur Bresilien gardera les blocs fraîchement acquis.

4. Conclusion

Malgré la difficulté, Stanford présente une implémentation d'architecture de stockage distribué qui semble assez robuste. La décorrélation des utilisateurs devrait aider le projet à perdre un minimum de données. Il reste encore à mesurer l'impact de la loi de Murphy sur cette belle mécanique, mais on voit que Stanford prend très au sérieux les effets de « l'environnement » des machines, elles ne seront pas toutes égales !
L'expérimentation lancée dans la « phase 1 » du projet va réunir des données « réelles » permettant peut être de réajuster les chiffres estimés au départ, soit vers un assouplissement de la redondance, soit au contraire son renforcement.