CONSERVATOIRE NATIONAL DES ARTS ET METIERS

CENTRE REGIONAL ASSOCIE DE CASABLANCA – MAROC

___________________

Mémoire présenté en vue d'obtenir

UE « Information et communication pour ingénieur »
Spécialité : INFORMATIQUE

par

Abdelkader KADIRI HASSANI YAMANI

___________________

Consistent Hashing ou le Hachage Cohérent

Soutenu le JJ MMMM 2015

_________________

JURY

PRESIDENT : Monsieur Kamel BARKAOUI Professeur des Universités,

CNAM Paris

MEMBRES : Monsieur Claude GENIER Enseignent CNAM Rhône-Alpes

et Maroc

Monsieur Karim CHEIKH Ingénieur en informatique

 Consistent Hashing ou le Hachage Cohérent

Mémoire présenté en vue d'obtenir

UE « Information et communication pour ingénieur »
Spécialité : INFORMATIQUE
Casablanca, 2015

_________________________________________________________________

RESUME

Les progiciels intégrés de gestion (PGI), ou ERP (Enterprise Resource Planning) en anglais,
constituent aujourd'hui une des solutions logicielles les plus en vue pour rendre le système
d’informations (SI) de l'organisation plus performent.

Dans le but de disposer de plus d’assurance quant à la réussite du projet de faire migrer le SI vers
une solution de type ERP, en terme de sécurité de l’investissement et de maîtrise des risques du
projet, nous apportons les éclairages nécessaires, notamment : les avantages, les inconvénients et
limites, les difficultés et contraintes, les risques inhérents, les facteurs potentiels d’échec, et les
conditions de succès du projet. L’objectif étant de présenter les éléments nécessaires pour juger
objectivement, et en connaissance de causes, de l’opportunité de s’engager dans un projet de
migration ERP.

Mots clés : PGI, ERP, projet migration, syndrome « plat de spaghettis », intégration, risques
projet.
_________________________________________________________________

SUMMARY

Enterprise Resource Planning (ERP); or ‘Les progiciels intégrés de gestion (PGI)’ in French,
constitute today one of the most highly valued software solutions for a more efficient information
system (IS) of any company.

With a view to securing more assurance regarding the success of the project to migrate IS towards
an ERP type of solution, in terms of investment safety, as well as project risk control, we provide
the necessary insights, notably in connection with the advantages, the drawbacks and limits, the
difficulties and constraints, the inherent risks, the potential factors of risk, as well as the conditions
for the success of the project, the ultimate objective being to lay out the necessary elements for an
objective, and well-informed, appraisal of the opportunity to engage in a project of ERP migration.

Key words: ERP, project migration, “spaghettis dish” syndrome, integration, project risks.
 SOMMAIRE

Introduction

CHAPITRE I – WEB CACHING .................................................................................... 1

I.1. Définition et pour quel besoin ..................................................................................... 2
I.2. Les différentes approches de ″caching″ ..................................................................... 4
I.3. L’utilisation du hachage en mémoire cache ............................................................... 7

CHAPITRE II – CONSISTENT HASHING ........................................................................ 9

II.1. Les objectifs de conception ...................................................................................... 10
II.2. La technique du hachage cohérent .......................................................................... 11
II.3. Les propriétés d'une fonction de hachage cohérent ............................................... 15

CHAPITRE III – EXEMPLES D’UTILISATION DU CONSISTENT HASHING ................... 16

III.1. L’implémentation Akamai ..................................................................................... 16
III.2. Les tables de hachage distribuées et les réseaux P2P ........................................... 18
III.3. Le système de stockage distribué Memcached ...................................................... 22

Conclusion ................................................................................................................ 24
Bibliographie
Liste des figures
Liste des tableaux
Annexes
Annexe 1 : Eléments de base du hachage
Annexe 2 : Une présentation des réseaux pair-à-pair (P2P)
Introduction

Le présent rapport traite du consistent hashing, ou hachage cohérent en français. Ce

procédés ingénieux fut inventé en 1997 par David Karger, Daniel Lewin et al., du
Massachusetts Institute of Technology (MIT) à Boston, pour servir la mise en cache
au niveau du Web (ie. Web Caching).

Le plan que nous avons retenu pour ce rapport s'articule autour de trois chapitres.
Nous entamons le premier chapitre par un survol de l'histoire du consistent hashing
depuis son apparition en 1997, puis nous enchainons par une description du contexte
de sa genèse. Soit, après la définition du Web Caching et l'explication de ses
avantages, nous passerons en revue ses différentes approches en mettant en relief
leurs limitations et inconvénients. Enfin nous décrirons la technique du hachage en
mémoire cache.

Le second chapitre est dédié à la présentation du consistent hashing. Aussi, nous

commencerons par décliner son objectif, sa technique et ses apports nouveaux. Nous
poursuivons par la présentation de la mise en œuvre des opérations standard sur les
tables de hachage cohérente, puis un moyen efficace d'équilibrage de charge (ie.
Load Balancing) entre serveurs est détaillé, soit les "copies virtuelles". Le chapitre est
clôturé par l'énumération des propriétés que devrait avoir toute fonction de hachage
cohérent.

L'idée originale du consistent hashing ayant été depuis adaptée pour apporter des
solutions à plusieurs autres problématiques de l'informatique récente, nous avons
jugé utile de consacrer un Chapitre entier pour zoomer sur cet aspect. Aussi, le
Chapitre III nous éclaire sur quelques contributions majeures du consistent hashing,
notamment au niveau des tables de hachage distribuées (DHT pour l'anglais
Distributed Hash Table) utilisées dans les réseaux peer-to-peer, et des systèmes de
stockage distribué tel que Memcached ou Dynamo d'Amazon.
Chapitre I : Web Caching

Nous entamons le premier chapitre par un survol de l'histoire du consistent hashing depuis
son apparition en 1997, puis nous enchainons par une description du contexte de sa genèse.
Soit, après la définition du Web Caching et l'explication de ses avantages, nous passerons en
revue ses différentes approches en mettant en relief leurs limitations et inconvénients. Enfin
nous décrirons la technique du hachage en mémoire cache.
Un peu d'histoire :

1) 1997 :
L’implémentation, et la mise en œuvre, du consistent hashing est apparue pour la
première 1 fois dans un papier [3] de recherche dans STOC ("Symposium on the Theory
of Computing") 2 . Ironiquement, le papier avait précédemment été rejeté d'une autre
conférence, d'informatique théorique, car au moins un des examinateurs avait estimé
"qu’il avait aucun espoir d'être pratique".

2) 1998 :
La société Akamai est crée.

3) 31 Mars 1999 :
Une bande-annonce pour "Guerre des étoiles : La Menace Fantôme" est publiée en ligne,
avec Apple comme distributeur officiel exclusif. Les performances du site web de "la
pomme croquée", www.apple.com, se dégradent presque immédiatement en raison du
nombre impressionnant de demandes de téléchargement. Pour une bonne partie de la
journée, le seul endroit sur la toile permettant de regarder (une copie non autorisée?) de
la bande-annonce est via les caches Web d'Akamai. L’événement met la compagnie
Akamai sur la carte.

4) 1er Avril 1999 :

Steve Jobs, ayant remarqué la performance d'Akamai de la veille, appelle le PDG
d'Akamai Paul Sagan pour parler. Sagan raccroche, pensant qu’il s’agit d'un poisson
d'avril de la part de l’un des co-fondateurs d’Akamai, Danny Lewin ou Tom Leighton.

5) 11 Septembre 2001 :
Tragiquement, Danny Lewin, co-fondateur d'Akamai avec son professeur Tom Leighton 3 ,
est tué à bord du premier avion qui percute le World Trade Center. Akamai reste
cependant "debout" à ce jour.
1
Le concept de consistent hashing a également été inventé, plus ou moins simultanément, dans [13].
L’implémentation dans [13] diffère et reste incomparable à celle présentée dans [3].
2
STOC est une conférence universitaire organisée chaque année depuis 1969, traditionnellement en
Mai/Juin. STOC et FOCS (Symposium on Foundations of Computer Science) sont considérés
comme étant les deux (2) conférences majeurs de la théorie des sciences de l’informatique.
http://acm-stoc.org/
3
Chaque année, lors du Symposium STOC, un prix, Danny Lewin Best Student Paper Award, est
décerné au meilleur article scientifique réalisé par un étudiant. Ce prix fut initié par Tom Leighton
pour commémorer la mémoire, de son ancien étudiant et puis associé, le regretté Daniel Lewin. Pour
rappel, Daniel M. Lewin avait soutenu en Mai 1998 son mémoire [2] de Master en sciences
informatiques, au Massachusetts Institute of Technology MIT, sous l'encadrement des professeurs
Tom Leighton et David Karger [1, 3, 6, 12, 25].
1
6) 2001 :
Consistent hashing est mobilisé, dans [12], pour résoudre des défis techniques qui se
posent dans les réseaux pair-à-pair (P2P). Un problème clé dans les réseaux P2P est de
savoir comment garder la trace de l'endroit où chercher un fichier, comme par exemple
un mp3. Cette fonctionnalité est souvent appelée "une table de hachage distribuée", ou
DHT : Distributed Hash Table. DHTs étaient un sujet de recherche très chaud dans les
premières années du 21ème siècle.

