Cours: INF4402
Projet: 3
Nom de famille: Pieraut, Prénom: Francis, Matricule: 60104
Nom de famille: AZIZI, Prénom: Oussama, Matricule: 1006964
Le but de ce travail pratique était de nous introduire aux notions de base du développement d'applications réparties répliqués avec accès en lecture et écriture et mise à jour atomique. Pour ce faire nous avons modifié le serveur de nom qui nous avait été donné afin de rendre les mises à jour atomiques. L'atomicité à été possible en appliquant la technique "two-phase commit protocole". Les aspects de pannes et de re synchronisation ont quant à eux seulement été analysé dans les sections appropriées.
Voici une brève explication des modifications faites:
Communication de la mise à jour de façon atomique
Description de la méthode choisie
Pour ce faire, nous nous sommes basés sur le "two-phase commit protocole" tel que décrit dans livre Distributed Systemes[1]. Notre implantation consiste à aviser tous les autres serveurs d'une modification. Cette modification sera enregistrée en mode inactif par tous les serveurs l'ayant reçu. Si tous les serveurs informent avoir bien reçu la modification, alors on les avisera d'activer cette modification. Dans le cas ou un seul serveurs répliqués ne répond pas convenablement à l'une de ces deux requêtes alors un message de retrait de la modification sera envoyé à tous les serveurs répliqués actifs jusqu'à ce qu'on soit assuré qu'ils soient tous au courant.
Description détaillée de d'une transaction entre un client et un serveur.
Nous considérons à cette étape que le serveur à reçu une requête de changement par le client qui a appelé la fonction setAddress(in string name, in string address).
Une fois que le serveur reçoit cette requête, il appelle la fonction broadCastChange(...). Cette fonction effectue les étapes suivantes:
Cette accusé sera à son tour retourné au client afin de l'avertir de l'état de la modification.
(liens vers les fichiers source) NameServer-client.c NameServer-server.c
Qu'arrive-t-il aux clients pour les accès de type get lorsqu'un ou plusieurs serveurs tombent en panne?
Tant que les serveurs restant ne sont pas surchargés, il n'y a aucune modification du côté du client. Dans les cas contraire, le client ne recevra tout simplement pas la réponse à sa commande get et sera contraint de ré-executer celle-ci tant qu'un serveur ne sera pas libre afin de répondre à sa requête. Les serveurs peuvent être conçu d'une manière à détecter une panne dans les autres serveurs (peers), et pourront ainsi procéder à la redirection des requêtes vers un autre serveur. En Pratique, les serveurs vérifient l'état de fonctionnement de chacun d'entre eux par des messages constant qu'ils échangent. Si le serveur ne répond pas, le second serveur prend le contrôle de son adresse ip ce qui permet l'acheminement des requêtes vers lui automatiquement. Bien entendu, toutes ces procédures se font d'une manière atomique. Le client peut se rendre compte d'une telle panne lorsque une exception lui est retournée après un temps d'expiration (timeout). Au niveau client, il est aussi possible de configurer un DNS serveur secondaire qui en cas de panne du DNS serveur primaire prend le relais.
Quel est le nombre minimal de serveurs requis pour fonctionner? (hypothèse : seulement pour la commande get + le nombre minimal est défini par le nombre minimum de serveurs nécessaires pour répondre à toutes les requêtes dans le cas d'un nombre de requête maximum préalablement défini)
Ceci dépend de la charge. Pour répondre à une telle question, il nous faudrait savoir le nombre maximum(MAX_SERVEUR) de requêtes auxquelles un serveur peut répondre, le nombre maximum de requêtes(MAX) pouvant être faites ainsi que le facteur(K) de sécurité voulu. Si nous connaissons les valeurs MAX et MAX_SERVEUR, le nombre minimal de serveurs requis pour fonctionner sera égale à l'arrondi vers le haut de K*(MAX/MAX_SERVEURS).
Le facteur K doit doit tenir compte entre autre de la disponibilité requise (availability) qui peux être calculé comme suit : 1-(p,puissance n) ou p étant la probabilité qu'un serveur tombe en panne, et n étant le nombre de serveur. Deux serveurs dont la probabilité de défaillance est indépendant, peuvent être considérés comme étant un minimun tant et aussi longtemps qu'ils représentent pas un goulot d'étranglement (bottlenneck).
En guise d'exemple, on suppose que la probabilité qu'un serveur tombe en panne est de 5% et un nombre de serveur n = 2,
Availibility = 1 - (0.05)^2 = 99.75 %
Est-il bon que tous les clients accèdent aux serveurs dans le même ordre de préférence?
Non. Dans une telle configuration le serveur i ne sera pas utilisé tant que le serveur précédant ne sera pas surchargé. Ceci n'est pas du tout ce qui est recherché car la charge n'est pas du tout équilibrée et cela reviendrait au fait d'utiliser de nouvelles ressource, ici de nouveaux serveurs, que lorsqu'on n'a pas d'autre choix. Cette configuration entraîne des délais inutiles aux clients lorsque les premiers serveurs sont surchargés car l'on doit de toute façon tenter de s'y connecter avant de passer au suivant. Si nous posons l'hypothèse de le nombre de serveurs est suffisant pour répondre aux requêtes dans le pire des cas, alors dans le cas moyen plusieurs serveurs ne seront jamais sollicités dans une telle configuration. Cette technique est inefficace car elle entraîne des délais inutiles pour les clients sachant que ceux-ci pourrait être inexistant dans un configuration d'ordre de serveur un peu plus aléatoire.
Comment la performance (de la rapidité des réponses aux requêtes) est-elle affectée (par le nombre de panne)? Ce qui se trouve entre parenthèse sont nos hypothèses.
Sachant que l'ordre de préférence est identique pour tous les clients et considérons la réponse précédente, nous devons considérer les deux cas suivant:
Dans le premier cas, le client aura un délais d'attente encore plus long car il tentera de communiquer avec les serveurs en pannes. Dans le deuxième cas, sachant que les serveurs précédent ne sont pas surchargé et qu'ils seront en mesure de répondre aux requêtes, il n'y aura aucun impacte sur la performance au niveau de la rapidité des réponses aux requêtes.
Plus le nombre de serveur augmente avec une probabilité p qu'un serveur i tombe en panne plus la disponibilité du système augmente ce qui permet d'augmenter la performance du système.
Dans l'implantation faite du client, les accès se font de façon itératif. Cette méthode et nécessaire car si une méthode récursives avait été implantée, la panne du serveur auquel on effectuerait une requêtes entraînerait l'impossibilité de recevoir une réponse et donc l'atomicité ne pourrait être respecté.
Dans le cas ou l'accès n'entraîne qu'une exception du coté serveur, l'accès itératif pourrait être intéressant. L'accès récursif est simple est permet aux serveurs intermédiaires de voir les réponses et les conserver en cache ce qui augmentera la disponibilité du système cependant si jamais un serveur bloque dans un tel accès, la performance pour les accès concurrents en souffrira. Dans un accès itératif le client peut être référé à un autre serveur et ne sera jamais bloqué mais les serveurs consultés ne verront jamais les réponses des autres serveurs. Chaque mode d'accès a des avantages comme il y a des inconvénients et pour pouvoir choisir il faut se déterminer des critères de sélection. Si on se base par exemple sur la simplicité et la disponibilité du système le mode récursif sera l'idéal.
Qu'arrive-t-il aux clients pour les accès de type set lorsqu'un ou plusieurs serveurs tombent en panne?
Dans notre implantation, la modification ne sera pas faite. En réalité, cette modification devrait être faite et propagée aux serveurs redondants restants. Lorsque les serveurs en pannes redemarerront, ils devraient vérifier l'existence d'un autre serveur et récupérer les modifications qui leur manque. Lorsque un des serveurs tombe en panne lors une opération set du client, le serveur est éventuellement remplacé et utilisera une procédure de recouvrement pour restaurer les informations manquantes à partir des autres serveurs. Le client quant à lui sera avisé de la panne subite du serveur par une exception qui lui retournée et lancera éventuellement la requête de nouveau qui sera traitée par un autre serveur.
Peut-on fonctionner avec un nombre réduit de serveurs à condition d'avoir quorum d'une majorité de serveurs?
Dans le contexte de serveurs répliqués avec mise à jours atomique, avoir quorum d'une majorité de serveurs implique selon nous d'avoir la certitude qu'en tout temps il y ait un minimum de serveurs fonctionnels afin d'assurer une réponse à toutes les requêtes et donc d'avoir atomicité absolue. Avec cette condition, le service de nom peut fonctionner car il permet de préserver l'atomicité et en plus il permet de ne pas gaspiller des ressources (serveurs inutiles).
Dans ce cas l'atomicité peut-elle toujours être garantie?
Oui car ceci permet d'assurer l'atomicité car il n'arrivera jamais que pour 2 requêtes semblables, l'une réponse soit la bonne et que l'autre soit nulle car aucun serveur n'a pu y répondre.
Lorsqu'un serveur qui était tombé en panne revient, comment peut-on le re synchroniser tout en préservant l'atomicité?
Lorsque serveur redémarre suite à une panne, il ne devrait pas pouvoir répondre à des requêtes tant qu'il n'aura pas récupérer les modifications qui lui manque, ceci bien entendu afin de conserver l'atomicité. Donc la re synchronisation du serveur redémarré sera faite par l'appel d'une procédure de recouvrement qui lui permettra sa mise à jour par rapport aux autres serveurs. Une fois cette mise à jour complétée, le serveur sera de nouveau prêt à répondre à des requêtes.
Le but de ce travail pratique était de nous introduire aux notions de base du développement d'applications réparties répliqués avec accès en lecture et écriture et mise à jour atomique. Pour ce faire nous avons modifié le serveur qui nous a été donné de tel sorte à ce qu'il propage l'information aux serveurs répliqués. Nous avons du tenir compte de la restriction d'atomicité de la mise à jour. Pour ce faire nous avons implanté une solution du type "two-phase commit protocole" tel que décrite dans livre Distributed Systemes[1].
En ce qui concerne les cas de pannes, nous avons fait une analyse sur la répercutions de celles-ci sur les clients. Dans le cas ou ces pannes entraîne la surcharge des serveurs répliqués fonctionnels, la conséquence sera que certaines requêtes ne seront tout simplement pas traitées. Nous avons aussi discuté du nombre minimal de serveurs répliqués en faisant ressortir les données nécessaires à son calcul. Nous avons aussi traité des contraintes lorsqu'un serveur redémarre à dans le but de le re synchronisation pour conserver l'atomicité.
Améliorations à apporter à notre serveur
Tolérance aux pannes
Dans ce travail pratique, nous n'avons implanté que de la mise à jour atomique. Donc une amélioration serait d'intégrer des fonctionnalités permettant une tolérance absolue aux pannes. Pour ce faire il nous faudrait avoir des métriques sur l'utilisation des serveurs ou tout simplement implanter un mécanisme adaptatif et dynamique de création de nouveaux serveurs s'ajustant à la charge ainsi qu'un mécanisme de re synchronisation lors du redémarrage des serveurs tombés en panne. Donc pour ajouter la tolérance aux pannes, il nous faudrait ajouter un mécanisme de re synchronisation et un permettant d'avoir quorum d'une majorité de serveurs.
Choix du serveur par le client
Tel que nous l'avons expliqué dans la section "Effet des pannes de serveurs (sur les accès en lecture)", le mécanisme de choix implanté du serveur n'est pas du tout optimal. Donc une autre amélioration possible serait d'implanté un système de choix random ou semi intelligent afin de maximiser la distributions des requêtes et de minimiser le délais d'attente des clients.
Ce travail pratique nous a permis de bien comprendre les notions de mise à jour atomique et les problèmes de pannes de serveurs répliqués.
[1]Distributed Systemes, concept and design chapitre 13(atomic commit protocole), section 13.3.1