RAID 1 monitorozás - kérdések

Ubuntu Linux

A szerverünkön (ubuntu linux) tönkrement egy szoftveresenen RAID 1 be kötött merevlemez páros közül az egyik diszk, aminek adatvesztés lett az eredménye. Ezzel kapcsolatban szeretném kérdezni a hozzáértőket, hogy mitől fordulhat elő ilyen? Mitől állhat le a tükrözés?
További kérdésem, hogy miként kell helyesen raid 1 be kötött merevlemezeket monitorozni? Mi a biztos jele annak, hogy döglődik illetve véglegesen tönkremegy az egyik diszk?
Segítségeket előre is köszönöm.

( mr shadow v | 2012. 12. 12., sze – 22:10 )

hdsentinel :P van linuxra binárisa ingyen, amúgy, sync állapotáról /proc/mdstat -ban találsz infót
(rejtett subscribe)

--
"'The time has come,' the Walrus said"

( calamari | 2012. 12. 12., sze – 22:43 )

http://manpages.ubuntu.com/manpages/precise/man8/mdadm.8.html

http://manpages.ubuntu.com/manpages/precise/man5/mdadm.conf.5.html 


MAILADDR
The  mailaddr line gives an E-mail address that alerts should be
sent to when mdadm is running in --monitor mode (and  was  given
the  --scan option).  There should only be one MAILADDR line and
it should have only one address.

...

PROGRAM
The program line gives the name of a  program  to  be  run  when
mdadm --monitor detects potentially interesting events on any of
the arrays that it is monitoring.  This program  gets  run  with
two or three arguments, they being the Event, the md device, and
possibly the related component device.

There should only be one program line and it should be give only
one program.

Én ennél jobbat nem tudok.

♲♻♲

( uid_6201 v | 2012. 12. 12., sze – 22:50 )

mdadm --monitor --scan -m emailcímed

Egyébként pedig cat /proc/mdstat
Ha [UU] helyett [U_] vagy [_U] van, akkor kiesett az adott diszk.

Ennyire egyszerű a szoftver RAID monitorozás.

a checkarray daemon hetente egyszer lefutott:

/etc/cron.d# tail -1 /etc/cron.d/mdadm
57 0 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet

A /etc/mdadm/mdadm.conf -ba pedig meg volt adva a "MAILADDR e-mailcím" , de figyelmeztető emailek nem érkeztek. A mail logokban nyomát sem látom, hogy email ment volna.

Mit kellett volna még beállítani?

( gmatyi | 2012. 12. 12., sze – 23:34 )

köszi szépen a válaszokat.

most nézem a logokat, és ezt látom benne. Van e valakinek tippje, hogy ebből mire lehet következtetni? Én ebből azt mondanám, hogy az sdb rossz, de az sda vinyó adta meg magát.

read error corrected - itt mi történik valójában?

/var/log/messages

Nov 26 00:50:18 linux kernel: [8268752.658291] sd 1:0:0:0: [sdb] Unhandled sense code
Nov 26 00:50:18 linux kernel: [8268752.658293] sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Nov 26 00:50:18 linux kernel: [8268752.658296] sd 1:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
Nov 26 00:50:18 linux kernel: [8268752.658299] Descriptor sense data with sense descriptors (in hex):
Nov 26 00:50:18 linux kernel: [8268752.658301] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Nov 26 00:50:18 linux kernel: [8268752.658307] 64 12 76 b8
Nov 26 00:50:18 linux kernel: [8268752.658309] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
Nov 26 00:50:18 linux kernel: [8268752.658313] sd 1:0:0:0: [sdb] CDB: Read(10): 28 00 64 12 76 b8 00 00 08 00
Nov 26 00:50:18 linux kernel: [8268752.664514] ata2: EH complete
Nov 26 00:50:18 linux kernel: [8268752.684366] raid1:md1: read error corrected (8 sectors at 1673932472 on sdb3)

smartctl nem talált hibát az sdb-n.

root@linux:~# smartctl -l selftest /dev/sdb
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.14-live-ig2] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 103 -
# 2 Short offline Completed without error 00% 99 -

Az alábbi kérdéseim továbbra is nyitottak:

- a checkarray miért jelzett hibáat az sdb-re, ha a smartcheck szerint annak semmi baja?
- ha a logokban nyomát sem látom annak, hogy az sda-val probléma lenne, akkor miért á llítja a technikus, hogy arra a smartctl hibát adott?
- továbbra sem értem, hogy az sdb-n mitől sérült meg a fájlrendszer? Használható adat lényegében nem maradt rajta. (a logok szerencsére 90%-ban megmaradtak...)

( lajos22 | 2012. 12. 13., cs – 00:47 )

