🥇Injini ya AERODISK: Upinzani wa majanga. Sehemu ya 1

Habari, wasomaji wa Habr! Mada ya makala hii itakuwa utekelezaji wa zana za kurejesha maafa katika mifumo ya hifadhi ya AERODISK Injini. Hapo awali, tulitaka kuandika katika makala moja kuhusu zana zote mbili: replication na metrocluster, lakini, kwa bahati mbaya, makala hiyo iligeuka kuwa ndefu sana, kwa hiyo tuligawanya makala hiyo katika sehemu mbili. Wacha tuende kutoka rahisi hadi ngumu. Katika makala hii, tutaweka na kupima replication synchronous - tutaacha kituo kimoja cha data, na pia kuvunja njia ya mawasiliano kati ya vituo vya data na kuona nini kinatokea.

Wateja wetu mara nyingi hutuuliza maswali mbalimbali kuhusu urudufishaji, kwa hivyo kabla ya kuendelea na kusanidi na kujaribu utekelezaji wa nakala, tutakuambia kidogo juu ya jinsi urudufishaji katika uhifadhi ni.

Nadharia kidogo

Uigaji katika mifumo ya hifadhi ni mchakato endelevu wa kuhakikisha utambulisho wa data kwenye mifumo kadhaa ya hifadhi kwa wakati mmoja. Kitaalam, kurudia kunatimizwa kwa njia mbili.

Urudufishaji wa usawazishaji - hii ni kunakili data kutoka kwa mfumo mkuu wa kuhifadhi hadi ule wa chelezo, ikifuatiwa na uthibitisho wa lazima kutoka kwa mifumo yote miwili ya uhifadhi kwamba data imerekodiwa na kuthibitishwa. Ni baada ya uthibitisho kwa pande zote mbili (mifumo yote miwili ya uhifadhi) ambayo data inachukuliwa kuwa kumbukumbu na inaweza kufanyiwa kazi. Hii inahakikisha utambulisho wa data uliohakikishwa kwenye mifumo yote ya hifadhi inayoshiriki katika nakala.

Faida za njia hii:

Data inafanana kila wakati kwenye mifumo yote ya hifadhi

Minus:

