UNA POSSIBILE SOLUZIONE OPENSOURCE PER UN SERVIZIO DI AUTENTICAZIONE UNICA AD ALTA DISPONIBILITA E SCALABILITA Giovanni Battista Barone, Davide Bottalico, Ciro Di Mauro, Nicola Ranaldo, Amerigo Izzo [giovannibattista.barone,davide.bottalico,ciro.dimauro,nicola.ranaldo,amerigo.izzo]@unina.it Centro di Servizi Informativi di Ateneo (C.S.I.) Università degli Studi di Napoli Federico II La continua evoluzione dei sistemi informativi, lo sviluppo delle reti, la diffusione del personal computer e l accresciuta informatizzazione di base, hanno favorito la crescita del bacino d utenza che fruisce di servizi in via telematica. Questi ultimi sono erogati sempre più frequentemente tramite applicazioni web-based spesso eterogenee e gestite da molteplici unità organizzative all interno della stessa realtà aziendale. In questa ottica i problemi di autenticazione e autorizzazione dell utente devono essere centralizzati per semplificarne la gestione, normalizzare ed integrare le informazioni con sistemi legacy ed attuare policy di sicurezza omogenee. I directory services costituiscono la soluzione ideale e standardizzata al problema assumendo quindi un ruolo chiave nella infrastruttura IT aziendale. Alle necessità di alta affidabilità e continuità si associa l esigenza di livelli di scalabilità della infrastruttura che rispondano alle dinamiche di evoluzione dei volumi di servizi erogati. In questo lavoro viene presenta l architettura realizzata mediante software opensource per i servizi di directory e di autenticazione unica di Ateneo. 1. Introduzione Scopo di questo lavoro è descrivere una possibile architettura per la fornitura in alta disponibilità di servizi di Directory Service di Ateneo e di autenticazione unica. Tali servizi costituiscono il cuore dei sistemi informativi di ateneo in quanto ad essi fanno riferimento tutte le procedure che devono avere accesso ai dati personali degli utenti strutturati e degli studenti per effettuare le classiche operazioni di ricerca (White Pages), verifica delle credenziali di accesso, gestione della messaggistica (posta elettronica e liste di distribuzione) e mailrouting al fine dell erogazione dei servizi web-based e di accesso alle risorse di rete (Dial-up, WiFi). Stante la criticità dei servizi offerti in termini di disponibilità, affidabilità e prestazioni, è necessario fare ricorso a combinazioni di architetture hardwaresoftware che possano soddisfare i requisiti citati. 1.1. Scelte progettuali Al fine di soddisfare i requisiti di affidabilità, protezione e scalabilità dell infrastruttura si è deciso di adottare le seguenti scelte architetturali:
- Il directory service dovrà essere in configurazione master-slave, al fine di separare le operazioni di scrittura/aggiornamento che avvengono sul master da quelle di lettura sugli slave da parte dei client. Tale scelta consente un più puntuale controllo delle policy di accesso in scrittura sul master e semplifica le politiche di gestione delle repliche sugli slave; - Per motivi di affidabilità, il directory service principale dovrà essere in alta affidabilità con cluster in configurazione active-standby e area di storage su SAN con storage services avanzati; - Gli slave dovranno essere tra di loro indipendenti e conservare sullo storage interno una replica del directory master. Il loro numero dovrà essere facilmente adeguabile al carico del sistema (scalabilità): per tale motivo dovranno essere tra di loro identici (differendo del solo indirizzo IP) e facilmente clonabili; - I client non dovranno essere a conoscenza dei singoli slave ed inoltreranno le richieste ad un unico indirizzo di rete cui farà capo un sistema di load balancing; - Il sistema di load balancing, oltre a bilanciare il carico delle richieste tra gli slave, ne verificherà la funzionalità con interrogazioni verso le istanze del servizio controllando che queste rispondano in modo semanticamente corretto (affidabilità e disponibilità); - L architettura dovrà essere realizzata utilizzando software OpenSource al fine di soddisfare requisiti di economicità e flessibilità; - L architettura hardware sulla quale implementare i servizi dovrà possedere caratteristiche di modularità, ridondanza e assenza di single point of failure per le componenti di alimentazione elettrica e rete. Dovrà inoltre consentire di effettuare operazioni di clonazione e sostituzione dei sistemi in maniera rapida ed affidabile. L architettura proposta è schematizzata in figura 1. Figura 1 Schema architetturale proposto
Di seguito verranno descritti i singoli elementi software scelti dopo attenta analisi per l implementazione dell architettura. 1.2. LDAP LDAP [1] (Lightweight Directory Access Protocol) nasce come alternativa leggera al DAP, protocollo per l accesso ai directory services X.500. Una delle sue più note e robuste implementazioni è OpenLDAP, da noi adottato oltre che per le note qualità in termini di affidabilità e prestazioni, anche per la facilità con cui è possibile realizzare la replicazione near real-time dei dati del directory verso altre istanze LDAP attraverso il nuovo protocollo syncrepl [2]. 1.3. RADIUS RADIUS [3] è lo standard de-facto per la fornitura di servizi di AAA (Autentication, Authorization, Accounting) per l autenticazione degli utenti che richiedono l accesso alle risorse di rete. In particolare, l architettura proposta dovrà supportare il servizio di autenticazione per il sistema di accoglienza PSTN/ISDN e per l accesso alla rete WiFi di Ateneo (WiFED). L implementazione scelta è FreeRADIUS [4], soluzione OpenSource ampiamente testata ed apprezzata per la flessibilità ed il supporto della maggioranza dei vendor e dei protocolli di autenticazione attualmente disponibili (in particolare PAP/TTSL, MSCHAPv2/PEAP). 1.4. LVS La soluzione OpenSource adottata per il load balancing è Linux Virtual Server [5], che realizza le funzionalità di bilanciamento delle richieste a livello IP. Tale soluzione è stata preferita anche in funzione della integrazione con ldirector, Tale strumento, disponibile nella suite di Linux-HA, ha il compito di interrogare le diverse istanze del servizio per verificare che le risposte siano semanticamente corrette così da guidare, tramite LVS, la redirezione delle richieste solo verso i real-server che funzionano correttamente. 1.5. Linux HA I servizi che costituiscono un single point of failure per l intero sistema di autenticazione, ovvero il servizio LDAP e Load Balancer, sono stati implementati su cluster in modalità active-standby utilizzando il modulo HeartBeat del progetto Linux-HA. 1.6. Linux Il sistema operativo OpenSource adottato è Linux nella sua distribuzione Gentoo per architettura amd64, scelta per il suo supporto nativo alle più recenti tecnologie e la flessibilità. Inoltre, essendo basata sui sorgenti, è ottimizzata per la piattaforma hardware sui cui è installata.
2. Realizzazione 2.1.1. LDAP Master Il directory service master è basato su LDAP ed è deputato esclusivamente alla conservazione e gestione dei dati: data la sua criticità è protetto con particolari policy di accesso e non è direttamente accessibile ai client. Le informazioni in esso contenute vengono aggiornate quotidianamente ed in modo automatico tramite opportune procedure (connettori) che sincronizzano i dati presenti con quelli provenienti dalle basi dati legacy, ad eccezione di alcuni campi (es. password) che l utente gestisce autonomamente tramite pannelli di gestione web-based. La continuità del servizio è garantita da un cluster in modalità active-standby realizzato tramite heartbeat con uno shared storage su SAN che offre storageservices (snapshot, mirroring, backup continui) con collegamenti Fibre Channel senza singoli punti di fallimento. La versione di OpenLdap adottata è la 2.3.35 che implementa una realizzazione stabile del protocollo di replica Syncrepl. Il backend adottato è basato su BerkeleyDB con tuning dell environment per ottimizzarne le prestazioni (checkpoint, cache). 2.1.2. Servizi Front End Le richieste di accesso ai servizi di directory ed autenticazione vengono evase dai sistemi di front end. Su ognuno di essi è presente una istanza di LDAP che contiene la replica in real-time del master ed una istanza radius per il servizio AAA. La necessità di propagare il più velocemente possibile gli aggiornamenti dal master LDAP ai front end, richiede l uso del protocollo di sincronizzazione syncrepl in modalità RefreshAndPersist [6]: tale modalità prevede l instaurazione di una connessione persistente tra il consumer ed il provider che può, in modalità PUSH, propagare al consumer gli aggiornamenti della base dati in near real time. L istanza LDAP sui sistemi di front end è stata inoltre ottimizzata nel backend prevedendo gli opportuni indici di ricerca ed evitando il proliferare dei file di log del db prevedendone l autocancellazione. I sistemi di front end sono stati concepiti per essere elementi autonomi in caso di indisponibilità del servizio di LDAP Master in quanto le istanze radius presenti su ogni singolo elemento fanno riferimento al servizio LDAP locale al front end come accesso al servizio di directory. 2.1.3. Load balancer Il sistema di load balancing è incluso in modo nativo nel kernel 2.6.19 e viene gestito tramite ipvsadm versione 1.24. In considerazione del fatto che la tipologia delle richieste verso i front end è tipicamente non persistente, e quindi il numero di connessioni verso un front end è pari al numero di job effettivamente in esecuzione su di esso, si è scelto di adottare un algoritmo di scheduling che stimi il carico in base al numero di connessioni, ovvero il SED (Shortest Expected Delay). L algoritmo di dispatching dei pacchetti IP è il DirectRouting : le richieste indirizzate dai client all ip virtuale che espone il servizio vengono forwardate a
livello 2 verso i front-end che risponderanno direttamente ai client. In questo modo il traffico di risposta dai front-end ai client non transita per il load balancer garantendo così tempi di risposta inferiori. 2.2. Hardware La realizzazione di un sistema che offra servizi in alta disponibilità, non può prescindere dall impiego di architetture hardware ridondanti. La soluzione architetturale proposta è efficacemente implementabile su sistemi di tipo blade che rappresentano il compromesso ottimale tra prestazioni, affidabilità e compattezza. La presenza di elementi comuni replicati (switch, alimentatori), la particolare simmetria nelle connessioni di questi con i blade-enclosure e l opportuna dislocazione fisica dei servizi sulle diverse lame consente l ottimizzazione della disponibilità in caso di failure hardware multipli. In figura 2 è rappresentato lo schema dei collegamenti di rete e di alimentazione delle lame e lo schema di allocazione dei servizi (viola LDAP master, giallo front-end, blu load balancer). Ogni lama dispone di 4 interfacce Giga ethernet (2 verso lo switch destro, 2 verso il sinistro): per sfruttare tale simmetria e garantire la connettività nell evenienza di un guasto degli switch, le interfacce delle lame sono poste 2 a 2 in bonding in modalità active-standby per garantire il path attraverso lo switch ancora attivo. Gli switch, a loro volta, sono tra di loro interconnessi da trunk orizzontali e verticali e connessi a 2 diversi switch di distribuzione mediante trunk: i loop di rete interni ed esterni vengono controllati tramite protocollo spanning tree. Figura 2 Schema connessioni hardware
3. Test 3.1. Test di affidabilità Sono stati effettuati dei test per verificare la risposta dell intero sistema ai fallimenti delle singole componenti. Per i test è stato utilizzato un software open source (SLAMD [7]) che permette la generazione di carico per le tipologie di servizi più diffusi in funzione di una molteplicità di parametri. In particolare, è stato verificato il tempo di risposta di LVS alla caduta di uno dei front end. Si può notare in figura 3 come in un tempo stimabile in meno di 3 secondi ldirector rileva il fault e istruisce LVS in modo da redirigere le richieste verso i front end funzionanti minimizzando il tempo di disservizio. Tale tempo è al più uguale all intervallo di check del servizio (parametro checkinterval in configurazione di ldirector) ed il valore scelto in questo caso (5s) è un compromesso tra rapidità di intervento e carico sui front-end aggiuntivo per i soli check. Figura 3 Risposta del sistema al fallimento di 1 front end 3.2. Misure di carico Il testbed realizzato è stato sottoposto ad un carico di produzione ed i front end monitorati tramite le features di Nagios [8]. Nelle figure sottostanti è riportato l andamento del carico del sistema implementato utilizzando solo 2 macchine per il sistema di front end. Dai grafici è evidente la buona suddivisione del carico tra i due sistemi in risposta a richieste di tipo search : nel periodo di tempo considerato uno dei due sistemi è stato fermato per manutenzione ordinaria ed il sistema ancora attivo si è accollato il carico di entrambe (periodo di tempo ore 11-13).
Figura 4 Carico front end 1 Figura 5 Carico front end 2 Un parametro che l esperienza condotta ha dimostrato essere critico sui sistemi che adottano OpenLDAP è il numero di file descriptor (fd) aperti contemporaneamente per singolo utente (non root) che tipicamente in ambiente Linux è impostato a 1024. Tali fd includono oltre i file residenti su memoria di massa utilizzati nella base dati, anche i socket delle connessioni aperte dai client verso il servizio che in particolari occasioni (ad esempio attacchi DoS) possono facilmente saturare un benché alto limite impostato. La mancanza di fd disponibili comporta il blocco completo del servizio e, nell ipotesi di scritture nella base dati, la corruzione della stessa con perdita delle ultime informazioni immesse. I grafici seguenti rappresentano il numero di fd aperti su due front-end del sistema in produzione: la distribuzione del carico ad opera del load-balancer comporta il dimezzamento delle risorse necessarie conseguendo un margine operativo maggiore che mette al riparo da eventuali situazioni di carico anomale.
Figure 6-7 Andamento dei fd aperti 4. Conclusioni Dai test eseguiti e dalle misure di carico esibite, la soluzione proposta risponde agli obiettivi che ci si era prefissi. In particolare si può notare, come il sistema possa essere equipaggiato in modo da rispondere adeguatamente a picchi di carico elevati, con richieste in termini di risorse macchina (CPU, memoria) limitate ed un utilizzo della rete efficiente. Si può dunque ipotizzare che, utilizzando l architettura proposta, il sistemi scali in maniera quasi lineare con il numero dei server, permettendo di gestire un volume comunque alto di richieste. Sarà interessante, quale naturale evoluzione, verificare la nuova modalità MultiMaster della versione alpha di OpenLdap, che permetterà la realizzazione di cluster active/active al fine di rendere scalabile anche la parte master dell'architettura e verificare la possibilità di distribuire i servizi di frontend anche sui sistemi che in cluster HeartBeat sono in standby in modo da razionalizzare l uso delle risorse di calcolo ed aumentare le potenzialità complessive. 5. Riferimenti bibliografici [1] M. Wahl, T. Howes, and S. Kille, RFC 2251 : Lightweight directory access protocol, Dec 1997. [2] Kurt D. Zeilenga, Jong Hyuk Choi, LDAP Content Synchronization, IBM, April 2003 [3] C. Rigney, S. Willens, Remote Authentication Dial In User Service (RADIUS), Jun 2000 [4] FreeRADIUS, http://www.freeradius.org/ [5] The Linux Virtual Server Project, http://www.linuxvirtualserver.org/ [6] OpenLDAP 2.3 Administrator's Guide, http://www.openldap.org/doc/admin23/guide.pdf [7] Neil A. Wilson, SLAMD Distributed Load Generation Engine, neil.a.wilson@sun.com [8] Nagios, host and service monitor, http://nagios.org/