una possibile soluzione opensource per un servizio di

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”, [email protected]
[8] “Nagios, host and service monitor”, http://nagios.org/