Le Megacli sono delle utility a linea di comando per la  gestione di controller RAID della LSI.

A questo link vi è una chiara descrizione su come installarli su di una Debian. Devo dire che la guida è molto chiara e soprattutto indica passo passo quali pacchetti di supporto installare. Per le MegaCLI basta cercare nel sito della LSI che l’autore indica e al primo controller scaricare il pacchetto zippato dal nome 8.02.16_MegaCLI.zip (l’attuale release).

Enjoy …

Installing MegaCLI in Debian-based System

Related posts:

1. Debian Squeeze verrà rilasciata nell’estate 2010
2. LSI MegaRAID SAS
3. iDrac 6 Debian Xen based e Serial Console Redirection

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Una tematica sempre viva nella implementazione di una architettura complessa per la erogazione di un servizio web è su come fare un buon tuning del file system per trovare la giusta combinazione tra velocità e sicurezza del file. Velocità sia nella scrittura che nella lettura del dato e sicurezza che questo non venga perso per eventi accidentali.
A questo link (http://wiki.centos.org/HowTos/Disk_Optimization) ho trovato alcuni buoni consigli per poter fare questo tuning e devo dire che calza abbastanza al caso mio: una macchina DELL R710 con 4 dischi da 1TB in modalità RAID 5; con lo scopo di erogare file via web-services.
Ho fatto delle prove su diversi file system usando i tool di testing quali Bonnie++ e Iozone. Ma prima di cambiare tipo di file system ho voluto provare a fare il tuning di quello che generalmente uso, ovvero il tipo ext3.
Le info necessarie per i settaggi sono state controllate direttamente a livello del controller PERC H700 che attualmente monta una Dell PE R710, come si vede dalla figura inclusa.
Le opzioni di creazione della partizione sono state:

<br />:~# mkfs.ext3 -b 4096 -E stride=16 -E stripe-width=48 -O dir_index /dev/xxxx<br />

E interrogando la partizione in oggetto ottengo le seguenti info:

<br />:~# tune2fs -l /dev/xxxx<br />tune2fs 1.41.6 (30-May-2009)<br />Filesystem volume name:   <none><br />Last mounted on:          <not available><br />Filesystem UUID:          4f5416fd-963d-4cbb-baf6-0db9b385ba88<br />Filesystem magic number:  0xEF53<br />Filesystem revision #:    1 (dynamic)<br />Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super large_file<br />Filesystem flags:         signed_directory_hash<br />Default mount options:    (none)<br />Filesystem state:         clean<br />Errors behavior:          Continue<br />Filesystem OS type:       Linux<br />Inode count:              183042048<br />Block count:              732168183<br />Reserved block count:     36608409<br />Free blocks:              720628010<br />Free inodes:              183042037<br />First block:              0<br />Block size:               4096<br />Fragment size:            4096<br />Reserved GDT blocks:      849<br />Blocks per group:         32768<br />Fragments per group:      32768<br />Inodes per group:         8192<br />Inode blocks per group:   512<br />RAID stripe width:        48<br />Filesystem created:       Fri Dec 17 17:23:34 2010<br />Last mount time:          n/a<br />Last write time:          Fri Dec 17 17:32:06 2010<br />Mount count:              0<br />Maximum mount count:      36<br />Last checked:             Fri Dec 17 17:23:34 2010<br />Check interval:           15552000 (6 months)<br />Next check after:         Wed Jun 15 18:23:34 2011<br />Reserved blocks uid:      0 (user root)<br />Reserved blocks gid:      0 (group root)<br />First inode:              11<br />Inode size:               256<br />Required extra isize:     28<br />Desired extra isize:      28<br />Journal inode:            8<br />Default directory hash:   half_md4<br />Directory Hash Seed:      0a4ecd73-58f9-4675-9dfe-f90cf0f7f667<br />Journal backup:           inode blocks<br />

Altre opzioni da seguire sono le opzioni di “mounting” e nel mio caso penso che seguirò la “noatime” come consigliato dalla guida sopra citata.

Ad ogni modo vedremo come andrà durante i test successivi che non mancheranno. Ovviamente i consigli sono ben accetti.

Technorati Tags: ext3, RAID, Dell, R710, iozone, bonnie++

Related posts:

1. Tuning del file system ext3 per un RAID hardware

Articoli correlati elaborati dal plugin Yet Another Related Posts.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

E’ possibile effettuare un monitoring dell’array RAID di un controller LSI Logic SAS 5/iR che montano macchine DELL, molto basilare, ma utile e immediato. Utilizzeremo il tool mpt-status.

La scelta di questo tool è molto semplice e (a volte) obbligata se la macchina in questione ha poca RAM.

Infatti molti scelgono di monitorare il tutto tramite omreport di Dell (parte della suite OpenManage) che sicuramente è il migliore tool di monitoraggio locale per i controller RAID (e non solo) in quanto, oltre a controllare lo stato dei dischi, restituisce molte più informazioni su tutto l’hardware della macchina (e del RAID stesso).

Purtroppo la compilazione di questo tool, a volte, può essere macchinosa su sistemi operativi CentOS, in particolare sulla versione 5.3.

Infatti la compilazione richiede il pacchetto kernel-devel ma, dopo numerosi test effettuati, non contiene (almeno la versione sui mirror ufficiali) alcune librerie LSI.

Per ovviare a questo problema possiamo adoperare rpmbuild ed il sorgente del kernel nella versione src.rpm.

Ho riassunto, in breve, tutti i comandi da lanciare per compilare correttamente mpt-status su CentOS ad ogni aggiornamento di kernel.

yum install rpm-build redhat-rpm-config unifdef -y
cd ~
rm -rf ~/rpmbuild
mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
echo ‘%_topdir %(echo $HOME)/rpmbuild’ > .rpmmacros
rm -f kernel-`uname -r`.src.rpm
wget http://mirror.centos.org/centos/5/updates/SRPMS/kernel-`uname -r`.src.rpm
rpm -i kernel-`uname -r`.src.rpm
rm -f kernel-`uname -r`.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -bp –target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee prep-out.log
cd /usr/src
rm -rf mpt-status-1.2.0
wget “http://freshmeat.net/urls/7a85a1d3af8efa1dbe086c142f773164? -O mpt-status-1.2.0.tar.gz
tar zxvf mpt-status-1.2.0.tar.gz
cd /usr/src/mpt-status-1.2.0
make KERNEL_PATH=~/rpmbuild/BUILD/kernel-`uname -r | cut -d “-” -f1`/linux-`uname -r | cut -d “-” -f1`.`uname -m`
make install
mknod /dev/mptctl c 10 220
modprobe mptctl

Per chi invece ha un sistema x86 e non ha tempo da dedicare alla compilazione, puo’ sempre trovare l’rpm qui disponibile, appunto, solo per sistemi 32bit.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Secondo un articolo sarebbe il momento di passare a raid a tripla parità.

Al momento la protezione più alta è offerta da configurazioni Raid6 a doppia parità, ma il crescente aumento dello spazio disco può mettere in crisi questi sistemi. La soluzione verrebbe dall’introduzione di un possibile Raid7. In realtà per definire uno standard più personalizzabile si arriverebbe alla definizione di Raid 7.x:

• Raid 7.1 = Raid5
• Raid 7.2 = Raid6
• Raid 7.3 = tripla parità

Nonostante la soluzione proposta sia utile per migliorare la sicurezza dei dati, non è che una componente di un sistema che è forte tanto quanto la sua parte più debole. Rafforzare la solidità dei dati sui dischi senza lavorare anche in altri punti può portare ad un eccessivo senso di sicurezza.

Purtroppo anche nei sistemi più sicuri, nel lungo periodo, avvengono delle corruzioni ai dati che spesso non vengono segnalate, come potete veder rappresentato in questa presentazione. Una soluzione possibile per arrivare a sistemi più sicuri è l’uso di checksum end-to-end come chiamati nella terminologia di ZFS.

Via | Acm

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Un post un po diverso dal solito, invece che spiegare qualcosa propongo un dibattito per approfondire un argomento di cui parlavo in questi giorni con alcuni amici e colleghi:

La situazione finale dovrebbe essere un piccolo file server, basato su una scheda Intel DG35EC, Debian Lenny e 1 terabyte di storage, dischi SATA II collegati al controller della scheda madre e raid gestito da md. La macchina dovrebbe mantenere un vmware server con relative VM e un po di backup di altre macchine della rete.

Il problema su cui apro la discussione e la seguente:

Conviene installare 2 dischi da 1TB in raid 1 o 3 dischi da 500 MB in raid5? La spesa per l hardware sarebbe la stessa per entrambe le configurazioni.

Non siate timidi, partecipate con i vostri consigli, le vostre esperienze, le vostre intuizioni e magari qualche sfrombolone, l importante e che i commenti siano in tema

(per ora saro imparziale e non rivelero come la penso)

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

3 dischi sata da 500 GB: sda, sdb, sdc

Per problemi di gestione del boot manager (grub) tutte le partizioni saranno configurate in RAID5, tranne la /boot che verra configurata in RAID1 con un disco di spare (se salta uno dei due dischi da cui la macchina esegue il boot, la partizione sul terzo disco (normalmente non utilizzata) viene inserita in automatico e sincronizzata con quella superstite).

Le nostre partizioni quindi saranno cosi organizzate:

sda1 sdb1 (raid1) sdc1 (spare) /boot
sda2 sdb2 sdc3 (raid5) swap
sdc3 sdb3 sdc3 (raid5) /home
sdc4 sdb4 sdc4 (raid5) /

Utilizzare il disco di installazione di ubuntu in versione alternate (la potete scaricare come la normale versione desktop da ubuntu.com o da qualsiasi altro mirror)

Al momento di partizionare i dischi selezionate l opzione MANUAL.

Create le partizioni che vi servono ma invece che ext3 e swap, marcatele come RAID.

N.B.: sda1, sdb1, sdc1 devono avere il flag di boot attivo.

Per velocizzare le seguenti operazioni di sincronizzazione degli array RAID dopo la loro creazione, e consigliabile eseguire il seguente comando che ha il difetto di sovraccaricare un po il sistema (e per questo non e consigliabile in produzione) ma in fase di installazione ci consente di concludere il tutto in tempi ragionevoli:


echo 50000 > /proc/sys/dev/raid/speed_limit_min

Dopo aver completato la creazione delle partizioni, selezionare la voce (configurazione RAID software)

Creare come detto (la vostra configurazione potrebbe essere diversa):

1 array raid1 con sda1, sdb1 (e sdc1 come spare)
1 array raid5 con sda2, sdb2, sdc2
1 array raid5 con sda3, sdb3, sdc3
1 array raid5 con sda4, sdb4, sdc4

Premere ALT-F2 e controllare l avanzamento della sincronizzazione degli array RAID con il comando:

cat /proc/mdstat

Concludere l installazione rispondendo alle domande del sistema (utenti, nome macchina, ecc ecc)

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Prossimamente mi troverò a configurare un fileserver, che dovrà servire una cinquantina di directory condivise attraverso Samba. L’hardware scelto è un Lenovo ThinkCentre M58, con due dischi SATA da 500GiB: so che l’ideale sarebbe stato un vero controller RAID, ma i prezzi sono quelli che sono e questo passa il convento. Per quanto riguarda il sistema operativo, sarà Debian Lenny: non è ancora stata rilasciata come stable, ma per quanto mi riguarda lo è a sufficienza.

Ho in mente una configurazione basata su RAID software (che mi dicono essere decisamente più stabile e performante rispetto a dmraid) e LVM, ma mi piacerebbe sentire qualche opinione da qualcuno più esperto di me, onde evitare di commettere errori banali.

Configurazione dei dischi

Probabilmente qualcuno storcerà il naso perché le partizioni di root e swap non sono gestite da LVM, ma c’è un motivo: pare che GRUB abbia qualche problema a fare il boot da LVM (l’installazione di Debian in qualche modo me lo conferma, proponendo LILO), quindi ho preferito mantenerle fuori. D’altra parte, se ci sarà una partizione che potrebbe avere bisogno di più spazio, non sarà nè quella di root nè la memoria virtuale.

Aggiungere dischi

Se mai ci fosse la necessità di avere più spazio, basterà comprare un altro paio di dischi, configurarli in RAID-1, aggiungerli al gruppo di volumi e allargare la partizione (cosa che con XFS si può fare a partizione montata).

Test prima di mettere la macchina in produzione

• mettere, una alla volta, le partizioni in fail (anche per controllare il funzionamento delle mail di notifica) e poi aggiungerle nuovamente all’array, giusto per verificare che tutto continui a funzionare ed avere una stima dei tempi di sincronizzazione del RAID
• avviare il sistema con un disco alla volta e verificare che parta correttamente
• preparare un CD di avvio di emergenza con GRUB e provarlo prima che sia necessario usarlo veramente, giusto perchè non si sa mai
• definire e provare una procedura per la sostituzione di un disco, stamparla e incollarla al case. Giusto per non trovarsi a fare cazzate, presi dalla fretta, quando sarà necessario
• provare un backup e un ripristino, cosa da fare indipendentemente da RAID e LVM
• qualcos’altro?

E quindi?

Quindi mi sembra di non aver dimenticato nulla, ma siccome non si sa mai chiedo consiglio: c’è qualcosa che non ho considerato?

Ti è piaciuto l articolo, eh? OFFRIMI UNA BIRRA! (è sufficiente essere iscritti a Paypal o avere una carta di credito, anche Postepay)

Condividi :

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Se avete un raid software sulla vostra macchina linux potete monitorarne gli eventi (errori, disallineamenti, crash) ricevendo mail a un indirizzo di vostra scelta.

Per configurare questa feature dovete lanciare il seguente comando:

sudo dpkg-reconfigure mdadm

Il sistema provvedera a chiedervi una serie di cose, tra cui l indirizzo email per la ricezione dei report.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Situazione: un server con due dischi in RAID1 software, ossia in mirroring, con Linux. I dischi sono SCSI, se fossero IDE o SATA il problema non cambierebbe. Il disco di avvio è sda, ed è “specchiato” con sdb. Si guasta il disco sda, ed occorre sostituirlo. Si spegne il server, si sostituisce con uno nuovo, si riaccende il server. Risultato: Non system disk or disk error. Il server non riparte.

Dato che il bootloader e GRUB sono completamente installati solo sul disco sda, la sua sostituzione con un disco vuoto toglie la possibilità di fare il boot. Come risolvere?

Si può operare in due modi: a cose fatte, ossia col disco già guasto e computer riavviato, oppure prima di spegnere il computer, o meglio prima che il disco si guasti, ossia al momento dell’installazione.

Nel primo caso occorre usare la modalità “Rescue” messa a disposizione da Fedora, avviare il server dal DVD di installazione ed operare come se si fosse perso il bootloader, come spiegato nella guida di installazione di Fedora nell’apposito capitolo.

Nel secondo caso si può operare in anticipo, o anche appena prima di spegnere il server per sostituire il disco guasto. Cosa andiamo a fare: installiamo GRUB anche sul secondo disco con tutto il necessario per far eseguire il boot anche da questo.

Da un terminale dove siamo root entriamo nella console di comando di GRUB:

# grub

    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]

