Injini ya AERODISK: Upinzani wa maafa. Sehemu ya 2. Metrocluster

Habari, wasomaji wa Habr! Katika makala ya mwisho, tulizungumzia kuhusu njia rahisi za kupona maafa katika mifumo ya hifadhi ya AERODISK ENGINE - replication. Katika makala haya, tutaingia kwenye mada changamano na ya kuvutia zaidi - kikundi cha metrocluster, yaani, njia ya ulinzi wa kiotomatiki wa maafa kwa vituo viwili vya data, vinavyoruhusu vituo vya data kufanya kazi katika hali inayotumika. Tutakuambia, kukuonyesha, kuivunja na kuirekebisha.

Kama kawaida, nadharia kwanza

Metrocluster ni nguzo iliyoenea katika tovuti kadhaa ndani ya jiji au eneo. Neno "nguzo" linatuonyesha wazi kuwa tata hiyo ni automatiska, yaani, kubadili nodi za nguzo katika tukio la kushindwa hutokea moja kwa moja.

Hapa ndipo tofauti kuu kati ya metrocluster na replication ya kawaida iko. Automation ya shughuli. Hiyo ni, katika tukio la matukio fulani (kushindwa kwa kituo cha data, njia zilizovunjika, nk), mfumo wa hifadhi utafanya kwa kujitegemea vitendo muhimu ili kudumisha upatikanaji wa data. Wakati wa kutumia nakala za kawaida, vitendo hivi hufanywa kabisa au kwa sehemu na msimamizi.

Je! Hii ni nini?

Lengo kuu ambalo wateja hufuata wanapotumia utekelezaji fulani wa vikundi vya metrocluster ni kupunguza RTO (Lengo la Muda wa Kurejesha Mapato). Hiyo ni, kupunguza muda wa kurejesha huduma za IT baada ya kushindwa. Ikiwa unatumia urudufishaji mara kwa mara, muda wa kurejesha utakuwa mrefu kuliko muda wa kurejesha ukitumia kikundi cha metrocluster. Kwa nini? Rahisi sana. Msimamizi lazima awe kwenye dawati lake na abadilishe urudufishaji kwa mikono, na kikundi cha metrocluster hufanya hivi kiotomatiki.

Ikiwa huna msimamizi aliyejitolea juu ya zamu ambaye halala, hakula, havuta sigara au mgonjwa, na anaangalia hali ya mfumo wa kuhifadhi saa 24 kwa siku, basi hakuna njia ya kuhakikisha kwamba msimamizi atafanya. kupatikana kwa kubadili mwenyewe wakati wa kutofaulu.

Ipasavyo, RTO kwa kukosekana kwa kikundi cha metrocluster au msimamizi wa kutokufa wa kiwango cha 99 cha huduma ya wajibu wa msimamizi itakuwa sawa na jumla ya muda wa kubadili mifumo yote na muda wa juu baada ya hapo msimamizi anahakikishiwa kuanza kufanya kazi. na mifumo ya uhifadhi na mifumo inayohusiana.

Kwa hiyo, tunafikia hitimisho la wazi kwamba metrocluster inapaswa kutumika ikiwa mahitaji ya RTO ni dakika, si saa au siku.Hiyo ni, wakati wa kushindwa kwa kituo cha data mbaya zaidi, idara ya IT inapaswa kutoa biashara kwa wakati. kurejesha ufikiaji wa huduma za IT ndani ya dakika, au hata sekunde.

Jinsi gani kazi?

Katika kiwango cha chini, kikundi cha metrocluster hutumia utaratibu wa urudufishaji wa data kisawazishaji, ambao tulielezea katika nakala iliyotangulia (ona. kiungo) Kwa kuwa urudufishaji ni sawa, mahitaji yake yanalingana, au tuseme:

• nyuzi za macho kama fizikia, Ethernet ya gigabit 10 (au zaidi);
• umbali kati ya vituo vya data sio zaidi ya kilomita 40;
• ucheleweshaji wa njia ya macho kati ya vituo vya data (kati ya mifumo ya hifadhi) ni hadi milisekunde 5 (zaidi 2).