Les réseaux P2P de première génération, comme Napster, ont résolu ce problème en
ayant un serveur centralisé garder une trace de l'endroit où tout est. Un tel réseau a un
seul point d'échec, raison pour laquelle il est donc aussi facile à arrêter. Les réseaux P2P
de deuxième génération, comme Gnutella, utilisés des protocoles de radiodiffusion afin
que chacun puisse garder une trace de l'endroit où chaque chose se trouve. C'est est une
solution coûteuse, qui plus est difficilement mise à l'échelle quand le nombre de nœuds
du réseau P2P augmente significativement (Cf. scalabilité). Les réseaux P2P de troisième
génération, comme Chord [12], utilisent le hachage cohérent pour garder la trace d'où
chaque chose se trouve. Le principal défi est de mettre en œuvre l'opération de
successeur présentée à la section II.2. (La technique du hachage cohérent - Page 11),
même si personne ne garde la trace de l'ensemble des serveurs. L'idée de haut niveau
dans [12], qui a été copié ou affiné dans plusieurs réseaux P2P ultérieurs, est que chaque
machine devrait être responsable de garder la trace d'un petit nombre d'autres machines
du réseau. Une recherche de l'objet est alors envoyée à la machine appropriée en
utilisant un protocole de routage intelligent.

Le hachage cohérent reste en usage dans les réseaux P2P modernes, y compris pour
certaines fonctionnalités du protocole BitTorrent.

7) 2006 :
Amazon met en œuvre son propre système Dynamo [9] en utilisant le hachage cohérent.
Le but de ce système est de stocker des tonnes d'objets à l'aide du matériel, tout en
maintenant un temps de réponse très rapide. Autant de données que possible sont
stockées dans la mémoire principale et le hachage cohérent est utilisé pour garder une
trace de ce qui est où.

Cette idée est maintenant largement copiée par les alternatives modernes, ie.
lightweight, de gestion des accès mémoire au niveau des bases de données, qui sont
traditionnellement stockées sur le disque. De telles alternatives ne supportent
généralement que peu d'opérations (par exemple, pas de clés secondaires), et se
détendent les traditionnelles exigences de consistance, et de cohérence, en échange de
la vitesse. Comme vous pouvez l'imaginer, cela est une grande victoire pour beaucoup
d'entreprises de l'Internet moderne.

I.1. Web Caching : définition et pour quel besoin

La motivation initiale du "consistent hashing", en 1997, a été la mise en cache pour le Web,
ou Web Caching en anglais.

2
Dans le contexte du Web, imaginez un navigateur demandant une URL 4 , comme
www.amazon.com . Bien sûr, on pourrait demander la page au serveur Web approprié.
Mais si la page est demandée maintes et maintes fois, il est inutile de la télécharger de façon
répétée à partir du serveur d'origine. Une idée évidente est d'utiliser un cache Web, qui
stocke une copie locale des pages récemment visitées. Quand une URL est demandée, on
peut d'abord vérifier la présence de la page visée dans le cache local. Si la page est dans le
cache local, on peut l'envoyer directement au navigateur, sans avoir à communiquer avec le
serveur d'origine. Si par contre la page ne se trouve pas dans le cache local, on la télécharge
depuis le serveur, puis elle est envoyée au navigateur et également stockée dans le cache
local pour une éventuelle réutilisation future.

La mise en cache 5 est bénéfique pour le Web. L'avantage le plus évident est que l'utilisateur
final jouit d’un temps de réponse beaucoup plus rapide. De plus, les caches améliorent
également l'Internet dans son ensemble : moins de demandes adressées à des serveurs
lointains signifie moins de trafic sur le réseau, moins de congestion dans les files d'attente
des commutateurs réseaux ou des serveurs Web, moins de paquets de données perdues,
etc.

Ainsi, l'installation d'un cache aide à soulager trois problèmes impactant les performances du
Web :

1) Congestion du réseau :
Comme vu dans l'exemple précédant, la reproduction des informations dans un cache
empêche le trafic superflu de circuler sur la toile d'internet. Ceci réduit la congestion
du réseau et les problèmes qui lui sont souvent liés (ie : des paquets pourraient être
retardés, voire même supprimés par des routeurs si le réseau est encombré).

2) Serveurs inondés :
La charge du serveur Web, fournisseur de contenu, est ainsi réduite. Ceci est d'autant
important pour les sites populaires, qui pourraient autrement être inondés de
demandes (ie. : requêtes des utilisateurs). Ce phénomène étant connu sous le nom de
: le "hot_spot problème".

3) Distance :
Finalement, le temps d'attente (ou latence) de l'utilisateur est réduite puisque les
informations recherchées sont géographiquement plus proches de l'utilisateur à servir.

Il apparaît donc clairement que nous avons besoin des caches au niveau du Web. Où
doivent-ils s’installer ?. Une première idée est de donner à chaque utilisateur final son propre

4
Le sigle URL (de l'anglais Uniform Resource Locator, littéralement « localisateur uniforme de
ressource »), auquel se substitue informellement le terme adresse web, désigne une chaîne de
caractères utilisée pour adresser les ressources du World Wide Web : site Web, document ou page
HTML, fichier (image, son, vidéo, document pdf ou autre), forum Usenet, entre autres.
L'URL est un format de nommage universel pour désigner une ressource, de manière unique, sur
Internet. C'est pour cette raison, que cette invention du Web, est aussi appelé adresse universelle.
Exemple : https://en.wikipedia.org/wiki/Uniform_resource_locator
5
La notion de mémoire cache est apparue commercialement sur le mainframe IBM 360/85 en 1968. Elle
fut d'abord utilisée par les processeurs, qui y enregistre temporairement une copie de la dernière
instruction qu'il vient d'exécuter. Le but étant de diminuer le temps d'un nouvel accès postérieur à
cette même instruction, et par suite influencer positivement la vitesse de traitement du programme
encours d'exécution.
3
cache, maintenu sur sa propre machine ou appareil. Donc, si vous demandez la page
www.amazon.com, et vous l’aviez aussi demandée dans un passé récent, la page peut vous
être retournée à partir de votre cache local. Si non, vous recevrez un échec du cache, et la
page sera téléchargée puis stockée dans votre cache local.
Cependant, nous pourrions prendre avantage de la mise en cache à un niveau supérieur si
nous pouvions mettre en œuvre un cache de Web qui est partagé par de nombreux
utilisateurs, par exemple, tous les utilisateurs du réseau CNAM.
Par exemple, si vous n'avez pas consultée amazon.com récemment mais quelqu'un de votre
proximité l’a fait (par exemple, quelqu'un d'autre dans le réseau du CNAM), ça ne serait pas
intéressant si vous pouviez simplement utiliser leur cache locale ?. Les avantages sont
évidents : en agrégeant les dernières demandes de pages (ou requêtes URL) d'un grand
nombre d'utilisateurs, ces utilisateurs pourront profiter, avec plus de succès, de plusieurs
pages dans le cache, et bénéficier par conséquent d’un temps de réponse réduit, soit moins
de latence 6 .

Pourquoi ceci n’est pas un problème facile?. Nous zoomons sur l'un des nombreux obstacles,
à savoir, mémoriser l’ensemble des pages Web récemment consultées par un grand nombre
d'utilisateurs pourrait prendre beaucoup d’espace de stockage. A moins de vouloir recourir à
une unique grosse machine, lente, et dédiée spécialement à cet effet, le cache agrégé
pourrait tout aussi bien ne pas tenir sur une seule machine.
I.2. Les différentes approches de ″caching″
Il y a deux approches extrêmes pour la mise en œuvre du cache. Dans la première approche
nous avons une architecture monolithique du cache où une grande et unique mémoire cache
est placée dans une ville pour servir tous les utilisateurs citoyens de la ville (voir Figure 2).
Cette architecture présente l'inconvénient qu'il y a un seul point d'échec et que le cache peut
être encombré dès lors que tous les habitants de la ville l'utilisent.

Figure 1 : Architecture du cache monolithique.

Un cache unique est placé dans la ville pour servir tous les utilisateurs. Puisque le
cache reçoit des demandes d'une grande population, le taux de présence va

6
A ce propos, l'objectif de la société Akamai était de prendre les consultations Web d’un jour, soit un
seul cache Web logique, partagée par plusieurs utilisateurs et le transformer en une technologie
viable.
4
 probablement être haut. Cependant, il a l'inconvénient que le cache doit être de
grande taille, et placé sur une machine à très grande tolérance aux pannes.

La deuxième architecture surmonte ces problèmes en utilisant une approche distribuée.

Chaque voisinage, ou quartier, a son propre cache qui sert l'ensemble des résidents du
quartier (voir Figure 3).

Figure 2 : Architecture du cache distribuée

Chaque voisinage a un cache qui sert les utilisateurs résidents dans ce voisinage.
Les caches étant très proches des utilisateurs, aussi n'importe quel contenu qui est
localisé dans le cache est retrouvé très rapidement et efficacement. Cependant,
puisque chaque cache reçoit seulement des demandes (requêtes) d'un petit nombre
d'utilisateurs, le taux de présence (ou de succès) va probablement être petit.

Ce système contourne les deux problèmes, susmentionnés, de l’architecture monolithique : Il

survivra à un échec et il étend le travail à travers plusieurs machines. En outre, il a
l'avantage que les caches sont encore plus proches de l'utilisateur et peuvent donc délivrer le
contenu demandé plus rapidement.

Cependant, cette architecture distribuée présente aussi quelques inconvénients. Le plus

grand est que le taux de présence, de l’information demandée au niveau du cache, sera
inférieur.
La première raison à cela est que les caches reçoivent des demandes (ou requêtes) d'une
population plus petite. Une autre raison est que les caches individuels sont plus petits que le
grand cache de l'approche monolithique et stockent donc seulement un sous-ensemble plus
petit des informations des fournisseurs de contenu.

Ainsi, la mise en oeuvre d'une mémoire cache partagée à grande échelle nécessite sa
diffusion sur plusieurs machines.

Maintenant, supposons qu'un navigateur demande amazon.com et vous voulez savoir si la

page Web a été mise en cache localement. Supposons que le cache partagé est réparti sur
100 machines. Où devrait vous cherchez une copie de la page Web mise en cache?. Vous
5
pouvez interroger tous les 100 caches à la recherche de la copie désirée, mais ceci semble
bien ingrat. Et avec beaucoup d'utilisateurs et des caches, cette solution franchit la ligne de
l’infaisable. Cà ne serait pas magique si, au lieu de cela, étant donné une URL (comme
amazon.com) nous saurions à quel cache s’adresser, par exemple celui de la machine , ou
serveur, numéro 23, pour récupérer la copie de la page recherchée?.