grub>

Per prima cosa vediamo se è tutto installato come ci serve, ossia se i file necessari a GRUB sono su tutti e due i dischi:

grub> find /grub/stage1
 (hd0,0)
 (hd1,0)

GRUB risponde nella sua notazione con l’indicazione delle partizioni dove sono i suoi file. Normalmente dovrebbero essere su tutti e due i dischi, tranne naturalmente il caso in cui uno dei due sia guasto, ma a quel punto ci interessa che siano installati sul disco ancora funzionante. Annotiamo la partizione per il secondo disco (hd1), in questo caso la 0, e procediamo ad installare:

grub> device (hd0) /dev/sdb

Con questo abbiamo detto a GRUB di considerare il secondo disco come primario. Serve perché al boot con il disco principale guasto, GRUB considererà il secondo disco come primo, per cui i comandi devono essere impartiti considerando quella ipotesi. Naturalmente dovremo sostituire adeguatamente i device per adattarli al nostro caso.

grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0xfd

Con questo abbiamo detto a GRUB quale sarà la partizione di avvio, ossia la root. Attenzione che può non essere la root del filesystem, ma è la partizione dove è posizionata la directory di boot con i file di GRUB. Nel mio caso avevo una partizione separata di boot, la prima sul disco.

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd0)"...  15 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.

Con questo abbiamo installato tutto il necessario per il boot. Possiamo spegnere il server, sostituire il disco guasto e riavviarlo, ricordando che occorre dire al BIOS del server o del controller di avviare dal secondo disco e non dal primo.

Riferimenti

• La documentazione di GRUB
• Una guida illuminante dalla mailing list DELL
• La documentazione sul RAID software di Linux (non aggiornatissima, ma sempre utile)

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 15% [?]

Puoi visualizzare il post originale qui.

Popularity: 13% [?]

Puoi visualizzare il post originale qui.

Popularity: 9% [?]

Puoi visualizzare il post originale qui.