Una SAN ad alta disponibilitàMario Giammarco

SAN vs NAS

● SAN: storage area network● NAS: network attached storage● A livello fisico sono molto simili● Ad alto livello servono per scopi diversi, ma non troppo● Sul mercato ne esistono da 100 a 100000 euro● Una SAN/NAS rischia di diventare un “single point of failure”

Utilizzo NAS

Utilizzo SAN

IDEA

● Come facciamo a risolvere il problema appena posto?

● SOLUZIONE:● Utilizziamo due server identici e sincronizziamo i dati contenuti!

SAN HA e simili

SAN HA e simili

● Ci sono molti modi per realizzare una replica di dati da fra due computer

● La soluzione che mostreremo sembra più complicata del necessario perché in realtà permette di ottenere una completa trasparenza

● Realizzeremo infatti un “cluster” ad alta disponibilità (attivo/passivo) a due unità

● Mostreremo come implementare una SAN ISCSI (niente NAS quindi)

Modello di SAN

Considerazioni

● Di primo acchito una san realizzata sincronizzando due computer “gemelli” può sembrare indistruttibile

● In realtà in questo modo abbiamo solo eliminato un “single point of failure”

● Occorre scegliere comunque l'hardware per evitare altri singoli punti di rottura: alimentatori ridondanti, doppie connessioni di rete, switch ridondanti, alimentazioni con ups, sistemi raid

● In caso di guasto di una delle due copie della san bisogna poi sperare che nel tempo di sostituzione, non si rompa l'altra copia

● Oltre a tutto questo ci sono i famigerati “guasti parziali” (vedi sidekick...)

Considerazioni-2

● Nel mondo dei sistemi ad alta affidabilità si parla di “serie di 9”:

● 99,9% 9 ore● 99,99% 52 minuti● 99,999% 5 minuti● 99,9999% 30 secondi

● Raddoppiando l'hardware a disposizione in genere si aggiunge un 9 alla situazione di partenza

Approfondimento: cluster a 3 nodi

Stati particolari

● Quorum● Split-brain● Fencing

Tecnologie opensource

● Vediamo ora quali strumenti opensource possiamo utilizzare per raggiungere il nostro obiettivo

● Per mantenere sincronizzati gli hard disk delle due unità lo standard attuale è DRBD

● Per realizzare il cluster fino a poco tempo fa si utilizzava “heartbeat”

● Ora si utilizza il successore di heartbeat che si chiama pacemaker/openais

● Per una SAN ISCSI linux ha diverse implementazioni di ISCSI target

DRBD

● Permette di sincronizzare fra due computer (in futuro più di due) i dati presenti nei loro rispettivi “block devices” (hard disk, md, lvm, etc.)

● La sincronizzazione può avvenire in modalità sincrona (modo C da noi utilizzato) o asincrona (A,B)

● Può funzionare in maniera attiva/passiva: in un dato momento un solo computer è attivo per scrivere e leggere i dati, mentre l'altro fa la parte del backup pronto a diventare lui il master in caso di necessità

● Dalla versione 8 può funzionare in maniera attiva/attiva: entrambi i computer possono ricevere ordini di lettura e di scrittura; fondamentale per filesystem distribuiti (gfs,ocfs)

DRBD - 2

● DRBD poi offre una serie di funzionalità apparentemente secondarie ma che lo rendono indispensabile per applicazioni HA (vedi discussione per inclusione kernel)

● Sincronizzazione efficiente in seguito alla perdita di connessione (bitmap e controllo hash)

● Controllo periodico online dei dati su hard disk per verifica guasti parziali

● Controllo con checksum dei dati di replica per identificare eventuali errori di rete

● Riconoscimento automatico dello split-brain e correzione automatica o in combinazione con cluster manager

● Altro: tripla replica, proxy, truck replication

SAN con DRBD

PACEMAKER

● DRBD fornisce “solamente” la replica dei dati e comunque ha bisogno di un aiuto esterno per alcune sue funzionalità (migrazione attivo/passivo,controllo split brain)

● Inoltre occorre coordinare il funzionamento di drbd con gli altri software che dovremo utilizzare per realizzare la nostra SAN

● Occorre quindi un software di gestione cluster (cluster manager).

Pacemaker

● Un cluster manager si compone di due parti: gestione risorse (CRM) e uno strato di comunicazione (messaging).

● Lo standard attuale in fase di dismissione si chiama “heartbeat”; fornisce sia messaging che CRM minimale (nella v2 migliorato)

● Il futuro standard ormai stabile per la parte CRM si chiama “pacemaker”

● Per il messaging, il nuovo standard è openais, anche se pacemaker può utilizzare heartbeat

● Openais verrà sostituito da corosync: entrambi implementano il nuovo protocollo di comunicazione “totem”

Pacemaker: caratteristiche

● Supporta cluster attivo/passivo e attivo/attivo● Non richiede obbligatoriamente storage condiviso● Può gestire qualsiasi risorsa con script (ocf,lsb,etc.)● Supporta dipendenze fra risorse● Ha un'interfaccia a riga di comando potente e semplice

Pacemaker

Pacemaker

Pacemaker

SAN con cluster

ISCSI

● ISCSI è uno standard industriale che permette di inviare comandi SCSI attraverso una rete tcp/ip

● Si posiziona a livello commerciale come un'alternativa economica a fibre channel

● Il server (la san che fornisce gli hard disk) viene chiamato target● Il client viene chiamato initiator● Esistono implementazioni software di target ed anche di initiator● Initiator per linux: open-iscsi (e altri), per windows è fornito dalla

Microsoft stessa● Target per linux: LIO, IET, SCST, STGT● Useremo IET ma in futuro LIO (VHACS)

SAN completa

Considerazioni

● Nel cluster attivo/passivo il server passivo non contribuisce al load balancing: si possono migliorare le prestazioni trasformandolo in attivo/attivo?

● Per non rischiare perdite di dati drbd adotta di default la modalità “no flush” che pero' compromette le prestazioni: come possiamo fare per ovviare?

Creare un prodotto

● Cosa manca per arrivare ad un “prodotto finito” ?

● Un interfaccia utente che renda “gestibile” la san (insieme consistente di features, impedisca esecuzione di ordini concorrenti,...)

● Un sistema di di “intelligenza” che permetta al sistema di riconoscere da solo le cause di malfunzionamenti e di segnalarle all'amministratore di sistema

● Un processo di sviluppo (vcs, test, riproducibilità)

Lavori in corso

● Per creare una configurazione riproducibile: chef● Come linguaggio per il backend: erlang, haskell● Per il frontend web: Wavemaker, Tibco gi, Aribaweb● Testing facilitato dall'uso dei web services

Grazie Mille per l'attenzione...

Domande?