Mahitaji haya yote ni ya ushauri kwa asili, ambayo ni kwamba, metrocluster itafanya kazi hata ikiwa mahitaji haya hayajafikiwa, lakini lazima tuelewe kuwa matokeo ya kutofuata mahitaji haya ni sawa na kushuka kwa utendakazi wa mifumo yote miwili ya kuhifadhi. kundi la metrocluster.

Kwa hivyo, nakala ya synchronous hutumiwa kuhamisha data kati ya mifumo ya uhifadhi, na jinsi nakala hubadilika kiotomatiki na, muhimu zaidi, jinsi ya kuzuia mgawanyiko wa ubongo? Ili kufanya hivyo, kwa kiwango cha juu, chombo cha ziada hutumiwa - msuluhishi.

Msuluhishi hufanyaje kazi na kazi yake ni nini?

Kisuluhishi ni mashine ndogo pepe au nguzo ya maunzi ambayo lazima izinduliwe kwenye tovuti ya tatu (kwa mfano, katika ofisi) na kutoa ufikiaji wa mfumo wa kuhifadhi kupitia ICMP na SSH. Baada ya kuzinduliwa, msuluhishi anapaswa kuweka IP, na kisha kutoka kwa upande wa uhifadhi onyesha anwani yake, pamoja na anwani za watawala wa mbali wanaoshiriki katika metrocluster. Baada ya hayo, mwamuzi yuko tayari kufanya kazi.

Msuluhishi hufuatilia kila mara mifumo yote ya uhifadhi kwenye metrocluster na ikiwa mfumo fulani wa uhifadhi haupatikani, baada ya kudhibitisha kutopatikana kutoka kwa mshiriki mwingine wa nguzo (moja ya mifumo ya uhifadhi "moja kwa moja"), anaamua kuzindua utaratibu wa kubadili sheria za kurudia. na uchoraji ramani.

Jambo muhimu sana. Msuluhishi lazima awe iko kwenye tovuti tofauti na yale ambayo mifumo ya hifadhi iko, yaani, wala katika kituo cha data 1, ambapo mfumo wa kuhifadhi 1 umewekwa, wala katika kituo cha data 2, ambapo mfumo wa kuhifadhi 2 umewekwa.

Kwa nini? Kwa sababu hii ndiyo njia pekee ya msuluhishi, kwa usaidizi wa moja ya mifumo ya hifadhi iliyobaki, inaweza kuamua kwa usahihi na kwa usahihi kuanguka kwa tovuti yoyote kati ya mbili ambapo mifumo ya kuhifadhi imewekwa. Njia zingine zozote za kuweka msuluhishi zinaweza kusababisha mgawanyiko wa ubongo.

Sasa hebu tuzame kwenye maelezo ya kazi ya msuluhishi.

Msuluhishi huendesha huduma kadhaa ambazo huchagulia kila mara vidhibiti vyote vya uhifadhi. Ikiwa matokeo ya kura yanatofautiana na ya awali (inapatikana / haipatikani), basi imeandikwa kwenye hifadhidata ndogo, ambayo pia inafanya kazi kwenye mwamuzi.

Hebu tuangalie mantiki ya kazi ya msuluhishi kwa undani zaidi.

Hatua ya 1: Bainisha kutopatikana. Tukio la kushindwa kwa mfumo wa hifadhi ni kukosekana kwa ping kutoka kwa vidhibiti vyote viwili vya mfumo sawa wa kuhifadhi ndani ya sekunde 5.

Hatua ya 2. Anza utaratibu wa kubadili. Baada ya msuluhishi kugundua kuwa moja ya mifumo ya uhifadhi haipatikani, anatuma ombi kwa mfumo wa uhifadhi wa "live" ili kuhakikisha kuwa mfumo wa uhifadhi "wafu" umekufa kweli.

Baada ya kupokea amri kama hiyo kutoka kwa msuluhishi, mfumo wa uhifadhi wa pili (moja kwa moja) pia huangalia upatikanaji wa mfumo wa uhifadhi wa kwanza ulioanguka na, ikiwa haipo, hutuma uthibitisho kwa mwamuzi wa nadhani yake. Mfumo wa kuhifadhi haupatikani.

