Smashdown del cloud privato contro il cloud pubblico

Forse uno dei due tipi di cloud è più nobile dell’altro?

Le offerte di cloud IaaS (Infrastructure as a Service) pubblico si accompagnano da diversi anni e hanno provato il loro valore. Oggi si possono mettere in pista una serie di server cloud pubblici, caricarli con software per appliance virtuali e disporre, in un solo giorno, di una app Web-facing Internet funzionante. Un cloud pubblico fornisce risorse su Internet un modello di costo self-service, con pagamento a consumo (pay as you go).

Se alla propria app in realtà “spuntano le ali” e ha bisogno di più CPU, memoria o storage, espanderla richiede un semplice clic (e addebito su carta di credito). Si, è vero che l’infrastruttura di cloud pubblico costa più dell’infrastruttura privata sul lungo termine, ma questo divario si sta riducendo, cosa che, si può pensare, potrebbe rendere il passaggio all’ingrosso dai datacenter tradizionali alle cloud pubbliche un gioco da ragazzi.

Ma i cloud pubblici hanno qualche punto debole che i professionisti IT detestano e gli operatori di cloud pubblico non sono ancora riusciti a escogitare soluzioni efficaci. Il primo punto debole è la perdita di controllo dell’IT: in un’interruzione di un’infrastruttura privata, lo staff IT può mettere mano alle applicazioni e ripararle, solitamente in fretta. I componenti cloud sono “là fuori, da qualche parte”, oltre la portata dell’IT, che invece deve dipendere dalle abilità di risoluzione dei guasti (che non sempre sono adeguate) del provider cloud.

Ci sono stati alcuni guasti spettacolari di cloud (emblematico, a questo proposito, il disastro di Amazon del weekend di Pasqua 2011) che hanno tenuto offline gli abbonati cloud per giorni.

Un secondo punto dolente è la sicurezza: Cloud Computing significa computing virtuale e i server virtuali hanno un mucchio di nuove vulnerabilità che devono essere mitigate. I fornitori di servizi cloud fanno quanto basta per indirizzarle? Non sempre. Per alcune vulnerabilità, non esiste alcuna soluzione nota nel panorama odierno della virtualizzazione.

Un terzo punto debole è relativo alle prestazioni: come tutti sappiamo, la “v” di “virtuale” sta per “falso”. I server cloud tipicamente non sono hardware reali dedicati (anche se alcuni provider in realtà offrono questa opzione ad un costo più elevato).

Molti condividono invece server fisici, storage e reti.

Un workload di un particolare utente può così far crescere il tempo di risposta di workload vicini che appartengono a utenti non correlati.
Così, la prestazione del cloud pubblico è solo stimata, non garantita. Tuttavia il Cloud Computing è un’ottima idea, che i datacenter IT delle grandi aziende hanno deciso di voler emulare sotto forma di infrastruttura di cloud privata. I cloud privati hanno lo scopo di migliorare i punti deboli del cloud pubblico e l’hanno fatto bene.

Con un cloud privato, voi controllate l’orizzontale, la verticale e sempre voi controllate l’affidabilità, la sicurezza e le prestazioni delle vostre applicazioni. È nata una certa rivalità “in the clouds”, con sostenitori della versione pubblica e di quella privata che si fronteggiano su queste tematiche.

In gioco ci sono miliardi di dollari di investimenti IT; alcuni di questi dollari sono i vostri.

Prima che mettiate denaro su uno o l’altro contendente, dovreste comprendere i pro e i contro di ciascuno, e cosa dovete fare per evitare di essere messi KO sul ring.

Il bum rush del cloud pubblico

L’idea alla base del cloud privato è quella di emulare il provisioning rapido e automatico e l’addebito automatico dei costi fornito dai cloud pubblici, spostando l’IT lontano dal ruolo di esperti applicativi ed entro una missione di provider di utility computing affitabile. Non è così semplice come si potrebbe pensare, tuttavia, poichè la maggior parte dei provider di cloud pubblico sorvegliano attentamente il loro software di provisioning e gestione.

Un problema che hanno incontrato i cloud privati è la corsa a implementare l’infrastruttura senza prima sviluppare processi interni di gestione delle risorse. I clienti interni tendono a chiedere un trattamento di favore per progetti minimi e senza forti policy che spesso risultano in espansione di “VM incontrollata” (la moltiplicazione incontrollata di macchine virtuali che sono malamente pianificate e malgestite).

