raid

  • Keli loginiai RAID masyvai viename diske - bloga idėja

    Sistemos apkrovaSistemos apkrova - Sistemos apkrova
    Namų serverio konfigūracija keitėsi ne vieną kartą. Įprastini ų programinių servisų serveris buvo paverstas virtualiųjų mašinų serveriu, tuo pačiu pasitobulinant virtualizacijos žinias bei palaipiojant ant vienokių ar kitokių grėblių. Nuo to laiko praėjo daugiau, nei metų, o kompiuterijos srityje tai labai daug - ištisa amžinybė. Per šį laiką serveryje buvo pakeistos net kelios kartos diskinių kaupiklių, daugeliu atveju dėl kaupiklių gedimų. Taip kiekvieną kartą serverio talpykla po truputį augo, senuosius diskus po vieną pakeičiant naujais didesniais kaupikliais. Duomenis visuomet pavyko išsaugoti, nors kartą berods teko atkūrinėti pabirusią failų sistemą ir prisiminti, kad rezervines kopijas galima ne tik kurti, bet ir iš jų atsistatyti duomenis.

    Po paskutinės migracijos serveryje buvo likę 3 diskai, kuriuose buvo sukonfigūruoti 3 RAID5 masyvai. Jau tuomet žinojau, kad konfigūracija nėra optimali, bet sistema, kaip ir veikė. Tuo metu visi servisai jau buvo išmigruoti į Docker programinius konteinerius, o virtualios mašinos sustabdytos. Palyginus su virtualiomis mašinomis, Docker konteineriai veikė gerokai sparčiau. Taip yra dėl kelių priežasčių. Pirmiausia, konteinerio procesų virtualizavimui reikia mažiau išteklių, nes programinio konteinerio struktūra yra paprastesnė, nei viso kompiuterio virtualizavimas. Antra, Docker konteineriai tiesiog naudoja serverio failinę sistemą, todėl bendrai paėmus reikia mažiau disko I/O operacijų, kurios trunka labai ilgai (palyginus su CPU skaičiavimo operacijomis).

    Taigi laikas ėjo ir vėl ėmė niežėti nagus, nes prieš keletą metų ant technologijų bangos buvęs Docker buvo išstumtas ir dabar naudojamas tik, kaip konteinerių paleidimo technologija bei kūrimo įrankis. O konteinerių infrastruktūros valdymo srityje dabar yra vienvaldis lyderis - Kubernetes. Tuo pat metu pribrendo laikas dar vienai serverio modernizacijai bei Kuberntes klasterio sukūrimui. Tiesa, kol kas klasterio dydį apribotas vienu serveriu, tačiau tai netrukdo naudoti Kubernetes privalumais. Vienas pagrindinių privalumų yra serviso teikimo užtikrinimas, kurį su Docker Compose teko spręsti įvairių Shell scenarijų ir sistemos servisų kokteiliu. Bet apie tai kitą kartą. Vos tik įdiegus Kubernetes ir numigravus pirmuosius Docker Compose servisus į Kubernetes, paaiškėjo, kad serveris ėmė veikti vėžlio greičiu, o sistemos apkrovos lygis nuolat pakildavo virš 4-5.

  • Nepirkite WD Red NAS diskų NAS įrenginiams!

    WD Red EFAX 2TBWD Red EFAX 2TB - WD Red EFAX 2TB
    Nauji metai, nauji grėbliai. Skamba keistai, tačiau taip yra - dalis „WD Red“ diskų, kuriuos „Western Digital“ reklamuoja, kaip skirtus namų tinklo duomenų saugykloms (NAS) yra tam VISIŠKAI NETINKAMI. Jie yra iš principo nesuderinami su kai kuriomis failinėmis sistemomis ir/arba RAID masyvais. Diskai veiks, tačiau darbo sparta bus apgailėtina, kartais dešimtis kartų lėtesnė, nei kitų, atrodytų prastesnių charakteristikų diskų.

    Jei trumpai, tai EFAX modelio 2-6 TB talpos „WD Red“ diskuose naudojama SMR (Shingled Magnetic Recording) technologija yra iš principo nesuderinama su dideliu skaičiumi atsitiktinių rašymo operacijų, kurios turi papildyti takelį. O kaip tik taip ir nutinka RAID masyvuose ar kai kuriose failinėse sistemose, dažnai naudojamose NAS įrenginiuose. Taip yra todėl, kad SMR technologijoje duomenų takelis turi būti perrašomas visas, jei greta jo esantis takelis turi duomenų. Taip yra todėl, kad disko magnetiniai duomenų takeliai yra surašomi labai tankiai ir beveik persidengia. Pagal duomenų rašymo algoritmą šie diskai primena elekroninius „Flash“ diskus, kur taip pat rašoma į laisvas atmintinės ląsteles, o išnaudojus laisvus blokus, imama trinti seniau „ištrinta“ informacija ir formuojami naujos laisvos atminties ląstelės. Kodėl „Western Digial“ nusprendė naudoti potencialiai lėtesnę technologiją? Atsakymas paprastas: į diską galima surašyti daugiau informacijos ir diskinį kaupiklį pagaminti pigiau.

  • RAID1 vertimas į RAID5 beldžiant į medį ir galvojant, ką paaukoti hardware dievams

    Namų serveris pergyveno jau kelis atnaujinimus. Pernai seni WD Green diskai buvo pakeisti didesniais, o dar vėliau jie paraudonavo, keičiant 1.5 TB į 2 TB WD Red, kurie turėtų būti labiau pritaikyti NAS reikmėms. Tačiau migravimo į 2 TB diskus ilgam neužteko ir serveryje ėmė baigtis vieta - vien rezervinės kopijos užima per 800GB. Taigi vėl ėmiau sukti galvą, kur gauti daugiau vietos.

    Paprasčiausias būdas - pirkti dar didesnius diskus. Bet tai brangu ir RAID1 nėra labai efektyvus disko erdvės panaudojimas. Taigi nusprendžiau RAID1 veidrodį pakeisti į RAID5 masyvą, kuriame duomenų saugumas remiasi kontrolinių sumų skaičiavimu. Naudojant Linux MD diskų masyvus, tai padaryti teoriškai yra labai paprasta. Tiesiog reikia "užauginti" RAID1 į "sugriuvusį" RAID5 ir paskui pridėti trūkstamą RAID5 diską. Ir taip nupirkus vieną papildomą diską, 2 TB veidrodis turėtų tapti 4 GB talpos RAID5 masyvu.

    Ką gi, diskas buvo užsakytas prieš savaitę. Šiandien išjungiau serverį, įdėjau ir prijungiau diską ir įjungus kompiuterį niekas nesudegė. Pradžia nebloga. Tiesa, diena prieš tai visus svarbius duomenis iš serverio persikopijavau į 2 atskirus išorinius diskus. Taip dėl visa ko. :) Linux RAID dokumentacijoje masyvo migracija aprašyta labai glaustai:

    mdadm --grow /dev/md/mirror --level=5
    mdadm --grow /dev/md/mirror --add /dev/sdc1 --raid-devices=3
  • Veidrodinis diskų masyvas negarantuoja sistemos darbo

    Rūpintis savo duomenų saugumu reikia nuolat ir reikia tai daryti patiems. Atsarginės kopijos turi būti daromos nuolat ar bent jau kai pagalvoji, kad gal reikėtų jas padaryti. :) Tačiau pačios sistemos apsaugojimui nuo netikėto disko gedimo rekomenduojama daryti veidrodinį ar aukštesnio lygio RAID masyvą. Ir, kaip parodė praktika - pageidautina viename diske neturėti keleto masyvų.

    Bet, pasirodo yra niuansų, todėl turėdami RAID1 veidrodinį masyvą - dar negalite būti tikri, kad nusprogus vienam iš diskų, jūsų sistema liks veiksni. Jau nė nekalbant apie duomenų teisingumą. Todėl - rezervinės kopijos ir dar kartą rezervinės kopijos. Net ir sisteminiams diskams, kur saugoma sistema ir jos konfigūracija. Nes pačią sistemą įdiegti galima greitai, tačiau prie visų reikiamų programų diegimo ir konfigūravimo kartais galima praleisti ir ne vieną dieną. Blogiau, kai apie tokius niuansus išsiaiškini sugedus būtent rezervines kopijas saugančio serverio diskui. :)

    Taigi apie viską iš eilės.