Introduzione alla realizzazione di un datacenter cloud-enabled Un case study

Transcript

1 Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Introduzione alla realizzazione di un datacenter cloud-enabled Un case study Corso di Sistemi Distribuiti e Cloud Computing Stefano Iannucci iannucci@ing.uniroma2.it Anno accademico 2011/12

2 Cloud Computing Cloud Computing: un paradigma emergente... Classificato secondo il livello di accesso: Private Cloud Public Cloud Hybrid Cloud Community Cloud Classificato secondo la tipologia di servizio offerto: Infrastructure as a Service (IaaS) Platform as a Service (PaaS) Software as a Service (SaaS)

3 Cosa c'è sotto il livello IaaS? Servizi di Cloud Computing strutturati a livelli Ogni livello offre un servizio al livello superiore Ogni livello sfrutta i servizi offerti al livello inferiore SaaS PaaS IaaS???

4 Scopo della lezione Fornire le basi per la progettazione architetturale di una infrastruttura cloud-enabled con caratteristiche di: Modularità Estendibilità Affidabilità e disponibilità Scalabilità Inoltre l'infrastruttura deve supportare qualsiasi tipo di uso da parte dei livelli superiori (deve essere general purpose) e sarà basata interamente su software open source.

5 Cos'è un servizio? Definizione OASIS: Un meccanismo per consentire l'accesso ad una o più funzionalità, dove l'accesso è fornito utilizzando un'interfaccia nota, consistentemente con vincoli e politiche specificate nella descrizione del servizio Punto di vista di oggi: Applicazione che esegue un dato compito. Richiede: CPU Memoria Dischi Rete Chi offre tali requisiti? Macchine server, sistemi di storage, dispositivi di rete

6

7 1 passo: disaccoppiamento Disaccoppiamento ed aggregazione delle risorse Due componenti principali nell'architettura Front-end subnet Back-end subnet Front-end subnet Dominio computazionale Tanti server diskless Back-end subnet Dominio dello storage Tanti sistemi di storage SaaS PaaS IaaS Front-end subnet Back-end subnet

8 La back-end subnet Obiettivi: Disaccoppiare i sistemi di storage dalle macchine che li richiederanno Aggregare sistemi di storage (possibilmente diversi) per raggiungere la massima espandibilità possibile Aggiungere politiche di gestione e replicazione Minimizzare i costi hardware Fornire una sorgente di backup rapida, efficace e semplice Fornire un sistema per la gestione delle risorse computazionali presenti nella front-end subnet Molti obiettivi hanno una soluzione in comune Aggiunta di un layer di disaccoppiamento tra sistemi di storage e macchine server aggiunta di uno storage gateway Vi ricorda qualcosa?

9 Una prima ipotesi di back-end subnet

10 La back-end subnet Obiettivi: Disaccoppiare i sistemi di storage dalle macchine che li richiederanno Aggregare sistemi di storage (possibilmente diversi) per raggiungere la massima espandibilità possibile Aggiungere politiche di gestione e replicazione Minimizzare i costi hardware Fornire una sorgente di backup rapida, efficace e semplice Fornire un sistema per la gestione delle risorse computazionali presenti nella front-end subnet Molti obiettivi hanno una soluzione in comune Aggiunta di un layer di disaccoppiamento tra sistemi di storage e macchine server aggiunta di uno storage gateway Vi ricorda qualcosa?

11 Aggregazione di diversi sistemi di storage Lo storage gateway possiede tanti Host Bus Adapter (HBA) quanti sono i sistemi di storage a lui collegati Solitamente un sistema di storage supporta: Gestione del RAID Gestione di volumi logici Possiamo utilizzarle? Gestione di funzionalità avanzate (es. replicazione) Solitamente un sistema di storage espone le proprie risorse come: Block layer: Dispositivi a blocchi su FC Dispositivi a blocchi su iscsi File layer: Condivisione file SMB/CIFS Condivisione file NFS

12 Aggregazione di diversi sistemi di storage Lo storage gateway possiede tanti Host Bus Adapter (HBA) quanti sono i sistemi di storage a lui collegati Solitamente un sistema di storage supporta: Gestione del RAID Gestione di volumi logici Gestione di funzionalità avanzate (es. replicazione) Solitamente un sistema di storage espone le proprie risorse come: Block layer: Dispositivi a blocchi su FC Dispositivi a blocchi su iscsi File layer: Condivisione file SMB/CIFS Condivisione file NFS

