Newsgroup: it.comp.os.linux.sys
Titolo: Dubbio su architettura Storage SAN o NAS + Openfilter

Ciao,
devo mettere su un servizio che comprenda
due server web collegati a due storage per avere una
situazione ridondante.
Premetto che non l'ho mai fatto .. ho solo letto in giro varie 
documentazioni.
Vorrei mettere su 2 server web con apache e mysql ma
i file ed il DB vorrei farli pescare dagli storage.
il tutto collegato in iSCSI.
Quello che mi è ancora maggiormente oscuro è la ridondanza fra i 2 SAN...
Ho capito che i 2 server web li vedono come un "HD" ma non ho capito
come funzioni di preciso la ridondanza fra i 2 storage.
Ipotizzo un collegamento del Webserver1 sia al SAN1 che al SAN2
e del Webserver2 sia al SAN1 che al SAN2
Ma dovrei vedere le due macchine come un singolo HD ...è possibile ?
Cosa mi consigliate per gli storage sia Hardware che Software ? ( capacità 
sui 2 Tera )
Pensavo di usare Openfilter .. qualcuno lo usa in produzione ?
Grazie mille
                                            -- Yena --

 Pensavo di usare Openfilter .. qualcuno lo usa in produzione ?
uhmm , x una cfg cosi' io farei tutto a manina......
-- 
Gli insulti hanno effetto solo dove e' presente l'emozione.
                -- Spock, "Who Mourns for Adonais?", data astrale 3468.1

 uhmm , x una cfg cosi' io farei tutto a manina......
Prendo spunto dal tuo suggerimento molto interessante per
esporti la mia idea che mi hai ispirato :
Diciamo che il WebServer1 per semplificare abbia un disco proprio SDA
+
2 "dischi" SDB=SAN1 e SDC=SAN2
Per semplificare tutti con un unica partizione ( in mod. operativa saranno
partizionati ..lvm etc ..)
SDB e SDC vengono gestiti dal Kernel in RAID 1 e quindi verrano gestiti e
visti come un singolo HD.
Identica configurazione per il Webserver2.
Mettendo davanti un bilanciatore , il tutto lavorerebbe insieme .. se si
rompesse uno dei 2 webserver
rimarrebbe UP il secondo.
Domandona: la condivisione dei 2 SAN tramite il Raid del Kernel
contemporaneo delle 2 macchine è corretto
o può generare problemi ?
Grazie ancora
                                                        -- Yena --

 o può generare problemi ?
la seconda che hai detto , x questo devi mettere nn il bilanciatore ma un sw
di clustering ha e devi usare 2 dischi x ogni san.
lvm è possibile ma anche quello deve attivare / disattivare i vg allo start
e allo stop del servizio.
-- 
E' una fortuna che tu stia procedendo cosi' lentamente, perche' stai andando
nella direzione sbagliata.

 e allo stop del servizio.
.. SI la direzione era il precipizio ;-)
Dunque .. vediamo se ho capito ... :
Avrò:
SAN1 con HardDisk1 + HardDisk2
SAN2 con HardDisk3 + HardDisk4
Step1: Creo un raid tra il SAN1 ed il SAN2 via Kernel ( HardDisk1 <-> 
HardDisk3  + HardDisk2 <-> HardDisk4 )
( quindi i due SAN dovranno essere collegati """" CROSS """" fra di loro )
A questo punto ogni SAN è come se avesse 2 HD .
Step2: Collego Webserver1 al SAN1, Webserver2 al SAN2,  Webserver1 a 
Webserver2 per HA.
Se fin qui è tutto OK non mi è chiaro come i due Raid costruiti sui SAN si 
sincronizzino fra di loro... ma mi rendo
conto che devo documentarmi meglio .... :-)  faccio ricerche in rete e 
magari ti rompo di nuovo..


 sincronizzino fra di loro...
Non si sincronizzano affatto.
Tu vuoi un cluster e non lo sai. :-)

whiplash wrote:

infatti , a funzionamento normale:
il server1 esegue il servizio1 che scrive sul raid1 che sta' sul disco1
della sanA e sul disco1 della sanB
il server2 esegue il servizio2 che scrive sul raid2 che sta' sul disco2
della sanA e sul disco2 della sanB
se un server si ferma l' altro riprende anche il servizio di quello fermo.
-- 
Aspetta!  Non sei stato preparato!
                -- Atoz, "Tomorrow is Yesterday", data astrale 3113.2

 sui 2 Tera )
