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

Posta Elettronica, Quote e de-duplica degli allegati

#### UPDATE 09-09-2013 ####
I primi risultati di un progetto di abilitazione del DAOS in ambito Enterprise qui
####

Per chi gestisce i sistemi di posta elettronica, l'applicazione delle quote alle caselle di posta è da sempre un motivo di scontro.
Se da un lato il sistemista la eleva ad unica possibilità di evitare catastrofi inenarrabili sui sistemi di posta, enumerando tutti i vantaggi che una soluzione del genere comporta, dall'altro chi usufruisce del servizio trova troppo comodo ed insostituibile ( e direi innegabilmente - nda)  usare la casella di posta come unico immenso archivio, documentale e non.
Chi ha ragione?
La risposta più ovvia (e più odiosa) è "dipende".... In particolare dipende infatti da 2 fattori, indipendenti tra di loro :

1. il livello del servizio che si sta offrendo
2. la "cultura informatica" degli utilizzatori

Se si sta offrendo un servizio premium, viene da se che è impossibile pensare di dare una "quota". Alcuni anni fa, cercando alternative al servizio GMail offerto da Google, mi sono reso conto di quanto BigG ci abbia abituato "male", di fatto eliminando il concetto della quota.
Ma come è possibile proporre ai propri utenti - e non solo a quelli "top" - questi livelli di servizio senza dover disporre di  PetaByte di archivi?

La gestione degli allegati
Tipicamente il problema dello storage è legato allo spazio occupato dall'intera casella, tralasciando il peso di ogni singolo messaggio.
Tipicamente la posta elettronica vede 1 messaggio inviato ad N destinatari, con successivi passaggi di risposte ed inoltri.

Questo flusso può essere ottimizzato se analizziamo la composizione del messaggio:

Ogni utente tipicamente inoltra gli allegati e risponde con una parte degli allegati originali. Sostituendo gli allegati con dei link otteniamo:

L'ottimizzazione è evidente, sia in termini di spazio occupato che di numero di file gestiti.

L'utilizzo delle funzioni di deduplica in un mailserver hanno un vantaggio rispetto ad applicare questa tecnologia per lo storage classico: gli allegati dei messaggi di posta sono in sola lettura, e pertanto non ci si dovrà preoccupare di delta, di confronto di blocchi o altro. Calcolato l'hash dell'allegato occorre solo verificare o meno la presenza del file.
La complessità inserita è quella di registrare correttamente i collegamenti tra file fisici (che possono poi essere ulteriormente compressi dal sistema di storage) e messaggi di posta.

Domino, SSO e ottimizzazione delle risorse

Utilizzando una infrastruttura di server domino è molto semplice attivare un SSO tra i server.

Se poi abbiamo i sistemi in replica ecco che l'alta affidabilità è assicurata.

Potrebbe però capitare che gli utenti tendano ad utilizzare principalmente un server (tipicamente il più "anziano") invece che il proprio server di riferiemento.

in tal caso questo piccolo script, da inserire ad esempio nell'init() di una pagina XPages, reindirizza correttamente l'utente alla corretta URL

      print("####### START REDIRECT TO MAILSERVER");

      var mailserver = new String(@DbLookup("names.nsf","($users)", context.getUser().getFullName(), "MailServer"));

      print("#######" + mailserver);

      print("#######" + session.getServerName());

      if (session.getServerName().compareToIgnoreCase(mailserver) == 0 )

            {

            print("####### NO REDIRECT TO ");

           

            }

      else

            {

            var fnqmailserver = @DbLookup("names.nsf","($servers)", mailserver, "SMTPFullHostDomain");

            print("####### REDIRECT TO " + fnqmailserver);

            externalCtx = facesContext.getExternalContext();

            externalCtx.redirect("https://"+fnqmailserver);

            }

      print("####### END REDIRECT");