Due parole sulle modalità di upgrade. Il documento ufficiale di VMware, che suggerisco caldamente di leggere, ricorda giustamente di controllare la compatibility matrix (lo dirà almeno duecento volte in 180 pagine di documento, quindi fatelo) e di pianificare l’evento di upgrade in quanto può generare “noie” alla continuità del nostro ambiente di produzione.

Il primo step è ovviamente il backup dell’attuale architettura: certificati e database della vCenter. Non è opportuno operare l’upgrade sotto snapshot o con altri trucchetti, fate gli opportuni backup.

Salvato il salvabile si può procedere con l’upgrade della vCenter alla versione 5.0 (U1 se preferite). Il wizard è del tutto simile a quelli di un’installazione come anche le risposte che daremo, fatta ovviamente eccezione per la licenza (dobbiamo mettere quella nuova) e per l’eventuale collocazione del database nel caso non si sia utilizzata la versione di MSSQL “integrata” nel server vCenter. Segnalo un video (semplice ma efficacie) che mostra tutto il processo: http://www.youtube.com/watch?v=wbmQPrTO5po.

Durante il processo di upgrade della vCenter non saranno ovviamente disponibili i servizi da essa erogati, mentre i servizi che girano “a livello host”, come HA, resteranno disponibili. Di fatto la procedura non ha impatto sulle VMs del cluster.

Terminato l’upgrade della vCenter si può passare agli hosts. Da manuale si dispongono di due strade: procedura “manuale” o tramite “update manager”. Personalmente preferisco utilizzare il metodo manuale per poi configurare l’host applicandovi il profilo del caso (se usate i profili). La procedura richiede ovviamente che l’host venga messo in maintenance mode, dovrete quindi spostare tutte le VMs ad esso assegnare sugli altri hosts del cluster; il tutto può quindi essere eseguito senza generare fermi di servizio.

Con l’infrastruttura pronta si passa alle VMs. Qui non c’è scampo, l’upgrade dei VMware Tools richiede il riavvio dei sistemi Microsoft e l’upgrade della versione del virtual hardware si fa a guest spenta. E’ necessario schedulare dei fermi di servizio.

Tempi di upgrade? Al netto della configurazione delle nuove funzionalità il processo di upgrade per il classico cluster di 3-5 hosts vi impegnerà poche ore (dipende anche dalla vostra confidenza con l’ambiente). Per le VMs stimerei 15 minuti a macchina considerando che probabilmente dovrete anche eseguire dei test post-upgrade.

Roolback? Attenzione: potete tornare sui vostri passi post-upgrade della vCenter, post-upgrade degli hosts e persino dei VMware tools… ma una volta che il virtual hardware è stato aggiornato non si torna più indietro.

Ok, tutti su vSphere 5!

Non mi metto a parlare delle funzionalità del prodotto, sono troppe… il messaggio che vorrei dare con questo post, ora che oltre a vederli usare li ho anche usati un po’, è il seguente: gran belle macchine, tantissime funzionalità in ambito networking, eccellente interfaccia di gestione (WinBox) e monitoraggio (the Dude). La nota dolente arriva alla fine: grande lode agli sviluppatori che hanno scritto un sistema operativi leggerissimo e ricco di servizi, meno lodi a chi ha creato un hardware prestante ma con un livello di affidabilità decisamente troppo basso.

Probabilmente incide anche il lavoro, per lo più outdoor, di questi apparati, ma la probabilità di un guasto hardware eccessiva se la paragoniamo ad un qualsiasi apparato di rete Cisco, giusto per fare un nome a caso. Ho visto router Cisco spegnersi dopo sei anni di onorato lavoro e venivano spenti solo perché era arrivato il momento di cambiarli, non perché non funzionassero. Questo non possiamo, oggi, dirlo del “ferro” MikroTik. E’ comunque opportuno evidenziare i pregi di queste macchine che, nonostante la loro versatilità e la loro configurabilità fammo veramente molto e costano veramente poco.

MTCNA è stato un corso generico, non tratta quindi specifici temi tecnici di settore come le reti geografiche o WiFi (temi ripresi in altri corsi) ma fa una panoramica sulle funzionalità del prodotto che parte dal semplice routing fino ad arrivare al firewalling e al servizio HotSpot.

