Përshëndetje, lexues të Habrës! Tema e këtij artikulli do të jetë realizimi i mjeteve të qëndrueshmërisë ndaj katastrofave në sistemet e ruajtjes AERODISK Engine. Fillimisht, ne dëshironim të shkruanim në një artikull për të dy mjetet: replikimin dhe metroklastrin, por, për fat të keq, artikulli doli shumë i gjatë, prandaj e ndamë artikullin në dy pjesë. Le të fillojmë nga e thjeshta deri te e komplikuara. Në këtë artikull do të konfigurojmë dhe testojmë replikimin sinhron – do të rrëzojmë një Qendër të Dhënash (CZ) dhe gjithashtu do të ndalim kanalin e komunikimit midis CZ-ve dhe do të shohim se çfarë do të ndodhë.
Shpesh, klientët tanë na bëjnë pyetje të ndryshme në lidhje me replikimin, prandaj, përpara se të kalojmë në konfigurimin dhe testimin e implementimeve të replikave, do të diskutojmë pak për atë që është replikimi në sistemet e ruajtjes së të dhënave.
Pak teori
Replikimi në sistemet e ruajtjes së të dhënave është një proces i vazhdueshëm për të siguruar identitetin e të dhënave në të njëjtën kohë në disa sisteme të ruajtjes. Teknikisht, replikimi kryhet nëpërmjet dy metodave.
Replikimi sinhron – është kopjimi i të dhënave nga sistemi kryesor i ruajtjes në atë rezervë me konfirmimin e detyrueshëm të të dy sistemeve të ruajtjes, që të dhënat janë regjistruar dhe konfirmuar. Vetëm pas konfirmimit nga të dy palët (nga të dy sistemet e ruajtjes) të dhënat konsiderohen të regjistruara dhe mund të përdoren. Kështu sigurohet identiteti i garantuar i të dhënave në të gjithë sistemet e ruajtjes që marrin pjesë në replikim.
Pikat e forta të këtij metodi:
- Të dhënat gjithmonë janë identike në të gjitha sistemet e ruajtjes
Disavantazhet:
- Kosto e lartë e zgjidhjes (kanale të shpejta komunikimi, fibra optike të shtrenjta, transceiver të gjatë dhe të tjera)
- Kufizime në distancë (brenda disa dhjetëra kilometrave)
- Nuk ka mbrojtje nga prishja logjike e të dhënave (nëse të dhënat prishen (me vetëdije ose rastësisht) në sistemin kryesor, ato automatikisht dhe menjëherë do të prishen edhe në rezervat, pasi të dhënat gjithmonë janë identike (ky është paradoksi))
Replikimi asinkron – kjo është gjithashtu kopjimi i të dhënave nga ruajtja kryesore në atë rezervë, por me një vonesë të caktuar dhe pa nevojën për konfirmimin e shkrimit nga ana tjetër. Mund të punohet me të dhënat menjëherë pas shkrimit në ruajtjen kryesore, ndërsa në ruajtjen rezervë të dhënat do të jenë të disponueshme pas një kohe. Identiteti i të dhënave në këtë rast, natyrisht, nuk sigurohet fare. Të dhënat në ruajtjen rezervë gjithmonë ndodhen pak "në të kaluarën".
Avantazhet e replikimit asinkron:
- Kosto e ulët e zgjidhjes (çdo kanal komunikimi, fibra optike është opsionale)
- Nuk ka kufizime në distancë
- Në ruajtjen rezervë të dhënat nuk dëmtohen në rast se ato dëmtohen në atë kryesore (të paktën për një kohë), nëse të dhënat janë prishur, gjithmonë mund të ndalohet replikimi për të mos lejuar dëm në të dhënat në ruajtjen rezervë
Disavantazhet:
- Të dhënat në qendra të ndryshme të të dhënave gjithmonë janë joidentike
Prandaj, zgjedhja e modit të replikimit varet nga detyrat e biznesit. Nëse është thelbësore që në Qendrat e të Dhënave rezervë të jenë të njëjtat të dhëna si në ato kryesore (dmth. kërkesa e biznesit për RPO=0), atëherë do të duhet të investoni dhe të pranoni kufizimet e replikës sinkrone. Nëse ndalesa e gjendjes së të dhënave është e pranueshme ose thjesht nuk keni para, atëherë, pa dyshim, duhet të përdorni metodën asinkrone.
Një mënyrë tjetër që duam të theksojmë është topologjia e metroklaustrit. Në modin e metroklaustrit përdoret replikimi sinkron, por, ndryshe nga replica e zakonshme, metroklaustri lejon të dyja sistemet e ruajtjes të punojnë në mënyrë aktive. Pra, nuk keni ndarje midis Qendrave të të Dhënave aktive dhe rezervë. Aplikacionet funksionojnë njëkohësisht me dy sistemi ruajtjeje, të cilat janë fizikisht të vendosura në Qendra të ndryshme të Të Dhënave. Kohët e ndalesës gjatë fatkeqësive në një topologji të tillë janë shumë të vogla (RTO, zakonisht minuta). Në këtë artikull nuk do të shqyrtojmë realizimin tonë të metroklaustrit, pasi është një temë shumë e madhe dhe e rëndësishme, ndaj do t'i kushtojmë një artikull të veçantë, duke vazhduar nga ky.
Gjithashtu shumë shpesh, kur flasim për replikimin përmes sistemeve të ruajtjes, shumë njerëz kanë një pyetje të arsyeshme: > «Shumë aplikacione kanë mekanizma të tyre për replikim, pse të përdorim replikimin në sistemet e ruajtjes? A është kjo më mirë apo më keq?»
Nuk ka një përgjigje të qartë, prandaj do të paraqesim argumentet PËR dhe KUNDRA:
Argumentet PËR replikimin në sistemet e ruajtjes:
- Thjeshtësia e zgjidhjes. Me një mjet mund të replikoni të gjithë masivin e të dhënave, pa marrë parasysh llojin e ngarkesës dhe aplikacioneve. Nëse përdorni replikimin nga aplikacionet, do t'ju duhet të konfiguroni çdo aplikacion veç e veç. Nëse ka më shumë se 2, kjo bëhet jashtëzakonisht e punës dhe e shtrenjtë (replikimi i aplikacioneve zakonisht kërkon një licencë të veçantë dhe jo falas për çdo aplikacion. Por për këtë më poshtë).
- Mund të replikoni çdo gjë – çfarëdo aplikacionesh, çdo të dhënash – dhe ato gjithmonë do të jenë konsistente. Shumë (shumica) e aplikacioneve nuk kanë mekanizma replikimi dhe replikat nga ana e sistemeve të ruajtjes janë mjeti i vetëm për të siguruar mbrojtje nga katastrofat.
- Nuk keni nevojë të paguani më shumë për funksionalitetin e replikimit të aplikacioneve. Për zakon, ai kushton shtrenjtë, ashtu si licencat për replikën e SHT. Por për licencën e replikimit të SHT-së, duhet të paguani një herë, ndërsa për licencën e replikës së aplikacioneve duhet të blini për çdo aplikacion veç e veç. Nëse ka shumë aplikacione të tilla, kjo bëhet e shtrenjtë dhe kostoja e licencave për replikimin e SHT-së bëhet një pikë në det.
Argumentet PROTI replikimit të SHT-së:
- Replika përmes aplikacioneve ka më shumë funksionalitet nga këndvështrimi i vet aplikacioneve, aplikacioni e njeh më mirë të dhënat e tij (që është e qartë), prandaj ka më shumë opsione për të punuar me to.
- Prodhuesit e disa aplikacioneve nuk garantojnë qëndrueshmërinë e të dhënave të tyre nëse bëhet replikimi me mjete të palëve të treta.*
*- një tezë e diskutueshme. Për shembull, një kompani e njohur prodhuese e DB, shumë gjatë deklaroi zyrtarisht se DB-ja e tyre mund të replikoheshin normalisht vetëm me mjetet e tyre, ndërsa replikimi i mbetur (përfshirë atë të SHT) është "jo i vërtetë". Por jeta tregoi se kjo nuk është e vërtetë. Më shumë se kaq, (por kjo nuk është e sigurt) është thjesht një përpjekje jo shumë e sinqertë për të shitur më shumë licenca klientëve.
Në shumicën e rasteve, replikimi nga STH është më i përshtatshëm, pasi është një opsion më i thjeshtë dhe më ekonomik, por ka raste të komplikuara kur funksionaliteti specifik i aplikacioneve është i nevojshëm dhe duhet të punojmë saktësisht me replikimin në nivelin e aplikacioneve.
Teoria ka përfunduar, tani praktika.
Ne do të konfigurojmë replikimin në laboratorin tonë. Në kushte laboratorike kemi simuluar dy Qendra të Dhënash (në të vërtetë, dy raftet ngjitur që duken si në ndërtesa të ndryshme). Stendi përbëhet nga dy STH Engine N2, të cilat janë të lidhura me kabuj optik. Një server fizik me sistemin operativ Windows Server 2016 është lidhur me të dy STH duke përdorur 10Gb Ethernet. Stendi është mjaft i thjeshtë, por kjo nuk e ndryshon thelbin.
Ai duket kështu:
Logjikisht, replikimi është organizuar si më poshtë:
Tani do të shqyrtojmë funksionalitetet e replikimit që kemi tani.
Përkrahën dy mënyra: asinkrone dhe sinkrone. Është logjike që mënyra sinkrone është e kufizuar nga distanca dhe kanali i komunikimit. Në veçanti, për mënyrën sinkrone kërkohet përdorimi i fibra optike si fizike dhe 10 gigabit Ethernet (ose më shumë).
Distanca e mbështetur për replikimin sinkron është 40 kilometra, me një vonesë të kanaleve optike midis Qendrave të Të Dhënave deri në 2 milisekonda. Në përgjithësi, do të funksionojë edhe me vonesa më të mëdha, por atëherë do të ketë ngadalësime të mëdha gjatë shkarkimit (çka është logjike), prandaj, nëse keni në mendje replikimin sinkron midis Qendrave të Të Dhënave, duhet të kontrolloni cilësinë e optikës dhe vonesat.
Kërkesat për replikimin asinkron nuk janë kaq serioze. Më saktësisht, nuk ka kërkesa fare. Cdo lidhje funksionale përmes Etherneti do të bëjë.
Aktualisht, në ruajtjen AERODISK ENGINE mbështetet replikimi për pajisjet bllok (LUN) përmes protokollit Ethernet (përmes metalit ose optikës). Për projektet ku kërkohet patjetër replikimi përmes fabrikës SAN përmes Fibre Channel, ne po shkruajmë një zgjidhje përkatëse, por për momentin nuk është e gatshme, prandaj në rastin tonë – vetëm Ethernet.
Replikimi mund të funksionojë midis çdo sistemi ruajtjeje të serisë ENGINE (N1, N2, N4) nga sistemet më të ulta në ato më të larta dhe anasjelltas.
Funksionaliteti i të dyja mënyrave të replikimit është plotësisht identik. Më poshtë një përshkrim më i detajuar për atë që ofrohet:
- Replikimi «one to one» ose «një me një», domethënë varianti klasik me dy Qendra të Të Dhënave, kryesore dhe rezervë.
- Replikimi «one to many» ose «një në shumë», pra një LUN mund të riplikohet në disa SAN njëherësh.
- Aktivizimi, deaktivizimi dhe «rrotullimi» i replikimit, përkatësisht për të aktivizuar, çaktivizuar ose për të ndryshuar drejtimin e replikimit.
- Replikimi është i disponueshëm si për grupet e RDG (Raid Distributed Group), ashtu edhe për DDP (Dynamic Disk Pool). Në këtë rast, LUN-i i grupit RDG mund të riplikohet vetëm në një RDG tjetër. Me DDP është e njëjtë.
Ka gjithashtu shumë veçori të tjera të vogla, por nuk ka kuptim të renditësh ato, do t’i përmendim gjatë konfigurimit.
Konfigurimi i replikimit
Procesi i konfigurimit është mjaft i thjeshtë dhe përbëhet nga tre etapa.
- Konfigurimi i rrjetit
- Konfigurimi i ruajtjes
- Konfigurimi i rregullave (lidhuve) dhe maping-ut
Një pikë e rëndësishme e konfigurimit të replikimit është se dy etapat e para duhet të përsëriten në SAN-in e largët, ndërsa etapa e tretë – vetëm në atë kryesor.
Konfigurimi i burimeve rrjetore
Së pari duhet të konfiguroni portet rrjetore, përmes të cilave do të transmetohet trafiku i replikimit. Për këtë, portet duhet të aktivizohen dhe t'u caktohen adresat IP në seksionin Front-end adaptuesit.
Pas kësaj, na nevojitet të krijojmë një pool (në rastin tonë RDG) dhe një IP virtuale për replikim (VIP). VIP është një adresë IP e lëvizshme që është lidhur me dy adresat "fizike" të kontrolluesve të SXY (porteve që sapo e konfiguram). Ajo do të jetë ndërfaqja kryesore e replikimit. Mund të operohet gjithashtu pa VIP, por me VLAN, nëse nevojitet të punojmë me trafik të etiketuar.
Procesi i krijimit të VIP-it për replikën nuk ndryshon shumë nga krijimi i VIP-it për hyrje-dali (NFS, SMB, iSCSI). VIP në këtë rast e krijojmë si zakonisht (pa VLAN), por patjetër duhet të tregojmë se është për replikim (pa këtë tregues nuk do të mund ta shtojmë VIP-in në rregullin në hapin tjetër).
VIP-i duhet patjetër të jetë në të njëjtën nënrrjetë si IP-të e porteve, midis të cilave "zhvillohet".
Përsërisim këto konfigurime në SXY-në e largët, natyrisht me një IP tjetër.
VIP-të nga SXY të ndryshme mund të jenë në nënrrjeta të ndryshme, e rëndësishme është që të ketë routing mes tyre. Në rastin tonë kjo është një shembuj i tillë (192.168.3.XX dhe 192.168.2.XX).
Këtu përfundon përgatitja e pjesës rrjet.
Konfigurojmë magazinat
Konfigurimi i ruajtjes për replikim ndryshon nga ai normal vetëm për faktin se mapimi bëhet përmes menysë speciale "Maping i Replikimit". Ndryshe, gjithçka është si me konfigurimin normal. Tani, me radhë.
Në grupin e krijuar më parë R02, nevojitet të krijojmë LUN. E krijojmë dhe e quajmë LUN1.
Po ashtu, na nevojitet të krijojmë një LUN të ngjashëm në SAN-in e largët me vëllim identik. E krijojmë. Për të shmangur ngatërrimet, LUN-in e largët do ta quajmë LUN1R.
Nëse do të na nevojitej të marrim një LUN që ekziston tashmë, atëherë gjatë konfigurimit të replikas, ky LUN produktiv do të nevojitej të deshtohej nga host-i, dhe në SAN-in e largët duhet thjesht të krijohej një LUN i zbrazët me vëllim identik.
Konfigurimi i ruajtjes është përfunduar, kalojmë në krijimin e rregullit të replikimit.
Konfigurimi i rregullave të replikimit ose lidhjeve të replikimit
Pas krijimit të LUN-ëve në SAN-in që do të jetë aktualisht primar (Primary), konfiguroni rregullin e replikimit LUN1 në SAN1 në LUN1R në SAN2.
Konfigurimi bëhet në menunë "Replikimi i Largët"
Krijojmë një rregull. Për këtë, duhet të specifikoni marrësin e replikës. Aty gjithashtu vendosim emrin e lidhjes dhe llojin e replikimit (sinhron ose asinkron).
Në fushën "sistemet e largëta" shtojmë storage array-në tonë SХД2. Për ta shtuar, nevojiten IP-të menaxhuese të SХД (MGR) dhe emri i LUN-it të largët, në të cilin do të kryejmë replikimin (në rastin tonë LUN1R). IP-të menaxhuese nevojiten vetëm në fazën e shtimit të lidhjes; trafiku i replikimit nuk do të kalojë përmes tyre, për këtë do të përdoret VIP-i i konfiguruar më parë.
Që në këtë fazë, mund të shtojmë më shumë se një sistem të largët për topologjinë "one to many": klikoni në butonin "shto nyjë", siç është paraqitur në figurën më poshtë.
Në rastin tonë, sistemi i largët është një, prandaj e kufizojmë në këtë.
Rregulli është gati. Vini re se ai shtohet automatikisht te të gjithë pjesëmarrësit e replikimit (në rastin tonë ata janë dy). Mund të krijohen sa më shumë rregulla të tilla për çdo numër LUN-esh dhe në çdo drejtim. Për shembull, mund të replikojmë disa LUN-e për balancimin e ngarkesës nga СХД1 në СХД2, dhe disa LUN-e të tjera në të kundërt – nga СХД2 në СХД1.
СХД1. Menjëherë pas krijimit filloi sinkronizimi.
СХД2. Shikojmë të njëjtin rregull, por tashmë ka përfunduar sinkronizimi.
LUN1 në SHT1 është në rolin e Primary, që do të thotë se është aktiv. LUN1R në SHT2 është në rolin e Secondary, që do të thotë se është në pritje për ndihmë në rast të dështimit të SHT1.
Tani mund ta lidhim LUN-in tonë me hostin.
Do ta bëjmë lidhjen përmes iSCSI, megjithatë ka mundësi edhe për FC. Cilësimi i mapimit të LUN-it i replikës është praktikisht i njëjtë me skenarin standard, prandaj nuk do ta shqyrtojmë këtë në detaje. Po të nevojitet, ky proces është përshkruar në artikullin "».
Dallimi i vetëm – krijojmë mapimin në menunë "Mappimi i replikimit"
Krijuam mapimin, ia dhamë LUN-in hostit. Hosti e pa LUN-in.
E formatojmë në sistemin lokal të skedarëve.
Kjo është, në këtë pikë, cilësimi mbaroi. Tani do të fillojnë testet.
Testimi
Ne do të testojmë tre skenarë kryesorë.
- Kalimi normal i roleve Secondary > Primary. Kalimi normal i roleve është në rast se, për shembull, në Qendrën Kryesore të Të Dhënave duhet të kryejmë ndonjë operacion preventiv dhe për këtë kohë, që të dhënat të jenë të aksesueshme, ne transferojmë ngarkesën në Qendrën Rezervë të Të Dhënave.
- Kalimi i rolit të dytë në të parin në rast të dështimit të qendrës së të dhënave (QTD). Ky është skenari kryesor, për të cilin ekziston replikimi, i cili mund të ndihmojë në mbijetimin e një dështimi të plotë të QTD-së pa ndalur funksionimin e kompanisë për një periudhë të gjatë.
- Prishja e kanaleve të komunikimit midis QTD-ve. Kontrollimi i sjelljes së saktë të dy sistemeve të ruajtjes nën kushte ku, për një arsye apo tjetër, kanali i komunikimit midis QTD-ve është i paarritshëm (për shembull, një ekskavator ka gërmuar në vend të gabuar dhe ka prerë optikën e errët).
Për të filluar, ne do të fillojmë të shkruajmë të dhëna në LUN-in tonë (shkruajmë skedarë me të dhëna rastësore). Menjëherë shohim se si po shfrytëzohet kanali i komunikimit midis sistemeve të ruajtjes. Kjo është e lehtë për t'u kuptuar nëse hapim monitorimin e ngarkesës së porteve, të cilat janë përgjegjëse për replikimin.
Tani të dy sistemet e ruajtjes kanë të dhëna "të dobishme", mund të fillojmë testin.
Për çdo rast, le të kontrollojmë hashin e njërit prej skedarëve dhe ta regjistrojmë.
Kalimi normal i rolit
Operacioni i kalimit të rolit (ndryshimi i drejtimit të replikimit) mund të bëhet me çfarëdo sistemi ruajtjeje, por megjithatë do të duhet të shkojmë në të dyja, pasi në Primary do të duhet të shkëputim mapimin, dhe në Secondary (e cila do të bëhet Primary) do të aktivizojmë të njëjtin.
Mund të lindë një pyetje e arsyeshme tani: pse nuk do ta automatizojmë këtë? Përgjigjja është e thjeshtë, replikimi është një mjet i thjeshtë për qëndrushmërinë ndaj katastrofave, që bazohet ekskluzivisht në operacione manuale. Ekziston një modh metroklastri për automatizimin e këtyre operacioneve, i cili është plotësisht i automatizuar, por konfigurimi i tij është shumë më i komplikuar. Do të shkruajmë për konfigurimin e metroklastri në artikullin e ardhshëm.
Në sistemin e ruajtjes kryesore, çaktivizojmë mapimin, për të garantuar ndalimin e regjistrimit.
Pastaj, në një nga sistemet e ruajtjes (nuk ka rëndësi nëse është kryesor ose rezervë), në menunë "Replikimi i Largët", zgjedhim lidhjen tonë REPL1 dhe klikojmë "Ndërro rolin".
Pas disa sekondash, LUN1R (sistemi rezervë) bëhet Primar.
Bëjmë mapimin e LUN1R me SHK2.
Pas kësaj, disku ynë E: automatikisht lidhet në host, vetëm kësaj here ai "erdhi" nga LUN1R.
Për çdo rast, krahasojmë shumën e hash-ëve.
Identikisht. Testi kaloi.
Kalimi i emergjencës. Mungesa e Qendrës së të Dhënave.
Aktualisht, sistemi kryesor pas kalimit normal është SHK2 dhe LUN1R, përkatësisht. Për të imituar një emergjencë, ne do të çaktivizojmë energjinë në të dy kontrollorët e SHK2.
Nuk ka më qasje në të.
Të shohim çfarë po ndodh në SHT 1 (rezervuar deri më tani).
Shohim se Primary LUN (LUN1R) nuk është i aksesueshëm. Ka pasur një mesazh gabimi në regjistrat, në panelin informativ, si dhe në rregullin e replikimit. Në përputhje me këtë, të dhënat nga hosti tani nuk janë të aksesueshme.
Ndryshojmë rolin e LUN1 në Primary.
Bëjmë mapimin në host.
Sigurohemi që disku E të ketë dalë në host.
Kontrollojmë hash-in.
Të gjitha janë në rregull. Rënia e Qendrës së të Dhënave, e cila ishte aktive, SHT e kaloi me sukses. Koha e përafërt që shpenzuam për lidhjen e 'rritjes' së replikimit dhe lidhjen e LUN-it nga Qendra e të Dhënave rezervë ishte rreth 3 minuta. E qartë, në prodhimin real gjithçka është shumë më e komplikuar, dhe përveç veprimeve me SHT duhet të kryhen një sërë operacionesh në rrjet, në hosta, në aplikacione. Dhe në realitet, ky interval kohe do të jetë ndjeshëm më i gjatë.
Këtu dëshiroj të shkruaj që gjithçka, testi u përfundua me sukses, por mos të nxitohemi. SHT kryesore 'po shtrihet', ne e dimë se kur ajo 'ra', ajo ishte në rolinin Primary. Çfarë do të ndodhë nëse ajo ngjason aktivizohet papritur? Do të ketë dy rolina Primary, që është e barabartë me prishjen e të dhënave? Tani do të kontrollojmë.
Shkoi papritur për të aktivizuar SHT-në që po shtrihet.
Ajo ngarkohet për disa minuta dhe pastaj rikthehet në sistem pas një sinkronizimi të shkurtër, por tashmë në rolin e Dytë.
Gjithçka është në rregull. Nuk ndodhi ndarje e mendjes. Ne menduam për këtë, dhe gjithmonë pas rënies së SÇD-së, ajo ngrihet në rolin e Dytë, pavarësisht se në cilin rol ishte "gjatësisht". Tani me siguri mund të themi se testi për dështimin e Qendrës të të Dhënave kaloi me sukses.
Dështimi i kanaleve të komunikimit midis Qendrave të të Dhënave
Objektivi kryesor i këtij testi është të sigurohemi që SÇD-ja nuk do të fillojë të bjerë në çështje, nëse përkohësisht humbasin kanalet e komunikimit midis dy SÇD-ve, dhe pastaj të rikthehen.
Pra. Ne çaktivizojmë kabllot midis SÇD-ve (le të imagjinojmë se i gërmoi një ekskavator).
Në Primar shohim se nuk ka lidhje me Dytorin.
Në Dytorin shohim se nuk ka lidhje me Primarin.
Gjithçka funksionon normalisht, dhe ne vazhdojmë të shkruajmë të dhënat në SÇD-në kryesore, domethënë, ato tashmë ndahen nga rezerva, pra janë "prishur".
Pas disa minutash "riaktivizojmë" kanalit të komunikimit. Sa herë që SÇD-të kanë parë njëra-tjetrën, sinkronizimi i të dhënave aktivizohet automatikisht. Këtu nga administratori nuk kërkohet asgjë.
Pas një kohe, sinkronizimi përfundon.
Koneksioni është rikthyer, nuk ka pasur situata të jashtzakonshme që shkaktuan prishjen e kanaleve të komunikimit, dhe pas aktivizimit është kryer automatikisht sinkronizimi.
Përfundimet
Ne përmbyllëm teorinë – çfarë dhe përse është e nevojshme, ku janë përfitimet dhe ku janë disavantazhet. Më pas, konfiguruan replikimin sinkron mes dy SHT.
Më pas u zhvilluan testet kryesore për kalimin normal, dështimin e Qendrës së të Dhënave dhe prishjen e kanaleve të komunikimit. Në të gjitha rastet, SHT punoi mirë. Nuk ka pasur humbje të të dhënave, operacionet administrative u minimizuan për skenarin manual.
Të nesërmen do ta komplikohet situatën dhe do tregojmë se si funksionon e gjithë kjo logjikë brenda një metrokastri në mënyrën aktive-aktive, dmth kur të dy SHT janë kryesore dhe sjellja gjatë dështimeve është plotësisht automatizuar.
Ju lutemi shkruani komente, do jemi të lumtur për kritika të arsyeshme dhe këshilla të dobishme.
Në takime të reja.
Burimi: habr.com
