OpenLDAP l alternativa Open Source ai Directory Server commerciali

Transcript

1 l alternativa Open Source ai Directory Server commerciali Luca Scamoni Senior Consultant SysNet 14 Giugno 2011

2 History 1998: Nasce la Foundation RELEASE 1.0 (ago. 1998) Derivata da codice U-Mich (versione spartana senza features di sicurezza). In 6 mesi due release (1.1 & 1.2) con l aggiunta di password hashing e controllo di accesso (ACL) LDAPv2 compliant. RELEASE 2.0 (ago. 2000) LDAPv3 compliant Strong authentication (SASL, TLS). Extended Operations. Threading. Improved ACL. Software stabile e robusto ma

3 History Applica il paradigma tipico di LDAP (veloce in lettura e lento in scrittura). Motivo: l unico backend disponibile (LDBM), all epoca implementato tramite GDBM, un db engine con lock a livello file. Ciò nonostante, facciamo gestire alla soluzione il routing del traffico mail di oltre utenti del mondo Finance.

4 History RELEASE 2.1 (giu. 2002) Librerie Berkeley DB, oggi Oracle: lock a livello di pagina. Nuovo backend BDB. Migliori performance sia in lettura sia in scrittura; maggiore concorrenza nell accesso ai dati. Nuove ext-ops. Backend virtuali: meta, glue, monitor RELEASE 2.2 (dic. 2003) Migliore scalabilità. Meccanismo di replicazione basato su protocollo LDAPSync. Nuovo backend gerarchico HDB (move e rename di interi rami). Gestione contemporanea di più backend. Proxy-cache per le query LDAP.

5 History Nel 2004 inizia il refactoring. Nuovi concetti di modularità rendono più semplice sviluppare backend e overlay. Molte funzionalità embedded vengono rese modulari. Codice base più semplice. Aggiungere nuove features diventa più facile.

6 History RELEASE 2.3 (giu. 2005) Prima versione modulare. Viene introdotta la gestione della configurazione via protocollo (back-config). Password policy. LDAP Sync diventa il meccanismo di replicazione d elezione. SLURPD deprecato. RELEASE 2.4 (ott. 2007) Viene riscritto il dispatcher delle connessioni. Viene ottimizzato l allocatore di memoria. Nuovi overlays e backend. Nuove versioni delle librerie BerkeleyDB comportano performance ancora maggiori. Documentazione.

7 Cos è LDAP LDAP è un protocollo basato su standard internet consolidati che permette di comunicare con sistemi (DSA) che implementano o comprendono il modello X.500. I dati sono organizzati in maniera gerarchica. Esiste un unico DIT che può essere frazionato su più DSA in grado di comunicare tra di loro L unica forma di replicazione ammessa è la shadow copy (read-only).

8 Modello X.500 Un unico DIT suddiviso su più DSA (root) è un namingcontext fittizio Struttura gerarchica

9 Quali architetture? Modello di dati intrinsecamente distribuito Dati ridondati e distribuiti ATTENZIONE: non sempre i server possono essere raggiungibili Occorre pianificare con cura l architettura

10 Quali architetture? Directory locale. Approccio minimale. Gestione centralizzata. Prestazioni e disponibilità dati non cruciali. Directory integrato Grandi organizzazioni con politiche di gestione dati differenziate. Collegamento tramite referrals.

11 Quali architetture? Directory locale. Approccio minimale. Gestione centralizzata. Prestazioni e disponibilità dati non cruciali. Utilizzo di meta-directory o proxy Chaining

12 Quali architetture? Pool di DSA replicati Gestione centralizzata Esigenze di prestazioni o robustezza Repliche sincronizzate (copie shadow) Pool di DSA distribuiti. Più sistemi di Directory Server in replica vengono collegati attraverso referrals o meta-directory.

13 Quali architetture? Directory Federato Ogni DSA è master per una parte dei dati e replica di altri DSA per la restante parte. In caso di problemi di connettività, l operatività è solo parzialmente compromessa.

14 Modelli di replicazione Con il Protocollo LDAP Sync sono stati introdotti due modelli di replicazione: - Pull, il modello caratteristico del protocollo. Le repliche contattano il master a intervalli prefissati e chiedono le modifiche dall ultima sincronizzazione. - Push : le repliche contattano il master e aprono una connessione persistente. Dopo la prima sincronizzazione, ogni volta che il master riceve una modifica manda un segnale alle repliche che provvedono ad aggiornarsi.

