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
