Newsgroup: it.comp.os.linux.sys
Titolo: mdadm: ripristino raid

Visto che qui dentro c'è gente che sa usare il raid software in maniera decisamente migliore della mia, faccio qualche domanda:
 
1) in caso di guasto ad un disco, per sostituirlo, devo fare manualmente il remove+add per ciascun volume o c'è un comando che lo fa in automatico?
 
Del tipo:
mdadm /dev/md1 --fail /dev/sda1 --remove /dev/sda1
mdadm /dev/md2 --fail /dev/sda2 --remove /dev/sda2
mdadm /dev/md3 --fail /dev/sda3 --remove /dev/sda3
--cambio il disco--
mdadm /dev/md1 --add /dev/sda1
mdadm /dev/md2 --add /dev/sda2
mdadm /dev/md3 --add /dev/sda3
 
 
Oppure c'è qualche bel comando che lo fa in automatico, del tipo:
mdadm --togli /dev/sda
--cambio il disco--
mdadm --metti /dev/sda
 
In pratica, gestendo automaticamente partizioni e volumi. In raid hardware basta togliere e mettere il disco, poi fa tutto lui. Sul software devo farlo a mano?
 
2) ho macchine super vecchie, quando muore un disco, il rebuild mi uccide anche l'altro (vuoi perchè era già danneggiato, vuoi perchè le ulteriori sollecitazioni su dischi di 10 anni non sono salutari etc etc). Proprio oggi son stato costretto a riavviare la macchina perchè piantata da errori di I/O sul disco "sano" durante il rebuild. Ovviamente, il boot non è riuscito, riavvio da live, e mi metto ad armeggiare con mdadmin.
Un create mi dice, giustamente, che la partizione contiene già un raid e chiede conferma sul proseguire o meno.
 
Premesso che sono riuscito a ripristinare tutto, in queste situazioni, c'è una procedura per poter ricreare un RAID cercando di partire da dati già esistenti ?
 
In altre parole, per farla breve, qual'è la procedura corretta per cercare di salvare il salvabile quando tutto è andato in vacca? Un --assemble non ha dato esito positivo.

 In altre parole, per farla breve, qual'è la procedura corretta per cercare di salvare il salvabile quando tutto è andato in vacca? Un --assemble non ha dato esito positivo.
 
Vi sono varie possibilita`.
Un "--assemble --force" spesso risolve il problema.
 
Poi dipende caso per caso.
In generale, se i dischi non sono proprio partiti,
cioe` se ve ne sono a sufficienza, si puo` provare
il "force", che ignora una possibile diversita` sul
event counter dei singoli dischi.
Un altra possibilita`, ad alto rischio, e` un "create",
con i dischi nello stesso preciso ordine originale.
In questo caso, pero`, bisogna sapere anche l'offset
dei dati e, se diverso da quello del "create" attuale
(nel tempo sono cambiate delle cose), fornirglielo
esplicitamente (ci dovrebbe essere una versione di
"mdadm" che consente questo). Se invece si usa "mdadm"
che ha creato, in primis, l'array, non dovrebbe esservi
questo problema.
 
Credo vi siano altri metodi, ma il consiglio e` di
non fare niente, chiedere sulla mailing list, fornendo
tutte le informazioni del caso (mdadm -D, -E, versioni
varie, etc., etc.).
 
bye,
 
-- 
 
piergiorgio

 il remove+add per ciascun volume o c'è un comando che lo fa in automatico?
 
Tempo fa mi ero fatto un appunto per il PC di casa:
 
0. (fare sempre un grub-install /dev/sdb dopo ogni aggiornamento automatico 
su /dev/sda per tenerlo allineato)
 
1. spegnere il sistema
 
2. rimuovere il disco guasto
 
3. se sda guasto spostare sdb su sda e aggiungere il nuovo disco come sdb, 
altrimenti sostituire semplicemente il disco
 
4. dopo il riavvio fare:
   sfdisk -d /dev/sda | sfdisk /dev/sdb per copiare le partizioni sul nuovo 
disco esattamente come sul vecchio
   grub-install /dev/sdb
   mdadm --manage /dev/md0 --add /dev/sdb1
   mdadm --manage /dev/md1 --add /dev/sdb2
   mdadm --manage /dev/md2 --add /dev/sdb3
 
   Oppure provare a fare: dd if=/BootSectorBackup.bin of=/dev/hdb bs=512 