Il y'a deux façons de combiner les deux approches extrêmes qui ont été décrites plus-haut.

Une idée, appelé "harvest caching", est d'avoir un système hiérarchique combinant les
caches de voisinage distribuées et le cache monolithique de la ville (voir Figure 3). Une
requête est d'abord envoyée au cache de voisinage le plus proche, et si l'information
recherchée n'est pas disponible, la demande est expédiée (ou requête avancée) au cache de
la ville.
Cette solution a certains des avantages des deux approches extrêmes, à savoir la bonne
localité et le haut taux de présence (succès), mais elle a aussi l'inconvénient principal du
système monolithique : le grand cache doit être hébergé sur une machine tolérante aux
pannes et munie d'une grande mémoire. D'où un coût élevé de la machine, voire même son
infaisabilité.

Figure 3 : Une hiérarchie de caches constituée de petits caches de voisinage en bas

de la hiérarchie et un grand cache monolithique de la ville en haut. Les demandes
(ou requêtes) sont d'abord envoyées au cache local de voisinage, et en cas d’échec
ils sont transférés au cache de la ville. Les caches de voisinage rapprochent le
contenu de l'utilisateur, tandis que la cache de la ville agrége les requêtes d'une
large population, et empêche ainsi le trafic superflu de traverser le réseau à
l'extérieur de la ville. Le problème avec ce système est que le cache de la ville doit
être une machine (ou un groupe de machines) puissante et tolérante aux pannes, ce
qui est cher voire même infaisable à construire et à maintenir.

6
La deuxième solution essaye de réaliser les avantages des deux approches extrêmes incluant
le bon taux de présence d'un grand cache, sans le besoin actuel pour une grande machine
tolérante aux pannes. L'idée est d'avoir un réseau de caches distribués qui coopèrent. Dans
un tel système chaque client choisit un cache principal (ou primaire) à qui il envoie ses
demandes. Si le cache principal manque, il essaye de localiser le document demandé dans
un des autres caches (par la multidiffusion de la demande), au lieu d'aller directement au
fournisseur de contenu. Cette technique a tous les avantages des précédents, mais introduit
un nouveau problème : comme le nombre de caches participants grandit, le nombre de
messages échangés peut devenir ingérable.
Donc, la question est comment faire fonctionner ensemble un groupe de caches comme un
seul grand cache, sans avoir de communications inter-caches nombreuses, et par suite
ingérables.

I.3. L'utilisation du hachage en mémoire cache

Formellement, nous voulons une cartographie à partir d'URLs à des caches. La première
pensée pourrait être d'utiliser une fonction de hachage à cet effet.

Figure 4: Une fonction de hachage fait correspondre à des éléments d'un univers U
(généralement grand) une liste de "buckets", comme des valeurs 32 bits.

Une «bonne» fonction de hachage H satisfait deux propriétés :

1) Elle est facile à retenir et à évaluer. Idéalement, le calcul de la fonction H comprend

juste quelques opérations arithmétiques, et peut-être une opération modulo "mod".
2) À toutes fins pratiques, H se comporte comme une fonction totalement aléatoire,
diffusant les données uniformément et sans corrélation notable entre les "buckets"
possibles.

7
Concevoir de bonnes fonctions de hachage n’est pas une tâche aisée, mais nous pouvons le
considérer comme un problème résolu. Une approche usuelle dans la pratique consiste à
utiliser une fonction de hachage bien connue, et bien conçu comme MD5 7 .

Il est plus que probable que cette fonction "se comporter de façon aléatoire" pour tout
ensemble de données que vous utilisez. Des garanties théoriques sont possibles seulement
pour les familles de fonctions de hachage 8 , qui motivent le choix d'une fonction de hachage
au hasard à partir d'une famille « universelle ».

Supposons l'existence d'une bonne fonction de hachage h pour acquis, nous pouvons
résoudre le problème du mapping des URLs à des caches.

Supposons qu'on a n caches, nommés {0, 1, 2, ..., n - 1}. Ensuite, nous pouvons simplement
stocker la page Web avec l'URL x au serveur nommé :
h (x) mod n (1)

Notez que h (x) est probablement quelque chose comme une valeur 32 bits, représentant un
nombre entier qui est bien plus grand que n. C’est bien pour cette raison que nous
appliquons l'opération "mod n" pour récupérer le nom de l'un des caches, nommés pour
rappel dans l’ensemble {0, 1, 2, ..., n - 1}.

La solution (1) de mappage des URLs à des caches est une excellente première, et qui
fonctionne très bien dans de nombreux cas. Toutefois, supposons que le nombre n des
serveurs n’est pas statique, mais qu’il change continuellement au fil du temps.

Par exemple, pour l’équipe d'Akamai en ses débuts jours, ils se sont concentrés sur l'ajout
d'autant de caches que possible partout sur Internet, de sorte que n était en constante
augmentation. Les caches Web peuvent également échouer ou perdre la connexion au
réseau, ce qui provoque la diminution de la valeur de n. Dans un contexte réseau peer-to-
peer (Cf. 6.2.), n correspond au nombre des nœuds du réseau P2P, et n est en constante
évolution en fonction des nœuds rejoignent ou quittent le réseau (voir chrum).

Supposons que nous ajoutons un nouveau cache, et faisons ainsi grimper n de 100 à 101.
Pour un objet x, il est très peu probable que (h (x) mod 100) et (h (x) mod 101) soient le
même nombre. Ainsi, le changement de n force presque tous les objets x à déménager :
c’est une catastrophe pour les applications où n est constamment en changement 9 .

