Il giorno 25 marzo 2011 19:41, Alessandro Baggi
<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.