Baada ya kupokea uthibitisho kama huo, msuluhishi anazindua utaratibu wa mbali wa kubadili urudufishaji na kuinua ramani kwenye nakala hizo ambazo zilikuwa amilifu (msingi) kwenye mfumo wa uhifadhi ulioanguka, na kutuma amri kwa mfumo wa pili wa uhifadhi kubadilisha nakala hizi kutoka kwa upili hadi msingi na. kuongeza ramani. Naam, mfumo wa pili wa hifadhi, ipasavyo, hufanya taratibu hizi, na kisha hutoa upatikanaji wa LUNs zilizopotea kutoka yenyewe.

Kwa nini uthibitishaji wa ziada unahitajika? Kwa akidi. Hiyo ni, idadi kubwa ya jumla ya idadi isiyo ya kawaida (3) ya washiriki wa nguzo lazima ithibitishe kuanguka kwa mojawapo ya nodi za nguzo. Ni hapo tu ndipo uamuzi huu utakuwa sahihi kabisa. Hii ni muhimu ili kuzuia kubadili vibaya na, ipasavyo, mgawanyiko wa ubongo.

Hatua ya 2 ya wakati inachukua takriban sekunde 5 - 10, kwa hivyo, kwa kuzingatia wakati unaohitajika kuamua kutopatikana (sekunde 5), ndani ya sekunde 10 - 15 baada ya ajali, LUNs kutoka kwa mfumo wa uhifadhi ulioanguka zitapatikana kiotomatiki kufanya kazi na hai. mfumo wa kuhifadhi.

Ni wazi kwamba ili kuepuka kupoteza miunganisho na wapangishi, unahitaji pia kutunza kusanidi kwa usahihi muda wa muda kwenye wapangishaji. Muda uliopendekezwa wa kuisha ni angalau sekunde 30. Hili litazuia seva pangishi kukata muunganisho kwenye mfumo wa hifadhi wakati wa kubadilisha upakiaji iwapo kutatokea maafa na inaweza kuhakikisha kuwa hakuna kukatizwa kwa I/O.

Subiri kwa sekunde, inageuka kuwa ikiwa kila kitu ni nzuri na metrocluster, kwa nini tunahitaji kurudiwa mara kwa mara?

Kwa kweli, kila kitu sio rahisi sana.

Hebu fikiria faida na hasara za metrocluster

Kwa hivyo, tuligundua kuwa faida dhahiri za kikundi cha metrocluster ikilinganishwa na uigaji wa kawaida ni:

• Automatisering kamili, kuhakikisha muda mdogo wa kurejesha katika tukio la maafa;
• Ni hayo tu :-).

Na sasa, tahadhari, hasara:

• Gharama ya suluhisho. Ingawa Metrocluster katika mifumo ya Aerodisk haihitaji leseni ya ziada (leseni sawa inatumika kama kwa nakala), gharama ya suluhisho bado itakuwa kubwa zaidi kuliko kutumia urudufishaji wa usawazishaji. Utahitaji kutekeleza mahitaji yote ya nakala inayolingana, pamoja na mahitaji ya kikundi cha metro kinachohusishwa na ubadilishaji wa ziada na tovuti ya ziada (tazama upangaji wa vikundi vya metrocluster);
• Utata wa suluhisho. Metrocluster ni ngumu zaidi kuliko nakala ya kawaida, na inahitaji umakini na bidii zaidi kwa kupanga, usanidi na uwekaji kumbukumbu.

Hatimaye. Metrocluster hakika ni suluhisho la juu sana la kiteknolojia na zuri wakati unahitaji kweli kutoa RTO kwa sekunde au dakika. Lakini ikiwa hakuna kazi kama hiyo, na RTO katika masaa ni sawa kwa biashara, basi hakuna maana katika kurusha shomoro kutoka kwa kanuni. Replication ya kawaida ya wafanyikazi-wakulima inatosha, kwani nguzo ya metro itasababisha gharama za ziada na shida ya miundombinu ya IT.

Mipango ya Metrocluster

