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
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
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).
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
L'esperienza aveva evidenziato dei limiti oltre cui il server non riusciva ad erogare correttamente i servizi IMAP ed SMTP.
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