En3pY :: Sebastian Zdrojewski

Business partner is a term used to denote a commercial entity with which another commercial entity has some form of alliance. This relationship may be a highly contractual, exclusive bond in which both entities commit not to ally with third parties. Alternatively, it may be a very loose arrangement designed largely to impress customers and competitors with the size of the network the business partners belong to.

Questa e’ la definizione che Wikipedia da al termine “Business Parnter”, ormai di comune utilizzo e spesso abusato, almeno per come vedo io l’idea di “partner”.

Chi e’ un Business Partner?

Un Business Partner puo’ essere un fornitore, un cliente, un agente o rivenditore, oppure un vendor di prodotti complementari (per esempio, una parte che si occupa della vendita di software ed una che si occupa della vendita di hardware). Quello che, purtroppo, vedo e vivo e’ l’abbinamento del termine “Business Partner” come sinonimo di “Fornitore”. Spesso infatti mi e’ capitato di vivere (e vedere in altri ambiti) un BP che si presenta per vendere dei prodotti (software o hardware che sia) ad una realta’. Non sarebbe bello, invece, che il Business Partner fosse piu’ una figura che aiuta il cliente a migliorare e fare piu’ business? Ne’ piu’ ne’ meno come accade con delle societa’ di consulenza finanziaria, se un BP aiuta un Cliente a crescere in maniera razionale? Lo scoglio piu’ grande probabilmente e’ che questo tipo di “filosofia” e’ un investimento a lungo termine.

La mia visione di Business Partner, ed e’ anche l’ottica con cui mi piace presentarmi sui Clienti, e’ quella di affiancare l’azienda con delle competenze di un certo livello, finalizzate unicamente al migliorare la produttivita’ del Cliente. Ritengo che aziende che si adattino a questo tipo di mentalita’ siano estremamente poche, forse perche’ le prospettive piu’ importanti per le divisioni commerciali sono proprio quelle di aumentare le vendite senza troppo considerare le effettive esigenze di un Cliente, o le eventuali difficolta’ fisiologiche che un ufficio acquisti o un responsabile IT puo’ riscontrare nell’acquistare del hardware. Prendiamo un’azienda che non ha personale tecnico qualificato al suo interno per fare delle decisioni strategiche (a medio/lungo termine) in ambito informatico. Andrebbe a crearsi un meccanismo tale per cui il “BP” (che si afferma tale) continua a vendere del hardware alla societa’ committente che magari e’ sovradimensionato (e’ capitato anche a me di recente, cosa che mi ha fatto rivisitare un po’ le politiche di acquisto) ma che non risponde alle reali esigenze dell’azienda in cui andra’ collocato. Oppure ancora, del hardware economico ma che nell’arco di breve tempo si scopre essere un collo di bottiglia, frenando cosi’ (laddove addirittura non crei danno economico) all’azienda. Dove sta il punto di equilibrio allora?

Il Business Partner deve capire quando offrire cosa. L’unico modo che ha e’ diventare una “divisione” distaccata del committente dei propri Clienti. Il paradigma di “Business Partner” cambierebbe dai sopra menzionati “fornitori” o “agente” il cui fine e’ quello di vendere prodotti ad un nuovo significato, piu’ idoneo, di societa’ che ha una missione comune, ossia quello di incrementare la produttivita’ e la qualita’ operativa del Cliente. La filosofia del BP diverrebbe quindi “io miglioro la qualita’ del lavoro del mio Cliente”, con ritorni economici ovviamente proporzionali al successo che il BP ottiene nel proprio ruolo di consulente e consigliere (forse la difficolta’ di riuscire ad adottare questa filosofia e’ legata proprio a quest ultimo punto?)

Visitare i datacenter di societa’ come i.Net (ma anche qualsiasi altro) e’ sempre un evento molto costruttivo. Ti fa capire le dinamiche economiche, politiche e tecniche che si celano dietro alla realizzazione di un datacenter (o di una Business Factory come la definiscono i signori del gruppo BT). Devo dire che il datacenter di i.Net e’ un gioiello tecnologico. Il giro fatto oggi all’evento ci ha consentito di andare a vedere sia le strutture dei servizi generali (condizionamento, generazione elettrica) che i locali di outsourcing veri e propri. La spiegazione di gran parte delle problematiche e’ stata in alcuni punti illuminante, mentre altre hanno confermato che il progetto datacenter (naturalmente non lontanamente paragonabile a quello di i.Net) che stiamo sviluppando e mettendo in atto presso la nostra realta’ e’ perfettamente in linea con gli standard dei datacenter piu’ evoluti.

