Newsgroup: it.comp.os.linux.sys
Titolo: partizionamento ds3400

Leggevo nei vari redbooks che lo storage va partizionato.
Esempio: se avessi 10 dischi, potrei fare due partizioni logiche da
5+5.
Ogni partizione può essere vista solo da 1 nodo per volta, salvo
configurazioni cluster dei nodi.
Leggevo su questo newsgroup che per fare boot da san bisogna fare 1
partizione per ogni nodo (con la lun0 dedicata al boot) ed
eventualmente 1 partizione con tutti gli altri dati.
Ma se la partizione può essere vista da 1 solo nodo per volta, come
fanno 10 server a fare il boot via san ed allo stesso tempo accedere
tutti insieme alla partizione?
(premessa: non devo fare niente, sto solo cercando di schiarirmi le
idee)

 Ma se la partizione puň essere vista da 1 solo nodo per volta,
No. Una partizione puň essere assegnata ad un hostgroup formato da piů host. 
Un host puň vedere piů partizioni. Quindi gli si fa vedere in esclusiva la 
partizione di boot con la lun0 da cui fare il boot e la partizione condivisa 
con i dati
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 
in termini ibm, la partizione è una associazione tra gruppo di host e
lun. in pratica, quando devi far vedere ad un host o gruppo di host una
serie di lun crei una partizione.
quando lo fai, definisci le lun che l'host deve vedere. a quella di boot
dai id 0, e l'host la vede come disco fisso.
tutto qua

 tutto qua
Eppure in un redbooks sulla serie DS3000 è scritto che la san deve
essere
suddivisa in partizioni, ed una partizione può essere vista solo da 1
host per
volta per evitare corruzioni di dati ed altre brutte cose.
E' anche scritto che in caso di cluster, l'intero cluster può accedere
alla stessa
partizione.
Quindi voi dite che prima creo le singole lun, poi 'accorpo' le lun in
partizioni di
storage le quali saranno viste dai singoli server anche in simultanea?
Poi su queste partizioni creo tutti i filesystem che voglio?
Io non ci capisco nulla di san, avete un documento da cui partire che
spiega come
diavolo funziona? Tanto prima o poi mi toccherà partire, e per quella
data, vorrei essere
preparato e sapere almeno di cosa sto parlando.
A livello teorico io vorrei fare 16 nodi bootabili via SAN ed allo
stesso tempo non "esportare"
tutti i dati a tutti i nodi. Ad esempio: nodi da 1 a 3 vedono alcune
partizioni (partizioni linux, dove poi posso fare LVM)
nodi da 4 a 8 vedono altre partizioni e così via.

 nodi da 4 a 8 vedono altre partizioni e così via.
Con i DS3400 questo non lo fai per il limite sul numero di partizioni


 da san di tutti i nodi poi non hai più partizioni da condividere tra i nodi.
Era un esempio.
Supponiamo che i nodi siano 15, se non erro, il DS3400 supporta 16
partizioni. 15 sono dedicate al boot (ma non ho capito come, se le
partizioni
accorpano delle lun, come faccio ad avere la lun0 su ogni partizione?
Dovrei quantomeno creare 15 lun, che non saranno mai tutte lun0.
(a meno che io non debba creare 1 lun0, poi dentro tale lun0 creo 15
partizioni.
il server1 farà boot dalla partizione1 della lun0, il server2 dalla
partizione2 della lun0 e
così via)
La 16° lun sarà quella con i dati di tutti.
Posso far accedere 15 server alla stessa lun/partizione e poi
partizionare ulteriormente
mediante linux? Così facendo, non mi serve un fs condiviso, sulla
partizione dello storage
faccio 15 partizioni linux....
----
tralasciando quanto scritto sopra (sto ragionando mentre scrivo), lo
storage può essere visto
così? :
disco0 -> rad5-0 -> lun0 => partizione0
disco1 -> rad5-0 -> lun0 => partizione1
disco2 -> rad5-1 -> lun0 => partizione2
disco3 -> rad5-1 -> lun1 => partizione3
disco3 -> rad5-2 -> lun2 => partizione4
disco4 -> rad5-3 -> lun3 => partizione5
Ovvero:
1) creo i vari volumi raid in base ai dischi (raid5-0 nel mio esempio
significa volume0 fatto con raid5)
2) per ogni volume creato creo le lun
3) per ogni lun, creo le singole partizioni.
in pratica, le lun son come i device a blocchi su linux (sda, sdb,
sdc, ...) che posso partizionare come voglio.
quello che non mi è chiaro è come debba essere visto "a blocchi" lo
storage. Su pc normali, ogni disco è un device a blocchi indipendente,
che posso formattare e gestire a piacere. Nelle san mi pare ci siano
dei livelli intermedi prima che un disco
possa essere gestito da un server, e questi livelli non li riesco a
focalizzare.
----

 la migrazione a caldo senza downtime da 1 server ad un altro?
