View Full Version : RAID 1 SW - Velocità ricostruzione
Stavo installando un server per testare Trustix in RAID 1; avendo solo 1 sata (Seagate 80Gb) sono andato a comprare un secondo HD, ma ovviamente in mezza provincia vendono solo Maxtor e l'altra mezza non ho potuto girarla ;)
Quindi ho 2 sata, Seagata 80Gb e Maxtor 120.
Attivando il Raid da installazione, ci mette una vita nella creazione dell'array, con rumori infernali (invece di schedulare in sequenza le partizioni le fa tutte assieme !)
Sono ripartito: installo solo 1 disco (seagate) e poi tiro su il raid.
All'incirca ho
/boot 100Mb
/ 3 Gb
/tmp 2 Gb
/usr 4 Gb
/var 15 Gb
/backup 20 Gb
/home il resto (circa 29 Gb)
(più spazio sprecato sul Maxtor).
A parte le difficoltà nel ricreare la struttura sul Maxtor e il bootloader, ma vi torna che ci vogliano ore e ore per il resync?
Qualcosa del tipo 40 minuti per la partizione da 3 Gb e 400 minuti per quella da 29 Gb ?? Sommandole tutte diventano più di 8 ore. Mettiamo che poi acceleri... ma non più di tanto
Esistono modi per accelerare il tutto?
Grazie!
mmm dovrebbero resyncarsi alla velocità di trasferimento che supportano, ovvero intorno hai 45 50 mega al secondo... ora potresti averli messi sulla stessa piattina o canale ed allora vai piu piano, oppure non hai attivo il dma.
ora non ho ben capito come hai tirato su il raid.. io lo tiro sempre su dopo e mai in installazione.
poi con un cat in proc controllo lo stato del resync, sempre che si verifichi, per ora solo test fortunatamente.
ciao
mmm dovrebbero resyncarsi alla velocità di trasferimento che supportano, ovvero intorno hai 45 50 mega al secondo... ora potresti averli messi sulla stessa piattina o canale ed allora vai piu piano, oppure non hai attivo il dma.
ora non ho ben capito come hai tirato su il raid.. io lo tiro sempre su dopo e mai in installazione.
poi con un cat in proc controllo lo stato del resync, sempre che si verifichi, per ora solo test fortunatamente.
ciao
Lo sto facendo su una Asus P4V800-X con VT8237 (senza usarne le funzionalità RAID), quindi su due canali SATA diversi. Il processore è un P4 2.4Ghz, quindi per quello che deve fare non è di sicuro una tartaruga ;)
Il RAID l'ho tirato su dopo l'installazione con mdadm. Tu usi per caso raidtool, configurandoti il raidtab?
E come boot loader a cosa ti appoggi? LILO o grub?
Non si sa mai, se dovessi farti qualche domanda più specifica ;)....
GRAZIE !
uso mdadm e lilo installato su entrambi i dischi.
dopo quello che mi hai detto non saprei che pesci prendere...
potresti provare una distro diversa solo per aver conferma della lentezza o normalità del resync dei dischi.
ciao
ilsensine
03-10-2005, 13:59
Se occorre effettuare un resync completo (ad es. perché un disco è stato aggiunto a un array esistente), la "lentezza" non è proprio inusuale. Anzi, non è neanche illogica.
Il resync viene effettuato da un thread a bassa priorità in background. Può essere interrotta in qualsiasi momento, e verrà automaticamente ripresa al successivo riavvio. Una volta che i dischi sono in sync, un eventuale resync dovuto a crash o mancanza di corrente viene effettuato solo sulle regioni modificate, quindi è pressocché istantaneo.
Non so se esiste un modo per "velocizzarlo", ma influirebbe comunque sulle prestazioni di sistema.
Mi sembra strano che effettui il resync in parallelo, l'ultima volta che ho controllato avveniva in serie (un array dietro l'altro sullo stesso device).
@_YTS_
Grazie, al limite proverò, ma mi piace questa distribuzione ;)
@ilsensine
Ti ringrazio per la delucidazione.
In effetti è comprensibile, ma mi sembra strano che su Linux non si sia prevista la possibilità di alzare la priorità del thread. Ad es., se sto installando da zero una macchina, mi piacerebbe avere un resync veloce per potere testare che tutto sia ok per procedere con l'installazione del resto. Non vorrei sbattermi e poi trovarmi con un sistema da rimettere in piedi per qualche problema. Se per mezz'ora il sistema deve essere quasi inutilizzato, se non per aggiornare il progresso dell'operazione, mi sta bene, ma poi vado "liscio".
Non è che scendendo di runlevel automaticamente si velocizzi?
Per l'ordine di resync, posso confermarti che hai ragione per quel che è, credo, la norma: se da un sistema funzionante aggiungo le partizioni all'array, il resync viene poi fatto in ordine.
Se l'operazione me la fa Trustix nel setup, le butta :( in parallelo. E senti che, man mano che unisci in RAID le partizioni speculari create, hai un incremento di rumore come se si aggiungessero coppie di Wanna Marchi in una stanza ;)
Sapendo che lo faceva in serie, all'inizio avevo anche pensato che il Maxtor fosse la solita ciofeca e cominciasse a saltare, invece probabilmente era la fatica di far saltare da una parte all'altra le testine.
Potrebbe essere un buon modo per far saltare i Maxtor :Prrr:
uso mdadm e lilo installato su entrambi i dischi.
dopo quello che mi hai
Tanto per avere una conferma, non potresti mica riportare qua il codice di lilo.conf ?
Lo hai installato con extra-raid-boot (vado a memoria) nella configurazione e hai invocato lilo con -x /dev/sda,/dev/sdb ??
Grazie
ilsensine
03-10-2005, 16:37
Ad es., se sto installando da zero una macchina...
Se stai installando da 0 una macchina, ti crei l'array ex-novo e non dovrebbe esserci alcun resync
Se stai installando da 0 una macchina, ti crei l'array ex-novo e non dovrebbe esserci alcun resync
Ahio' ;)
Dissi:
Se l'operazione me la fa Trustix nel setup, le butta in parallelo.
e fa rumore, sembra ci metta una vita.
Il metodo che uso, riassunto, per farlo da zero è:
1) installo la macchina su sda
2) replico le partizioni su sdb, che dichiaro come tipo fd
3) credo il raid con sdb e missing, formatto le partizioni e le monto
4) ci copio tutto sda (a seconda di dove leggo, per quest'operazione trovo metodi diversi più o meno funzionanti)
5) modifico fstab duplicato nel disco md per metterci appunto gli opportuni device al posto di sda
6) modifico per prova la sola root di lilo e riparto
Se và, aggiungo il disco originario al raid, ma così facendo parte il resync....
C'è un'altra procedura migliore?
Stavo pensando di provare a partire da un live CD....
allora crei due file di configurazione di lilo, praticamente speculari eccetto il device di boot e la root....
poi lanci le due righe di sotto, ovviamente i nomi li metti a dovere:
lilo -C /etc/lilo.conf.hda
lilo -C /etc/lilo.conf.hdc
cosi facendo installi il bootloader su entrambi i dischi e se ne stacchi uno al riavvio parte l'altro.
cmq in rete trovi di meglio come spiegazione, ciao
io sono appena riuscito a farlo (grazie ai consigli di tutti :)) e impiega circa 5-6 minuti a ricostruire un raid di 4 giga.
dimenticavo: i dischi sono due maxtor ata133 da 200gb. ma erano occupati solo pochi giga.
ps: sicuro che sia attivo l'u-dma sui dischi?
OK, grazie.
Immagino che in un caso dovrò dare -b /dev/sda e nell'altro /dev/sdb, no?
Però dentro cosa c'è scritto?
Perchè in rete ho trovato di metterci md0 (nel mio caso md1) come root, ma da quello che mi dici dovrà essere invece sda1 e sdb1 rispettivamente, vero ?
Grazie ancora.
ecco qua, li capisci meglio che mille parole...
http://www.faqs.org/docs/Linux-mini/Boot+Root+Raid+LILO.html#ss3.1
praticamente qualcosa del genere:
# cat lilo.conf.sda
# GLOBAL SECTION
# device containing /boot directory
disk=/dev/md0
# geometry
bios=0x80
sectors=32
heads=64
cylinders=4095
# dummy
partition=/dev/md1
# start of device "disk" above
start=32
boot=/dev/sda
map=/boot/map
install=/boot/boot.b
image=/boot/bzImage
root=/dev/md0
label=LinuxRaid
read-only
# ------------------------
# cat lilo.conf.sdb
# GLOBAL SECTION
# device containing /boot directory
disk=/dev/md0
# geometry
bios=0x80
sectors=32
heads=64
cylinders=4095
# dummy
partition=/dev/md1
# start of device "disk" above
start=32
boot=/dev/sdb
map=/boot/map
install=/boot/boot.b
image=/boot/bzImage
root=/dev/md0
label=LinuxRaid
read-only
ciao
OK, grazie.
Ho visto dove stavo sbagliando: c'erano poche informazioni nel lilo.conf (quello suggerito da trustix) e soprattuto non c'era la geometria. Probabilmente, avendo due dischi diversi, è ancor più d'obbligo metterla.
Però.... Kernel Panic :( mi dice che non può montare la root.
Non credo sia perché la prima volta che ho unito il disco principale (ex missing) all'array ho fatto il reboot dopo 10 minuti. E se mancasse la corrente?
Comunque con Knoppix ho fatto terminare l'operazione, ma niente.
La cosa interessante è che, se non ho visto male, da Knoppix si viaggia a 47.000K/s mentre da Trustix a 1.200Kb/s
Si può toccare qualcosa per accelerare?
Si può toccare qualcosa per accelerare?
La risposta è si e alla fine l'ho trovata qua:
http://portal.suse.com/sdb/en/2005/08/rschmid_md_speed.html
In sintesi, la velocità di resync ha un limite minimo e massimo specificato in /proc e più precisamente
/proc/sys/dev/raid/speed_limit_min => 1000
/proc/sys/dev/raid/speed_limit_max => 200000
Basta alzare il minimo con
echo "40000" > /proc/sys/dev/raid/speed_limit_min
Che subito pompa alla grande :sofico:
Per quanto riguarda il fatto che avvenga in parallelo, sembra che non sia un problema di Trustix. Ho visto da qualche parte (ho perso il link, ne sto leggendo troppi in questo momento) che il kernel 2.6 è "convinto" che se un raid è fatto su più partizioni, allora c'è un rapporto 1:1 tra partizioni e disco, per cui il parallelizzare incrementa le prestazioni. Ma và và :( !
Quindi nel mio caso ho il sistema piantato e droppato nella shell dopo il riavvio post installazione fatta direttamente su RAID 1 sw.
Probabilmente è così lento che non ce la fa a finire prima di entrare :(
Ora stop provando a stoppare tutti quelli in parallelo, alzare il minimo del resync e attivarli uno ad uno man mano che finiscono.
ilsensine
04-10-2005, 07:41
La risposta è si e alla fine l'ho trovata qua:
http://portal.suse.com/sdb/en/2005/08/rschmid_md_speed.html
In sintesi, la velocità di resync ha un limite minimo e massimo specificato in /proc e più precisamente
/proc/sys/dev/raid/speed_limit_min => 1000
/proc/sys/dev/raid/speed_limit_max => 200000
Basta alzare il minimo con
echo "40000" > /proc/sys/dev/raid/speed_limit_min
Che subito pompa alla grande :sofico:
Buono a sapersi. Immaginavo un file in proc.
Mi sembra strano che le impostazioni non sono specifiche per ciasun array
Ho visto da qualche parte (ho perso il link, ne sto leggendo troppi in questo momento) che il kernel 2.6 è "convinto" che se un raid è fatto su più partizioni, allora c'è un rapporto 1:1 tra partizioni e disco
Non avrai mica fatto un array con più partizioni sullo stesso disco?
buona a sapersi la storia del transfert da settare in proc...
cmq la prova fatta con knoppix ha dato il risultato che immaginavo, ovvero che era un problema di distro.
la trustix inoltre per il fatto di essere compilata con lo stack smashing credo sia un filino piu lenta, spero di non aver detto una cavolata sbagliando distro in questione..
ciao
Non avrai mica fatto un array con più partizioni sullo stesso disco?
Dipende da cosa intendi: ho fatto si più partizioni del disco, ma ognuna è stata messa in raid con la speculare sull'altro disco.
Quindi ho, ad es., 5 partizioni su sda e 5 su sdb associate una ad una.
Non ho neanche una partizione di A in RAID con un altra di A.
Come dicevo, sembra che partano dal presupposto che se ho 4 partizioni, ho 4 dischi :(
la trustix inoltre per il fatto di essere compilata con lo stack smashing credo sia un filino piu lenta, spero di non aver detto una cavolata sbagliando distro in questione..
ciao
No, è vero http://linux.trustix.com/whatsnew.html . E' compilata con questa protezione. Per un server credo che ogni protezione sia sempre la ben venuta ;)
ilsensine
04-10-2005, 09:45
Dipende da cosa intendi: ho fatto si più partizioni del disco, ma ognuna è stata messa in raid con la speculare sull'altro disco.
Ok ho una configurazione simile in ufficio. Quando mi ha fatto la ricostruzione (era zompato un disco e l'ho sostituito), mi ha ricreato prima un array poi l'altro, non in contemporanea...
Forse è cambiato qualcosa negli ultimi kernel? Quando ho fatto la ricostruzione avevo (mi sembra) un 2.6.8...
mm ilsensine con ricreato prima un array intendi dire prima un md0 poi un md1 e via dicendo?
cmq si di solito il raid fa cosi, farlo in parallelo sarebbe alquanto carino ma ai fini delle prestazioni non gioverebbe in quanto il transfer seppur limitato dalla meccanica sarebbe limitato anche dall'andare avanti e indietro lungo la superficie del disco della testina, un gran casino insomma.
PS: non è un initd parallelo come si potrebbe pensare, è copia di dati, meglio farlo sequenziale o controllato con ncq ma allora il discorso cambia, si lavora un pelino piu alto come controllo.
PS: esatto avevo ricodato giusto... la trustix è compilata con ssp è quindi un pelino piu lenta.
ho in produzione personale una slack compilata con ssp.... avevo fatto lo stesso con una debian, utilizzare trustix spero sia solo perche ha tutto gia integrato, non per un senso di falsa sicurezza.
ho in produzione personale una slack compilata con ssp.... avevo fatto lo stesso con una debian, utilizzare trustix spero sia solo perche ha tutto gia integrato, non per un senso di falsa sicurezza.
Bhè, è comoda per molti aspetti.
A differenza di altre, si installa con tutto disattivato, per cui attivo solo quello che mi serve senza rischiare di dimenticarmi di disattivare qualche cavolata.
Inoltre mi pare installi proprio il minimo indispensabile di suo, non devo andare a spulciare nell'elenco dei pacchetti quelli inutili, ecc., ne sbattermi con le dipendenze per partire da zero e aggiungere di volta in volta.
Poi è ovvio, per la sicurezza occorre configurare bene. Ma trustix mi sembra un buon compromesso tra facilità e paranoicità.
Debian è fulminata, qualsiasi cosa deve essere autorizzata.
Per mettere su le applicazioni Java (che è poi la mia attività principale) c'è da dannare sempre per scrivere qualche policy :(
Bhè, è comoda per molti aspetti.
A differenza di altre, si installa con tutto disattivato, per cui attivo solo quello che mi serve senza rischiare di dimenticarmi di disattivare qualche cavolata.
Inoltre mi pare installi proprio il minimo indispensabile di suo, non devo andare a spulciare nell'elenco dei pacchetti quelli inutili, ecc., ne sbattermi con le dipendenze per partire da zero e aggiungere di volta in volta.
Poi è ovvio, per la sicurezza occorre configurare bene. Ma trustix mi sembra un buon compromesso tra facilità e paranoicità.
E' lo stesso motivo per cui la uso sul mio serverino... ha i programmi che mi servono, nè più nè meno, inoltre preferisco comuqnue sempre vim a debconf! Appena tiro su un muletto volevo provare anch'io il discorso raid con Trustix! Tra l'altro Trustix a differenza penso anche di Sarge liscia usa EVMS... vantaggi o svantaggi?
Ps piccolo OT: tu riesci a portarla in UTF-8? Io ho installato glibc-locales, modificato il file /etc/locales e generato relativi locales, ma non rieco a mandarla correttamente in unicode... boh.. :confused:
Appena tiro su un muletto volevo provare anch'io il discorso raid con Trustix!
A me Trustix sta facendo una cosa strana, sarei tentato di segnalarla sul loro forum.
Se configuro un raid con queste partizioni durante l'installazione:
md0 /boot 100 Mb (da 2 partizioni primarie)
md1 / 3 Gb (da 2 partizioni primarie)
sda3 swap 1 Gb primaria
md2 /tmp 2 Gb
md3 /usr 4 Gb
md4 /var 15 Gb
md5 /backup 20 Gb
md6 /home il restante
al successivo riavvio si pianta e mi manda nella shell dicendo che se sono sicuro che md1 è un ext2 posso provare a ripararla. Questo regolarmente, con due macchine completamente diverse (quella di oggi 2 sata Hitachi identici da 80gb, P4 3Ghz e mobo Asus con SIS).
Se invece faccio queste partizioni (cosa che ho fatto perché ero stufo di sbattermi):
md0 / 15 Gb (da 2 primarie)
sda2 swap 1 Gb primaria
md1 /var/log 10 Gb (da 2 estese)
md2 /backup 20 Gb (da 2 estese)
md3 /home il resto (da 2 estese)
Tutto fila liscio e al riavvio mi porta tranquillamente alla richiesta della login.
A questo punto, come dicevo, c'è ancora in corso il resync delle partizioni.
Allora io consiglio di procedere così:
1) fermare /etc/init.d/syslogd (perché scrive in var/log)
2) smontare /home, /backup, /var/log (e per questo si deve fermare il syslog)
3) fermare uno ad uno i raid che stanno facendo resync pazzescamente lenti e in parallelo (1000Kb/s con tempo stimato anche di 500 minuti). Tutti tranne quello su cui è montata la root, che deve essere lasciato proseguire:
mdadm --stop /dev/md3
mdadm --stop /dev/md2
mdadm --stop /dev/md1
4) alzare a 40000 la velocità minima di resync (ma oggi anche 60000 andava bene, anzi meglio, purché non il server non stia facendo altro)
echo "40000" > /proc/sys/dev/raid/speed_limit_min
Il motivo per cui si fermano i raid è che con questa velocità minima fai impazzire i dischi ;) e io non rischierei
5) riattivare uno ad uno i vari md con (attenzione ai numeri di md e sda, sdb)
mdadm -A -R /dev/md1 /dev/sda5 /dev/sdb5
mdadm -A -R /dev/md2 /dev/sda6 /dev/sdb6
mdadm -A -R /dev/md3 /dev/sda7 /dev/sdb7
6) abbassare a 10000 il limite minimo di velocità per il futuro (quando non sei lì a controllare se il server può permettersi velocità sostenute)
echo "10000" > /proc/sys/dev/raid/speed_limit_min
Tra l'altro Trustix a differenza penso anche di Sarge liscia usa EVMS... vantaggi o svantaggi?
Non so dirti. Al momento più che altro mi ha disorientato. Credo ci sia un GUI per gestirlo da remoto via SSH, ma non ti so dire di più.
Ps piccolo OT: tu riesci a portarla in UTF-8? Io ho installato glibc-locales, modificato il file /etc/locales e generato relativi locales, ma non rieco a mandarla correttamente in unicode... boh.. :confused:
Non mi sono accorto della necessità, quindi non so se ci sia già o meno (ci guardo).
Per cosa ti serve?
P.S.: sto usando la 3.0 Viper del 23/9/2005
Ciao! Grazie per le risposte!
Data l'ora non mi ci metto a leggerlo, domani vedrò di farlo: http://evms.sourceforge.net/user_guide/#appxmdreg magari ci trovo qualcosa di utile! Sarà, ma secondo me c'è lo zampino dell'EVMS... anche senza RAID, la prima versione uscita (3.0 appena uscita) su un disco di prova da 20GB mi si piantava durante il partizionamento con EVMS.
X l'UTF-8 è solo che ho tutte le macchine in unicode, era per "sfizio" niente di più!
Comunque viste le mie pretese di server casalingo, mi trovo molto bene con Trustix! Notte!
Dalla documentazione di EVMS niente di che, a parte quello già detto:
You can follow the progress of the sync process by examining the /proc/mdstat file. You can also control the speed of the sync process using the files /proc/sys/dev/raid/speed_limit_min and /proc/sys/dev/raid/speed_limit_max. To speed up the process, echo a larger number into the speed_limit_min file.
Per quanto la velocità del primo sync, prima di concludere l'installazione con Viper e del riavvio, si potrebbe editare /etc/sysctl.conf e aggiungere dev.raid.speed_limit_min = 40000 così al riavvio srabbe già impostato alla corretta velocità e poi rimuovere la riga o riportarla al valore originale. Rimane il problema della paralelizzazione del rsync...
PS: esatto avevo ricodato giusto... la trustix è compilata con ssp è quindi un pelino piu lenta.
ho in produzione personale una slack compilata con ssp.... avevo fatto lo stesso con una debian, utilizzare trustix spero sia solo perche ha tutto gia integrato, non per un senso di falsa sicurezza.
Sicuro che lo sia anche la versione 3.0? Perchè avevo cercato qualche info in rete, ma nulla... c'è qualche modo per scoprirlo? (Ad esempio il fatto che per compilare il kernel debba usare -fno-stack-protector dipende dall'SSP?)
Grazie! ciao!
Sicuro che lo sia anche la versione 3.0?
Credo lo confermino qua http://www.trustix.org/content/view/6/29/
E' di febbraio; a memoria non ricordo se era già in giro la prerelease della 3.0, ma mi pare di si.
Credo lo confermino qua http://www.trustix.org/content/view/6/29/
E' di febbraio; a memoria non ricordo se era già in giro la prerelease della 3.0, ma mi pare di si.
Ah ecco dov'era.. li proprio sotto il naso! :oink: Grazie! ;)
mmm il kernel mi pare che non riesci a compilarlo con ssp attivo... il resto si :D
oggi mi sono sparato un vsfptd + SSL + ssp + flags ottimizzati + chroot + kernel grsec
tutto su slack 10.2
mi diverto cosi... no scherzo è per l'azienda area ftps sicura
ciao
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.