Messaggi di errore poco chiari

A volte dei messaggi di errore poco chiari possono causare enormi perdite di tempo. Nel mio blog in inglese ho descritto un caso in cui il laconico messaggio “Errore di sistema” non fornisce un grande aiuto per individuare un problema che impedisce il deployment di un progetto per Analysis Services 2005. La causa scatenante (in questo caso) era un problema nella definizione degli utenti appartenenti a un ruolo all’interno del progetto. Consiglio generale: se possibile è bene evitare di associare degli utenti a un ruolo all’interno di un progetto, ma è bene farlo solo sui server in produzione, usando poi degli script di deployment (generabili con il deployment wizard) per evitare di perdere l’associazione utenti-ruoli a ogni nuovo deployment.

L’hardware giusto per sviluppare package con Integration Services

Un motivo di sconforto per chi ha cominciato a usare SQL Server Integration Services è la velocità non entusiasmante (per usare un eufemismo) dell’editor di Integration Services.


Premesso che sicuramente si può fare qualcosa per migliorare le prestazioni, va detto che ho cominciato a lavorare con una workstation “adeguata” (AMD 4400+ dual core, 4Gb RAM) e devo dire che non mi sento più di rimpangere l’editor di DTS. La questione è interessante perché se uno va ad analizzare quello che succede realmente tra CPU e RAM in teoria sarebbero sufficienti 2Gb di RAM, quindi la differenza è tutta sulla CPU, tra cache, tempi di accesso alla RAM e clock. La differenza percepita è molto più grande di quella teoricamente presente se uno va a vedere le caratteristiche tecniche di due macchine (il termine di paragone che ho è un Pentium Mobile da 2.4GHz): la sensazione è completamente diversa, direi un ordine di grandezza anziché il “doppio” che suggerirebbero i diversi “clock”. Un piccolo benchmark che ho fatto per avere un riferimento conferma che l’impressione non è campata per aria: un package eseguito non in debug passa da 162 secondi sul portatile a 15 secondi sul desktop “ben carrozzato”.


Conclusioni:



  • devo cambiare notebook

  • la legge di Moore è ancora valida (il notebook ha poco più di due anni) anche se non va applicata solo al clock della CPU

Suggerimento per chi vuole sviluppare in maniera produttiva: aggiornare l’hardware se ha più di due anni, si ripaga in fretta se a ogni debug risparmiate due minuti di attesa.

Esperienza sulla virtualizzazione


Circa un mese fa ho iniziato un’operazione di server consolidation e di aggiornamento e ampliamento dei server di sviluppo che uso per molte delle mie attività.
Una premessa necessaria è che, pur avendo usato prodotti come VMware sin dalle prime versioni, ho sempre ritenuto che la perdita prestazionale fosse un prezzo molto alto da pagare per tutta una serie di casi.
Pur mantenendo una certa riserva rispetto all’uso della virtualizzazione in alcuni scenari (su cui tornerò tra poco) credo che la combinazione dell’avanzamento di hardware e software (inteso come prodotti di virtualizzazione) offra oggi una soluzione valida per innumerevoli scenari.
In questo post cerco di raccontare un po’ la mia esperienza, con gli occhi dello sviluppatore che ogni tanto deve fare anche il sistemista (credo sia un’esperienza piuttosto comune).


L’idea è di partire con due server quasi gemelli (dischi, RAM, rete) e differenti solo per le CPU usate (due dual-core 2.8GHz da una parte e due Xeon “normali” ma da 3.8GHz dall’altra).
Il software di virtualizzazione usato è VMware GSX Server: Microsoft Virtual Server, per quanto stia evolvendo velocemente, è ancora distante da prestazioni e flessibilità di VMware.
Senza entrare troppo nei dettagli, su un server sono montate una decina di macchine virtuali che restano “sempre attive” e su cui girano una serie di servizi di supporto (dal Domain Controller a Vault) che devono essere sempre disponibili. Questo primo server (diciamo “di produzione”) ha anche delle interfacce in DMZ e degli IP esposti (il lavoro da remoto è essenziale) e nonostante questo la sicurezza ottenuta nella separazione delle reti è uguale se non maggiore (per il controllo che è possibile) della precedente separazione (reti e macchine fisiche).
Il secondo server contiene invece SQL Server sul sistema operativo host insieme a VMware GSX Server, che consente di affiancare la piena potenza di calcolo di tutti i processori (quando si provano dei caricamenti di un Data Warehouse la potenza non basta mai) alla condivisione delle risorse con macchine virtuali “di sviluppo” (che possono essere reinstallate e/o riavviate spesso, per i più disparati motivi).
Perché mai una simile architettura? Eccone i vantaggi:



  • backup di tutte le macchine virtuali fatte dal sistema operativo host (in fondo le macchine virtuali sono dei file sul disco)
  • disaster recovery relativamente semplice: si ripristinano le macchine virtuali sul server superstite e i sistemi di produzione ritornano operativi con un fermo macchina minimo (compatibile con le esigenze operative interne, insomma)
  • gestibilità: creare o spostare una macchina virtuale è estremamente semplice e si può fare tutto da remoto, con vari tool di amministrazione che consentono di variare tutti i parametri fisici delle macchie virtuali
  • costi: forse è la cosa più importante, ma dal mio punto di vista la flessibilità e il minor tempo necessario per la manutenzione ha un valore ancora maggiore del risparmio sull’hardware “fisico”. Comunque, giusto per fare qualche conticino, un server da meno di 6.000€ tiene in piedi una decina di macchine virtuali e resta ancora un po’ di spazio (RAM in particolare) per aumentare il carico. È indubbio che un numero pari di macchine con caratteristiche hardware equivalenti a ogni macchina virtuale costerebbe di più (i dischi sono Ultra SCSI 320 da 15.000 rpm in mirror).
  • licenze: come ho detto, tutto l’ambiente serve per fare sviluppo e test e quindi per le licenze di VMware GSX Server si può ricorrere alla VMTN Subscription, un contratto analogo a quello di MSDN (Microsoft) con cui è possibile utilizzare i prodotti VMware per scopi di sviluppo (con alcune limitazioni che però nel nostro caso non costituivano un problema).