count=1
 
   (446 grub, resto partition table)
 
Nel caso ci sia solo una partizione guasta fare prima:
 
mdadm --manage /dev/md0 --fail /dev/sdb3
mdadm --manage /dev/md1 --fail /dev/sdb2
mdadm --manage /dev/md2 --fail /dev/sdb3
mdadm --manage /dev/md0 --remove /dev/sdb3
mdadm --manage /dev/md1 --remove /dev/sdb2
mdadm --manage /dev/md2 --remove /dev/sdb3
 
Spero possa esserti utile.
 
 
Ciao,
  Void

 varie, etc., etc.).
 
Se ci si trova in una situazione simile, 9 volte su 10 la macchina è ferma, come nel mio caso ieri.
Chiedere su una ML potrebbe richiedere ore o giorni prima di avere una risposta, quasi sempre parziale.
 
E' chiaro che se la situazione lo dovesse permettere (tipo macchina non vitale che può stare ferma 2 giorni) sarebbe certamente la soluzione migliore.

 Spero possa esserti utile.
 
Non proprio, tolto il discorso dello switch, questa è la normale procedura che adotto io, (ma non spegno il server), avendo dischi hotplug.
 
Più che altro, nel 2016, credo sia più comodo e utile fare un raid su tutto il disco e non più mille-mila partizionamenti:
 
in pratica (pseudo comando):
$ mdadm --create /dev/md0 --level=1 /dev/sda /dev/sdb
 
e poi usare LVM sopra /dev/md0
 
In questo caso la sostituzione del disco si semplica, essendoci solo 1 volume.
 
Al limite, se si volesse fare i fighi, si può creare una partizione di root, metterla sotto raid in md0, creare una partizione secondaria grossa come tutto il disco e poi fare md1+LVM su tutto il resto. Giusto per evitare LVM sulla root, ma ormai tutte le distribuzioni hanno LVM in initrd.

 Se volessi cambiare l'intero disco /dev/sdb, devo rimappare a mano tutti i singoli volumi md ?
 
  In assenza di un file mdadm.conf si.
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.
 

   E lo sa perché si legge i metadati in /proc/mdstat
 
  Le *informazioni*, scusa.  I metadati sono scritti sui superblocchi
dei dischi/partizioni/container.


E con un mdadm.conf la ricostruzione si può automatizzare? 
Se si, come?

 Se si, come?
 
Che io sappia non si puo`.
 
Il motivo e` che, per design, "md" e "mdadm" cercano
di evitare "cose" automatiche il piu` possibile.
 
Se togli un disco, tipo /dev/sdb, con 3 partizioni e lo
cambi con un altro, non puoi fare "mdadm --add /dev/sdb"
 
Per prima cosa, "--add" vuole un RAID, cioe` /dev/mdX,
come primo parametro.
 
Secondo, come scritto sopra, non si fanno cose in modo
automatico, per decisione precisa.
 
Oppure ho capito male cosa vuoi fare.
 
Onestamente, non ho mai provato a mettere i /dev/sdX
in mdadm.conf, per il semplice motivo che i nomi non
sono costanti...
 
bye,
 
-- 
 
piergiorgio

 sono costanti...
 
Puoi usare il path fisico (quello non varia), non per forza sd[a-z].
$ ls -1 /dev/disk/by-path/*
/dev/disk/by-path/pci-0000:00:14.0-usb-0:12:1.0-scsi-0:0:0:0
/dev/disk/by-path/pci-0000:00:14.0-usb-0:12:1.0-scsi-0:0:0:1
/dev/disk/by-path/pci-0000:00:14.0-usb-0:12:1.0-scsi-0:0:0:2
/dev/disk/by-path/pci-0000:00:14.0-usb-0:12:1.0-scsi-0:0:0:3
 
Ma poi cosa succede se si spostano i dischi in altro server? mdadm si baserà solo sui propri metadati presenti sui singoli dischi, o cercherà comunque di accedervi tramite path ?
 
Nel senso: creo un raid sul server 1 con i dischi in 0:0:0:1 e 0:0:0:2.
Scoppia tutto, sposto i dischi su un altro server ma in 0:0:0:3 e 0:0:0:4.
Il raid riparte o fa casino, vedendosi path differenti ?

 che adotto io, (ma non spegno il server), avendo dischi hotplug.
 
Come dicevo nella scorsa mail si trattava di un PC casalingo usato come 
server, senza dischi hotplug.
 
 
Ciao,
  Void

 Ma, ripeto, probabilmente nel 2016 non ha più senso fare mille-mila volumi RAID mappati su singole partizioni. Volume unico md0 e passa la paura. Poi metto LVM sopra di lui. Così facendo non c'è più bisogno di mappare mille-mila partizioni a mille-mila volumi, se muore un disco, lo cambio con 1 singolo --remove ed un 1 singolo --add
 
C'è persino una FAQ di mdadm che suggerisce di fare un singolo volume RAID ed eventualmente partizionare/LVMmare quello.
 
A questo punto, sono per provare un bel RAID-1 a 3 dischi, il RAID-10 proprio non mi piace, sopratutto all'aumentare dei dischi.

 Il raid riparte o fa casino, vedendosi path differenti ?
 
Il driver "md" usa i metadati sul disco per
ri-assemblare il RAID.
 
Normalmente, "udev" inizia a trovare i dischi e,
se sono volumi "md", li assembla con "mdadm -I"
(e non con "mdadm -A").
Dove "-I" sta per "incremental".
 
Quindi, ignora completamente i nomi dei dischi,
proprio per evitare confusioni.
Ora, la "POLICY" di cui sopra sembra cambiare
questo comportamento, in maniera piu` mirata.
 
Devi provare...
 
bye,
 
-- 
 
piergiorgio

 Mai provato, neanche questo.
 
Quindi se io tolgo i dischi da un server e li metto su un altro, lui non fa il boot ?
 
Uhm, è esattamente ciò che voglio fare io ed uno dei motivi principali per il quale i nuovi server li farò tramite RAID software e non hardware.
 
In passato (molto passato, direi trapassato remoto, kernel 2.2/2.4 o cose simili) 
mi sembra di aver già fatto una operazione simile senza alcun problema.
Il filtro su host è stato introdotto di recente ?

 Il filtro su host è stato introdotto di recente ?
 
Relativamente di recente e serve ad evitare che un
componente RAID venga usato, per sbaglio, su di un
host diverso da quello nativo.
 
Ovviamente si puo` by-passare (credo, di solito e`
sempre possibile).
 
bye,
 
-- 
 
piergiorgio

 host diverso da quello nativo.
 
questo mi crea ancora più confusione in testa.
Ti faccio un esempio.
 
Server 1 con 8 slot per dischi.
  md0 in raid1 con disco0+disco1 per il sistema operativo
  md1 in raid6 con disco2+3+4+5+6+7
 
Server 2 con 8 slot per dischi.
  md0 in raid1 con disco0+disco1 per il sistema operativo
  md1 inesistente
 
Se sposto i dischi di md1 da server1 a server2 (visto che ci sono degli slot liberi), lui non lo avvia? I dischi in questione, è vero che sono stati attivati su un server differente, ma non fanno parte di alcun raid presente sul server2. Tecnicamente potrebbe attivarli senza indugi creando md1
 
Discorso diverso se su server2 fosse già presente un md1 con magari 3 dischi: disco2+3+4. Spostando i dischi restanti ed attivandoli, verrebbe fuori un casino. Questo è chiaro che non lo deve fare e fa bene a non farlo a causa dell'host differente.
 
Spero di essermi spiegato. sono 3 casistiche differenti:
- spostamento di TUTTI i dischi da un server all'altro, compreso il SO
- spostamento di TUTTI i dischi di un dato volume raid, su un server dove tale volume non esiste
- spostamento di PARTE dei dischi di un volume RAID su un server dove tale volume esiste già (ma che non ha niente a che vedere con quello di server1)

 - spostamento di PARTE dei dischi di un volume RAID su un server dove tale volume esiste già (ma che non ha niente a che vedere con quello di server1)
 
Fermo restando che non ho mai provato in prima
persona la situazione, il problema che "host"
tenta di evitare e` che si assembli un RAID dove
non si dovrebbe.
 
Se, per es., hai un RAID da qualche parte e sposti
questi dischi su di un altra macchina, rischi di
avere assemblato il RAID e magari montato (perche`
in fstab c'e` un riferimento al RAID e non UUID)
al posto di quello effettivo.
 
Cioe`, se, per es., fstab ha: /dev/md1 /home ...
ed il RAID "alieno" viene assmblato come md1 in
automatico, il sistema rischia di (tentare) di
montare quel volume in /home, quando non c'entra
niente (stesso discorso se il RAID ha LVM).
 
Quindi, per evitare questa (ed altre simili)
situazione il RAID viene (dovrebbe) essere
assemblato in *automatico* solo se corrisponde
all'host designato.
 
Ovviamente, se tu sai che non vi saranno problemi,
lo puoi far assemblare da mdadm.conf (credo).
 
Questo e` all'incirca la situazione, come scritto sopra,
non ho mai provato.
Forse si puo` fare un test con loop device.
Ovviamente, "host" si puo` cambiare durante la fase
di "assemblaggio" del RAID (o creazione).
 
bye,
 
-- 
 
piergiorgio

 remove+add per ciascun volume o c'è un comando che lo fa in automatico?
 
No, devi farlo per ogni partizione implicata nella creazioni di volumi raid.
A latere, stai attento, ho visto mdadm comportarsi in modo completamente
differente in base alla distribuzione che usi (ovvero, su Fedora/CentOS ha un
comportamento, su Debian un altro)
 
Enrico

 comportamento, su Debian un altro)
 
Vale a dire? comportamenti differenti su cosa ?

 Vale a dire? comportamenti differenti su cosa ?
 
Sgancio il disco, su Fedora/CentOS non è in grado di riattivare il RAID, anche
se in degraded mode (ha bisogno di un intervento manuale). Su Debian sì.
Sinceramente non ho mai capito il razionale di questo comportamento (non
sembrerebbe essere a causa della presenza/assenza di mdadm.conf), anche se
mi piacerebbe...
 
Enrico

 mi piacerebbe...
 
E` una configurazione, c'e` anche su Debian e
su Ubuntu. Dipende da come viene installato.
E si puo` cambiare in seguito.
 
bye,
 
-- 
 
piergiorgio

 su Ubuntu.
 
È una configurazione che non ho mai trovato, ma devo dire che non ho cercato
molto a fondo...
 
Enrico


Io ho dei sistemi Ubuntu che, distrattamente, sono
stati configurati in quel modo, cioe` se il RAID
non e` "integro", non partono...
 
Come cambiare la cosa, pero`, non saprei, e` da
tempo che non me ne occupo.
 
Forse c'e` qualcosa sulla cmdline del kernel, i
soliti parametri interpretati dagli script di
boot (e non dal kernel).
 
bye,
 
-- 
 
piergiorgio

 non e` "integro", non partono...
 
No, il default di Ubuntu è quello: se il RAID è rotto, la macchina non fa il
boot, o detta meglio la macchina non fa il boot automatico se il raid è in
modo degradato.
 
Ho sempre odiato ubuntu per questa scelta, specie la prima volta che l'ho
scoperto a 200Km dal server in questione... ;-(((
 
 
Avevo un solo server ubuntu, ed è stato spianato. Non ricordo dove fosse
l'impostazione, ma era facilmente modificabile. A saperla. ;)
 
-- 
  I politici dovrebbero leggere fantascienza,
  non western o storie di polizia. 		(Arthur C. Clarke)

 l'impostazione, ma era facilmente modificabile. A saperla. ;)
 
Mi meraviglia, pero`, che RHEL abbia lo stesso default.
 
bye,
 
-- 
 
piergiorgio

 modo degradato.
 
Debian come si comporta?

 molto a fondo...
 
Forse vi state riferendo a questo:
 
https://help.ubuntu.com/lts/serverguide/advanced-installation.html#raid-degraded
 
 
 
 

 Debian come si comporta?
 
L'array viene creato in stato DEGRADED ma comunque attivato
 
Enrico

 
https://help.ubuntu.com/lts/serverguide/advanced-installation.html#raid-degraded
 
 
Si, credo proprio di si.
 
-- 
  Il computer è come la morosa:
  meno ci mettono mano gli altri e meglio è! ;-)
							(Enrico)

 L'array viene creato in stato DEGRADED ma comunque attivato
 
AFAIK, non in tutte le versioni.
Qualche giorno fa (non trovo più il link) ho trovato un bug aperto che parla proprio di questa problematica con l'introduzione del montaggio dei volumi non più sequenziale ma non ricordo in che altro modo.
 
Scusate ma non ricordo altro.