7
MD5 est intégrée à la plupart des langages de programmation. De plus, vous pouvez simplement
copier son code à partir du Web. Vous pourriez vouloir utiliser quelque chose de plus rapide et plus
léger (mais toujours sous test), comme une fonction de hachage de la famille FarmHash.
8
En supposant que le nombre de « buckets » n est significativement plus petit que la taille de l'univers
U, toute fonction de hachage a pathologiquement un large ensemble données S ⊆ U. Pour cette
raison, plusieurs éléments de S pourraient être hachés au même bucket, et entrer par suite en
collision. (Cf. : Pigeonhole Principle)
9
Ce déménagement nous rappelle l'opération "rehash", soit l’application d’une 2eme fonction de
hachage, qui existe dans la plupart des implémentations des tables de hachage. Rappelons que quand
le facteur de charge (# nombre d'éléments / # buckets n) d'une table de hachage augmente, le temps
de recherche se rallonge. Ainsi quand le facteur de charge devient trop grand, un d'habitude des
augmentations le nombre de buckets, en le multipliant par exemple par 2, ce qui exige le
remaniement (ou rehachage) de tous les éléments. Ceci est une opération lourde et coûteuse, mais
traditionnellement justifiée si elle n’est invoquée que rarement. Dans le contexte de la mise en cache
8
 Figure 5 : La figure supérieure (i) montre l'attribution de 10 documents à
4 serveurs utilisant la fonction de hachage f (d) = d + 1 mod 4. La partie
inferieure de la figure (ii) montre la nouvelle attribution après qu'un
serveur supplémentaire est ajouté et la fonction de hachage changée à :
f (d) = d + 1 mod 5. Les carrés montrent l'attribution de la nouvelle
fonction et les cercles montrent celles de la fonction précédente. Notez que
presque chaque document est attribué à un serveur différent suite à
l’introduction du nouveau serveur.

Chapitre II : Consistent Hashing

Notre critique de la solution (1) pour cartographier des URLs vers des caches a motivé
l'objectif du Consistent Hashing : nous voulons une table de hachage type, avec la
fonctionnalité de pouvoir stocker des "trucs" et les récupérer plus tard, disposant de la
propriété supplémentaire que presque tous les objets restent affectés au même cache même
si le nombre n des caches change.

Web, le nombre de buckets change tout le temps. En outre, « rehacher » un objet implique le
déplacement de données entre plusieurs machines à travers le réseau, ce qui est plus coûteux que le
« rehachage » des éléments d'une table de hachage stockée sur une seule machine.

9
II.1. Les objectifs de conception

David Karger, Daniel Lewin et d'autres, du MIT à Boston, ont développés, dans [1], [2] et
[3], une nouvelle approche, consistent hashing, qui s'efforce de surmonter les inconvénients
des approches ci-dessus mentionnés, tout en gardant leurs avantages. Les objectifs de
conception qu'ils avaient à l'esprit à l'époque étaient les suivants :

 un système distribué :
Le système devrait être construit avec un grand nombre de petits caches, bon marché,
distribués partout dans le réseau. De cette façon, il y a un cache près de chaque utilisateur
et la charge totale est distribuée sur plusieurs machines.

 Pas de control centralisé :

Le comportement du cache devrait dépendre seulement des informations disponibles
localement ou obtenues de manière non centralisée, sans aucun contrôle central qui pourrait
se révéler un point critique d'échec.

 Robustesse sous différentes vues :

Les caches peuvent être ajoutés et enlevés du réseau à tout moment, et il n'y a aucun
contrôle central qui garde la trace du statut des machines de cache. Ainsi, des utilisateurs
différents peuvent avoir des vues différentes de l'ensemble des caches.

 Scalabilité :
Le Web grandit chaque jour et par suite le système de caching devrait se maintenir efficace
en cas d'augmentation significative de l'utilisation. Donc le système devrait être capable de
maintenir ses performances en cas de forte demande ou de montée en charge du réseau.

 Prévenir le problème “hot spots” :

Les machines de cache et les serveurs ne devraient jamais être inondés. Pour la simple
raison que la réassignation de la responsabilité d'une page chaude d'un serveur à un cache
ne marchera pas si le cache est inondé.

 Minimiser le traffic :
Le système devrait être conçu pour que le trafic total sur le réseau Internet soit réduit autant
que possible. Cela signifie que le système de cache devrait être conçu pour qu'autant de
demandes que possible soient servies au plus près du demandeur.

 Répartition de charge :
La capacité de stockage d'une machine de cache est limitée. Aussi, aucun cache ne devrait
être obligé de stocker une fraction disproportionnée des pages de cache, et la charge globale
devrait être équitablement répartie entre les différents caches disponibles. (ie. : Load
Balancing en anglais).

 Minimiser l’attente :
Le système de cache doit être assez simple pour ne pas augmenter significativement la
latence de l'utilisateur.

Nous présentons en 3.1. une des plus populaire mise en œuvre de cette fonctionnalité [2] 10 .

10
On ne devrais jamais confondre deux choses fondamentalement différentes :
10
II.2. La technique du hachage cohérent
L'idée clé est : en plus du hachage des noms de tous les objets (càd les URLs) x, comme
auparavant, nous hachons aussi les noms de tous les serveurs s. Les noms d'objets et des
serveurs doivent être hachés à la même taille, comme des valeurs 32 bits.

Figure 6 : Chaque élément du tableau ci-dessus est un bucket de la table de hachage.

Chaque objet x est assigné au premier serveur s sur sa droite.

Figure 7 : (Gauche) Nous collons 0 et (232 − 1) ensemble, de telle sorte que les objets soient assignés
au serveur le plus proche dans le sens horaire (ie. des aiguilles d'une montre). Ceci résout le problème
du dernier objet se trouvant à droite du dernier serveur. (Droite) Ajout d'un nouveau serveur s3.
L’objet x2 se déplace de s0 à s3.

Pour comprendre quels objets sont affectés à quels serveurs, considérez le tableau de la
Figure 2, indexées par les valeurs possibles de hachage. (Ce tableau peut être très grand et
il n’existe que dans nos esprits; nous allons présenter sa mise en œuvre effective plus loin.)
Imaginez que nous avons déjà haché tous les noms de serveurs et les avons notés dans les
« buckets » correspondants.

(i) ce qu’un algorithme, ou structure de données, est censée faire (i.e., sa spécification /API); et (ii) la
mise en œuvre ou implémentation (par exemple, la façon dont la fonction souhaitée est
effectivement atteinte et réalisée). Il peut, bien sûr, y avoir des mises en oeuvre multiples pour une
même fonctionnalité. Par exemple, les objectifs du consistent hashing peuvent aussi être réalisés par
d'autres implémentations et mises en œuvre [13, 11].

11
Étant donné un objet x mappé au bucket h(x), nous parcourons les buckets à droite de h(x)
jusqu'à ce que nous trouvions un bucket h(s) au quel le nom d’un certain serveur s est
haché. (Nous enroulons autour du cercle, si nécessaire). Nous désignons ensuite le serveur s
comme responsable de l'objet x.

Cette approche peut également être visualisée sur un cercle, avec des points sur le cercle
correspondants aux valeurs de hachage possibles (Figure 3 (Gauche)). Serveurs et objets
sont tous deux hachés à des points sur ce cercle; un objet est stocké sur le serveur qui est le
plus proche dans le sens des aiguilles d'une montre. Ainsi, n serveurs divisent le cercle en n
segments, avec chaque serveur responsable de tous les objets contenus dans un seul de ces
segments.

Cette idée simple conduit à des propriétés intéressantes. Tout d'abord, en assumant des
fonctions de hachage raisonnables, la charge attendue sur chacun des n serveurs est
exactement une fraction de 1/n des objets 11 . Deuxièmement, et ce qui est plus important
encore, supposons que nous ajoutons un nouveau serveur s – quels objets devront se
déplacer? Seulement les objets à stocker en s. (Voir Figure 3 (à droite)).

Combinées, ces deux observations impliquent que l’ajout d’un nième serveur provoque le
déménagement de seulement 12 une fraction des objets, soit 1/n. Ceci est le meilleur scénario
possible si nous voulons que la charge soit répartie uniformément. Clairement, les objets à
charger sur le nouveau serveur doivent se déplacer de l'endroit où ils étaient auparavant 13 .

a) Opérations sur la table de hachage cohérente :

Comment pouvons-nous mettre en œuvre les opérations standard, comme la recherche et

l’insertion, au niveau de la table de hachage cohérente ?.

Étant donné un objet x, les deux opérations se résument au problème de mise en œuvre
efficace du scan horaire vers la droite pour le serveur s qui minimise h (s) soumise à la
condition h (s)  h (x) 14 .

Ainsi, nous voulons une structure de données pour stocker les noms des serveurs, avec les
valeurs de hachage correspondantes en tant que clés, qui supportent une opération de
successeur rapide. Une table de hachage n’est pas assez bonne, vue qu’elle ne maintient
11
En cas de variance significative, nous pouvons la réduire via la « réplication ».
12
En revanche, avec la solution (1) : h(x) mod n, en moyenne seulement 1/n des objets ne bougent
pas lorsque le nième serveur est ajouté !.
13
You might wonder how the objects actually get moved. There are several ways to do this, and the
best one depends on the context. For example, the new server could identify its "successor" and send
a request for the objects that hash to the relevant range. In the original Web caching context, one can
get away with doing nothing: a request for a Web page that was re-assigned from an original cache s
to the new cache s0 will initially result in a cache miss, causing s0 to download the page from the
appropriate Web server and cache it locally to service future requests. The copies of these Web
pages that are at s will never be used again (requests for these pages now go to s0 instead), so they
will eventually time out and be deleted from s. (in [8])
14
Nous ignorons le cas du cercle, ie. "wrap-around", qui peut être traité séparément comme un cas
limite.

12
aucune information d'ordre; Un tas, ou heap, n'est pas assez bon : il ne maintient seulement
qu’un ordre partiel pour que l'identification du minimum soit rapide ; mais rappelons que la
recherche dans les arbres binaires, qui maintiennent un ordre total des éléments stockés,
supporterait pleinement une fonction de Successeur 15 . Vu que le temps d'exécution de cette
opération est linéaire dans la profondeur de l'arbre, il serait judicieux d'utiliser un arbre
binaire de recherche équilibré, comme un arbre Rouge-Noir 16 . Trouver le serveur
responsable du stockage d’un objet donné x requiert un temps en O(log n), où n est le
nombre de serveurs.

Figure 8 : Exemple d’arbre bicolore ou arbre rouge-noir.

b) Réduire l'écart de charge :

Bien que la charge prévue de chaque serveur est une fraction de 1/n des objets, la charge
réalisée, ou réelle, de chaque serveur peut varier. Ce phénomène étant bien connu par la
"répartition de charge" ou "Load balancing". Schématiquement, si vous choisissez n points
aléatoires sur le cercle, il est très peu probable d'obtenir une division parfaite du cercle en
segments de tailles égales.

Un moyen facile de réduire cet écart est de faire k "copies virtuelles" de chaque serveur s.
Ceci peut être réalisé en hachant le nom du serveur s avec k différentes fonctions de
hachage, pour obtenir h1(s), … , hk(s).

Par exemple, avec les serveurs {0; 1; 2} et k = 4, nous choisissons 12 points sur le cercle : 4
étiquetés "0", 4 étiquetés "1" et 4 autres points étiquetés "2". (Voir Figure 5)

Les objets x sont assignés comme auparavant, càd à partir de h (x), nous scannons à droite
dans le sens horaire jusqu'à ce que nous rencontrions une des valeurs de hachage d’un
certain serveur s, ensuite s est chargé de stocker x.

15
Cette opération est généralement survolée dans la documentation sur les arbres de recherche, mais
elle est exactement ce que nous voulons ici!
16
Pour plus d’information sur ce type de structure, voir : https://fr.wikipedia.org/wiki/Arbre_bicolore

13
 Figure 9 : Répartition de charge par "copies virtuelles"
Diminution de l’écart en attribuant à chaque serveur multiples valeurs de hachage.

Par symétrie, chaque serveur s’attend toujours à obtenir une fraction de 1/n des objets.
Cette réplication augmente le nombre de clés stockées dans l’arbre binaire de recherche
équilibré par un facteur k, mais elle réduit l’écart de charge entre serveurs de manière
significative. Intuitivement, quelques copies d'un serveur obtiendront plus d'objets que prévu
(plus de 1/Kn fraction), mais ceci sera en grande partie neutraliser par d'autres copies qui
obtiennent moins d'objets qu'attendu. Le choix de k = log2 (n) est assez grand pour obtenir
des charges raisonnablement équilibrées.
Les copies virtuelles sont également utiles pour traiter les serveurs hétérogènes qui ont des
capacités différentes. Une approche raisonnable consiste, pour un serveur donné, à réaliser
un nombre de copies virtuelles proportionnel à la capacité du serveur en question. 17

17
Par exemple, si un serveur est deux fois plus grand qu’un autre, il devrait avoir deux fois plus de
copies virtuelles.
14
 Figure 10 : Cette figure illustre comment les fonctions de hachage distribuent les
documents entres serveurs. Supposez que les noms des documents sont des entiers, et
qu'il y a 13 serveurs numérotés de 1 à 13. Les documents sont hachés aux serveurs
utilisant un type commun de fonction de hachage qui est :
f (d) = a d + b mod 13 , avec a et b des entiers fixes. (i) présente la distribution
originale de 134 documents aux serveurs.

Notez que quelques serveurs stockent beaucoup plus de documents que d'autres, et
ainsi dans le modèle de fréquence d'accès égale ils sont plus lourdement chargés. (ii)
représente la distribution de documents aux serveurs par la fonction de hachage.
Aucun serveur n'est responsable d'une façon disproportionnée d’une grande partie des
documents.