L’errore che si presenta per chi possiede Workstation 8.0.x è il seguente:

vthread-3| I120: Trying to find a suitable PBM set for kernel 3.2.0-23-generic

Fortunatamente è tutto facilmente risolvibile con una semplice patch disponibile nel web: http://communities.vmware.com/message/1900761.

Unico neo il momento di celolunghismo degli sponsor, avrebbero potuto presentare i propri case history senza lanciarsi frecciatine a vicenda… inutile litigarsi la palma del migliore davanti ad una platea composta per lo più da informatici incalliti… pessima figura. Nulla da rimproverare agli amici del VMUG che hanno segnalato con garbo di adottare un altro atteggiamento nell’affrontare la tavola rotonda.

Nonostante il tema proposto – la sicurezza – si è parlato per lo più di storage in termini di performance ed innovazione con un ottimo intervento di Rapposelli sulla tecnologia SSD. Non potevano mancare meravigliosi momenti dedicati al cloud, in particolare l’intervento di Stephen Harrod, ospite speciale di questa edizione del VMUG meeting, è stato veramente interessante.

Insomma, tutti i temi trattati sono stati interessanti, ma ammetto che non mi sarebbe dispiaciuto discutere di sicurezza con le menti presenti, il che mi fa venire il solito sospetto: il tema “sicurezza” in Italia non è ancora sufficientemente sentito.

Alla prossima!

Questa strategia di protezione dei dati è nota con il nome di offsite backup, ovvero la capacità del backup system di generare un set di dati di backup, copia dei backup ordinari, i cui media siano fisicamente esportabili e collocabili in un luogo distinto, possibilmente distante, rispetto al luogo in cui sono collocati i sistemi oggetto di backup.

Il paradigma funziona in virtù del fatto che esiste un piano di backup ordinario che protegge i sistemi dalla potenziale perdita di dati; si pensi al classico backup giornaliero che ci permette di recuperare dati di N giorni fa. Il piano di offsite prevede la copia, su altro media, dell’intero set di backup; i media utilizzati per la copia vengono poi “etichettati” come volumi offsite e collocati in un luogo sicuro e distinto rispetto alla loro posizione originale.

Il risultato di questa procedura consta nel disporre di una copia online delle schedulazioni di backup e un’ulteriore copia offline ed in altra sede.

In tempi più recenti, con l’aumento di disponibilità di banda, sta diventando consuetudine utilizzare la tecnica delle “copie simultanee” generando, contemporaneamente, il set di backup ordinari ed il set di backup di copia e già collocato in altra sede. Si ottiene quindi che sia i backup ordinari che gli offsite sono, di fatto, online e reperibili rapidamente dal sistema di backup.

Il backup offsite, sia esso su media online o offline, è alla base della procedura di DR in quanto difficilmente ripristinerete i sistemi se il “disastro” ha coinvolto server e backup system (solitamente sono nello stesso luogo).

Che si utilizzi Tivoli Storage Manager i degli scripts ciò che conta è che le copie di backup siano effettivamente in due luoghi diversi. Le aziende multi sede spesso si inviano le copia a vicenda, è già qualcosa. Gli amministratori di sistemi diligenti si portano i nastri a casa, meglio di niente. Per chi ha modo di fare le cose secondo best practice il supporto più garantito o con il miglior rapporto GB/€ resta il nastro LTO (giunto alla versione 5 con 1,5 TB di capienza, 3 TB con compressione dei dati secondo gli standard di TSM), da conservare in appositi contenitori che ne garantiscono l’integrità per anni.

Si nota sempre più spesso la tendenza ad utilizzare HD portatili per la conservazione dei dati. Comodo, rapido e assolutamente insicuro :-)
Le probabilità di rottura di un HD di fascia “80€ al supermercato” è molto più alta di quella di un LTO o altra tipologia di nastro. Usare gli HD per gestire il piano di offsite è sicuramente comodo, ma non adagiatevi troppo su questa comodità (my two cents).

Chiudo augurando a tutti di non dover mai applicare le procedure di DR.