13 Aggregazione di diversi sistemi di storage (2) Logical Volume Management Famiglia di software per la gestione flessibile dello storage Condividono solitamente lo schema base di funzionamento a tre livelli di astrazione: Physical Volumes (PVs)(costituiti da Physical Extents) Volume Groups (VGs) Logical Volumes (Lvs) Sono in ogni caso layer applicati al di sopra di dispositivi a blocchi I LV sono dispositivi a blocchi

14 Aggregazione di diversi sistemi di storage (3) Caratteristiche tipiche di un Logical Volume Manager: Ridimensionamento (nella maggior parte dei casi online) dei VG tramite: Aggiunta di PV Rimozione di PV Ridimensionamento di LV tramite: Concatenazione di nuovi PE Distacco di PE Creazione di snapshot di volumi sfruttando Copy On Write (COW) Read-only Read/write Supporto delle più comuni configurazioni RAID Spostamento di LV su altri PV (a volte online)

15 Aggregazione di diversi sistemi di storage (4) Linux Logical Volume Manager (LVM) Presente in differenti versioni da molti anni in Linux Implementa tutte le funzionalità viste finora Utilizza il framework device-mapper del kernel Linux (serve per mappare device a blocchi su device a blocchi) Molto semplice da utilizzare Comandi relativi a PVs cominciano con pv Comandi relativi a VGs cominciano con vg Comandi relativi a LVs cominciano con lv

16 Aggregazione di diversi sistemi di storage (5) Esempio di uso di LVM per aggregare le capacità di due device: /dev/sda e /dev/sdb Creazione di due PV: pvcreate /dev/sda pvcreate /dev/sdb Creazione di un VG vgcreate mygroup /dev/sda /dev/sdb Creazione di un LV lvcreate -L dimensione -n myvol mygroup Formattazione del LV mkfs.ext4 /dev/mygroup/myvol

17 La back-end subnet Obiettivi: Disaccoppiare i sistemi di storage dalle macchine che li richiederanno Aggregare sistemi di storage (possibilmente diversi) per raggiungere la massima espandibilità possibile Aggiungere politiche di gestione e replicazione Minimizzare i costi hardware Fornire una sorgente di backup rapida, efficace e semplice Fornire un sistema per la gestione delle risorse computazionali presenti nella front-end subnet Molti obiettivi hanno una soluzione in comune Aggiunta di un layer di disaccoppiamento tra sistemi di storage e macchine server aggiunta di uno storage gateway Vi ricorda qualcosa?

18 Una prima ipotesi di back-end subnet SPOF! SPOF! SPOF!

19 Una seconda ipotesi di back-end subnet

20 Una seconda ipotesi di back-end subnet

21 Distributed Redundant Block Device (DRBD)

22 Replicazione dello storage con DRBD Funzionalità di DRBD... Replicazione sincrona, asincrona, memory-sincrona Mascheramento degli errori di I/O Recovery automatico, con sincronizzazione sul diff Funzionamento basato su ruoli: primario e secondario Nodo primario abilitato a montare il filesystem presente nella risorsa DRBD Nodo secondario abilitato a montare il filesystem solamente se questo è di tipo distribuito (GFS, OCFS2) Il nodo secondario può diventare primario in caso di fallimento del primario Tale scenario è gestito da software per alta disponibilità come Heartbeat E' un layer e deve essere posizionato su un device a blocchi Su un disco (es. /dev/sda) Su una partizione (es. /dev/sda1) Su un volume LVM (es. /dev/mygroup/myvol) E' a sua volta un device a blocchi

23 Esempio di configurazione di DRBD resource r1 { protocol A; startup { wfc-timeout 15; degr-wfc-timeout 60; } disk { on-io-error detach; } net { cram-hmac-alg "sha1"; shared-secret secret ; max-buffers ; max-epoch-size 16384; sndbuf-size 0; rcvbuf-size 0; } on primary { device /dev/drbd0; disk /dev/sdc1; address :7788; meta-disk internal; } on secondary { device /dev/drbd0; disk /dev/repdata/imgos; address :7788; meta-disk internal; } }

