Rezervimi nuk është një nga teknologjitë e modës për të cilat brohorasin nga çdo hekur. Thjesht duhet të jetë në ndonjë kompani serioze, kjo është e gjitha. Ne bëjmë kopje rezervë të disa mijëra serverëve në bankën tonë - kjo është një punë komplekse, interesante, disa nga hollësitë e së cilës, si dhe keqkuptimet tipike rreth kopjeve rezervë, thjesht duan të tregohen.
Unë kam punuar në këtë temë për gati 20 vjet, nga të cilat 2 vitet e fundit kanë qenë në Promsvyazbank. Në fillim të praktikës, bëra kopje rezervë pothuajse manualisht, me skriptet që thjesht kopjonin skedarët. Pastaj u shfaqën mjete të përshtatshme në Windows: mjeti Robocopy për përgatitjen e skedarëve dhe NT Backup për kopjim. Dhe vetëm atëherë erdhi koha për softuer të specializuar, kryesisht Veritas Backup Exec, i cili tani quhet Symantec Backup Exec. Kështu që unë jam njohur me kopjet rezervë për një kohë të gjatë.
Me fjalĂ« tĂ« thjeshta, kopja rezervĂ« Ă«shtĂ« ruajtja e njĂ« kopjeje tĂ« tĂ« dhĂ«nave (makina virtuale, aplikacionet, bazat e tĂ« dhĂ«nave dhe skedarĂ«t) ruhen rregullisht, pĂ«r çdo rast. Ădo dĂ«shtim zakonisht manifestohet si njĂ« dĂ«shtim hardueri ose logjik dhe rezulton nĂ« humbje tĂ« tĂ« dhĂ«nave. QĂ«llimi i njĂ« sistemi rezervimi Ă«shtĂ« tĂ« zbusĂ« dĂ«min e shkaktuar nga humbja e tĂ« dhĂ«nave. NjĂ« dĂ«shtim hardueri Ă«shtĂ«, pĂ«r shembull, dĂ«shtimi i serverit ose i magazinimit ku ruhet baza e tĂ« dhĂ«nave. NjĂ« dĂ«shtim logjik Ă«shtĂ« humbja ose modifikimi i disa tĂ« dhĂ«nave, duke pĂ«rfshirĂ« edhe pĂ«r shkak tĂ« gabimit njerĂ«zor: fshirja aksidentale e njĂ« tabele ose skedari ose ekzekutimi i njĂ« skripti tĂ« gabuar. EkzistojnĂ« gjithashtu kĂ«rkesa rregullatore pĂ«r ruajtjen e llojeve tĂ« caktuara tĂ« informacionit pĂ«r njĂ« periudhĂ« tĂ« zgjatur, pĂ«r shembull, deri nĂ« disa vjet.
Përdorimi më tipik i kopjeve rezervë është rivendosja e një kopjeje të ruajtur të bazave të të dhënave për vendosjen e sistemeve të ndryshme të testimit, klone për zhvilluesit.
Ka disa mite tipike rreth kopjeve rezervë që duhet të shpërndahen shumë kohë më parë. Këtu janë më të famshmit prej tyre.
Miti 1. Rezervimi ka qenë prej kohësh vetëm një funksion i vogël brenda sistemeve të sigurisë ose ruajtjes
Sistemet rezervë mbeten ende një klasë e veçantë zgjidhjesh dhe shumë të pavarura. Ata kanë shumë punë për të bërë. Në fakt, ato janë linja e fundit e mbrojtjes kur bëhet fjalë për integritetin e të dhënave. Pra, rezervimi funksionon me ritmin e vet, sipas orarit të vet. Një raport ditor gjenerohet për serverët, ka ngjarje që veprojnë si nxitës për sistemin e monitorimit.
Plus, modeli i rolit të aksesit në sistemin rezervë ju lejon të delegoni një pjesë të autoritetit tek administratorët e sistemeve të synuara për të menaxhuar kopjet rezervë.
Miti 2. Kur ka një RAID, një kopje rezervë nuk është më e nevojshme.
Pa dyshim, grupet RAID dhe riprodhimi i të dhënave janë një mënyrë e mirë për të mbrojtur sistemet e informacionit nga dështimet e harduerit, dhe nëse keni një server gatishmërie, mund të organizoni shpejt kalimin në të në rast se makina kryesore dështon.
Nga gabimet logjike që janë bërë nga përdoruesit e sistemit, teprica dhe përsëritja nuk kursen. Këtu është një server gatishmërie me shkrim mbrapa - po, mund të ndihmojë nëse zbulohet një gabim përpara se të sinkronizohej. Dhe nëse momenti humbet? Vetëm një kopje rezervë në kohë do të ndihmojë këtu. Nëse e dini që të dhënat ndryshuan dje, mund ta rivendosni sistemin në pardje dhe të nxirrni të dhënat e nevojshme prej tij. Duke pasur parasysh faktin se gabimet logjike janë më të zakonshmet, rezervimi i vjetër i mirë mbetet një mjet i provuar dhe i nevojshëm.
Miti 3. Një kopje rezervë është diçka që bëhet një herë në muaj.
Frekuenca e rezervimit Ă«shtĂ« njĂ« cilĂ«sim i konfigurueshĂ«m qĂ« varet kryesisht nga kĂ«rkesat e sistemit tuaj rezervĂ«. ĂshtĂ« mjaft e mundur tĂ« gjesh tĂ« dhĂ«na qĂ« pothuajse kurrĂ« nuk ndryshojnĂ« dhe nuk janĂ« veçanĂ«risht tĂ« rĂ«ndĂ«sishme, humbja e tyre nuk do tĂ« jetĂ« kritike pĂ«r kompaninĂ«.
Ato, në të vërtetë, mund të rezervohen një herë në muaj dhe madje edhe më rrallë. Por të dhënat më kritike ruhen më shpesh, në varësi të treguesit RPO (Recovery point Objrective), i cili përcakton humbjen e lejuar të të dhënave. Kjo mund të jetë një herë në javë, një herë në ditë ose edhe disa herë në orë. Ne i kemi këto regjistra të transaksioneve nga DBMS.
Kur sistemet vihen në funksionim komercial, duhet të miratohet dokumentacioni rezervë, i cili pasqyron pikat kryesore, procedurën e përditësimit, procedurën e rikthimit të sistemit, procedurën e ruajtjes së kopjeve rezervë dhe të ngjashme.
Miti 4. VĂ«llimi i kopjeve po rritet vazhdimisht dhe zĂ« plotĂ«sisht çdo hapĂ«sirĂ« ââtĂ« caktuar.
Rezervimet kanë një periudhë të kufizuar ruajtjeje. Nuk ka kuptim, për shembull, të ruash të gjitha 365 kopjet rezervë ditore gjatë vitit. Si rregull, lejohet të mbahen kopje ditore për 2 javë, pas së cilës ato zëvendësohen me të freskëta, dhe versioni që është bërë i pari në muaj mbetet në ruajtje afatgjatë. Ai, nga ana tjetër, ruhet gjithashtu për një kohë të caktuar - çdo kopje ka një jetë.
Ekziston një mbrojtje nga humbja e të dhënave. Rregulli zbatohet: para se të fshihet një kopje rezervë, duhet të formohet tjetra. Prandaj, të dhënat nuk do të fshihen nëse rezervimi nuk është përfunduar, për shembull, për shkak të mosdisponueshmërisë së serverit. Jo vetëm që respektohen kornizat kohore, por kontrollohet edhe numri i kopjeve në set. Nëse sistemi është projektuar që të ketë dy kopje rezervë të plotë, do të ketë gjithmonë dy prej tyre dhe e vjetra do të fshihet vetëm kur të shkruhet me sukses një i tretë i ri. Pra, rritja e vëllimit të zënë nga arkivi rezervë shoqërohet vetëm me rritjen e sasisë së të dhënave të mbrojtura dhe nuk varet nga koha.
Miti 5. Filloi kopjimi - gjithçka varej
ĂshtĂ« mĂ« mirĂ« tĂ« thuhet kjo: nĂ«se gjithçka ngrin, kjo do tĂ« thotĂ« qĂ« administratori Ă«shtĂ« nĂ« vendin e gabuar. NĂ« pĂ«rgjithĂ«si, performanca e kopjimit rezervĂ« varet nga shumĂ« faktorĂ«. PĂ«r shembull, nga shpejtĂ«sia e vetĂ« sistemit tĂ« kopjimit rezervĂ«: sa tĂ« shpejta janĂ« hapĂ«sirat e tij tĂ« ruajtjes nĂ« disk dhe bibliotekat e shiritit. Nga performanca. serverat Sistemet e kopjes rezervĂ«: nĂ«se ato mund tĂ« trajtojnĂ« pĂ«rpunimin e tĂ« dhĂ«nave, kompresimin dhe heqjen e dyfishimit. Dhe gjithashtu shpejtĂ«sinĂ« e lidhjes midis klientit dhe serverit.
Rezervimi mund të shkojë në një ose më shumë transmetime, në varësi të faktit nëse sistemi që rezervohet mbështet multithreading. Për shembull, Oracle DBMS ju lejon të jepni fije të shumta, sipas numrit të procesorëve të disponueshëm, derisa shpejtësia e transferimit të arrijë kufirin e gjerësisë së brezit të rrjetit.
Nëse përpiqeni të rezervoni një numër të madh temash, atëherë ekziston një shans për të mbingarkuar një sistem që funksionon, ai me të vërtetë do të fillojë të ngadalësohet. Prandaj, numri optimal i fijeve zgjidhet për të siguruar performancë të mjaftueshme. Nëse edhe rënia më e vogël e performancës është kritike, atëherë ekziston një mundësi e shkëlqyer kur kopjimi nuk kryhet nga një server luftarak, por nga kloni i tij - gatishmëria në terminologjinë e bazës së të dhënave. Ky proces nuk nis sistemin kryesor të punës. Të dhënat mund të merren përmes më shumë transmetimeve, pasi serveri nuk përdoret për mirëmbajtje.
Në organizatat e mëdha, krijohet një rrjet i veçantë për sistemin rezervë në mënyrë që rezervimi të mos ndikojë në prodhimin. Për më tepër, trafiku mund të mos transmetohet përmes rrjetit, por përmes SAN.
Ne përpiqemi të shpërndajmë ngarkesën edhe me kalimin e kohës. Rezervimet kryhen kryesisht gjatë orëve jo pune: gjatë natës, gjatë fundjavave. Gjithashtu, ata nuk vrapojnë të gjithë në të njëjtën kohë. Rezervimet e makinave virtuale janë një rast i veçantë. Procesi praktikisht nuk ka asnjë efekt në performancën e vetë makinës, kështu që rezervimi mund të shpërndahet gjatë ditës dhe të mos shtyjë gjithçka gjatë natës. Ka shumë hollësi, nëse merrni parasysh gjithçka, rezervimi nuk do të ndikojë në performancën e sistemeve.
Miti 6. Nis një sistem rezervë - kjo është toleranca e gabimeve për ju
Mos harroni kurrë se një sistem rezervë është linja e fundit e mbrojtjes, që do të thotë se duhet të ketë pesë sisteme të tjera përpara tij që sigurojnë vazhdimësinë, disponueshmërinë e lartë dhe tolerancën ndaj fatkeqësive të infrastrukturës së IT dhe sistemeve të informacionit të ndërmarrjeve.
Të shpresosh që kopja rezervë do të rivendosë të gjitha të dhënat dhe do të rrisë shpejt shërbimin e rënë nuk ia vlen. Humbja e të dhënave nga momenti i kopjimit deri në momentin e dështimit është i garantuar dhe të dhënat mund të ngarkohen në një server të ri për disa orë (ose ditë, siç jeni me fat). Prandaj, ka kuptim të krijohen sisteme të plota tolerante ndaj gabimeve pa zhvendosur gjithçka në një kopje rezervë.
Miti 7. Kam krijuar një kopje rezervë një herë, kontrollova nëse funksiononte. Mbetet vetëm për të parë regjistrat
Ky Ă«shtĂ« njĂ« nga mitet mĂ« tĂ« dĂ«mshme, falsifikimin e tĂ« cilit e kupton vetĂ«m gjatĂ« incidentit. Regjistrimet e suksesshme tĂ« rezervimit nuk janĂ« njĂ« garanci qĂ« gjithçka shkoi vĂ«rtet ashtu siç duhej. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kontrolloni paraprakisht kopjen e ruajtur pĂ«r vendosje. Kjo do tĂ« thotĂ«, filloni procesin e rikuperimit nĂ« njĂ« mjedis testimi dhe shikoni rezultatin.
Dhe pak për punën e administratorit të sistemit
Në modalitetin manual, askush nuk ka kopjuar të dhëna për një kohë të gjatë. SRK-të moderne mund të rezervojnë pothuajse gjithçka, thjesht duhet ta konfiguroni siç duhet. Nëse është shtuar një server i ri, vendosni politika: zgjidhni përmbajtjen që do të rezervohet, specifikoni opsionet e ruajtjes dhe zbatoni orarin.
Në të njëjtën kohë, ka ende shumë punë për shkak të flotës së gjerë të serverëve, duke përfshirë bazat e të dhënave, sistemet e postës, grupimet e makinave virtuale dhe ndarjet e skedarëve si në Windows ashtu edhe në Linux / Unix. Punonjësit që mbajnë në funksion sistemin rezervë nuk rrinë pa punë.
PĂ«r nder tĂ« festĂ«s, dĂ«shiroj t'u uroj tĂ« gjithĂ« administratorĂ«ve nerva tĂ« fortĂ«, qartĂ«si lĂ«vizjesh dhe hapĂ«sirĂ« ââtĂ« pafund pĂ«r ruajtjen e kopjeve rezervĂ«!
Burimi: www.habr.com