Oggi tutti parliamo di cloud computing e, ad accezione degli addetti ai lavori (quanto mi piace questa espressione), ritengo che pochi abbiano compreso il tema. Faccio quindi un passo indietro rispetto al mio precedente post, probabilmente troppo tecnico, nel tentativo di raccontare il concetto di cloud agli esseri umani.

Il concetto standard di infrastruttura informatica prevede che un’azienda debba dotarsi di determinate componenti hardware (computer, monitor, apparati di rete, ecc.) e software (sistemi operativi, applicazioni, server gestionali, server di posta elettronica, ecc.) per informatizzarsi.

Queste componenti costituiscono un investimento di capitale e generano dei costi ricorrenti per la loro gestione e manutenzione: serviranno tecnici qualificati per far funzionare il tutto e serviranno nuovi investimenti per mantenere l’infrastruttura efficiente. Inoltre ogni nuovo investimento deve tener conto dei trend di crescita, si rischia quindi di dover investire sovradimensionando un’infrastruttura che sarà a regime di utilizzo sono per una parte della sua vita.

I servizi cloud mirano a minimizzare i costi d’infrastruttura astraendone il concetto stesso. Le aziende di settore si impegnano a pre-costruire e manutenere un’infrastruttura informatica di alto livello su cui le aziende clienti possono far risiedere i propri servizi pagando un canone per l’uso delle risorse e delle funzionalità. Avviene dunque che il responsabile ICT dell’azienda ABCDEF s.r.l. non sarà più vincolato ad acquistare un server e il software necessario per il server e per i client al fine di mettere a disposizione il servizio di posta elettronica, potrà invece rivolgersi ad un’azienda che eroga servizi cloud e dire:

voglio la posta elettronica con Exchange per 2000 utenti e con 10 GB di spazio mailbox ad utente, voglio pagare solo per lo spazio che uso, voglio che ci siano i backup granulari a livello mailbox con 1 mese di retention e che il sistema sia in H.A., voglio il monitoraggio del servizio ed un presidio 24×7 da contattare in caso di problemi

e finalmente qualcuno risponderà:

certo, il servizio sarà pronto tra due giorni e costerà € XX ad utente e € YY a GB di spazio utilizzato

Ho voluto ovviamente estremizzare con un ipotetico Software as a Service, ma la realtà, per le aziende che dispongono di questo tipo di servizi, non è distante da quanto ho scritto.

Dal punto di vista dell’utilizzatore dei servizi il passaggio al cloud potrebbe essere quasi trasparente in quanto, nell’esempio precedente, l’utente usava Exchange prima e continua ad usare Exchange dopo. Dal punto di vista dell’ICT manager la situazione cambia notevolmente in quanto si trova a gestire un servizio e non una “sala server interna” che eroga servizi. Cambiano gli oneri, cambiano le competenze, cambiano le responsabilità, cambiano i costi. Su questo versante è una piccola rivoluzione.

Il cloud risolve quindi tutti i problemi dell’ICT? Vi rimando al mio vecchio post :-)

Esiste un interessante documento di VMware che suggerisce cinque riflessioni utili a chi desidera virtualizzare il proprio Datacenter, grande o piccolo che sia. Il documento titola “Five steps to determine when to virtulize your servers” e di seguito ne espongo il sunto.

Step 1: comprendere i benefici della virtualizzazione
I quattro principali benefici della virtualizzazione sono il risparmio di tempo, il risparmio economico, la facilità di gestione e le potenzialità di recovery in caso di disastro. Questi quattro benefici sono ovviamente da rapportare al mondo fisico dove l’ottimizzazione delle risorse hardware è meno versatile e spesso presenta delle diseconomie in quanto ogni server può far girare un sistema operativo, quello installato.

In relazione al risparmio, sia esso di tempo o di moneta sonante, vale la legge dei numeri: gestire un cluster VMware di due nodi costa meno che gestire venti – o più – server fisici. Ovvio che se la nostra infrastruttura comprende un server che fa tre cose, le fa bene da anni, il sistema è solido ed il backup sono a regime… bhe, in questo caso potrebbe aver poco senso virtualizzare il quanto il rapporto costo/beneficio potrebbe risultare poco allettante.

