Diventa Autore per CoreTech | Scopri di più
26/08/19 CoreTech Blog
.png)
I server virtuali in ambiente cloud possono essere chiamati con nomi commerciali differenti in base al cloud provider che eroga il servizio.
Di seguito alcuni esempi di come vengono chiamati i cloud server dai diversi Provider
Di fatto un cloud server è un server virtuale che gira in un ambiente di virtualizzazione, generalmente uno tra: kvm, vmware, hyperv-v, xen
Nota. Per comodità vengono utilizzate delle immagini di VMware, ma non si parla specificatamente di VMware nell'articolo!
Per quanto inerente un server virtuale ospitato presso un cloud provider, il mercato al momento non offre una "definizione" standard per ciò che riguarda l'infrastruttura tecnica su cui risiede.
Questo implica che tutte le offerte possono sembrare uguali e differire solo per il prezzo.. ma in realtà non sono uguali!
Una prima distinzione può essere fatta in merito all'architettura sottostante, se si tratta di server virtuali ospitati in un infrastruttura in cluster oppure su singolo server fisico.
La similitudine più immediata per rendere il concetto è quella che attiene agli aerei.
Un aereo a due o più motori è paragonabile ad un infrastruttura cluster e da la garanzia di poter continuare a volare anche quando uno dei motori si guasta, a differenza di un aereo mono motore, paragonabile ad un server singolo.
Su un aereo bimotore o quadrimotore i passeggeri hanno maggiori garanzie di quelle che possono avere su un aereo mono motore.
Un cluster è l'insieme di 2 o più server fisici connessi tra loro, che sono in grado di offrire Fault Tolerance* (tolleranza ai guasti) dei server virtuali su di essi ospitati, quando si verifica un problema hardware.
*andare a fine articolo...
I Server fisici che costituiscono un cluster vengono anche detti Nodi del cluster.
Un Nodo di un cluster è in pratica un Hypervisor (kvm, vmware, hyper-v, xen) ospitato da un server fisico nel quale trovano posto CPU, RAM e Schede di Rete, ma "NON" lo storage (gli hard disk... salvo configurazione tipo vSAN generalmente non utilizzata dai cloud provider).
Immagine fisico-logica di come è costituito un cluster. A sinistra si vedono gli hypervisor (i server fisici) e a destra si vede lo storage che è accessibile da tutti e 3 i server fisici che costituiscono il cluster.
Attraverso la funzionalità offerta dal sistema di virtualizzazione, viene garantita la continuità di servizio qualora uno dei nodi del cluster dovesse avere un guasto hardware.
Il sistema di virtualizzazione gestisce l'indisponibilità di uno dei nodi del cluster, spostando i carichi di lavoro (i server virtuali) verso il nodo (o i nodi) che funziona correttamente.
Per poter procedere allo spostamento immediato dei server virtuali, il file immagine del server virtuale deve stare su uno storage condiviso. Il file immagine in pratica è il disco virtuale che contiene tutta la macchina virtuale/server virtuale.
Lo storage condiviso può essere di tipo Direct Attached, cioè collegato alla controller dello storage tramite cavi SAS o Fibra Ottica, oppure può trattarsi in uno storage di rete, quindi accessibile appunto tramite rete (cavo di rame o fibra). Nel secondo caso tra gli hypervisor e lo storage c'è di mezzo uno switch di rete che mette in comunicazione i server fisici con lo storage (SAN che sta per Storage Area Network).
Quando si sceglie di offrire un infrastruttura Cluster, tornando all'analogia, bisogna considerare che se un motore va in avaria, l'altro motore deve poter sostenere tutto il carico dell'aereo senza mettere in pericolo i passeggeri.
Questo significa che se si ha un cluster a 3 nodi (3 hypervisor, ovvero 3 server fisici), la capacità di calcolo (CPU e RAM) di tutti e 3 i server fisici, non viene utilizzata completamente, ma si lasciano inutilizzate parte delle risorse dei server, almeno abbastanza da coprire l'eventuale mancanza (guasto) di 1 server.
Ad esempio, su un cluster a 3 nodi si lasciano inutilizzate almeno un terzo delle risorse di CPU e RAM, in pratica un hypervisor non viene utilizzato!
Molte offerte di server cloud, a dispetto di quello che pensano spesso tante persone, NON sono ospitati in un infrastruttura in Cluster, quindi non c'è Fault Tollerance
E lo so che a qualcuno sembrerà brutta questa cosa ma è così. Danno tutti per scontato che in CLOUD tutto sia ridondato, ma questa è una falsa credenza.
Se la scheda madre del server che ospita il server virtuale si rompe, tutti i server su di esso ospitati smettono immediatamente di funzionare e non ripartono su un altro server. Inoltre visto che il servizio di backup dei server è generalmente escluso, se non acquistato a parte, qualora si rompessero i dischi, non è detto che il cloud provider sarebbe in grado di ripristinare i server virtuali ospitati sul sull'hypervisor.
Ogni server virtuale viene ospitato da un unico server fisico sul quale è presente comunque un sistema di virtualizzazione tra kvm, vmware, hyper-v o xen.
Su tale server fisico trovano posto CPU, RAM, Schede di rete e STORAGE.
.png)
Lo storage è composto da dischi locali installati sul singolo server.
Il pro di una scelta di questo tipo da parte del cloud provider è che l'infrastruttura ha un costo minore e le velocità di accesso al disco possono (ma non è detto perchè dipende dalla densità di vm per singolo hypervisor) essere più elevate rispetto a quelle disponibili in un infrastruttura con storage condiviso. Inoltre hard disk SSD per lo storage locale di un server fisico possono avere un costo nettamente inferiore rispetto a dischi SSD delle medesime capacità, ma per sistemi storage condivisi (SAN), perchè questi ultimi richiedono dischi SSD di fascia enterprise.
Il primo è un disco SSD SATA3 che può essere usato anche su server. Non è tra i dischi più economici (143 euro per 1TB)!
.png)
Questo disco invece è un SSD SAS di fascia enterprise (336 euro per 1TB). Lo stesso identico disco (eventualmente con Firmware "modificato") con il brand di un produttore di server come HP o DELL costa 4 o 5 volte tanto.
.png)
Da questo esempio si può vedere che solo i dischi di fascia enterprise per storage di rete costano più del doppio dei dischi per i server stand alone (singoli server).
Purtroppo i cloud provider non fanno sempre chiarezza su quale sia l'infrastruttura sottostante la propria offerta commerciale.
Di seguito ci sono alcune immagini relative alle offerte commerciali di differenti provider.
Da alcune di queste immagini si riesce a comprende che l'offerta si riferisce a server virtuali ospitati su storage condivisi probabilmente configurati in un infrastruttura cluster, senza che però vengano spiegate più nel dettaglio agli elementi...
Esempio 1
.png)
Esempio 2
.png)
Esempio 3
.png)
Da altre immagini è esplicitato chiaramente che ci si riferisce a dischi locali (intesi come dischi installati localmente sui server fisici), mentre in altre immagini ancora, l'offerta non è per niente chiara e si parla unicamente di dischi.
Esempio 1. Si legge Local RAID, sta a significare che i dischi sono locali sul server.
.png)
Esempio 2.
In questa immagine si fa riferimento al fatto che è disponibile un offerta più affidabile che fa uso di storage su SAN, ad indicare che l'altra offerta (sempre la loro) non ha lo storage su SAN. Infatti in questa offerta si fa riferimento a dischi con il termine HDD, mentre l'altra offerta pubblicizzata nella pagina parla di dischi SSD (dischi montati localmente sui server)
.png)
Come si può capire, server virtuali ospitati in un infrastruttura cluster rispetto a server virtuali ospitati su un singolo server fisico, hanno caratteristiche di Fault Tollerance e Disponibilità differenti... e di conseguenza costi differenti.
A prescindere quindi dai nomi utilizzati per indicare i cloud server, i prodotti sono simili ma non tutti uguali.
Come si vede da questa immagine alcuni provider scrivono il caso d'uso per l'offerta specifica. Però anche un "esperto" può rimanere confuso dalla descrizione. Prima si fa riferimento al fatto che l'offerta sia adatta a "esperimenti iniziali" e "lavoro di sviluppo" e una riga più sotto si parla di inclusione di bilanciamento di carico e scalabilità automatica.
.png)
Giungiamo alle conclusioni. Chi ha letto tutto l'articolo avrà ora maggiori elementi per farsi un idea delle offerte che il mercato mette a disposizione e di come cercare di leggerle e capire cosa acquisterà.
In generale è necessario guardare bene le offerte spulciando sia nelle descrizioni che eventualmente nelle KB e se non basta meglio scaricarsi il contratto di vendita e leggerlo tutto, alla ricerca di maggiori dettagli.
Purtroppo il marketing preferisce non dare troppe informazioni tecniche e solo andando a caccia delle postille si riesce a volte a capire cosa si sta' acquistando.
Ci auguriamo che il mercato maturi al punto da dare la più ampia trasparenza ai clienti, nel frattempo bisogna armarsi di pazienza e informarsi.
Per ogni suggerimento sui contenuti, o per segnalare eventuali errori, sentitevi liberi di commentare o di contattarmi eventualmente al mio indirizzo email roberto.beneduci@coretech.it
*Quando si parla di Fault Tolerance non si intende la fault tolerance di VMware che è una caratteristica del sistema di virtualizzazione per cui 2 hypervisor sincronizzano tra loro memoria e registri cpu di una stessa VM al fine di garantirne la massima disponibilità senza necessità che la VM venga riavviata in caso di guasto di uno degli hypervisor.
Il termine viene usato per indicare la capacità del sistema di sopperire a dei guasti di un hypervisor fisico garantendo una maggiore disponibilità del servizio, nel caso specifico del server virtuale ospitato. Che la VM si debba riavviare o meno è un fattore non rilevante ai fini della spiegazione dell'articolo.