II.3. Les propriétés d’une fonction de hachage cohérent

Nous récapitulons ci-dessous les propriétés que devrait avoir toutes fonction de hachage
cohérent :
 Équilibre :
Les items sont affectés aux ʺbucketsʺ aléatoirement.

 Monotonicity:
Quand un ʺbucketʺ est ajouté les seuls items réassignés, ou réaffectés, sont ceux qui
sont assignés au nouveau ʺbucketʺ.

 Charge :
La charge d'un ʺbucketʺ est le nombre d'items assignés à un ʺbucketʺ sur un ensemble
de vues. Idéalement, la charge devrait être petite.

15
  Diffusion :
La diffusion d'un item est le nombre de ʺbucketʺ où l’item est placé sur un ensemble de
vues. Idéalement, la diffusion devrait être petite.

Chapitre III : Exemples d'utilisation du Consistent hashing

Après la présentation d'une des plus célèbres implémentation du consistent hashing, nous
zoomons sur quelques contributions majeures du consistent hashing, notamment au niveau
des tables de hachage distribuées (DHT pour l'anglais Distributed Hash Table) utilisées dans
les réseaux peer-to-peer, et des systèmes de stockage distribué tel que Memcached ou
Dynamo [9] d'Amazon.

III.1. L’implémentation d’Akamai

En 1998, Danny Lewin[2] et son professeur encadrant Tom Leighton fondèrent une société
appelée Akamai, qui emploie effectivement le hachage cohérent. Cette société maintient des
caches partout à travers le monde, et offre ainsi aux utilisateurs du Web l’accès rapide aux
données stockées dans ses caches pour le compte des fournisseurs de contenu. Akamai met
en cache principalement des photos et d'autres fichiers. La raison est que ce sont
généralement les gros fichiers en terme de taille, qui constituent la majeure partie de la
charge au fournisseur de contenu et sont aussi principalement responsable de la latence
élevée dans la récupération d'une page Web.

Il se trouve qu'Akamai utilise un hachage des noms de serveurs pour vous permettre
d'obtenir le fichier demandé à partir du cache le plus proche. La Figure 11 illustre comment
cela fonctionne. Le hachage est fait en deux étapes :

1) Le fournisseur de contenu hache l'URL en un numéro de série, par exemple, 212

dans l'exemple. Si cette URL est demandée, le serveur local demande d'abord au
serveur haut-niveau d’Akamai de lui fournir l'adresse IP du serveur bas-niveau.

2) Le serveur de nom de bas niveau évalue la fonction de hachage cohérente pour la

vue courante sous le numéro de série donné. Il retourne ensuite les adresses IP des
caches où le document est mappé en vertu de la fonction de hachage cohérente.

Akamai met à la disposition du fournisseur de contenu un programme qui fait la première

étape, à savoir la cartographie des URLs vers des numéros de série. En général, le
programme essaie d’affecter le même numéro de série à toutes les URL relatives à un
document HTML donné, de manière à minimiser le nombre de recherches DNS. Cependant,
si une certaine limite sur le nombre total d'octets de l'objet sur un numéro de série est
atteinte, il va commencer à utiliser un nouveau numéro de série. L'objectif est de minimiser
les recherches DNS, sans que ceci ne rendre la répartition de charge, ou « load balancing »
en anglais, sur les serveurs difficile à réaliser.

Supposons qu'un fournisseur de contenu hache un document à l'étape 1 à

"a1.g.akamai.net". Ci-dessous, nous utilisons des outils utiles pour montrer comment la
résolution de noms fonctionne pour ce document "akamailisé" et de suivre la façon dont une
demande de ce document est traitée.

16
 Figure 11: Comment la requête ʺa212.g.akamai.netʺ est résolue dans Akamai

dig (Domain Information Groper) envoie des paquets de requête de nom domaine aux name
serveurs, et peut être utilisé pour recueillir des informations à partir des serveurs Domain
Name System. Dans la figure 12, nous exécutons dig a1.g.akamai.net pour savoir à quel
serveur d’Akamai notre document est mappé. Le résultat de l’exécution nous renseigne que
"a1.g.akamai.net" relève des adresses IP 206.245.157.79 et 206.245.157.71, et que le
temps de la requête était de 1 ms.

Figure 12: Utilisation du "dig" dans l'implémentation Akamai

17
Le second outil est traceroute. Il imprime le chemin parcouru par les paquets pour un réseau
hôte. La Figure 13 montre le résultat de traceroute a1.g.akamai.net.

Nous voyons que cela prend 10 sauts jusqu'à ce que le paquet atteigne finalement le serveur
d’Akamai d’adresse IP 206.245.157.79. Pour rappel, cette dernière est l'une des deux
adresses IP où a1.g.akamai.net est mappé. En outre, le paquet met en moyenne environ 16
ms pour y arriver à destination.

Figure 13: Utilisation du " Tracroute " dans l'implémentation Akamai

III.2. Les tables de hachage distribuées et les réseaux P2P :

Le Hachage Cohérent, ou Consistent Hashing, est également largement utilisé dans les tables
de hachage distribuées (DHT pour l'anglais Distributed Hash Table), notamment dans les
célèbres réseaux peer-to-peer (P2P 18 ).

Les réseaux P2P sont des réseaux logiques distribués dont le principe de base est un principe
d’égalité entre des nœuds dynamiques, appelés pairs ou peer en anglais. Ils sont, par
ailleurs, des réseaux de recouvrement 19 spécifiques, dont une bonne partie d’entres eux sont
à base des tables de hachage distribuées 20 .

18
L'acronyme P2P est une contraction de Peer to Peer, en anglais, ou, Pair à Pair, en français. Le
terme P2P sera utilisé par la suite.
19
Un réseau de recouvrement ou overlay est un réseau virtuel s’appuyant sur un ou plusieurs réseaux
physiques existants. Parmi ces réseaux existants, dits sous-jacents ou underlay, l’Internet (ou des
sous-réseaux de l’Internet) est un bon exemple.
20
La DHT est une table de hachage partagée entre tous les éléments actifs d’un système réparti.

18
 Figure 14 : Modèle de réseau P2P.

La particularité des DHTs utilisées dans les architectures P2P est la fonction de hachage, qui
est dite consistante (consistent hashing). Elle garantit avec une probabilité élevée une
distribution uniforme des ressources sur l’ensemble des nœuds et un déplacement de O(1/N)
objets lors de l’arrivée ou du départ d’un Nième pair du réseau 21 . En effet, la dynamique des
pairs induit l’échange de messages et le déplacement d’objets pour préserver la structure et
la cohérence de la DHT. Les architectures P2P à base de DHTs représentent alors de faibles
coûts de maintenance et d’utilisation.

Figure 15 : Classification des systèmes P2P, avec quelques exemples.

La grande majorité des architectures P2P décentralisées structurées est basée sur des DHT.

21
La variation de la structure du réseau pair-à-pair, due à l’arrivée et au départ non anticipé de pairs,
est appelée churn.

19
Les tables de hachage distribuées (DHT)

Chaque pair, du réseau P2P, met à disposition une partie de ses propres ressources, appelés
aussi objets, et reçoit un identifiant unique, dit nodeId 22 . Il en est de même pour chaque
ressource, dont l’identifiant est dit objectId. Lorsqu’on parle d’une requête, l’objectId
recherché est dit key.

L'identifiant nodeId de la pair, est résultat de l'application d'une fonction de hachage sur son
adresse IP (par exemple SHA1 ou MD5). Les pairs peuvent ainsi être classés selon leur
identifiant au sein d'une table de hachage distribuée. Chaque pair possède alors un index
contenant un certain nombre d'autres pairs répartis sur la DHT. Le contenu de cet index
varie selon l'implémentation. En utilisant cette approche, des systèmes pair-à-pair comme
Chord [12], Pastry ou Tapestry obtiennent une couche de routage très performante.

Les nodeId et objectId sont dans un même espace logique K qui correspond à l’index global
de la DHT. Chaque pair est responsable d’une partie de cet espace. Cette partie est nommée
"la DHT du pair".

Dépendamment de l’implémentation de la DHT, l’espace de hachage correspondant (et donc

la DHT) peut être visualisé comme une grille, un cercle (ou anneau), ou une ligne.
L’ensemble des identifiants forment alors une structure logique : un anneau dans les
systèmes Chord [12] et Pastry ou bien un tore d-dimensionnel dans CAN.

L’implémentation de la DHT est spécifique à l’algorithme de routage du protocole mis en

œuvre. Cet algorithme va permettre de construire la DHT en associant chaque objectId au
pair responsable de l’objet correspondant. En d’autres termes, étant donné une fonction de
hachage h et un pair ayant une adresse IP @IP et voulant partager sur le réseau une
ressource r, on a :

h(r) = k K ; où k est l’objectId

et h(@IP) = i K ; où i le nodeId

La ressource r, ou un lien vers cette ressource, est alors stockée sur la DHT du pair
d’adresse @IP tel que dist(k, i) est minimale ; dist(k, i) étant la distance entre k et i, telle
que définie dans l’espace logique K. Autrement dit, dans la DHT, r est indexée par le pair
d’identifiant i.

Dans une DHT, un identifiant (i.e., une clé) est associé à chaque pair et à chaque bloc de
données. La clé d’un bloc de données est généralement obtenue par l’application d’une
fonction de hachage sur le contenu du bloc. Le pair dont l’identifiant est le plus proche de la
clé du bloc est appelé racine du bloc.

De même, tout pair d’identifiant j quelconque connaît de par sa DHT tous les pairs
d’identifiant m quelconque, tel que la distance entre j et m est faible. Si m n’est pas
«proche» de k, le pair d’identifiant j a dans sa DHT au moins un pair n strictement plus
proche de k. Ainsi, par itération, j trouve k et peut récupérer la ressource r.

22
Dans la littérature, on dit souvent, par exemple, « le pair 3 », au lieu de dire « le pair d’identifiant
(ou de nodeId) 3 ». Il en est de même pour l’identification des objets.

20
La figure 7 donne un exemple de mécanisme de routage dans un réseau overlay basé sur
une DHT. Le casier jaune représente pratiquement une ligne de la DHT du nœud pointé.

Figure 16 : DHT et mécanisme de routage overlay 23

En utilisant les services de sa DHT chaque pair peut donc à tout moment :
- sur la base du nodeId, établir une communication directe ou indirecte avec un autre pair ;
- et grâce à l’objectId, localiser une ressource.

D’ailleurs, chaque DHT implémente des fonctionnalités de recherche (lookup) et de

récupération (retrieval), assurant deux fonctions principales :
- une fonction put(key, data) qui remplit la DHT ;
- et une fonction get(key) qui permet de localiser un objet à partir de son objectId (qui est
la clé de la requête) en retournant le nodeId du pair responsable de l’objet. Ce pair-ci va
alors fournir l’objet soit directement soit indirectement en indiquant où il peut être trouvé.

Les DHTs garantissent donc l’unicité de la clé 24 et l’aboutissement des requêtes en un

nombre minimal de sauts 25 . Au pire des cas, la localisation d’un objet nécessitera l’échange
d’un nombre de messages logarithmique du nombre de pairs actifs. Par ailleurs, ne perdons
pas de vue que l'’objectif principal des DHTs est le passage à l’échelle. Appliquées aux
réseaux P2P, elles garantissent en plus les quatre propriétés suivantes [27] :

1) un degré de connexion faible :

