lunedì 21 luglio 2014

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).


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



martedì 1 luglio 2014

Sette in un sol colpo!

Chi si ricorda il prode piccolo sarto, che per aver scritto che ne aveva abbattuti "Sette in un sol colpo!" - riferendosi alle mosche e non ai giganti - fu chiamato ad affrontare quelli che infestavano il suo regno?!?

Il punto è che quando ci sono degli annunci interessanti si finisce sempre per volerlo dire nel modo più diretto ed incisivo!!!

E io volevo segnalare un'iniziativa di Packt Publishing , per i loro 10 anni: tutti gli ebook ed i video a 10$ fino al 5 luglio!

Maggiori informazioni le potete trovare qui

personalmente la mia top 7 è questa:

Mastering Web Application Development with AngularJS
Node.js Blueprints
Practical Data Analysis
Data Visualization with D3.js Cookbook
Prezi HOTSHOT
Node Cookbook: Second Edition
Heroku Cloud Application Development

Buona lettura a tutti!!!

mercoledì 25 giugno 2014

I programmatori non scalano!

Lunedì scorso , all' Html5 code show, per la prima volta mi è capitato di essere chiamato in causa come componente di una "casta".

L'originale oratore ha spesso chiesto,  sottolineando con tono di stupore, se davvero fossimo tutti programmatori, quasi che vederne tanti tutti assieme fosse uno spettacolo più unico che raro.

Ora chi legge queste righe probabilmente avrà già iniziato a commentare sull'assurdita' di tale affermazione,  ma il vivo stupore con cui ci guardava e ci sentiva parlare mi ha spinto a sforzarmi di vedere la cosa da un altro punto di vista.

Ma noi programmattori siamo una casta?

In effetti io sono uno di quelli che pensa che per essere un buon (analista) programmatore  serve una certa forma mentis e tanta passione,  e la conoscenza dei linguaggio  da sola non ti porta oltre l'essere in buon coder.

Però il discorso che il nostro ospite stava facendo, in alcuni momento piu che dipingerci come tanti piccoli nerd intenti a modificare codici,  ci aveva trasformato in idraulici che ti rifilano i pezzi usati di qualche altro cliente.

Ora io sono il primo a dire che siamo 'artigiani', perche i  codici hanno sempre un minimo di arte, ma quel discorso mi ha fatto sorridere (e mi ha anche un po irritato)

"Voglio imparare a programmare così non mi fregano più!"

In questi giorni a casa stanno rifacendo le guaine del terrazzo. Li ho osservati.... so spaccare le mattonelle? Si ( e magari mi faccio male). Posso tenere il cannello per sciogliere la guaina? Si, è come minimo mi brucio e spargo catrame ovunque. Morale.... non posso rifarmi il terrazzo... ma neanche dare una mano, se prima non passo mesi o anni ad imparare dagli errori miei e degli altri.

Facciamo un lavoro difficile, ma che spesso non sappiamo valorizzare.

E come casta non valiamo molto, se uno (magari pure ultra cinquantenne) fresco di tutorial si definisce "programmatore".

D'altronde siamo per natura solitari.... e questa credo sia il nostro più grande limite... non scaliamo :) 

sabato 22 marzo 2014

MogoID: l'alternativa di ActiveRecord per il mondo NoSQL



Qualche tempo fa avevo scritto alcune righe sul mondo NoSQL ed in particolare si Mongo , dopo la lettura di "Instant MongoDB" ( http://bit.ly/17RQbZ7 ), notando però la mancanza di 
riferimenti a driver e o gemme specifiche

Be, i signori di Packt mi hanno gentilmente segnalato un altro titolo,  "Learning MongoID" di Gutam Rege pubblicato da poco (per chi volesse lo trova qui: 14 euro spesi bene! http://bit.ly/1dfRK2c

Ad ogni modo, il libro ripercorre tutte le fasi e i passi necessari per l'utilizzo di Mongo tramite la gemma MongoID.

Per chi già conosce Rails e Rails 4 in particolare .... be i primi capitoli sembrerebbero da saltare, ma invece è importante leggerli, anche se velocemente: dal requisito fondamentale di "scollegare" le gemme di ActiveRecord alla definizioni delle classi che utilizzano Mongo al primo approccio con le istruzioni MOPED in sostituzione delle classiche chiamate SQL di ActiveRecord, ed anche la scelta di introdurre concetti come la serializzazione e l'utilizzo di Set o addirittura di classi complesse (serializzandola) rende la lettura ricca di spunti interessanti anche per programmatori più esperti

Il libro scorre velocemente, con un inglese tecnico semplice da comprendere e tradurre e pochi punti che richiedono l'ausilio dell'amato / odiato google traslate :)

Interessanti sono i riferimenti dovuti ad Origin (la gemma che fornisce il supporto alle query per Mongo con un suo DSL) , alle modalità di gestione del journaling , della gestione della cache e delle cancellazioni, così come alla gestione del lock ed al supporto per transazioni (ricordando comunque che , per definizione, un sistema NoSQL non è "transazionale" nell'accezione che se ne fa nel modo SQL)

Nei primi capitoli il testo copre tutti gli aspetti salienti per una modellazione: i differenti metodi di relazione, la differenza tra related document ed embedded document,  le differenti modalità di ricerca, creazione (date un'occhiata al metodo upsert) ed aggiornamento, anche atomico, dei dati.

Si parla anche della gestione degli attributi dinamici... caratteristica di per se semplice da immaginare per un ambiente NoSQL, ma decisamente interessante per chi proviene dal mondo relazionale... gli avrei dedicato qualche attenzione in più!

Tutto il quarto capitolo è sulla gestione delle relazioni. In effetti è un po lungo, e rischia di essere ripetitivo, ma di fatto così è anche un'ottima referenza per comprendere meglio le opzioni di default e gestire le variazioni.

Il Quinto capitolo affronta il mondo di Origin e delle modalità di interrogazione: un argomento fondamentale, per capire appieno le potenzialità di un sistema come Mongo anche per le sue caratteristiche geo-spaziali.

C'è invece da prestare attenzione al capitolo 6 - Performace Tuninig.
Francamente lo avrei diviso... premesso che le performance sono fondamentali per ogni progetto, questo capitolo va a toccare argomenti che vanno dagli indici e monitoring del Mongo , al sistema di aggregazione alle funzioni Map / Reduce: questi ultimi due a mio parere meritavano un capitolo ad-hoc.

Fondamentale, per poter iniziare un progetto con il piede giusto, l'ultimo capitolo, che illustra i vari moduli di MongoID e le gemme (principali) ad oggi utilizzabili e compatibili con questo sistema: aasm , audit , devise .
Magari qualche piccolo esempio sarebbe stato apprezzato.


Quindi che dire... se volete iniziare ad utilizzare Mongo... un ottimo testo per avere a portata di mano tutte le referenze che servono!

----------------------------------
Un ultimo aggiornamento... E' in corso una campagna di Pactk (http://bit.ly/1j26nPN . ) per i loro 2000mo ebook: uno ne compri e uno te ne regalano.... se vi serviva un buon motivo, eccolo!!