Monitoring Domino ... my Ruby Way

Da alcuni mesi un cliente mi ha affidato un progetto che prevede il monitoring "attivo" di una serie di Server Lotus Domino , provenienti da una versione 6 tramite successivi upgrade e che vengono acceduti principalmente (se non esclusivamente ) tramite IMAP, promuovendo tutte le attività necessarie per garantire la stabilità del server ma anche evidenziando statistiche d'uso ed eventuali anomalie (come ad esempio mail bombing o tentativi di accesso non autorizzati).

Con i committenti si è deciso di implementare delle azioni correttive volte a garantire la stabilità e l'affidabilità dei sistemi da un lato e migliorarne l'efficenza e la risposta dall'altro.

Da un lato si è operato sulla stabilità del server Domino principale, definendone un secondo su cui generare i nuovi utenti e trasferire parte di quelli presenti.

Dall'altro si è predisposto un ambiete di monitoring in grado di identificare in tempo reale gli andamenti del sistema e fornire una console unica sui server

Per il monitoring e la manutenzione ordinaria sono stati predisposti una serie di script di amministrazione ( di cui una parte in Ruby), nonchè un'interfaccia di analisi dei log unificata per i vari server del cliente e che evidenziasse andameti e l'approssimarsi di criticita

Prima versione

Seconda Versione

Il quadro generale

Premessa obbligatoria è ricordare che i sistemi Lotus non sono solo server di Posta, ma offrono l'intero stack aplicativo, e questo, a volte, è questo credo sia un loro pregio e difetto.

Primo perchè molte delle soluzioni di monitoring esistenti sono applicazioni commerciali, in quanto l'integrazione con le componenti base del Domino va fatta utilizzando delle API in C ed è una operazione complessa, laboriosa e quindi poche (o nessuna) di queste soluzioni sono gratuite o ad un costo "abbordabile"

Secondo perchè le soluzioni che prevedono un'integrazione nativa con il notes possono causare esse stesse l'instabilità del sistema, e comunque funzionano fintanto i sistemi domino funzionano.

Inoltre, per questo specifico progetto, i vincoli di budget (0) non erano i soli: la tipologia e la dimensione dell'infrastruttura che si era venuta a creare nel tempo non permetteva di applicare alcune delle "Best Practices" (come implementare di  un cluster o la suddivisione dei servizi) o di effettuare monitoring con prodotti terzi

- 2 Domini non in trust fra loro
- 2 server Domino
- 2 sistemi di mail-relay terzo che funge da SMTP relay da e verso internet
- integrazione con un server Zimbra, sullo stesso dominio internet
- SO Solaris (non supportato l'aggiornamento alla 9). Gli agent SNMP presenti non sono compatibili con il la versione richiesta dal Domino e non sono aggiornabili
- Livelli di SLA con servizio garantito al 99.9%
- Nessuna quota sui DB di posta (ma possibilità di effettuare archiviazione sulla base di policy temporali)

I server Domino gestiscono circa 5000 caselle, che generano quotidianamente circa 10 Gb di traffico e 150.000 messaggi scambaiti , con un dimensione complessiva dei file NSF di oltre 8 TeraByte

Gli interventi

DAOS
E' stato abilitato il DAOS per ridurre la dimensione del filesystem ed ottimizzare le operazioni di manutenzione e le prestazioni del filesystem della macchina (in particolare ridurre l'accesso al disco e le contese sugli accessi).

Implementazione DAOS in ambienti enterprise from Luca Arcara

politica di archiviazione proattiva
sono stati predisposti degli script ruby che identificano i database più numerosi tramite l'utilizzo del catalog (in termini di documenti e peso) e tengono traccia delle ultime archiviazioni eseguite, così da rendere il più efficiente possibile la policy di archiviazione presente (180gg)

ottimizzazione dell''utilizzo delle risorse da parte del servizio Domino
 attivazione dei parametri

• NSF_DbCache_Maxentries
• NSF_Buffer_Pool_Size_MB
• CREATE_R85_DATABASES
• DAOSEnable
• Namelookup_max_mb
• view_rebuild_dir
• EVENT_POOL_SIZE
• MailFileDisableCompactAbort
• UPDATE_FULLTEXT_THREAD
• FTUPDATE_IDLE_TIME
• Debug_Show_Timeout
• DEBUG_CAPTURE_TIMEOUT

definizione degli alert e dei probe sullo stato del server / transaction log.

L'esperienza aveva evidenziato dei limiti  oltre cui il server non riusciva ad erogare correttamente i servizi IMAP ed SMTP.

In particolare nei casi in cui venivano aperte oltre 1000 sessioni IMAP contemporanee (in SSL)  si notavano bocchi del sistema e un utilizzo oltre i limiti del transaction Log (4GB).
Sono stati perciò predisposti degli alert automatici tramite probe sui parametri :

• IMAP.Sessions.Inbound.Active
• IMAP.Sessions.Threads.Busy
• Database.RM.Current.K.Restart.Redo.Hold
• Database.RM.Current.K.UnCommited.Undo.Hold