13/02/2018 Il mondo del cloud computing: point of failure, sia a livello architetturale che fisico, dei servizi oggi presenti sul mercato, ma anche nuove possibili soluzioni per l'alta affidabilità.

2. Introduzione
Layer Fisico
Dal bare-metal ai Servizi di Sistema
Andrea Di Marco
Virtualizzazione (VM / LXC / Cloud)
Cluster Engine
Servizi applicativi (un esempio)
Case Study: SysOpen
Architettura
Tecnologie

3. DEFINIZIONI
High Availability
Alta Affidabilità è la caratteristica di un sistema che mira ad
assicurare un livello di prestazioni concordato, solitamente in
termini di disponibilità e raggiungibilità, per un periodo di tempo
superiore al “normale”.
RAS
Reliability, Availability, Serviceability
In breve:
● Affidabilità Correttezza dell’output [MTBF]
detect e/o auto correzione dell’errore
● Disponibilità UpTime [Nines]
● Manutenibilità Tempo di riparazione [ETR]

4. DALBARE-METALAISERVIZI
Layer architetturali
L’alta affidabilità è chiaramente richiesta dal Business
e impatta su tutto lo stack tecnologico
dalla network (pila ISO/OSI)
alle applicazioni

5. PHYSICALLAYER
Data Center / Network
● Backbone / POP
● Routing
● Switch Fabric
● Servizi (es. SAN)
● UPS
Server
● RAM ECC
● Hot Swap
● RAID (w battery)
● Schede di Rete
● Alimentatori
● OFB Management

6. Una parola con tante sfumature
Virtualizzazione sottende molti concetti e il panorama è molto ampio.
Da IBM SIMMON (1960) a IBM z/VM (2000) da XEN (2003) alle tecniche di Hyperjacking…
Panoramica
VIRTUALIZZAZIONE
...fino ai sistemi cloud come, ad esempio, OpenStack.

7. Il computer nel computer
E’ l’implementazione logica più semplice del concetto di virtualizzazione.
Da fisico a virtuale il passaggio è trasparente.
VIRTUAL MACHINE
VIRTUALIZZAZIONE
Pro
● Isolato
● Indipendente
● Massimo Controllo
Contro
● Legacy
● Alto Overhead
● Provisioning “lento”
Come si pone rispetto ad un’architettura in HA ?

8. Una VM leggera
Perché avere un sistema operativo stand-alone quando possiamo separare solo la parte
“logica” che ci interessa? I container consentono di ottimizzare le risorse.
CONTAINER
VIRTUALIZZAZIONE
Pro
● Leggero
● Provisioning “rapido”
Contro
● Poco isolato
● Lock sul sistema operativo
● Scarsa indipendenza
Come si pone rispetto ad un’architettura in HA ?

9. Un nuovo approccio
Il cloud prende la virtualizzazione, sia VM che Container, il bare-metal e fonde tutto in un unico
sistema “as-a-service” che consente di prendere il meglio di tutte le tecnologie
(o almeno questo promette...)
CLOUD
VIRTUALIZZAZIONE
Come si pone rispetto ad
un’architettura in HA ?

10. CONFRONTO
VIRTUALIZZAZIONE
L’alta affidabilità totale è raggiungibile solo con un approccio bottom-up dal Networking
all’applicativo. Il mondo della virtualizzazione delega, di fatto, l’HA dell’hardware al fornitore del
servizio, in modo proporzionale allo stack “as-a-Service”.
- Il mondo cloud, container, VPS è realmente in HA?
- Come sono implementati i servizi dei principali provider?

11. Clustering
La ridondanza dei servizi, in molti casi, passa per il clustering a basso livello.
Le macchine parte di un cluster devono conoscere i reciproci stati per sapere se e quando
sono autorizzate ad operare (es. lock su un file o acquisizione di un IP).
Ci sono diversi modi di definire un cluster…
Multi-Master / Fail Over (aka Active-Passive)
CLUSTERENGINE

12. Clustering FOSS
Sono tecnologie molto mature, dal primo
HeartBeat (1999) che consentiva solo una
configurazione Active-Passive al primo CRM
PaceMaker (2004) fino CoroSync (2012) che
permette di raggiungere configurazioni
decisamente complesse.
HeartBeat / PaceMaker / CoroSync
CLUSTERENGINE

13. Clustering applicativo
Lo stack applicativo può essere clusterizzato se il software lo supporta.
(S)Vantaggi
I vantaggi presunti di un ambiente clustered sono talvolta dei pitfall prestazionali.
Ogni situazione richiede un’opportuna analisi.
Esempio: sessioni in Tomcat
KPI
I punti di attenzione sono, nella maggioranza dei casi, molto simili:
- Condivisione dei dati
- Concorrenza
- (Dis)allineamento
- Performance
- Fault Tolerance
Stack Applicativo
SERVIZIAPPLICATIVI

