Spinelli Raffaele. SISI on cluster

Transcript

1 Spinelli Raffaele SISI on cluster

2 Introduzione SISI - Scalable Intermediary Software Infrastructure, è un framework per sviluppare e fare deploy di Edge Service. SISI è basato su Apache e mod_perl Grazie a mod_perl è possibile accedere ad ogni fase del HTTP request cycle di apache, in modo da personalizzare il comportamento dello stesso. In definitiva SISI è un proxy, che applica i servizi sullo stream request/response HTTP Ma come realizzare un cluster di SISI?

3 Lo Stato dell'arte L'architettura di base nella realizzazione di cluster di web server, implica la figura di un Web Switch che di solito è l'unico dispather, la cui mansione non è altro che quella di smistare le richieste e/o le risposte tra i clienti e il cluster. Ci sono due tipologie di dispatcher: L4/x L7 Si differiscono per: Per il livello in cui vengono prese le decisioni. Inoltre entrambi si differenziano in one-way e two-way. I dispatcher L7 operano a livello 7 dello stack ISO/OSI, e per questo risultano molto inefficienti rispetto agli L4, ma in compenso possono utilizzare algoritmi di dispatching che basano le loro decisioni sui contenuti di una richiesta, e risultano più flessibili.

4 Lo Stato dell'arte - 2 I dispatcher L4/x lavorano a livello di trasporto, si differenziano tra di loro per l'esatto livello a cui operano, in pratica esistono due dispatcher: L4/2 L4/3 Lo smistamento viene fatto tramite una tabella di routing All'arrivo di un pacchetto, se c'è un SYN bit, viene scritto un nuovo record nella tabella Viceversa viene ricercato nella tabella, l'indirizzo del client, per vedere a chi fare forwarding dei pacchetti da quest'indirizzo.

5 Lo Stato dell'arte - 3 I dispatcher L4/x possono fare una stima del carico dei nodi già dalla mappa che usano per il dispatching, senza bisogno di informazioni provenienti dai nodi. Una stima di questo tipo non è molto affidabile in quanto tiene conto solo del numero di connessioni per nodo, (e.: Least Connections algorithm usato anche da Cisco LocalDirector) La differenza tra L4/2 e L4/3 è che il primo opera a livello MAC, il secondo a livello IP. C'è una differenza in efficienza, in quanto con un L4/3 ci sono un po' di controllo in più da fare, che non sono fatti con un dispatcher L4/2.

6 Lo stato dell'arte - 4 Cosa significa two-way? Il web switch non si occupa solo di assegnare un server ad ogni richiesta di connessione, ma anche di instradare la risposta verso il client È intuitivo vedere come il web switch in questo caso, possa facilmente diventare il collo del bottiglia del sistema.

7 Lo stato dell'arte - 6 Chissà cos'è one-way? Il web switch si occupa solo di assegnare un server ad ogni richiesta di connessione, è il server stesso a preoccuparsi poi di mandare direttamente la risposta al client. Per realizzare un web switch one-way ci sono alcune tecniche, tra le quali spiccano: RR DNS Aliasing

8 Lo stato dell'arte - 7 In base a quale criterio vengono prese le decisioni di dispatching? Gli algoritmi per il dispatching si dividono in : Statici RoundRobin (RR) Dinamici Client-aware algorithms Server-aware algorithms Client and server aware algorithms Il primo meta-algoritmo tiene conto di informazioni sul client, un dispatcher L7 può prendere decisioni in base al tipo di servizio richiesto dal client o altre informazioni contenute nella richiesta http.

9 Lo stato dell'arte - 8 Il secondo meta-algoritmo tiene conto dello stato dei server componenti il cluster, (CPU load, numero di connessioni aperte, numero di connessioni che pendono). Il terzo meta-algoritmo cerca di ottenere un load balancing migliore rispetto ai primi due fondendoli, infatti quest ultimo decide sia in base ad informazioni relative al client, sia in base ad informazioni sullo stato dei nodi. Le decisioni da prendere richiedono un po di lavoro in più Ma può risultare in una migliore distribuzione del carico di lavoro.

10 L'idea La prima cosa è stata cercare fra i moduli esistenti per perl, qualcosa che facesse al caso nostro. Il full-immersion sui moduli perl di CPAN alla ricerca di qualcosa per la realizzazione del cluster non ha dato i risultati desiderati. L'idea è stata suggerita dalla documentazione di mod_perl. Utilizzare i VirtualHost di Apache e dei PerlProcessConnectionHandler ad hoc

11 L'idea - 2

12 L'idea - 3 Con parole di mod_perl The process_connection phase is used to process incoming connections. Only protocol modules should assign handlers for this phase, as it gives them an opportunity to replace the standard HTTP processing with processing for some other protocols (e.g., POP3, FTP, etc.). L'implementazione di nuovi protocolli va fatta in VirtualHost, in questo modo è possibile implementare su più VirtualHost un protocollo di comunicazione per lo scambio di dati sullo stato del cluster e uno per per lo smistamento delle richieste da soddisfare.