E’ un periodo che continuo a “giocare” con le Storage Area Network. Ad inizio anno abbiamo installato il DS4700 di IBM: 7 dischi da 500Gb SATA per il Gruppo Editoriale. A febbraio gestiva solamente l’archivio delle edizioni dei giornali (giusto quei 400Gb di dati), oggi e’ stata affiancata da due switch F.C. a 16 porte e lo storage conta 16 dischi misti SATA e SAS. Devo dire che tra tutte le soluzioni storage basate su Fibre Channel il DS4700 e’ quello che mi da le soddisfazioni piu’ grandi sia come qualita’ del hardware, sia come prestazioni (anche se oggi e’ piuttosto sottoutilizzata). Un progetto a medio/lungo termine che sto cercando di portare avanti prevede l’utilizzo di questo storage (ovviamente tutto 4Gbps con doppi percorsi) per mettere in piedi un cluster active/standby per il database di Tera (il sistema editoriale del Gruppo) che altri non e’ che un SQL Server. Ma questa e’ un’altra battaglia.

Il DS4700 secondo benchmark ufficiali e’ uno storage che offre performance di fascia alta a prezzi non eccessivi (~ 40KEUR). Supporta dischi SAS F.C. a 4Gbps e SATA (chiamati da IBM Fiber - ATA) da 3GBps con capacita’ fino a 750Gb che possono essere contenute all’interno dello stesso enclosure grazie all’opzione “Intermix”. Come da capitolato di IBM, lo storage ha delle licenze per le “partizioni” (ossia le macchine che accedono allo storage) e per le funzioni addizionali (sistemi Microsoft Windows, sistemi Linux, sistemi Solaris, ecc.). Le altre opzioni degne di massima considerazione sono FlashCopy per istantanee del filesystem nonche’ Intellimirror (se non erro) per la replica dello storage finalizzata al Disaster Recovery. Il sistema e’ equipaggiato con controller da 2Gb di cache (nel nostro caso) interamente ridondato. Degno di nota il fatto che il enclosure consente di contenere fino a 16 dischi, a differenza dei 12 normalmente contenuti in altri sistemi storage visti in giro. Anche l’architettura interna e’ degna di considerazione: ogni disco ha un percorso di accesso dedicato (ovviamente ridondante) dal controller, a differenza delle altre soluzioni storage F.C. che hanno una topologia di accesso ai dischi ad anello, che rallente le operazioni di I/O.

Il DS4700 e’ stato il progenitore delle SAN e delle infrastrutture F.C. all’interno del nostro datacenter. Settimana scorsa e’ arrivata un altro storage F.C., di Sun Microsystems, appunto per il sistema gestionale. Il bello di avere un’infrastruttura F.C. in casa e’ che si entra in una fascia di servizi di livello decisamente superiore (e una corrente filosofica di gestione dello storage totalmente diversa). Il nuovo storage di Sun e’ stato inglobato nell’infrastruttura F.C. del Gruppo Editoriale, manovra che ha consentito di risparmiare una somma non indifferente sugli switch necessari per il suo corretto funzionamento (parliamo di cifre che si aggirano sui 15KEUR per due switch in fibra nuovi), e consentendo di avere in casa un sistema active/standby di indubbia qualita’ per termini di performance ed affidabilita’. Sull’architettura e benchmark di questa macchina non ho nessun tipo di informazione (ancora) perche’ e’ una scatola chiusa installataci dagli uomini del gestionale, ma e’ solo questione di tempo.

Oggi, infine terzo Storage analizzato e testato: si tratta del E-Storage 6550 di E4, dispositivo dual controller con 1Gb di cache per controller ad un prezzo di listino maledettamente accattivante (a partire da 10.800 EUR circa) che supporta sia dischi SATA che dischi SAS, promiscui come nel caso del DS4700, all’interno di un unico enclosure o - naturalmente - nei box di espansione addizionali (chiamati JBOD). Scalabile fino a 112 dischi questa sara’ la terza soluzione storage che andremo ad implementare entro fine anno, che andra’ a costituire la seconda infrastruttura Fibre Channel del nostro Datacenter, completamente separato da quello del gruppo editoriale e finalizzato all’erogazione dei servizi in outsourcing che richiedono capacita’ scalabili (servizi E-Mail, storage condiviso per i web server, storage on demand, backup, ecc).