24 La back-end subnet Obiettivi: Disaccoppiare i sistemi di storage dalle macchine che li richiederanno Aggregare sistemi di storage (possibilmente diversi) per raggiungere la massima espandibilità possibile Aggiungere politiche di gestione e replicazione Minimizzare i costi hardware Fornire una sorgente di backup rapida, efficace e semplice Fornire un sistema per la gestione delle risorse computazionali presenti nella front-end subnet Molti obiettivi hanno una soluzione in comune Aggiunta di un layer di disaccoppiamento tra sistemi di storage e macchine server aggiunta di uno storage gateway Vi ricorda qualcosa?

25 LVM + DRBD o DRBD + LVM? Sia LVM che DRBD operano su device a blocchi Sia LVM che DRBD forniscono a loro volta device a blocchi LVM DRBD Disco fisico DRBD LVM Disco fisico

26 Entrambi!! LVM DRBD Disco fisico Storage primario DRBD LVM Disco fisico Storage replica Lo strato LVM sul nodo replica ci consente di ottenere uno snapshot di tutto ciò che si trova ai livelli superiori Cosa si trova al livello superiore di LVM sul nodo Storage replica?

27 DRBD + LVM e LVM + DRBD LVM LVM DRBD Disco fisico Storage primario DRBD LVM Disco fisico Storage replica Anche trovandoci sul nodo DRBD con ruolo secondario possiamo accedere al contenuto dei LV LVM contenuti al di sopra dello strato DRBD eseguendone uno snapshot al livello inferiore Possiamo eseguire un backup dei dati in modo del tutto asincrono rispetto al normale funzionamento del sistema

28 L'architettura di storage completa

29 La back-end subnet Obiettivi: Disaccoppiare i sistemi di storage dalle macchine che li richiederanno Aggregare sistemi di storage (possibilmente diversi) per raggiungere la massima espandibilità possibile Aggiungere politiche di gestione e replicazione Minimizzare i costi hardware Fornire una sorgente di backup rapida, efficace e semplice Fornire un sistema per la gestione delle risorse computazionali presenti nella front-end subnet Molti obiettivi hanno una soluzione in comune Aggiunta di un layer di disaccoppiamento tra sistemi di storage e macchine server aggiunta di uno storage gateway Vi ricorda qualcosa?

30 Una seconda ipotesi di back-end subnet SPOF!!! SPOF!!! SPOF!!! SPOF!!!

31 Una terza ipotesi di back-end subnet

32 Aggregazione di canali di rete Problema: Una singola connessione di rete può costituire un Single Point Of Failure dell'intero sistema Un singolo switch può costituire un Single Point Of Failure dell'intero sistema Una singola connessione verso un sistema di storage può costituire un Single Point Of Failure dell'intero sistema (non vedremo oggi storage multi-pathing) Soluzione Aggregazione dei canali di rete

33 Aggregazione dei canali di rete (2) Aggregazione dei canali di rete eseguita a livello Logical Link Control (LLC) della pila OSI Disponibile in Linux il driver bonding Crea un'interfaccia di rete virtuale (Master) denominata bondx, alla quale vengono associate diverse interfacce di rete fisiche ethx (slave) Diverse modalità operative: balance-rr active-backup broadcast 802.3ad (Cisco EtherChannel/LACP) balance-tlb balance-alb

34 Aggregazione dei canali di rete (3) balance-rr I frame ethernet vengono inviati in ordine sequenziale dalla prima interfaccia slave fino all'ultima Tutti i frame inviati hanno come MAC sorgente il MAC della prima scheda di rete slave (MAC rewriting) Le schede di rete vengono poste in modalità promiscua per poter ricevere anche frame non diretti a loro (necessario per il load-balancing dei frame in arrivo) Sconsigliato se per i client l'ordine dei frame è importante Fornisce failover e load-balancing active-backup Solo un'interfaccia slave all'interno del bond è attiva. Un'altra interfaccia diventa attiva se e solo se la slave attiva fallisce Fornisce failover ma non fornisce load-balancing

35 Aggregazione dei canali di rete (4) broadcast Raramente utilizzato: invia i frame su tutti gli slave disponibili Fornisce fault tolerance ma non fornisce load-balancing 802.3ad Utilizza tutti gli slave disponibili secondo il protocollo 802.3ad E' l'unico protocollo che fornisce un meccanismo di controllo Necessario il supporto degli switch per la creazione di canali aggregati E' utilizzato soprattutto per creare link aggregati tra più apparati switch, difficilmente utilizzato tra server e switch Fornisce fault tolerance e load-balancing