Qualche considerazione sulle risorse necessarie.



  1. RAM: tanta. Un server con meno di 4Gb è quasi inutile per fare operazioni simili. Può avere senso partire con 6Gb, con 8Gb si ha molto spazio per operare.
  2. CPU: finora non è mai stato un problema, però la migrazione di tutti i servizi richiederà ancora tempo e quindi, anche se le macchine virtuali sono già tutte definite, non sono ancora tutte attive, quindi il consumo per ora non è significativo. Poi ovviamente dipende tutto dalle applicazioni e dal carico applicato…
  3. LAN: avere tante prese di rete è la cosa migliore perché garantisce la possibilità di allestire le configurazioni più strane. Come minimo è bene avere due collegamenti, ma con quattro sicuramente non si sbaglia. Bisogna ricordare che un serve che ospita macchine virtuali è come se fosse una server farm: progettereste il telaio limitando i collegamenti di tutte le macchine a un unico hub?

Come ho detto prima, esistono ancora dei limiti che però saranno presto superati. Il più grande è che l’attuale versione di VMware GSX Server non fornisca a ciascuna macchina virtuale più di un processore. Questo limite, insieme a un certo rallentamento sulle operazioni di I/O, mi fa scegliere di usare una macchina “fisica” per ospitare SQL Server 2005 e Analysis Services. Ma le prossime versioni supereranno almeno il limite dei processori (VMware workstation già lo fa), mentre per la penalizzazione sulle operazioni di I/O dovrò tornare sull’argomento più avanti, l’argomento richiede studi approfonditi.


A questo punto devo fare un doveroso ringraziamento per tutto ciò che ho imparato nonché per il fatto che nell’arco di due giorni ci fosse dal nulla un’infrastruttura funzionante (praticamente un datacenter visto il numero di macchine virtuli)… Il grazie va ad Alessandro Perilli, che oltre a essere un esperto di virtualizzazione e sicurezza mantiene anche un seguitissimo blog [in inglese] sulla virtualizzazione (http://virtualization.info) che è una grande miniera di informazioni, novità e riferimenti su tutti i prodotti relativi alla virtualizzazione.

Promesse da marinaio

Arrivando quasi al termine di un breve periodo di vacanza, sono andato a rileggermi i buoni propositi per il 2005 per scoprire con sgomento di non essere riuscito a mantenerne praticamente nessuno. Il divertimento è cercare delle scuse per giustificarsi, ma andiamo con ordine.



  1. Nuovo linguaggio: anziché approdare a nuovi lidi o tornare al passato (C++) mi sono fermato lungo la via di C# per arrivare alla versione 3.0. Scusa: poca motivazione (e totale assenza di tempo) per dedicarsi a un linguaggio che poi non si usa nella quotidianità. Ma il proposito doveva servire appunto a trovare una motivazione, quindi scusa pessima.

  2. Libro: no comment. In realtà il progetto l’ho abbandonato dopo aver maturato l’idea di una certa intempestività e forse inefficacia del progetto che stavo portando avanti. Scusa per lavarsi la coscienza.

  3. Progetto “open”: non posso dire di averla mantenuta, ma ci ho lavorato e forse qualcosa vedrà la luce, grazie anche ai contributi di chi ha già dato una mano (si tratta di qualcosa relativo a dati di comuni e località italiane). Spero di riuscire a consolidare qualcosa prima che le nevi si sciolgano (senza che questo debba sembrare presagio dell’inizio di una nuova era glaciale).

  4. Articoli su Win32: l’avevo detto che era difficile…

  5. Telefoni: alla fine ho preso sia il Qtek 9090 che l’i-mate SP3 rinunciando in definitiva solo al Motorola MPx. Poi ho venduto il Qtek 9090 e sono passato all’i-Mate JasJar. Dunque se vista in negativo, non sono riuscito a scegliere. Se vista in positivo, sono riuscito a venirne fuori. Se vista obiettivamente, non si meritava un impegno “formale” di così grande valore…

  6. Una settimana senza posta: impensabile. Credo di non aver mai raggiunto le 24 ore su 365 giorni. Il JasJar è la capitolazione definitiva per chi vuole abbandonarsi a questa forma di dipendenza.

Come scusa finale, ho lavorato tanto e mi sono dedicato moltissimo ad Analysis Services 2005, senza aver ancora avuto il tempo di scrivere a sufficienza su questo nuovo prodotto. Ma su questo ci sto lavorando (e questo è vero perché ho già scritto l’equivalente di un paio di articoli e quindi se anche non finisco tutto, qualcosa da pubblicare ce l’avrò lo stesso).


Siccome il tempo porta consiglio, per il 2006 non ripeterò l’esperienza di fare propositi che potrebbero rilevarsi promesse da marinaio.


Buon 2006 a tutti.