Nem kicsit gyanús, ha a RAID1 adatvesztést szenved 1 diszk kiesésekor. Nyilván megadta magát mind2. Ott dobnám el az agyam ha a mirror lecuppanna, mert elszáll belőle egy diszk..

--
openSUSE 12.2 x86_64

Én is ugyanezen problémázom, ezért próbálom teljes részletességében megérteni, hogy mi is történhetett, egyébként bérelt szerverről van szó. Néhány kérdésemre még várom a választ a szolgáltató technikus kollégáitól. Azt írták nekem, hogy az sdb nem hibás, de ezt most én is szívesen letesztelném.
Milyen tesztprogramot futtassak le, amelyik nem okoz semmilyen adatvesztést az sdb-n?

A RAID szinteket szerintem sem kellene összekeverni.

Hat en egy smartctl-lel ugranek neki, hogy az miket mond. Ha csunyakat, akkor be kell telefonalni, hogy letojod, hogy szerintuk mi van, itt es most csereljenek. Ha valami komoly gond van a diskkel, azt jo esellyel a SMART kihozza.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nálam a RAID1 eleve 3 diszkből áll. Természetesen van napi és heti mentés is. (és a mentésről is van legalább 1 mentés...) Aztán heti 1-2x végig zörgetek egy hdsentinelt, rálesek a mdadm --detail-re. Ennyiből már általában kiderül a problematika jellege, aztán ha valamivel gond van, akkor addig rugdosom a gépet, míg jó nem lesz... Őhm.. Vagyis kikapom a gépből lemezt, aztán rálesek jobban smart-ra, és eldöntöm, hogy megy-e vissza a gépbe, vagy szemét tárolásra lesz kijelölve.

--
openSUSE 12.2 x86_64

A napi és heti mentés a szerveren belül volt megoldva. RAID1 esetén ugyanis elég valószínűtlennek gondoltam ezt a scenariot, hogy mindkét vinyó egyszerre lesz kampec, úgy hogy zéró adat marad rajta. Ha a szolgáltató hibázik, akkor persze ez előfordulhat.
A mentéseket is mentegettük egy külső merevlemezre. Ezen sajnos megsemmisültek az adatok pár nappal a szerver összeomlást megelőzően.

tudsz jobbat?
mert némi ráfizetéssel kérhettünk volna a szolgáltatótól backup szolgáltatást, ami lényegében abból állt volna, hogy készül 1 db full backup, aztán 3 inkrementális, utána pedig egy megint egy full backup úgy hogy törlődik az előző full backup, hogy az előző ne foglalja a helyet... - mert szerintem az ilyen megoldás esetén a vinyó fogja tudni, hogy mikor kell tönkremennie.

Csak az a kérdés, hogy mennyi pénz van rá és/vagy mennyi kárt okoz egy-egy kiesés mint most. Egy egyterás külső WD 25-26k, egy évre elosztva kb. havi 2k, és elég sok dologra használható. Ettől van lejjebb is, meg feljebb is megoldás, csak pénz kérdése.

Én pl. a crashplanhoz mentek pár dolgot.

ennél csak jobbat tudok.

1. bérelsz egy vps-t és arra backupolsz
2. beállítasz egy backup szervert
3. akár otthon beállítasz egy backup szervert és arra backupolsz vpn-en keresztül
4. backupolsz a cloudba is
5...
végtelenek a lehetőségek.

ha a gépben megpukkan a táp, s megszalad a 220 a merevlemezekre akár, akkor mit érnél egy gépen belüli backuppal?
ha felnyomják a gépedet és kapsz egy dd-t a lemezeidre, mit érnél egy gépen belüli backuppal?
ha programhiba miatt történik valami, ami mondjuk törli a lemezeidet, mit érnél egy gépen belüli backuppal?
ha meghal a rendszered és nem tudsz bootolni, hogy visszaállj a backupból, mit érnél egy gépen belüli backuppal?
ha kigyullad a gép, mit érsnél egy gépen belüli backuppal?
ha ellopják a gépet, mit érnél egy gépen belüli backuppal?
stb. ?

milyen szolgáltatást futtatsz?

számtalan kockázatot fel lehetne sorolni, azonban nálunk egy mostanihoz hasonló kiesés még nem okoz jelentős kárt, hogy az 1.-4. -en megérje komolyabban gondolkodni. Különféle NAS-okat azonban már kedvező árakon lehet kapni, azonban még nem volt időm utánanézni, hogy melyik típust érdemes venni. vpn és raid1 legyen benne szerintem...

Nálam a mentés úgy néz ki, hogy a szerveren egy script minden nap lefut és az összes fontos cuccot a szerverről egy temp mappába gyűjti, majd dátumozza és végül csinál egy tar.gz-t belőle. Aztán azt másolja egy mappába ami nfs-en egy másik backup szeró RAID10-es tömbjére mutat (jelenleg azért nfs, mert még nem tudtam időt szakítani a iSCSI megtanulására.), azután másolja a cuccot egy másik mappába ami szintén nfs, de a saját kis home szerveremre mutat, ahonnan egy külső diszkre másolom a cuccot... hetente készítek backupot a backup szerverről is, ami szintén egy külső merevlemezre kerül.

Mikor még paranoidabb voltam, akkor általában 2 lemezre mentettem a cuccot.

a mentéseket pedig (jelenleg) 1 évre visszamenőleg bármikor előtudom szedni.

--
openSUSE 12.2 x86_64

Csak az adatokat. Az OS, programok, beállítások stb. ~10perc alatt visszadobható az imageből. Mikor egy új vasat állítok be, akkor telepítem rá az OS-t ahogy azt illik, beállítgatom stb, utána az egész diszket klónozom egy imagebe, és ha problem van, akkor az ahhoz a géphez készült image elő, lemezre fel, és kész is. A fontosabb szolgáltatásokhoz pedig minimum 2 gépet állítok be.

--
openSUSE 12.2 x86_64

( sirenter | 2012. 12. 13., cs – 09:28 )

"További kérdésem, hogy miként kell helyesen raid 1 be kötött merevlemezeket monitorozni?"

http://en.gentoo-wiki.com/wiki/RAID/Software
"Data Scrubbing

In short: Especially if you run a RAID5 array, trigger an active bad block check on a regular basis, or there is a high chance of hidden bad blocks making your RAID unusable during reconstruction.
Normally, RAID passively detects bad blocks. If a read error occurs, the data is reconstructed from the rest of the array, and the bad block is rewritten. If the block can not be rewritten, the defective disk is kicked out of the active array.
Once the defective drive is replaced, reconstruction will cause all blocks of the remaining drives to be read. If this process runs across a previously undetected bad block on the remaining drives, another drive will be marked as failed, making RAID5 unusable. The larger the disks, the higher the odds that passive bad block detection will be inadaquate. Therefore, with today's large disks it is important to actively perform data scrubbing on your array.
With a modern (>=2.6.16) kernel, this command will initiate a data consistency and bad block check, reading all blocks, checking them for consistency, and attempting to rewrite inconsistent blocks and bad blocks.

echo check >> /sys/block/mdX/md/sync_action"

Welcome Back, My Friends, to the FLAME That Never Ends...tisztelet a kivételnek

"Ezt nem ismertem"
fentieket olvasva más sem: nem vagyok debian guru, de a checkarray pontosan ezt csinálja

"Milyen idokozonkent illik eztet futtatni?"
hetenként szoktam; a full resync eléggé megnyúzza a diskeket, szerintem sem gyakrabban, sem ritkábban nem praktikus

más: az mdadm --monitor nem reagál rá, ezért a /proc/mdstat-ot emilben el szoktam küldeni magamnak

Welcome Back, My Friends, to the FLAME That Never Ends...tisztelet a kivételnek

( gmatyi | 2012. 12. 14., p – 14:34 )

Huh, úgy néz ki, hogy ezúttal ezt a raid 1 problémát szerencsésen megúsztuk. A szolgáltatónál visszatették a régi sda-t, amelyiken ott volt minden adatunk. (lementettük) A smartctl a régi sda-ra mindenféle hibákat mutat.

A kérdés továbbra is az, hogy miként fordulhat elő, hogy egy raid 1 egyik diszkje elkezd gyengélkedni, ami azt eredményezi, hogy a másik diszken (ami a smartctl szerint hibátlan) a fájlrendszer annyira károsodik, hogy lényegében minden adat elvész róla?

Már elég sok vinyó rámhalt RAID1-ben (legalább 5db az elmúlt 8-10 évben biztosan), de sosem volt adatvesztésem - szerencsére. Mondjuk rendes hardveres RAID kártyán volt mind. Bár rendes hardveres RAID-del is lehet probléma. Például nem tesztelt, nem RAID-be szánt típusú vinyót kidobál, stb...
RAID adatvesztést még mainframe rendszer (lásd MÁV Elvira), illetve enterprise-grade storage (lásd Pécsi Egyetem) is elszenvedhet, miközben nagyságrendekkel többet költöttek rá, mint te - vagy pláne amennyit én valaha is fogok.

Üdv:
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Én is arra gyanakszom, hogy a szolgáltató (akitől a szervert béreljük) bizonyos részletekben félretájékoztat minket, amikor megpróbáljuk felderíteni a lehetséges eseményeket. A smart adatokból kinyert "hány órát üzemelt az adott merevlemez" adatok alapján ugyanis nem lehetséges az a scenerio, amit a szolgáltató eddig a tudomásunkra hozott.

( zitev v | 2012. 12. 15., szo – 14:48 )

beraktam a memóba...

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség