Përshëndetje, lexues të Habrit! Tema e këtij artikulli do të jetë zbatimi i mjeteve të rimëkëmbjes nga fatkeqësitë në sistemet e ruajtjes së motorit AERODISK. Fillimisht, ne donim të shkruanim në një artikull për të dy mjetet: replikimin dhe metrocluster, por, për fat të keq, artikulli doli të ishte shumë i gjatë, kështu që e ndamë artikullin në dy pjesë. Le të kalojmë nga e thjeshta në komplekse. Në këtë artikull, ne do të vendosim dhe testojmë përsëritjen sinkron - do të heqim një qendër të dhënash, dhe gjithashtu do të thyejmë kanalin e komunikimit midis qendrave të të dhënave dhe do të shohim se çfarë ndodh.
Klientët tanë shpesh na bëjnë pyetje të ndryshme rreth replikimit, kështu që përpara se të kalojmë në konfigurimin dhe testimin e zbatimit të kopjeve, ne do t'ju tregojmë pak se çfarë është replikimi në ruajtje.
Pak teori
Replikimi në sistemet e ruajtjes është një proces i vazhdueshëm i sigurimit të identitetit të të dhënave në disa sisteme ruajtjeje njëkohësisht. Teknikisht, përsëritja realizohet në dy mënyra.
Replikimi sinkron – ky është kopjimi i të dhënave nga sistemi kryesor i ruajtjes në atë rezervë, i ndjekur nga konfirmimi i detyrueshëm nga të dy sistemet e ruajtjes që të dhënat janë regjistruar dhe konfirmuar. Është pas konfirmimit nga të dyja anët (të dy sistemet e ruajtjes) që të dhënat konsiderohen të regjistruara dhe mund të punohen me to. Kjo siguron identitetin e garantuar të të dhënave në të gjitha sistemet e ruajtjes që marrin pjesë në kopje.
Përparësitë e kësaj metode:
- Të dhënat janë gjithmonë identike në të gjitha sistemet e ruajtjes
Cons:
- Kostoja e lartë e zgjidhjes (kanalet e komunikimit të shpejtë, fibra optike e shtrenjtë, marrës me valë të gjata, etj.)
- Kufizimet në distancë (brenda disa dhjetëra kilometrash)
- Nuk ka mbrojtje kundër korrupsionit logjik të të dhënave (nëse të dhënat janë të dëmtuara (qëllimisht ose aksidentalisht) në sistemin kryesor të ruajtjes, ato do të korruptohen automatikisht dhe menjëherë në atë rezervë, pasi të dhënat janë gjithmonë identike (ky është paradoksi)
Replikimi asinkron – kjo është edhe kopjimi i të dhënave nga sistemi kryesor i ruajtjes në atë rezervë, por me një vonesë të caktuar dhe pa nevojën e konfirmimit të shkrimit në anën tjetër. Mund të punoni me të dhënat menjëherë pasi t'i regjistroni ato në sistemin kryesor të ruajtjes, dhe në sistemin e ruajtjes rezervë të dhënat do të jenë të disponueshme pas ca kohësh. Identiteti i të dhënave në këtë rast, natyrisht, nuk sigurohet fare. Të dhënat në sistemin e ruajtjes rezervë janë gjithmonë pak "në të kaluarën".
Përparësitë e replikimit asinkron:
- Zgjidhje me kosto të ulët (çdo kanal komunikimi, optika opsionale)
- Nuk ka kufizime në distancë
- Në sistemin e ruajtjes rezervë, të dhënat nuk përkeqësohen nëse dëmtohen në atë kryesor (të paktën për ca kohë); nëse të dhënat dëmtohen, gjithmonë mund ta ndaloni kopjen për të parandaluar prishjen e të dhënave në sistemin e ruajtjes rezervë
Cons:
- Të dhënat në qendra të ndryshme të të dhënave nuk janë gjithmonë identike
Kështu, zgjedhja e mënyrës së përsëritjes varet nga objektivat e biznesit. Nëse është e rëndësishme për ju që qendra e të dhënave rezervë të përmbajë saktësisht të njëjtat të dhëna si qendra kryesore e të dhënave (d.m.th., kërkesa e biznesit për RPO = 0), atëherë do t'ju duhet të shpenzoni paratë dhe të përballoni kufizimet e një sinkroni kopje. Dhe nëse vonesa në gjendjen e të dhënave është e pranueshme ose thjesht nuk ka para, atëherë patjetër që duhet të përdorni metodën asinkrone.
Le të theksojmë veçmas një mënyrë të tillë (më saktë, një topologji) si një metrokluster. Në modalitetin metrokluster, përdoret replikimi sinkron, por, ndryshe nga një kopje e zakonshme, një metrokluster lejon që të dy sistemet e ruajtjes të funksionojnë në modalitetin aktiv. Ato. ju nuk keni një ndarje midis qendrave të të dhënave aktive dhe të gatishmërisë. Aplikacionet funksionojnë njëkohësisht me dy sisteme ruajtjeje, të cilat ndodhen fizikisht në qendra të ndryshme të të dhënave. Kohët e ndërprerjes gjatë aksidenteve në një topologji të tillë janë shumë të vogla (RTO, zakonisht minuta). Në këtë artikull ne nuk do të shqyrtojmë zbatimin tonë të metroklusterit, pasi kjo është një temë shumë e madhe dhe e gjerë, kështu që ne do t'i kushtojmë një artikull të veçantë, të ardhshëm, në vazhdim të këtij.
Gjithashtu, shumë shpesh, kur flasim për riprodhimin duke përdorur sistemet e ruajtjes, shumë njerëz kanë një pyetje të arsyeshme: > “Shumë aplikacione kanë mjetet e tyre të riprodhimit, pse të përdorim replikimin në sistemet e ruajtjes? A është më mirë apo më keq?
Nuk ka asnjë përgjigje të qartë këtu, kështu që këtu janë argumentet PER dhe KUNDËR:
Argumentet PËR replikimin e ruajtjes:
- Thjeshtësia e zgjidhjes. Me një mjet, ju mund të përsërisni të gjithë grupin tuaj të të dhënave, pavarësisht nga lloji i ngarkesës dhe aplikimi. Nëse përdorni një kopje nga aplikacionet, do t'ju duhet të konfiguroni secilin aplikacion veç e veç. Nëse ka më shumë se 2 prej tyre, atëherë kjo është jashtëzakonisht punë intensive dhe e shtrenjtë (përsëritja e aplikacionit zakonisht kërkon një licencë të veçantë dhe jo falas për secilin aplikacion. Por më shumë për këtë më poshtë).
- Ju mund të përsërisni çdo gjë - çdo aplikacion, çdo të dhënë - dhe ajo do të jetë gjithmonë e qëndrueshme. Shumë (shumica) aplikacione nuk kanë aftësi riprodhimi, dhe kopjet nga sistemi i ruajtjes janë mënyra e vetme për të siguruar mbrojtje nga fatkeqësitë.
- Nuk ka nevojë të paguani shumë për funksionalitetin e riprodhimit të aplikacionit. Si rregull, nuk është i lirë, ashtu si licencat për një kopje të sistemit të ruajtjes. Por ju duhet të paguani për një licencë për riprodhimin e ruajtjes një herë, dhe një licencë për kopjen e aplikacionit duhet të blihet për secilin aplikacion veç e veç. Nëse ka shumë aplikacione të tilla, atëherë kushton një qindarkë goxha dhe kostoja e licencave për përsëritjen e ruajtjes bëhet një pikë në kovë.
Argumentet KUNDËR replikimit të ruajtjes:
- Replica përmes aplikacioneve ka më shumë funksionalitet nga pikëpamja e vetë aplikacioneve, aplikacioni i njeh më mirë të dhënat e tij (natyrisht), kështu që 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 riprodhimi bëhet duke përdorur mjete të palëve të treta. *
* - tezë e diskutueshme. Për shembull, një prodhues i mirënjohur DBMS ka deklaruar zyrtarisht për një kohë shumë të gjatë se DBMS-ja e tyre mund të riprodhohet normalisht vetëm duke përdorur mjetet e tyre, dhe pjesa tjetër e përsëritjes (përfshirë sistemet e ruajtjes) "nuk është e vërtetë". Por jeta ka treguar se nuk është kështu. Me shumë mundësi (por kjo nuk është e sigurt) kjo nuk është thjesht përpjekja më e ndershme për t'u shitur më shumë licenca klientëve.
Si rezultat, në shumicën e rasteve, përsëritja nga sistemi i ruajtjes është më i mirë, sepse Ky është një opsion më i thjeshtë dhe më pak i kushtueshëm, por ka raste komplekse kur nevojiten funksionalitete specifike të aplikacionit dhe është e nevojshme të punohet me përsëritjen e nivelit të aplikacionit.
Mbaroi me teorinë, tani praktikë
Ne do të konfigurojmë kopjen në laboratorin tonë. Në kushte laboratorike, ne emuluam dy qendra të dhënash (në fakt, dy rafte ngjitur që dukej se ishin në ndërtesa të ndryshme). Stenda përbëhet nga dy sisteme magazinimi të motorit N2, të cilët lidhen me njëri-tjetrin me kabllo optike. Një server fizik që ekzekuton Windows Server 2016 është i lidhur me të dy sistemet e ruajtjes duke përdorur 10 Gb Ethernet. Qëndrimi është mjaft i thjeshtë, por kjo nuk e ndryshon thelbin.
Skematikisht duket kështu:
Logjikisht, replikimi organizohet si më poshtë:
Tani le të shohim funksionalitetin e riprodhimit që kemi tani.
Dy mënyra mbështeten: asinkron dhe sinkron. Është logjike që modaliteti sinkron të kufizohet nga distanca dhe kanali i komunikimit. Në veçanti, modaliteti sinkron kërkon përdorimin e fibrave si fizikë dhe 10 Gigabit Ethernet (ose më të lartë).
Distanca e mbështetur për riprodhimin sinkron është 40 kilometra, vlera e vonesës së kanalit optik midis qendrave të të dhënave është deri në 2 milisekonda. Në përgjithësi, do të funksionojë me vonesa të mëdha, por më pas do të ketë ngadalësime të forta gjatë regjistrimit (gjë që është edhe logjike), kështu që nëse planifikoni replikim 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ë aq serioze. Më saktësisht, ata nuk janë fare aty. Do të funksionojë çdo lidhje Ethernet.
Aktualisht, sistemi i ruajtjes AERODISK ENGINE mbështet riprodhimin për pajisjet e bllokut (LUN) nëpërmjet protokollit Ethernet (mbi bakër ose optik). Për projektet ku kërkohet riprodhimi përmes një pëlhure SAN mbi Fiber Channel, aktualisht po shtojmë një zgjidhje të përshtatshme, por ajo nuk është ende gati, kështu që në rastin tonë, vetëm Ethernet.
Përsëritja mund të funksionojë midis çdo sistemi magazinimi të serisë MOTORRI (N1, N2, N4) nga sistemet e reja te ato më të vjetra dhe anasjelltas.
Funksionaliteti i të dy mënyrave të përsëritjes është plotësisht identik. Më poshtë janë më shumë detaje rreth asaj që është në dispozicion:
- Përsëritja "një me një" ose "një me një", domethënë versioni klasik me dy qendra të dhënash, kryesore dhe rezervë
- Replikimi është "një për shumë" ose "një për shumë", d.m.th. një LUN mund të përsëritet në disa sisteme ruajtjeje në të njëjtën kohë
- Aktivizoni, çaktivizoni dhe "ndërsoni" replikimin, përkatësisht, për të aktivizuar, çaktivizuar ose ndryshuar drejtimin e përsëritjes
- Replikimi është i disponueshëm si për grupet RDG (Raid Distributed Group) ashtu edhe për DDP (Dynamic Disk Pool). Megjithatë, LUN-et e një grupi RDG mund të riprodhohen vetëm në një tjetër RDG. E njëjta gjë me DDP.
Ka shumë më tepër veçori të vogla, por nuk ka kuptim të veçantë t'i renditim ato; ne do t'i përmendim ato ndërsa vendosim.
Vendosja e replikimit
Procesi i konfigurimit është mjaft i thjeshtë dhe përbëhet nga tre faza.
- Konfigurimi i rrjetit
- Konfigurimi i hapësirës ruajtëse
- Vendosja e rregullave (lidhjeve) dhe hartëzimi
Një pikë e rëndësishme në vendosjen e përsëritjes është që dy fazat e para duhet të përsëriten në sistemin e ruajtjes në distancë, faza e tretë - vetëm në atë kryesore.
Vendosja e burimeve të rrjetit
Hapi i parë është konfigurimi i portave të rrjetit përmes të cilave do të transmetohet trafiku i replikimit. Për ta bërë këtë, duhet të aktivizoni portet dhe të vendosni adresat e tyre IP në seksionin e përshtatësve të përparme.
Pas kësaj, ne duhet të krijojmë një grup (në rastin tonë RDG) dhe një IP virtuale për replikim (VIP). VIP është një adresë IP lundruese që është e lidhur me dy adresa "fizike" të kontrollorëve të ruajtjes (portet që sapo konfiguruam). Kjo do të jetë ndërfaqja kryesore e riprodhimit. Ju gjithashtu mund të operoni jo me një VIP, por me një VLAN, nëse keni nevojë të punoni me trafik të etiketuar.
Procesi i krijimit të një VIP për një kopje nuk është shumë i ndryshëm nga krijimi i një VIP për I/O (NFS, SMB, iSCSI). Në këtë rast, ne krijojmë një VIP të rregullt (pa VLAN), por sigurohuni që të tregojmë se është për replikim (pa këtë tregues nuk do të mund të shtojmë VIP në rregull në hapin tjetër).
VIP-i duhet të jetë në të njëjtin nën-rrjet si portat IP ndërmjet të cilave qarkullon.
Ne i përsërisim këto cilësime në një sistem ruajtjeje në distancë, sigurisht me një IP të ndryshme.
VIP-at nga sisteme të ndryshme ruajtjeje mund të jenë në nënrrjeta të ndryshme, gjëja kryesore është se ka rrugëzim midis tyre. Në rastin tonë, ky shembull është treguar saktësisht (192.168.3.XX dhe 192.168.2.XX)
Kjo përfundon përgatitjen e pjesës së rrjetit.
Konfigurimi i hapësirës ruajtëse
Vendosja e ruajtjes për një kopje ndryshon nga zakonisht vetëm në atë që ne bëjmë hartën përmes një menyje të veçantë "Replication Mapping". Përndryshe, gjithçka është njësoj si me konfigurimin normal. Tani, në rregull.
Në grupin e krijuar më parë R02, duhet të krijoni një LUN. Le ta krijojmë dhe ta quajmë LUN1.
Ne gjithashtu duhet të krijojmë të njëjtin LUN në një sistem ruajtjeje në distancë me madhësi identike. Ne krijojmë. Për të shmangur konfuzionin, le ta quajmë telekomandën LUN LUN1R
Nëse do të na duhej të merrnim një LUN që ekziston tashmë, atëherë gjatë konfigurimit të kopjes, do të na duhej ta çmontojmë këtë LUN produktiv nga hosti dhe thjesht të krijonim një LUN bosh me madhësi identike në sistemin e ruajtjes në distancë.
Konfigurimi i ruajtjes ka përfunduar, le të kalojmë në krijimin e një rregulli të përsëritjes.
Vendosja e rregullave të përsëritjes ose lidhjeve të përsëritjes
Pas krijimit të LUN-ve në sistemin e ruajtjes, i cili do të jetë ai kryesor për momentin, ne konfigurojmë rregullin e riprodhimit LUN1 në sistemin e ruajtjes 1 në LUN1R në sistemin e ruajtjes 2.
Cilësimi bëhet në menynë "Replikimi në distancë".
Le të krijojmë një rregull. Për ta bërë këtë, duhet të specifikoni marrësin e kopjes. Aty vendosim edhe emrin e lidhjes dhe llojin e replikimit (sinkron ose asinkron).
Në fushën “sistemet në distancë” shtojmë sistemin tonë të ruajtjes2. Për të shtuar, duhet të përdorni sistemet e ruajtjes së IP të menaxhimit (MGR) dhe emrin e LUN të largët në të cilin do të kryejmë replikimin (në rastin tonë, LUN1R). IP-të e kontrollit nevojiten vetëm në fazën e shtimit të një lidhjeje; trafiku i riprodhimit nuk do të transmetohet përmes tyre; VIP-ja e konfiguruar më parë do të përdoret për këtë.
Tashmë në këtë fazë mund të shtojmë më shumë se një sistem në distancë për topologjinë “një tek shumë”: klikoni butonin “shto nyjen”, si në figurën më poshtë.
Në rastin tonë, ekziston vetëm një sistem në distancë, kështu që ne kufizohemi në këtë.
Rregulli është gati. Ju lutemi vini re se ai shtohet automatikisht në të gjithë pjesëmarrësit e përsëritjes (në rastin tonë ka dy prej tyre). Ju mund të krijoni sa më shumë rregulla të tilla që dëshironi, për çdo numër LUN dhe në çdo drejtim. Për shembull, për të balancuar ngarkesën, ne mund të përsërisim një pjesë të LUN-ve nga sistemi i ruajtjes 1 në sistemin e ruajtjes 2, dhe një pjesë tjetër, përkundrazi, nga sistemi i ruajtjes 2 në sistemin e ruajtjes 1.
Sistemi i ruajtjes 1. Menjëherë pas krijimit filloi sinkronizimi.
Sistemi i ruajtjes 2. Ne shohim të njëjtin rregull, por sinkronizimi tashmë ka përfunduar.
LUN1 në sistemin e ruajtjes 1 është në rolin Primar, domethënë është aktiv. LUN1R në sistemin e ruajtjes 2 është në rolin e Sekondarit, domethënë është në gatishmëri në rast se sistemi i ruajtjes 1 dështon.
Tani mund ta lidhim LUN-in tonë me hostin.
Ne do të lidhemi përmes iSCSI, megjithëse mund të bëhet edhe përmes FC. Vendosja e hartës përmes iSCSI LUN në një kopje praktikisht nuk ndryshon nga skenari i zakonshëm, kështu që ne nuk do ta shqyrtojmë këtë në detaje këtu. Nëse ka ndonjë gjë, ky proces përshkruhet në artikullin "'.
Dallimi i vetëm është se ne krijojmë hartën në menynë "Replication Mapping".
Ne vendosëm hartën dhe ia dhamë LUN hostit. Pritësi pa LUN.
Ne e formatojmë atë në një sistem skedari lokal.
Kjo është e gjitha, konfigurimi ka përfunduar. Testet do të vijnë më pas.
Testimi
Ne do të testojmë tre skenarë kryesorë.
- Ndërrimi i rregullt i roleve Sekondar > Primar. Ndërrimi i rregullt i roleve nevojitet në rast se, për shembull, duhet të kryejmë disa operacione parandaluese në qendrën kryesore të të dhënave dhe gjatë kësaj kohe, në mënyrë që të dhënat të jenë të disponueshme, transferojmë ngarkesën në qendrën e të dhënave rezervë.
- Ndërrimi i roleve emergjente Sekondar > Primar (dështimi i qendrës së të dhënave). Ky është skenari kryesor për të cilin ekziston riprodhimi, i cili mund të ndihmojë të mbijetojë një dështim të plotë të qendrës së të dhënave pa e ndaluar kompaninë për një periudhë të gjatë.
- Ndarja e kanaleve të komunikimit ndërmjet qendrave të të dhënave. Kontrollimi i sjelljes së saktë të dy sistemeve të ruajtjes në kushte kur për ndonjë arsye kanali i komunikimit midis qendrave të të dhënave nuk është i disponueshëm (për shembull, një ekskavator ka gërmuar në vendin e gabuar dhe ka thyer optikën e errët).
Së pari, ne do të fillojmë të shkruajmë të dhëna në LUN tonë (shkrimi i skedarëve me të dhëna të rastësishme). Menjëherë shohim se po shfrytëzohet kanali i komunikimit ndërmjet sistemeve të ruajtjes. Kjo është e lehtë për t'u kuptuar nëse hapni monitorimin e ngarkesës së porteve që janë përgjegjëse për përsëritjen.
Të dy sistemet e ruajtjes tani kanë të dhëna "të dobishme", ne mund të fillojmë testin.
Për çdo rast, le të shohim shumat hash të një prej skedarëve dhe t'i shkruajmë ato.
Ndërrimi i rregullt i roleve
Funksionimi i ndërrimit të roleve (ndryshimi i drejtimit të replikimit) mund të bëhet me çdo sistem ruajtjeje, por do t'ju duhet të shkoni te të dy, pasi do t'ju duhet të çaktivizoni hartën në Primary dhe ta aktivizoni atë në Sekondar (i cili do të bëhet Primar ).
Ndoshta tani lind një pyetje e arsyeshme: pse të mos e automatizoni këtë? Përgjigja është: është e thjeshtë, përsëritja është një mjet i thjeshtë i qëndrueshmërisë ndaj fatkeqësive, bazuar vetëm në operacionet manuale. Për të automatizuar këto operacione, ekziston një modalitet metrokluster; ai është plotësisht i automatizuar, por konfigurimi i tij është shumë më i ndërlikuar. Ne do të shkruajmë për ngritjen e një metrocluster në artikullin vijues.
Në sistemin kryesor të ruajtjes, ne çaktivizojmë hartën për të siguruar që regjistrimi të ndalojë.
Pastaj në një nga sistemet e ruajtjes (nuk ka rëndësi, në atë kryesor ose rezervë) në menunë "Remote Replication", zgjidhni lidhjen tonë REPL1 dhe klikoni "Ndrysho rolin".
Pas disa sekondash, LUN1R (sistemi i ruajtjes rezervë) bëhet Primar.
Ne hartojmë LUN1R me sistemin e ruajtjes2.
Pas kësaj, disku ynë E: i bashkëngjitet hostit automatikisht, vetëm këtë herë ai "mbërriti" nga LUN1R.
Për çdo rast, ne krahasojmë shumat hash.
Në mënyrë identike. Testi i kaluar.
Failover. Dështimi i qendrës së të dhënave
Për momentin, sistemi kryesor i ruajtjes pas ndërrimit të rregullt është sistemi i ruajtjes 2 dhe LUN1R, përkatësisht. Për të imituar një aksident, ne do të fikim fuqinë në të dy kontrollorët e ruajtjes2.
Nuk ka më akses në të.
Le të shohim se çfarë po ndodh në sistemin e ruajtjes 1 (ai rezervë për momentin).
Ne shohim që LUN Primar (LUN1R) nuk është i disponueshëm. Një mesazh gabimi u shfaq në regjistrat, në panelin e informacionit dhe gjithashtu në vetë rregullin e përsëritjes. Prandaj, të dhënat nga hosti nuk janë aktualisht të disponueshme.
Ndrysho rolin e LUN1 në Primar.
Unë jam duke bërë hartën për hostin.
Sigurohuni që disku E të shfaqet në host.
Ne kontrollojmë hash.
Cdo gje eshte ne rregull. Sistemi i ruajtjes i mbijetoi me sukses rënies së qendrës së të dhënave, e cila ishte aktive. Koha e përafërt që kaluam për lidhjen e "kthimit" të replikimit dhe lidhjen e LUN nga qendra e të dhënave rezervë ishte rreth 3 minuta. Është e qartë se në prodhimin real gjithçka është shumë më e ndërlikuar, dhe përveç veprimeve me sistemet e ruajtjes, ju duhet të kryeni shumë më tepër operacione në rrjet, në host, në aplikacione. Dhe në jetë kjo periudhë kohore do të jetë shumë më e gjatë.
Këtu dua të shkruaj se gjithçka, testi ka përfunduar me sukses, por le të mos nxitojmë. Sistemi kryesor i ruajtjes është "gënjeshtra", ne e dimë se kur "ra", ishte në rolin Primar. Çfarë ndodh nëse ndizet papritmas? Do të ketë dy role parësore, që është e barabartë me korrupsionin e të dhënave? Le ta kontrollojmë tani.
Le të aktivizojmë papritmas sistemin themelor të ruajtjes.
Ngarkohet për disa minuta dhe më pas kthehet në shërbim pas një sinkronizimi të shkurtër, por në rolin e Sekondarit.
Gjithçka në rregull. Ndarja e trurit nuk ndodhi. Ne menduam për këtë, dhe gjithmonë pas një rënie sistemi i ruajtjes ngrihet në rolin e Sekondarit, pavarësisht se çfarë roli kishte në "gjatë jetës". Tani mund të themi me siguri se testi i dështimit të qendrës së të dhënave ishte i suksesshëm.
Dështimi i kanaleve të komunikimit ndërmjet qendrave të të dhënave
Detyra kryesore e këtij testi është të sigurohet që sistemi i ruajtjes të mos fillojë të veprojë çuditshëm nëse humbet përkohësisht kanalet e komunikimit midis dy sistemeve të ruajtjes dhe më pas shfaqet përsëri.
Kështu që. Ne shkëputim telat midis sistemeve të ruajtjes (le të imagjinojmë se ato janë gërmuar nga një ekskavator).
Në Primar shohim se nuk ka asnjë lidhje me Sekondarin.
Në Sekondarin shohim se nuk ka asnjë lidhje me Primar.
Gjithçka funksionon mirë, dhe ne vazhdojmë të shkruajmë të dhëna në sistemin kryesor të ruajtjes, d.m.th., ato janë të garantuara të jenë të ndryshme nga ajo rezervë, domethënë ato janë "të ndara".
Në pak minuta ne "riparojmë" kanalin e komunikimit. Sapo sistemet e ruajtjes shohin njëri-tjetrin, sinkronizimi i të dhënave aktivizohet automatikisht. Asgjë nuk kërkohet nga administratori këtu.
Pas ca kohësh, sinkronizimi përfundon.
Lidhja u rivendos, humbja e kanaleve të komunikimit nuk shkaktoi asnjë situatë emergjente dhe pas ndezjes u bë automatikisht sinkronizimi.
Gjetjet
Ne analizuam teorinë - çfarë është e nevojshme dhe pse, ku janë të mirat dhe ku janë të këqijat. Më pas vendosim replikimin sinkron midis dy sistemeve të ruajtjes.
Më pas, u kryen teste bazë për kalimin normal, dështimin e qendrës së të dhënave dhe dështimin e kanalit të komunikimit. Në të gjitha rastet, sistemi i ruajtjes funksionoi mirë. Nuk ka humbje të të dhënave dhe operacionet administrative janë mbajtur në minimum për një skenar manual.
Herën tjetër do ta komplikojmë situatën dhe do të tregojmë se si funksionon e gjithë kjo logjikë në një metrokluster të automatizuar në modalitetin aktiv-aktive, domethënë kur të dy sistemet e ruajtjes janë parësore dhe sjellja në rast të dështimeve të sistemit të ruajtjes është plotësisht e automatizuar.
Ju lutemi shkruani komente, do të jemi të lumtur të marrim kritika të shëndosha dhe këshilla praktike.
Deri herën tjetër.
Burimi: www.habr.com