Ko RAID odpove

Veliko zaposlenih, ki vsako jutro prihaja v službo, spije prvo zgodnjo kavico, poklepeta s sodelavci, pregleda novice na spletu, elektronsko pošto in se potem, če je pri volji, loti resnega dela, ne razmišlja o tem, kaj bi se z njihovimi delovnimi mesti zgodilo, če bi prišlo do usodne napake na računalniškem sistemu, ki bi pomenila, da podjetje izgubi vse ali vsaj večino ključnih podatkov za poslovanje in podporo poslovnim procesom.

Kot kažejo analize in nedvoumno tudi primeri iz prakse, večinoma takih primerov pomeni konec za podjetje in posledično tudi izgubo delovnih mest. Torej to področje je daleč od tega, da bi ga kdorkoli, pa naj gre še za tako majhno podjetje, jemal z levo roko in neresno. Se pa o tem, če do tega že pride, običajno ne govori in skrbno skrije.

Sam sodim med ljudi, ki ne samo da pred skokom v bazen preverijo, ali je v bazenu sploh voda in kolikšna je njena globina, ampak, če gre za prvi skok v bazen, poizkušam pregledati tudi video posnetke vzorčnih neuspelih skokov in analizirati, kaj je šlo v teh primerih narobe. Da še sam ne pridem v kategorijo neuspelih poizkusov.

V pomoč in morda razmislek, bom v tem prispevku opisal nekaj dejanskih primerov iz moje prakse, kjer je malo manjkalo, da ni prišlo do resne izgube podatkov, pa najsi bo to elektronska pošta zaposlenih ali ostali podatki in datoteke na mrežnih strežnikih.

Najprej pa nekaj tehničnega ozadja.

V strežnikih, ki so ponavadi v vsakem podjetju srce podatkovnega centra, je običajno najhujša možna okvara na diskih. V osebnih računalnikih imamo ponavadi vgrajen en sam disk, in če se ta pokvari, so podatki izgubljeni in gremo v trgovino po novega ter preklinjamo izgubljene fotografije in podobno. V strežnikih pa se že dolgo časa uporabljajo tako imenovana RAID diskovna polja, kjer  se prek ustreznega krmilnika poveže skupaj več diskov tako, da je taka konfiguracija sposobna preživeti okvaro enega diska brez da bi strežnik to kakorkoli občutil in delo poteka lahko nemoteno naprej. Filozofija pa temelji na statistični verjetnosti, da je hkratna okvara v istem trenutku  večih diskov skoraj neverjetna.

Pred leti, ko so bili diski še manjših kapacitet, je bil popularen tako imenovan RAID5, sistem treh ali večih diskov, kjer je bil en disk redundanten in je krmilnik s pomočjo matematičnih funkcij podatke po diskih razporedil tako, da tudi če se eden disk pokvari, se da iz ostalih še vedno nemoteno dobiti vse podatke. V primeru okvare diska se je preprosto strežnik ustavilo, zamenjalo okvarjen disk in naredilo t.i. rebuild, obnovo podatkov zopet na vse diske v polju. Kasneje se je pojavila tudi možnost, da si imel en disk v strežniku na rezervi že priklopljen, ter je sistem sam brez zaustavljanja znal obnoviti diskovno polje v primer okvare.

Danes so diski postali bistveno večji in se uporablja sedaj večinoma samo še RAID1, ki pomeni dva ali več (parno število) diskov v “mirrorju” (zrcaljenje – vsak zapis gre na dva diska) ali pa RAID10, ki pomeni zrcaljenje in “striping”, ki pripomore predvsem k performansam (hitrejši dostop in pisanje).

Sedaj pa primeri, kjer se je v praksi pokazalo, da še tako dobra teorija ne pomaga, če odpove v praksi.

PRIMER št. 1

Moja prva služba, sam nastopam v funkciji pripravnika in v bistvu samo opazovalca. Datotečni strežnik ima 3 diske v RAID5. Informatik naroči servis, da pride posesati prah v strežniku. Strežnik ugasnejo, odprejo, prah posesajo, a strežnik se ne zažene več. Kljub RAID diskovnem polju je prišlo do nepopravljive okvare med posegom.