Ogni nodo ha il suo disco di sistema (sia onboard oppure sulla SAN 
cambia fava, ergo io preferisco la prima soluzione, ma son gusti).
Tutti i nodi accedono a un volume della SAN su cui stanno le VM.
Fine.
-- 
http://bofhskull.wordpress.com/

 dei livelli intermedi prima che un disco
Nelle SAN il device è la LUN. Una lun equivale ad un disco sul S.O. e puoi 
partizionarlo (nel senso di fdisk) come meglio credi.


 Tutti i nodi accedono a un volume della SAN su cui stanno le VM.
Si, solo che faccio confusione con i termini.
Da quel che sto iniziando a capire ora, su una san appena accesa io
devo
1) creare i vari volumi raid partendo dai miei dischi fisici (e fin
qui, son buoni tutti)
2) per ogni volume raid, creo 1 o più lun.
3) per ogni lun creta, creo 1 o più partizioni storage (che sono
semplicemente dei contenitori di lun
ovvero, ogni host che accede a quella partizione storage può lavorare
solo sulle lun presenti, una sorta di vg LVM che
è associato ad uno o più pv LVM)
4) connetto 1 o più host alle singole partizioni.
Tornando al mio esempio, se voglio fare boot di 15 host, dovrò:
1) creare un "piccolo" volume raid per il boot (quindi conterrà solo i
sistemi operativi dei nodi fisici)
2) creare la lun0 sul volume raid piccolo
3) creare una partizione con al suo interno la lun0
4) far collegare i 15 server alla partizione
fatto questo, i server bootano via san.
Quindi posso creare altri volumi raid (magari 1 per ogni 7-8 dischi
per avere maggiori performance) sopra
i quali creare altre lun da accorpare in altre partizioni che saranno
viste dai server.
In queste partizioni creo poi i singoli filesystem dove salverò gli
LVM per i server virtuali.

 partizionarlo (nel senso di fdisk) come meglio credi.