Sehemu hii haidai kuwa mwongozo wa kina wa muundo wa vikundi vya metrocluster, lakini inaonyesha tu mwelekeo kuu ambao unapaswa kutatuliwa ikiwa utaamua kuunda mfumo kama huo. Kwa hivyo, wakati wa kutekeleza kikundi cha metrocluster, hakikisha kuwa unahusisha mtengenezaji wa mfumo wa kuhifadhi (yaani, sisi) na mifumo mingine inayohusiana kwa mashauriano.

Maeneo

Kama ilivyoelezwa hapo juu, kikundi cha metrocluster kinahitaji angalau tovuti tatu. Vituo viwili vya data ambapo mifumo ya hifadhi na mifumo inayohusiana itafanya kazi, pamoja na tovuti ya tatu ambapo msuluhishi atafanya kazi.

Umbali uliopendekezwa kati ya vituo vya data sio zaidi ya kilomita 40. Umbali mkubwa una uwezekano mkubwa wa kusababisha ucheleweshaji zaidi, ambao katika kesi ya kikundi cha metro haufai sana. Hebu tukumbushe kwamba ucheleweshaji unapaswa kuwa hadi milisekunde 5, ingawa inashauriwa kuwaweka ndani ya 2.

Inashauriwa kuangalia ucheleweshaji pia wakati wa mchakato wa kupanga. Mtoa huduma yeyote aliyekomaa zaidi au chini ambaye hutoa nyuzi macho kati ya vituo vya data anaweza kupanga ukaguzi wa ubora haraka sana.

Kuhusu ucheleweshaji kabla ya msuluhishi (ambayo ni, kati ya tovuti ya tatu na mbili za kwanza), kizingiti cha kuchelewa kilichopendekezwa ni hadi milliseconds 200, yaani, muunganisho wa kawaida wa VPN wa shirika kwenye mtandao unafaa.

Kubadilisha na Mtandao

Tofauti na mpango wa kurudia, ambapo inatosha kuunganisha mifumo ya hifadhi kutoka kwa tovuti tofauti, mpango wa metrocluster unahitaji kuunganisha majeshi na mifumo yote ya hifadhi kwenye tovuti tofauti. Ili kuifanya iwe wazi zaidi tofauti ni nini, mipango yote miwili imeonyeshwa hapa chini.

Kama inavyoonekana kutoka kwa mchoro, wapangishi wetu wa tovuti 1 hutazama mfumo wa uhifadhi 1 na mfumo wa uhifadhi 2. Pia, kinyume chake, wapangishi wa tovuti 2 hutazama mfumo wa uhifadhi wa 2 na mfumo wa kuhifadhi 1. Hiyo ni, kila mwenyeji huona mifumo yote ya uhifadhi. Hili ni sharti la uendeshaji wa kundi la metrocluster.