15 Modelli di replicazione Modello di replicazione convergente. Non ci sono tempi garantiti ma lo stato di una replica convergerà sempre allo stato del master. Se una replica rimane troppo disallineata (problemi di connettività) il protocollo prevede i meccanismi per effettuare una sincronizzazione completa. È possibile aggiungere nuove repliche a caldo. Una replica con database vuoto si allinea automaticamente (scalabilità orizzontale).

16 E se la replica è dietro un Firewall? È sufficiente un istanza proxy (back-ldap). Il proxy inizia il processo di replicazione con il master ma il suo backend è la replica al di là del firewall. La connessione verso la replica è quindi sempre uscente.

17 Modelli di replicazione In ambienti con alta frequenza di scrittura si possono ottenere migliori performance serializzando le operazioni di update Modalità delta-sync: le singole operazioni di modifica vengono tracciate in un apposito database (accesslog) che viene interrogato dalle repliche per le operazioni di sync.

18 Multimaster Considerata come la soluzione di tutti i problemi, ogni istanza può accettare scritture e replicarla sulle altre. È implementato da vari Vendors con modalità (e performance) differenti. Pro: nessun Single Point Of Failure le istanze master possono essere ditribuite geograficamente failover automatico/high Availability

19 Multimaster Invalid: niente a che vedere con il bilanciamento di carico. una singola istanza può gestire migliaia di scritture al secondo. la necessità di replicazione incrociata aumenta il traffico sulla rete. il throughput di un architettura single master è superiore dato che si possono ottimizzare gli indici rispetto alle repliche (le istanze multimaster DEVONO avere configurazioni identiche).

20 Multimaster Contro: Non rispetta il modello X.500 (solo shadow copy ) e la garanzia di consistenza intrinseca ad esso. La replicazione a livello di entries può causare conflitti nel caso in cui un istanza resti separata molto a lungo dalle altre a causa di un frazionamento di rete. Problemi di riconciliazione delle entries in caso di disallineamento. ATTENZIONE: richiede stretta sincronia di clock

21 Backend & Overlays

22 Backend & Overlays Frontend, backend e overlays sono i 3 elementi fondamentali. Frontend elabora e decodifica il protocollo, applica le restrizioni e i controlli. Backend è lo storage fisico o virtuale dei dati. Overlays sono moduli di codice capaci di modificare on-the-fly richieste e risultati o di applicare features non previste dal modello standard.

23 Backends Back-bdb e back-hdb sono i backend standard. Sono basati su librerie Oracle BerkeleyDB. ACID compliant, semplici e veloci. Condividono il 90% del codice. Back-hdb utilizza un modello dati totalmente gerarchico e consente lo spostamento efficiente di interi rami dell albero LDAP. Centinaia di milioni di entries con volumi oltre 1TB e performance di decine di migliaia di query/sec.

24 Backends Back-ldap: proxy ldap in grado di rimappare le richieste verso un DSA remoto anche attraverso rewrite dei namingcontexts. Back-meta: estensione di back-ldap in grado di rimappare le richieste verso più DSA. Back-monitor: backend virtuale che consente di monitorare lo stato del DSA. Back-config: permette la gestione via protocollo LDAP dell intera configurazione del servizio. Rende possibili le modifiche senza restart del servizio.

25 Backends Back-ndb: sviluppato con la collaborazione di MySQL, si basa su architettura mysql-cluster. Fornisce accesso ldap ai dati contenuti in uno o più database (RDBMS). La replicazione è quella nativa mysql-cluster. Possibilità di agire sui dati sia via protocollo LDAP, sia attraverso SQL standard.

26 Overlays Accesslog intercetta le singole operazioni di scrittura e le memorizza in un backend che può essere interrogato via LDAP. Auditlog memorizza tutte le modifiche su un file. Chain permette a un DSA di seguire i referrals al posto del client. In questo modo un insieme di DSA distribuiti può apparire come un unico DSA. Constraint consente di definire delle regole di validità sui dati contenuti negli attributi del directory server. Dynamic List permette l espansione di gruppi dinamici attraverso l uso di query ldap interne. memberof, integrità referenziale di Microsoft-iana memoria.