13 L'Architettura Per ovviare al vincolo di trasparenza sul client, si puòricorrere ad un dispatcher L4/2 con aliasing. I client hanno come indirizzo del proxy l'indirizzo del dispatcher,i nodi del cluster hanno oltre al proprio indirizzo IP un altro indirizzo IP secondario,quello del despatcher Questo di solito è realizzato grazie ad un 'hack' del modulo tcp/ip del kernel di sistemi *Unix.

14 L'Architettura - 2 In pratica... Portare su VirtualHost la fase di applicazione dei servizi, che in fondo è quella che costa di più, replicando i servizi.

15 L'Architettura - 3 Emerge per l'architettura il ruolo del Naming Server. Il suo compito è quello di tener traccia dei nodi attivi, e comunicare i cambiamenti a tutti i nodi attivi. Inoltre è a conoscenza dei servizi disponibili di tutti i nodi attivi. Il ruolo del Naming Server, non è un collo di bottiglia, serve solo per il BootUp. Il Naming Server può rendersi utile anche per l'autenticazione degli utenti, infatti...

16 L'Architettura - 4 A meno di implementare un sistema di autenticazione distribuito, ogni macchina ha la lista di tutti i profili. Quando un utente vuole modificare il suo profilo, le modifiche devono essere condivise da tutti i nodi Il Naming Server tiene una lista dei nodi avvisati dei cambiamenti, in modo da poter avvisare anche eventuali nodi che al momento non sono attivi Una lista di questo tipo dovrebbe avere una durata di esistenza ragionevole, da studiare per bene, un esistenza troppo breve taglierebbe fuori dei nodi dalle modifiche ai profili, un esistenza troppo lunga sarebbe uno spreco di risorse.

17 Il protocollo Quanto conviene usare SOAP come protocollo di comunicazione? SOAP per sua natura non brilla per efficienza, ma per l'interoperabilità che ne deriva, almeno teoricamente :) La sua non efficienza è dovuta, se non del tutto, al fatto che utilizza XML, il cui parsing è parecchio oneroso Persone come Dan Davis e Manish Parashar hanno condotto benchmark comparativi tra vari SOAP ToolKit e altri protocolli binari. [Latency Performance of SOAP Implementations ] [Performance of Web Services in Capital Market System ] Ma i risultati non sono molto incoraggianti...

18 The test in question Correva l'anno 2001 quando scoprirono che... Solo Microsoft riusciva a fare peggio...

19 The test in question - 2 Dopo un anno... E Microsoft guadagna posizioni...in un modo o nell'altro

20 The test in question - 3 Purtroppo i benchmark si fermano al 2002, cosicché non ci sono dati a sufficienza per prendere una decisione. Per questi motivi, abbiamo deciso di fare dei semplici test di comparazione tra due SOAP ToolKit e un protocollo binario, sempre su un metodo per l'appunto DoNothing() I test hanno riguardato: JavaRMI Apache AXIS SOAP::Lite Comunicazione direttamente su Socket

21 I nuovi test Il test su JavaRMI è stato eseguito nel caso semplice, in assenza di repository, ovvero copiando a mano lo stub nel classpath del client l test su AXIS è stato effettuato utilizzandolo come servlet per Apache Tomcat, ivi utilizzando HTTP come protocollo. Per SOAP::Lite, erano in programmazione per essere eseguiti due tipologie di test, per adesso è stato possibile realizzare solo il primo tipo. Il primo tipo di test consiste nell'utilizzare un demone HTTP embedded istanziato all'interno dello script perl. E il secondo tipo di test? Il secondo, invece voleva inserire il servizio all'interno di Apache/mod_perl, però...

22 I nuovi test - 2 Qualche dettaglio sul secondo test Dopo aver installato e configurato adeguatamente Apache, mod_perl e il modulo SOAP::Lite, all'invocazione del servizio si otteneva il seguente errore: Questo è dovuto al fatto che mod_perl è nella fase heavy development di conseguenza non è facilissimo per chi sviluppa moduli andare passo passo con le nuove versioni Per adesso bisogna pazientare un po', e provare con versione meno recenti.

23 I nuovi test - 3 JavaRMI Risultati

24 I nuovi test - 4 Apache AXIS Risultati Un po' altino, vediamo che succede se lo richiamiamo

25 I nuovi test - 5 Apache AXIS - Resurrection Perché? Questo è dovuto all'inizializzazione di axis, che causa un notevole aumento della latenza nella prima invocazione, infatti anche chiamando servizi differenti, la latenza non ha sbalzi di questa portata.

26 I nuovi test - 6 SOAP::Lite con daemon HTTP embedded Come prima c'è una significativa differenza tra la prima invocazione e le successive In questo caso è dovuto all'istanziazione del demone HTTP da parte dello script server.pl

27 I nuovi test - 6 SOAP::Lite con daemon HTTP embedded Come prima c'è una significativa differenza tra la prima invocazione e le successive In questo caso è dovuto all'istanziazione del demone HTTP da parte dello script server.pl

28 Conclusioni SOAP-Lite è migliorato negli ultimi anni, ma i suoi valori restano abbastanza alti, purtroppo non essendo stato possibile effettuare il secondo tipo di test, decidere adesso sarebbe prematuro e potrebbe portare a un prototipo non efficiente. L'idea è che se la latenza si porta sotto i 100ms si potrebbe utilizzare SOAP-Lite senza troppa inefficienza.

29 T h a t 's A l l