Il giorno 25 marzo 2011 19:41, Alessandro Baggi
<alessandro.baggi@gmail.com <mailto:alessandro.baggi@gmail.com>> ha
scritto:
Comincio a fare un po di confusione.
Se dico qualcosa di sbagliato correggimi.
Con una SAN, (tralasciando le schede di rete) abbiamo un initiator
e dei target, in sostanza il target è colui che da i dischi e
l'initiator è quello che lo dovrebbe gestire. L'utilizzo di una
SAN è legato alla velocita con cui i dati vengono trasmessi, e
questo non fa forza solo sulle schede di rete ma anche hdd,
processori ecc..., ecco per cui utilizziamo molteplici macchine
per lo scopo.
Ovvio tutto contribuisce alla velocità della trasmissione dei dati,
ricorda ma credo sia superfluo dirlo che un target può essere
associato ad un solo initiator quindi ogni risorsa esportata via iscsi
può essere gestita da un solo initiator alla volta...
Penso che gli scopi per cui si usa iscsi possano essere
principalmente due:
1) Avere N macchine, ognuna con uno storage per una determinata
sezione, e quindi "aggregarli" su un unico sistema. Ma questa
tipologia puo essere schivata.
In realtà lo scopo reale è questo, da una parte hai un initiator,
magari un server non troppo performante, magari virtuale, cui non è
possibile collegare un grande storage, o comunque è poco utile, in
quanto in caso di guasto al server ti trovi senza server e senza
storage, nel caso siano risorse diverse, puoi sempre agganciare lo
spazio disco ad un server di backup o di emergenza e limitare il tempo
di down; dall'altra hai una SAN pensata apposta per fornire storage, a
seconda della configurazione con svariati slot per hard disk hot swap,
raid hw, rete ed alimentazione ridondata, con un s.o. customizzato,
come i QNAP per esempio che occupano pochissime risorse.
2) (questa secondo me è la piu utile) Avere N macchine, ognuna con
N hdd, per creare una unica grande rete che raggiunge dimensioni
di storage molto molto elevate, questo dovrebbe essere uno dei
motivi per cui si dice low cost e con prestazioni abbastanza elevate.
Per la prima ipotesi, diciamo che la possiamo tralasciare, avere N
server storage e aggregarli su una unica macchina, non mi sembra
poi cosi utile, in fondo lo abbiamo gia il server, che fa il
lavoro che deve fare, anzi, se l'initiator fallisce abbiamo un
unico punto di fallimento, se cade l'initiator cade tutta la rete.
iscsi ci permette per cui di dare all'initiator un certo numero di
dischi, sia questo un hdd normale, sia un md, o un lvm.
Prendiamo in considerazione la seconda ipotesi.
Ora la domanda che mi pongo è: e se volessi creare un sistema con
uno storage di dimensioni molto elevate (fantastichiamo petabyte,
oppure 3000 TB) per un qualche scopo, come fare per ovviare a
questo? Fino ad ora non ho mai sentito di singole macchine che
hanno controller in grado di fare cio (parliamo sempre di bassi
costi, non di mainframe), per ora penso che la soluzione possa
essere un Cluster di hdd, e per le operazioni servono sempre CPU,
RAM etc...e penso che con iscsi si possa fare molto facilmente,
ovvio diventa complesso da gestire ma si possono creare sempre
sistemi di automazione.
Per la questione dei raid, su ogni singola macchina (target),
dovremmo mettere i dischi in raidN per fornire una qualche
ridondanza per i dati, sulla singola macchina, in quanto ora sono
le singole macchine a fare da point of failure oltre che
all'initiator. Per cui se si rompe una macchina, o un hdd, o
qualche componente e la macchina diventa inusabile la rete cade
(mi riferisco agli hdd), sempre nel caso di un unico grande
storage. Ma se invece provvediamo a fornire una ridondanza in
rete? Per esempio un raid 1 tra due dev di due diverse macchine
(la sincronizzazione verra tra i due hdd via iscsi e vie rete)
Facciamo conto che drbd non esista, anche se penso che si basi
sullo stesso principio. Bhe penso che se cade la prima abbiamo
sempre la seconda, ovvio che si abbasserebbero le performance fino
alla risincronizzazione.
Quello che ho pensato io è: abbiamo 4 target e un initiator. Sui
target abbiamo 12 HDD che configuriamo con un raid5 hardware o
software che sia (tralasciamo i livelli dei raid) per cui vedremo
/dev/md0 sui target, sull'initiator abbiamo invece i dev importati
sdb, sdc, sdd e sde. E fin qui tutto bene. Supponiamo ora di
volere un unico gigante archivio per esempio per lo storage di
siti e materiale relativo ai siti, per una webfarm. Il miglior
modo per poter fare cio sarebbe quello di condividere i raid dei
singoli target sull'initiator per fare un "volume" di una certa
dimensione. Questo permette alta velocita, in quanto il carico
viene ripartito su 4 macchine, e su N HDD, e allo stesso tempo in
alta velocita su N schede rete.
Pensi che iscsi possa essere applicato anche a questo concetto? Io
credo che si possa applicare in tale ambito, cio comporterebbe una
complessità elevata ma se il sistema è ben progettato sarebbe
(secondo me) una soluzione a dir poco fantastica.
Premesso che tutto è possibile, per lo meno a livello di test, studio
ecc... credo ci sia un problema alla base, supposto che un azienda
abbia la necessità di vari petabyte di spazio disco, credo che
dovrebbe avere anche le risorse per acquistare dell'hardware adeguato,
ci sono SAN di IBM ed HP tanto per citare alcuni nomi conosciuti che
teoricamente non hanno limiti di espandibilità a livello di spazio
disco. In situazioni come la tua si dovrebbe pensare ad un cluster
gestito bene, capisci che si io importo via iscsi 4 nodi da 10 TB per
ottenerne uno da 40TB devo necessariamente creare un lvm o un raid,
magari raid0 per non perdere spazio, ma in caso di raid degradato ?
Quello creato sull'initiator segnala lo status che però è da
attribuire ad almeno uno dei 4 nodi, per cui devi "smontare"
gradualmente almeno 2 raid, se fossero 2 dischi su 2 nodi diversi
avresti perso tutti i dati :( poi considera il tempo di ricostruzione
dell'array degradato.... di 40TB a dir poco ingestibile in realtà di
produzione.
Spero di essere stato chiaro...
Ciao
Domenico.
--
-------
"Eliminato l'impossibile ciò che resta per quanto improbabile è la
verità".
Conan Doyle.