Oggi siamo stati in E4 per vedere questa nuova macchina che dovrebbe arrivarci a Dicembre. Devo dire che e’ un gran bel pezzo di macchina. Il software di management e’ tutto web based Java-less (con mia somma gioia), unica osservazione e’ riguardante l’utilizzo di Safari che potrebbe causare malfunzionamenti alla macchina (reboot). La gestione dei RAID e’ denominata “Virtual Disk Management”, su cui successivamente si possono creare le LUN che piu’ si desidera. La gestione dei percorsi e degli accessi e’ piuttosto semplice una volta comprese le logiche con cui lavora la macchina, le funzionalita’ ACL lo rendono un dispositivo decisamente allineato con i dispositivi di storage di classe superiore (molto meglio del MSA1000 di HP che - in alcune versioni dei controller - non supporta per niente il controllo accessi alle LUN). Le espansioni dello storage, mediante l’aggiunta di addizionali JBOD, avviene utilizzando cavi Infiniband, per cui standard di mercato di fatto.

Penso che mi dara’ enormi soddisfazioni questo storage! :)

Come avevo scritto ieri, stamattina siamo andati allo SMAU per parlare con alcune aziende. Devo dire che, a parte il viaggio lunghissimo per raggiungere la Fiera di RHO, lo SMAU di quest’anno e’ stata una fiera con i fiocchi. Poche persone, tanto spazio tra gli stand, niente ragazzini e ragazze immagine che ballano sui cubi degli operatori di telefonia mobile, assetati di gadget. Divieto d’ingresso ai minori di 18 anni (inspiegabilmente pero’ si vedevano girare delle signore anziane che raccoglievano cataloghi!!) e finalmente si parla di una fiera in cui si puo’ conversare tranquillamente con le persone senza che moscerini fastidiosi ti interrompano alla ricerca di un gadget.

Poche le societa’ che esponevano, poco il hardware esposto, pochissimi gli operatori TLC (British Telecom, Telecom Italia e Tiscali Business). Pochi anche i brand esposti: immancabile IBM con uno stand tutto dedicato agli 80 anni di innovazione, APC con le soluzioni di continuita’, contenimento e il datacenter all’insegna del “Green Computing” (e quindi all’efficienza dei datacenter). Un ramo dedicato interamente alla Pubblica Amministrazione, moltissime riviste di settore e una sezione dedicata ai produttori di hardware asiatici.

Devo dire che mi ha lasciato piacevolmente soddisfatto, sia da un punto di vista qualitativo vista la nuova organizzazione, sia per i contatti raccolti e le nozioni apprese durante il seminario e i vari incontri che abbiamo avuto. L’unico rammarico e’ la dimensione della fiera, che ha visto una brusca riduzione: solamente due padiglioni, come ho detto, il poco hardware di fascia medio alta presente, ma visti gli anni precedenti la cosa non mi stupisce affatto. Speriamo che il livello di qualita’ rimanga inalterato l’anno prossimo e ci sia piu’ affluenza di vendor (per esempio speravo di incontrare VMware e Trend Micro, ma nessuno dei due era presente).

E’ incredibile la quantita’ di computer portatili che vengono rubati dalle automobili. A prescindere dal lasciarli (o meno) in vista quando si pacheggia all’autogrill, probabilmente la perdita materiale dell’apparecchio e’ il problema minore. La posta elettronica (vedi mie precedenti osservazioni) e’ anche semplicemente salvaguardabile, ma il resto dei dati? Una tragedia. Forse la fortuna vuole che alcuni individui non badino nemmeno alle informazioni in essi contenuti, tuttavia esiste una potenziale possibilita’ che chi ruba un computer portatile (ma naturalmente la cosa si applica anche a computer fissi) possa attingere ad informazioni classificate. Seguendo la regola della scala sociale (delle aziende si intende) piu’ il notebook e’ recente maggiori sono le possibilita’ che contenga dati sensibili o comunque di importanza rilevante per l’azienda poiche’ il computer stesso sara’ di un dirigente. Quello che maggiormente mi lascia stupito e’ il fatto che quando parlo di crittografia dei dati tutti pensino ad una cosa complessa da implementare, mantenere e soprattutto utilizzare. Poi parlo di EFS e il mondo sorride a chi deve curare i dati contenuti in un notebook.