Ok.
Credo di iniziare a capire.
-- ragionamento ad alta voce ON --
Una volta che ho configurato la mia san (ovvero creato i volumi raid,
create le lun delle dimensioni che preferisco (1 lun per ogni server
che deve fare il boot + 1 o più lun per le macchine virtuali vere e
proprie), una volta che ho 'esportato' le lun mediante delle
partizioni storage, devo connettere uno o più server a tali
partizioni.
Sui server avrò quindi disponibili i device a blocchi creati dalle san
e visibili attraverso la partizione storage.
A sto punto non devo far altro che creare su ogni lun tanti volumi
LVM, potrei convertire la singola lun in un volume fisico LVM,
all'interno del quale creare un gruppo LVM e poi fare tanti volumi
logici, uno per ogni VPS.
I volumi sono scritti sulla san, per cui un eventuale secondo nodo si
ritroverebbe i volumi già configurati e sempre visibili.
Quello che non si può fare (con filesystem tradizionali) è montare il
FS presente sul singolo volume da più nodi, ma è una operazione che
non devo fare.
L'importante è che i volumi LVM siano visibili su tutti i nodi che
devono fare live migration.
Fatto ciò, sul nodo 1 creo la VPS1 che utilizza LVM1, sul nodo1 creo
la VPS2 che utilizza LVM2 e così via.
Sul nodo2 farò altrettanto con lo stesso gruppo di volumi LVM ma
utilizzando, ovviamente, volumi logici differenti (LVM3, LVM4, ...)
Se voglio fare migrazione di una VPS, xen/vmware dovrebbe procedere in
questo modo (da quanto ho capito): crea il clone della VPS sul nodo di
destinazione ma non la avvia, salva lo stato della VPS (ram ed altre
cose) su disco, spegne la vecchia VPS, accende la nuova VPS, che per
forza di cose si collegherà al volume corretto in base alla
configurazione.
Per cui, una singola LUN dovrebbe bastare, salvo VPS molto trafficate
in cui sarebbe opportuno suddividere il carico su lun differenti,
magari appoggiate ad array differenti sulla san.
Quello che non mi è chiaro è come fare tante lun0 per poter consentire
il boot dei nodi. Dovrei fare una singola lun0 partizionata (fdisk) in
più parti?
Non mi pare sia possibile selezionare la partizione di boot
all'interno di una lun....
-- ragionamento ad alta voce OFF --

 più parti?
Intendi "una singola lun0 comune a tutti i nodi"? In tal caso, NO.
E se non hai necessità assoluta di avere il sistema operativo dei nodi 
sulla SAN, usa dischi locali e non ti rovinare la vita...
-- 
http://bofhskull.wordpress.com/

 preparato e sapere almeno di cosa sto parlando.
una san è come un disco scsi per l'host.

 
quoto e confermo

 sulla SAN, usa dischi locali e non ti rovinare la vita...
Il boot da san lo voglio fare. Meno dischi che si rompono, meno
problemi in generale
(una volta configurato). Ma non escludo che con tutti i server che
avanzeranno dopo aver
virtualizzato, potrei prenderne 2 da utilizzare con server per il PXE
e fare boot da li.
Così facendo, il boot avverrebbe via pxe tramite due gateway. (e
risparmierei anche sulle
lun)
Però, sempre a livello teorico, se volessi far bootare 10 nodi
direttamente da san, come diavolo
si fa? Leggevo che possono fare il boot solo da lun0, ma di lun0 ne
posso fare solo 1, ovviamente....

 secco. per lei è sempre una lun associata ad un host
Si, ora ho capito.
In parole molto povere, una lun è come una porta di uno switch
ethernet.
Una partizione (nelle san IBM) è un po come una VLAN. La porta1 e la
porta2
fan parte della VLAN1, la porta3 e la porta4 fan parte della VLAN2.
Un server, può vedere solo le porte che fanno parte della VLAN a cui è
associato.
Esempio del cavolo, ma dovrebbe rendere l'idea.

 da san di tutti i nodi poi non hai più partizioni da condividere tra i nodi.
Non so cosa prenderò.
Sono indeciso tra EMC AX4-5f (della dell, per questioni interne
nostre), il DS3400 IBM
oppure il NetApp FAS2020 (o 2050).
Quest'ultimo mi stuzzica tantissimo, costa se non erro sui 4500
dollari ma ha sia 4 porte fibra 4gb
che 4 porte iscsi e può esportare anche cifs ed nfs.
Come apparato non sembra male, si può partire in iscsi per fare
pratica e poi passare tutto in fibra
comprando due switch.
Esperienze a riguardo? Una cosa non mi convince affatto: la
documentazione è inesistente.
Sul sito non son riuscito a trovare un singolo documento o manuale se
non dei case history e dei datasheet.

 Il boot da san lo voglio fare. 
Mi pare che questo sia il RedBook corretto:
http://www.redbooks.ibm.com/abstracts/sg247065.html


 boot solo da lun0, ma di lun0 ne posso fare solo 1, ovviamente....
A ogni nodo dai vedere come LUN0 una LUN diversa.
-- 
http://bofhskull.wordpress.com/

 Devi avere una LUN che sia visibile da tutti i nodi contemporaneamente.
ok però una volta resa visibile la lun a tutto il gruppo ci pensa xen
a gestire i vari lvm cluster o devo configurare tutto a mano?


-- 
http://bofhskull.wordpress.com/

 a gestire i vari lvm cluster o devo configurare tutto a mano?
Fa lui.
-- 
http://bofhskull.wordpress.com/

 Fa lui.
Perfetto, mi resta solo da trovare la san...
Il boot via rete lo posso risolvere anche in altri modi. San o non
san, posso sempre
fare un server esterno con due dischi sata da 1tb esportati in iscsi/
nfs/aoe, tanto servono solo per caricare i
sistemi operativi dei nodi, per cui le performance in accesso non
dovrebbero essere fondamentali
(i log, saranno su server esterno, i dati saranno su san, il s.o.
dovrebbe accedere pochissimo al disco)
Tra le tre san che ho elencato sopra, tu cosa consiglieresti? Hai
esperienze in merito?
I parerei dei produttori sono discordanti, conosco colleghi che son
stati consigliati ad acquistare una san iscsi
altri che puntano solo a fibra e così via... (e le necessità erano
sempre le stesse: virtualizzare dei server)

 sempre le stesse: virtualizzare dei server)
Un po' tante variabili, anche cosě. In primis: virtualizzare *quanti* 
server?
Perchč tra reggere l'I/O di una dozzina di sistemi e reggerne centinaia 
c'č una grossa differenza.
iSCSI satura facilmente prima, c'č il vantaggio che costa poco e quando 
hai saturato le capacitŕ di una SAN ne aggiungi una seconda, una terza, 
ecc in maniera piů o meno lineare, dato che il trasporto avviene su 
normale facility di rete. Ovviamente, questo ti dŕ un overhead 
amministrativo, moltiplica potenzialmente le sorgenti di problemi, ecc.
Perň mantiene i costi bassi.
FC ha limiti superiori piů elevati, ma richiede investimenti piů 
sostanziosi, soprattutto se l'obiettivo č di poter scalare molto in alto.
Scegliere il prodotto in ambito storage č sempre un casěno, nella mia 
esperienza. Per quel che vuol dire, io ho Sun, quindi non rientro in 
alcuno degli oggetti che elenchi. E non ho molta esperienza con oggetti 
diversi: mi č capitato di metter le mani su sistemi altrui (DS3400 e EVA 
in particolare), ma non abbastanza da potermi sbilanciare su aspetti 
diversi dal mero costo di acquisto...
-- 
http://bofhskull.wordpress.com/

 usa dischi locali e non ti rovinare la vita...
Quoto, immensamente quoto.

 diversi dal mero costo di acquisto...
Sun ovvero? Che modello?
iSCSI o fibra?
Considera che te vai 10-20 volte il mio traffico, se tu sei su iscsi,
a me basta una penna USB, se
te sei su fibra, a me forse basta iscsi....

 te sei su fibra, a me forse basta iscsi....
Maqquandomai...
-- 
http://bofhskull.wordpress.com/

 esperienza. Per quel che vuol dire, io ho Sun
A proposito, hai toccato la macchinetta nuova che vendono adesso basata su 
OpenSolaris che è in pratica una blacbox per lo storage che sfrutta le 
funzionalità di ZFS e dtrace? (non mi ricordo il modello)
-- 
Vide

 funzionalità di ZFS e dtrace? (non mi ricordo il modello)
Nope...
-- 
http://bofhskull.wordpress.com/

 Maqquandomai...
Perchè?
Tu non fai 10 volte il mio traffico?

sempre le stesse: virtualizzare dei server)
Fornitore con cui parli, parere che trovi.
Hai appena fatto la domanda da chi vuol esser milionario!
Mi piacerebbe anche a me capirlo bene, ma intanto sfrutto lo storage che mi 
trovo, poi se serve crescerò.
<pensiero a voce alta ON>
Una volta che i dati non sono più in locale, spostarli da ISCSI a FC è 
questione di acquistare qualcosa, ma non dovresti (CORREGGETEMI PER CORTESIA 
SE SBAGLIO) ricominciare da zero, in particolar modo se lo storage 
acquistato
supporta entrambe le soluzioni, ma la seconda è un opzione a pagamento.
<pensiero a voce alta OFF>
Sono tutti d'accordo che iscsi ha performance inferiori di fc, ma la 
questione è sempre nel quanto (si va dall'impercettibile
all'inacettabile differenza).
Poi chi dice che anche l'uso di TOE non porta tutto questo vantaggio (se sei 
fortunato che l'accoppiata storage/vmware sia supportato).
Qualcuno di loro mi ha fatto venire in mente, le persone che anni fa si 
fissavano sulla velocità potenziale della porta seriale (e me lo ha 
ricordato Skull, su un trhead in cui parlava di velocità adsl con un 
utonto...), invece di vedere che il collo di bottiglia è da un altra parte: 
in questo caso quanti dischi e come sono gestiti (livello raid, volume al di 
sopra di x raid... o altro) o per andare ancora più indietro
quelli che guardavano la sola frequenza di clock per valutare le performance 
del computer...
Comunque non dimentichiamo che la velocità di 1gb può essere aumentata 
usando bonding e/o jumbo-frame (peccato solo che quest'ultimo vmware esx non 
lo supporti), configurando opportunamente lo switch.
Ciao,
ScriptJus 

 lo supporti), configurando opportunamente lo switch.
