Invocation dÕune entitŽ sur un autre cluster

Nous avons vu que la communication entre clusters se faisait par lÕintermŽdiaire des diffŽrents processeurs de contr™le du cluster de contr™le.

LorsquÕune entitŽ dŽsire •tre accŽdŽe par des entitŽs extŽrieures ˆ sa Pt‰che, elle doit •tre associŽe ˆ un port public qui doit •tre dŽclarŽ comme rendant un service donnŽ (gr‰ce ˆ lÕappel syst•me port_publish(…)). LorsquÕune autre entitŽ sur un proces-seur distant dŽsire accŽder ˆ ce service, elle exŽcute un port_lookup(…) qui a pour consŽquence de premi•rement retourner une capacitŽ associŽe ˆ se service, et deuxi•-mement de crŽer un ECB_r avec dans le champ eLocalisation, le numŽro de proces-seur distant et le numŽro de port sur ce procesproces-seur.

Mais ce processeur nÕappartenant pas au cluster de la Pt‰che, son numŽro nÕappara”t pas dans les tables de routage de la Pt‰che. Conclusion, lorsque un serveur dÕentitŽs local rŽcup•re la localisation de lÕentitŽ distante, il ne peut lui envoyer directement le mes-sage, puisquÕil ne conna”t pas le chemin pour y aller. Dans ce cas, il envoie systŽmati-quement le message vers le processeur de contr™le de la Pt‰che (en passant par le pont de communication), en espŽrant que celui-ci saura correctement router le message.

Chapitre 5 : Gestion des entitŽs dans ParObj

Communication avec le cluster syst•me

Les communications avec le cluster syst•me pouvant •tre relativement frŽquentes, il ne faut pas que les messages passent leur temps ˆ rebondir de serveurs dÕentitŽs ˆ serveurs dÕentitŽs, ˆ la recherche du destinataire final. Or, lorsquÕun message est destinŽ au sys-t•me, son chemin passe invariablement par les processeurs de contr™le de chaque Pt‰che, puis par le ou les ponts entre le cluster de contr™le et le cluster syst•me. Conclu-sion, ce mŽcanisme dÕacheminement peut •tre directement pris en compte au niveau du protocole de routage.

Pour cela, ˆ tout processeur du cluster syst•me est assignŽ un numŽro particulier qui permet au mŽcanisme de routage de le reconna”tre aisŽment (par exemple en mettant ˆ un le bit de poids fort du numŽro de processeur). Ainsi, lorsque un tel numŽro est ren-contrŽ, le message correspondant est automatiquement routŽ de pont de communication en pont de communication, sans passer par les serveurs dÕentitŽs. Lorsque le message arrive enfin dans le cluster syst•me, il est dŽlivrŽ directement au bon endroit puisque le numŽro de processeur destination est connu des tables de routage.

Note : ce procŽdŽ (le codage particulier du numŽro de processeur) peut •tre appliquŽ ˆ

tous les clusters fournissant un service syst•me. Par exemple, un cluster mŽmoire devra pouvoir lui aussi •tre accŽdŽ le plus rapidement possible.

Communication avec un cluster utilisateur

Apr•s lÕexŽcution de la procŽdure port_lookup(…) qui gŽn•re un message ˆ desti-nation de la Pt‰che de contr™le du syst•me (sur le cluster syst•me)15, le serveur dÕentitŽs local dispose dÕun ECB_r qui contient lÕEID et la localisation de lÕentitŽ qui se trouve sur un autre cluster.

Lorsque lÕentitŽ locale E_l veut communiquer avec une entitŽ distante E_d, un message est envoyŽ au serveur dÕentitŽs local qui, ne sachant o• envoyer le message, le route vers le serveur dÕentitŽs du processeur de contr™le de la Pt‰che (que nous appelons SEPctrl). Si cÕest la premi•re fois quÕune requ•te est Žmise vers E_d, le serveur de contr™le ne sait pas plus o• envoyer le message. Il va alors de nouveau sÕadresser au cluster syst•me et lui demander Òvers quel processeur de mon cluster dois-je envoyer le

message si je veux communiquer avec E_d ?Ó. Le syst•me gr‰ce ˆ E_d retrouve la Pt‰che associŽe, et donc le processeur de contr™le correspondant. Il peut donc renvoyer lÕin-formation demandŽe. LorsquÕil re•oit une rŽponse, le SEPctrl crŽe un ECB_r qui va associer lÕEID de E_d avec le numŽro de processeur du processeur de contr™le de la Pt‰che distante. Les messages suivants pourront alors •tre systŽmatiquement routŽs vers ce processeur. Lorsque le message arrive sur le processeur de contr™le de la Pt‰che dis-tante, la t‰che de contr™le qui connait la localisation de Ed, peut alors envoyer la req•te sur le bon processeur, Cf. Figure 5.12.

Chapitre 5 : Gestion des entitŽs dans ParObj

: communication entre cluster : trajet dŽsirŽ : communication entre cluster : trajet rŽel : comm. avec le serveur de contr™le syst•me

Cluster utilisateur Cluster syst•me Cluster de contr™le E_l E_d SEPctrl Processeur de contr™le

Figure 5.12. Communication entre deux Pt‰ches

Communication par un chemin direct

Afin dÕaccŽlŽrer la communication entre clusters, et si le matŽriel de la machine le per-met, il devra •tre possible de rŽclamer (par exemple au moment du chargement) un ou plusieurs chemins directs vers un cluster donnŽ. Ces chemins permettront dÕŽviter le passage par le cluster de contr™le, en autorisant une communication entre deux proces-seurs de deux clusters diffŽrents.

La figure 5.13 rŽsume les diffŽrents chemins que prennent les messages lors de la com-munication entre clusters diffŽrents.

Chapitre 5 : Gestion des entitŽs dans ParObj

: communication entre cluster : trajet dŽsirŽ : communication entre cluster : trajet rŽel : communication entre un cluster et le syst•me

Cluster utilisateur Cluster syst•me Cluster de contr™le chemin direct

(les messages ne passent pas par les serveurs de contr™le)

Processeur de contr™le