Forse non tutti sanno che EFS (Encrypted File System) e’ una funzionalita’ gia’ presente in Windows 2000, e quindi anche in Windows XP. La sua implementazione e’ semplice: selezioniamo la cartella Documenti del computer del nostro dirigente, nelle proprieta’ avanzate impostiamo che il contenuto della cartella deve essere crittografato e la descrizione della cartella diventa di colore verde. L’unica nostra preoccupazione da questo momento in poi e’ quella che il nostro dirigente non perda la propria password e non ne utilizzi una particolarmente semplice. In ogni caso possiamo rendere le cose difficili al probabile ladro impostando delle GPO di lockout sufficienti da esasperarlo e convincerlo a cambiare le password dopo aver forzato l’utente administrator. Se questo dovesse capitare continueremo a dormire sogni tranquilli: il certificato con cui vengono cifrati i documenti perde di validita’, e i documenti diventano completamente illeggibili.

L’utente non deve fare nessuna operazione specifica. Ogni documento che salva nella cartella documenti sara’ cifrato. Nessuna proprieta’ avanzata, nessun applicativo aggiuntivo, e’ tutto li’, pronto per essere utilizzato da chiunque.

Esistono anche software che operano in modo alquanto simile, eppure visto che abbiamo una funzione forte e a portata di mano e, soprattutto, integrata nel nostro sistema, perche’ non usarla? Tanto piu’ che l’utente deve solo imparare a tenere in ordine i propri documenti, cosa che richiede uno sforzo piuttosto limitato e quindi piu’ facilmente assimilabile da esso rispetto all’imparare l’utilizzo di un nuovo applicativo sicuramente complesso, pieno di password da ricordare e parametri da impostare. Aprire e chiudere documenti normalmente e, forse, dopo un po’ se trovano un documento sul disco il cui colore e’ nero piuttosto che verde, domandarsi il motivo e contattare il supporto tecnico con una domanda che - dal nostro punto di vista - e’ finalmente un segno di miglioramento perche’ i dati sono sicuri.

Ovunque io abbia lavorato mi è capitato di dover sviluppare un’applicazione per gestire determinate situazioni. Progetti, gestione supporto tecnico, IT governance, e via discorrendo. Ultimamente ho molto a cuore la parte di gestione del supporto tecnico che cerco di plasmare secondo quella che è la realtà corporativa in cui mi trovo (vedi Visioni IT: continuiamo ad integrare il Help Desk). Uno degli argomenti di cui invece non ho mai avuto modo di parlare sono sicuramente gli aspetti sistemistici.

In passato ho lavorato molto con Apache e RedHat Linux e continuo a farlo con una discreta soddisfazione tuttavia la mia scelta nell’ambito aziendale è caduta su Microsoft Windows 2003 Server come piattaforma server per l’applicazione, pur mantenendo una componente Open per la sua implementazione (PHP, MySQL, OpenLDAP, ecc). Le motivazioni sono svariate, ma in linea di massima devo ammettere che Windows 2003 Server è uno dei prodotti che mi piacciono maggiormente. Secondo me è uno dei prodotti migliori rilasciati da Microsoft negli ultimi anni (credo che se avessi dovuto scegliere tra RedHat Linux e Windows 2000 Server ci avrei pensato con molta più attenzione a cosa scegliere).  Avendo sempre un consistente numero di utenti da gestire (> 50) e un dominio Active Directory in cui sono gestiti tutti gli utenti, mettersi a duplicare un database utenti è più o meno equivalente ad un suicidio amministrativo (da un punto di vista di gestione sistemi naturalmente). Per questa ragione (praticamente ovvia), IIS6 con autenticazione Integrata (o base) è la scelta naturale per risolvere il mio problema. L’obiettivo è tipicamente quello di dare agli utenti il minor numero possibile di cose da ricordare e semplificare il più possibile la loro vita (autenticazione trasparente di IE). Per quanto riguarda la sicurezza, il supporto HTTPS di IIS6 risponde totalmente ai miei requisiti. In altri termini, con un costo in licensing relativamente ridotto ho la possibilità di mettere in piedi un frontend di produzione (anche virtuale) con un elevato livello funzionale e in grado di darmi le funzionalità di Alta Affidabilità mediante il servizio Load Balancing (disponibile anche su Windows 2003 Web Edition).

