Principe de la méthode MSP

Nous avons baptisé cette méthode la procédure de recherche multicast, ou bien en anglais Multicast Search Procedure (MSP) [OTJM09]. Cette procédure est initiée en amont de l'algorithme GCA, au moment même où un n÷ud souhaite acquérir un verrou. En eet, lorsqu'un n÷ud désire entrer en section critique et qu'il ne dispose pas d'un verrou compat- ible dans son cache, l'algorithme GCA lui dicte d'envoyer une requête à son n÷ud parent dans l'arbre. Or, si son père est situé sur un site distant de plusieurs millisecondes de latence réseau, cela va rajouter un délai supplémentaire non négligeable, et ainsi allonger le temps d'accès à la section critique. De plus, rien ne lui garantit que son père pourra lui attribuer le verrou dont il a besoin. Il n'a en réalité aucun moyen pour évaluer le temps qu'il va mettre à acquérir le verrou.

Avant de présenter notre solution, nous devons d'abord dénir la notion de voisin dans les grilles. En eet, nous utiliserons dorénavant ce terme, pour désigner des n÷uds proches en terme de latence réseau.

5.1. La procédure de recherche multicast (MSP) 85 Dénition 4. N÷uds voisins

Deux n÷uds sont considérés comme des voisins, lorsque les propriétés suivantes sont vériées :

(i) La latence réseau qui sépare les deux n÷uds est faible.

(ii) Le réseau interconnectant les deux n÷uds permet la diusion de messages multicast.

Dans un environnement tel qu'une grille au sens grappe de grappes, pour que ces pro- priétés soient vériées, les deux n÷uds doivent impérativement se trouver dans le même site administratif. Par nature, les requêtes multicast ne peuvent pas traverser les hôtes frontaux. De plus, du fait de la distance qui sépare les sites, la latence ne peut pas être considérée comme faible. Il est en réalité très dicile de savoir à quel moment la latence est faible. Cette notion est très subjective car elle dépend directement de l'architecture du réseau. En eet, celle-ci peut être relativement complexe, même au sein d'un site ad- ministratif. Pour simplier notre étude, nous considérons que seule la latence intra-site est faible (i.e quelques centaines de microsecondes). Cette hypothèse nous semble assez réa- liste, en eet, elle est en adéquation avec les caractéristiques de la plate-forme Grid'5000 [GHVBPS06]. De plus, nous supposons que l'architecture du réseau intra-site est susam- ment simple pour autoriser la diusion de messages multicast à tous les n÷uds.

Dans ce contexte, nous appliquons la solution suivante : Dénition 5. Procédure MSP

Lorsqu'un n÷ud souhaite accéder à la section critique, et que son père n'est pas un voisin, alors il peut initier une procédure MSP en amont de l'algorithme GCA, dans le but unique d'acquérir rapidement de l'information auprès de ses voisins. Si cette recherche aboutit à un résultat, les informations obtenues devront permettre à la requête d'emprunter un chemin plus court que celui proposé par l'algorithme GCA, pour que le n÷ud puisse accéder plus rapidement à la section critique.

Pour mettre en ÷uvre la procédure MSP, nous utilisons les communications multicast. Dans le composant VCOM, les communications multicast sont basées sur l'utilisation du protocole non able UDP. Il est donc évidemment hors de question d'attribuer un ver- rou grâce à un simple message multicast. Sans quoi, cela pourrait entraîner de sérieux interblocages, si un message venait à se perdre. Au contraire, les messages multicast que nous utilisons contiennent uniquement de l'information. De plus, le comportement des n÷uds voisins est diérent en fonction du type de verrou demandé.

Verrou de type READ

Pour un verrou partagé R, l'idée est de pouvoir obtenir l'accès à la section critique grâce à un n÷ud voisin qui dispose d'un verrou compatible dans son cache. Ainsi, tous les voisins qui possèdent un verrou de type R vont répondre à la requête multicast. Sur l'exemple illustré par la gure 5.1, le n÷ud C initie une procédure MSP car son père, le n÷ud B, est situé sur un site diérent du sien. Parmi les voisins de C, seul D dispose d'un verrou compatible dans son cache. Il sera donc le seul à répondre à la requête multicast. Lorsque plusieurs n÷uds répondent, nous prenons la première réponse qui arrive au niveau du n÷ud C. En eet, nous supposons que les n÷uds moins chargés répondront plus rapi- dement que les autres.

Le n÷ud C dispose désormais de deux chemins : le chemin original dicté par l'algorithme GCA, ainsi que le chemin alternatif obtenu grâce à la procédure MSP. A partir de là, C va tenter d'obtenir l'accès à sa section critique en empruntant le chemin alternatif. Si pour une raison quelconque, en utilisant cette voie, la requête ne peut pas être satisfaite (e.g à cause d'une panne d'un n÷ud), alors la procédure MSP n'aura servi à rien, mais le n÷ud pourra toujours tenter d'accéder à sa section critique en empruntant le chemin original. Dans l'exemple de la gure 5.1, C a obtenu le verrou grâce à un voisin, ce qui a réduit considérablement le temps d'accès à la section critique. Sans la procédure MSP, il aurait obtenu le verrou grâce au n÷ud B, situé sur un site distant de plusieurs millisecondes de latence.

5.1. La procédure de recherche multicast (MSP) 87

Verrou de type WRITE ou OPEN

Un verrou exclusif de type W ou O requiert l'acquisition du jeton. La procédure MSP va alors nous aider à déterminer si le jeton est situé au sein du même site. Pour cela, lorsque la diusion multicast est réalisée auprès des n÷uds voisins du site, si la racine se trouve parmi eux, alors celle-ci répondra favorablement à la requête. Au contraire, si le jeton est situé sur un autre site, alors la recherche échouera.

La gure 5.2 illustre un exemple de la procédure MSP pour des verrous exclusifs. Nous y voyons que C obtient le jeton directement auprès du n÷ud A. De plus, lors de l'invalidation de leur cache, les n÷uds B et D ont mis à jour leur n÷ud père, en pointant sur le nouveau possesseur du jeton : le n÷ud C.

Fig. 5.2  Exemple de MSP pour un verrou de type WRITE ou OPEN