OpenLdap Monitoring Guide HowTo
From ImoLUGPedia
L'implementazione open source di LDAP (OpenLDAP) è un software estremamente robusto e performante anche su server poco “dotati” dal punto di vista delle risorse hardware. Nell'azienda dove lavoro utilizziamo con soddisfazione un cluster LDAP a due nodi paritetici con replicazione tra primario e secondario tramite il demone Slurpd (Standalone LDAP Update Replication Daemon). Il nostro cluster gestisce l'autenticazione SSH, Webmin e DB2 di decine di server AIX/Linux di test, validazione e produzione. Vengono fatte giornalmente decine di migliaia di operazioni di Bind e milioni di Search. Da amministratore di questo sistema sono sempre stato interessato a tutti i possibili modi per renderlo veramente efficiente in modo da poterne sfruttare appieno le potenzialità e soprattutto per mantenere sempre alto il livello di servizio all'aumentare del carico di lavoro. Un'aspetto che però non avevo mai affrontato fino a poche settimane fa è quello del monitoring del servizio stesso. Vi siete mai chiesti per esempio se e come sia possibile tenere sotto controllo il numero di bind/search fatte in una certa unità di tempo? O capire in quale momento della giornata il vostro LDAP è maggiormente utilizzato e dai chi, o il numero di search fatte in una giornata, o il numero di add/modify/delete , il numero di connessioni, ecc...? E' sicuramente possibile utilizzare un livello di logging sufficiente ai nostri scopi (ricordo che si va da 0 a 256 ovvero dal livello meno “verboso” al più dettagliato) e predisporre degli script per l'analisi di tale log e l'estrazione delle informazioni che ci interessano. Si tratta però di un metodo poco elegante e performante, soprattutto se stiamo lavorando in un sistema di produzione con log al massimo dettaglio per motivi di Policy di Sicurezza e quindi di dimensioni che possono raggiungere anche diversi GB ogni giorno!!
Fortunatamente lo stesso OpenLDAP ci mette a disposizione un sistema nativo molto efficiente per il monitoring del suo livello di servizio. Per abilitarlo è sufficiente aggiungere nel file di configurazione “slapd.conf” la seguente direttiva:
database monitor
A dispetto di quanto possa sembrare non stiamo creando un nuovo database gestito dal nostro backend (ad esempio il Berkeley DB) ma di un database interno che verrà creato alla partenza dell'LDAP e da esso automaticamente gestito. Come riportato nel manuale di amministrazione è necessario che anche le seguenti direttive siano presenti (ovviamente i percorsi sono da controllare):
include ./schema/core.schema
modulepath /usr/local/libexec/openldap moduleload back_monitor.la
Si tratta sostanzialmente di caricare il modulo necessario a rendere operativo il nostro database monitor e la sua gestione dinamica.
A questo punto sarà sufficiente riavviare LDAP per avere a disposizione una serie di informazioni molto interessanti (al momento l'unico modo che mi è noto per azzerare tali statistiche è il riavvio di LDAP stesso).
Vi state chiedendo come accedere a tali informazioni?
Semplice, tramite una serie di search all'interno di un nuovo ramo così definito:
cn=Monitor
Possiamo definirlo un ramo “fittizio” nel senso che non lo vedrete apparire nella struttura ad albero del vostro LDAP. E' e rimane una struttura dinamica interna e quindi non memorizzata nel vostro backend database principale. Naturalmente è possibile mappare il database su un DN differente e impostare una password, il tutto con le seguenti direttive (ad esempio):
rootdn "cn=monitoring,cn=Monitor" rootpw monitoring
Suggerisco di applicare delle regole d'accesso, non vorrete mica rendere disponibili a tutti queste informazioni? Ad esempio:
access to dn.subtree="cn=Monitor" by dn.exact="cn=Manager,dc=example,dc=it" by * none
Ma veniamo alla parte interessante, l'accesso alle statistiche di servizio del nostro LDAP. Proviamo ad esempio a intorrogare il nodo principale e vediamo cosa otteniamo:
ldap01:~ # ldapsearch -x -b "cn=Monitor" -D "cn=Manager,dc=lancse,dc=csebo.it" -w <password di Manager> -s base '+' # extended LDIF # # LDAPv3 # base <cn=Monitor> with scope base # filter: (objectclass=*) # requesting: + #
# Monitor dn: cn=Monitor structuralObjectClass: monitorServer creatorsName: modifiersName: createTimestamp: 20090219141845Z modifyTimestamp: 20090219141845Z monitoredInfo: OpenLDAP: slapd 2.3.32 (Feb 9 2007 09:19:52) entryDN: cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
Si tratta semplicemente della descrizione del nodo "Monitor" con alcune informazioni sulla data di creazione del nodo stesso, la versione di openLDAP e poco altro. Le informazioni più utili le troviamo invece nei seguenti nodi:
cn=Databases,cn=Monitor cn=Listeners,cn=Monitor cn=Overlays,cn=Monitor cn=Statistics,cn=Monitor cn=Threads,cn=Monitor cn=Time,cn=Monitor cn=Waiters,cn=Monitor
Vi rimando al manuale di amministrazione di openLDAP per una descrizione (purtroppo non molto dettagliata) di questi nodi. Le informazioni che personalmente ho trovato più interessanti sono il numero di connessioni al server LDAP, il numero di operazioni di Bind, Unbind, Add, Delete, Modify e Search. Ecco le relative search:
ldapsearch -x -b "cn=Total,cn=Connections,cn=Monitor" -D "cn=Manager,dc=lancse,dc=csebo.it" -w <password di Manager> -s base '+' ldapsearch -x -b "cn=Bind,cn=Operations,cn=Monitor" -D "cn=Manager,dc=lancse,dc=csebo.it" -w <password di Manager> -s base '+' ldapsearch -x -b "cn=Unbind,cn=Operations,cn=Monitor" -D "cn=Manager,dc=lancse,dc=csebo.it" -w <password di Manager> -s base '+' ldapsearch -x -b "cn=Add,cn=Operations,cn=Monitor" -D "cn=Manager,dc=lancse,dc=csebo.it" -w <password di Manager> -s base '+' ldapsearch -x -b "cn=Delete,cn=Operations,cn=Monitor" -D "cn=Manager,dc=lancse,dc=csebo.it" -w <password di Manager> -s base '+' ldapsearch -x -b "cn=Modify,cn=Operations,cn=Monitor" -D "cn=Manager,dc=lancse,dc=csebo.it" -w <password di Manager> -s base '+' ldapsearch -x -b "cn=Search,cn=Operations,cn=Monitor" -D "cn=Manager,dc=lancse,dc=csebo.it" -w <password di Manager> -s base '+'
Nel caso delle operazioni di search l'output è il seguente:
# extended LDIF # # LDAPv3 # base <cn=Search,cn=Operations,cn=Monitor> with scope base # filter: (objectclass=*) # requesting: + #
# Search, Operations, Monitor dn: cn=Search,cn=Operations,cn=Monitor structuralObjectClass: monitorOperation monitorOpInitiated: 22178911 monitorOpCompleted: 22178910 creatorsName: modifiersName: createTimestamp: 20090219141845Z modifyTimestamp: 20090219141845Z entryDN: cn=Search,cn=Operations,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: FALSE
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
In questo specifico caso vediamo che l'LDAP ha gestito 2 Milioni abbondanti di search dal 19 Febbrario 2009. Ovviamente risulta molto facile filtrare un'output di questo tipo e fare dei check (ad esempio in Big Brother) per graficare l'andamento di queste operazioni fondamentali. Guardiamo qualche esempio del cluster della mia azienda:
Quello che si evince da questo grafico è che durante la notte aumentano le operazioni di search fatte al nostro LDAP. Ciò è dovuto ai batch notturni che girano sui vari server DB2. E' un comportamento che ci aspettavamo ma che è bello poter verificare con questi strumenti!! ;-)
Vediamo invece le operazioni di Bind:
Anche nel caso delle bind possiamo notare la presenza di alcuni picchi, anche durante la giornata. Il comportamento è incostante rispetto alle search perchè è variabile il numero di client che fanno operazioni di bind.
Come è giusto aspettarsi da un servizio di Directory ecco il numero limitato di add richieste al sistema: (ci sono dei picchi di operazioni di Add dovute a script che girano costantemente e che controllano quali utenze hanno password più vecchie di 42 giorni e le disabilitano oltre che attivare quelle scadute e per le quali è stata cambiata la password negli ultimi 5 minuti)
Il grafico delle connessioni aperte verso il Server LDAP è praticamente costante, guardiamolo:
Questo comportamento è facilmente spiegabile dai client che tendono a tenere aperte le connessioni verso il server fino a quando vengono fatte operazioni di qualche tipo. I picchi discendenti non sono altro che riavvii del server.
Grazie a questo metodo nativo di OpenLDAP per il monitoring di servizio è stato possibile verificare alcuni andamenti che sospettavamo, ma cosa ancora più importante ci è ora possibile avere un metodo affidabile per capire in quali situazioni aumenta il carico richiesto al server e in corrispondenza di quali eventi.