Bila shaka, hakuna haja ya kuunganisha kila mwenyeji na kamba ya macho kwenye kituo kingine cha data; hakuna bandari au kamba zitatosha. Miunganisho hii yote lazima ifanywe kupitia swichi za Ethernet 10G+ au FibreChannel 8G+ (FC ni ya kuunganisha wapangishi na mifumo ya hifadhi ya IO pekee, chaneli ya urudufishaji inapatikana tu kupitia IP (Ethernet 10G+) pekee.

Sasa maneno machache kuhusu topolojia ya mtandao. Jambo muhimu ni usanidi sahihi wa subnets. Inahitajika kufafanua mara moja subnets kadhaa kwa aina zifuatazo za trafiki:

• Subnet ya urudufishaji ambayo data itasawazishwa kati ya mifumo ya hifadhi. Kunaweza kuwa na kadhaa yao, katika kesi hii haijalishi, yote inategemea topolojia ya mtandao ya sasa (tayari imetekelezwa). Ikiwa kuna mbili kati yao, basi ni wazi uelekezaji lazima usanidiwe kati yao;
• Neti ndogo za hifadhi ambazo wapangishi watafikia rasilimali za uhifadhi (ikiwa ni iSCSI). Kunapaswa kuwa na subnet moja kama hiyo katika kila kituo cha data;
• Kudhibiti subnets, yaani, subnets tatu zinazoweza kubadilishwa kwenye tovuti tatu ambazo mifumo ya uhifadhi inasimamiwa, na arbiter pia iko hapo.

Hatuzingatii subneti za kufikia rasilimali za mwenyeji hapa, kwa kuwa zinategemea sana majukumu.

Kutenganisha trafiki tofauti katika subnets tofauti ni muhimu sana (ni muhimu sana kutenganisha nakala kutoka kwa I/O), kwa sababu ikiwa unachanganya trafiki yote kwenye subnet "nene", basi trafiki hii haitawezekana kudhibiti, na katika hali ya vituo viwili vya data hii bado inaweza kusababisha chaguzi tofauti za mgongano wa mtandao. Hatutazingatia kwa undani suala hili ndani ya mfumo wa kifungu hiki, kwani unaweza kusoma juu ya kupanga mtandao uliowekwa kati ya vituo vya data kwenye rasilimali za watengenezaji wa vifaa vya mtandao, ambapo hii inaelezewa kwa undani sana.

Usanidi wa kisuluhishi

Msuluhishi lazima atoe ufikiaji wa violesura vyote vya usimamizi wa mfumo wa hifadhi kupitia itifaki za ICMP na SSH. Unapaswa pia kufikiria juu ya kushindwa kwa mwamuzi. Kuna nuance hapa.

Usuluhishi wa kushindwa unahitajika sana, lakini hauhitajiki. Nini kitatokea ikiwa mwamuzi ataanguka kwa wakati usiofaa?

• Uendeshaji wa metrocluster katika hali ya kawaida haitabadilika, kwa sababu arbtir haina athari kabisa juu ya uendeshaji wa metrocluster katika hali ya kawaida (kazi yake ni kubadili mzigo kati ya vituo vya data kwa wakati unaofaa)
• Zaidi ya hayo, ikiwa msuluhishi kwa sababu moja au nyingine huanguka na "kulala kupitia" ajali katika kituo cha data, basi hakuna kubadili kutatokea, kwa sababu hakutakuwa na mtu wa kutoa amri muhimu za kubadili na kuandaa quorum. Katika kesi hii, metrocluster itageuka kuwa mpango wa kawaida na replication, ambayo itabidi kubadilishwa kwa mikono wakati wa maafa, ambayo yataathiri RTO.

Nini kinafuata kutoka kwa hii? Ikiwa unahitaji kuhakikisha kiwango cha chini cha RTO, unahitaji kuhakikisha kuwa msuluhishi ni mstahimilivu wa makosa. Kuna chaguzi mbili kwa hii:

• Zindua mashine ya mtandaoni iliyo na kisuluhishi kwenye hypervisor inayostahimili makosa, kwa bahati nzuri hypervisor zote za watu wazima zinaunga mkono uvumilivu wa makosa;
• Ikiwa kwenye tovuti ya tatu (katika ofisi ya kawaida) wewe ni wavivu sana kufunga nguzo ya kawaida na hakuna nguzo iliyopo ya hypervozor, basi tumetoa toleo la vifaa vya arbiter, ambalo linafanywa katika sanduku la 2U ambalo mbili za kawaida. Seva za x-86 hufanya kazi na ambazo zinaweza kustahimili kushindwa kwa ndani.

Tunapendekeza sana kuhakikisha uvumilivu wa kosa la msuluhishi, licha ya ukweli kwamba metrocluster haihitaji katika hali ya kawaida. Lakini kama nadharia na mazoezi inavyoonyesha, ikiwa utaunda miundombinu ya kuaminika ya kuzuia maafa, basi ni bora kuilinda. Ni bora kujilinda na biashara yako kutoka kwa "sheria ya ubaya," ambayo ni, kutokana na kutofaulu kwa msuluhishi na moja ya tovuti ambazo mfumo wa uhifadhi unapatikana.

Usanifu wa suluhisho

Kuzingatia mahitaji hapo juu, tunapata usanifu wa ufumbuzi wa jumla wafuatayo.

LUNs zinapaswa kusambazwa sawasawa katika tovuti mbili ili kuepuka upakiaji mkubwa. Wakati huo huo, unapoweka ukubwa katika vituo vyote viwili vya data, unapaswa kujumuisha sio tu sauti mbili (ambayo ni muhimu kuhifadhi data wakati huo huo kwenye mifumo miwili ya kuhifadhi), lakini pia utendaji mara mbili katika IOPS na MB/s ili kuzuia uharibifu wa programu katika tukio la kushindwa kwa moja ya vituo vya data.

Kando, tunaona kuwa kwa mbinu sahihi ya kupima ukubwa (yaani, mradi tumetoa kikomo cha juu cha IOPS na MB/s, pamoja na rasilimali muhimu za CPU na RAM), ikiwa ni moja ya mifumo ya uhifadhi kwenye nguzo ya metro inashindwa, hakutakuwa na kushuka kwa kiwango kikubwa kwa utendaji chini ya hali ya kazi ya muda kwenye mfumo mmoja wa hifadhi.

Hii inafafanuliwa na ukweli kwamba wakati tovuti mbili zinafanya kazi wakati huo huo, uigaji wa synchronous "hula" nusu ya utendaji wa kuandika, kwani kila shughuli lazima iandikwe kwa mifumo miwili ya kuhifadhi (sawa na RAID-1/10). Kwa hivyo, ikiwa moja ya mifumo ya uhifadhi inashindwa, ushawishi wa kurudia kwa muda (mpaka mfumo wa uhifadhi ulioshindwa urejeshe) hupotea, na tunapata ongezeko la mara mbili katika utendaji wa kuandika. Baada ya LUNs za mfumo wa uhifadhi ulioshindwa kuanza tena kwenye mfumo wa uhifadhi wa kufanya kazi, ongezeko hili mara mbili hupotea kwa sababu ya ukweli kwamba mzigo unaonekana kutoka kwa LUNs za mfumo mwingine wa uhifadhi, na tunarudi kwenye kiwango sawa cha utendaji tuliokuwa nao kabla ya "kuanguka", lakini tu ndani ya mfumo wa tovuti moja.

Kwa usaidizi wa ukubwa unaofaa, unaweza kuhakikisha hali ambayo watumiaji hawatahisi kushindwa kwa mfumo mzima wa hifadhi wakati wote. Lakini tunarudia mara nyingine tena, hii inahitaji ukubwa wa makini sana, ambayo, kwa njia, unaweza kuwasiliana nasi kwa bure :-).

