Le reti aziendali crescono assieme (fortunatamente) alle aziende che cominciano a godere dei vantaggi derivanti dalla possibilita' di connettere, a costi ragionevoli, sedi geograficamente dislocate. VPN over Internet, connessioni dedicate o VPN realizzate sui backbone degli ISP... le scelte possibili sono tante con tanti vantaggi e svantaggi in ognuna di esse. L'unico fattore che tutt'ora accomuna le varie soluzioni e' la capacita' del canale trasmissivo. Prendiamo una qualsiasi linea ADSL in wholesale: enorme capacita' di banda in download, uno spiraglio minimo (256Kbps) per l'upload. Questa e' una caratteristica tecnica che puo' essere accettabile per un'azienda che deve navigare oppure (gia' meno) utilizzare i mezzi di messaggistica elettronica. Vediamo invece una necessita' puramente amministrativa: quale azienda non dispone di un sistema gestionale? Anche in questo ambito esistono soluzioni di diversa natura e concezione, eppure tutti hanno qualcosa in comune: il modello client/server (come del resto la stragrande maggioranza di applicazioni).

La cosa che maggiormente mi colpisce del modello "client/server" di oggi e' che pochi sembrano aver imparato qualcosa dal passato. Pensiamo un attimo ai terminali 3270 di IBM, detti anche "Display Device" utilizzato per l'accesso al sistema gestionale residente su Mainframe (server) su terminali stupidi utilizzando un programma testuale: Telnet (client). Un modello semplice in cui l'utente inseriva i dati o si aspettava dei dati sul proprio terminale trasmettendoli o ricevendoli dal server. Il modello e' eccellente ed e' costituito da tre stadi: il client in cui e' presente l'interfaccia utente, il server che effettivamente e' l'applicazione che elabora i dati provenienti dai client e li ritrasmette ad esso, e il database. La caratteristica fenomenale e' che decine di utenti potevano operare utilizzando delle connessioni ridottissime visto che la capacita' di banda utilizzata dai terminali era attorno al Kbps (si, uno) se non durante le fasi di stampa (che bello, all'epoca si inviavano dati ASCII alle stampanti ad aghi: 80 caratteri per ogni riga, piu' i codici CR ed LF oppure FF).

Oggi il modello e' "presuntuosamente" uguale, ma in realta' ha una pecca di fondo. Hanno eliminato uno strato dal modello precedente. Oggi il client e' un'interfaccia grafica (GUI) mentre il server e' brutalmente il Database. Client/Server. Giusto no?

No.

Il problema delle connessioni di rete e' che sono latenti e con capacita' ridotte. Le capacita' ampie sono tutt'ora onerose e giustificare la necessita' di una connessione 10Mbps per poter far accedere un utente al sistema gestionale e' praticamente una follia. Ricordiamoci anche che la velocita' di connessione tra due sedi connesse in VPN e' pari "alla velocita' massima della connessione piu' lenta". Tanto per capirci, se due sedi sono connesse tra di loro in VPN usando il backbone del ISP, parlando di connessioni Wholesale, anche ammettendo che sulla tratta non ci sia alcun traffico le sedi non potranno comunicare tra di loro a piu' di 256Kbps. Parlando di gestionali, questo vuol dire che se un utente in una sede di Torino cerca di accedere al gestionale che sta a Milano avra' a disposizione solamente i suddetti 256Kbps per il trasferimento di dati. Ogni volta che l'utente poi effettua un'operazione sull'interfaccia utente, il "client" genera una query, la inoltra al "server" e attende il risultato... un risultato che e' un recordset (un insieme di righe generate dal database) che deve essere di nuovo interpretato ed elaborato. Capita spesso che i database "lascino" i risultati nella propria memoria, pertanto ogni "passaggio di elaborazione" tra un record e l'altro necessita di una nuova richiesta di dati dal client al DB e una corrispondente risposta. Inoltre i timeout delle connessioni o le latenze portano con se problemi di stabilita' nella connessione tra il client e il server, introducendo tutta una serie di problemi e fastidi tanto all'utenza (che diventa improduttiva) quanto alla gestione dei sistemi (che - di fatto - non ha modo di risolvere il problema).

La soluzione sarebbe quella di inserire un "middleware" tra i due strati: il client invia una richiesta al nostro "middleware" (che - nel caso di sistemi gestionali - e' l'applicativo gestionale vero e proprio), questi interroga il database (che da un punto di vista tecnico e' connesso al DB con una rete ad alte prestazioni) e invia al client i risultati gia' elaborati. Non dobbiamo certo andare ad inventarci nuovi protocolli di trasmissione per fare queste operazioni, ce ne sono gia' tanti e sono ottimizzati per questo tipo di attivita'. Da un punto di vista funzionale, beh... le cose cambiano considerevolmente. Intanto l'utente non ha piu' i problemi di lentezza di creazione della connessione e rice/trasmissione dati, e i 256Kbps di banda non rappresentano certo un problema (alla fine anche se le linee vanno in backup ISDN con 128Kbps l'utenza puo' tranquillamente continuare a lavorare indisturbata).

Non e' andata come speravo... o meglio... come doveva andare... il sistema e' ancora bloccato... non riesco a darmi pace, continuo a riesaminare e riesaminare i dati che ho tirato fuori stamattina... debug di quelli piu' assidui, a vedere cosa fa il sistema mentre elabora il batch... DLL, filesystem, memoria... nessuna conclusione... trovato un altro problemino sulle cache dei dischi di sistema... eppure non ho risolto. A livello di sistema quelle macchine sono perfette, anche a volerlo non hanno nessun errore di configurazione.

Dicono che il nostro sistema sia identico a quello di un'altra realta'... io ho un presentimento sulla internazionalizzazione del sistema... sapremo lunedi'. Oggi penso che andro' avanti sull'analisi del sistema di posta elettronica...

Alla domanda: "risparmiamo sul sistema di posta elettronica ma rendiamola veramente efficace" la mia risposta e': Linux RedHat (o Fedora, o CentOS), Cyrus e Postfix. Che cosa ha di speciale? Dimenticavo il quarto ingrediente: Active Directory.

Sto studiando un sistema che consenta il raggiungimento di questi obiettivi:

• riduzione dei costi di licenza sui sistemi di posta elettronica
• tenere tutta la posta elettronica in linea (IMAP)
• ridurre i costi di amministrazione del sistema

A che punto sono? Ho un IMAP server che si autentica su KDC di Active Directory (non e' single sign on ma e' possibile consolidare il meccanismo di autenticazione su un sistema gia' presente in tante aziende: Active Directory appunto) e utilizza la stessa per l'aliasing dei messaggi e il delivery (praticamente fa delle query LDAP). Avro' un paper pronto tra qualche giorno, ci sto lavorando di notte :p

Stay tuned.

Alla fine ieri abbiamo finalmente messo mano a quella bella famigliola dei server Editoriali. Un'impresa che - stando agli standard visti fino ad oggi - per spostare 4 server da un server all'altro, modificare i percorsi della rete ethernet, installare due Catalyst 2960 nei nuovi armadi, configurarli e cablarli, avrebbe dovuto impiegare circa 2 giorni e' durata poco piu' di due ore effettive di lavoro. Abbiamo eliminato i vecchi switch di rete 10/100, finalmente il backbone dei server e' gigabit (rame) anche se privo di ridondanza fisica (RSTP e' comunque gia' configurato e pronto per l'aggiunta di nuovi 2 switch). Mentre i tecnici dell'editoriale stavano facendo il loro lavoro sull'editoriale per migrare i servizi io e Aste83 ci siamo impegnati a spostare i 4 server metaframe... un lavoro arduissimo: 30' netti e gia' stavamo installando Director su tutti i metaframe. Finalmente i server sono tutti uno sopra l'altro, insieme (i 4 xSeries sopra la SAN). Nei giorni precedenti avevamo riconvertito una unita' logica RAID precedentemente fatta in RAID-5 (su 9 dischi :-/) in un RAID-10, visto la quantita' di dati che questi dischi dovranno gestire in ingresso e in uscita. Unico momento di quasi-panico e' quando toccando dentro l'alimentazione di uno degli switch FC questo ha spento lo switch stesso (ora il cavo non si stacchera' di certo) pero' la cosa ci ha dato modo di provare che il MPIO funziona :)))

Finalmente mi e' chiaro anche come funziona gran parte delle applicazioni dell'editoriale (mica per altro, ma perche' capire il giro che fanno le foto prima di entrare in pagina bisognava vedere la cosa sul nascere).

Insomma un passaggio molto meno doloroso delle settimane precedenti (GPO sui metaframe completamente incartate, una revisione totale di tutto l'ambiente di produzione, SAN con un RAID-1 perso e apparentemente irrecuperabile, giusto quei 100 e rotti Gb di dati - recuperato il giorno successivo da Aste83...) anzi... e' stato quasi piacevole, mi sono divertito un sacco. Unico mancamento e' la carenza di sonno... abbiamo iniziato alle 20 e finito alla 1:45 ma tutto sommato ne e' valsa la pena :)))

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

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