Scusa, probabilmente mi sfugge qualcosa: tu stai parlando di SAN,
ovvero, Storage Area Network, giusto?
Perchè io ho lavorato in EMC^2, e gli storage, generalmente, hanno un
software integrato non alterabile, incluso negli storage stessi, che si
occupa della gestione della ridondanza, della sincronizzazione con
backup remoti e del bilanciamento del carico.
I vari storage sono connessi tramite fibra-ottica a uno (FCSW) fiber
channel switch, e una volta terminate le operazioni di mapping e zoning,
puoi accedere a un set di dischi ridondati su più storage differenti,
come se fosse un solo unico volume.
Il tutto è trasparente per l'applicativo che usa lo storage.

 Il tutto è trasparente per l'applicativo che usa lo storage.
Questo è esattamente quello che mi piacerebbe realizzare !
Mi sai consigliare un prodotto valido che hai magari già utlizzato ?
( Parlo appunto di SAN "Storage Area Network" )
Ho spulciato sul sito della Dell ma non mi convincono ..
... Poi davanti gli metto i miei N server WEB ...


 come se fosse un solo unico volume.
questo è vero , ma le copie "remote" o non sono in linea o sono read-only ,
l' unico modo x portarle su' è "tagliare" la copia , quello che hai
descritto tu' secondo me' funziona bene x fare una disaster recovery
geografica se hai una dark fiber di una decina di km e puoi investire una
bella cifra , ma x fare business continuance non è proprio pratica....
-- 
Forse il nostro universo si trova dentro al dente di qualche gigante.
                -- Anton Pavlovic Cechov (1860-1904), scrittore russo


Io ho usato più volte questo con il relativo switch in fibra ma non ho
avuto il piacere di testarlo su Linux (solo su Aix purtroppo):
http://www-5.ibm.com/storage/europe/it/disk/ds4000/ds4300/index.html
 Gio'
-- 
/*
 * SnB - Qualità informatica - 
http://www.snb.it
 */

 il tutto collegato in iSCSI.
Valuta questa configurazione:
DNS roundrobin
dominio.com
  A 212.xxx.xxx.xx1 webserver1
	     A 212.xxx.xxx.xx2 webserver2	
i due webserver si connettono a MySQLmaster per le INSERT, UPDATE e 
DELETE ed a MySQLslave per le SELECT (ovviament parliamo di un cluster 
MySQL in cui 1 nodo è master e gli altri (1 o +) slave)
in questo modo fra webserver1/2 e MySQLservers passano solo le queri ed 
i result che sono comunque (relativamente) pochi bit anche in caso di 
grande carico ed è sufficente una comune eth
i file (immagini o altro) puoi piazzarli su un paio di NAS e 
sincronizzarli ogni tot o al limite adottare un filesystem distribuito 
tipo GFS ma credo che prima bisognerebbe capire esattamente di che 
tipologia di file si sta parlando.
Un infrastruttura simile offre prestazioni analoghe ad una SAN (visto 
che non intendi utilizzare la SAN per fare il suo lavoro che tipicamente 
  è quelo di fornire l'intero filesystem su cui sono installati i server 
diskless) ed ha costi di deployment/gestione decisamente inferiori, 
inoltre si ha un vero cluster MySQL esente da potenziali errori in 
scrittura che nel caso di un filesystem distribuito potrebbero dare 
qualche grattacapo, mentre così il server slave si limita ad eseguire a 
sua volta le stesse query (INSERT & UPDATE & DELETE) eseguite sul master 
rendendo de facto i due sistemi totalmente indipendenti e garantendo un 
elevato grado di disponibilità.

 elevato grado di disponibilità.
Avere un Unico FS composto da una serie di SAN scalabile sarebbe il mio
obbiettivo in modo da avere
i dati in sicurezza e un FS scalabile.
Quindi, vediamo se ho capito:
se avessi un solo WEB Server diskless e lo collegassi ad una SAN di almeo 2
SERVER
avrei una situazione "sicura" ridondata a livello di FileSystem e mi dici
che MySQL lavorerebbe bene.
Come metto in sicurezza il server web a questo punto ?
Devo mettere un secondo WEB SERVER sempre collegato alla SAN immagino ...
e userebbero lo stesso FS .. quindi andrebbero configurati con una sorta di
HA fra loro...?
Thankss
                                                        -- Yena --

 HA fra loro...?
Non esattamente, ogni server ha una propria LU visto che sennò si 
avrebbero accessi concorrenziali al sistema quindi fisicamente sarebbe 
come avere 2 server separati e nessun vantaggio pratico

 bella cifra , ma x fare business continuance non è proprio pratica....
Si, hai ragione, i dischi sono ridondati all'interno dello stesso
storage, mi confondevo con il disaster recovery, sai è passato un po' di
tempo da quando usavo quei sistemi.