Poizkusijo obnove podatkov iz tračne (DAT) enote ne uspe, pa kljub temu da obstaja več trakov, na katere se je delala varnostna kopija. Očitno ni nihče preverjal, ali se kopije izvajajo pravilno in ali se da iz njih sestaviti strežnik nazaj in obnoviti podatke. Ker so podatki pomembni in je bilo na strežniku praktično nekajletno delo cele ekipe ljudi, informatik vzame diske in odide v Nemčijo v neko firmo, ki se ukvarja z reševanjem podatkov. Kako drag je bil poseg in koliko podatkov so strokovnjaki podjetja uspelo obnoviti, mi ni uspelo izvedeti.

PRIMER št. 2

V tem primeru nastopam kot koordinator (v bistvu pa deklica za vse), na nek način sem seveda kot edini informatik odgovoren za delovanje informacijskega sistema.

Strežnik za elektronsko pošto in upravljanje z dokumenti, na katerem je prek 100 poštnih predalov plus cela vrsta ostalih kritičnih aplikacij, ima v RAID5 polju 3 diske. Zunanje podjetje, ki je konfiguriralo diskovno polje in namestilo programsko opremo, je pozabilo vklopiti zvočni alarm ob odpovedi diska. Sam pa žal ob prevzemu na to nisem bil pozoren. Ker gre za cenejšo izvedbo strežnika (entry level), ta tudi nima na sprednji strani nikakršnega vizualnega opozorila, kaj se dogaja z diski.

Strežnik (proizvajalca ne bom navedel, ker se to lahko zgodi kateremu koli in ne bi bilo pravično, če bi omenjal firmo) ima žal hudo serijsko napako. Najprej se pokvari prvi disk. Strežnik sicer deluje naprej brez problema, a nihče ne ve, da je prišlo že do okvare enega diska. Čez nekaj dni, morda teden ali dva, Windows 2000 konča v znani zaslon smrti –  “blue screen”. Odletel je še drugi disk od treh, podatki pa nepopravljivo uničeni! Od vsega je ostala samo varnostna kopija na traku DLT, kamor se je vsak večer shranjevala celotna vsebina strežnika. Dva diska sta bila potem zamenjala, obnova iz traku je bila izvedena brez problemov in izguba podatkov je bila samo nekaj ur, od zadnje varnostne kopije, do okvare naslednjega dne.

Brez varnostne kopije…he, he – shit happens, greš pač novim izzivom naproti (čez kak teden začneš delati drugje – informatiki so kar iskan kader), ostali se pa znajdite kakor veste in znate… (čez kakšen mesec je šel tudi tretji disk, tako da v roku dveh mesecev so crknili vsi trije diski, kot rečeno zaradi serijske napake).

PRIMER št. 3

Zopet strežnik, sicer drugega priznanega proizvajalca. Serviser pride zjutraj dograditi RAM, strežnik ugasne in ponovno zažene. Zgodi se pa … nič. RAID krmilnik javlja neko napako. V meniju ob zagonu računalnika sicer piše, da so vsi diski OK. Serviser oceni, da je šel RAID krmilnik in naroči novega. Ko po enem dnevu prispe, zažene računalnik, a ta zopet pade takoj v “blue screen” of death. Jaz potem vzamem namestitveni CD, kjer je tudi neko orodje napisano v javi za pregled diskovnega polja in to orodje šele pokaže, da se je dejansko pokvaril disk, RAID krmilnik pa žal okvare ni pravilno prepoznal in namesto da bi pokvarjen disk dal offline, je pokvaril celotno diskovno polje. Vsi podatki spet uničeni, ostal je samo trak in nič drugega. Tudi v tem primeru je bil zadnja varnostna kopija prejšnjega dne narejena pravilno in obnova podatkov gre brez problema. Zaradi spleta nesrečnih okoliščin pa je trajal izpad sistema resda nesprejemljivo dolgo.

Zato povsod tam, kjer gre za važne podatke… BACKUP!