14. Esempio: Liferay Portal
Si trovano innumerevoli guide sul clustering di questo stack applicativo, tuttavia, eliminare
gli SPF non è così semplice come la raccontano e, spesso, si vedono architetture figlie del
compromesso, che di HA hanno ben poco… un esempio lampante arriva dal wiki del portale
stesso.
Apache / Tomcat / MySQL / FileSystem
SERVIZIAPPLICATIVI
Ci sono alcune lacune:
● Cluster tra Tomcat
● Loadbalancer (?)
● DB Controller (?)
● Lo storage condiviso
○ Lucene index
○ Repository
Forse non è così semplice,
ma si può fare.

15. CASESTUDY
CASE STUDY: SysOpen
Un’infrastruttura pensata per essere resiliente.
Un solo principio:
“Keep it Simple”
La volontà di erogare servizi in alta affidabilità ha condotto
ad un disegno architetturale che portasse a sistema le
principali tecnologie Open Source del settore
Per essere competitivi occorre poter offrire servizi efficaci,
efficienti e in linea con i prezzi di mercato.
L’infrastruttura che vedremo è stata progettata attorno alle
tre parole chiave RAS:
● Reliability
● Availability
● Serviceability
Approccio: Bottom-Up

18. Proxmox
- VE High Availability Cluster
- Multi-master Design
- Proxmox Cluster File System
- Corosync
- Web & CLI interface
- Auth Realms LDAP / AD / PAM / VE
- Proxmox Cluster File System
- IPMI Fencing
pfSense
- Snort IDS / IPS
- Common Address Redundancy Protocol
- IPSec / OpenVPN
SSD & SAS + Cloud
- Fast SSD Storage
- GlusterFS Replica
- Swift backup
DBaaS
- 3x HA Proxy
- KeepAliveD
- MariaDB w xtrabackup

19. CASESTUDY
Capacità
Il modello di infrastruttura esposto ha un tempo di
realizzazione non trascurabile (~10gu), ma è in grado di
ospitare un numero elevato di applicativi grazie
all’efficienza nella gestione delle risorse.
Ad oggi il sistema ospita circa 70 VM tra sistemi di
produzione, macchine di sviluppo, test e staging.
Questi i numeri (a causa di un fault in Farm)
Uptime 99.990%
MTBF 96 giorni
ETR 12h (senza reperibilità)
Costi e Ricavi:
Budget ~900€/mese
Gestione 4h / mese
Capacità del sistema 40% usato [RAM]
Guadagno +30%

20. CASESTUDY
Performance
L’infrastruttura presentata, comparata con server fisici
equipaggiati con SSD e Xeon E5, nonché con architetture
AWS complesse ha mostrato prestazioni superiori.
Esempio: Benchmark Magento (cliente reale)
OVH
[as-is]
AWS
[proposta n.1]
SysOpen
[proposta n.2]

21. Performance
Sono stati eseguiti dei test di carico su configurazioni in HA per
sostituire il bare-metal di un applicativo Magento.
Virtual Users: 0-100
Bare-Metal
Load Avg Time: ~520ms
AWS
Load Avg Time: ~7320ms
SysOpen
Load Avg Time: ~540ms
Costo
Bare-Metal NO HA
216 €/mese
AWS ~ HA
~500 €/mese
SysOpen HA
~ 500 €/mese
Risorse
Server Intel(R) Xeon(R)
CPU E5-1630 v3 @ 3.70GHz
2x2TB SATA
2x480GB SSD Raid HW
+
NAS 4TB - link GigaBit
2x Nodi PHP m4.large
1x Nodo di search
1x load balancer
1x disco shared EFS
1x Istanza memcached
1x Istanza RDS MariaDB
2x Bilanciatore NGINX
3x Nodi Applicativi
2x Nodo RedisCache
3x Storage SSD
1x Istanza MariaDB Percona
XtremeDB Cluster

22. CASESTUDY
Vantaggi
Il vantaggio di un sistema gestito in toto, non aaS, è insito
in quattro key-word:
● Flessibilità
● Supporto
● Prestazioni
● Risparmio
L’alta personalizzabilità del sistema, e l’unione di questo con
la gestione “managed” consente in modo evidente di
sgravare il cliente dai problemi architetturali e permette al
fornitore del servizio di sfruttare appieno le potenzialità
dell’hardware.

23. GRAZIE