Sot dikur në infrastrukturën IT, me përdorimin e përgjithshëm të virtualizimit, sistemet e ruajtjes së të dhënave janë thelbi që ruan të gjitha makinat virtuale. Dështimi i këtij elementi mund të ndalë plotësisht funksionin e qendrës së kujtesës. Edhe pse një pjesë e konsiderueshme e pajisjeve serverike ka dështim të qëndrueshëm në një formë ose një tjetër "nga-default", për shkak të rolit të veçantë të SCHED në kuadër të qendrës së të dhënave, kërkesat për të janë më të larta në aspektin e "vijueshmërisë".
Metoda më efektive për të siguruar dështimin e qëndrueshëm në IT është përdorimi i disa kopjeve të pajisjeve dhe SO-së (në rastin më të thjeshtë - dyfishimi). Sigurisht, SCHED mund të dyfishohet plotësisht. Dhe për rikuperimin nga katastrofat, pikërisht ky qasje përdoret. Por jo të gjithë kompanitë mund ta përballojnë një zgjidhje të tillë. Fjalën nuk e kam vetëm për koston e dyfishuar të pajisjeve, por edhe për shpenzimet e tjera për organizimin e një zgjidhjeje të tillë dhe mbështetjes së saj të mëtejshme.
Megjithatë, mundësia e dyfishimit të pajisjeve nuk heq nevojën për të siguruar dështimin e qëndrueshëm në nivelin e komponentëve. Në veçanti, në SCHED aplikohet rezervimi për blloqet e energjisë, modulët e ndihmës, ruajtësit dhe, natyrisht, kontrolluesit. Të gjitha këto kanë kohë që janë bërë rutinë. Është e vështirë të gjejmë SCHED pa përdorimin e një dizajni të tillë. këtu – nuk është përjashtim. Por dëshirojmë të flasim në këtë artikull për atë që nuk bie në sy menjëherë, dhe që është e fokusuar kryesisht në rritjen e qëndrueshmërisë së sistemit si një e tërë.
Modulet e ndihmës
Shumë shpesh në me kaseta 2U-3U përdoren module të kombinuara, që bashkojnë bloket e energjisë dhe ventilatorët. Nga njëra anë, kjo është e përshtatshme, pasi duhet të mirëmbahen vetëm një bllok. Nga ana tjetër, nëse sistemi i ndihmës dështon, mund të ndalojë bllokun e energjisë për të shmangur mbinxehjen. Dhe duket se do të krijohet një situatë jo aq kritike, por shtimi i dobësive në SCHED nuk është me të vërtetë i dëshiruar.
Ftohja në SÇD Qsan është organizuar në formën e moduleve të veçanta me "kërkesë të nxehtë", të pavarur nga blloqet e energjisë. Saktësisht, në blloqet e energjisë ka ventilatorë të tyre, të destinuar për ajrosjen e vetë BPs. Moduli i ftohjes përmban dy ventilatorë të pavarur, të cilët sigurojnë njëri-tjetrin. Ka dy module të tilla në SÇD: njëri në të djathtë dhe tjetri në të majtë – për ajrosjen efikase të të gjitha komponenteve. Nëse ndodh një dështim i njërit nga ventilatorët, të gjithë të tjerët automatikisht rrisin shpejtësinë e tyre për të kompensuar mungesën e fluksit të ajrit që është krijuar. Për këtë arsye, defekti i ventilatorit nuk paraqet rrezik për tepricën e gjithë pajisjes.
Topologjia e lidhjes së rafteve të zgjerimit
Skema klasike e lidhjes në SÇD nënkupton një topologji që quhet kaskadë. Në këtë rast, kontrollorët përkatës të rafteve dhe SÇD lidhen me njëri-tjetrin përmes një kablli SAS të vetëm. Pra, gjithsej rezulton në 2 kabuj për një sistem me dy kontrollorë. Nëse kërkohet të lidhet e dyta, ajo lidhet njëjtë me rafte e parë. Dhe kështu me radhë. Një avantazh i kësaj topologjie është thjeshtësia e realizimit në pajisje. Ndërsa një disavantazh do të ishte disa vulnerabilitet ndaj ndarjes papritur të zinXhirëve SAS për shkak të dështimit të kryqëzuar të kontrollorëve të pandër lidhur të SÇD dhe rafteve ose për shkak të energjisë së humbur të njërit nga rafteve të zgjerimit në mes të zinXhirëve. Si rezultat, do të humbasim aksesin në një pjesë të ruajtësve dhe mund të shkatërrojmë grupin RAID, nëse ai është "i shpërndarë" në disa trupa.
Nga dështimi i kryqëzuar i kontrollorëve, Qsan ka një mbrojtje në formën e një lidhjeje logjike të brendshme midis kontrollorëve përmes backplane të SÇD. Kështu, kontrollori i SÇD sheh jo vetëm kontrollorin JBOD, i lidhur drejtpërdrejt me të, por edhe kontrollorin "fqinji" përmes një lidhjeje speciale në backplane. Si rezultat, nëse ndodh kjo situatë dhe askush fizikisht nuk do të tërheqë kabujt SAS midis SÇD dhe rafteve, aksesin në të gjithë ruajtësit do të ruhet.
Për të mbrojtur nga ndërprerja e zinxhirit SAS, për shembull, për shkak të humbjes së energjisë së raftit të zgjatjes, zakonisht aplikohet një topologji tjetër lidhëse – kaskada e kundërt. Në këtë rast, SXY lidhet direkt me raftin e parë dhe të fundit në zinxhir, duke marrë qasje në disqet siç do të ishte nga të dy anët.
Nëse dëshiron një mbrojtje më të fortë, mund të ndërtohen konfigurations më të mëdha, duke përdorur, për shembull, topologjinë e pemës. Ose mund të komplikohet akoma më shumë nëpërmjet kombinimit të topologjive të përmendura. Kjo është e mundur falë numrit të madh të lidhjeve SAS në pajisje (2 për çdo kontrollues SXY dhe 5 për çdo kontrollues JBOD) me identifikimin automatik të mënyrave të punës hyrje/ dalje. E rëndësishme është që admini vetë të mos ngatërohet. SXY do të jetë në gjendje ta konfigurojë siç duhet.
Fast rebuild
Prania në sistem e disqeve rezervë me ‘zëvendësim të nxehtë’ (hot spare) rrit ndjeshëm besueshmërinë e ruajtjes së informacionit. Megjithatë, thjesht të bësh të disponueshëm disqe të tillë nuk do të thotë se ke mbrojtje absolute. Problemi është se procesi i rikuperimit (rebild) është mjaft i lodhshëm dhe shpesh zgjat gjatë. Kjo vështirësi shfaqet për shkak të aksesit të vazhdueshëm në të dhënat kryesore. Kjo do të thotë që sistemi, përveç punës aktuale, duhet gjithashtu të kopjojë të dhënat në diskun e ri. Dhe gjatëzgjatja e rebild-it është drejtpërdrejt e varur nga kapaciteti i disku dhe karakteristikat e tij të shpejtësisë. Duke qenë se sistemi nuk di asgjë për hapësirën reale të zënë në disqe, ai në procesin e rebild-it vetëm kopjon gjithçka: bllok pas blloku.
Si rezultat, rikuperimi i një disku modern me kapacitet të madh 10+TB në ngarkesë të rëndë mbi SXY mund të zgjasë lehtësisht një javë e më shumë. Duhet gjithashtu të merret parasysh që gjatë rebild-it, rritet dukshëm probabiliteti i dështimit të disqeve të tjera për shkak të ngarkesës së shtuar mbi to. Dhe kjo mund të paraqesë një rrezik serioz në rast se përdoret, për shembull, RAID5.
Si zgjidhje për këtë problem, shumë zhvillues të SXY-ve kanë shqetësuar përshpejtimin e procesit të rikuperimit. Për këtë, mund të aplikohen qasje të ndryshme, por thelbi mbetet i njëjtë – kopjimi gjatë rebild-it i vetëm bllokave realisht të zëna. Qsan nuk ka mbetur anash nga ky problem. SXY-ja e këtij produkti ka një opsion të aktivizuar. sistemi monitoron ndihmën e përdorur për regjistrimin e bllokëve, duke pasur kështu mundësinë që në rast të një dështimi të harduerit të kopjojë vetëm ata në një njësi të re.
Opsioni Fast Rebuild nuk është i aktivizuar si parazgjedhje gjatë krijimit të volumieve, pasi përdorimi i tij ka ndikim në performancë, veçanërisht gjatë operacioneve të shkruarjes rastësore, sepse:
- Duhet të monitorohet regjistrimi në blloqe;
- Gjatë ribuild-it nuk ndodh ribarazimi i kontrolleve për hapësirat e papërdorura, prandaj për regjistrimin e ri në këtë zonë është e nevojshme së pari "të inicializohet" ajo.
Prandaj, nuk rekomandohet përdorimi i Fast Rebuild për volumet, për shembull, me baza të dhënash me ngarkesë të lartë ose në sistemi monitorimi, ku volumi gjithsesi do të mbushet në 100%. Por për serverët e skedarëve ose të postës, ky opsion do të jetë në të vërtetë shumë i dobishëm.
Në përfundim
Çdo prodhues i regjistrimeve të dhënash nënkupton se pajisjet e tij janë të besueshme. Dhe nëse nuk ka gabime fatale gjatë zhvillimit të pajisjeve dhe përpjekjeve të jashtëzakonshme për kursimin e kostove gjatë procesit të prodhimit dhe testimit, në përgjithësi, mund të bien dakord me shitësin. Megjithatë, duhet të kuptohet:
- besueshmëria bazë e regjistrimeve të dhënash është përpara gjithçka një mënyrë për të vazhduar qasjen në të dhëna në rast të dështimit të ndonjë komponenti(i);
- opsionet shtesë përsa i përket besueshmërisë (si ato që u përmendën më sipër) janë përjashtimi i disa mundësive për defekte dhe rritja e mundësive tuaja për të pasur qasje në të dhëna;
- Besueshmëria 100%, fatkeqësisht, nuk ekziston. Mirëpo, për të arritur sa më afër saj, shumica e shitësve të sjellshëm të regjistrimeve të dhënash (dhe mes tyre) bëjnë maksimumin për të përmirësuar vazhdimisht produktet e tyre si në aspektin harduerik ashtu edhe në atë softuerik.
Gjithashtu, duhet të kihet parasysh se asnjë besueshmëri absolute e regjistrimeve të dhënash nuk anulon nevojën për kopje rezervë, plane të qarta dhe të provuara për rikuperimin në rast të një emergjence dhe mbështetje teknike operative nga shitësi.
Burimi: habr.com
