Un cloud ibrido si riferisce a un ambiente misto di elaborazione, archiviazione e servizi costituito da infrastruttura locale, servizi di cloud privato e un'orchestrazione di cloud pubblico tra le varie piattaforme. L'utilizzo di una combinazione di cloud pubblici, elaborazione in sede e cloud privati nel data center significa disporre di un'infrastruttura cloud ibrida.
Le prestazioni hanno generalmente una priorità inferiore in un cloud ibrido, poiché l'obiettivo di disporre di un'infrastruttura cloud ibrida è comunemente rivolto al ripristino di emergenza, alla disponibilità e alla scalabilità. In questo post del blog tratteremo alcuni suggerimenti generali per migliorare le prestazioni delle nostre applicazioni, carichi di lavoro e cluster in esecuzione su una configurazione di cloud ibrido.
Host/istanze/risorse dedicati
Si dice che il costo dei servizi cloud sia inferiore a causa dell'ampia condivisione delle risorse. Tuttavia, un maggiore grado di condivisione significherebbe automaticamente minori garanzie di prestazione.
Le istanze cloud sono soggette a stabilità imprevedibile ma con alcuni costi aggiuntivi possiamo ridurre questo rischio con risorse dedicate. Le istanze dedicate sono istanze eseguite su hardware dedicato a un singolo tenant. In genere, gli host o le istanze dedicati sono fisicamente isolati a livello di hardware host dalle istanze che appartengono ad altri tenant. Ciò garantirà risorse adeguate al servizio e stabilizzerà praticamente le prestazioni dei tuoi carichi di lavoro nel lungo periodo. A seconda del tuo budget, hai più opzioni tra cui scegliere risorse dedicate come host dedicati, istanze o larghezza di banda.
Ci sono anche molte offerte e sconti se prevedi di eseguire le istanze per un periodo più lungo. Ad esempio, impegnandosi in AWS EC2 Reserve Instance, gli utenti possono risparmiare fino al 70% del costo dell'istanza rispetto ai costi standard su richiesta. Una volta che le applicazioni oi carichi di lavoro sono stati testati e pronti per la produzione, si consiglia vivamente di optare per un contratto a lungo termine, a condizione di allocare risorse sufficienti all'istanza per quel particolare periodo di contratto.
Gestione della larghezza di banda
La larghezza di banda è costosa. Ciò che è costoso è l'infrastruttura per trasportare la larghezza di banda da un luogo all'altro. La posa della fibra, l'hardware di instradamento di livello carrier e di livello provider, le spese generali di monitoraggio e manutenzione per mantenere tutto in funzione, il noleggio della suite di datacenter, il personale di un ingegnere del Network Operation Center (NOC) 24 ore su 24, 7 giorni su 7, contribuiscono tutti al prezzo elevato di un larghezza di banda affidabile. Per non parlare del ritmo della tecnologia, delle richieste degli utenti e della durata dei prodotti dei fornitori, spesso richiedono che una grossa fetta dell'investimento di cui sopra venga buttata via e il ciclo di vita ogni 7-10 anni, in alcuni casi 5 anni.
La maggior parte del cloud pubblico fornisce consente lo scambio di dati con altri Cloud Service Provider (CSP), realizzabile in diversi modi:
-
Trasferimento di dati tramite indirizzi IP pubblici su Internet.
-
Utilizzo di un servizio VPN gestito tra la rete locale e la rete CSP.
-
Connettiti direttamente dalla rete on-premise o dalle reti cloud private con l'altro CSP come Partner Interconnect per Google Cloud o AWS Direct Connect per AWS.
-
Trasferisci i dati all'altro CSP tramite un punto di presenza comune (POP).
-
Peering di rete con reti cloud private e rete CSP.
Queste opzioni differiscono in termini di velocità di trasferimento, latenza, affidabilità, accordi sul livello di servizio (SLA), complessità e costi. Indipendentemente dalle opzioni, l'idea è la stessa:minore è il trasferimento di dati utilizzato, minore è il costo.
Per ridurre l'utilizzo della larghezza di banda, la compressione è la cosa più importante da fare. La maggior parte dei servizi di replica ora supporta la compressione della connessione, che può ridurre notevolmente le dimensioni del trasferimento di dati tra più siti. Ad esempio, l'abilitazione della compressione della connessione per MySQL master-slave può facilmente ridurre l'utilizzo della larghezza di banda fino a 1,5 volte, senza configurazione aggiuntiva a livello di compressione o algoritmo. Questa è chiamata tecnica di compressione dei dati senza perdita di dati. Puoi impostare un rapporto di compressione ancora più alto, con un compromesso tra potenza di elaborazione per compressione e decompressione su entrambi gli endpoint.
Anche il posizionamento del carico di lavoro è importante. Con la configurazione del cloud ibrido, le applicazioni e i carichi di lavoro possono esistere sia su cloud privati che pubblici. Per le applicazioni interne, è molto meglio inserirle nel cloud privato più vicino a quelle locali con una latenza di rete inferiore. Per migliorare le prestazioni delle applicazioni pubbliche, posizionare le applicazioni sui server perimetrali di Content Delivery Network (CDN), che ridurrà notevolmente l'onere del server principale di gestire solo la richiesta dinamica e scaricare la distribuzione di contenuto statico su più server perimetrali, geograficamente più vicino agli utenti finali.
Crittografia più veloce
La crittografia in transito e a riposo è obbligatoria in una configurazione di cloud ibrido poiché possediamo solo una parte dell'infrastruttura. Non vogliamo che occhi indiscreti guardino i nostri dati durante la trasmissione, o il rischio di violazioni dei dati da furto o estranei che hanno accesso fisico ai nostri dati. In parole semplici, ogni parte dei dati in movimento o dei dati non fisicamente accessibili deve essere crittografata, punto. Tuttavia, alcune crittografie possono compromettere la velocità e le prestazioni dei carichi di lavoro.
Un errore comune è presumere che un messaggio crittografato utilizzando AES256 sia più difficile da decifrare rispetto alle stesse informazioni protette utilizzando AES128. È logico che una chiave di dimensioni maggiori introduca una maggiore complessità ma, come con qualsiasi sistema, le implementazioni sono soggette a debolezze. Supponendo che stiamo parlando di AES128 rispetto a AES256, c'è una nota debolezza nella funzione di espansione dei tasti che colpisce AES256. Fondamentalmente, la debolezza riduce la complessità di AES256 a quella inferiore a AES128.
Alcuni degli strumenti di tunneling come WireGuard sono noti per la loro crittografia più veloce e abbastanza semplici da implementare durante il tunneling tra più siti. Funziona in modo simile a come funziona la crittografia SSH, utilizzando un approccio di crittografia asimmetrica. Secondo questa ricerca, WireGuard è in media del 58% più veloce di OpenVPN in tutte le località testate. Una crittografia più veloce significa meno tempo per crittografare e decrittografare i dati, consentendo un aumento significativo delle prestazioni dello scambio di dati.
Se ti chiedi come configurare WireGuard VPN per un ambiente cloud ibrido, dai un'occhiata a questo post del blog, Distribuzione multi-cloud per la replica di MariaDB utilizzando WireGuard.
Monitoraggio di tutto
Gli ambienti basati su cloud si basano su un insieme complicato di risorse e identificare i problemi di disponibilità e prestazioni che influiscono maggiormente sui servizi aziendali è impegnativo. Il team operativo deve essere in grado di monitorare in modo olistico lo stato delle applicazioni, inclusi i componenti dell'infrastruttura cloud associati.
Il miglioramento delle prestazioni su un cloud ibrido non può avvenire senza un'ampia visibilità in tutte le risorse in ogni momento. Risorse come l'utilizzo dell'istanza e della rete, le prestazioni delle applicazioni, l'esperienza utente, la latenza e i file di registro sono molto importanti da raccogliere e campionare per garantire che possiamo risolvere proattivamente i problemi di prestazioni e disponibilità prima che raggiungano gli utenti finali o peggiorino. L'allocazione errata delle risorse avverrà sempre in un ambiente di approvvigionamento scadente, che alla fine porta a una scarsa pianificazione delle capacità e allo spreco di denaro e risorse.
La maggior parte dei provider di cloud pubblico offre servizi di monitoraggio approfonditi, che coprono più livelli e componenti dei servizi cloud in abbonamento. Tuttavia, il pezzo mancante è comunemente un'unificazione di monitoraggio tra diverse piattaforme cloud, provider e ambienti. Gli strumenti di monitoraggio all-in-one open source come Icinga, Nagios Core e Zabbix possono essere configurati per monitorare quasi tutto ciò che è coinvolto in un cloud ibrido, in particolare istanze, reti, servizi e applicazioni cloud.
Nel caso di monitoraggio delle prestazioni per i server di database nell'ambiente cloud ibrido, le seguenti risorse potrebbero essere d'aiuto:
-
Monitoraggio delle prestazioni di MariaDB in un cloud ibrido
-
Monitoraggio di PostgreSQL in un ambiente ibrido