Gharama kubwa ya suluhisho (njia za mawasiliano ya haraka, nyuzi za macho za gharama kubwa, transceivers za mawimbi marefu, n.k.)
Vizuizi vya umbali (ndani ya makumi kadhaa ya kilomita)
Hakuna ulinzi dhidi ya upotovu wa data wa kimantiki (ikiwa data imepotoshwa (kwa makusudi au kwa bahati mbaya) kwenye mfumo mkuu wa hifadhi, itaharibika kiotomatiki na papo hapo kwenye chelezo, kwa kuwa data inafanana kila wakati (hicho ndicho kitendawili)

Urudufu wa Asynchronous - hii pia ni kunakili data kutoka kwa mfumo mkuu wa uhifadhi hadi kwa chelezo, lakini kwa kucheleweshwa fulani na bila hitaji la kudhibitisha maandishi kwa upande mwingine. Unaweza kufanya kazi na data mara baada ya kurekodi kwenye mfumo mkuu wa hifadhi, na kwenye mfumo wa hifadhi ya hifadhi data itapatikana baada ya muda fulani. Utambulisho wa data katika kesi hii, bila shaka, haijahakikishwa hata kidogo. Data kwenye mfumo wa kuhifadhi chelezo huwa kidogo "zamani."

Faida za urudufishaji wa asynchronous:

Suluhisho la gharama ya chini (njia zozote za mawasiliano, optics hiari)
Hakuna vikwazo vya umbali
Kwenye mfumo wa uhifadhi wa chelezo, data haiharibiki ikiwa imeharibiwa kwenye ule kuu (angalau kwa muda fulani); ikiwa data itaharibika, unaweza kusimamisha nakala ili kuzuia uharibifu wa data kwenye mfumo wa hifadhi rudufu.

Minus:

Data katika vituo tofauti vya data sio sawa kila wakati

Kwa hivyo, uchaguzi wa njia ya kurudia inategemea malengo ya biashara. Ikiwa ni muhimu kwako kwamba kituo cha data chelezo kina data sawa na kituo kikuu cha data (yaani, hitaji la biashara la RPO = 0), basi itabidi utoe pesa taslimu na uweke vikwazo vya usawazishaji. nakala. Na ikiwa ucheleweshaji wa hali ya data unakubalika au hakuna pesa tu, basi hakika unahitaji kutumia njia ya asynchronous.

Wacha pia tuangazie kando hali kama hiyo (kwa usahihi zaidi, topolojia) kama kikundi cha metro. Katika hali ya metrocluster, urudiaji wa kisawazishaji hutumiwa, lakini, tofauti na nakala ya kawaida, kikundi cha metro huruhusu mifumo yote ya uhifadhi kufanya kazi katika hali amilifu. Wale. huna utengano kati ya vituo vya data vinavyotumika na vya kusubiri. Maombi hufanya kazi kwa wakati mmoja na mifumo miwili ya uhifadhi, ambayo iko katika vituo tofauti vya data. Wakati wa kupumzika wakati wa ajali katika topolojia hiyo ni ndogo sana (RTO, kwa kawaida dakika). Katika makala hii hatutazingatia utekelezaji wetu wa metrocluster, kwa kuwa hii ni mada kubwa sana na yenye uwezo, kwa hivyo tutatoa nakala tofauti, inayofuata kwake, kwa kuendelea na hii.

Pia, mara nyingi sana, tunapozungumza kuhusu urudufishaji kwa kutumia mifumo ya hifadhi, watu wengi wana swali linalofaa: > “Programu nyingi zina zana zao za urudufishaji, kwa nini utumie urudufishaji kwenye mifumo ya hifadhi? Je, ni bora au mbaya zaidi?

Hakuna jibu wazi hapa, kwa hivyo hapa kuna hoja za FOR na CONS:

Hoja ZA urudufishaji wa uhifadhi:

Urahisi wa suluhisho. Ukiwa na zana moja, unaweza kunakili seti yako yote ya data, bila kujali aina ya upakiaji na programu. Ikiwa unatumia nakala kutoka kwa programu, itabidi usanidi kila programu kivyake. Ikiwa kuna zaidi ya 2 kati yao, basi hii ni kazi kubwa sana na ya gharama kubwa (urudiaji wa maombi kawaida huhitaji leseni tofauti na sio ya bure kwa kila programu. Lakini zaidi juu ya hiyo hapa chini).
Unaweza kunakili chochote - programu yoyote, data yoyote - na itakuwa thabiti kila wakati. Programu nyingi (zaidi) hazina uwezo wa kurudia, na nakala kutoka kwa mfumo wa uhifadhi ndio njia pekee ya kutoa ulinzi dhidi ya majanga.
Hakuna haja ya kulipia zaidi kwa utendakazi wa kurudia programu. Kama sheria, sio nafuu, kama vile leseni za replica ya mfumo wa uhifadhi. Lakini unapaswa kulipia leseni ya urudufishaji mara moja, na leseni ya nakala ya programu inahitaji kununuliwa kwa kila programu kivyake. Ikiwa kuna maombi mengi kama haya, basi inagharimu senti nzuri na gharama ya leseni za uigaji wa uhifadhi inakuwa tone kwenye ndoo.

Hoja DHIDI ya urudufishaji wa uhifadhi:

Replica kupitia programu ina utendaji zaidi kutoka kwa mtazamo wa programu yenyewe, programu inajua data yake bora (dhahiri), kwa hivyo kuna chaguzi zaidi za kufanya kazi nao.
Watengenezaji wa baadhi ya programu hawahakikishi uthabiti wa data zao ikiwa kunakili tena kwa kutumia zana za wahusika wengine. *

* - Thesis yenye utata. Kwa mfano, mtengenezaji mashuhuri wa DBMS amekuwa akitangaza rasmi kwa muda mrefu sana kwamba DBMS yao inaweza tu kuigwa kawaida kwa kutumia njia zao, na urudufishaji uliosalia (pamoja na mifumo ya kuhifadhi) "sio kweli." Lakini maisha yameonyesha kuwa hii sivyo. Uwezekano mkubwa zaidi (lakini hii sio hakika) hili sio jaribio la uaminifu zaidi la kuuza leseni zaidi kwa wateja.

Matokeo yake, katika hali nyingi, replication kutoka kwa mfumo wa kuhifadhi ni bora, kwa sababu Hili ni chaguo rahisi na la gharama nafuu, lakini kuna matukio magumu wakati utendakazi maalum wa maombi unahitajika, na ni muhimu kufanya kazi na urudufishaji wa kiwango cha maombi.

Imekamilika kwa nadharia, sasa fanya mazoezi

Tutasanidi nakala kwenye maabara yetu. Katika hali ya maabara, tuliiga vituo viwili vya data (kwa kweli, racks mbili za karibu ambazo zilionekana kuwa ziko katika majengo tofauti). Msimamo una mifumo miwili ya hifadhi ya Injini N2, ambayo imeunganishwa kwa kila mmoja na nyaya za macho. Seva halisi inayoendesha Windows Server 2016 imeunganishwa kwenye mifumo yote miwili ya hifadhi kwa kutumia Ethernet ya 10Gb. Msimamo ni rahisi sana, lakini hii haibadilishi kiini.

Kwa utaratibu inaonekana kama hii:

Kimantiki, urudufishaji umepangwa kama ifuatavyo:

Sasa hebu tuangalie utendaji wa urudufishaji ambao tunao sasa.
Njia mbili zinaungwa mkono: asynchronous na synchronous. Ni mantiki kwamba hali ya synchronous ni mdogo na umbali na njia ya mawasiliano. Hasa, hali ya usawazishaji inahitaji matumizi ya nyuzi kama fizikia na 10 Gigabit Ethernet (au zaidi).

Umbali unaotumika kwa urudufishaji wa usawazishaji ni kilomita 40, thamani ya kuchelewesha ya chaneli ya macho kati ya vituo vya data ni hadi milisekunde 2. Kwa ujumla, itafanya kazi na ucheleweshaji mkubwa, lakini basi kutakuwa na kupungua kwa nguvu wakati wa kurekodi (ambayo pia ni ya kimantiki), hivyo ikiwa unapanga urudiaji wa synchronous kati ya vituo vya data, unapaswa kuangalia ubora wa optics na ucheleweshaji.

Mahitaji ya urudufishaji wa asynchronous sio mbaya sana. Kwa usahihi zaidi, hawapo kabisa. Muunganisho wowote wa Ethernet unaofanya kazi utafanya.

Kwa sasa, mfumo wa hifadhi wa AERODISK ENGINE unaauni urudufishaji wa vifaa vya kuzuia (LUNs) kupitia itifaki ya Ethaneti (juu ya shaba au macho). Kwa miradi ambapo urudufishaji kupitia kitambaa cha SAN juu ya Fiber Channel inahitajika, kwa sasa tunaongeza suluhisho linalofaa, lakini bado halijawa tayari, kwa hivyo kwa upande wetu, Ethernet pekee.

Uigaji unaweza kufanya kazi kati ya mifumo yoyote ya hifadhi ya mfululizo wa ENGINE (N1, N2, N4) kutoka mifumo midogo hadi ya zamani na kinyume chake.

Utendaji wa njia zote mbili za urudufishaji unafanana kabisa. Chini ni maelezo zaidi kuhusu kile kinachopatikana:

Marudio "moja hadi moja" au "moja hadi moja", ambayo ni, toleo la kawaida na vituo viwili vya data, kuu na chelezo.
Replication ni "moja kwa wengi" au "moja kwa wengi", i.e. LUN moja inaweza kuigwa kwa mifumo kadhaa ya kuhifadhi mara moja
Washa, zima, na "geuza" urudufishaji, mtawalia, ili kuwezesha, kuzima, au kubadilisha mwelekeo wa urudufishaji.
Uigaji unapatikana kwa vidimbwi vya RDG (Raid Distributed Group) na DDP (Dynamic Disk Pool). Walakini, LUNs za bwawa la RDG zinaweza tu kuigwa kwa RDG nyingine. Sawa na DDP.

Kuna vipengele vingi vidogo, lakini hakuna maana maalum katika kuorodhesha; tutazitaja tunapoziweka.

Kuweka replication

Mchakato wa usanidi ni rahisi sana na una hatua tatu.

Kuanzisha mtandao
Mpangilio wa hifadhi
Kuweka sheria (miunganisho) na ramani

Jambo muhimu katika kuanzisha replication ni kwamba hatua mbili za kwanza zinapaswa kurudiwa kwenye mfumo wa hifadhi ya kijijini, hatua ya tatu - tu kwa moja kuu.

Kuweka rasilimali za mtandao

Hatua ya kwanza ni kusanidi bandari za mtandao ambazo trafiki ya urudufishaji itapitishwa. Ili kufanya hivyo, unahitaji kuwezesha bandari na kuweka anwani zao za IP katika sehemu ya adapta za Mbele.

Baada ya hayo, tunahitaji kuunda bwawa (kwa upande wetu RDG) na IP ya kawaida ya replication (VIP). VIP ni anwani ya IP inayoelea ambayo inaunganishwa na anwani mbili za "hali" za vidhibiti vya uhifadhi (bandari ambazo tumesanidi hivi punde). Hii itakuwa kiolesura kikuu cha replication. Unaweza pia kufanya kazi sio na VIP, lakini kwa VLAN, ikiwa unahitaji kufanya kazi na trafiki iliyotambulishwa.

Mchakato wa kuunda VIP kwa nakala sio tofauti sana na kuunda VIP ya I/O (NFS, SMB, iSCSI). Katika kesi hii, tunaunda VIP ya kawaida (bila VLAN), lakini hakikisha kuonyesha kwamba ni kwa ajili ya kurudia (bila pointer hii hatutaweza kuongeza VIP kwa utawala katika hatua inayofuata).

VIP lazima iwe katika mtandao mdogo sawa na milango ya IP ambayo inaelea.

Tunarudia mipangilio hii kwenye mfumo wa hifadhi ya mbali, na IP tofauti, bila shaka.
VIP kutoka kwa mifumo tofauti ya uhifadhi inaweza kuwa katika subnets tofauti, jambo kuu ni kwamba kuna njia kati yao. Kwa upande wetu, mfano huu umeonyeshwa haswa (192.168.3.XX na 192.168.2.XX)

Hii inakamilisha utayarishaji wa sehemu ya mtandao.

Inaweka hifadhi

Kuweka hifadhi kwa ajili ya nakala hutofautiana na kawaida tu kwa kuwa tunapanga ramani kupitia menyu maalum ya "Kunakili Ramani". Vinginevyo, kila kitu ni sawa na usanidi wa kawaida. Sasa, kwa utaratibu.

Katika bwawa lililoundwa hapo awali R02, unahitaji kuunda LUN. Hebu tuunde na tuuite LUN1.

Tunahitaji pia kuunda LUN sawa kwenye mfumo wa uhifadhi wa mbali wa ukubwa sawa. Tunaunda. Ili kuepuka kuchanganyikiwa, hebu tupige simu LUN LUN1R ya mbali

Ikiwa tungehitaji kuchukua LUN ambayo tayari ipo, basi wakati wa kusanidi nakala, tungehitaji kupakua LUN hii inayozalisha kutoka kwa seva pangishi, na tuunde LUN tupu ya ukubwa sawa kwenye mfumo wa hifadhi ya mbali.

Usanidi wa uhifadhi umekamilika, wacha tuendelee kuunda sheria ya urudufishaji.

Kuweka kanuni za urudufishaji au viungo vya urudufishaji

Baada ya kuunda LUNs kwenye mfumo wa kuhifadhi, ambao utakuwa wa msingi kwa sasa, tunaweka kanuni ya urudufishaji ya LUN1 kwenye mfumo wa hifadhi wa 1 hadi LUN1R kwenye mfumo wa hifadhi wa 2.

Mpangilio unafanywa kwenye menyu ya "Replication Remote".

Hebu tutengeneze sheria. Ili kufanya hivyo, unahitaji kutaja mpokeaji wa replica. Huko pia tunaweka jina la uunganisho na aina ya replication (synchronous au asynchronous).

Katika sehemu ya "mifumo ya mbali" tunaongeza mfumo wetu wa kuhifadhi2. Ili kuongeza, unahitaji kutumia mifumo ya uhifadhi wa IP ya usimamizi (MGR) na jina la LUN ya mbali ambayo tutafanya uigaji (kwa upande wetu, LUN1R). IP za kudhibiti zinahitajika tu katika hatua ya kuongeza muunganisho; trafiki ya urudufishaji haitapitishwa kupitia kwao; VIP iliyosanidiwa hapo awali itatumika kwa hili.

Tayari katika hatua hii tunaweza kuongeza zaidi ya mfumo mmoja wa mbali kwa topolojia ya "moja hadi nyingi": bofya kitufe cha "ongeza nodi", kama kwenye takwimu hapa chini.

Kwa upande wetu, kuna mfumo mmoja tu wa mbali, kwa hiyo tunajizuia kwa hili.

Sheria iko tayari. Tafadhali kumbuka kuwa imeongezwa moja kwa moja kwa washiriki wote wa replication (kwa upande wetu kuna wawili wao). Unaweza kuunda sheria nyingi kama unavyopenda, kwa idadi yoyote ya LUNs na katika mwelekeo wowote. Kwa mfano, kusawazisha mzigo, tunaweza kuiga sehemu ya LUNs kutoka kwa mfumo wa kuhifadhi 1 hadi mfumo wa kuhifadhi 2, na sehemu nyingine, kinyume chake, kutoka kwa mfumo wa kuhifadhi 2 hadi mfumo wa kuhifadhi 1.

Mfumo wa uhifadhi 1. Mara tu baada ya uumbaji, usawazishaji ulianza.

Mfumo wa uhifadhi2. Tunaona sheria sawa, lakini maingiliano tayari yamekwisha.

LUN1 kwenye mfumo wa kuhifadhi 1 iko katika jukumu la Msingi, yaani, inatumika. LUN1R kwenye mfumo wa kuhifadhi 2 iko katika jukumu la Sekondari, yaani, iko katika hali ya kusubiri ikiwa mfumo wa hifadhi 1 utashindwa.
Sasa tunaweza kuunganisha LUN yetu na mwenyeji.

Tutaunganisha kupitia iSCSI, ingawa inaweza pia kufanywa kupitia FC. Kuweka ramani kupitia iSCSI LUN katika nakala sio tofauti na hali ya kawaida, kwa hivyo hatutazingatia hili kwa undani hapa. Ikiwa kuna chochote, mchakato huu umeelezewa katika kifungu "Mpangilio wa haraka'.

Tofauti pekee ni kwamba tunaunda ramani katika menyu ya "Replication Replication".

Tulianzisha ramani na tukatoa LUN kwa mwenyeji. Mwenyeji aliona LUN.

Tunaibadilisha kuwa mfumo wa faili wa ndani.

Hiyo ndiyo yote, usanidi umekamilika. Mitihani itakuja ijayo.

Upimaji

Tutajaribu hali tatu kuu.

Kubadilisha jukumu mara kwa mara la Sekondari > Msingi. Kubadilisha jukumu mara kwa mara kunahitajika ikiwa, kwa mfano, tunahitaji kufanya shughuli za kuzuia katika kituo kikuu cha data na wakati huu, ili data ipatikane, tunahamisha mzigo kwenye kituo cha data chelezo.
Kubadilisha jukumu la dharura Sekondari > Msingi (kushindwa kwa kituo cha data). Hii ndiyo hali kuu ambayo kuna nakala, ambayo inaweza kusaidia kustahimili kushindwa kamili kwa kituo cha data bila kusimamisha kampuni kwa muda mrefu.
Uchanganuzi wa njia za mawasiliano kati ya vituo vya data. Kuangalia tabia sahihi ya mifumo miwili ya kuhifadhi katika hali ambapo kwa sababu fulani njia ya mawasiliano kati ya vituo vya data haipatikani (kwa mfano, mchimbaji alichimba mahali pabaya na kuvunja optics ya giza).

Kwanza, tutaanza kuandika data kwa LUN yetu (kuandika faili na data ya random). Mara moja tunaona kwamba njia ya mawasiliano kati ya mifumo ya hifadhi inatumiwa. Hii ni rahisi kuelewa ikiwa utafungua ufuatiliaji wa mzigo wa bandari ambazo zinahusika na replication.

Mifumo yote miwili ya hifadhi sasa ina data "muhimu", tunaweza kuanza jaribio.

Ikiwezekana, hebu tuangalie hesabu za hashi za mojawapo ya faili na tuziandike.

Kubadilisha jukumu mara kwa mara

Uendeshaji wa majukumu ya kubadili (kubadilisha mwelekeo wa urudufishaji) unaweza kufanywa na mfumo wowote wa kuhifadhi, lakini bado utahitaji kwenda kwa zote mbili, kwa kuwa utahitaji kuzima uchoraji wa ramani kwenye Msingi, na kuiwezesha kwenye Sekondari (ambayo itakuwa ya Msingi. )

Labda swali linalofaa sasa linatokea: kwa nini usifanye hii otomatiki? Jibu ni: ni rahisi, uigaji ni njia rahisi ya kukabiliana na maafa, kwa kuzingatia tu uendeshaji wa mwongozo. Ili kufanya shughuli hizi otomatiki, kuna modi ya metrocluster; imejiendesha kikamilifu, lakini usanidi wake ni ngumu zaidi. Tutaandika juu ya kuanzisha metrocluster katika makala inayofuata.

Kwenye mfumo mkuu wa hifadhi, tunazima uchoraji wa ramani ili kuhakikisha kuwa kurekodi hukoma.

Kisha kwenye moja ya mifumo ya uhifadhi (haijalishi, kwenye kuu au chelezo) kwenye menyu ya "Replication Remote", chagua uunganisho wetu REPL1 na ubofye "Badilisha jukumu".

Baada ya sekunde chache, LUN1R (mfumo wa hifadhi rudufu) inakuwa Msingi.

Tunapanga LUN1R na mfumo wa kuhifadhi2.

Baada ya hayo, gari letu la E: limeunganishwa kiotomatiki kwa mwenyeji, wakati huu tu "ilifika" kutoka LUN1R.

Ikiwezekana, tunalinganisha hesabu za hashi.

Sawa. Mtihani umepita.

Failover. Kushindwa kwa kituo cha data

Kwa sasa, mfumo mkuu wa kuhifadhi baada ya kubadili mara kwa mara ni mfumo wa kuhifadhi 2 na LUN1R, kwa mtiririko huo. Ili kuiga ajali, tutazima nishati kwenye vidhibiti vyote viwili.
Hakuna tena ufikiaji wake.

Wacha tuone kinachoendelea kwenye mfumo wa uhifadhi wa 1 (ule wa chelezo kwa sasa).

Tunaona kwamba Primary LUN (LUN1R) haipatikani. Ujumbe wa hitilafu ulionekana kwenye magogo, kwenye jopo la habari, na pia katika sheria ya kurudia yenyewe. Kwa hivyo, data kutoka kwa seva pangishi haipatikani kwa sasa.

Badilisha jukumu la LUN1 kuwa la Msingi.

Ninatengeneza ramani kwa mwenyeji.

Hakikisha kuwa kiendeshi E kinaonekana kwenye seva pangishi.

Tunaangalia heshi.

Kila kitu kiko sawa. Mfumo wa uhifadhi ulinusurika kwa mafanikio kuanguka kwa kituo cha data, ambacho kilikuwa hai. Takriban muda tuliotumia kuunganisha "ugeuzaji" wa kurudia na kuunganisha LUN kutoka kituo cha data chelezo ilikuwa kama dakika 3. Ni wazi kwamba katika uzalishaji halisi kila kitu ni ngumu zaidi, na pamoja na vitendo na mifumo ya kuhifadhi, unahitaji kufanya shughuli nyingi zaidi kwenye mtandao, kwenye majeshi, katika maombi. Na katika maisha kipindi hiki cha wakati kitakuwa cha muda mrefu zaidi.

Hapa ningependa kuandika kwamba kila kitu, mtihani umekamilika kwa ufanisi, lakini tusikimbilie. Mfumo mkuu wa kuhifadhi ni "uongo", tunajua kwamba "ulipoanguka", ulikuwa katika jukumu la Msingi. Ni nini hufanyika ikiwa inageuka ghafla? Kutakuwa na majukumu mawili ya Msingi, ambayo ni sawa na ufisadi wa data? Hebu tuangalie sasa.
Hebu tuwashe ghafla mfumo wa hifadhi ya msingi.

Inapakia kwa dakika chache na kisha inarudi kwa huduma baada ya maingiliano mafupi, lakini katika jukumu la Sekondari.

Yote Sawa. Mgawanyiko wa ubongo haukutokea. Tulifikiria juu ya hili, na kila mara baada ya kuanguka mfumo wa uhifadhi hupanda hadi jukumu la Sekondari, bila kujali ilikuwa jukumu gani katika "wakati wa maisha." Sasa tunaweza kusema kwa uhakika kwamba mtihani wa kushindwa kwa kituo cha data ulifanikiwa.

Kushindwa kwa njia za mawasiliano kati ya vituo vya data

Kazi kuu ya mtihani huu ni kuhakikisha kuwa mfumo wa uhifadhi hauanza kutenda ajabu ikiwa unapoteza kwa muda njia za mawasiliano kati ya mifumo miwili ya hifadhi na kisha inaonekana tena.
Hivyo. Tunakata waya kati ya mifumo ya uhifadhi (hebu fikiria kuwa zilichimbwa na mchimbaji).

Kwenye Msingi tunaona kwamba hakuna uhusiano na Sekondari.

Kwenye Sekondari tunaona kwamba hakuna uhusiano na Shule ya Msingi.

Kila kitu hufanya kazi vizuri, na tunaendelea kuandika data kwenye mfumo mkuu wa hifadhi, yaani, wamehakikishiwa kuwa tofauti na moja ya hifadhi, yaani, "wamejitenga".

Katika dakika chache "tunatengeneza" njia ya mawasiliano. Mara tu mifumo ya hifadhi inapoonana, ulandanishi wa data huwashwa kiotomatiki. Hakuna kinachohitajika kutoka kwa msimamizi hapa.

Baada ya muda, maingiliano yanakamilika.

Uunganisho ulirejeshwa, upotezaji wa njia za mawasiliano haukusababisha hali yoyote ya dharura, na baada ya kuwasha, maingiliano yalifanyika kiatomati.

Matokeo

Tulichambua nadharia - ni nini kinachohitajika na kwa nini, wapi faida na hasara ziko wapi. Kisha tunaweka urudufishaji wa synchronous kati ya mifumo miwili ya kuhifadhi.

Kisha, majaribio ya kimsingi yalifanywa kwa kubadili kawaida, kushindwa kwa kituo cha data na kushindwa kwa njia ya mawasiliano. Katika hali zote, mfumo wa kuhifadhi ulifanya kazi vizuri. Hakuna upotezaji wa data na shughuli za usimamizi huwekwa kwa kiwango cha chini kwa hali ya mikono.

Wakati ujao tutatatiza hali hii na kuonyesha jinsi mantiki hii yote inavyofanya kazi katika kikundi kiotomatiki cha metrocluster katika hali inayotumika, yaani, wakati mifumo yote miwili ya uhifadhi ni msingi, na tabia katika kesi ya hitilafu za mfumo wa uhifadhi inajiendesha kikamilifu.

Tafadhali andika maoni, tutafurahi kupokea ukosoaji mzuri na ushauri wa vitendo.

Mpaka wakati ujao.

Chanzo: mapenzi.com

Injini ya AERODISK: Upinzani wa maafa. Sehemu 1