CREATE TABLE tbl_pazienti (

 ID_paziente INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,

 nome_paziente VARCHAR(45) NULL,

 codice_fiscale CHAR(15) NULL,

 indirizzo VARCHAR(45) NULL,

 localita VARCHAR(255) NULL,

 provincia CHAR(2) NULL,

 stato CHAR(3) NULL DEFAULT "ITA",

 telefono VARCHAR(20) NULL,

 codice_assistito CHAR(10) NULL,

 PRIMARY KEY(ID_paziente)

);

1. Creazione del livello di autorizzazione
2. Per ogni tabella andiamo a definire quale colonna l’utente può visualizzare e quale no (un valore booleano)
3. Salviamo le modifiche

SELECT t.nome_paziente, t.codice_fiscale, t.indirizzo, t.localita,

       t.provincia, t.stato, t.telefono, t.codice_assistito

FROM tbl_pazienti t

WHERE t.ID_paziente = 25

LIMIT 1;

$q = “SELECT.....”;

$r = mysql_query( $q );

$data = mysql_fetch_array( $r );

 

# Altro codice

 

print( $data[ “nome_paziente” ] );

$sql = “SELECT ....”;

$obj->query( $sql );

 

# Altro codice

 

print $obj->getElement( “nome_paziente” );

"L'applicazione e' lenta"
"Comprate una macchina con 8 processori"