27 Overlays Proxy-cache implementa una cache locale dei risultati delle query ldap (in congiunzione con back-ldap/meta). Password policy implementa una I-D per la gestione in-directory delle password con gestione delle durate, delle complessità, lockout, ecc. Referential Integrity permette l integrità referenziale a fronte di move o cancellazioni di entries (il modello X.500 non lo prevede). Rewrite/Remap consente di manipolare DN/dati e il mapping di ObjectClass/attributeTypes. Spesso utilizzato in ambienti misti per fornire viste unificate di dati distribuiti e difformi. Translucent integra dati provenienti da DSA remoti con dati locali.

28 Use cases 2001: SysNet viene incaricata di trovare una soluzione alla gestione del delivery della posta elettronica in vista della fusione di 3 dei principali Istituti Bancari dell epoca. La soluzione avrebbe dovuto: - garantire il routing corretto delle mail verso i 3 domini esistenti e il nuovo dominio unificato - avere impatto zero sulla configurazione dei sistemi di posta esistenti - essere flessibile e consentire di integrarsi con eventuali nuovi domini.

29 Use cases Nasce il Mailhub: una soluzione basata su sendmail e che permette di assegnare ad ogni utente dei diversi domini, un indirizzo mail unificato e univoco, noto solo al Mailhub che continua a fare delivery delle mail alle mailbox esistenti ma riscrive tutti i messaggi in uscita con il nuovo indirizzo. Un processo notturno tiene allineati con i sistemi di posta (per nuovi utenti o dismissioni).

30 Use cases 2002: al termine della fusione, il dominio unificato cambia, tutto nell arco di una notte con downtime di 0 sec. Alcuni anni più tardi una nuova fusione; vengono superati 100k utenti e occorre mantenere sincronizzate le GAL. INDOVINATE

31 Use cases 2006: un grosso provider di telecomunicazione mobile aveva l esigenza di fornire un punto di accesso centralizzato ai dati di 30M di utenti distribuiti su oltre 100 DSA con tempi di risposta nell ordine dei ms. Idea chiave: il proxy deve utilizzare tutta la conoscenza possibile sulla localizzazione del dato cercato per: Massimizzare le performance di ricerca Minimizzare il traffico di rete

32 Use cases (2.3) ha già tutti gli ingredienti: back-ldap è ideale quando si conosce il target back-meta è ideale quando non lo si conosce La soluzione: un overlay che analizzi le richieste e cerchi di individuare il target. trovato? usa back-ldap non trovato? usa back-meta E fa molto di più

33 Use cases Intercetta e analizza le richieste. È costruito su back-meta, contiene una copia privata di back-ldap per ciascun target, più un istanza back-meta per tutti i target. Cache delle informazioni sulla posizione dei dati. Intelligenza configurabile su come localizzare le informazioni in base alle richieste. Gestione speciale delle operazioni di bind e write Circa righe di codice.

34 Use cases 2007: una Certification Authority espone via LDAP certificati, CA e CRL attraverso una infrastruttura composta da un interfaccia home-made e un SunOne DS. La soluzione home-made non è più gestibile in termini di know-how; si tratta di molte migliaia di entry di dimensioni variabili da pochi Kb a molti Mb. Si potrebbe migrare tutti i dati direttamente su SunOne. Ma ci sono costi da sostenere

35 Use cases La risposta è la migrazione della soluzione home-made su standard. Un metadirectory consente di interrogare le due implementazioni ( e Sun) in maniera trasparente. Ma perché fermarsi qui Con un Overlay che intercetta le scritture dal sistema di provisioning e le propaga a due target differenti ( e Sun) si migra l intero contenuto di SunOne su garantendo un transitorio sicuro e a prova di rollback.

36 E domani? 2.4 ha già 4 anni, rispetto al passato è molto Tanto lavoro al contorno: Documentazione Migrazione del sistema di versioning Nuovo request tracker Ma lo sviluppo della 2.5 è già iniziato

37 E domani? Gestione dinamica di nuove sintassi (attualmente codificate) attraverso linguaggio forth. Maggiore flessibilità nella gestione dinamica della configurazione (backconfig). Nuovo backend memory-based (back-mdb?). Transazioni LDAP (RFC5805).

38 l alternativa Open Source ai Directory Server commerciali Grazie Per rivedere questa presentazione: