Programiniai RAID masyvai „Linux“ sistemoje turi keletą privalumų prieš aparatinius sprendimus. Ypač, jei kalbama apie pigius aparatinius RAID valdiklius, kurie dažniausiai yra ne ką daugiau aparatiniai, nei „mdam“ sukurti masyvai. Vienas tokių privalumų - universalumas. Programinį RAID masyvą galima sukurti iš bet kokių diskų ir/arba jų skirsnių. Taip yra bent jau teorijoje. Deja!..
Yra toks anekdotinis posakis: „teoriškai arklys - praktiškai neatsikelia“. Ne kitaip ir su programiniu RAID - ne visi diskiniai kaupikliai dera tarpusavyje. Ir kas svarbiausia -- klaidos ir fiksuojamos, ir ignoruojamos, o to pasėkoje nuolat byra RAID masyvo duomenys! Būtent! RAID veidrodis lieka geras, o duomenys jame susigadina!
Šiek tiek priešistorės. Namų serverio pagrindinę plokštę užpuolė kondensatorių maras ir bent trys plokštės kondensatoriai pasipūtę „pareiškė“, kad ši plokštė daugiau neveiks. Jau iki pastebint „prasprogusius“ kondensatorius, plokštėje buvo sugedęs vienas iš keturių SATA kanalų. Taigi, neaišku dėl to ar ne, tačiau kartu su plokšte nusibaigė ir vienas 500 GB diskas, kuriame be įprastinių filmų ir muzikos buvo saugomos ir asmeninės fotografijos bei filmuota vaizdo medžiaga, nes serveris buvo naudojamas duomenims archyvuoti. Dalį duomenų iš 500 GB kaupiklio visgi pavyko išsaugoti anksčiau, nei galutinai suvyrėjo failų sistema ir visi jie sukeliavo į LVM tomą, sukurtą laikiniai prijungtame 500 GB „Seagate“ USB nešiojamajame kaupiklyje. Tačiau ateičiai buvo apsispręsta išspręsti duomenų praradimo problemą ir kurti veidrodinį RAID masyvą, nupirkus papildomą 1,5 TB diską.
Serveryje buvo likęs dar gyvas 1 TB diskas, kuris jau buvo sudalintas į keletą skirsnių, su duomenų ir virtualių mašinų LVM tomais. Naujasis 1,5 TB diskas buvo sudalintas taip, kad pirmasis terabaitas atkartotų 1 TB disko skirsnius, o likusi vieta paskirta dar vienam RAID masyvui.
vm-serv:~# fdisk -l /dev/sda
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000eb383
Device Boot Start End Blocks Id System
/dev/sda1 * 1 25 200781 fd Linux raid autodetect
/dev/sda2 26 3849 30716280 fd Linux raid autodetect
/dev/sda3 3850 121601 945842940 fd Linux raid autodetect
vm-serv:~# fdisk -l /dev/sdb
Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x6ed54abf
Device Boot Start End Blocks Id System
/dev/sdb1 1 25 200781 fd Linux raid autodetect
/dev/sdb2 26 3849 30716280 fd Linux raid autodetect
/dev/sdb3 3850 121601 945842940 fd Linux raid autodetect
/dev/sdb4 121602 182401 488376000 fd Linux raid autodetect
vm-serv:~#
Toliau buvo remiamasi šiuo puikiu LVM migracijos į RAID masyvą vadovu. Ir palaipsniui paprasti LVM tomai numigravo į /dev/mdx RAID veidrodžius. Numigravus virtualias mašinas liko svarbiausias LVM tomas su išsaugotomis vestuvių nuotraukomis ir kita medžiaga, kurios torentuose rasti tikrai nepavyks. Taigi visi šie duomenys buvo rūpestingai perkelti į /dev/md4 masyvą, sudarytą iš vieno /dev/sda4 skirsnio.
vm-serv:~# cat /proc/mdstat
Personalities : [raid1]
md3 : active raid1 sdb4[1]
488374840 blocks super 1.2 [2/1] [_U]
md2 : active raid1 sda3[2] sdb3[1]
945841780 blocks super 1.2 [2/2] [UU]
md1 : active raid1 sda2[2] sdb2[1]
30715184 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sda1[2] sdb1[1]
200769 blocks super 1.2 [2/2] [UU]
unused devices: <none>
vm-serv:~#
Kadangi sugedęs 500 GB diskas yra ilgam užstrigęs garantiniame aptarnavime, o /dev/md4 saugo svarbius duomenis, nusprendžiau nepalikti pusiau sudaužyto veidrodžio ir prie /dev/md4, nusprendžiau prijungti 500 GB USB kaupiklio /dev/sdc1 skirsnį. Greitis man svarbu nebuvo - svarbu, kad duomenys būtų dubliuoti ir sugedus vienam iš trijų serverio kaupiklių - neprarasčiau jokių duomenų. Pridėjus /dev/sdc1 skirsnį - prasidėjo ilgas RAID veidrodžio atkūrimas - duomenų kopijavimas iš /dev/sdb4 į /dev/sdc1.
Deja, tai buvo klaida. Nors „mdadm“ rodė, kad RAID veidrodis veikia be sutrikimų ir duomenys po pusės paros buvo sėkmingai sudubliuoti, tačiau po pusantros paros pastebėjau, kad virtualaus serverio tinklo paslaugos yra neprieinamos. Pabandęs pažiūrėti /home turinį su ls komanda, gavau tik sugriuvusių katalogų sąrašą ir I/O klaidų šūsnį ekrane. Sistemos veiklos ataskaitoje tuo tarpu puikavosi maždaug tokie pranešimai
Apr 7 22:00:05 files kernel: [ 165.501688] end_request: I/O error, dev vdb, sector 213277759
Apr 7 22:00:19 files kernel: [ 179.577452] end_request: I/O error, dev vdb, sector 212231231
Apr 7 22:00:19 files kernel: [ 179.578035] __ratelimit: 668 callbacks suppressed
Apr 7 22:00:19 files kernel: [ 179.578579] Buffer I/O error on device vdb1, logical block 26528896
Apr 7 22:00:19 files kernel: [ 179.579164] lost page write due to I/O error on vdb1
Apr 7 22:00:19 files kernel: [ 179.579704] Buffer I/O error on device vdb1, logical block 26528897
Apr 7 22:00:19 files kernel: [ 179.580504] lost page write due to I/O error on vdb1
Apr 7 22:00:19 files kernel: [ 179.581434] Buffer I/O error on device vdb1, logical block 26528902
Apr 7 22:00:19 files kernel: [ 179.581434] lost page write due to I/O error on vdb1
Apr 7 22:00:19 files kernel: [ 179.581434] Buffer I/O error on device vdb1, logical block 26528903
Apr 7 22:00:19 files kernel: [ 179.581434] lost page write due to I/O error on vdb1
Apr 7 22:00:19 files kernel: [ 179.581434] end_request: I/O error, dev vdb, sector 212231103
Apr 7 22:00:19 files kernel: [ 179.581434] end_request: I/O error, dev vdb, sector 212232239
Nieko gero... Tuo tarpu virtualios mašinos ataskaitoje puikavosi tokie kiek paslaptingi pranešimai, akivaizdžiai rodantys, jog kažkas negerai su svarbiausiu RAID veidrodžiu.
Apr 7 22:01:19 vm-serv kernel: [184687.776848] bio too big device md3 (248 > 240)
Apr 7 22:01:19 vm-serv kernel: [184687.776900] bio too big device md3 (248 > 240)
Apr 7 22:01:19 vm-serv kernel: [184687.776949] bio too big device md3 (248 > 240)
Apr 7 22:01:19 vm-serv kernel: [184687.776996] bio too big device md3 (248 > 240)
Apr 7 22:01:19 vm-serv kernel: [184687.777044] bio too big device md3 (248 > 240)
Apr 7 22:01:19 vm-serv kernel: [184687.777093] bio too big device md3 (248 > 240)
Apr 7 22:01:19 vm-serv kernel: [184687.777142] bio too big device md3 (248 > 240)
Kas keisčiausia - /proc/mdstat nerodė jokių RAID veikos sutrikimų. RAID veidrodžiai pasak „mdadm“ buvo visiškai sveiki ir md3 buvo nurodomas, kaip [UU]. Akivaizdu buvo, kad RAID byra, jei dar nesubyrėjo. Greita paieška „Google“ nenudžiugino - pasirodo, tai nuo 2009 metų žinoma klaida. Taip sakant - „it's not a bug, it's a feature“.
Klaidos esmė gana miglota, tačiau jei teisingai supratau I/O operacijos duomenų bloko dydis USB ir įprastiems SATA kaupikliams nėra vienodas. Ar tai RAID „mdadm“ tvarkyklė nesugeba išsiaiškinti sudėtinių veidrodžio komponentų įvesties/išvesties operacijų bloko dydžio, ar tai USB įrenginys pasigiria, jog moka daugiau, nei gali iš tiesų. Tačiau rezultatas toks, kad rašant duomenis į tokį RAID masyvą - dalis duomenų nubyra, nes praėję pro „mdadm“ sluoksnį ir išskaidyti į atskirus įrenginius, duomenys nėra pilnai surašomi į vieną iš kaupiklių.
Akivaizdaus sprendimo per keletą valandų rasti nepavyko. Net ir pašalinus /dev/sdc1 įrenginį iš masyvo, fizinis serveris skundėsi dėl neteisingų I/O operacijų. Tačiau po akimis užkliuvo vieno iš vartotojų pasiūlymas sukurti LVM tomo būklės atvaizdą („snapshot“). Jam tai padėjo išspręsti šią problemą. Apie atvaizdo sukūrimą galvojau ir pats -- tokiu būdu tikėjausi išsaugoti esamą duomenų būseną, jei netyčia fsck programa padarytų ką nors labai negero, betaisydama virtualaus serverio diską. Kol kas paaiškinimo nesugalvojau, tačiau lvcreate -s files-disk1-home -L 100G -n files-disk1-snap išsprendė problemas. Taigi, nors svarbiausias veidrodis kol kas yra suskaldytas, tačiau bent jau sudėliotas į vietas ir nesubyrėjęs.
Reikia tikėtis naujas 1,5 TB diskas nesuges anksčiau, nei iš garantinio aptarnavimo sugrįš 500 GB SATA kaupiklis, o nuotraukos ir vaizdo įrašai jau saugiai suarchyvuoti į svarbių duomenų archyvą sveikame veidrodyje.
Akivaizdu, kad programiniai RAID masyvai nėra tokie universalūs, kaip norėtųsi. Todėl patarimas ketinantiems apsaugoti savo duomenis veidrodiniais masyvais -- nemaišykite skirtingų tipų kaupiklių... Jei jau naudojate SATA diskus, tai masyvą kurkite tik iš SATA diskų, o ne papildykite juos USB kaupikliais ar SD atmintinėmis... Kaip sakoma - protingi žmonės mokinasi iš klaidų, o išmintingi iš svetimų klaidų. Būkite išmintingais... ;)