Si, ma su una iSCSI tu hai 4gb complessivi tra i controller, su una
fibra hai 16GB tra i
due controller..... la fibra è 4 volte più veloce.

 lo supporti), configurando opportunamente lo switch.
Non è poi così vero.
L'aggregazione di più link ethernet in bonding permette flussi più elevati.
La sua efficacia è però limitata dal fatto di dover evitare il fenomeno 
del frame-reordering: per evitarlo, gli algoritmi di bilanciamento usano 
le NIC sulla base di hash-map, canalizzando sulla stessa interfaccia 
quello che va/viene dallo stesso MAC-address.
Significa che tutto quello che va da una specifica macchina (il tuo 
server) ad uno specifico target iSCSI (con il suo mac-address) passa 
sempre dalla stessa NIC, privandoti quindi di qualsiasi vantaggio 
portato dall'aggregazione di più link (tranne il failover, ovviamente).
A questo puoi porre -in qualche misura- rimedio se usi lo storage iSCSI 
accedendo in multipath ad entrambi i controller (cosa comunque 
consigliabile), dato che avrai tendenzialmente due flussi separati che 
andranno ad utilizzare le due diverse NIC.
Oppure usi due subnet diverse per i due path collegate ciascuna ad una 
NIC diversa (no bonding), ed ottieni ridondanza e load-balancing 
dell'accesso allo storage attraverso il solo multipathing, senza 
affidarti al bonding (se poi ce lo vuoi aggiungere, tantomeglio).
In particolare, per XenSource versione 5.0 e successive, è consigliabile 
comunque affidare il bilanciamento dell'accesso ad iSCSI al 
multipathing, se possibile, perchè l'algoritmo di bonding usato è SLB: 
basa l'hashing sul MAC *sorgente* e non destinazione, poichè è pensato 
per poter distribuire su più NIC il traffico delle VM (che hanno MAC 
ovviamente diversi). Significa che in un caso come il dialogo con iSCSI, 
dove il MAC di uscita è sempre quello del Dom0, non bilanci un tubo 
comunque.
Ciò detto, una osservazione: in qualche misura, parliam del sesso degli 
angeli.
Anche se in teoria le attività in direzione di uno storage iSCSI possono 
tranquillamente saturare il gigabit a disposizione, in realtà per le 
attività di virtualizzazione (dove non c'è un flusso di I/O unico e 
grosso, ma tanti piccini generati dalle VM) il limite che arriva prima è 
quello dovuto al movimento dei dischi e alla cache dell'array...
Almeno nella mia esperienza, con "tante" VM di dimensioni medio-piccole 
come nel caso di servizi e clienti tipicamente ISP, dove le attività son 
bene o male guidate dalla connettività pubblica.  Non dubito che 
nell'utilizzo in datacenter enterprise, in cui le VM sono "grosse  e 
cattive" le cose sian diverse e si possa impattare facilmente nel limite 
del gigabit, ma nel mio ambito -da quanto osservo- il limite è ben lontano.
-- 
http://bofhskull.wordpress.com/

 del gigabit, ma nel mio ambito -da quanto osservo- il limite è ben lontano.
Esatto, lascia pure che l'i/o su disco è diverso dalla banda a
disposizione, ma
se una VPS ha un collegamento di (per dire) 512kbit alla rete
pubblica, non potrà
mai fare così tanto i/o su disco da mettere in ginocchio una san
iscsi.
Se nessuno legge e scrive sul server perchè la banda è satura, non ci
sarà nemmeno
nessuno che legge e scrive sullo storage.
O meglio, non sarà così tanto elevato il traffico i/o. Log a parte,
l'i/o su disco di una VPS ad
uso ISP dovrebbe essere abbastanza correlata al traffico internet.
(abbastanza se non del tutto
correlata)

due controller..... la fibra è 4 volte più veloce.
Come hai calcolato 4gb?
Dipende da quante schede puoi mettere in parallelo (sempre che lo switch e 
lo storage effettivamente siano in grado di distribuire le richieste).
Ogni contributo in tal senso è gradito, da chi ha più esperienza.
Ciao,
ScriptJus 

 Ogni contributo in tal senso è gradito, da chi ha più esperienza.
Come detto non sono i Gb nominali a fare la differenza maggiore, almeno non 
nella maggior parte degli scenari.


 lontano.
Ciao,
ScriptJus 

