Prima di avviare una istanza di cloud computing, 3 fasi da affrontare

La scelta di passare ad una soluzione di cloud computing implica alcune conoscenze di base e scelte da affrontare in partenza. Vediamo in questo articolo come procedere con ordine e poter migrare in tranquillità ad una soluzione di cloud computing. Prendiamo in esempio il caso di HostingSolutions.it come cloud provider.

Molte aziende stanno iniziando a muovere i primi passi nel mondo del cloud computing. Alcune aziende si muovono timidamente, altre hanno già spostato sul cloud gran parte dei dati e servizi. Nonostante la tendenza generale alla prudenza, alcune ricerche hanno evidenziato che solamente il 30% delle aziende che si avvicinano al cloud compiono ricerche accurate prima di scegliere il provider a cui affidarsi. Si tratta in parte di una contraddizione, perché se veramente ci preoccupiamo della sicurezza dei nostri dati sul cloud, per coerenza dovremo essere molto attenti al momento di scegliere un provider. La prima fase da affrontare, prima di avviare un’istanza di cloud computing, consiste perciò nella valutazione dei diversi provider.

Scelta del cloud provider

La prima analisi da compiere riguarda ovviamente le credenziali dell’azienda. L’esperienza di un provider, il suo nome sul mercato e la sua affidabilità sono in generale informazioni accessibili pubblicamente. Si tratta di un’analisi tutto sommato superficiale, ma conviene comunque svolgerla come selezione preliminare dei diversi candidati.

Una volta identificati i provider ci sembrano più affidabili possiamo valutare le caratteristiche tecniche, commerciali e amministrative. Uno dei primi aspetti riguarda la definizione degli SLA (Service Level Agreement). Gli SLA sono solitamente espressi come una tabella di servizi associati ad un valore percentuale. Ad esempio, uno SLA di Availability pari al 99,99% nei giorni feriali significa che il provider garantisce un accesso ai dati senza interruzioni per il 99,99% del tempo. Lo stesso servizio potrebbe avere uno SLA leggermente minore nei festivi (ad esempio 99,9%). Un’azienda seria rende chiaramente accessibili i parametri attesi per gli SLA, evidenziandoli sul contratto d’uso ed eventualmente negoziandoli in fase di trattativa. Inoltre dovrebbe sempre essere chiaro come viene gestito il mancato rispetto di un livello di SLA contrattuale: a questi eventi potrebbero fare seguito sconti (verso il cliente) o penalità (verso il provider). Non si dovrebbe mai scegliere un provider senza informarsi su quali sono i livelli di SLA promessi, e come vengono gestiti.

Dal punto di vista della gestione del cliente dobbiamo informarci su quali sono le modalità di assistenza offerte dal cloud provider. Quando migriamo, in toto o in parte, il nostro business sul cloud ciò non significa che non avremo più bisogno di fornire assistenza ai nostri clienti. È inevitabile aspettarsi comunque richieste, domande e segnalazioni di problemi. Quello che cambia, se passiamo al cloud, è la modalità con la quale possiamo fornire assistenza ai clienti. Conviene informarsi anzitempo sulle procedure che permettono al nostro team di assistenza di collaborare con il supporto offerto dal cloud provider. In questo modo possiamo valutare l’efficienza della catena di assistenza che parte del cliente finale, passa per il nostro centro assistenza, per essere poi inoltrata verso l’assistenza offerta dal cloud provider.

Un altro aspetto importante riguarda la gestione delle praticheamministrative. Per quanto la fatturazione dei servizi possa essere automatizzata è bene informarsi sulle modalità di tracciamento dei diversi costi. Sia per i servizi a consumo che per quelli a pacchetto è importante poter tracciare in tempo reale i diversi costi: ciò permette a noi e ai nostri clienti di controllare le risorse utilizzate in rapporto al loro costo. Senza un’adeguata interfaccia di monitoraggio dei costi sia noi che gli utilizzatori finali rischiamo di trovarci delle sorprese al momento della fatturazione.

 

Individuazione delle risorse

Dopo aver scelto il provider del servizio cloud possiamo procedere con l’individuare le risorse che fanno al caso nostro. Tra le risorse disponibili sul cloud possiamo trovare dischi di storage remoti, sistemi operativi virtuali, server e applicazioni. Dopo averle identificate nell’interfaccia dobbiamo decidere come poterle combinare per creare l’architettura che ci interessa. Una scelta molto semplice, comoda per fare delle prime prove o preparare delle demo, consiste nell’utilizzare un singolo server virtuale. Questa architettura assomiglia alla classica soluzione LAMP(Linux, Apache, MySQL, PHP) , costituita da tre strati che interagiscono tra loro. Al primo livello troviamo il Web server, che riceve direttamente le richieste da parte dell’esterno. Subito dopo troviamo l’application server, o semplicemente l’applicazione Web, che per esempio potrebbe essere implementata da un servizio CGI oppure delle pagine PHP. Infine troviamo il database server, inteso come applicazione che si occupa di accedere ai dati in modo opportuno. I tre componenti lavorano assieme per realizzare la cosiddetta architettura su tre livelli (three-tier). La soluzione più semplice è quella di usare una singola istanza che accolga tutte e tre le applicazioni, mentre il sistema di storage vero e proprio resta una risorsa a parte. In figura 1, sulla sinistra, troviamo lo schema che descrive un’architettura di questo tipo, implementata su un unico server.

Figura 1 – Architetture a confrontoLa distinzione tra una soluzione di cloud computing e una soluzione server dedicato

