Disk (storage) kieses tulelese, megfelelo kezelese

Linux-haladó

Sziasztok!

Tortent az egyik IBM blade rendszerrel a hetvegen, hogy kb 5-6 percre eltunt alola a storage (egyelore meg nyomozzak wtf, de mindket controller egyszerre mult ki). A lenyeg, hogy ezt a blade-n (vmware 6.0) futo linuxok mind ugy eltek meg, mintha lehuztam volna a rendszerdisket, aztan par perc mulva visszadugtam volna.
Disztro (salak,debian,ubuntu kulonbozo verziok) es kernel fuggvenyeben a legkulonbozo errorokat irta dmsegbe (az sda write timeouttol a kulonbozo filerendszer crashekig bezarolag). Volt par aminel read-only lett a rendszerdisk, de nem mindegyikben. Reboot utan soknal manualis fsck is kellett, sok hibaval, volt ahol a mysql is megborult.
Ha jol sejtem, az okozta a fo problemat, hogy 5-6 percig nem tudtak irni a diskre, ezt ugyan dmesgbe logoltak de nem zavartattak magukat nagyon, es amikor visszajott a disk, akkor szepen folytattak az irast, de a kieso idoben irando adatokat mar nem irtak ki ujra. Emiatt a journalingba lyukak lettek, az sql-be hianyzo rekordok amire viszont voltak kesobb hivatkozasok stb.

Ami vicc hogy ugyanezen a vason az osszes win 2008/12 siman kibirta, csak a logban latszik hogy volt disk hiba, de egy sem allt meg, egyiken se tortent adatserules.

Mar tulvagyunk a krizisen, de mivel semmi elojele nem volt, es latszolag tenni se nagyon tudunk ellene (lehet soha tobbet nem lesz ilyen, de lehet hogy egy huzosabb munkanap elofordul megint), jo lenne valahogy felkesziteni a linuxokat erre, hogy lehetoleg kevesebb fs/sql corruptionnal eljek tul a dolgot.

Kerdes, hogy talalkozott-e mas is ilyesmivel, vagy van-e otlet arra, hogy a linuxot hibaturobbe tegyuk, hogy disk kieses eseten ne csesszen szet mindent miutan visszajott. Igen tudom hogy a linux nagyon nem birja a hardver hibakat, de valamit hatha megis lehetne tenni. Nekem is vannak otleteim (pl script ami figyeli a dmesget es ha ilyesmit lat akkor hard poweroffolja, vagy esetleg suspendeli a vm-et, de ez eleg drasztikus)

A'rpi

  • 1519 megtekintés

( asm v | 2018. 03. 06., k – 21:40 )

Szerintem valasszuk kulon a bare-metalt a virtualizalt kornyezettol.
Bare-metal esetben a kernel a SCSI hibakodoknak megfeleloen tud vmit cselekedni, pl. ujraprobalkozni nehanyszor, read-only-va valtani a filerendszert, stb.
Virtualizalt kornyezetben (legalabbis ESXivel) maskepp zajlodnak le az esemenyek. Nekem az a tapasztalom, hogy datastore elvesztese eseten (all path down) a VM megall es a hypervisor probalkozik az irassal. A guest OS mar feltehetoen masfajta hibat erzekel (timeout). Mindenesetre vSphere kornyezetben konfiguralhato, hogy mikent videlkedjen datastore vesztes eseten.

Egyebkent arrol van info, hogy a storage controller(ek) szabalyosan indult(ak)-e ujra? Siman lehet hogy ugy crashelt(ek), hogy a write cache torlodott kiiras nelkul. Tehat nem feltetlen a guest OS a hibas...

"Due to the nature of an APD situation, there is no clean way to recover.

The APD situation needs to be resolved at the storage array/fabric layer to restore connectivity to the host.
All affected ESXi hosts may require a reboot to remove any residual references to the affected devices that are in an APD state."

:(

( bognarattila | 2018. 03. 06., k – 22:06 )

Nem pont ilyen okból, de találkoztam már hasonlóval, bár adatvesztés és hasonló mizéria nem volt. A jelenség vegyes tud lenni: teljes fagyástól a hálózati működésig több minden is előfordult (azaz például ssh-val be lehetett lépni).
Windows-ok esetén szintén változó a tapasztalat: teljes halál is előfordult, de olyan is, hogy végül futott tovább. Minden esetben történt újraindítás, biztos ami biztos alapon.

Ami segíthet: I/O timeout növelése. Linux alatt ez tipikusan automatikusan megtörténik (/lib/udev/rules.d/60-open-vm-tools.rules), elvileg Windows alatt is (VMware Tools által). Alapból 3 percre nő.

Csatlakozom ahhoz a feltételezéshez, miszerint az adatvesztésnek lehet köze ahhoz, hogy a tároló nem tudott kiírni valamit annak ellenére, hogy visszaigazolta az írást (cache vesztés). Ez ellen viszont nem sok minden segít (legfeljebb az írási gyorsítótár kihagyása, de ennek hátránya nyilván teljesítmény oldalon jelenik meg).

Ez milyen tároló? Ha lesz diagnózis a probléma okáról, érdekelne.

( egeresz | 2018. 03. 06., k – 22:35 )

Sajnálatosan a linux nem igazán hangolható, hogy mennyi legyen a block device elvesztése esetén a timeout, és mit csináljon akkor. Valami okból a linux kernelfejlesztők úgy gondolják, hogy ennek a block device területén lenne a helye (és pl. az iSCSI initiátorban ez elégge konfigurálható is). Sok blockdevice, mind máshogy kezeli -- nem jó ez. Szerintem a filesystem layerben lenne helye egy timeoutnak, de legfeljebb az nfs tud ilyet.

Az a tapasztalat, hogy 30sec alatti megakadást a linux jól visel, 30 sec körülit talán, 30 sec felettinél elesik, vagy jobb, ha elesik.
A windows nagyobb arányban éli túl, azonban nem konzekvens a viselkedése.

Ettől független az adatvesztés kérdésköre.
Adat nem veszhetne. Ehhez biztosít szolgáltatásokat a linuxban a driver, filesystem, és esetleg a adatbáziskelező. Más kérdés, hogy ezeket az adatbiztonsági szolgáltatásokat használja-e a rendszergazda vagy a programozó. Az LVM nem barrier-proof, a MD device (sw raid) nem barrier-proof, egy filesystemet is lehet úgy mountolni, hogy ne legyen barrier-proof (de legalább gyors legyen) és az adatbázisszervereket is lehet "batch" üzemmódban használni, vagy journal nélkül. Úgy gyorsabbak, de crash esetén adatvesztés lehet/lesz.

A ESX6 elég jól bírja, nem ott szokott adatvesztés lenni.

Ha a storage két kontrollere egyszerre halt meg, akkor ott szoftveres bug lesz. Az veszthet adatot. (a storage-ben két kontroller hardver van, nem valószínű, hogy egyszerre pusztul meg, de csak egyetlen firmwre (két példányban futva) az tud egyszerre hibázni.)

A "sok disztro sokféleképpen vesztett adatot" jelenség valószínűtlenné teszi, hogy a linuxok voltak félrekonfigolva mind, és valószínűbbé, hogy a storage szoftveres crash dobta el az adatot.

----

itt jut eszembe egy nagyszerű és gyors LSI storage (FAStT, DS4xxx, Engenio, most netapp E) ahol is volt egy FC limit (DS4700 = maximálisan 2048 párhuzamos scsi művelet) az ezen felül érkezett IO műveleteket a gép hibajelzés nélkül eldobta... (a doksiban volt rá workaround, csak el kellett olvasni, és be kellett tartani)

( arpi_esp v | 2018. 03. 07., sze – 11:16 )

ubi+ext4 halala:
[17419684.153451] Write(10): 2a 00 00 49 af 30 00 00 08 00
[17419684.153455] end_request: I/O error, dev sda, sector 4828976
[17419684.154074] EXT4-fs warning (device sda1): ext4_end_bio:317: I/O error -5 writing to inode 923773 (offset 0 size 0 starting block 603623)
[17419684.154077] Buffer I/O error on device sda1, logical block 603366
[17419684.154692] sd 2:0:0:0: timing out command, waited 180s
[17419684.155310] sd 2:0:0:0: [sda]
[17419684.155312] Result: hostbyte=DID_OK driverbyte=DRIVER_OK
[17419799.180840] EXT4-fs error (device sda1): ext4_journal_check_start:56: Detected aborted journal

eleg vicces azert, hogy az i/o error az csak warning ext4-nel :)
ezek altalaba nem lettek readonlyk, de ha megis akkor is reboot utan fsck (ami altalaban tobb oldalnyi hibat irt) es mysql repair vagy backupbol restore kellett :(
pedig az ubi 16-okon volt vmware tools is.

salak14+reiserfs:
[3428024.024902] REISERFS error (device sda1): zam-7001 reiserfs_find_entry: io error
[3428024.024995] REISERFS (device sda1): Remounting filesystem read-only
[3428024.424413] sd 2:0:0:0: timing out command, waited 180s
[3428024.424420] sd 2:0:0:0: [sda] Unhandled error code
[3428024.424422] sd 2:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x00
[3428024.424425] sd 2:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 01 b4 6c d0 00 00 10 00
[3428024.424430] end_request: I/O error, dev sda, sector 28601552
ez mind RO lett es sima reboot utan mukodott minden.

fstab ubi16-on:
UUID=69543db2-0ff3-48e7-8a37-82841e6471a3 / ext4 errors=remount-ro 0 1

ubi 14-en is, pedig ez a gep nagyon csunyan megdoglott (nagyon sok fs hiba, sql hibak):
UUID=03ec207c-2ddb-484d-afd9-39b89241c818 / ext4 errors=remount-ro 0 1

debian 7.1, ez is meghalt, fsck kellett addig nem is bootolt be:
UUID=9377580c-db63-4b2c-a074-269e624e9d28 / ext4 errors=remount-ro 0 1

Működött a VMware Tools általi beállítás: "timing out command, waited 180s"

Warning: szemlélet kérdése, hogy mit tekintünk hibának. Például ha azt tekinti hibának, ha szerkezet sérül, akkor egy meghiúsult módosítás nem feltétlenül az.

A hibát valószínűleg az okozta, hogy a 180s előtti időben keletkezett adatok kimentek a tárolónak, visszaigazolás megérkezett, de a lemezre nem jutottak ki. A tároló újraindulását követően pedig nem az az állapot volt a lemezeken, amiről visszaigazolást kapott a Linux. De a Linux ezzel nyilván csak akkor szembesült, amikor újraindult a tároló indulását követően. Az, hogy problémás az indulás vagy sem valószínűleg attól függ, hogy pontosan mely adatok hiányoznak, a naplózásból helyre tudta-e rakni vagy sem.

a slackwaren biztosan nem volt vmwtools, es ott is 180s irt :) de lehet a kernelben van erre valami hogy ha erzekeli a vm kornyezetet akkor erre all be?

visszaigazolas az irasrol szerintem nem jott, mert akkor nem irta volna a timeoutot se, hanem azt hinne minden rendbe ment. tehat azt erzekelte hogy a disk eltunt, de ennek ellenere futott tovabb...

Egy (nem bugos) naplózó fájlrendszer legalapvetőbb tulajdonsága, hogy bármelyik pillanatban kirántod alóla a diszket/áramot, túl fogja élni (és akkor is, ha a diszk nem sorban írta ki az épp pufferben levő adatokat, ehhez kell barrier támogatás az FS/RAID/LVM/stb driverben).

Az már jó kérdés, hogy mi van akkor, ha a diszk visszajön. A sikertelenül írt blokkokat hagyja a francba, és újra elkezd írni új blokkokat, mintha mi se történt volna? Az az adatvesztés receptje, és elég súlyos lenne, ha ez történne. De ehhez a fájlrendszer és diszk driverek elég mély ismerete kellene. Gondolom amúgy, hogy ennek elkerülésére szolgál az errors=remount-ro.

Úgyhogy szerintem is a storage hazudik.

> A sikertelenül írt blokkokat hagyja a francba, és újra elkezd írni új blokkokat, mintha mi se történt volna?

szerintem az ext4-nel pont ez tortent. a reiserfs-ekkel nem volt problema, de az az elso errornal atment readonlyba es ugy is maradt. az ext4 meg csak warningolgatott es kinlodott tovabb az errors=remount-ro ellenere is.

Lehet, hogy már alap a 180s (/sys/block/sda/device/timeout), esetleg VMware Tools nélkül is beállítja az udev virtuális lemez esetén.

Ami történhetett:
t0: írás kimegy, tároló visszaigazol (adat cache-ben)
t1: cache kiírása lemezre
t2: írás kimegy, tároló visszaigazol (adat cache-ben)
t3: tároló elhasal
t4 (tx = 0s): írás indítása, de nem megy, vár
t5 (tx = 0s + delta): írás indítása, de nem megy, vár
... (180s)
t20 (tx = 180s): timeout

A t2 időben kiírt adat veszhetett el: tároló átvette annak rendje és módja szerint, de valami hiba miatt már nem volt módja kiírni a cache-ből, mert t3-kor mindkét vezérlő megállt. A t4-től kezdeményezett sikertelen írások üzenetei jelentek meg (gondolom a konzolon).
Nem ismerem a naplózó fájlrendszer részleteit, de gondolom ott is előfordulhat, hogy inkonzisztencia lép fel hardver probléma esetén (t3-kori tároló halál annak minősül, mert nem az történt, amit az alrendszer visszajelzett).

igen elkepzelheto, sot valoszinu hogy mar ott is tortent adatvesztes amikor a storage leszakadt (valoszinusitjuk hogy crashelt a 2 controller, mert semmi riasztas nem jott rola csak rebootoltak - de az valoban jo kerdes, hogy miert egyszerre?)

azt nem tudom, hogy a vmware cacheli-e a diskeket vagy azonnal tovabbpasszol mindent ami jon a vm-ektol a storagenek? ha cachel, akkor ilyen esetben azokkal mi lesz, a disk visszaterese utan kiirja-e vagy az is eldobalja mint a linux tette? (vegulis a vmware host is egy linux)

A'rpi

esxi biztosan nem cache-el, azonnal továbbadja az adatokat a tároló felé. (útközben vannak queue-k, de amíg az adat várakozik a kiírásara, addig az esxi nem küld vissza nyugtát)

(van lehetőség flash read cache-re például, de az más történet és csak olvasás, mint ahogyan a nevéből is kitűnik)

( freeoli v | 2018. 03. 07., sze – 20:17 )

Engem érdekelne a tároló típusa és bekötése is a többi mellett is.

A blade center én lévő sas/fc switch is érdekes lehet de az nem okoz ilyet.

Az ilyen LSI/Avago tárolóknál is minden lun egy vezérlőn lóg egy időben de a cache elvileg a kettő közt tükrözte van. Ezt írtad, hogy ez nem igazán ment, mert egy controllert reboot még előfordulhat, csak nem kettő.

Faek egyszerűek de beton stabilak. A Dell MD sorozattal van nagyon sok kapcsolatom de az ugyanez. Ott a firmware changelog tele van ilyen fixel. Controller reboot, ezért vagy azért. Sosem tapasztaltam de én frissen tartom mindet. Nem tudom, hogy a DS changelog publikus e de az MD szerintem ugyanaz így a changelog is.

https://www.dell.com/support/home/us/en/04/Drivers/DriversDetails?drive…