iscsi.
A meno che non parliamo di un VPS che pubblica un servizio web, che si 
appoggia su un DB, con tonnellate di tabelle, e quando tu effettui una 
richiesta di pochi k, lui dietro ne muove TB... :)
Ciao,
ScriptJus 

 giustificare la cosa ti confondono non poco le idee.
Il fatto è che se i check vengono effettuati in HW con aggeggi che sono 
in grado di andare alla velocità del cavo, il fatto che ci sia overhead 
computazionale è prestazionalmente irrilevante.
Lo è sicuramente da altri punti di vista, quale quello progettuale, il 
che sta alla base del fatto che un HBA per iSCSI ha prezzi paragonabili 
ad un HBA FC.
Sostanzialmente la differenza di prezzo sta nell'infrastruttura di 
trasporto (gli switch) e nella qualità e prestazione dell'architettura 
dello storage.
Una SAN "capace di TOT" ti costerà sostanzialmente uguale 
indipendentemente dal fatto che l'interfacciamento avvenga in FC o in 
GigaEthernet. Le differenze, quando ci sono, sono dovute al costo 
specifico di una specifica architettura (che per FC sono IMHO tenute 
alte per questioni "di cartello" più che per ragioni intrinseche)
HP ha un buon esempio:
- 2012fc: è un dual-controller FiberChannel. 8500$
- 2012i:  è un dual-controller iSCSI. 7500$
- 2012sa: è un dual-controller SATA. 6500$
I prezzi dello stesso oggetto, nelle tre configurazioni, non sono 
granchè dissimili.
Certo alla soluzione FC c'è da aggiungere gli switch FC. Di norma, chi 
gestisce già dei datacenter gli switch gigabit ethernet li ha già...
Alla fine, se prendi questo specifico oggetto, la differenza la puoi 
riassumere tutta qui, dato che gli HBA costano a loro volta praticamente 
uguali.
E un altro dettaglio: per FC serve sempre HBA. Per iSCSI anche no, se 
l'uso dello storage non deve essere eccessivamente intensivo.
Magari non interessa nulla, ma può fare la differenza per chi si aspetta 
di avere, oltre agli accessi intensivi da parte di 
alcune-poche-macchine, N piccoli accessi da parte di sistemi a basso I/O.
E in termini di costo, significa risparmiarsi N * il costo di ogni HBA...
-- 
http://bofhskull.wordpress.com/

 lo storage effettivamente siano in grado di distribuire le richieste).
Le san entry level non consentono l'aggiunta di ethernet aggiuntive,
altrimenti il problema
non sussisterebbe per me. Prenderei una san con le ethernet base per
poi aggiungerle in futuro.
ad esempio la DS3200/3300 ha solo 4 etherent gigabit, non espandibili.

 giusto dimensionamento.
E ma anche il consulente di provata esperienza dovrebbe andare a caso.
Tu guardi i server, dici: ok, dovrebbero bastare X mbit/iops.
Ma quell'X lo dai a caso in base ad una statistica data dalla tua
esperienza o
almeno fai partire un test/monitor/totalizzatore sul server per 1
mese?
La SAN è un acquisto non indifferente per chiunque, non ci si può
muovere a caso.

 richiesta di pochi k, lui dietro ne muove TB... :)
Si, ma si spera che il VPS con il mysql abbia grosse ram (come è
giusto che sia per mysql).
Così facendo, il grosso delle richieste sarà fatto da cache in ram.
Poi, ovviamente, un db progettato male avrà ripercussioni su tutta la
san.

 E in termini di costo, significa risparmiarsi N * il costo di ogni HBA...
Gli HBA iscsi costano la metà di quelli in fibra, i quali arrivano
tranquillamente a 1000 euro e ne
servono almeno 2 per ogni server.
Con iscsi parti subito: compri la san e la attacchi, poi in seguito
puoi aumentare di un po le performance
comprando switch ethernet di qualità migliore, comprando delle HBA o
delle schede ethernet con TOE, ma
sono acquisti che puoi dilazionare nel tempo e che puoi fare solo in
caso di necessità *dopo* aver visto come
butta con il resto della san.
Con la fibra, o compri tutto e subito o non parti.
I blade, da questo punto di vista, dovrebbero far risparmiare. non ti
servono le HBA ma solo i due switch da
blade, che spesso costano meno di quelli standalone.

 quello dovuto al movimento dei dischi e alla cache dell'array...