L’altra scelta consiste nel creare un server dedicato per ciascuna applicazione. Avremo così un server che ospita Apache, un server dedicato per l’applicazione (le pagine PHP, ASP ecc.) e infine un server dedicato per il database. Questa configurazione è mostrata nello schema di destra di figura 1.

Di primo acchito si potrebbe pensare che l’architettura basata su tre server dedicati sia più che sufficiente per qualunque attività. In realtà ciò non è vero, perché il sistema di questo tipo è detto non ridondante. Poiché tutti gli elementi del sistema sono strettamente necessari al buon funzionamento dello stesso, un qualunque malfunzionamento o disservizio di un elemento della catena rischia di compromettere l’intero sistema. Per questo motivo possiamo gestire le risorse del cloud in modo più snello, creando dei server dedicati extra. Ad esempio possiamo creare due server che si occupino di ricevere le richieste HTTP, corrispondenti (ad esempio) a due istanze del server Apache associate a due server dedicati diversi. I due server possono lavorare in concerto per mezzo di sistema di load balancing, ovvero a distribuzione di carico. Con questo stratagemma, anche se uno dei Web server risultasse fuori servizio, o semplicemente sotto carico, le nuove richieste degli utenti verrebbero automaticamente renderizzate verso l’alto server.

Le architetture ridondanti di questo tipo sono molteplici. Teoricamente possiamo rendere ridondante qualsiasi elemento della catena. A seconda dell’esigenza potremmo avere più di un Web server, più di un application server e più di un database server. Nel caso volessimo replicare il database server dobbiamo introdurre i concetti di Master DB e Slave DB. Un database server non può essere clonato con la stessa facilità con la quale cloniamo un web server o un application server. Nel caso del database è necessario decidere qual è il database primario, che viene appunto detto Master DB. Gli altri database saranno delle copie di quello primario, aggiornate automaticamente tramite alcuni job che girano in background. Per questo motivo le copie slave del database conterranno probabilmente dati leggermente meno aggiornati. Ad esempio un database slave potrebbe aggiornarsi con un ritardo di 10-30 secondi rispetto al master. A seconda del timing caratteristico del nostro business ciò suggerisce una certa attenzione nel momento in cui decidiamo di utilizzare un’architettura ridondante anche a livello del database. In linea di massima questa è una buona idea solamente se trattiamo dei dati per i quali non è un problema avere un ritardo di qualche secondo. Ad esempio, se usiamo il database primario per aggiornare i dati e quello secondario per i servizi di sola lettura, molto probabilmente non avremmo alcun problema neppure con un ritardo di qualche minuto tra le due istanze.

 

Strategia di utilizzo

Le modalità di utilizzo della piattaforma cloud possono dipendere dalla tecnologia utilizzata da provider. Ad esempio, i servizi cloud offerti da EC2di Amazon in alcuni casi utilizzano un sistema di storage off line rispetto agli altri servizi. Ciò significa che, in questo caso, le strategie di utilizzo delle macchine virtuali sono diverse da quelle dei dispositivi di storage. Altre aziende possono usare sistemi diversi, con tecnologie diverse, per cui le scelte che ottimizzano l’utilizzo delle risorse cambiano di conseguenza.

Consideriamo ad esempio la soluzione offerta da Hosting Solutions, basata sulla piattaforma OpenStack, un sistema open source sviluppato con la collaborazione di aziende quali Apache e NASA. Oltre alla piattaforma ci interessa sapere come vengano gestite le diverse macchine virtuali. Nel caso di Hosting Solutions viene usato il sistema hypervisor KVM, che permette a molti provider di tutto il mondo di offrire i servizi di OpenStack al pubblico.

Una volta identificata la tecnologia utilizzata provider possiamo documentarci per capire quali sono le strategie che possiamo applicare per ottimizzare costi e prestazioni. Molti provider offrono dei prezzi più vantaggiosi per la virtualizzazione delle macchine piuttosto che per l’accesso ai dispositivi di storage. Ciò significa che, a parità di servizio, un’applicazione cloud basata su molte macchine virtuali (VM) potrebbe costare meno di una che utilizza un’unica macchina virtuale appoggiata su diversi dispositivi di storage. Per capire la differenza tra le diverse soluzioni dobbiamo ricordarci che le macchine virtuali di fatto convivono sulla stessa macchina fisica. Ad esempio, se il provider dispone di un calcolatore (macchina fisica) con una memoria di 12GB, nel momento in cui questa macchina viene usata per virtualizzare due macchine virtuali, il provider sceglie come assegnare i 12GB di memoria. Potremmo avere due macchine virtuali equivalenti, ciascuna con 6GB di memoria, oppure potremmo averne una più potente, con 8GB di memoria, affiancata da una supporto con 4GB di memoria. Se invece la stessa macchina fisica venisse usata per visualizzare 3 VM equivalenti, ciascuna di esse disporrebbe di 4GB di memoria.

Lo stesso discorso si applica a tutte le risorse della macchina fisica. Le diverse macchine virtuali dovranno condividere risorse di rete, spazio su disco e capacità di elaborazione del processore. Solitamente il processo di scambio dati tra una macchina virtuale e il dispositivo di storage implica la serializzazione dei dati, che vanno poi deserializzati. Questo processo rallenta in generale il servizio e impatta costi di risorse diverse. Diventa quindi importante valutare se la nostra attività richiede più elaborazione (utilizzo della CPU delle VM) oppure è incentrata sulla persistenza dei dati (dispositivi di storage). Con la conoscenza della tipologia del nostro servizio potremmo trovare l’architettura più adatta, la soluzione più performante e quindi ottimizzare il rapporto qualità/costo.

Facci sapere cosa ne pensi!

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *