Nel post di oggi riprendiamo l’intervento di Tony Branson dal portale High Scalability. Il tema trattato da Branson riguarda la progettazione di infrastrutture resilienti e l’importanza di capire le differenze di significato tra i termini prestazioni, alta disponibilità e scalabilità – spesso utilizzati senza cognizione di causa o come sinonimi, osserva.
Prima di proseguire vi ricordiamo che un nostro precendente post dal titolo “Cloud: differenza tra continuità di servizio e scalabilità” potrebbe rivelarsi una interessante lettura da affiancare al post odierno. Iniziamo con il chiarire il significato di ciascun termine per poi passare ad alcune considerazioni in merito a ciascuna di esse.
Prestazioni
La parola si riferisce al throughput disponibile per uno specifico workload in un determinato intervallo di tempo. E’ importante ricordare che le prestazioni vanno quantificate testando l’affidabilità e la scalabilità di hardware, network e software. Un dato livello prestazionale non va infine considerato come un valore definitivo quanto transitorio: le operazioni di testing saranno una pratica costante nel reparto IT perchè legate ai cambiamenti che interesseranno nel tempo l’infrastruttura (aggiunta/eliminazione di funzionalità, nuovi servizi ed esigenze di business etc.).
Le performance sono legate ad alcune buone norme di scalabilità. Come vedremo nel paragrafo successivo, è infatti consigliato focalizzarsi su scalabilità ed investimenti in strumentazioni adeguata (anche di alto livello) piuttosto che su risorse infrastrutturali superiori alle nostre reali necessità.
Scalabilità
Si riferisce all’abilità di un’applicazione o di un sistema nel gestire elevati carichi di lavoro e soddisfare una maggiore richiesta di risorse di calcolo, rete etc. Tra gli errori più comuni, sottolinea Branson, vi è la cosiddetta ottimizzazione eccessiva (over optimization), il basare quindi la propria strategia su risorse infrastrutturali sovradimensionate rispetto alle reali esigenze. Ciò comporta una serie di svantaggi quali costi totali incrementati e perdita di capitale in investimenti che non generano un ritorno finanziario. Un approccio del genere necessità non solo di molto tempo ma anche di un team di ingegneri di alto livello. Come anticipato nel punto precedente è molto meglio investire “30” in strumentazione di alto livello che “100” in piani di scalabilità che si dilungano per troppi mesi e dilapidano tempo e budget prezioso.
Il Service Level Agreement (SLA) è importante per determinare la tipologia di scalabilità necessaria. Cosa si intende per scalabilità verticale ed orizzontale? La prima, ideale ad esempio per un trading system che esige scalabilità immediata, prevede l’upgrade del sistema esistente, ovvero l’aggiunta di risorse fisiche quali storage, memoria e CPU. I principali benefici della scalabilità verticale sono: il preservamento della compatibilità delle applicazioni (non occorre apportare modifiche al codice), mansioni amministrative nella norma (bisogna occuparsi di un unico sistema).
La seconda si concentra ugualmente sull’aumento di capacità ma opta per la suddivisione del carico di lavoro tra diversi database server più piccoli. In questo modo è possibile ospitare i dati in più server liberando risorse per la manutenzione del sistema e riducendo il carico di lavoro sui nodi esistenti. La scalabilità orizzontale consente: di limitare le spese sfruttando sistemi meno costosi, di supportare al volo incrementi lineari di capacità, maggiore resilienza (il downtime di un sistema non sarà in grado di bloccare tutte le operazioni in corso).
Alta disponibilità
Si utilizza questo termine per indicare un servizio o applicazione che rimane costantemente utilizzabile/operativo e che non subisce quindi alcuna interruzione. Un servizio è in alta disponibilità quando non risente minimamente di inaspettate problematiche – come un guasto improvviso ad uno o più server etc. Assicurarsi che le applicazioni ospitate nel tier intermedio continuino ad essere eseguite richiede la presenza di un meccanismo di failover che reindirizzi le query, con una copia degli stessi dati, ad un altro server.
In queste situazioni la disponibilità può essere raggiunta assicurandosi che: sia stato effettuato il deploy dei medesimi componenti in ogni istanza del cluster; il meccanismo di failover sia “consapevole” della posizione e delle disponibilità o meno dei nodi presenti in quel cluster; il meccanismo di failover sia in grado di seguire l’avanzamento di tutte le task ed effettuare all’occorrenza un roll back nel caso in cui le operazioni non vadano a buon fine.
Per puntare ad elevati livelli di resilienza è consigliato affidarsi anche a software per il load balancing del database, un elemento “trasparente” che si colloca tra il database server e le applicazioni ed è in grado di reindirizzare istantaneamente il traffico senza alcune modifiche all’applicazione. Tra gli altri vantaggi: scalabilità orizzontale trasparente e scalabilità verticale istantanea, continuità lavorativa anche con elevati volumi di traffico, tempistiche di risoluzione dei problemi ridotte, procedure di failover automatiche senza alcun downtime ed interruzione.