Hai esperienze in merito alla virtualizzazione di db?
Dovrei virtualizzare un SQL su cui girano diversi db.
Ciao,
ScriptJus 

quantomeno di una san in grado di supportare X*10.
Per linux esistono innumerevoli tool per controllare le cose (alla più 
disperata ti arrangi con cron & iostat...)
Per windows potresti cominciare da Pannello di controllo/Strumenti di 
amministrazione/Performance monitor e crei un "registro contatore". (che ti 
permette di mettere contatori anche su alcuni parametri dei servizi da 
monitorare - per ex. sql server).
Se può esserti utile, alcuni contatori che usai tempo fa per verificare le 
performance di un server SQL e capire se la memoria era sufficiente e dove 
potesse essere un collo di bottiglia.
\\SERVER\Memory\Available MBytes
\\SERVER\Memory\Pages/sec
\\SERVER\PhysicalDisk(_Total)\% Disk Time
\\SERVER\PhysicalDisk(_Total)\Avg. Disk Read Queue Length
\\SERVER\PhysicalDisk(_Total)\Avg. Disk Write Queue Length
\\SERVER\Processor(_Total)\% Processor Time
\\SERVER\Processor(0)\% Processor Time
\\SERVER\Processor(1)\% Processor Time
\\SERVER\SQLServer:Buffer Manager\Buffer cache hit ratio
\\SERVER\SQLServer:Buffer Manager\Checkpoint pages/sec
\\SERVER\SQLServer:Buffer Manager\Lazy writes/sec
\\SERVER\SQLServer:Buffer Manager\Page life expectancy
\\SERVER\SQLServer:Memory Manager\Target Server Memory(KB)
\\SERVER\SQLServer:Memory Manager\Total Server Memory (KB)
\\SERVER\SQLServer:SQL Statistics\SQL Compilations/sec
\\SERVER\SQLServer:SQL Statistics\SQL Re-Compilations/sec
\\SERVER\System\Context Switches/sec
\\SERVER\System\Processor Queue Length
ed i link su cui mi ero basato (c'è n'era un altro ma non lo trovo più):
http://www.computerperformance.co.uk/HealthCheck/Disk_Health.htm
http://www.sql-server-performance.com/articles/audit/hardware_bottlenecks_p1.aspx
A meno che non vuoi usare tool commerciali.
Ciao,
ScriptJus 

 server per 1 mese?
Dipende da caso a caso. Per esempio per le soluzioni aziendali standard che 
normalmente seguo io posso fare una valutazione sufficientemente corretta 
anche senza dati effettivi: un domain controller, un file server, un printer 
server, un proxy, ecc.ecc. sono macchine il cui carico è essenzialmente solo 
funzione del numero utenti aziendali (salvo casi veramente eccezionali)
Già per un database può essere necessario raccogliere dei dati sul campo, 
anche se spesso può essere sufficiente chiedere informazioni alle ditta che 
producono i software che si appoggiano a quel DB.
Per altri usi bisogna affidarsi a chi ha esperienza in quello specifico 
ambito, perché non esiste un metodo deterministico per il dimensionamento (o 
meglio i metodi ci sono, ma in genere producono soluzioni sovradimensionate) 
ma molto è dettato dall'esperienza.


 Dovrei virtualizzare un SQL su cui girano diversi db.
Per quel che vuol dire, attualmente praticamente tutti i DB che ho in 
produzione girano in virtuale. Però tieni conto che le necessità in 
ambito ISP non sono necessariamente paragonabili a quelle dell'ambito 
enterprise...
I miei database o sono a basso carico (poche decine di 
richieste/secondo, per database di piccola dimensione ad uso web) oppure 
sono molto piccoli dimensionalmente (che in pratica significa tutta la 
tabella in RAM e alcune centinaia di interrogazioni/secondo)
Il che significa che in pratica il grosso cruccio con la progettazione 
di soluzioni DB (l'accesso allo storage) difficilmente vien tirato in 
ballo, da me.
Chi fornisce consulenza su virtualizzazione in ambito enterprise 
(THe_ZiPMaN, Whiplash) ha certamente più esperienza di me...
-- 
http://bofhskull.wordpress.com/

 (THe_ZiPMaN, Whiplash) ha certamente più esperienza di me...
Ho miei clienti diretti ($big_money_transfer_operator) che virtualizzano a 
tutto spiano db MS SQL, dopo i primi deployment fatti da noi.
Anche in $biggest_italian_bank ho visto non pochi MS SQL virtualizzati.
In azienda, ho tre pgsql virtualizzati che fanno il loro bravo mestiere
e un server in outsourcing di $big_finanziaria con Oracle, anch'esso
virtualizzato.
Con una buona SAN e opportuni dimensionamenti/accorgimenti si può fare, direi.

 funzione del numero utenti aziendali (salvo casi veramente eccezionali)
Come ha già scritto Skull, in ambito enterprise (o anche aziendale,
secondo me), le
necessità sono ben diverse da quelle in ambito ISP.
Sono necessarie san più potenti in ambito aziendale, IMHO.
In ambito isp i database (i miei, ma a quanto pare anche quelli di
skull) sono piccoli,
con moltissime letture (quindi cache a go-go) rispetto alle scritture
(anche di alcuni ordini
di grandezza, ad esempio 10 scritture ogni 10000 letture).
Ma anche se fossero 50-50, le scritture su db sarebbero di piccole
dimensioni, giusto una
insert in qualche tabella e non intere archiviazioni di file... In tal
caso, ne deve passare di acqua
sotto i ponti prima di saturare una iscsi, a maggior ragione se gli
accessi al db avvengono solo dietro
richieste fatte da rete pubblica limitate con qualche shaping sul
traffico.
Discorso differente per il web, dove gli utenti caricano via ftp file
di dimensioni assurde, ma sarebbero
sempre delle eccezioni, e non la norma, dove tradizionalmente un sito
internet è composto da tanti
piccoli file. (nulla poi vieta di di piazzare un cluster di due
reverse proxy fuori-san, con tonnellate di ram e
caching per 10-15 minuti, giusto per scaricare l'i/o diretto ai dischi
san. caching brevissimo per non rompere
i maroni agli utenti che caricano il file e non se lo vedono attivo
via web. Con tutte le macchine risparmiate
tramite virtualizzazione, due proxy ci vengon fuori)
Resto sempre più della mia idea: nel dubbio, o si compra fibra (con
costi di startup elevati) oppure conviene
farsi un clusterino con openfiler. due quadport intel con TOE ed
avresti performance, forse, superiori ad una san
iscsi entry level, ad un costo inferiore alla metà. (anche perchè si
potrebbe esportare in AoE anzichè iSCSI evitando
l'overhead di quest'ultimo)
Il più è solo trovare l'hardware corretto, un server con 12 dischi ad
esempio come l'intel o i sun (che però costano
e non so chi li vende in Italia, tanto per dirne una)
Sarebbe perfetto trovare un server con doppio controller integrato.
Difficilmente in una san hai un guasto tale da doverla
spegnere, dato che tutto è ridondato. In un server, se ti muore un
processore, lui si riavvia, se ti muore la controller tu sei a piedi.
Per cui ti servono due server in drbd.

 Per cui ti servono due server in drbd.
Il che può rappresentare un collo di bottiglia.


san.
Parole sante! 

 Il che può rappresentare un collo di bottiglia.
In che senso?
Per il ritardo dato dalla sincronia?
Se non hai grosse scritture (altrimenti fare una san in drbd sarebbe
un suicidio) non dovresti aver
problemi di sincronia, e con una quadport di ottimo livello
risolveresti quasi definitivamente.
(qualche consiglio su un server a molti dischi che non costi un occhio
della testa?
IBM mi pare faccia massimo 8 dischi da 2.5 pollici, HP fa 12 dischi ma
solo SATA, DELL 8 dischi da 2.5 pollici.
Ci sarebbe un Intel, ma in Italia non so dove sia in vendita, il mio
fornitore non ha quel modello)

 giusto che sia per mysql).
Una UPDATE in qualunque [R]DBMS  sono pochi byte che possono trasformarsi in 
*molte* giramenti di dischi (e non solo) :)
-- 
Vide

 Esempio del cavolo, ma dovrebbe rendere l'idea.
alla fine si, č cosě

 tutto spiano db MS SQL, dopo i primi deployment fatti da noi.
Giusto per curiosit�, ma in che zone (geografiche) bazzichi per lavoro?
Non c'ho potere di scelta economica, ma una dritta verso l'alto posso sempre 
tentarla...
Ciao,
ScriptJus 

 sempre tentarla...
Uhm...:-)