chaque pair garde en mémoire (dans une liste ou table) un nombre restreint de
connexions actives ;
2) un diamètre petit :
le nombre maximal de sauts nécessaires pour atteindre n’importe quel autre pair du
réseau est minimisé ;
3) un routage “gourmand” :
chaque pair calcule tout seul le plus court chemin pour atteindre la destination ;

23
Figure reprise de : Balke W.-T., Siberski W. (2006) Structured Peer-to-Peer Networks [en ligne].
L3S Research Center, University of Hannover. Disponible sur : http://www.l3s.de/~balke/lecture-
p2p/Vorlesung_3.pdf (consulté le 02.07.2015)
24
Les DHT sont des systèmes de stockage répartis qui utilisent, en effet, une infrastructure s’appuyant
sur des protocoles de routage par clés (Key-Based Routing, ou KBR).
25
Il s’agit là de sauts logiques, par opposition aux sauts physiques que sont les sauts IP.
21
 4) la robustesse :
un chemin vers la destination peut être trouvé même en cas de rupture de liens ou
disparition de pairs.

Dans la dynamique des réseaux P2P, les pairs vont constamment s’organiser pour former un
graphe de communication conforme avec l’implémentation de la DHT et ayant un rapport
diamètre/degré optimal. Ainsi, les systèmes P2P basés sur les DHT fournissent un moyen
passant à l’échelle et tolérant aux fautes pour stocker des blocs de données de manière
totalement distribuée, efficace et simple à utiliser.
Parmi les protocoles de routage dans les réseaux P2P utilisant 26 des DHTs, citons un des plus
connus : "Kademlia". Celui-ci est d’ores et déjà intégrée dans les deux applications P2P de
partage de fichiers, les plus populaires : BitTorrent 27 et eMule 28 .

Les DHT fournissent au développeur un haut niveau d’abstraction pour l’implémentation de

systèmes de stockage persistant à large échelle, masquant ainsi la complexité des protocoles
de tolérance aux fautes, de la réplication et du routage réseau. C’est pourquoi les DHT sont
de plus en plus utilisées pour des applications ayant un fort besoin de fiabilité, telles que les
systèmes de sauvegarde [23], de gestion distribuée de fichiers [24, 25], ou les systèmes de
distribution de données [26].

III.3. Les systèmes de stockage distribués Memcached et Dynamo

Le Consistent haching est aussi largement utilisé dans divers systèmes de stockage tel que
Memcached [7] et Casandra[4]. Il faut dire, que dans ce domaine, les algorithmes de
distribution les plus utilisés sont ceux fondés sur la technique du hachage cohérent [3, 6],
qui est mise en œuvre dans plusieurs systèmes de stockage de données massives.

Memcached est un système, Libre 29 et Open Source, de cache mémoire distribuée à des fins
générales. Il est souvent utilisé pour accélérer les sites Web dynamiques qui utilisent des
bases de données. En effet, pour des grands sites Web dynamiques, comme Wikipedia, avec
une grande charge d’accès aux bases de données, Memcached 30 aide à alléger la charge sur
les serveurs à travers la mise en cache des données en mémoire principale.

Memcached permet de stocker, pour un temps définissable, des données dans la mémoire
principale (ou vive : RAM). Les données qui sont stockées, sous un format de type clé-
valeur, peuvent être de type string, array, object et peuvent provenir notamment d’une base
de données. En mettant en cache les données, dans la RAM, on réduit le nombre de fois où
une source de données externe (comme une base de données ou une API) doit être lue.

26
Ces protocoles ont vu le jour dans les milieux de recherche académique. Les quatre premiers
protocoles sont : Chord [12], Pastry, CAN (Content-Addressable Network) et Tapestry.
27
Loewenstern A. (2008) DHT Protocol. BitTorrent.org. [en ligne]. Disponible sur :
http://www.bittorrent.org/beps/bep_0005.html (consulté le 02.07.2015)
28
eMule-Project.net. (2004) eMule v.40f is available. [en ligne]. Disponible sur :
<http://www.emuleproject.net/home/perl/news.cgi?l=1&cat_id=&b=20> (consulté le 02.07.2015)
29
http://memcached.org/
30
Memcached est sous licence de type BSD.

22
L'architecture de Memcached est simple; le partitionnement s'appuie sur le hachage de la
clé, qui est utilisé pour calculer l'adresse du serveur sur lequel les données sont stockées.
Memcached est en fait une grosse table de hachage (ou hashmap en anglais) distribuée.
L'intelligence du cache est partagée entre le client et le serveur. En outre, la montée en
charge se fait par l'addition de nouveaux serveurs avec plus de RAM.
Les API de Memcached fournissent un très grand tableau de hachage réparti sur plusieurs
machines. Quand la hashmap est pleine, une nouvelle insertion provoque la purge des
données les plus anciennes, soit les moins récemment utilisées.

Ainsi, cette technologie permet de renvoyer directement une donnée demandée à l’utilisateur
sans avoir besoin de questionner la base de données. De plus, en limitant de la sorte le
nombre de requêtes envoyées à la base de donnée, la charge du serveur se trouve
efficacement allégée. Par conséquent, on peut se permettre de réduire le nombre des
serveurs, et de ce fait réduire les coûts.

Parler d’optimisation de la vitesse d’exécution d’un site Web, passe forcement par un
système de cache. En proposant des performances de rapidité puissantes, Memcached est
une solution efficace dans ce domaine, qui a été rapidement adoptée par le Web.

Une raison possible du succès de Memcached est sa simplicité, tant du point de vue de la
compréhension que de l'implémentation. Par ailleurs, il y'a lieu de préciser que Memcached
est un pur système de cache et ne propose pas d’autres fonctionnalités en plus du cache, tel
que la persistance des données 31 , la réplication, l'élasticité et la sécurité. Mais, Memcached
semble avoir trouvé le compromis idéal au niveau des performances et simplicité d'utilisation.
Ce qui n'est pas le cas des autres solutions de cache distribués qui ont étendu la liste des
fonctionnalités de leur solution.

Il est intéressant de noter aussi que Memcached est non seulement une solution de cache
"serveur", mais son protocole d'échange a également participé à sa grande adoption 32 . Le
protocole Memcached est devenu un standard de fait pour le cache avec des librairies
clientes disponibles pour la pluparts des langages : PHP, Python, Java, C#, C, Ruby, Go et
plus.

Développé à l'origine pour alléger la charge des serveurs de base de données du site
populaire de blogs www.LiveJournal.com, Memcached est maintenant utilisé par des géants
du Net, tels que YouTube2, Reddit3, Zynga4, Facebook5,6 et Twitter7.

Depuis 2007 les demandes d'emploi pour les solutions de caches distribués ont fortement
grossi, avec Memcached et Oracle Coherence comme leaders. Les autres solutions comme
VMWare Gemfile, Terracotta EhCache, JBoss Infinispan sont également en forte croissance.

31
enregistrer, par exemple, les données sur le disque dur, pour qu'en en cas de panne ou autres, les
données ne sont pas perdues.
32
Le protocole Memcached est utilisé par de nombreuses solutions qui fournissent des fonctionnalités
comme la réplication, et l'élasticité, par exemple, Amazon ElastiCache, Google App Engine
Memcache, Gear6, Memcachedb et Couchbase. Il est possible par exemple d'accéder à JBoss
Infinispan en utilisant le protocole Memcached.

23
Memcached 33 , qui fête cette année ses 10 ans, reste la solution de cache la plus utilisée 34
par les projets Java, notamment avec le très populaire client Spymemcached 35 .

En conclusion, nous rappelons que la technique du Consistent haching a été adoptée dans
une grande variété de systèmes de stockage [7,4], pour lesquels elle est particulièrement
appropriée.

Conclusion
Consistent hashing, ou hachage cohérent en français, est un thème représentatif en sciences
informatiques au moins pour les aspects suivants. Tout d'abord, le sujet se fonde sur le
hachage, une vielle technique algorithmique, et l’adapte pour diverses applications réelles et
actuelles. En suite, le sujet est « moderne », dans le sens où il aborde des problématiques
des systèmes informatiques actuels, et qui n’existaient pas dans les applications d’antan.

Le "consistent hashing" fut inventé, en 1997, et développé par David Karger, Daniel Lewin et
al., du MIT à Boston, pour servir la mise en cache au niveau du Web (ie. Web Caching).
L'avantage le plus évident est que l'internaute jouit d’un temps de réponse beaucoup plus
rapide, et les performances du Web s'en trouvent également améliorées.

L'idée a des applications réelles. Le Hachage cohérent a donné naissance à la société

Akamai, qui est à ce jour est un acteur majeur d'Internet, avec une capitalisation boursière
de 12 B$, qui gère la présence sur le Web pour le compte de plusieurs grandes compagnies.

L'idée originale a été reconvertie et adaptée depuis pour diverses utilisations en NTIC.

Plus récemment, Consistent hashing a été réorienté pour résoudre des problèmes de base
dans les réseaux peer-to-peer, y compris des parties de BitTorrent. En effet, il est largement
utilisé dans les tables de hachage distribuées (DHT pour l'anglais Distributed Hash Table),
notamment dans les célèbres réseaux peer-to-peer (P2P 36 ). La particularité des DHTs
utilisées dans les architectures P2P est la fonction de hachage, qui est dite consistante
(consistent hashing). Elle garantit avec une probabilité élevée une distribution uniforme des
ressources sur l’ensemble des nœuds et un déplacement de O(1/N) objets lors de l’arrivée
ou du départ d’un Nième pair du réseau 37 . Les systèmes P2P à base de DHTs représentent

33
Memcached, une belle histoire de caching joliment racontée par un administrateur système, et qui
fut par suite illustrée par the online comic TOBlender.com

34
si l'on regarde les tendances des demandes d'emploi calculées par Indeed.com
35
Discution avec Dustin Sallings, le développeur de Spymemcached, le client Java pour Memcached le plus
utilisé, qui donne son point de vue sur le succès croissant de Memcached. [en ligne] :
http://www.infoq.com/fr/news/2013/06/java-memcached-rise
36
L'acronyme P2P est une contraction de Peer to Peer, en anglais, ou, Pair à Pair, en français. Le
terme P2P sera utilisé par la suite.
37
La variation de la structure du réseau pair-à-pair, due à l’arrivée et au départ non anticipé de pairs,
est appelée churn.

24
alors de faibles coûts d’utilisation et de maintenance, et disposent (comme Chord, Pastry ou
Tapestry) d'une couche de routage très performante. De plus, ces systèmes fournissent un
moyen passant à l’échelle et tolérant aux fautes pour stocker des blocs de données de
manière totalement distribuée, efficace et simple à utiliser.

Le Consistent haching est aussi largement utilisé dans divers systèmes de stockage tel que
Memcached , Dynamo d'Amazon et Casandra.

De nos jours, des enfants de tous pays utilisent le hachage cohérent pour le stockage
distribué, rendu populaire par le système Dynamo; l’idée étant de disposer d’une solution
légère (ie. lightweight), alternative à une base de données, où toutes les données résident
dans la mémoire principale à travers de multiples machines, plutôt que sur disque dur. Le
procédés est efficace : le hachage cohérent retrouve la trace des objets demandés, qui sont
ensuite acheminés rapidement à l'utilisateur.

Il faut dire, que dans ce domaine, les algorithmes de distribution les plus utilisés sont ceux
fondés sur la technique du hachage cohérent, qui est mise en œuvre dans plusieurs
systèmes de stockage de données massives, pour lesquels elle est particulièrement
appropriée.

Cette idée est maintenant largement copiée par les alternatives modernes, ie. lightweight, de
gestion des accès mémoire au niveau des bases de données, qui traditionnellement stockent
sur disque. De telles alternatives ne supportent généralement que peu d'opérations (par
exemple, pas de clés secondaires), et se détendent les traditionnelles exigences de
consistance, et de cohérence, en échange de la vitesse. Comme vous pouvez l'imaginer, cela
est une grande victoire pour beaucoup d'entreprises de l'Internet moderne.

Avant de conclure, notons que "le hachage cohérent recouvre une idée non évidente, même
à l'informaticien bien formé. Mais une fois assimilé, le hachage cohérent est général et
suffisamment flexible pour se révéler potentiellement utile à la résolution d'autres
problèmes". De plus, "conceptuellement simple et réaliste, l’idée pourrait vous servir si vous
êtes un fondateur de start-up, ingénieur logiciel senior, ou étudiant doctorant. Il y’a de fortes
chances que l'idée pourrait vous être utiles à l'avenir" 38 . en citant le professeur Tim
Roughgarden, de l'Université de Stanford en Californie, .lors de son introduction au cours
The Modern Algorithmic Toolbox.

38
In [8] Standford document
25
Bibliographie :
[1] : David Karger, Alex Sherman, Andy Berkheimer, Bill Bogstad, Rizwan Dhanidina, Ken
Iwamoto, Brian Kim, Luke Matkins, Yoav Yerushalmi. "Web Caching with Consistent
Hashing." Proceedings of the 8th International WWW Conference, May 1999.
[on line] Consulté le 03/07/2015 : http://www8.org/w8-papers/2a-
webserver/caching/paper2.html

[2] : Daniel Lewin. “Consistent hashing and random trees: algorithms for caching in
distributed networks.”. Massachusetts Institute of Technology MIT Master Thesis, May
1998.
[on line] Consulté le 03/07/2015 : http://dspace.mit.edu/handle/1721.1/9947

[3] : D. Karger, Eric Lehman, Tom Leighton, Matthew Levine, Daniel Lewin, Rina
Panigrahy, "Consistent Hashing and Random Trees : Distributed Caching Protocols for
Relieving Hot Spots on the World Wide Web." - In Proceedings of the 29th Annual ACM
Symposium on Theory of Computing (STOC’97), pages 654-663, New York, USA, May
1997.
[on line] Consulté le 03/07/2015 : http://people.csail.mit.edu/karger/Papers/web.ps

[4] : Avinash Lakshman and Prashant Malik. "Cassandra : structured storage system on a p2p
network". In Proceedings of the 28th ACM symposium on Principles of distributed
computing, PODC ’09, pages 5–5, New York, NY, USA, 2009. ACM. 69, 103, 102

[5] : Zhen Ye and Shanping Li. A request skew aware heterogeneous distributed storage
system based on cassandra. In Computer and Management (CAMAN), 2011
International Conference on, pages 1–5, 2011. 69

[6] : David R. Karger and Matthias Ruhl. Simple efficient load balancing algorithms for peer-
to-peer systems. Proceedings of the sixteenth annual ACM symposium on Parallelism in
algorithms and architectures – SPAA ’04, page 36, 2004. 6, 61, 74, 103, 102
[on line] Consulté le 03/07/2015 :
http://people.csail.mit.edu/karger/Papers/loadbalancing-spaa.pdf

[7] : Brad Fitzpatrick. Distributed caching with memcached. Linux J., 2004(124) :5–, August
2004. 103, 102

[8] : Stanford University. Cours CS168: The Modern Algorithmic Toolbox. Chapitre
Consistent Hashing. Tim Roughgarden & Gregory Valiant. March 30, 2015. 11 pages.
[internet] : http://web.stanford.edu/class/cs168/l/l1.pdf

[9] : G. DeCandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman, A. Pilchin, S.

Sivasubramanian, P. Vosshall, and W. Vogels. "Dynamo: Amazon's highly available
key-value store". SIGOPS Operating Systems Review, 41(6):205-220, 2007.

[10] : Dynamo est le nom donné au Système de stockage, ou magasin de données distribuées
clé-valeur, d'Amazon. Dynamo offre une haute disponibilité d'accès au data notamment
à l'aide des tables de hachage distribuées (DHT), et au consistent hashing. Consulté le
29/06/2015. www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
[11] : J. Lamping and E. Veach. A fast, minimal memory, consistent hash algorithm.
arXiv:1406.2294, 2014.

[12] : I. Stoica, R. Morris, D. Liben-Nowell, D. R. Karger, M. F. Kaashoek, F. Dabek, and H.

Balakrishnan. Chord: A scalable peer-to-peer lookup protocol for internet applications.
IEEE/ACM Transactions on Networking, 11(1):17-32, 11 February 2003.
[on line] Consulté le 06/07/2015 :
http://pdos.csail.mit.edu/papers/ton:chord/paper-ton.pdf

[13] : D. G. Thaler and C. V. Ravishankar. Using name-based mappings to increase hit rates.
IEEE/ACM Transactions on Networking, 6(1):1-14, 1998.

[14] : MemCached is a free and open source, distributed memory object caching system,
intended for use in speeding up dynamic web applications by alleviating database load.
was originally developed by Brad Fitzpatrick for LiveJournal in 2003.
http://memcached.org/ Consulté le 29/06/2015.

[15] : Open Stack Cloud Software Fundation. Partitioned Consistent Hash Ring. (Consulté le
29/06/2015). Disponible à : http://docs.openstack.org/developer/swift/ring.html

[16] : Avinash Lakshman, Prashant Malik. "Cassandra: a decentralized structured storage

system". ACM SIGOPS Operating Systems Review. 2010

[17] : Project Voldemort - A distributed database. "Consistent hashing is a technique that

avoids these problems, and we use it to compute the location of each key on the
cluster.".
Consulté le 29/06/2015. http://www.project-voldemort.com/voldemort/design.html

[18] : Akka Routing strategies for messages. "Uses of consistent hashing to select a routee
based on the sent message". Consulté le 29/06/2015.
http://doc.akka.io/docs/akka/snapshot/scala/routing.html

[19] : GlusterFS is a scalable network filesystem. A free and open source software, how
provide create large, distributed storage solutions. Consulté le 28/06/2015.
http://www.gluster.org/community/documentation/index.php/Features/composite-
operations
http://www.gluster.org/2012/03/glusterfsalgorithmsdistribution/ : page orpheline le
28/06/2015.

[20] : "Skylable architecture". Consulté le 28/06/2015.

