Përshëndetje, lexues të Habrit! Në artikullin e fundit, ne folëm për një mjet të thjeshtë të rikuperimit të fatkeqësive në sistemet e ruajtjes së motorrit AERODISK - përsëritja. Në këtë artikull, ne do të zhytemi në një temë më komplekse dhe interesante - metrocluster, domethënë një mjet për mbrojtjen e automatizuar të fatkeqësive për dy qendra të të dhënave, duke lejuar qendrat e të dhënave të funksionojnë në modalitetin aktiv-aktive. Ne do t'ju tregojmë, do t'ju tregojmë, do ta thyejmë dhe do ta rregullojmë.
Si zakonisht, teoria së pari
Një metrokluster është një grup i shpërndarë në disa zona brenda një qyteti ose rajoni. Fjala "grup" na lë të kuptohet qartë se kompleksi është i automatizuar, domethënë, ndërrimi i nyjeve të grupimit në rast dështimesh ndodh automatikisht.
Këtu qëndron ndryshimi kryesor midis një metrocluster dhe replikimit të rregullt. Automatizimi i operacioneve. Kjo do të thotë, në rast të incidenteve të caktuara (dështimi i qendrës së të dhënave, kanalet e prishura, etj.), sistemi i ruajtjes do të kryejë në mënyrë të pavarur veprimet e nevojshme për të ruajtur disponueshmërinë e të dhënave. Kur përdorni kopje të rregullta, këto veprime kryhen tërësisht ose pjesërisht manualisht nga administratori.
Çfarë do të bëni?
Qëllimi kryesor që klientët ndjekin kur përdorin implementime të caktuara metrokluster është të minimizojnë RTO (Objektivi i Kohës së Rimëkëmbjes). Kjo do të thotë, për të minimizuar kohën e rikuperimit të shërbimeve të IT pas një dështimi. Nëse përdorni përsëritje të rregullt, koha e rikuperimit do të jetë gjithmonë më e gjatë se koha e rikuperimit me një metrocluster. Pse? Shume e thjeshte. Administratori duhet të jetë në tryezën e tij dhe të ndërrojë replikimin manualisht, dhe metrocluster-i e bën këtë automatikisht.
Nëse nuk keni një administrator të dedikuar në detyrë që nuk fle, nuk ha, nuk pi duhan ose sëmuret dhe shikon gjendjen e sistemit të ruajtjes 24 orë në ditë, atëherë nuk ka asnjë mënyrë për të garantuar që administratori do të të jetë i disponueshëm për ndërrim manual gjatë një dështimi.
Prandaj, RTO në mungesë të një metroclusteri ose një administratori të pavdekshëm të nivelit të 99-të të shërbimit të detyrës së administratorit do të jetë i barabartë me shumën e kohës së kalimit të të gjitha sistemeve dhe periudhën maksimale pas së cilës administratori garantohet të fillojë punën me sistemet e ruajtjes dhe sistemet përkatëse.
Kështu, arrijmë në përfundimin e qartë se metrocluster duhet të përdoret nëse kërkesa për RTO është minuta, jo orë ose ditë. Kjo do të thotë, kur në rast të dështimit më të keq të qendrës së të dhënave, departamenti i IT duhet t'i japë biznesit me kohë. për të rikthyer aksesin në shërbimet e IT brenda disa minutave, apo edhe sekondave.
Si funksionon kjo gjë?
Në nivelin më të ulët, metrokluster përdor një mekanizëm për riprodhimin sinkron të të dhënave, të cilin e përshkruam në artikullin e mëparshëm (shih. ). Meqenëse përsëritja është sinkron, kërkesat për të janë korresponduese, ose më saktë:
- fibër optike si fizikë, 10 gigabit Ethernet (ose më e lartë);
- distanca midis qendrave të të dhënave nuk është më shumë se 40 kilometra;
- Vonesa e kanalit optik midis qendrave të të dhënave (midis sistemeve të ruajtjes) është deri në 5 milisekonda (optimalisht 2).
Të gjitha këto kërkesa kanë natyrë këshilluese, domethënë, metroklusteri do të funksionojë edhe nëse këto kërkesa nuk plotësohen, por duhet të kuptojmë se pasojat e mosrespektimit të këtyre kërkesave janë të barabarta me një ngadalësim të funksionimit të të dy sistemeve të ruajtjes në metroklusterin.
Pra, një kopje sinkron përdoret për të transferuar të dhëna midis sistemeve të ruajtjes dhe si ndërrohen automatikisht kopjet dhe, më e rëndësishmja, si të shmanget truri i ndarë? Për ta bërë këtë, në një nivel më të lartë, përdoret një ent shtesë - një arbitër.
Si funksionon një arbitër dhe cila është detyra e tij?
Arbitri është një makinë e vogël virtuale ose një grup harduerësh që duhet të lëshohet në një faqe të tretë (për shembull, në një zyrë) dhe të sigurojë akses në sistemin e ruajtjes nëpërmjet ICMP dhe SSH. Pas nisjes, arbitri duhet të vendosë IP-në, dhe më pas nga ana e ruajtjes të tregojë adresën e saj, plus adresat e telekomandave që marrin pjesë në metrocluster. Pas kësaj, gjyqtari është gati për të punuar.
Arbitri monitoron vazhdimisht të gjitha sistemet e ruajtjes në metrokluster dhe nëse një sistem i veçantë ruajtjeje nuk është i disponueshëm, pasi konfirmon mosdisponueshmërinë nga një anëtar tjetër i grupit (një nga sistemet e ruajtjes "live"), ai vendos të nisë procedurën për ndërrimin e rregullave të riprodhimit. dhe hartëzimi.
Një pikë shumë e rëndësishme. Arbitri duhet të jetë gjithmonë në një vend të ndryshëm nga ato në të cilat ndodhen sistemet e ruajtjes, domethënë, as në qendrën e të dhënave 1, ku është instaluar sistemi i ruajtjes 1, as në qendrën e të dhënave 2, ku është instaluar sistemi i ruajtjes 2.
Pse? Sepse kjo është e vetmja mënyrë që një arbitër, me ndihmën e një prej sistemeve të ruajtjes së mbijetuar, mund të përcaktojë pa mëdyshje dhe saktësi rënien e ndonjë prej dy vendeve ku janë instaluar sistemet e ruajtjes. Çdo metodë tjetër e vendosjes së një arbitri mund të rezultojë në një ndarje të trurit.
Tani le të zhytemi në detajet e punës së arbitrit.
Arbitri drejton disa shërbime që anketojnë vazhdimisht të gjithë kontrollorët e ruajtjes. Nëse rezultati i sondazhit ndryshon nga ai i mëparshmi (i disponueshëm/i padisponueshëm), atëherë ai regjistrohet në një bazë të dhënash të vogël, e cila funksionon edhe tek arbitri.
Le të shohim më në detaje logjikën e punës së arbitrit.
Hapi 1: Përcaktoni padisponueshmërinë. Një ngjarje e dështimit të sistemit të ruajtjes është mungesa e ping nga të dy kontrollorët e të njëjtit sistem ruajtjeje brenda 5 sekondave.
Hapi 2. Filloni procedurën e ndërrimit. Pasi arbitri ka kuptuar se një nga sistemet e ruajtjes nuk është i disponueshëm, ai i dërgon një kërkesë sistemit të ruajtjes "live" në mënyrë që të sigurohet që sistemi i ruajtjes "i vdekur" është vërtet i vdekur.
Pas marrjes së një komande të tillë nga arbitri, sistemi i dytë (live) i ruajtjes kontrollon gjithashtu disponueshmërinë e sistemit të ruajtjes së parë të rënë dhe, nëse nuk është aty, i dërgon konfirmimin arbitrit të supozimit të tij. Sistemi i ruajtjes është me të vërtetë i padisponueshëm.
Pas marrjes së një konfirmimi të tillë, arbitri fillon një procedurë në distancë për ndërrimin e replikimit dhe ngritjen e hartës në ato kopje që ishin aktive (primare) në sistemin e ruajtjes së rënë, dhe dërgon një komandë në sistemin e dytë të ruajtjes për të ndryshuar këto kopje nga sekondare në parësore dhe ngre hartën. Epo, sistemi i dytë i ruajtjes, në përputhje me rrethanat, kryen këto procedura, dhe më pas siguron qasje në LUN-të e humbura nga vetja.
Pse nevojitet verifikim shtesë? Për kuorumin. Kjo do të thotë, shumica e numrit total tek (3) të anëtarëve të grupimit duhet të konfirmojnë rënien e një prej nyjeve të grupimit. Vetëm atëherë ky vendim do të jetë padyshim i saktë. Kjo është e nevojshme për të shmangur ndërrimin e gabuar dhe, në përputhje me rrethanat, ndarjen e trurit.
Hapi kohor 2 zgjat afërsisht 5 - 10 sekonda, kështu, duke marrë parasysh kohën e nevojshme për të përcaktuar padisponueshmërinë (5 sekonda), brenda 10 - 15 sekondave pas aksidentit, LUN nga sistemi i ruajtjes së rënë do të jenë automatikisht të disponueshëm për të punuar me transmetimin e drejtpërdrejtë. sistemi i ruajtjes.
Është e qartë se për të shmangur humbjen e lidhjeve me hostet, duhet të kujdeseni gjithashtu që të konfiguroni saktë afatet e kohrave në host. Koha e rekomanduar është të paktën 30 sekonda. Kjo do të parandalojë që hosti të ndërpresë lidhjen me sistemin e ruajtjes gjatë ndërrimit të ngarkesës në rast fatkeqësie dhe mund të sigurojë që të mos ketë ndërprerje hyrëse/dalëse.
Prisni një sekondë, rezulton se nëse gjithçka është aq mirë me metroklusterin, pse kemi nevojë fare për përsëritje të rregullt?
Në realitet, gjithçka nuk është aq e thjeshtë.
Le të shqyrtojmë të mirat dhe të këqijat e metroklusterit
Pra, kuptuam se avantazhet e dukshme të metroklusterit në krahasim me replikimin konvencional janë:
- Automatizimi i plotë, duke siguruar kohë minimale të rikuperimit në rast fatkeqësie;
- Kjo eshte e gjitha :-).
Dhe tani, vëmendje, disavantazhet:
- Kostoja e zgjidhjes. Megjithëse metroklusteri në sistemet Aerodisk nuk kërkon licencim shtesë (përdoret e njëjta licencë si për kopjen), kostoja e zgjidhjes do të jetë akoma më e lartë se përdorimi i riprodhimit sinkron. Do t'ju duhet të zbatoni të gjitha kërkesat për një kopje sinkrone, plus kërkesat për metroklusterin që lidhen me ndërrimin shtesë dhe vendndodhjen shtesë (shih planifikimin e metroklusterit);
- Kompleksiteti i zgjidhjes. Metrocluster është shumë më kompleks se një kopje e zakonshme, dhe kërkon shumë më tepër vëmendje dhe përpjekje për planifikim, konfigurim dhe dokumentacion.
Përfundimisht. Metrocluster është padyshim një zgjidhje shumë e avancuar teknologjikisht dhe e mirë kur vërtet duhet të siguroni RTO në sekonda ose minuta. Por nëse nuk ka një detyrë të tillë, dhe RTO në orë është në rregull për biznesin, atëherë nuk ka kuptim të gjuani harabela nga një top. Replikimi i zakonshëm punëtor-fshatar është i mjaftueshëm, pasi një grup metro do të shkaktojë kosto shtesë dhe ndërlikim të infrastrukturës së IT.
Planifikimi i metroklusterit
Ky seksion nuk pretendon të jetë një udhëzues gjithëpërfshirës për hartimin e metroklusterit, por tregon vetëm drejtimet kryesore që duhet të përpunohen nëse vendosni të ndërtoni një sistem të tillë. Prandaj, kur zbatoni një metrocluster, sigurohuni që të përfshini prodhuesin e sistemit të ruajtjes (d.m.th. ne) dhe sisteme të tjera të lidhura për konsultime.
Vendet e organizimit
Siç u tha më lart, një metrocluster kërkon të paktën tre vende. Dy qendra të dhënash ku do të funksionojnë sistemet e ruajtjes dhe sistemet përkatëse, si dhe një vend i tretë ku do të punojë arbitri.
Distanca e rekomanduar midis qendrave të të dhënave nuk është më shumë se 40 kilometra. Një distancë më e madhe ka shumë të ngjarë të shkaktojë vonesa shtesë, të cilat në rastin e një metroklusteri janë jashtëzakonisht të padëshirueshme. Ju kujtojmë se vonesat duhet të jenë deri në 5 milisekonda, por këshillohet që t'i mbani brenda 2.
Rekomandohet të kontrollohen vonesat edhe gjatë procesit të planifikimit. Çdo ofrues pak a shumë i pjekur që ofron fibër optike midis qendrave të të dhënave mund të organizojë një kontroll cilësie mjaft shpejt.
Sa i përket vonesave para arbitrit (d.m.th., midis faqes së tretë dhe dy të parave), pragu i rekomanduar i vonesës është deri në 200 milisekonda, domethënë, një lidhje e rregullt VPN e korporatës përmes Internetit është e përshtatshme.
Ndërrimi dhe rrjetëzimi
Ndryshe nga skema e replikimit, ku mjafton të lidhni sistemet e ruajtjes nga vende të ndryshme, skema e metroklusterit kërkon lidhjen e hosteve me të dy sistemet e ruajtjes në vende të ndryshme. Për ta bërë më të qartë se cili është ndryshimi, të dyja skemat tregohen më poshtë.
Siç mund të shihet nga diagrami, hostet e faqes sonë 1 shikojnë si sistemin e ruajtjes 1 ashtu edhe sistemin e ruajtjes 2. Gjithashtu, përkundrazi, hostet e faqes 2 shikojnë si sistemin e ruajtjes 2 ashtu edhe sistemin e ruajtjes 1. Kjo do të thotë, çdo host i sheh të dy sistemet e ruajtjes. Ky është një parakusht për funksionimin e metroklusterit.
Natyrisht, nuk ka nevojë të lidhni çdo host me një kordon optik me një qendër tjetër të dhënash; asnjë portë ose kordon nuk do të mjaftojë. Të gjitha këto lidhje duhet të kryhen përmes ndërprerësve Ethernet 10G+ ose FibreChannel 8G+ (FC është vetëm për lidhjen e hosteve dhe sistemeve të ruajtjes për IO, kanali i replikimit është aktualisht i disponueshëm vetëm nëpërmjet IP-së (Ethernet 10G+).
Tani disa fjalë për topologjinë e rrjetit. Një pikë e rëndësishme është konfigurimi i saktë i nënrrjeteve. Është e nevojshme që menjëherë të përcaktohen disa nënrrjeta për llojet e mëposhtme të trafikut:
- Nënrrjeti i replikimit mbi të cilin të dhënat do të sinkronizohen ndërmjet sistemeve të ruajtjes. Mund të ketë disa prej tyre, në këtë rast nuk ka rëndësi, gjithçka varet nga topologjia aktuale (tashmë e zbatuar) e rrjetit. Nëse ka dy prej tyre, atëherë padyshim që rrugëtimi duhet të konfigurohet midis tyre;
- Nënrrjetet e ruajtjes përmes të cilave hostet do të kenë akses në burimet e ruajtjes (nëse është iSCSI). Duhet të ketë një nënrrjet të tillë në çdo qendër të dhënash;
- Nënrrjetet e kontrollit, d.m.th., tre nënrrjeta të rutueshme në tre faqe nga të cilat menaxhohen sistemet e ruajtjes, dhe arbitri ndodhet gjithashtu atje.
Ne nuk i konsiderojmë nën-rrjetet për të hyrë në burimet e hostit këtu, pasi ato varen shumë nga detyrat.
Ndarja e trafikut të ndryshëm në nënrrjeta të ndryshme është jashtëzakonisht e rëndësishme (është veçanërisht e rëndësishme të ndani kopjen nga I/O), sepse nëse e përzieni të gjithë trafikun në një nënrrjet "të trashë", atëherë ky trafik do të jetë i pamundur të menaxhohet, dhe në kushtet e dy qendrave të të dhënave kjo ende mund të shkaktojë opsione të ndryshme të përplasjes së rrjetit. Ne nuk do të thellohemi thellë në këtë çështje brenda kornizës së këtij artikulli, pasi mund të lexoni për planifikimin e një rrjeti të shtrirë midis qendrave të të dhënave në burimet e prodhuesve të pajisjeve të rrjetit, ku kjo përshkruhet në detaje.
Konfigurimi i arbitrit
Arbitri duhet të sigurojë akses në të gjitha ndërfaqet e menaxhimit të sistemit të ruajtjes nëpërmjet protokolleve ICMP dhe SSH. Ju gjithashtu duhet të mendoni për dështimin e arbitrit. Këtu ka një nuancë.
Dështimi i arbitrit është shumë i dëshirueshëm, por nuk kërkohet. Çfarë ndodh nëse arbitri rrëzohet në kohën e gabuar?
- Funksionimi i metroklusterit në modalitetin normal nuk do të ndryshojë, sepse arbtir nuk ka absolutisht asnjë efekt në funksionimin e metroklusterit në modalitetin normal (detyra e tij është të kalojë ngarkesën midis qendrave të të dhënave në kohën e duhur)
- Për më tepër, nëse arbitri për një arsye ose një tjetër bie dhe "e zë gjumi" një aksident në qendrën e të dhënave, atëherë nuk do të ndodhë asnjë ndërrim, sepse nuk do të ketë njeri që të japë komandat e nevojshme të ndërrimit dhe të organizojë një kuorum. Në këtë rast, metrokluster do të kthehet në një skemë të rregullt me replikim, e cila do të duhet të ndërrohet manualisht gjatë një fatkeqësie, e cila do të ndikojë në RTO.
Çfarë rrjedh nga kjo? Nëse vërtet duhet të siguroni një RTO minimale, duhet të siguroheni që arbitri të jetë tolerant ndaj gabimeve. Ka dy opsione për këtë:
- Nisni një makinë virtuale me një arbitër në një hipervizor tolerant ndaj gabimeve, për fat të mirë të gjithë hipervizorët e rritur mbështesin tolerancën ndaj gabimeve;
- Nëse në vendin e tretë (në një zyrë konvencionale) jeni shumë dembel për të instaluar një grup normal dhe nuk ka grup ekzistues të hipervozorit, atëherë ne kemi ofruar një version harduer të arbitrit, i cili është bërë në një kuti 2U në të cilën dy të zakonshëm Serverët x-86 punojnë dhe të cilët mund t'i mbijetojnë një dështimi lokal.
Ne rekomandojmë fuqimisht sigurimin e tolerancës së fajit të arbitrit, pavarësisht nga fakti se metrokluster nuk ka nevojë për të në modalitetin normal. Por, siç tregojnë teoria dhe praktika, nëse ndërtoni një infrastrukturë vërtet të besueshme kundër katastrofave, atëherë është më mirë ta luani të sigurt. Është më mirë të mbroni veten dhe biznesin tuaj nga "ligji i poshtërësisë", domethënë nga dështimi i arbitrit dhe i një prej vendeve ku ndodhet sistemi i ruajtjes.
Arkitektura e zgjidhjeve
Duke marrë parasysh kërkesat e mësipërme, marrim arkitekturën e mëposhtme të përgjithshme të zgjidhjes.
LUN-et duhet të shpërndahen në mënyrë të barabartë në dy vende për të shmangur mbingarkesat e rënda. Në të njëjtën kohë, gjatë përcaktimit të madhësisë në të dy qendrat e të dhënave, duhet të përfshini jo vetëm vëllimin e dyfishtë (i cili është i nevojshëm për të ruajtur të dhënat në të njëjtën kohë në dy sisteme ruajtjeje), por edhe performancën e dyfishtë në IOPS dhe MB/s për të parandaluar degradimin e aplikacionit në ngjarja e dështimit të njërës prej qendrave të të dhënave ov.
Më vete, vërejmë se me qasjen e duhur ndaj madhësisë (d.m.th., me kusht që të kemi siguruar kufijtë e sipërm të duhur të IOPS dhe MB/s, si dhe burimet e nevojshme të CPU dhe RAM), nëse një nga sistemet e ruajtjes në Dështon grupi i metrosë, nuk do të ketë një rënie serioze të performancës në kushtet e punës së përkohshme në një sistem magazinimi.
Kjo shpjegohet me faktin se kur dy site funksionojnë njëkohësisht, përsëritja sinkron "ha" gjysmën e performancës së shkrimit, pasi çdo transaksion duhet të shkruhet në dy sisteme ruajtjeje (të ngjashme me RAID-1/10). Pra, nëse një nga sistemet e ruajtjes dështon, ndikimi i replikimit përkohësisht (derisa sistemi i ruajtjes së dështuar të rikuperohet) zhduket dhe marrim një rritje të dyfishtë në performancën e shkrimit. Pasi LUN-të e sistemit të ruajtjes së dështuar rifillojnë në sistemin e ruajtjes së punës, kjo rritje e dyfishtë zhduket për shkak të faktit se ngarkesa shfaqet nga LUN-të e sistemit tjetër të ruajtjes dhe ne kthehemi në të njëjtin nivel të performancës që kishim përpara "bie", por vetëm brenda kornizës së një siti.
Me ndihmën e përmasave kompetente, ju mund të siguroni kushte në të cilat përdoruesit nuk do të ndjejnë fare dështimin e një sistemi të tërë ruajtjeje. Por e përsërisim edhe një herë, kjo kërkon përmasa shumë të kujdesshme, për të cilën, meqë ra fjala, mund të na kontaktoni falas :-).
Ngritja e një metroklusteri
Vendosja e një metroklusteri është shumë e ngjashme me vendosjen e riprodhimit të rregullt, të cilin e përshkruam . Prandaj, le të përqendrohemi vetëm në dallimet. Ne ngritëm një stol në laborator bazuar në arkitekturën e mësipërme, vetëm në një version minimal: dy sisteme ruajtjeje të lidhura nëpërmjet 10G Ethernet, dy ndërprerës 10G dhe një host që shikon përmes ndërprerësve në të dy sistemet e ruajtjes me porte 10G. Arbitri punon në një makinë virtuale.
Kur konfiguroni IP virtuale (VIP) për një kopje, duhet të zgjidhni llojin VIP - për metrocluster.
Ne krijuam dy lidhje riprodhimi për dy LUN dhe i shpërndamë ato në dy sisteme ruajtjeje: LUN TEST Primary në sistemin e ruajtjes 1 (lidhja METRO), LUN TEST2 Primary për sistemin e ruajtjes 2 (lidhja METRO2).
Për ta, ne konfiguruam dy objektiva identikë (në rastin tonë iSCSI, por FC gjithashtu mbështetet, logjika e konfigurimit është e njëjtë).
Sistemi i ruajtjes 1:
Sistemi i ruajtjes 2:
Për lidhjet e riprodhimit, u bënë harta në çdo sistem magazinimi.
Sistemi i ruajtjes 1:
Sistemi i ruajtjes 2:
Ne vendosëm shumë rrugë dhe ia paraqitëm atë hostit.
Ngritja e një arbitri
Ju nuk keni nevojë të bëni ndonjë gjë të veçantë me vetë arbitrin; thjesht duhet ta aktivizoni atë në faqen e tretë, t'i jepni një IP dhe të konfiguroni aksesin në të nëpërmjet ICMP dhe SSH. Vetë konfigurimi kryhet nga vetë sistemet e ruajtjes. Në këtë rast, mjafton të konfiguroni arbitrin një herë në cilindo nga kontrollorët e ruajtjes në metrocluster; këto cilësime do t'u shpërndahen të gjithë kontrollorëve automatikisht.
Në seksionin Replikimi në distancë>> Metrocluster (në çdo kontrollues)>> butoni "Konfiguro".
Ne futim IP-në e arbitrit, si dhe ndërfaqet e kontrollit të dy kontrolluesve të ruajtjes në distancë.
Pas kësaj, duhet të aktivizoni të gjitha shërbimet (butoni "Rinisni gjithçka"). Nëse rikonfigurohet në të ardhmen, shërbimet duhet të rifillojnë që cilësimet të hyjnë në fuqi.
Ne kontrollojmë që të gjitha shërbimet po funksionojnë.
Kjo përfundon konfigurimin e metroklusterit.
Testi i përplasjes
Testi i përplasjes në rastin tonë do të jetë mjaft i thjeshtë dhe i shpejtë, pasi funksionaliteti i riprodhimit (ndërrimi, qëndrueshmëria, etj.) u diskutua në . Prandaj, për të testuar besueshmërinë e metroklusterit, mjafton që ne të kontrollojmë automatizimin e zbulimit të dështimit, kalimit dhe mungesës së humbjeve të regjistrimit (ndalesat I/O).
Për ta bërë këtë, ne imitojmë një dështim të plotë të njërit prej sistemeve të ruajtjes duke fikur fizikisht të dy kontrollorët e tij, pasi fillimisht kemi filluar kopjimin e një skedari të madh në LUN, i cili duhet të aktivizohet në sistemin tjetër të ruajtjes.
Çaktivizo një sistem ruajtjeje. Në sistemin e dytë të ruajtjes ne shohim alarme dhe mesazhe në regjistrat se lidhja me sistemin fqinj ka humbur. Nëse njoftimet nëpërmjet monitorimit SMTP ose SNMP janë konfiguruar, administratori do të marrë njoftimet përkatëse.
Saktësisht 10 sekonda më vonë (e dukshme në të dy pamjet e ekranit), lidhja e përsëritjes METRO (ajo që ishte Primar në sistemin e ruajtjes së dështuar) u bë automatikisht Primar në sistemin e ruajtjes që funksiononte. Duke përdorur hartën ekzistuese, LUN TEST mbeti i disponueshëm për hostin, regjistrimi u zhyt pak (brenda 10 përqindëshit të premtuar), por nuk u ndërpre.
Testi përfundoi me sukses.
Duke përmbledhur
Zbatimi aktual i metroklusterit në sistemet e ruajtjes së serisë AERODISK Engine N lejon plotësisht zgjidhjen e problemeve aty ku është e nevojshme të eliminohet ose minimizohet koha e ndërprerjes për shërbimet e IT dhe të sigurohet funksionimi i tyre 24/7/365 me kosto minimale të punës.
Mund të themi, sigurisht, se e gjithë kjo është teori, kushte ideale laboratorike, e kështu me radhë... POR ne kemi një sërë projektesh të zbatuara në të cilat kemi zbatuar funksionalitetin e rezistencës ndaj fatkeqësive dhe sistemet funksionojnë në mënyrë perfekte. Një nga klientët tanë mjaft të njohur, i cili përdor vetëm dy sisteme ruajtjeje në një konfigurim rezistent ndaj fatkeqësive, tashmë ka rënë dakord të publikojë informacione rreth projektit, kështu që në pjesën tjetër do të flasim për zbatimin luftarak.
Faleminderit, presim një diskutim produktiv.
Burimi: www.habr.com