Step 2: valutare la soluzione di virtualizzazione
Il mercato offre differenti soluzioni e modelli di virtualizzazione, i tre brand citati all’inizio offrono la loro interpretazione dei servizi di virtualizzazione e tutti e tre lo fanno molto bene. Io sono un dichiarato fun di VMware ma bisogna considerare il fatto che ogni brand offre qualcosa di unico. Un esempio banale: se il nostro Datacenter comprende e comprenderà sempre server con O.S. di casa Microsoft potrebbe seriamente aver senso utilizzare HyperV.

Al di la del brand va considerato il livello di funzionalità che si richiede alla nostra server farm virtuale. VMware, ad esempio, offre diverse modalità di licensing per diversi livelli di funzionalità, da quella base dove “basta virtualizzare” a quelle Enterprise con funzionalità evolute come l’alta affidabilità la Fault Tollerance ed il DRS.

Step 3: assicurarsi che le applicazioni funzioneranno bene in virtuale
Virtuale non è fisico, ficchiamocelo bene in testa. Aggiungere una stratificazione software porta inevitabilmente a dei costi che, per quanto trascurabili, esistono. Se virtualizziamo male questi costi diventano delle vere e proprie perdite di performance che possono compromettere il servizio.

Quando si valuta una soluzione di virtualizzazione è necessario investire del tempo in analisi per comprendere quali sistemi dovranno girare sullo stesso nodo, quali dovranno condividere lo storage, quali avranno bisogno di risorse garantite e quali invece potranno lavorare tranquillamente best-effort. Esempio: se posizioniamo nello stesso Datastore due sistemi che fanno molto I/O su disco è inevitabile generare una contesa di risorse, sin dall’inizio i due sistemi dovranno essere posizionati su dischi logici e fisici differenti.

Step 4: analisi dei costi
Quanto costa virtualizzare? Come detto poco fa molto dipende dal livello di funzionalità che si desidera, ad ogni modo virtualizzare bene non è gratis e non è affatto detto che tutte le aziende possano permetterselo. Esistono aziende che offrono servizi di virtualizzazione nei propri Datacenter (io lavoro per una di queste) con soluzioni a canone mensile, ma c’è anche chi preferisce (o è vincolato ad) investire in una propria infrastruttura di virtualizzazione.

In questo caso i costi lievitano notevolmente e basta poco per raggiungere i 10.000-15.000 euro di infrastruttura. Quindi la questione è: ma mi conviene virtualizzare? Fatevi i conti in tasca, potreste trovare soluzioni meno belle ma altrettanto affini al vostro target.

Step 5: considerare le skills ed il tempo per migrare in virtuale
Per approcciare una migrazione da mondo fisico a mondo virtuale è necessario avere delle skills sul prodotto di virtualizzazione che si è scelto. Se queste skills non le si hanno in casa è ovviamente saggio rivolgersi ad un professionista (ci sono fior di aziende e liberi professionisti stra-certificati che potete contattare).

E’, inoltre, da tener presente che il lavoro di migrazione richiederà dell’operatività che potrebbe durare anche parecchi giorni a seconda della mole di dati. Spesso è utile fare un piano d’azione per effettuare le migrazioni in più step e minimizzare l’impatto sugli utenti dei servizi che si è deciso di virtualizzare.

La virtualizzazione è (IMHO) un grande strumento ma non va utilizzato “a caso”, bisogna ponderare bene ogni scelta prima di intraprendere la via del virtuale e trarne effettivi benefici.

In molti è ancora radicata la credenza che gli attacchi informatici siano opera di qualche furfante che dalla propria tana opera nella notte allo scopo di rubare denaro per via telematica. La verità è abbastanza diversa. Oggi buona parte degli attacchi sono condotti da bot che in mesi di lavoro collezionano decine di server compromessi con i mezzi più banali (spesso con semplici brute force). Questa modalità di attacco nelle sue prime fasi ha come unico obbiettivo il guadagnarsi l’accesso a quanti più sistemi possibili a prescindere da cosa vi sia sui server. I server compromessi vengono spesso utilizzati per altri attacchi o come base per attacchi DDoS. Si può quindi essere vittime di un attacco informati senza necessariamente essere il bersaglio primario.