Naj vsa prepričujejo še tako v zanesljivost strežnikov, žal, ko bo šlo kaj hudo narobe, bo potrebno vzeti trak z varnostno kopijo. In ni dovolj, da se varnostne kopije skrbno delajo vsak dan, potrebno je tudi redno preverjati zapise v dnevnikih programa za arhiviranje in občasno narediti testno obnovo parih podatkov, da se prepričamo, ali zadeva dejansko deluje. Potrebno pa je imeti razdelano strategijo, ali še bolje zapisano proceduro, kako se bo sistem obnovil iz traku v primeru resne okvare.

Dobri sistemci pa morajo razmišljati tudi o tem, da stavba, v katerem so strežniki in trezor z trakovi zgori, jo zalije voda, poruši potres ali nenazadnje, se vanjo zaleti ugrabljen Boeing 747 z teroristi na krovu. V takih primerih gredo ponavadi k vragu tudi arhivske kopije na trakovih in tudi za ta primer je potrebno imeti scenarij.

Cenena možnost je, da se kopije traku prenašajo redno na neko dislocirano, razumno oddaljeno mesto, kjer se lahko shranjujejo pod enakimi varnostnimi pogoji, kot na matični lokaciji.

Večja podjetja, kjer denar za informacijske sisteme ni vprašljiv, se lahko odločajo tudi za to, da uporabijo diskovna polja SAN (storage area network), ki se prek optičnih kablov povežejo na strežnike. V takih primerih je lahko diskovno polje kilometre stran od strežnikov, oziroma se zadeva konfigurira tako, da je eno diskovno polje na matični lokaciji, drugo, na katero se vsi podatki zapisujejo paralelno, pa na drugi lokaciji.

Tako sem bral v primeru napada na WTC, da je imelo na tak način konfiguriran sistem neko finančno podjetje, s sedežem v enem izmed dvojčkov. Ko je letalo porušilo dvojčka, je celoten informacijski sistem (strežniki in diskovno polje) praktično v realnem času preklopil na lokacijo na obrobju New Yorka in deloval naprej, kot da se ni zgodilo nič.

V primeru človeških življenj zaposlenih delavcev taki mehanizmi žal še ne delujejo. Vsak dober kapitalist ali tajkun pa ve, da se da nove človeke (ljudi) hitro najti na trgu delovne sile.

Samo da ne crknejo serverji.

Oglej si tudi:
– RAID Tutorial via AC&NC

Advertisements

Značke: ,

4 komentarji to “Ko RAID odpove”

  1. Emtec Says:

    Kako priročno, ravno danes zjutraj me je še pred zasluženo kavico predramil piskajoči zvok iz server rooma, in glej ga zlomka.
    Raid kontroler je šel po gobe, hvala bogu za trak in za to da je bil strežnik testni…

  2. rockstar1707 Says:

    Dober zapis. Sploh za nas, ki smo precej samouki glede takihle računalniških pogruntavščin.

  3. Lampret Says:

    Odlično napisano. =) Uporabljaš mogoče tudi kakšen sistem za repliciranje strežnika in samodejen preklop na sekundarca ob izpadu glavnega strežnika?

  4. dronyx Says:

    @Lampret: Kakšnih večjih osebnih izkušenj z “repliciranjem strežnikov” nimam, sem pa opazil, da so danes za zagotavljanje visoke razpoložljivosti zelo popularne rešitve, ki temeljijo na virtualizaciji (VMware), kjer se da pokvarjen strežnik enostavno zagnati drugje oziroma premakniti v realnem času, brez da bi to uporabniki opazili (recimo VMotion).

    Je pa to potem povsem drug cenovni rang (podobno velja za klasične gruče), ker da to deluje, potrebuješ drug nivo vzdrževanja, ki pa seveda stane. Zato je tu vedno tehtanje med tem, ali si to lahko privoščiš in ali to zares potrebuješ.

Oddajte komentar

Fill in your details below or click an icon to log in:

WordPress.com Logo

Komentirate prijavljeni s svojim WordPress.com računom. Odjava / Spremeni )

Twitter picture

Komentirate prijavljeni s svojim Twitter računom. Odjava / Spremeni )

Facebook photo

Komentirate prijavljeni s svojim Facebook računom. Odjava / Spremeni )

Google+ photo

Komentirate prijavljeni s svojim Google+ računom. Odjava / Spremeni )

Connecting to %s


%d bloggers like this: