Sono sempre più grandi le quantità di dati che abilitano risorse e servizi cloud e sono sempre affidate alla connettività di rete che si riesce a garantire. Non importa che si tratti di una LAN che supporta un cloud privato o pubblico, o di una vasta WAN globale che supporta un cloud ibrido: il tema connettività resta fondamentale per ogni organizzazione ed è necessario affrontarlo in modo efficace, caso per caso.
È un lavoro che tocca agli architetti del cloud, chiamati a valutare le capacità, le configurazioni e i relativi costi della connettività LAN e WAN, per garantire una strategia e un’implementazione del cloud ibrido adeguata, affidabile ed economica.
Elementi chiave della connettività del cloud ibrido
Le principali aree di interesse della connettività del cloud ibrido sono tre: LAN, WAN e il provider di cloud pubblico.
LAN
Una rete aziendale privata, a lungo andare, risulta raramente sufficiente per supportare un cloud privato. Le risorse cloud devono essere disponibili su richiesta, ma i team IT non possono prevedere facilmente i modelli di utilizzo e i livelli di carico in un modello di cloud privato (interno): i colli di bottiglia della rete LAN possono emergere man mano che gli utenti attingono alle risorse. La buona notizia è che un cloud privato raramente ha un impatto sull’intera LAN, più che altro influisce sull’infrastruttura LAN associata ai server, allo storage e allo stack software del cloud privato.
Da un punto di vista fisico, la porzione di LAN dedicata al cloud privato deve essere valutata e aggiornata per supportare la scalabilità e la flessibilità. Questo potrebbe significare l’implementazione di switch ridondanti, più gateway WAN e un’ampia larghezza di banda LAN per gestire i picchi di carico di lavoro. Il monitoraggio strategico del traffico dovrebbe poi aiutare a identificare i colli di bottiglia e a giustificare gli aggiornamenti o le modifiche architettoniche alla LAN, sempre sotto il controllo dell’organizzazione proprietaria del cloud privato.
WAN
Il modo più semplice per collegare un cloud privato a uno o più cloud pubblici è attraverso Internet. Sebbene gli ISP offrano un’enorme larghezza di banda a prezzi accessibili, l’Internet aperto può essere però soggetto a interruzioni e congestioni. Inoltre, può esporre il traffico di rete non crittografato a minacce alla sicurezza.
Per risolvere questi problemi, è necessario mantenere un’applicazione e i suoi dati nello stesso luogo, sia che si tratti di un cloud pubblico, sia che si trovi in home. Va considerata anche la possibilità di effettuare una connessione WAN specifica tra il cloud privato e il provider di cloud pubblico, talvolta chiamata interconnessione dedicata. AWS, Microsoft e Google supportano questo tipo di servizi, disponibili presso i principali fornitori di telecomunicazioni regionali. Indipendentemente dalla connettività WAN, i cloud ibridi dovrebbero implementare una crittografia completa per tutti i dati a riposo e in trasmissione, per garantire la sicurezza dei dati aziendali in rete contro le minacce più frequenti e sempre più sofisticate.
Provider di cloud pubblico
Sebbene un’organizzazione non possa aumentare o modificare la LAN di un provider cloud, è comunque fondamentale considerare l’implementazione di cloud services lato provider da questo punto di vista. Servizi e attività del cloud pubblico, come la creazione di cloud privati virtuali (VPC) e di sottoreti, sono infatti spesso incorporati nei criteri e nei flussi di lavoro automatizzati dell’utente del cloud. Mettere a disposizione di un cloud pubblico le proprie risorse, per esempio, è un’attività che solitamente ricade sull’utente, aggravando i suoi oneri in termini di automazione e orchestrazione. In questo caso, di fatto, il cloud pubblico viene considerato come un’estensione di quello privato. Diventa quindi fondamentale sviluppare e mantenere quella coerenza necessaria per garantire flussi di lavoro fluidi e sicuri e l’interoperabilità tra cloud all’interno di un ambiente ibrido.
Inoltre, è necessario prendere in considerazione l’affidabilità del provider del cloud pubblici e le sue tempistiche, perché un cloud ibrido funziona solo quando sia il cloud privato che quello pubblico sono operativi. Eventuali tempi di inattività di uno dei due, dovuti a guasti hardware, configurazioni errate o altri fattori, compromettono tutto l’ecosistema
Considerazioni e prerequisiti per la connettività del cloud ibrido
Per stabilire e mantenere una connessione tra un cloud privato e uno pubblico, è importante comprenderne i requisiti di rete entrando nel merito del volume di dati, della velocità, della sicurezza e delle prestazioni. È necessario considerare sei parametri chiave.
Larghezza di banda
È in genere il parametro più comune legato alla connettività. Idealmente, rappresenta il volume di dati che una connessione di rete può gestire nel tempo, solitamente misurato in gigabit al secondo. Le esigenze di larghezza di banda WAN di un’azienda per un cloud ibrido sono influenzate dalla quantità di traffico che deve fluire tra il cloud privato e quello pubblico. I carichi di lavoro ad alta intensità e le applicazioni multiple che condividono simultaneamente la larghezza di banda disponibile possono generare volumi di traffico più elevati. In generale, per un’organizzazione è meglio iniziare con una connessione di larghezza di banda media e a basso costo e poi scalare in base alle necessità.
Una sola larghezza di banda aggiuntiva potrebbe non essere sufficiente a garantire un servizio adeguato, perché una singola connessione WAN rappresenta un potenziale singolo punto di guasto per il cloud ibrido. Meglio optare per più connessioni WAN unite e bilanciate, in modo da poter gestire larghezze di banda più elevate, pur garantendo la ridondanza.
Latenza
Questo parametro rappresenta il ritardo misurabile tra l’invio e la ricezione di un pacchetto. Con l’aumento della latenza, la reattività apparente di un’applicazione diminuisce, impattando sul livello di soddisfazione degli utenti e sulle attività time-sensible, come l’elaborazione dei dati IoT.
I principali fattori che influenzano la latenza sono la distanza fisica tra gli endpoint e tutti gli switch, i router, i gateway e le altre apparecchiature di rete che interagiscono con il singolo pacchetto. Per ridurla, è necessario minimizzare la distanza tra i cloud. Per esempio, collegare quello privato alla regione del cloud pubblico più vicina e utilizzare una connessione dedicata che riduca al minimo la quantità di apparecchiature di rete presenti tra i due siti.
Disponibilità e affidabilità
Se la connessione di rete è interrotta, il cloud ibrido nel migliore dei casi risulterà compromesso, ma più probabilmente tutto ciò che è presente sul cloud pubblico non sarà disponibile: dati e applicazioni. Un singolo punto di guasto introduce un rischio e una singola connessione tra un cloud privato e uno pubblico non può fornire una disponibilità del 100%. Va tenuto conto che una disponibilità del 99,95%, però, equivale a 21,91 minuti di downtime al mese.
È importante valutare la disponibilità e l’affidabilità delle connessioni, nonché il tempo di attività garantito nel contratto di servizio del cloud del provider. Per migliorare la disponibilità, è necessario stabilire una connettività ridondante per evitare singoli punti di guasto. Questa è un’opzione molto comune per migliorare la disponibilità del cloud ibrido e gestire la larghezza di banda. Anche le architetture LAN interne possono poi beneficiare di architetture di rete ridondanti. (L’architettura LAN interna del cloud provider non può essere modificata dagli utenti del cloud pubblico).
Sicurezza
Sebbene la sicurezza non sia una caratteristica fisica della rete, è necessario considerarne l’impatto sul traffico di rete. In generale, si consiglia di crittografare i dati delle applicazioni sia a riposo che in transito, e anche quelli di comando, controllo e configurazione. Si possono sfruttare le tecnologie più comuni come Secure Sockets Layer/Transport Security Layer, per impedire lo snooping e l’intercettazione. L’importante è collocare i dati nello stesso luogo dell’applicazione, per ridurre al minimo i trasferimenti di dati tra infrastrutture cloud private e pubbliche. Le organizzazioni che optano per una connettività Internet aperta possono spesso beneficiare anche di altre tecnologie di sicurezza, come le VPN o il peering diretto.
I costi
Una connessione dedicata attraverso un grande ISP regionale, può essere costosa. Gli oneri economici possono aumentare anche per le connessioni ad alta larghezza di banda, soprattutto quelle ridondanti. Tutto ciò può rendere il cloud ibrido proibitivo.
L’ingresso dei dati è praticamente gratuito con la maggior parte dei fornitori di cloud, ma l’uscita può rivelarsi costosa, a seconda della quantità di accessi e del volume di dati spostati. Le applicazioni vanno quindi pensate in quest’ottica, perché minimizzino uscite e spostamenti di dati tra regioni del cloud pubblico.
Monitoraggio e reportistica
Tenere controllate le metriche delle prestazioni LAN e WAN, come la larghezza di banda e la latenza, è molto importante. La comprensione delle performance dei segmenti di rete coinvolti nel cloud ibrido aiuta a identificare e risolvere i problemi e a giustificare gli aggiornamenti del servizio o del progetto, quando i requisiti del cloud ibrido cambiano nel tempo.
Best practices di connettività del cloud ibrido
Non esistono due architetture di cloud ibrido uguali. Ogni implementazione dipende dalle esigenze specifiche e dal budget dell’azienda. Tuttavia, queste best practice consentono di configurare la connettività del cloud ibrido senza spendere troppo:
- Conoscere i dati. Trasferire nel cloud solo la quantità minima di dati di un’applicazione. Identificare i dati corretti, proteggerli durante il trasporto attraverso la rete e assicurare la costante aderenza ai requisiti di compliance normativa.
- Mantenere la crittografia e verificare che i dati siano fisicamente conservati in regioni del cloud pubblico adeguate. Gli altri dati devono rimanere all’interno del data center locale e della LAN.
- Comprendere sicurezza e governance. I cloud ibridi sono soggetti a fattori di compliance normativa e di governance precisi. Non tutti i dati possono essere archiviati in tutti i cloud pubblici: dipende dalla sensibilità dei dati e del settore. La gestione della rete richiede attenzione a questioni quali la sovranità dei dati e la business continuity.
- Riconoscere i limiti della rete. I grandi trasferimenti di dati nel cloud pubblico sono in genere gratuiti, ma possono mettere a dura prova la limitata larghezza di banda LAN e WAN. La connettività WAN dedicata può evitare la congestione che a volte affligge la connettività Internet pubblica, ma anche questa opzione è spesso inadeguata. Meglio potrebbe essere optare su un servizio cloud, come AWS Snowball o Microsoft Azure Data Box, per trasferire fisicamente grandi volumi di dati al fornitore di cloud pubblico dell’azienda.
- Considerare l’elasticità delle applicazioni. Sebbene il cloud bursting sia difficile da implementare, a causa delle differenze fondamentali tra le architetture e i servizi dei cloud pubblici e privati, l’elasticità delle applicazioni è ancora un fattore importante nell’ambito del cloud ibrido. Il reindirizzamento del traffico applicativo aggiuntivo da un cloud privato a uno pubblico può richiedere una larghezza di banda di rete supplementare e aumentare i problemi di latenza. Si possono implementare le risorse e i servizi di rete per supportare istanze applicative, set di dati e bilanciamento del carico tra gli ambienti.
- Progettare la rete per scalare. È facile collegare una LAN a una WAN. Ma anche un solo collo di bottiglia della rete, come per esempio un solo gateway di rete on-premises, pone problemi di scalabilità e affidabilità. Quando si implementa la connettività del cloud ibrido, è necessario progettare la ridondanza e la scalabilità per evitare, ove possibile, singoli punti di guasto.
- Utilizzare criteri di configurazione comuni. L’automazione guida la configurazione di VPN, VPC, sottoreti e altre risorse di rete. Tuttavia, le risorse nel cloud privato sono in genere avviate e gestite in modo diverso rispetto al cloud pubblico. Ciò può comportare policy e flussi di lavoro diversi per gestire gli stessi tipi di attività su entrambi i lati del cloud ibrido. Per mitigare questi problemi, meglio puntare su policy e flussi di lavoro di rete comuni, anche per ridurre gli errori e accelerare le risposte. Molti fornitori IT offrono servizi che garantiscono un livello di parità tra gli ambienti, tra cui aziende con radici on-premises, come VMware e Red Hat. Anche AWS, Microsoft e Google offrono servizi che estendono i loro strumenti di gestione del cloud pubblico all’interno dell’azienda.
- Misurare e testare. Così come vengono monitorate le applicazioni, serve controllare anche le prestazioni e la disponibilità della rete, per supportare la gestione del cloud ibrido e consentire azioni correttive o la pianificazione della capacità a lungo termine in base a metriche o avvisi. Per ottenere una buona visione dell’ambiente LAN e del cloud pubblico potrebbe essere necessario un piccolo set di strumenti per la gestione dei log, delle prestazioni, delle applicazioni, delle prestazioni della rete e altri tool open source, per ottenere una visione end-to-end della rete del cloud ibrido.
Strumenti e opzioni per la connettività del cloud ibrido
Quando ci si prepara a realizzare ambienti di cloud ibrido, è necessario provvedere alla creazione della connessione, alla selezione di una piattaforma comune e alla gestione dell’ambiente cloud ibrido connesso:
- Connessioni. Collegare una rete privata a Internet e utilizzare servizi di cloud pubblico per creare un cloud ibrido è semplice. Le potenziali sfide della connettività Internet pubblica hanno però generato la disponibilità di connessioni dedicate che ormai la maggior parte dei principali fornitori di servizi di telecomunicazione può implementare. In alternativa, i fornitori di cloud pubblico offrono servizi di connessione dedicati, come Google Cloud Dedicated Interconnect, AWS Direct Connect, Azure ExpressRoute, Oracle Cloud Infrastructure FastConnect e IBM Cloud Direct Link.
- Piattaforme. Date le potenziali differenze tra le architetture dei cloud pubblici e privati, i cloud provider offrono oggi degli “ambienti unificati”, basati su tecnologie consolidate, come Kubernetes e VMware Cloud Foundation. Spesso favoriscono anche l’uso di stack tecnologici comuni, che consentono di replicare gli ambienti di cloud pubblico all’interno di un’infrastruttura on-premise, come AWS Outposts, Azure Arc, Azure Stack, Platform9 Managed OpenStack e Google Cloud Anthos. In effetti, chi adotta queste piattaforme comuni solitamente adotta anche l’infrastruttura del fornitore di cloud pubblico all’interno del cloud privato, per creare un ambiente cloud ibrido uniforme con servizi comuni.
- Strumenti. La gestione del cloud ibrido richiede anche l’uso di strumenti per monitorare e gestire componenti privati e pubblici, compresi reti e servizi. Molti di quelli per il cloud pubblico interagiscono con gli ambienti di cloud privato, come Amazon CloudWatch, AWS CloudTrail, Google Cloud Console e gli strumenti di gestione di Azure. Esistono anche molti strumenti di terze parti, tra cui CloudBolt, Cloudian, Cloudify, ManageIQ, Morpheus, Flexera Cloud Management Platform, IBM Turbonomic e Apptio Cloudability, oltre alle funzionalità di gestione incorporate nei principali stack, come OpenStack e Apache CloudStack.
Ciò che serve è valutare e selezionare la connettività, le piattaforme e gli strumenti più adatti alle esigenze della propria azienda e alla strategia di cloud ibrido a lungo termine.