La (triste) storia dell'Information Technology degli ultimi anni e' proprio questa... i programmatori sono drogati di risorse di sistema. Personalmente rimpiango i tempi in cui si programmava in Assembler: avevi un set di istruzioni ridotto e se non progettavi un programma bene finivi la memoria a disposizione per il sorgente applicativo. Erano tempi duri, ma quando rilasciavi il software erano vere soddisfazioni. I processori avevano i clock a 16MHz, 24MHz nel migliore dei casi. Se una funzione era troppo lenta (magari in applicazioni industriali) ti toccava riscrivere la routine per ridurre il numero di cicli macchina che impiegava a completarsi (e a fare i conti con un foglio XL piuttosto che Lotus 123 per vedere il numero di cicli macchina e quindi millisecondi ci mette). Se invece ci metteva troppo mettevamo un numero di NOP sufficiente per perdere abbastanza tempo... PERDERE TEMPO!!!

Oggi no. Codice lurido, non strutturato, ad oggetti... MegaByte di memoria allocata in non si capisce bene quale motivo... come disse qualcuno anni fa (non ricordo chi - abbiate pieta') "man mano che il linguaggio di programmazione diventa alto, la capacita' analitica dei programmatori calera'"... forse arrivera' il giorno in cui il codice si scrivera' da solo... oggi chiunque sappia usare frontpage e' programmatore (momento di gelo).

La fine e' abbastanza drammatica: applicazioni non strutturate, non documentate, pessimamente commentate, poco sicure e poco efficienti. Un collega mi racconto' di un'applicazione sviluppata in ambiente non forkabile che, per dare migliori performance, e' stata installata su una macchina a 8 processori. L'esito di questa installazione e' facilmente deducibile. Ma allora mi chiedo: perche' gli sviluppatori non hanno l'umilita' di ammettere che non capiscono niente di sistemi e hardware, non riflettono sul fatto che le applicazioni possono essere migliorate semplicemente ottimizzando il codice (o le query, o il carico di lavoro tra applicazione e database)? Qual'e' questa drammatica fenditura che si e' verificata tra "programmazione" e "conoscenza del hardware" su cui l'applicazione deve girare?

Poi si dice che bisogna risparmiare sulle infrastrutture. Io rimpiango le persone come il mio professore di Sistemi Industriali all'ITIS che ti ribaltava la testa se facevi una routine in 13 righe quando potevi farlo in 7. Aveva ragione, io oggi me ne rendo conto, ma possibile che persone cosi' non insegnino piu'?