I cloud pubblici sono assolutamente neutrali rispetto alle esigenze dei clienti. Si ottiene ciò per cui si paga, e nemmeno un centesimo in più.
Finchè l’IT può ottenere questa disciplina, i deployment di cloud privato probabilmente aumenteranno la complessità senza offrire l’eleganza di fornitura del servizio che ci si aspetta.

L’elemento chiave di un cloud privato realizzabile è la componente di gestione del workload, che comprende server dedicati al portale di fornitura dei servizi all’utente finale, al monitoraggio, al load balancing e alla ricerca guasti.
L’ideale sarebbe che le reti di gestione e di workload, così come lo storage, fossero completamente isolati gli uni dagli altri.

Costruire una piattaforma affidabile di cloud privato è spesso al di fuori delle capacità dei team IT enterprise, anche esperti, primariamente perchè la tecnologia è decisamente nuova.

I vendor di “Private-cloud-in-a-box” aiutano a indirizzare questo problema attraverso la fornitura di pacchetti di infrastruttura preconfezionati, quali il sistema IBM PureFlex, che supporta sia x86 che gli host fisici IBM i Power. PureFlex ha l’amministrazione cloud integrata su server fisici dedicati con isolamento di rete secondo best practice.

Un portale integrato self-service consente ai consumatori di VM di avviare nuovi server mentre traccia i costi per l’attribuzione interna; il portale comprende hook per consentire all’IT di mediare il processo di deployment e prevenire la proliferazione di VM.

Inoltre, il sistema supporta API che consentono agli operatori di cloud privato di personalizzare le interfacce di gestione per il branding interno o per soddisfare speciali esigenze di controllo.

I cloud pubblici colpiti al mento

Il Cloud computing è una tecnologia nuova: Amazon ha lanciato il proprio “Elastic Compute Cloud” nel 2006, solo sei anni fa.

Perciò, ci si dovrebbe aspettare che la sua affidabilità cresca col tempo. Ahimè, è successo esattamente l’opposto, cosa che da alla gente dell’IT una nuova paura quando considerano dove investire i loro beni futuri per la pensione.

Il 2011 ha visto un rapido aumento delle interruzioni cloud rispetto agli anni precedenti, a partire dal già menzionato disastro Amazon di Pasqua.

Questo singolo guasto, durato quattro giorni, ha fatto precipitare l’affidabilità di Amazon EC2 dai “cinque nove” dorati dei campioni IT fino a un 98,9%.

In termini numerici si tratta di un piccolo valore. Ma i cloud sono mondiali, quindi si deve considerare l’intero pianeta per ottenere una vera misura di fragilità del cloud.

Nell’agosto del 2011, entrambi i datacenter cloud di Microsoft e di Amazon situati a Dublino, Irlanda, sono stati messi fuori uso da scariche elettriche causate da fulmini.

La campana è suonata dopo due giorni di downtime. Circa nello stesso momento, Microsoft ha lanciato il suo cloud Office 365, che i critici sostengono dovrebbe essere ribattezzato “Office 363”, dopo che una serie di errori di configurazione e deployment ha causato l’impossibilità per molti utenti di accedere ai loro uffici virtuali per 48 ore. Google Docs ha sofferto downtime spurio durato ore a Budapest e nella sua città apparentemente sorella, San Francisco.

Quest’anno (2012 – NdEn3pY), un bug ha colpito il cloud Microsoft Azure (un certificato digitale scaduto il 29 Febbraio), mettendo gli utenti al tappeto per diverse ore.

Questi sono solo alcuni degli esempi più emblematici, ma ci sono state, e continuano ad esserci, molte interruzioni nel cloud pubblico.
Anche se il 2012 appare essere meno problematico del 2011.

L’International Working Group sulla resilienza del Cloud Computing, costituito quest’anno da Telecom ParisTech dall’Università Paris 13, ha pubblicato il report “Classifica dell’affidabilità del Cloud Computing nel mondo – http://iwgcr.wordpress.com/), notando che i 13 più grandi fornitori di cloud hanno accumulato un totale di 568 ore di downtime a partire dal 2007.

In altri termini, si tratta di cinque giorni all’anno di “dark clouds”.

Quindi, i cloud non sembrano ancora in grado di rappresentare l’unico provider di servizi IT.

Una sfida fondamentale fronteggiata dagli operatori di cloud privato, che stanno seguendo nuovi percorsi nell’interoperabilità dei componenti.

Un cloud pubblico utilizza lo stesso hardware usato dai normali centri IT, solo in volumi enormi, e l’hardware è interconnesso in modi complessi e nuovi, mai considerati dai suoi progettisti. Prevedere e contrastare modalità di guasto in questa arena è più arte che scienza. Quando qualcosa va storto, il problema spesso si propaga attraverso la rete di un cloud, rendendo la diagnosi e la riparazione estremamente difficili.

Nuove tecnologie, quali SDN (Software Defined Networking) e gli standard di interoperabilità del cloud pubblico vi consentiranno di implementare workload attraverso diversi operatori di cloud, distribuendo il rischio di guasto di un singolo operatore.

Dalle interruzioni del cloud pubblico è derivata una cosa positiva: i fornitori di cloud sono stati sorprendentemente sinceri riguardo ai loro insuccessi e sembra che abbiano imparato da essi.

Amazon, per esempio, ha istituito nuove procedure e percorsi di gestione “fuori banda” nel suo disastro pasquale indotto dai tecnici.
Google sostiene di aver identificato punti deboli nel suo dataplex e ha effettuato aggiornamenti appropriati.

Tutti i principali fornitori di cloud oggi offrono agli utenti una visibilità schietta sugli uptime dell’infrastruttura, con console di stato che permettono di tracciare i problemi in tempo reale.

La mascella di vertro dello “snapshot” della virtualizzazione

La sicurezza del cloud pubblico è una preoccupazione naturale per le applicazioni enterprise mission-critical, ma molte persone dell’IT credono di poter indirizzare queste preoccupazioni con la crittografia: criptare i dati a riposo e in transito, utilizzando la tokenizzazione, le public key infrastructure (PKI) e le VPN. La virtualizzazione in effetti introduce alcuni rischi nuovi, primariamente legati al hypervisor e alla sua interfaccia con il mondo esterno. Delle due classi generali di hypervisor: il Tipo 1, che viene implementato sul “nudo metallo” e il Tipo 2, che gira all’interno di un OS come Linux o Windows. Il Tipo 1 è l’unico considerato accettabile per l’operatività di cloud pubblica o privata sicura.
Gli Hypervisor di Tipo 1 contengono solo i componenti necessari per eseguire task di gestione della virtualizzazione, dando loro una superficie di attacco molto più piccola delle architetture di Tipo 2. Per gli Hypervisor di Tipo 1 è anche comune venir eseguiti da storage a sola lettura (read-only), rendendoli meno suscettibili ad un attacco diretto.

Un aspetto fondamentale della protezione degli hypervisor è quello di assicurare che tutte le componenti di gestione, e glu hyperviror stessi, siano isolati dagli accessi pubblici a Internet,oltre che dalle reti virtuali utilizzate dai workload cloud. Le best practice sia per cloud pubblico che privato attualmente richiedono questo isolamento, e generalmente è stato ben implementato nei cloud pubblici.

Ma la virtualizzazione del cloud pubblico ha un sottile rischio di insicurezza per cui attualmente non esiste alcun rimedio: il problema “VM Snapshot”.

Ogni piattaforma moderna di virtualizzazione supporta un processo di servizio chiamato “snapshotting”, in cui una VM viene congelata nel tempo con un record di stato memorizzato su disco.

I meccanismi della snapshot sono troppo complessi per descriverli qui, ma basti sapere che una snapshot è equivalente a copiare su di un file tutta la memoria e lo storage su disco.

Questo file può poi venire utilizzato per vari compiti amministrativi, quali backup o fornire capacità di restart alle applicazioni.

La Figura 1 illustra come il processo di VM snapshot crei un nuovo rischio. Si consideri un utente offsite che accede a un’applicazione “sicura” ospitata (hosted) in una VM presso un provider cloud. Come parte dei suoi compiti di manutenzione periodica, il provider crea una snapshot della VM.

Questa snapshot contiene lo stato completo della VM e, nel caso di questa applicazione, le chiavi crittografiche utilizzate per crittografia “a riposo” e le chiavi VPN usate per criptare i dati scambiati con gli utenti offsite. Un agente maligno (un impiegato scontento di un provider cloud, un hacker o anche un agente governativo) ottiene accesso a quella snapshot, copiandola sulla propria macchina. Lo stesso poi ricostruisce la VM operativa e ne estrae tutti i dati utili, comprese le chiavi crittografiche. Ancora peggio, l’intruso sfrutta le chiavi VPN per impersonare un utente remoto legittimo o perseguire un attacco MitM (Man in the Middle). La dolce scienza di questa vulnerabilità per gli hacker è che il cliente cloud non sa mai che alla sua VM è stata presa una snapshot, e men che meno che la snapshot è stata sfruttata.
Una proprietà intrinseca delle snapshot è che esse non influiscono in alcun modo sulla VM operativa. È anche possibile che un hacker possa riuscire a subentrare alla funzione stessa della snapshot, dandole accesso completo a qualsiasi VM operante in un dato cloud. Per alcune applicazioni, quali quelle governate da normative specifiche (per esempio HIPAA o PCI-DSS), il problema snapshot pone una barriera insormontabile. Poichhè le snapshot coinvolgono l’hypervisor e l’hardware CPU sottostante, solo una misura di sicurezza a questo (basso) livello può proteggere da un simile problema, attraverso snapshot crittografate per esempio.

I cloud privati hanno lo stesso rischio, ma gli operatori di cloud privati sono in controllo diretto dell’accesso alla loro rete fisica e delle misure di prevenzione delle intrusioni. Così (almeno teoricamente) sono maggiormente in grado di dimostrare mitigazione del rischio.

L’hypervisor PowerVM di IBM, interamente implementato in hardware e in firmware a sola lettura, mitiga un grande numero di rischi di sicurezza della virtualizzazione.

In particolare, la sua Hardware Management Console separa la gestione delle VM dalle VM stesse, mentre il VIOS (Virtual I/O Server) di PowerVM supporta zone multiple di sicurezza dello storage e protezione firewall integrata, cosa che aiuta a mitigare il problema snapshot. Tuttavia queste misure non eliminano completamente il rischio.

Stracciare le prestazioni

Un altro attributo del cloud pubblico che porta l’IT a considerare le opzioni di cloud privato è quello delle prestazioni. Qui il cloud pubblico ha uno svantaggio intrinseco, perchè la sua reattività dipende alla fine dall’imprevedibile Internet. I provider cloud tipicamente hanno connessioni Internet massicce, che raramente hanno problemi di congestione.

Ma anche se un cliente cloud ha abbondante larghezza di banda, la sua connessione al cloud passa probabilmente attraverso diversi provider Internet, ognuno dei quali potrebbe avere problemi di congestione o di routing. Solo per questa ragione le applicazioni cloud hanno un ritardo intrinseco che gli utenti percepiscono, rendendo il cloud più lento in modo misurabile rispetto all’infrastruttura di server locali che costituisce un cloud privato.

La latenza di Internet è solo un fattore di performance.

Per definizione, il cloud pubblico condivide risorse fisiche tra molti utenti e i workload dei singoli a volte degradano i rispettivi tempi di risposta.
Teoricamente, le prestazioni si livellano nel tempo, ma le medie significano poco se la propria applicazione di shopping non riesce a richiamare le vendite in modo abbastanza veloce da soddisfare le richieste durante la ressa festiva.

È compito del cloud provider rilevare la conflittualità e ribilianciare i workload quando è necessario, ma questo processo è completamente opaco nei confronti dei consumatori cloud. Certo, i fornitori cloud offrono garanzie di SLA (Service Level Agreement), ma queste sono tipicamente limitate a un credito sul costo del servizio nel caso in cui il SLA non venga rispettato. Qesti crediti escludono sempre i danni accidentali, come il valore delle vendite perse.

Una limitazione di bilanciamento dei carichi dei maggiori fornitori di cloud pubblico deriva da una limitazione fondamentale della virtualizzazione x86, per cui i workload possono condividere risorse di CPU solo in modo approssimativo. Un dato workload viene allocato ad un numero intero di CPU virtuali e spesso questo numero è o troppo piccolo o troppo grande in termini di potenza di calcolo, il che risulta in prestazioni ridotte o prestazioni sprecate.

IBM PowerVM e l’architettura PureFlex supportano le micro-partizioni, che possono allocare risorse di processore in modo frazionario. Così, un cloud privato basato su PowerVM può allocare 0,3 di una CPU a un workload a bassa priorità, e 1,5 CPU a un workload più grande, uniformando meglio le risorse alla necessità.

Armonizzazione applicativa

Le limitazioni del cloud pubblico non lo eliminano come contendente nell’IT computing. Quando le caratteristiche di un’applicazione combaciano con le capacità del cloud pubblico, non c’è di solito alcun inconveniente nel deployment di cloud pubblico, soprattutto quando la propria infrastruttura di virtualizzazione esistente deve espandersi e ha problemi ad accogliere nuovi workload.

Le applicazioni che vanno bene nel cloud pubblico sono quelle con budget iniziali limitati per l’acquisto di beni strumentali. Il cloud pubblico consente di mettere le proprie applicazioni in grado di operare immediatamente e spesso permette ai proprietari delle applicazioni entro l’azienda di implementare all’esterno della coda di progetti del dipartimento IT.

L’elasticità del cloud pubblico permette all’applicazione di espandersi per incontrare la domanda a un costo prevedibile e la geodiversità dà una misura di business continuity integrata (purchè il progettista dell’applicazione includa risorse cloud di backup nel deployment). Si possono ottenere questi stessi benefici con un cloud privato, ma le spese iniziali in conto capitale di un cloud privato possono essere difficili da giustificare se tutte le proprie potenziali applicazioni possono essere eseguite senza rischi in uno o più cloud pubblici.

Tuttavia, alcune applicazioni possono essere facilmente scartate come candidati a un cloud pubblico in base alla funzionalità, alla sicurezza o alle esigenze prestazionali.

Le applicazioni che richiedono una compliance stretta con le regole di sicurezza che non possono essere rispettate dai cloud provider, come HIPAA, sono poco adatte al cloud pubblico.

Così sono le applicazioni che consumano molta larghezza di banda o che hanno esigenze critiche di tempi di risposta, come il software per la grafica interattiva o per l’ingegneria. Alcune applicazioni legacy semplicemente non funzionano nel cloud perchè le loro interazioni con risorse non-cloud sono troppo complesse o perchè nessun cloud pubblico supporta un vecchio linguaggio di programmazione,
o le esigenze di runtime del database.

Poichè il cloud privato dà un controllo assoluto sulla sicurezza, sulle prestazioni e sulla compatibilità di piattaforma, servirà meglio queste applicazioni.

La stretta di mano del pugile: il cloud ibrido

Anche se gli operatori di cloud pubblico e i vendor di cloud privato amano dipingere la loro rivalità come un qualcosa che richiede una decisione unanime in un modo o nell’altro, i consumatori enterprise gradirebbero ottenere il meglio di entrambi i mondi.

Un modo per ottenere questo risultato è il concetto di cloud ibrido, che in un mondo ideale consente agli utenti di spostare liberamente workload virtuali dal datacenter aziendale all’infrastruttura di cloud pubblico e viceversa, secondo le necessità.

La chiave alla praticabilità del cloud ibrido è l’interoperabilità tra cloud, sia nelle interazioni da privato a pubblico che da pubblico a privato.

L'interoperabilità richiede standard per la portabilità dei dati, migrazione di workload dal vivo e strumenti per gli sviluppatori.

Questi standard sono in corso di pubblicazione da parte di diverse organizzazioni nascenti di standardizzazione cloud:

• Cloud Computing Interoperability Forum
• Cloud Security Alliance
• Cloud Standards Customer Council
• Distributed Management Task Force
• Open Data Protocol
• OpenStack.org
• Storage Network Industry Association

 

Ognuna di queste organizzazioni si rivolge ad un aspetto particolare dell’infrastruttura cloud: portabilità dei dati, hypervisor, strumenti di gestione, sviluppo di policy, protocolli, sicurezza e storage. Potete visitare i loro siti per vedere quali provider di cloud pubblico e vendor di cloud privato partecipino nella realizzazione degli standard pubblici, cosa che può servire per guidare le vostre decisioni d’acquisto di un cloud.
Un gruppo attivo negli standard particolarmente prolifico, OpenStack.org, offre già un sistema operativo cloud scalabile completo di sistema di gestione. IBM ha firmato con OpenStack.org all’inizio di quest’anno (2012), unendosi a Cisco, Dell, NetApp e altri importanti vendor cloud.

Questo articolo è stato riprodotto su autorizzazione di MAT Edizioni dal numero 270 di Dicembre 2012 di SystemNews. Autore: Mel Beckman - direttore tecnico senior di System iNews.