36 Aggregazione dei canali di rete (5) Transmit-tlb Il traffico in uscita è distribuito sugli slave attivi Uno slave soltanto viene utilizzato per la ricezione Viene eseguito MAC rewriting per sovrascrivere l'indirizzo sorgente con quello dello slave deputato alla ricezione Fornisce load-balancing in invio e fault-tolerance Transmit-alb Estende transmit-tlb aggiungendo il load balancing in ricezione Il driver modifica le risposte ARP in modo tale da bilanciare gli host sugli slave attivi Fornisce load-balancing e fault-tolerance

37 La front-end subnet Obiettivo: Fornire risorse computazionali per l'esecuzione dei servizi Costituita da server senza disco (diskless) Il servizio di disco è ottenuto dalla back-end subnet con protocolli a livello di blocco o di file Sequenza di boot da rete: Richiesta indirizzo IP tramite DHCP Il server DHCP comunica anche l'indirizzo di un server TFTP dal quale scaricare l'immagine del kernel da eseguire Scaricamento Immagine del kernel tramite TFTP dallo storage gateway della back-end subnet e successiva esecuzione rootfs montato tramite NFS o iscsi

38 Gli Host della front-end subnet Solitamente i server appartenenti alla front-end subnet sono host di virtualizzazione Stack di rete piuttosto complesso: come fornire il servizio di rete alle macchine virtuali? Due possibilità Bridging. Soluzione più semplice: lavora a livello LLC della pila OSI e non presuppone nulla sulle applicazioni che gireranno all'interno delle VM NAT. Soluzione più complessa: richiede un software router/firewall su ogni host, offre maggiore controllo ma presuppone che nelle macchine virtuali gireranno applicazioni che vogliono esporre servizi su TCP/IP o UDP/IP

39 Stack di rete server di front-end Struttura in Figura replicata per i due lati dei server di front-end Verso backend subnet Verso gli utenti finali

40 Gestione del datacenter cloud-enabled Il datacenter non deve essere gestito manualmente Esistono tool open-source per la gestione automatica Eucalyptus OpenStack OpenNebula OpenQRM

41 OpenQRM Applicazione basata su plug-in per la gestione di un datacenter Caratteristiche principali Completa separazione dell'hardware (macchine fisiche e VM) dal software (immagini di disco) Supporto per differenti tecnologie di virtualizzazione N to 1 failover Gestione integrata dello storage Open source

42 OpenQRM - terminologia Resource: hardware fisico o virtuale che mette a disposizione CPU e RAM Image: contenitore di un root filesystem. Fa solitamente riferimento ad un LV che la contiene Kernel: programma kernel scaricato dalla macchina fisica/virtuale al momento del boot tramite TFTP Appliance = Resource + Image + Kernel

43 Uno sguardo da vicino a OpenQRM

44 Provisioning / deprovisioning Le funzionalità di cloud computing offerte da OpenQRM non permettono di definire politiche di provisioning/de-provisioning di VM E' compito del gestore dell'applicazione allocare e deallocare tutte le risorse necessarie per far fronte al carico OpenQRM mette a disposizione un WSDL per eseguire le principali operazioni di provisioning e de-provisioning Il client per questo Web service può essere incluso all'interno di un ciclo di controllo MAPE-K per rendere automatico lo scaling dell'infrastruttura

45 Linux CPU Hot-plug Funzionalità per l'aggiunta / rimozione di CPU a caldo E' sufficiente compilare il kernel Linux con l'opzione CONFIG_HOTPLUG_CPU=y Nello pseudo-filesystem /sys è presente il percorso: /sys/devices/system/cpu Contiene una directory per ogni CPU installata sul sistema in questione, all'interno della quale il file online permette di attivare/disattivare la CPU Funzionalità indipendente dalla tecnologia di virtualizzazione: funziona anche su macchine fisiche!

46 Dimensionamento dinamico della RAM Meccanismo di memory ballooning In KVM implementato con il driver virtio_balloon

47 Dimensionamento dinamico della RAM (2) Decisioni su come gestire il balloon sono gestite dal sistema host Se il balloon si restringe il sistema guest dispone di più memoria Se il balloon si espande il sistema guest dipone di meno memoria Swap e/o OOM killer