Kuanzisha kikundi cha metrocluster

Kuanzisha kikundi cha metrocluster ni sawa na kusanidi urudufu wa kawaida, ambao tulielezea ndani makala iliyopita. Kwa hiyo, hebu tuzingatie tofauti tu. Tunaweka benchi katika maabara kulingana na usanifu hapo juu, tu katika toleo la chini: mifumo miwili ya hifadhi iliyounganishwa kupitia 10G Ethernet, swichi mbili za 10G na mwenyeji mmoja anayeangalia kupitia swichi kwenye mifumo yote ya hifadhi na bandari za 10G. Msuluhishi anaendesha kwenye mashine pepe.

Wakati wa kusanidi IPs za kawaida (VIPs) kwa replica, unapaswa kuchagua aina ya VIP - kwa metrocluster.

Tuliunda viungo viwili vya urudufishaji vya LUN mbili na kuvisambaza katika mifumo miwili ya hifadhi: LUN TEST Msingi kwenye mfumo wa hifadhi 1 (kiungo cha METRO), LUN TEST2 Msingi kwa mfumo wa hifadhi 2 (kiungo cha METRO2).

Kwao, tulisanidi malengo mawili yanayofanana (kwa upande wetu iSCSI, lakini FC pia inaungwa mkono, mantiki ya usanidi ni sawa).

Mfumo wa uhifadhi 1:

Mfumo wa uhifadhi 2:

Kwa miunganisho ya kurudia, uchoraji wa ramani ulifanywa kwenye kila mfumo wa hifadhi.

Mfumo wa uhifadhi 1:

Mfumo wa uhifadhi 2:

Tunaanzisha njia nyingi na kuiwasilisha kwa mwenyeji.

Kuweka msuluhishi