http://wiki.skylable.com/wiki/Sxarchitecture#Data_distribution

[21] : "Riak Concepts". Riak is a distributed, scalable, open source key/value store. Each node
in Riak is fully capable of serving any client request. This is possible due to the way
Riak uses consistent hashing to distribute data around the cluster.
Consulté le 29/06/2015. http://docs.basho.com/riak/latest/theory/concepts/
[22] : Référence pour la duplication et la cohérence :
A. S. Tanenbaum & M. van Steen, Distributed Systems - Principles and Paradigms,
Prentice Hall, 2002, chapitre 6.

[23] : M. Landers, H. Zhang, and K.-L. Tan, “Peerstore : Better performance by relaxing in
peer-to-peer backup,” in P2P ’04 : Proceedings of the 4th International Conference on
Peer-to-Peer Computing. Washington, DC, USA : IEEE Computer Society, August
2004, pp. 72–79.

[24] : J.-M. Busca, F. Picconi, and P. Sens, “Pastis : A highly-scalable multi-user peer-to-peer
file system,” in Euro-Par ’05 : Proceedings of European Conference on Parallel
Computing, August 2005, pp. 1173–1182.

[25] : F. Dabek, F. M. Kaashoek, D. Karger, R. Morris, and I. Stoica, “Wide-area cooperative

storage with CFS,” in SOSP ’01 : Proceedings of the 8th ACM symposium on Operating
Systems Principles, vol. 35, no. 5. New York, NY, USA : ACM Press, December 2001,
pp. 202–215.

[26] : J. Jernberg, V. Vlassov, A. Ghodsi, and S. Haridi, “Doh : A content delivery peer-to-
peer network,” in Euro-Par ’06 : Proceedings of European Conference on Parallel
Computing, Dresden, Germany, September 2006, p. 13.

[27] : Risson J., Moors, T. (2006) Survey of research towards robust peer-to-peer networks:
Search methods. Computer Networks, 50(17):3485–3521
 Liste des figures
Figure Titre Page
Figure 1 Architecture du cache monolithique 2

Figure 2 Architecture du cache distribuée 3

Figure 3 Architecture du cache hybride 5

Figure 4 Une fonction de hachage 6

Figure 5 Exemple de fonction de hachage 8

Figure 6 Organisation de la table de hachage cohérent 9

Figure 7 La table de hachage cohérent en cercle 9

Figure 8 Exemple d’arbre bicolore ou arbre rouge-noir 11

Figure 9 Répartition de charge par "copies virtuelles" 12

Figure 10 Distribution de charge aux serveurs par la fonction de hachage 13

Figure 11 Résolution de requête dans l'implémentation Akamai 15

Figure 12 Utilisation du " dig " dans l'implémentation Akamai 16

Figure 13 Utilisation du " Tracroute " dans l'implémentation Akamai 16

Figure 14 Modèle de réseau P2P 19

Figure 15 Classification des systèmes P2P, avec quelques exemples. 20

Figure 16 DHT et mécanisme de routage overlay 21

 ANNEXE 1 :
Eléments de base du hachage

Une table de symboles permet de stocker des paires "clé-valeur".

On distingue deux types de tables de symboles : les tables associatives (maps en
anglais) et les dictionnaires.
Les clés des maps sont uniques, tandis que celles d'un dictionnaire ne le sont pas
nécessairement.

1 Table de hachage = un tableau où on stocke les paires "clé-valeur"

L’indice dans la table de hachage est donné par la formule : H(clé) mod n

Figure : une table de hachage (ou bucket array).

Les paires "clé-valeur" sont éparpillées dans le tableau le plus uniformément possible.
Vocabulaire : Une case, vide ou occupée, du tableau porte le nom de Bucket.

Les indices de chaque paire, dans le tableau, sont déterminés par le hach code de
la clé. Lorsque deux clés différentes sont envoyées sur la même case du tableau, on
dit qu'il y a collision.

Une fonction f d’un ensemble E vers un ensemble F est dite injective si :

x, yE², x yf xf y
Ceci garantit donc que : x, yE², f xf yx y

Une fonction de hachage est une fonction injective d’un ensemble de clés vers un
ensemble de valeurs, qui à une chaîne d’octets de longueur quelconque associe une
valeur unique (de taille fixe).

Une table de hachage 1 représente un tableau de correspondance entre des clés et

des valeurs liées par une fonction de hachage, h.

Note de renvoi pour « Les fonctions de hachage » : Par ailleurs ces primitives
sont aussi omniprésentes en cryptographie, et leurs applications sont innombrables :
signature (“Hash-and-sign”), vérification de mots de passe, vérification de l’intégrité
d’un fichier ou d’un message (MAC), construction de schémas de chiffrement
asymétriques INDCCA, etc.
est très utilisé en cryptographie

Une fonction de hachage H a plusieurs propriétés (supposées), que sont :

1) résistance aux collisions :

Il est difficile de trouver deux messages M et M’ qui produisent le même
haché, i.e. tels que H(M) = H(M’).

2) résistante aux pré-images :

Étant donné un haché y, il est difficile de trouver un message M produisant ce
même haché : H(M) = y.

3) résistance aux secondes pré-images :

Étant donné un message M, il est difficile de trouver un autre message M’ qui
collisionne avec M , càd : H(M) = H(M’).

Il semble y avoir un consensus pour dire qu’une fonction de hachage H est sûre si
elle vérifie à la fois ces 3 propriétés.

1
Pour se familiariser avec le concept de hachage (table des symboles, principe des tables de
hachage, gestion des collisions, fonctions de hachages, implémentation et performances),
voir pour une première lecture un bon tutorial sur le sujet à l’adresse :
https://openclassrooms.com/courses/les-tables-de-hachage-1
Plusieurs manières existent pour gérer les collisions : le sondage linéaire (probing en
anglais); le double hachage; le chaînage linéaire, etc.
Une fonction de hachage est bonne si, pour n'importe quel élément, les hach codes
générés sont les plus différents possibles (idéalement, ils devraient être tous
différents), afin bien sûr d'éviter les collisions.
En prenant d'abord un modulo P, ie. P nombre premier > N, on évite les collisions.
Puis, refaire ensuite un modulo avec la taille du tableau N, histoire de ne pas en
sortir :
(H(clé) mod P ) mod N

Une table de hachage sera d'autant plus efficace si les fonctions de hachage et de
compression (ie modulo) répartissent les indices le plus uniformément possible.
Les performances de la table de hachage dépendent du nombre de clés insérées.
Le facteur de charge λ est le rapport entre le nombre d'éléments insérés dans la
table de hachage et le nombre de cases de la table :

λ est donc un indicateur du taux de remplissage de votre table de hachage. Par

soucis de performances, on définit un facteur de charge maximum, et s'il est dépassé
on agrandira la table.

Une autre implémentation, très répandue, des tables de symboles se fait avec des
arbres. Pour N éléments ajoutés, la hauteur d'un arbre peut être réduite à :
 ANNEXE 2 :

Une présentation des réseaux pair-à-pair (P2P)

Les définitions du P2P sont nombreuses et différentes. La plus générique est la

suivante :

"Le P2P fait référence à une classe de systèmes et d’applications qui utilisent des
ressources distribuées (d’un réseau) pour réaliser une fonction critique de manière
décentralisée" 2 .

Il est à noter que le terme fonction fait allusion à un service, un mécanisme (par
exemple, de routage,…), etc.

Figure 1 : Modèle de réseau P2P.

Un réseau P2P est un réseau logique distribué dont le principe de base est un
principe d’égalité entre des nœuds dynamiques, appelés pairs.

2
"P2P refers to a class of systems and applications that employ distributed resources to
perform critical function in a decentralized manner.". In : Milojičić D. S., Kalogeraki V.,
Lukose R., Nagaraja K., Pruyne J., Richard B., Rollins S., Xu Z. (2002) Peer-to-Peer
Computing. HPL- 2002-57. Hewlett-Packard Laboratories, 52 p.
 Consistent Hashing ou le Hachage Cohérent

Mémoire présenté en vue d'obtenir

UE « Information et communication pour ingénieur »
Spécialité : INFORMATIQUE
Casablanca, 2015

_________________________________________________________________

RESUME

Les progiciels intégrés de gestion (PGI), ou ERP (Enterprise Resource Planning) en anglais,
constituent aujourd'hui une des solutions logicielles les plus en vue pour rendre le système
d’informations (SI) de l'organisation plus performent.

Dans le but de disposer de plus d’assurance quant à la réussite du projet de faire migrer le SI
vers une solution de type ERP, en terme de sécurité de l’investissement et de maîtrise des
risques du projet, nous apportons les éclairages nécessaires, notamment : les avantages, les
inconvénients et limites, les difficultés et contraintes, les risques inhérents, les facteurs
potentiels d’échec, et les conditions de succès du projet. L’objectif étant de présenter les
éléments nécessaires pour juger objectivement, et en connaissance de causes, de l’opportunité
de s’engager dans un projet de migration ERP.

Mots clés : PGI, ERP, projet migration, syndrome « plat de spaghettis », intégration,
risques projet.
_________________________________________________________________

SUMMARY

Enterprise Resource Planning (ERP); or ‘Les progiciels intégrés de gestion (PGI)’ in French,
constitute today one of the most highly valued software solutions for a more efficient
information system (IS) of any company.

With a view to securing more assurance regarding the success of the project to migrate IS
towards an ERP type of solution, in terms of investment safety, as well as project risk control,
we provide the necessary insights, notably in connection with the advantages, the drawbacks
and limits, the difficulties and constraints, the inherent risks, the potential factors of risk, as
well as the conditions for the success of the project, the ultimate objective being to lay out the
necessary elements for an objective, and well-informed, appraisal of the opportunity to
engage in a project of ERP migration.

Key words: ERP, project migration, “spaghettis dish” syndrome, integration, project
risks.