Provate a spiegare quanto da me scritto ad un qualsiasi membro di una PMI italiana. Al di la del comprendere o meno gli aspetti tecnici del tema è lampante una completa mancanza di interesse, come se il problema non esistesse. C’è addirittura il rischio che passiate per paranoici.

Chi ha tanti anni di servizio alle spalle sa che “l’attacker” è dietro l’angolo e questa consapevolezza ci spinge, dovrebbe spingerci, a fare le cose per bene: password robuste, policy di firewalling stringenti, attenzione al livello di patching, hardening dei sistemi, fino ad arrivare agli IDS ed IPS laddove la situazione lo richiede.

La sicurezza informatica è, in Italia, ancora percepita come un qualcosa in più, non sempre necessaria, qualcosa di trascurabile salvo situazioni particolari come l’essere una banca. La sensibilizzazione sul tema sta di fatto a noi, forse dobbiamo indossare la tunica del “security evangelist” più spesso.

Il migliore amico del problem solver è il log file. Guardiamoci dentro e leggiamo attentamente, non necessariamente alla ricerca di un errore il quale non è detto che si manifesti esplicitamente. Riporto un esempio recentissimo:

*** NetworkManager[921]: <info> Starting VPN service 'pptp'...
*** NetworkManager[921]: <info> VPN service 'pptp' started (org.freedesktop.NetworkManager.pptp), PID 3877
*** NetworkManager[921]: <info> VPN service 'pptp' appeared; activating connections
*** NetworkManager[921]: <info> VPN plugin state changed: 1
*** NetworkManager[921]: <info> VPN plugin state changed: 3
*** NetworkManager[921]: <info> VPN connection 'TEST VPN' (Connect) reply received.
*** pppd[3878]: Plugin /usr/lib/pppd/2.4.5/nm-pptp-pppd-plugin.so loaded.
*** pppd[3878]: pppd 2.4.5 started by root, uid 0
*** pptp[3883]: nm-pptp-service-3877 log[main:pptp.c:314]: The synchronous pptp option is NOT activated
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
*** pppd[3878]: Using interface ppp0
*** tuxicity pppd[3878]: Connect: ppp0 <--> /dev/pts/2
*** NetworkManager[921]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0)
*** NetworkManager[921]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found.
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 43392).
*** pppd[3878]: CHAP authentication succeeded
*** kernel: [ 6154.097690] PPP BSD Compression module registered
*** kernel: [ 6154.135569] PPP Deflate Compression module registered
*** pppd[3878]: LCP terminated by peer (MPPE required but peer negotiation failed)
*** pptp[3889]: nm-pptp-service-3877 log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed
*** pptp[3889]: nm-pptp-service-3877 log[callmgr_main:pptp_callmgr.c:258]: Closing connection (shutdown)
*** pptp[3889]: nm-pptp-service-3877 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
*** pptp[3889]: nm-pptp-service-3877 log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed
*** pptp[3889]: nm-pptp-service-3877 log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)
*** pppd[3878]: Modem hangup
*** pppd[3878]: Connection terminated

Trovato il problema? Allora cerchiamo con Mr. Google e capiamo cosa è successo. Fortunatamente PPTP è ben documentato e alla pagina http://pptpclient.sourceforge.net/howto-diagnosis.phtml del sito troviamo buona parte degli errori e relativa diagnosi. Nonostante io non ami particolarmente PPTP bisogna apprezzare la quantità di documentazione a disposizione, ottimo ausilio alla diagnosi dei problemi.

Non limitiamoci a guardare i log del cliente, anche i logs dei server che erogano il servizio VPN possono contenere informazioni utili alla diagnosi di un problema (ammesso che il server sia in vostra gestione).

Ultima nota: incentivate l’uso di VPN per l’accesso ai servizi “delicati”, anche se il servizio prevede nativamente un sistema di autenticazione. Un esempio banale è la posta elettronica aziendale: limitarsi ad esporla in IMAP o in POP3 è una pratica poco sicura. Un buon livello di “blindatura” è l’esposizione della sola porta 25 per la ricezione della posta dall’esterno e l’accesso ai servizi del mail server solo tramite sessione VPN. Paranoia? Noi la chiamiamo sicurezza ;-)