Server dedicato o cloud?

Storicamente ho sempre preferito i server dedicati alle soluzioni virtuali o cloud di vecchio stampo, semplicemente perché per un costo fisso si ricevono risorse dedicate e garantite, mentre con i server virtuali o le soluzioni cloud di prima generazione non erano sempre garantite, inoltre era sempre presente il rischio di noisy neighbours, cioè di “vicini rumorosi” presenti sullo stesso server fisico o cluster. Vale a dire che se capitava di avere la propria macchina virtuale su di un server fisico dove risiedeva un cliente che consumava in modo accentuato per esempio le risorse dei dischi o la CPU, spesso questo aveva ripercussioni sulla performance e particolarmente sulle latenze del proprio server virtuale in situazioni di carico.

Ma con il sopravvenire di nuove tecnologie e metodologie – quello che noi chiamiamo il Cloud 2.0 ed io personalmente l’IaaS come deve essere –  queste problematiche che ho suddiviso in quattro fattori sono state in gran parte risolte:

1. Sul nostro Cloud 2.0 tutte le risorse sono dedicate e garantite al 100%. Vale a dire che se si ordinano 2 CPU Cores e 4 GB di RAM, queste risorse – una volta lanciato il server cloud – vengono dedicate esclusivamente e garantite al 100% – niente overbooking, niente garanzia solo del 50% come fanno alcuni nostri competitor ecc.
   Questo perché se si utilizza una politica di allocazione risorse di tipo shared o dinamica si riscontrano i problemi di latenza precedentemente descritti anche con i migliori sistemi. Con le risorse garantite al 100% e dedicate esclusivamente invece non c’è il rischio che il sistema in caso di picchi inaspettati debba spostare dinamicamente risorse da una istanza (che magari utilizzava in modo dinamico più risorse) ad un’altra (che normalmente utilizza meno di quanto previsto/di quanto ordinato ma che in casi di picco ne ha bisogno). Anche se questo meccanismo dinamico funziona bene ed è stato perfezionato negli anni, c’è sempre una certa latenza che impedisce di garantire tempistiche stabili in ogni situazione.
   Dedicare le risorse assegnate alle singole istanze cloud è l’unico modo per poter garantire tempi di risposta stabili e prevedibili.
2. Per quanto riguarda la connettività verso l’internet (l’upstream) grazie agli standard 10GE (10 Gbps su Ethernet) e 40GE (40 Gbps su Ethernet) per server fisico è possibile garantire banda sufficiente e latenza bassa prevedibile ad ogni singola istanza cloud.
   Prendiamo come esempio di calcolo – non pratico, ma come caso estremo – i server fisici più potenti che utilizziamo per supportare la nostra infrastruttura Cloud 2.0: 64 CPU Core (fisici!), 256 GB di RAM ECC, connessione InfiniBand fino a 2 x 40Gbps, connettività internet 1x 40GE o 2x 10GE. Di queste risorse togliamo 2 CPU Core e 16 GB di RAM per l’hypervisor e rimangono 62 CPU Core e 240 GB di RAM assegnabili alle istanze cloud. Con un minimo di 1 CPU Core per istanza cloud si riescono a lanciare 62 cloud server con 3GB+ di RAM. Dividendo la banda passante esterna per 62 si ottengono 645 Mbps (con 40GE) oppure 322 Mbps di banda disponibile garantita per istanza cloud, ampiamente superiore a 100Mbps o 200 Mbps (i tagli tipici scelti dai clienti).
   Quindi anche la banda passante non è più un problema.
3. Quello che rimane sono la performance dello storage, sia per quanto riguarda il throughput in lettura ed in scrittura, cioè quanti dati si riescono a leggere o scrivere al secondo, che per le operazioni input/output al secondo (IOPS), cioè quante operazioni di lettura o scrittura si riescono a fare al secondo.
   Faccio questa distinzione perché il throughput stesso non è quasi mai un problema, essendo le applicazioni che girano sul cloud quasi sempre o CPU-bound, RAM-bound o IOPS-bound. Mi spiego meglio: praticamente tutti gli storage moderni con dischi SSD o sistemi ibridi riescono a fornire throughput sufficiente sia in lettura che scritture in ambienti multi-threaded per le applicazioni tipiche (web-server, database-server ecc.) escluso lo streaming, l’OS paging (che va evitato comunque) e server di log particolarmente carichi. Un singolo disco SSD moderno da solo riesce a fornire circa 500MB/s, mentre circa 150-180MB/s normalmente sono sufficienti.
4. Mentre il discorso cambia per quanto riguarda gli IOPS, cioè le operazioni di lettura e scrittura al secondo. Un singolo disco SSD moderno in modalità mista (80% lettura, 20% scrittura) riesce a fornire al massimo 10-15.000 IOPS, mentre un disco rigido SAS o SATA riesce a fare 25-150 IOPS. Considerando che lo storage primario sul cloud viene utilizzato perlomeno da uno se non da più cluster e che un cluster normalmente ha da quattro a sedici server fisici, moltiplicando per il massimo di 62 istanze cloud come precedentemente ipotizzato, lo storage primario deve avere almeno 100.000 IOPS per poter garantire 100 IOPS per istanza in media (ca. 992 istanze su cluster da 16 server fisici). Se si ha bisogno di più IOPS per singola istanza cloud si deve predisporre un cloud privato in modo adeguato, utilizzare il cosiddetto local storage per una istanza cloud specifica (rendendo però l’istanza stessa non più migrabile facilmente!) oppure passare ad un server dedicato per questo tipo di carico.

• Fidarsi è bene.

  Provare è meglio!

• Consulenza.

  Problemi con il cloud?

• Dedicati.

  Scopri la gamma