Esempio di architettura che utilizza il cloud storage gateway. Fonte: Devcentral.f5
Il cloud storage è un archivio di memoria collegato ad una piattaforma cloud. Nel post di oggi cercheremo di capire dove, come, quando è perchè occorra affidarsi ad un gateway. Partiamo innanzitutto definendo il “dove”: immaginiamo uno stack IT a quattro livelli (Applicativo, Middleware, Server e Storage) con associati i tre livelli classici di servizio, ovvero SaaS (applicativo), PaaS (middleware) e IaaS (server e storage). Non tutte queste tipologie di servizio necessitano di gateway di storage.
Ipotizziamo che una compagnia decida di puntare tutto sul SaaS e passare nel cloud – come auspicato dai principali cloud provider. In questo scenario per entrare nel cloud sarebbe richiesto unicamente l’uso di alcuni dispositivi di accesso quali smartphone, tablet, personal computer e nient’altro. Il data center proprietario diventa quindi obsoleto e l’infrastruttura del provider cloud (completa di server, storage, applicazioni) diviene il nuovo punto di riferimento. Se separiamo tra di loro server e storage “collocandoli” in box distinti, ci troveremo di fronte ad uno scenario in cui dello storage rimarrà nel data center tradizionale mentre altro sarà spostato nel cloud tramite dei gateway cloud storage. Questa combinazione di utilizzo on-premise e cloud IT è chiamata cloud ibrido ed è la configurazione in cui è probabile incontrare un gateway.
La funzione base del gateway è quella di tradurre gli standard di accesso allo storage adoperati da un’azienda (iSCSI, CIFS/NFS) in API utilizzate in contesti cloud (REST, SOAP, Amazon S3). Da un punto di vista puramente concettuale si tratterebbe quindi solo di una funzione di transizione. Tipicamente un gateway cloud dovrebbe essere in grado di effettuare il trasferimento dati tra il data center ed il cloud in maniera più efficiente, obiettivo soddisfabile riducendo lo scambio di messaggi del protocollo e usando alcuni tipi di tecnologia di riduzione dei dati, quali la de-duplicazione. Non è una sorpresa il fatto che alcuni fornitori di gateway abbiano un buon background nell’ottimizzazione WAN; inoltre, per affrontare i problemi di sicurezza, i gateway cloud devono anche inglobare al loro interno capacità di crittografia per i dati da inviare.
Quali casi di utilizzo per un gateway
Quali dati salvare nel cloud? E’ una domanda che ci si pone spesso. Il cloud non è consigliato per l’archiviazione di dati primari per via di latenze troppo elevate e connessioni lente rispetto a quanto offerto da una modalità di accesso on-premise. Nel caso in cui si voglia tuttavia utilizzare il cloud come “storage primario”, il gateway dovrà necessariamente disporre di buone capacità di caching: solo in questo sarà possibile aggirare i problemi appena menzionati. Generalmente è poi bene ricordare che il cloud è molto più indicato per l’archiviazione di tutti quei dati a cui si accede saltuariamente e che non abbiano esigenze di tempo critico di accesso. In questi casi d’uso è altamente consigliato disporre di un backup dei dati on-premise.
Il cloud può essere concepito anche come un’opzione di disaster recovery in cui i dati sono memorizzati sia in una struttura interna di storage che nel cloud, trasformandosi di conseguenza in un buon strumento di backup. In questo caso può essere utile un gateway cloud dedicato, che aiuta a separare i dati operazionali dai dati di backup, il che spiega la diffusione della categoria dei gateway pensati per il backup. Nell’eventualità in cui si verichi un disastro o un incidente, con conseguente perdita di dati, anche il cloud storage fisico potrebbe andare irrimediabilmente perso con tutto il resto. Come aggirare il problema? La soluzione migliore è quella di ricorrere ad un gateway remoto virtualizzato. E’ possibile creare una macchina virtuale ed eseguirla da hypervisor nel cloud, sacrificando si la velocità ma minimizzando i danni di inaspettati incidenti/disastri.
Anche nel caso in cui un gateway cloud non sia disponibile come appliance virtuale, una cosa di cui tenere conto è che i dati nel cloud dovrebbero essere accessibili nativamente senza usare un gateway. Il lock-in, ovvero la rischiosa dipendenza da un unico provider di cui spesso si parla, è sicuramente poco gradito alle aziende. Nel momento in cui un fornitore chiude i battenti, cambia i livelli di servizio (SLA) o incrementa i prezzi… le aziende sono pronte a passare ad un altro provider? Quanto tempo occorrerà per portare a termine la migrazione? In queste situazioni possiamo pensare al gateway cloud come ad un punto logico per virtualizzare l’accesso al cloud provider.
Potrebbe anche aver senso acquistare il gateway da un venditore terzo rispetto ai provider cloud ai quali ci si affida, altrimenti un livello di virtualizzazione permetterebbe di associarsi a due diversi fornitori cloud, ognuno con diversi SLA a differenti prezzi: in questo caso il gateway va utilizzato per gestire automaticamente i dati – tipologie di dati da memorizzare e piattaforma cloud alla quale destinarli. In caso di necessità questo livello di virtualizzazione permetterebbe di effettuare una migrazione dal primo al secondo cloud provider.