Il backend applicativo (normalmente installato sulla stessa macchina) invece basa la sua struttura su un database MySQL 5 e come linguaggio di programmazione l’intramontabile PHP. Sono due applicativi che conosco ormai molto bene e staccarmene a favore di piattaforme superiori (come .NET ed MSSQL) non mi intriga un gran che (sebbene io usi anche le altre due piattaforme, anche in un contesto web – vedi più avanti). MySQL 5 è un database robusto, veloce e capace di gestire volumi di informazioni consistenti senza nessun problema. Lo uso dalla lontana 3.23, rigorosamente con supporto relazionale. Oggi penso di saperlo usare con una grande capacità, sfruttando tutti i benefici che mi può portare, dal supporto per le transazioni alle stored procedure, fino ad arrivare alla gestione dei trigger (con l’avvento della versione 5). Anche PHP è una scelta derivata dagli anni di esperienza: è veloce, ha un set di funzioni molto vasto e un framework che mi sono creato nel corso degli anni facilita molto le cose. La conoscenza del linguaggio è stata sicuramente la scelta determinante.

Ora torniamo agli aspetti sistemistici. Ho accennato al problema dell’autenticazione utenti e indubbiamente questa è una tra le ragioni più importanti per cui ho optato per Windows come web server. Un’altra ragione è senza dubbio l’archiviazione documentale e il sistema di indicizzazione integrato in Windows. E come non apprezzare l’accesso alle risorse di sistema di Windows se non attraverso le librerie di PHP e gli oggetti COM? Questi ultimi (gli oggetti COM appunto) richiamati da PHP aprono frontiere che su Linux non sono attraversabili. Pensiamo solo alla generazione dei report. Molti subito diranno “ma come, possiamo generarli in PDF!”. E il problema si risolve. Il problema è che questa è una risposta da tecnico/programmatore e la mia opinione a riguardo è che il PDF non è un formato pratico. È un formato in sola lettura, poco gestibile e soprattutto difficilmente riutilizzabile. Ricordiamoci che stiamo parlando di applicazioni corporative, non siti Internet (nel qual caso i PDF sono senz’altro un’ottima soluzione).

Installando Microsoft Office sul server è possibile richiamare documenti Office veri e propri, generati in modalità nativa che di certo non causeranno problemi di compatibilità con i pacchetti Office diffusi in azienda. Generare quindi report in formato Excel o Word diventa un gioco da ragazzi. Allo stesso modo, le stampe dei report non sono più da gestire via pagine HTML bensì in formati più “apprezzati” dalle stampanti: inviare i documenti in stampa direttamente alle code di stampa sulla rete diventa altresì semplice. Un altro vantaggio di questo sistema integrato è quello di poter delegare ad un utente non programmatore l’autonomia per generare nuovi formati elettronici. Supponiamo di dover stampare un report su carta intestata o con una formattazione particolare. L’utente che genera il formato del report deve solo costruire lo scheletro del documento, formattarlo in modo che l’applicativo sostituisca determinate zone (o campi) con i valori generati dall’applicazione (ovviamente un breve corso di formazione è indispensabile). Nessun intervento sul codice dell’applicativo è necessaria, management e dipartimento IT non hanno necessità di cooperare per un’operazione tipica della prima divisione.

Vogliamo andare avanti? Questa è più una delle mie “Visioni” di come le cose potrebbero andare, ma qualche tempo fa ci avevo provato a giocare. Prendiamo le librerie di oggetti COM di Skype e facciamo in modo che il nostro applicativo possa anche parlare con gli operatori, sfondando la barriera delle email e sfruttando in modo senza dubbio proficuo anche i sistemi di messaggistica immediata.

Non dimentichiamo .NET e le sue funzionalità di sistema che possono essere molto comode. Prendiamo per esempio un banale applicativo sviluppato in ambiente di prova per la mia Intranet. L’esigenza era quella di riuscire a creare un ambiente di spool in cui una fotocopiatrice possa “parcheggiare” un file PDF acquisito. La fotocopiatrice carica il file sul server usando un accesso SMB diretto. Una volta che il file viene “sganciato” sul disco del server (ergo, vengono tolti i lock in lettura) il server deve modificare il nome del file e catalogarlo sul filesystem in una certa maniera. Qui .NET torna utilissimo, soprattutto se ciò che mettiamo in piedi è un semplice servizio di sistema con poche righe di C# che intercetta il file appena creato (con FilesystemWatcher) e lo sposta in una posizione altrimenti non accessibile agli utenti.

Sicuramente la gamma di prodotti disponibili per gli ambienti Microsoft Windows sono più ampi rispetto ai prodotti Open Source che, spesso e volentieri, richiedono diverse ore di studio, adattamento tecnico e inevitabilmente anche grafico prima di essere implementate negli ambienti di produzione. Il supporto tecnico, poi, è una cosa che ci tocca sperare di avere in tempi brevi e comunque sempre da supporto comunitario.

Insomma, secondo il mio personale punto di vista, integrare soluzioni vendor specific ha i suoi vantaggi (tempi di risposta, implementazione, supporto tecnico, documentazione) e svantaggi (costi) rispetto al mondo delle soluzioni Open Source, tuttavia una scelta bilanciata delle due dimensioni per trarre i vantaggi di entrambe le fazioni può portare vantaggi tangibili ed efficienti all’ambiente corporativo in cui ci troviamo a lavorare tutti i giorni, dando ottimi strumenti di lavoro all’utenza che – senza di noi – non avrebbe modo di lavorare come si deve. Molti mondi diversi possono finalmente lavorare insieme senza dover impazzire a trovare software che svolga ogni singola azione da fornitori esterni, dandoci la possibilità di creare un unico sistema integrato e cooperante.

Io ogni giorno trovo delle cose a dir poco meravigliose nelle email che leggo. Oggi ne ho vista una nuova che ha veramente dell’affascinante:

“please don’t print this e-mail unless you really need to.“

Ora mi chiedo: ma che senso ha? E’ come quella norma che dice che “per inviare comunicazioni ad un’azienda per mezzo della posta elettronica, bisogna prima chiedere - sempre via email - se e’ possibile inviare detta comunicazione”. Non ha senso, allora anche le aziende che distribuiscono volantini dovrebbero lasciare nelle nostre caselle di posta prima una richiesta di consenso alle comunicazioni commerciali!

Le cose che i nostri adorati politici (sempre rigorosamente laici) stanno mettendo in piedi a noi tecnocrati sono norme e regole assolutamente inutili, prive di senso e spesso poco attuabili. Ma la cosa continua e non penso accennera’ a finire molto presto

th

Che gli utenti siano inaffidabili si sa. Così come si sa che il 90% dei problemi, secondo il layer OSI, si trova nell’ottavo livello (ovvero tra la sedia e la console). 

Il SysAdmin assume un nuovo “passatempo”: predire il futuro. E fortuna vuole che Murphy abbia scritto la sua legge: se qualcosa può andare storto, lo farà. Il mio corollario è: se c’è di mezzo un utente, lo farà prima del previsto. L’utente finale tende ad essere un catalizzatore di disastri, quando c’è di mezzo un “laico” succedono sempre cose inspiegabili. Quelli di questo articolo si riferiscono alla perdita di messaggi di posta elettronica che avvengono autonomamente.

Vediamo il problema: utente finale, scarica la sua posta elettronica sul proprio profilo utente. Ci lavora per mesi e poi, ovviamente quando lui ha la massima necessità di un messaggio, si scopre che quel messaggio non c’è più. Si è cancellato. Si, esatto, non è che è stato erroneamente cancellato, si è cancellato da solo assieme alle email di tutta la settimana precedente. Insomma, se vogliamo essere pessimistici, seguendo la legge di Murphy, l’utente avrebbe dovuto perdere la posta elettronica in modo irreversibile nel momento cruciale. Invece abbiamo a che fare con un disastro “selettivo”. Quando pensi di averle viste tutte, eh?

Io sono uno dei sostenitori della posta in linea. Ho avuto modo di convincermi di questo sistema gia’ molte volte, e piu’ vado avanti e piu’ sono certo della mia presa di posizione. In qualita’ di Responsabile Sistemi Informativi la cosa piu’ importante da tenere sempre presente e’ che bisogna sempre garantire la disponibilita’ degli strumenti e delle informazioni che esse mettono a disposizione agli utenti. Dormire tranquillo, per quanto mi riguarda, non vuol dire sapere che i servizi non crolleranno, ma anche che i dati saranno accessibili, e se non sono piu’ accessibili, poterli recuperare.

All’utenza dei vertici delle aziende non interessa normalmente “come le cose funzionano”, desiderano solo che funzionino. Punto.

La posta elettronica e’ uno strumento di lavoro che assume sempre una maggiore importanza. L’idea di avere MX multipli, piu’ server di backend non e’ sufficiente. Sfortuna vuole che l’utenza non sia molto attendibile e chiedere aglu utenti di fare delle copie di backup dei propri dati e’ assolutamente un’utopia. I processi di logoff possono richiedere tempo in base alle dimensioni dei file di dati che piu’ diventano grossi, piu’ diventano pesanti da trasferire (via rete) e fragili. Tutto questo porta ad una sola conclusione: prima o poi uno (o piu’ utenti) si lamenteranno della perdita di tutti i messaggi. E questo e’ un problema seccante.

Tenere la posta elettronica in linea ha pro e contro (come tutto). Il pro e’ che il “point of failure” e’ uno (e non magari 300). Avendo una valida gestione delle quote si possono ottenere ottimi risultati in termini di performance e sicurezza. Come amministratore di sistema, gestire un server e’ molto meno problematico che gestire un client di rete (manca l’elemento “utente”) e generalmente si e’ in grado di prevedere un problema prima che questo effettivamente assuma quell’aspetto (di problema appunto). Inoltre, a insaputa degli utenti, si possono fare attivita’ di backup sui messaggi di posta elettronica, cosa che non puo’ certo fare che bene alla salvaguardia dell’azienda stessa.

Fare i backup dei messaggi di posta elettronica non e’ semplice. Anzi, esistono innumerevoli problemi nella gestione di un sistema di questo tipo. A seconda del server di posta elettronica, poi, esistono anche diverse tipologie di backup che si possono fare. I sistemi che usano singoli file per il mailbox store (come Courier) sono quelli piu’ problematici, poiche’ o supportano un sistema di “log circolari/incrementali” per registrare i singoli messaggi che transitano sulla casella, oppure ci tocca fare solo dei backup completi delle mailbox. Altri server, come Cyrus, usano singoli file organizzati in directory, per salvare i messaggi. La policy di backup incrementale, in questo caso, ha senso e puo’ essere applicata usando la “data di ultima modifica” come sistema di riferimento, tuttavia il processo di ripristino va studiato poiche’ i file vengono nominati con un numero pari all’indice del messaggio sulla directory IMAP. Esistono poi le soluzioni commerciali (come Symantec Backup Exec con l’agente per Exchange Server) in cui e’ possibile fare i backup dei singoli messaggi di posta durante le normali operazioni del server.

A prescindere dalla tipologia di server che si intende utilizzare, fatte le opportune valutazioni di storage (una SAN, per esempio sarebbe un grande beneficio in una infrastruttura simile) il concetto fondamentale dovrebbe essere quello che i messaggi devono essere sempre disponibili e, in caso di necessita’, non doversi mai trovare in condizioni di dire “mi spiace ma non ho modo di recuperare il tuo messaggio di ieri”. Vi assicuro che non e’ per niente gradevole dover ammettere una cosa simile

Una delle cose del mondo IT che meno approvo e per cui ho un rifiuto concettuale e’ quando societa’ di consulenza (o presunti guru di settore) riescono a convincere le aziende ad acquisire potenze di calcolo enormi senza pensare alle conseguenze delle proprie azioni. Macchine a quattro o otto vie, con capacita’ di memoria mastodontiche, certo con unita’ disco in RAID per prevenire la perdita di dati e alimentazioni ridondate… ehm… scusate, ma se muore la macchina, il Vostro business che fine fa? Premettendo di avere anche il migliore dei contratti di assistenza, riuscirete ad avere un fermo anche di quattro ore (leggi: mezza giornata) sul vostro lavoro… menomale che c’e’ il solitario di windows.

Di recente ne vedo svariate di queste realta’, che richiedono una elevata capacita’ di elaborazione. Non sono certo tra le persone che si spaventano dei numeri di elaborazioni o di transazioni (applicative, non database) di cui l’azienda ha bisogno. Pero’ mi sono spesso domandato del perche’ nessuno (o quasi nessuno) parli mai del modello “load balancing”. Forse non tutti sanno che i cluster non servono solo a garantire la continuita’ di un servizio, ma possono essere anche utilizzati per aumentare la capacita’ di elaborazione del sistema nella sua complessita’.

Prendo come esempio un progetto che ho sviluppato (a livello di laboratorio, ma e’ assolutamente in grado di operare nel mondo reale) per un test. Il problema era di poter effettuare elaborazioni di una grande quantita’ di documenti in formato PostScript da convertire in PDF.

Per lo sviluppo dell’ambiente di test ho utilizzato delle macchine virtuali su cui girava un Windows Server 2003 Standard Edition (si, la standard edition, quindi non e’ proibitivo in termini di costi). Il primo server Windows 2003 l’ho configurato facendone subito il hardening anche dell’applicazione, al fine di avere una macchina virtuale da replicare su tutte le altre. Conclusa l’installazione ho sigillato il sistema con sysprep (altra componente di sistema) e mi sono copiato l’immagine del disco su un DVD. Ho avviato la prima macchina virtuale, completato la sua configurazione e quindi messa a dominio (in questo caso avevo gia’ due DC funzionanti). Per gli altri tre nodi ho semplicemente copiato la mia immagine dal DVD e avviato la macchina virtuale da quel disco. In meno di due ore avevo 4 server perfettamente pronti per poter essere configurati nel cluster.

Per il clustering in bilanciamento di carico ho usato il Network Load Balancing di Microsoft Windows 2003 Server, ho creato il cluster e aggiunto i 4 nodi. Il servizio condiviso era naturalmente il servizio di condivisione file e stampanti. Poi ho cominciato ad inviare i file al cluster e verificato che venissero analizzati dai vari nodi del server. Naturalmente non potevo pretendere delle prestazioni formidabili (il laboratorio girava su una macchina monoprocessore) pero’ cambiando architettura hardware (passando magari a server Xeon, Dual Core oppure addirittura su processori Power) il vantaggio sarebbe stato evidente.

La soluzione presentata avrebbe consentito di poter elaborare una piu’ grande quantita’ di dati che con una singola macchina (riducendo i tempi di attesa dell’output) con un risparmio sul hardware (quasi il 20%) rispetto alla proposta fatta da un’altra parte (una macchina quadriprocessore con un boato di memoria e dei dischi con configurazioni incomprensibili). Il vantaggio vero di una soluzione in load balancing (rispetto ad un hardware che apporti lo stesso volume di calcolo) e’ la continuita’ del servizio. Supponiamo (come e’ nel caso del progetto descritto) che la generazione del PDF sia cruciale per l’attivita’ dell’azienda e che una mancanza di consegna dei PDF apporti una perdita non solo momentanea ma anche di immagine. Che succede se il sistema si ferma? Tra intervento tecnico, telefonate di utenti che inveiscono sull’amministratore di sistema, la chiamata all’assistenza e le preghiere che “non sia il controller disco” passano tra le 2 e le 4 ore prima che il problema venga risolto (gia’, perche’ il corriere ha trovato traffico a causa di un incidente, e se il nostro SysAdmin apre la macchina la garanzia se ne va a quel paese). Il danno e’ fatto: mancano due ore alle 20, scadenza ultima della consegna dei PDF, il giorno dopo c’e’ un’importante manifestazione in cui l’azienda aveva investito denaro e non potra’ avere le brochure dalla tipografia. Il sistema viene risolto, sono le 19, il sistema e’ appena ripartito, sta prendendo in carico i primi file… sono danneggiati, bisogna ricontattare il grafico per rimetterle in coda di processi… passano le 20, il sistema e’ ancora a meta’ strada per finire le conversioni…

Definitivamente la soluzione “tutto su uno” non funziona, soprattutto perche’ non da effettivi vantaggi in questo tipo di applicazioni. Se fosse morta una sola macchina virtuale (dump di sistema, crash applicativo), gli altri nodi avrebbero comunque continuato a operare e il ritardo sarebbe stato veramente ridotto, non compromettendo l’immagine dell’azienda.

Business Continuity o Alta affidabilita’? Parliamone…