Huna haja ya kufanya chochote maalum na msuluhishi yenyewe; unahitaji tu kuiwezesha kwenye tovuti ya tatu, kuipa IP na kusanidi ufikiaji wake kupitia ICMP na SSH. Usanidi yenyewe unafanywa kutoka kwa mifumo ya uhifadhi yenyewe. Katika kesi hii, inatosha kusanidi kisuluhishi mara moja kwenye vidhibiti vyovyote vya uhifadhi kwenye kikundi cha metrocluster; mipangilio hii itasambazwa kwa watawala wote kiotomatiki.

Katika sehemu ya Urudiaji wa Mbali>> Metrocluster (kwenye kidhibiti chochote)>> kitufe cha "Sanidi".

Tunaingia IP ya msuluhishi, pamoja na miingiliano ya udhibiti wa watawala wawili wa uhifadhi wa mbali.

Baada ya hayo, unahitaji kuwezesha huduma zote (kifungo cha "Rudisha Kila kitu"). Ikiwa itasanidiwa upya katika siku zijazo, huduma lazima ziwashwe upya ili mipangilio ianze kutumika.

Tunaangalia kuwa huduma zote zinaendelea.

Hii inakamilisha usanidi wa kikundi cha metrocluster.

Jaribio la kuacha kufanya kazi

Jaribio la kuacha kufanya kazi kwa upande wetu litakuwa rahisi na la haraka sana, kwa kuwa utendakazi wa kurudia (kubadili, uthabiti, n.k.) ulijadiliwa katika makala ya mwisho. Kwa hiyo, ili kupima uaminifu wa metrocluster, inatosha kwetu kuangalia automatisering ya kugundua kushindwa, kubadili na kutokuwepo kwa hasara za kurekodi (I / O inacha).

Ili kufanya hivyo, tunaiga kushindwa kamili kwa moja ya mifumo ya hifadhi kwa kuzima kimwili watawala wake wote wawili, baada ya kuanza kwanza kunakili faili kubwa kwenye LUN, ambayo lazima iamilishwe kwenye mfumo mwingine wa hifadhi.

Zima mfumo mmoja wa kuhifadhi. Kwenye mfumo wa pili wa uhifadhi tunaona arifa na ujumbe katika kumbukumbu kwamba uunganisho na mfumo wa jirani umepotea. Ikiwa arifa kupitia ufuatiliaji wa SMTP au SNMP zitasanidiwa, msimamizi atapokea arifa zinazolingana.

Sekunde 10 haswa baadaye (inayoonekana katika viwambo vyote viwili), muunganisho wa urudufishaji wa METRO (ule uliokuwa Msingi kwenye mfumo wa uhifadhi ulioshindwa) ukawa Msingi kiotomatiki kwenye mfumo wa uhifadhi wa kufanya kazi. Kwa kutumia ramani iliyopo, LUN TEST iliendelea kupatikana kwa mwenyeji, rekodi ilipungua kidogo (kati ya asilimia 10 iliyoahidiwa), lakini haikukatizwa.

Jaribio limekamilika kwa mafanikio.

Kwa muhtasari

Utekelezaji wa sasa wa kikundi cha metrocluster katika mifumo ya hifadhi ya mfululizo wa Injini ya AERODISK inaruhusu kikamilifu kutatua matatizo ambapo ni muhimu kuondoa au kupunguza muda wa kupungua kwa huduma za IT na kuhakikisha uendeshaji wao 24/7/365 na gharama ndogo za kazi.

Tunaweza kusema, bila shaka, kwamba hii yote ni nadharia, hali bora ya maabara, na kadhalika ... LAKINI tuna idadi ya miradi iliyotekelezwa ambayo tumetekeleza utendaji wa kukabiliana na maafa, na mifumo inafanya kazi kikamilifu. Mmoja wa wateja wetu wanaojulikana sana, ambao hutumia mifumo miwili tu ya uhifadhi katika usanidi wa kuzuia maafa, tayari amekubali kuchapisha habari kuhusu mradi huo, kwa hiyo katika sehemu inayofuata tutazungumzia kuhusu utekelezaji wa kupambana.

Asante, tunatarajia mjadala wenye tija.

Chanzo: mapenzi.com