1.3 Group Membership per WAN
1.3.2 Un’implementazione di MNS: Xpand
Gli autori [31] presentano un algoritmo di membership implementato in Xpand, pro-gettato per essere flessibile e garantire soprattutto una buona efficienza a quelle ap-plicazioni che non richiedono una forte semantica. Per lo stesso motivo vengono usati in esso due differenti flussi per i messaggi di controllo e per quelli applicativi, di cui i primi fanno ricorso ad un servizio di trasporto affidabile.
L’algoritmo di membership implementato in Xpand `e ottimizzato per fornire le seguenti propriet`a:
1.3. GROUP MEMBERSHIP PER WAN 23
Smooth-Join : Un nuovo membro deve poter entrare nel gruppo senza modificare il flusso dei messaggi del gruppo;
Fast-Join : una volta che un processo entrante si `e registrato nella sua LAN deve poter iniziare ad inviare messaggi;
Dynamic Membership : deve poter permettere ai processi di entrare o uscire dal gruppo in un ambiente di tipo WAN.
Il servizio di membership permette di fornire queste propriet`a senza compromettere le due propriet`a base di consegna di Xpand, cio`e:
FIFO order : ogni ricevente, che inizia a ricevere messaggi da una data sorgente, ricever`a tutti i messaggi emessi in ordine FIFO dal momento in cui ha eseguito il join al flusso;
Gap-Free : due processi che rimangono connessi durante cambiamenti consecutivi della membership continueranno a ricevere ogni altro messaggio senza interruzioni nello stream dei messaggi.
Problematiche d’implementazione
Allo scopo di riuscire a mantenere un elevato numero di client, Xpand `e stato implemen-tato utilizzando un’architettura gerarchica a due livelli: ogni LAN `e rappresentata da un delegato che coordina le attivit`a del protocollo riguardo alla sua LAN di competen-za con il gruppo distribuito su base WAN. Per incrementare la scalabilit`a un delegato potrebbe essere visto come una collezione di sender, o di receiver, della sua LAN e il sender potrebbe non essere un membro esplicito del gruppo. L’informazione relativa al sender, in una LAN, potrebbe essere mantenuta dal solo delegato che riceverebbe le informazioni inviate dal sender per poi distribuirle all’interno del gruppo.
Abbiamo, quindi, che i processi partecipanti ad un sistema Xpand sono raggruppati in cluster, in modo tale che i membri dello stesso cluster si trovino sulla stessa LANi cluster sono distribuiti su di una WAN e possiamo distinguere in essi due tipi di processi:
regolari e delegati. I processi regolari eseguono l’user application mentre i delegati
sono demoni designati a servire come rappresentanti della LAN per gli altri cluster. I delegati, quindi, non solo rilevano i cambiamenti all’interno della propria LAN ma son incaricati di comunicare questi cambiamenti agli altri delegati loro pari in modo da
diffondere l’informazione sui nodi che hanno mutato il loro stato all’interno del sistema. Devono inoltre gestire situazioni di partizionamento, di disconnessione o di aggiunta di nuove reti, attraverso il management con i nuovi delegati che si aggiungono ad un gruppo.
Un delegato di una LAN `e replicato per scopi legati alla tolleranza ai guasti ma solo un delegato `e attivo in un determinato istante. Tutti gli altri delegati non attivi, chiamati delegati di backup, vengono utilizzati come copie di emergenza del delegato designato.
Network Event Notification Service
L’architettura gerarchica appena descritta si combina con un’implementazione client/server del servizio di Membership Notification in cui i client utilizzano il no-tification service per richiedere l’ingresso o l’uscita dal gruppo, o per aggiornare le informazioni riguardo al gruppo stesso. Esistono cio`e un insieme di server, i delegati appunto, ognuno dei quali `e incaricato dei seguenti compiti:
1. essere il punto di accesso dei nodi in joining;
2. tracciare le partenze dei processi, siano esse a causa di guasti o di leave volontarie; 3. fornire viste della membership a chiunque ne faccia richiesta.
Il servizio fornisce ai client un’interfaccia che consiste fondamentalmente di tre funzioni base:
• NS join(G) `e una richiesta di un client di entrare a far parte del gruppo G; • NS leave(G) `e una richiesta di un client di lasciare il gruppo G;
• NS resolve(G) `e una richiesta di ricevere la lista della membership corrente, cos`ı
come viene vista dal notification service.
Il servizio permette ai processi regolari l’iscrizione a gruppi che non si trovino sulla stessa LAN, e nel caso in cui un processo client voglia iscriversi ad un gruppo di cui il suo delegato non `e ancora membro dovr`a prima aspettare il join al gruppo in questione da parte del processo delegato.
Il notification service contiene un modulo di failure detector che, poich`e staimo assumendo un ambiente di esecuzione asincrono, `e costretto ad essere inaffidabile in
1.3. GROUP MEMBERSHIP PER WAN 25
alcune sue esecuzioni, pu`o cio`e sospettare erroneamente alcuni processi corretti. Dato che uno degli obiettivi `e proprio l’implementazione del servizio in un ambiente asin-crono gli autori non hanno richiesto al NS di essere accurato ma hanno supposto che sia sempre completo, nel senso che se un processo fallisce nel ricevere un messaggio inviatogli allora il processo sar`a eventualmente sospettato. Secondo gli autori il sod-disfacimento delle propriet`a di liveness di Xpand non dipende, inoltre, dalla capacit`a del membership notification service di fornire una vista consistente poich´e Xpand `e in grado di comunicare con ogni insieme connesso di client.
I risultati mostrati in [31] vengono a confemare che Xpand rispetti le propriet`a su enunciate anche se non `e fatto alcun riferimento alla effettiva dinamicit`a, in termini di frequenza di operazioni di join e di leave, su cui sono state effettuate le prove speri-mentali. Vedremo nel Capitolo 4 come tale parametro risulti invece di fondamentale importanza per quello che concerne le sorti di un protocollo di group membership.