Capitolo 2 - Affidabilità del servizio ai guasti (fault):
problematiche e soluzioni
Come è stato illustrato nel precedente capitolo l’architettura MPLS-DiffServ costituisce un valido strumento per garantire i parametri di connettività tra server e client che sono richiesti dal servizio di streaming per funzionare correttamente. In uno scenario statico, cioè qualora nel sistema (server + rete + client) non avvengano cambiamenti, tale architettura risulterebbe sufficiente a garantire una connettività con parametri di funzionamento adeguati per tutta la durata del servizio. Tuttavia in uno scenario più realistico, nel corso del servizio, che in via generale può raggiungere la durata di alcune ore (per esempio in caso dello streaming di un lungometraggio), possono intervenire nel sistema complessivo dei cambiamenti tali (fault) da poter compromettere la sua continuità. In tale evenienza si vogliono mettere in campo dei meccanismi che consentano di rimediare agli inconvenienti.
Possibili
fault
Il servizio usufruisce di un sistema costituito da 3 elementi principali, ciascuno dei quali può in via generale dare luogo ad un fault:
• il client • i server • la rete
Poiché eventuali guasti localizzati sul client (siano essi dovuti un malfunzionamento dell’applicazione di streaming, oppure del client host ) risultano di difficile soluzione, essi non verranno trattati in seguito, presupponendo un’affidabilità totale.
Fault localizzati sul server
Nel casi di fault localizzato sul server si possono riconoscere 3 possibilità:
• Malfunzionamenti catastrofici: cioè guasti che pregiudichino totalmente il funzionamento del server, il recupero dal malfunzionamento, nonché la notifica dell’inconveniente (es. interruzione elettrica, interruzione della connettività, ecc.). Agli effetti del servizio si ha un’interruzione del flusso dati di streaming inviati sulla rete, senza la possibilità di notifica dell’evento.
• Malfunzionamenti non catastrofici: cioè eventi che obbligano il server ad interrompere il servizio verso uno o più client, senza pregiudicare la possibilità di effettuare la notifica della
caso fenomeni di overloading, malfunzionamenti rilevabili del software, ecc. Agli effetti del servizio si ha un’interruzione dello streaming, con notifica dell’errore.
• Byzantine Failure: cioè guasti che il server non è in grado di rilevare, ma lo portano a proseguire l’erogazione del servizio in maniera non corretta, inviando dati di streaming non conformi, oppure in maniera non corretta, che portano il client a interrompere la riproduzione o a proseguire il servizio in maniera errata.
Fault localizzati sulla rete
Per quanto riguarda la rete si deve considerare l’eventualità che essa si trovi, nel corso del servizio, nella situazione di non poter più garantire del tutto o in parte la connettività end-to-end tra client e server, con conseguente interruzione del servizio di streaming; ciò può avvenire in due casi:
• Interruzione della connessione a banda garantita (preemption): alcune architetture di rete (tra la quali MPLS-DiffServ) prevedono la possibilità che connessioni possano venire abbattute in corso di funzionamento, per liberare risorse (tipicamente di banda) a nuove connessioni, secondo criteri di priorità che sono proprie di ciascuna architettura. Tale evenienza, se da un lato non comporta necessariamente l’interruzione completa del servizio, può comunque implicare la perdita delle garanzie di QoS necessarie all’applicazione per funzionare appieno, portando ad una degradazione della qualit à del contenuto multimediale riprodotto.
• Guasti alla rete ( link o nodi ): guasti ai dispositivi di rete lungo il path seguito dallo streaming possono interrompere bruscamente il flusso dei dati diretti al client, pregiudicando la continuità del servizio.
Ripristino di un
fault
Per garantire un servizio affidabile è necessario adottare dei meccanismi di recupero in grado di intervenire a garantire la corretta continuazione del servizio di streaming, qualora intervenga nel sistema uno dei fault elencati. Tali meccanismi possono essere implementati ai diversi livelli dello stack protocollare, dal livello di rete a quello applicativo. In via generale, ed indipendentemente dal livello al quale è implementato, è possibile individuare all’interno di un qualsiasi meccanismo di recupero, 3 fasi distinte e successive che intercorrono dal momento in cui si verifica la fault, al momento in cui essa viene recuperata:
1. Fault detection: in questa fase il fault deve essere rilevato, e deve essere deciso se dare il
2. Fault notification: i meccanismi che operano la fault detection devono notificare la
rilevazione del fault, allo scopo di avviare nel più breve tempo possibile i meccanismi di ripristino.
3. Fault recovery: vengono avviati e portati a completamento i meccanismi di ripristino che
riportano, se possibile, il servizio ai normali standard di funzionamento Vincoli alle prestazioni delle tecniche di ripristino di un fault
Indipendentemente dal meccanismo di recupero, e al livello al quale esso è implementato, sussistono dei vincoli al che essi possano essere utilizzati per assicurare l’affidabilità del servizio. In particolare si vuole:
• Trasparenza all’utente: il metodo di recupero deve essere trasparente all’utente, il che significa che deve portare alla riproduzione del contenuto multimediale al client in modo ininterrotto, senza richiedere alcun intervento dell’utente. Ciò non esclude un’integrazione dei metodi di affidabilità nell’applicazione al lato client, ma richiede che essi impieghino il più breve tempo possibile per completare il recupero dal fault, senza interruzioni, anche momentanee, del servizio. In caso di applicazioni in tempo reale, come uno streaming multimediale, diviene allora fondamentale che i meccanismi di recupero siano quanto più veloci possibili, in modo da completare le procedure prima che il fault provochi un underflowing del playout buffer nell’applicazione al lato client, con conseguente interruzione della riproduzione del contenuto multimediale (vedi Capitolo 1 - Garanzie di QoS richieste da uno streaming multimediale). Il vincolo sul tempo massimo di recupero dipende in maniera determinante dalla lunghezza temporale del playout buffer: valori tipici si aggirano a ordini di grandezza di qualche decina di secondi.
• Continuità della connessione di rete a banda garantita: il metodo di recupero deve essere in grado di garantire con continuità una connessione a banda garantita tra server e client, allo scopo di evitare perdite nella qualità percepita.
Fault
a livello di rete
Nel capitolo precedente si è mostrato come l’architettura MPLS -TE possa essere in grado di garantire la QoS end-to-end, attraverso l’instaurazione di LSP a banda garantita. In seguito verrà analizzato in che modo essa è in grado di garantire l’affidabilità, e se le garanzie offerte sono sufficienti rispetto ai vincoli elencati precedentemente. In particolare si andranno ad analizzare nello specifico i fault di rete precedentemente elencati, per poi affrontare possibili tecniche di ripristino a questo livello dello stack protocollare. Meccanismi di recupero a
inevitabilmente non potranno recuperare un fault localizzato sul server, per i quali sono necessari meccanismi di livello superiore.
LSP preemption
Uno dei vincoli utilizzati dall’algoritmo CSPF per la computazione del LSP path è costituito dai due valori di priorità che contraddistinguono ciascun LSP, il setup priority e l’ hold priority, entrambi compresi nel range 0-7, in ordine di priorità decrescente (0 rappresenta la priorità più alta, 7 quella più bassa).
I valori di priorità sono utilizzati per redimere situazioni di resource contention tra un LSP che deve essere instaurato e quelli già stabiliti, in particolare nel caso in cui sul path ottimo individuato dall’algoritmo CSPF in fase di path computation, vi siano uno o più link in cui la banda disponibile non sia sufficiente a supportare il nuovo LSP, vengono confrontati il valore di setup priority del nuovo LSP con quello di hold priority dei LSP già stabiliti. Qualora il primo sia maggiore dei secondi, questi ultimi vengono abbattuti per lasciare posto al nuovo LSP (LSP preemption).
In caso di fault dovuto a LSP preemption, la fault detection è operata come in Figura 2-1:
Figura 2-1: Fault detection e notification in caso di LSP preemption
1. Fault: Il LSP ad alta priorità viene stabilito attraverso la segnalazione RSVP, instradato
su uno dei link attraversato dal LSP a priorità bassa.
2. Fault detection:. In caso di banda insufficiente il LSP a bassa priorità subisce preemption
e deve essere abbattuto dal transit router, il quale rileva immediatamente il fault.
3. Fault notification: Il transit router invia all’ ingress router un messaggio RSVP RSV
TEAR, insieme ad una nuova istanza di LSA-TE che aggiorna la disponibilità di banda sul link. L’ ingress router può dare inizio alla procedura di dynamic path recovery non appena aggiornato il proprio TED.
La Figura 2-2 mostra un esempio di LSP preemption con rerouting: il LSP BLU viene abbattuto per lasciare risorse al LSP ROSSO e viene reinstradato lungo un percorso subottimo.
Figura 2-2: LSP preemption con rerouting
Il parametro di priorità e i meccanismi di preemption risultano strumenti utili per stabilire una gerarchia dei LSP e quindi per risolvere in modo coerente alle esigenze eventuali problematiche di resource contention, ma anche per ottimizzare il routing di LSP con esigenze particolari. I LSP che godono di valori di priorità maggiore godono infatti di evidenti vantaggi rispetto ai LSP con minore priorità:
• Minore probabilità di blocco e interruzione del servizio: E’ evidente che i LSP con valori di priorità alti hanno minore probabilità di subire preemption o di non venire stabiliti per mancanza di risorse, in quanto non risentono dei LSP a priorità minore.
• Instradamento del LSP su percorsi ottimi: i LSP a priorità maggiore hanno una maggiore probabilità di venire instradati lungo il percorso ottimo; si veda a titolo di esempio la Figura 2-2, in cui il LSP ROSSO ad alta priorità è instradato immediatamente sul percorso ottimo, mentre il LSP BLU dopo la preemption è inoltrato lungo un percorso subottimo, caratterizzato da un maggiore numero di hop. Ciò può riflettersi ad esempio sui parametri di QoS come latenza e jitter, che dipendono fortemente dal numero di hop attraversati.
Per esempio è possibile che nell’applicazione presentata si voglia aggiungere un ulteriore classe di servizio per applicazioni multimediali intolleranti al ritardo, come un servizio di telefonia IP (VoIP) o videoconferenza, i quale richiedono connessioni a banda garantita e con parametro di latenza end-to-end quanto più possibile limitato; è preferibile allora assegnare una priorità più alta ai LSP che servono questa applicazione, in modo che attraverso la preemption possano essere inoltrati verso un percorso più breve, limitando il tempo di attraversamento del LSP.
Poiché il tempo impiegato dalla fase di fault detection, il LSP rerouting in seguito a preemption risulta in definitiva applicabile alle esigenze del servizio, ed è in grado di garantire l’affidabilità, fintanto che sulla rete è presente un path sul quale è possibile instradare il LSP a banda garantita.
Guasto di un link
In caso di malfunzionamento di un link, tutti i LSP che lo attraversano vedranno interrotta la connettività end-to-end, fintanto che le procedure di recupero non si completano. In Figura 2-3 sono illustrate le fasi di fault detection e notification in caso di guasto di un link.
Figura 2-3: Fault detection e notification in caso di guasto di un link
1. Fault: Il fault si verifica in caso che uno dei link attraversati dal LSP si guasti,
interrompendo del tutto la connettività.
2. Fault detection: la fase di fault detection viene effettuata dal transit router direttamente
connesso al link guasto, il quale è in grado di rilevarne l’interruzione o il malfunzionamento attraverso meccanismi di basso livello (elettronico, ottico, ecc.). I tempi di rilevazione possono arrivare a ordini di grandezza intorno al secondo [17], a seconda del tipo di interfaccia.
3. Fault notification: Il transit router invia all’ ingress router un messaggio RSVP RSV
TEAR, insieme ad una nuova istanza di LSA-TE che aggiorna la topologia di rete eliminando il link guasto. L’ ingress router può dare inizio alla fase di fault recovery non appena aggiornato il proprio TED.
Si deve tenere conto che per questo tipo di fault si possono allargare i tempi di ricomputazione dei path attraverso l’algor itmo CSPF: questo perché TUTTI i LSP che attraversavano il link guasto devono essere ricalcolati, e quindi si potrebbe presentare un elevato carico di lavoro per alcuni degli ingress router.
Tuttavia, se la procedura di fault detection si limita a valori prossimi al secondo, e il numero di LSP che può attraversare un link si limita a qualche decina, i tempi di recupero per questo tipo di fault possono anche limitarsi ad alcuni secondi, e quindi, per le nostre esigenze di
affidabilità, potrebbero anche essere recuperati a livello di rete, qualora naturalmente sia disponibile un path alternativo sul quale reinstradare il LSP.
Guasto di un nodo
Il guasto di un nodo può avere conseguenze più gravi di un guasto di link, sia perché implicano l’interruzione di tut ti i link che affluiscono al nodo guasto, sia a causa dell’intrinseca lunghezza temporale della fase di fault detection. In Figura 2-4 sono illustrate le procedure di fault detection e notification:
Figura 2-4: Fault detection e notification in caso di gusto di un nodo
1. Fault: Il fault si verifica in caso che uno dei router attraversati dal LSP si guasti, nel
senso che interrompe la connettività senza però sconnettere le proprie interfacce a livello fisico (ad esempio per un guasto del motore di forwarding).
2. Fault detection: a fronte di un’interruzione della connettività, i router direttamente
connessi a quello guasto non sono in grado di rilevare il fault attraverso i meccanismi di basso livello, come nel caso di un guasto di link. La fase di fault detection viene allora effettuata solo dai meccanismi di refresh soft-state dei protocolli OSPF e RSVP: dopo che il transit router non riceve per un certo intervallo temporale i messaggi di refresh tipici di tali protocolli (esempio OSPF Hello), suppone un guasto del router adiacente. Purtroppo i tempi di rilevazione possono arrivare a ordini di grandezza intorno a qualche decina di secondi.
• Fault notification: Il transit router invia all’ ingress router un messaggio RSVP RSV TEAR, insieme ad una nuova istanza di LSA-TE che aggiorna la topologia di rete eliminando il router guasto. L’ ingress router può dare inizio alla fase di fault recovery non appena aggiornato il proprio TED.
E’ eviden te come in relazione ad un servizio di streaming, un fault di questa natura non possa essere risolto tempestivamente dalla rete, a meno di non usare dei playout buffer in uscita di dimensioni eccessive. Si tenga conto poi, che il guasto di un router implica l’interruzione di tutti i link ad esso connessi, con conseguente fault di tutti i LSP che transitano su quei link:
ciò porta al rerouting di un elevato numero di LSP, in numero maggiore che nel caso di guasto al singolo link, con conseguente allungamento del tempo di recupero
Tecniche di ripristino a livello di rete
Le tecniche di ripristino a livello di rete prevedono sostanzialmente il rerouting del traffico su path alternativi a quelli in cui il fault si è verificato. L’architettura MPLS prevede diver se modalità di ripristino tra cui si può citare la funzionalità di fast-reroute[13], la quale provvede ad una protezione statica del LSP a livello di link: in caso di fault localizzato su un link fast-reroute provvede al ripristino attraverso un LSP di detour precalcolato e prestabilito; a fronte di un tempo di recupero minimo, fast-reroute, come tutte le tecniche di ripristino precalcolate non offre un utilizzo ottimale delle risorse di rete. Per questo motivo si è considerato più specificatamente la tecnica di ripristino basata sul path recovery dinamico.
Path Recovery dinamico
L’architettura MPLS -TE mette in campo funzionalità di path recovery dinamico in grado di ristabilire un LSP prematuramente abbattuto a causa di un fault. In tale evenienza la rete cerca di reagire nel più breve tempo possibile ristabilendo end-to-end il LSP instradandolo lungo un path diverso, calcolato in maniera dinamica, non precalcolata. La Figura 2-5 mostra la procedura di LSP rerouting.
Figura 2-5: MPLS dynamic path recovery
1. Fault: il fault può essere localizzata su un link o su uno dei router attraversato dal LSP.
2. Fault detection:. la detection viene effettuata da uno dei nodi “a monte“ della fault, nei
tempi e nei modi esaminati in precedenza.
3. Fault notification: Il nodo che ha effettuato la fault detection provvede a notificarla
all’ ingress router attraverso messaggi RSVP RSV TEAR. Allo stesso tempo vengono distribuite in tutta la rete nuove istanze di LSA-TE che annunciano eventuali cambiamenti
della topologia, nonché della disponibilità di risorse di banda sui link. Il tempo richiesto per questa operazione dipende dalla latenza di rete e dai tempi di riconfigurazione dei router. Le esperienze proposte nel Capitolo 4, hanno rilevato che questa fase può impiegare alcuni secondi.
4. Fault Recovery 1 (path compilation): L’ ingress router, aggiorna il proprio TED
attraverso i LSA-TE che sono distribuiti nella rete attraverso i meccanismi di OSPF flooding. Quindi è in grado di computare l’algoritmo CSPF per calcolare l’eventuale nuovo path sul quale il LSP può essere reinstradato. Il tempo richiesto da questa fase dipende essenzialmente dalla velocità di computazione del router, e può variare da pochi millisecondi ad alcuni secondi. Inoltre va considerato che nel caso un router debba ricalcolare contemporaneamente più LSP (si veda ad esempio il caso di guasto di un link), il tempo impiegato si allunga in maniera proporzionale al loro numero
5. Fault Recovery 2 (path signaling): Se la computazione ha successo il LSP può venire
ristabilito attraverso la segnalazione RSVP-ER (vedi Capitolo 1 - Traffic engineering con MPLS). Tale segnalazione impiega un tempo vicino al Round Trip Time tra ingress ed Egress router (messaggio PATH + messaggio RSV) , con valori tipici massimi di alcune centinaia di millisecondi.
I tempi necessari a tale procedura vengono a dipendere da due fattori determinanti:
• Latenza end-to-end, determinante ai punti 3 (fault notification) e 5 (segnalazione RSVP) • Velocità di computazione del LSP da parte dell’ ingress router (punto 4).
Inoltre va tenuto conto che i tempi di recupero aumentano in rapporto alle dimensioni del dominio MPLS: in caso di una rete di grandi dimensioni, con migliaia di LSP attivi, un fault grave, come il guasto di un link potrebbe provocare il rerouting di un numero molto elevato di LSP; i n tal caso si potrebbero creare dei fenomeni di resource contention, con il risultato che alcuni LSP potrebbero seguire la procedura di rerouting diverse volte, prima di raggiungere una conformazione stabile, con il risultato di moltiplicare i tempi di recupero.
E’ evidente quindi che, rispetto ai criteri di affid abilità richiesti, tale meccanismo pone due problematiche che devono essere considerate:
• La procedura di recupero potrebbe impiegare troppo tempo, con il rischio di incorrere nella perdita di qualità dell’applicazione. Considerando domini MPLS fino a dimen sioni medie (poche decine di router), le procedure di recupero a livello di rete sopra elencate, possono limitare la loro durata ad alcuni secondi; se anche la fase di fault detection è limitata temporalmente ad alcuni secondi, è allora ancora possibile che la procedura di dynamic path
recovery possa essere utilizzata nelle applicazioni di streaming utilizzando buffer sufficientemente grandi.
• La procedura di recupero potrebbe non avvenire affatto, qualora non siano presenti sulla rete path alternativi, interrompendo quindi la connettività con parametri di QoS garantiti.
Tecniche di ripristino a livello superiore: migrazione del server
Nelle applicazioni di rete di tipo client / server, i meccanismi di migrazione del server possono costituire uno strumento efficace per garantire l’affidabilità e la continuità del servizio in caso di fault. E’ possibile infatti che lo stesso servizio possa venire erogato da un altro server (backup server), in maniera automatica e senza l’intervento dell’utente al lato client (Figura 2-6). Ovviamente ciò richiede che esista sulla rete almeno un altro server che possa erogare lo stesso servizio per prendere posto del vecchio. Nel caso qui analizzato si richiede che sulla rete siano disponibili un certo numero di server, che siano in grado di erogare lo stesso contenuto multimediale. E’ da notare che è possibile che tutti i server siano operativi, in modo che ciascuno eroghi il servizio a client differenti, secondo una politica di load balancing.
Figura 2-6: Migrazione del server
Server Server
Client Client
Si tratta di tecniche che allo stato attuale sono state proposte in letteratura essenzialmente per garantire l’affidabilità in caso di fault del server, cioè nei casi in cui i meccanismi a livello di rete non possono essere di aiuto. Diverse architetture ed implementazioni sono state proposte ad oggi; in seguito si andrà ad illustrare le più interessanti, quali sono le problematiche che devono essere affrontate, e quali soluzioni sono state adottate.
Fault detection e fault notification
Nell’ambito dei meccanismi di migrazione del server, la funzionalità di fault detection può essere localizzata essenzialmente in 3 punti:
• Sul server: la fault detection operata direttamente dal server è stata proposta in diverse implementazioni [15][16], risultando particolarmente adatta a rilevare tempestivamente fault del server minori, quali problematiche di overloading o guasti non catastrofici. Risulta impiegata anche qualora si voglia operare una migrazione del server in modo trasparente all’applicazione a lato client [15].
• Mediante agenti centralizzati: alcune implementazioni [14][16] propongono l’adozione di processi delocalizzzati dal server e dal client, con compiti di supervisione sul sistema globale, per rilevare e innescare la migrazione del server . Possono consistere in health monitor, per rilevare fault localizzati sul server [16]. Inoltre possono essere utilizzati per controllare il processo di fault recovery in fase di migrazione del server [14].
Un approccio centralizzato di questo tipo può da un lato presentare vantaggi di maggiore affidabilità in fase di fault recovery, grazie ad un maggior controllo sullo stato complessivo del sistema. Dall’altro presenta problematiche ovvie di scalabilità, nonché di affidabilità in fase di fault detection, in quanto i sistemi di health monitor possono non sempre risultare affidabili nel rilevare tempestivamente fault sul server, soprattutto in caso di byzantine failure.
• Sul client: l’applicazione a lato client è in grado di rilevare tempestivamente un fault solo nel caso in cui il servizio implichi una costante interazione con il server, come nel caso di un servizio di content delivery, di cui lo streaming risulta un esempio tipico; una improvvisa interruzione della comunicazione, nonché la degradazione della qualità della connettività end-to-end, possono essere rilevate dal client per effettuare una tempestiva fault detection.
Per di più, rispetto ad una fault detection operata sul server, questo approccio consente di rilevare tempestivamente non solo fault localizzati sul server, ma anche eventuali fault di
rete. A fronte di questi vantaggi, un approccio del genere richiede d’altra parte modifiche all’applicazione lato client.
Una volta che i meccanismi di fault detection hanno rilevato la necessità della migrazione del server, la fault notification richiede unicamente che l’evento sia notificato tempestivamente ai sistemi che devono operare la fault recovery.
Fault recovery
I meccanismi di fault recovery devono far fronte essenzialmente a due problematiche:
• Checkpointing: Qualsiasi implementazione deve far fronte al problema del checkpointing dell’applicazione, cioè il server di backup deve essere in grado di continuare ad offrire il servizio da dove il working server è stato interrotto. La mancanza di una tale funzionalità rende inutile l’implementazione del meccanismo di migrazione. Il problema legato a questo meccanismo è legato al fatto che il checkpointing è fortemente application dependent.
Nel caso dello streaming multimediale tuttavia il problema può risultare di semplice soluzione: se tutti i server hanno memorizzato lo stesso file multimediale, è possibile operare un checkpointing a livello di byte, in cui il server di backup inizia lo streaming dall’esatto punto del file in cui il server primario è stato interrotto.
• Scelta del server di backup: le politiche di scelta del server di backup, che sono necessarie qualora i server a disposizione siano più di 2, possono soddisfare diverse esigenze di ottimizzazione. Alcune implementazioni [16] propongono che come server di backup sia scelto quello verso il quale è possibile completare la procedura di migrazione nel minor tempo: ciò può risultare fondamentale in applicazioni in tempo reale come lo streaming multimediale, allo scopo di garantire un servizio quanto più possibile continuo e senza perdite di qualità all’utente al lato client. In applicazioni meno stringenti dal punto di vista temporale, o comunque nei casi in cui si voglia ottimizzare l’utilizzo delle risorse di rete può risultare più utile scegliere il server che richieda un minore utilizzo di risorse di rete per garantire la connettività, ad esempio scegliendo il server che presenti la minore “distanza” dal client host, secondo la metrica IGP.
Migrazione del server trasparente al client
Le ultime proposte apparse in letteratura riguardanti schemi di migrazione del server, mirano a rendere il processo quanto più possibile trasparente ai vari livelli del lato client, con l’intenzione di proporre architetture per un servizio che tenda a mi nimizzare gli interventi che
devono essere operati al lato utente, delocalizzando gli aggiornamenti richiesti al lato service provider (server + rete).
Una proposta interessante è quella portata da [16], che presenta un’architet tura totalmente trasparente all’applicazione al lato client; per far questo però è necessaria la modifica del livello di trasporto, in particolare alla parte di kernel del client host, che gestisce il protocollo di trasporto TCP, allo scopo di dotarlo di funzionalità per la migrazione del peer in maniera trasparente all’applicazione. L’obiezione che si può muovere a questa proposta è quella di aver solamente spostato la modifiche dall’applicazione al livello di trasporto. Al contrario viene mostrato un interessante approccio distribuito, in cui la migrazione del server è utilizzato per risolvere problematiche di server overloading o server failure.
Proposte ancora più radicali sono quelle portate da [14] e [15], i quali propongono alcune possibili meccanismi di migrazione del server implementati in maniera trasparente al client host a tutti i livelli, da quello di rete a quello applicativo; in altre parole in seguito alla migrazione del server intervengono delle procedure nella rete e nei server tali da emulare la continuità del server primario; ciò comporta l’innegabile vantaggio di non dover apportare alcuna modifica all’architettura del client host, nonché alle applicazioni che usufruiscono del servizio, anche qualora queste non prevedano alcun meccanismo di migrazione del server. D’altra parte un’implementazione di questo tipo implica la necessità di notevoli interventi sull’architettura di rete e dei server ai livelli più bassi:
• Livello di rete: affinché la migrazione del server sia trasparente a livello di rete è necessario che il backup server si appropri dell’indirizzo di rete del working server. Ciò comporta due possibili scenari:
Colocazione dei server [15]
Architetture di rete per la transizione di indirizzi [14]
• Livello di trasporto: affinché la migrazione del server sia trasparente a livello di trasporto è necessario tenere costantemente traccia dello stato della connessione a tale livello; se il servizio fa uso di un protocollo di trasporto stateful (esempio TCP) è necessario che sia tenuta traccia di tutti i parametri di stato della connessione (es. TCP Sequenze number).
Cooperazione tra tecniche di ripristino a diversi livelli
Si è visto come un fault di rete può essere risolto attraverso i meccanismi previsti dall’architettura, la quale può provvedere al re routing automatico della connessione protetta.
Tuttavia si è visto come essi, nell’ambito del servizi o di uno streaming multimediale, non possono considerarsi del tutto affidabili per 2 ordini di motivi:
• La procedura di recupero potrebbe impiegare troppo tempo (ad esempio in caso di guasto di nodo), con il rischio di incorrere nella perdita di qualità dell’applicazione.
• La procedura di recupero potrebbe non avvenire affatto, qualora non siano presenti sulla rete path alternativi tra server e client, interrompendo quindi la connettività con parametri di QoS garantiti.
I meccanismi di migrazione del server siano stati proposti in letteratura per risolvere problematiche di affidabilità legate a possibili fault riconducibili al server stesso, in cui la rete è impossibilitata ad intervenire. Tuttavia non è detto che la migrazione del server non possa essere utilizzata per recuperare fault di rete, che la rete stessa non è in grado di recuperare, allo scopo di migliorare l’affidabilità complessiva del servizio.
Si veda ad esempio la Figura 2-7: durante il servizio il client perde la connessione a banda garantita con il Server A, ad esempio in caso di LSP preemption senza possibilità di rerouting. Se è possibile invece stabilire un LSP tra Server B e client, la migrazione del server è in grado di risolvere la fault laddove la rete risulta per forza di cose impossibilitata.
Figura 2-7: Migrazione del server in caso di fault di rete
Altri casi in cui un intervento tempestivo della migrazione del server può garantire una maggiore affidabilità, risulta essere un fault di rete in cui la rete stessa non è in grado di
intervenire in maniera sufficientemente veloce e tempestiva, come un fault di nodo, in tale evenienza la perdita di connettività può essere rilevata tempestivamente in fase di fault detection dal client, che può quindi richiedere la migrazione per garantire la continuità del servizio.
Coordinazione delle tecniche di ripristino
E’ evidente comunque che per integrare meccanismi di recupero a livelli diversi occorre stabilire dei criteri e delle funzionalità che permettano la loro coordinazione, allo scopo di evitare fenomeni di sovrapposizione o concorrenza che possono portare il sistema complessivo ad uno stato inconsistente.
Il criterio più semplice è quello di far intervenire meccanismi di livello superiore soltanto qualora quelli di livello inferiore non siano in grado di recuperare il fault nel rispetto dei vincoli richiesti dal servizio. Nel nostro caso allora la migrazione del server dovrebbe intervenire nel caso di fault di rete, soltanto qualora la rete non sia in grado di effettuare il LSP rerouting nei tempi stabiliti.
Criteri diversi da quello temporale, potrebbero basarsi sull’ottimizzazione nell’utilizzo delle risorse di rete, ad esempio facendo in modo che fra tutti i server da cui è possibile instaurare una connessione a banda garantita sia scelto quello che minimizza la metrica IGP
Nel caso di preemption del LSP che trasporta lo streaming dal server A, la rete potrebbe effettuarne il rerouting su un percorso subottimo; tuttavia potrebbe essere possibile erogare il servizio dal server B nel caso sia possibile stabilire un LSP che impieghi una metrica IGP minore, nel qual caso, sebbene la rete sia in grado da sola di ripristinare il servizio, la migrazione potrebbe essere utilizzata per minimizzare l’utilizzo delle risorse di rete.
I diversi criteri non sono mutuamente esclusivi, poiché potrebbero ad esempio essere utilizzati in momenti successivi, ad esempio utilizzare il criterio temporale in prima battuta non impedisce l’adozione di criteri di traffic-engineering in un secondo momento, quando le esigenze di urgenza e tempestività della soluzione non sussistono più.
Nelle implementazioni presentate nei capitolo successivi si è fatto ricorso al primo criterio, basato sulla precedenza temporale, come mostrato in Tabella 2-1.
Fault di rete Ripristino Primario Ripristino Secondario
LSP preemption ⇒ LSP rerouting ⇒ Migrazione del Server Guasto di link ⇒ LSP rerouting ⇒ Migrazione del Server Guasto di nodo ⇒ Migrazione del Server
Tabella 2-1: Coordinazione dei meccanismi di recupero secondo un criterio di livello
Nei casi quindi di preemption e link failure è la rete ad intervenire per prima, mentre la migrazione del Server è adottata solo in seconda battuta. Al contrario, poiché è stato stabilito che in caso di guasto di nodo è molto improbabile che la rete riesca ad intervenire tempestivamente, viene adottato comunque la migrazione del Server.
In definitiva questo criterio individua la strategia che consente di minimizzare il tempo di recupero per ciascuna fault di rete, privilegiando i meccanismi di recupero a livello di rete qualora essi risultino siano più veloci ad completare il recupero rispetto alla migrazione del Server, mentre quest’ultima è adottata qualora la prima non sia in grado di interve nire tempestivamente. Tale criterio consente di minimizzare il tempo impiegato dai meccanismi di recupero dalla fault di rete, cosa fondamentale nel caso di un servizio di streaming, in cui un tempo di recupero troppo elevato può comportare un’interruzion e del servizio, in caso di underflowing del playout buffer.
