AERODISK Engine: Paglaban sa kalamidad. Bahagi 2. Metrocluster

Kumusta, mga mambabasa ng Habr! Sa huling artikulo, napag-usapan namin ang tungkol sa isang simpleng paraan ng pagbawi ng sakuna sa mga sistema ng imbakan ng AERODISK ENGINE - pagtitiklop. Sa artikulong ito, sumisid tayo sa isang mas kumplikado at kawili-wiling paksa - ang metrocluster, iyon ay, isang paraan ng awtomatikong proteksyon sa sakuna para sa dalawang data center, na nagpapahintulot sa mga data center na gumana sa active-active mode. Sasabihin namin sa iyo, ipakita sa iyo, sirain ito at ayusin ito.

As usual, theory muna

Ang metrocluster ay isang cluster na nakakalat sa ilang mga site sa loob ng isang lungsod o rehiyon. Ang salitang "cluster" ay malinaw na nagpapahiwatig sa amin na ang complex ay awtomatiko, iyon ay, ang paglipat ng mga cluster node sa kaganapan ng mga pagkabigo ay awtomatikong nangyayari.

Dito matatagpuan ang pangunahing pagkakaiba sa pagitan ng metrocluster at regular na pagtitiklop. Automation ng mga operasyon. Iyon ay, sa kaganapan ng ilang mga insidente (data center failure, sirang channel, atbp.), ang storage system ay malayang gagawa ng mga kinakailangang aksyon upang mapanatili ang availability ng data. Kapag gumagamit ng mga regular na replika, ang mga pagkilos na ito ay ganap o bahagyang ginagawa nang manu-mano ng administrator.

Ano ang ginagawa nito?

Ang pangunahing layunin na itinataguyod ng mga customer kapag gumagamit ng ilang partikular na pagpapatupad ng metrocluster ay upang mabawasan ang RTO (Layunin ng Oras ng Pagbawi). Iyon ay, upang mabawasan ang oras ng pagbawi ng mga serbisyo ng IT pagkatapos ng isang pagkabigo. Kung gagamit ka ng regular na pagtitiklop, ang oras ng pagbawi ay palaging mas mahaba kaysa sa oras ng pagbawi gamit ang isang metrocluster. Bakit? Napakasimple. Ang administrator ay dapat nasa kanyang desk at manu-manong lumipat ng replikasyon, at awtomatiko itong ginagawa ng metrocluster.

Kung wala kang dedikadong administrator na naka-duty na hindi natutulog, hindi kumakain, hindi naninigarilyo o nagkakasakit, at binabantayan ang estado ng storage system 24 na oras sa isang araw, kung gayon walang paraan upang matiyak na ang administrator ay ay magagamit para sa manu-manong paglipat sa panahon ng pagkabigo.

Alinsunod dito, ang RTO sa kawalan ng isang metrocluster o isang walang kamatayang admin ng ika-99 na antas ng serbisyo ng tungkulin ng administrator ay magiging katumbas ng kabuuan ng oras ng paglipat ng lahat ng mga system at ang maximum na tagal ng oras pagkatapos nito ay ginagarantiyahan ang administrator na magsimulang magtrabaho. na may mga sistema ng imbakan at mga kaugnay na sistema.

Kaya, kami ay dumating sa malinaw na konklusyon na ang metrocluster ay dapat gamitin kung ang kinakailangan para sa RTO ay ilang minuto, hindi oras o araw. upang maibalik ang access sa mga IT -service sa loob ng ilang minuto, o kahit na mga segundo.

Paano ito gumagana?

Sa mas mababang antas, ang metrocluster ay gumagamit ng isang mekanismo para sa kasabay na pagtitiklop ng data, na inilarawan namin sa nakaraang artikulo (tingnan. link). Dahil ang pagtitiklop ay kasabay, ang mga kinakailangan para dito ay katumbas, o sa halip:

• optical fiber bilang physics, 10 gigabit Ethernet (o mas mataas);
• ang distansya sa pagitan ng mga data center ay hindi hihigit sa 40 kilometro;
• Ang pagkaantala ng optical channel sa pagitan ng mga data center (sa pagitan ng mga storage system) ay hanggang 5 milliseconds (pinakamahusay na 2).

Ang lahat ng mga kinakailangang ito ay likas na pagpapayo, iyon ay, gagana ang metrocluster kahit na ang mga kinakailangang ito ay hindi natutugunan, ngunit dapat nating maunawaan na ang mga kahihinatnan ng hindi pagsunod sa mga kinakailangang ito ay katumbas ng isang pagbagal sa pagpapatakbo ng parehong mga sistema ng imbakan sa ang metrocluster.

Kaya, ang isang kasabay na replika ay ginagamit upang maglipat ng data sa pagitan ng mga sistema ng imbakan, at paano awtomatikong lumipat ang mga replika at, higit sa lahat, kung paano maiwasan ang split-brain? Upang gawin ito, sa isang mas mataas na antas, isang karagdagang entidad ang ginagamit - isang arbiter.

Paano gumagana ang isang arbitrator at ano ang kanyang gawain?

Ang arbiter ay isang maliit na virtual machine o isang hardware cluster na dapat ilunsad sa ikatlong site (halimbawa, sa isang opisina) at magbigay ng access sa storage system sa pamamagitan ng ICMP at SSH. Pagkatapos ng paglunsad, dapat itakda ng arbiter ang IP, at pagkatapos ay ipahiwatig mula sa gilid ng imbakan ang address nito, kasama ang mga address ng mga remote controller na lumahok sa metrocluster. Pagkatapos nito, ang referee ay handa nang magtrabaho.

Ang arbiter ay patuloy na sinusubaybayan ang lahat ng mga sistema ng imbakan sa metrocluster at kung ang isang partikular na sistema ng imbakan ay hindi magagamit, pagkatapos na kumpirmahin ang hindi magagamit mula sa isa pang miyembro ng cluster (isa sa mga "live" na sistema ng imbakan), nagpasya siyang ilunsad ang pamamaraan para sa paglipat ng mga panuntunan sa pagtitiklop. at pagmamapa.

Isang napakahalagang punto. Ang arbitrator ay dapat palaging matatagpuan sa isang site na iba sa mga kung saan matatagpuan ang mga storage system, ibig sabihin, wala sa data center 1, kung saan naka-install ang storage system 1, o sa data center 2, kung saan naka-install ang storage system 2.

Bakit? Dahil ito ang tanging paraan na ang isang arbitrator, sa tulong ng isa sa mga nabubuhay na sistema ng imbakan, ay maaaring malinaw at tumpak na matukoy ang pagbagsak ng alinman sa dalawang mga site kung saan naka-install ang mga sistema ng imbakan. Anumang iba pang paraan ng paglalagay ng arbiter ay maaaring magresulta sa split-brain.

Ngayon ay sumisid tayo sa mga detalye ng gawain ng arbitrator.

Ang arbiter ay nagpapatakbo ng ilang mga serbisyo na patuloy na nagpo-poll sa lahat ng storage controllers. Kung ang resulta ng poll ay naiiba sa nauna (available/unavailable), ire-record ito sa isang maliit na database, na gumagana din sa arbiter.

Tingnan natin ang lohika ng gawain ng arbitrator nang mas detalyado.

Hakbang 1: Tukuyin ang hindi magagamit. Ang isang kaganapan sa pagkabigo ng storage system ay ang kawalan ng ping mula sa parehong mga controller ng parehong storage system sa loob ng 5 segundo.

Hakbang 2. Simulan ang pamamaraan ng paglipat. Matapos mapagtanto ng arbiter na ang isa sa mga sistema ng imbakan ay hindi magagamit, nagpapadala siya ng isang kahilingan sa "live" na sistema ng imbakan upang matiyak na ang "patay" na sistema ng imbakan ay talagang patay na.

Matapos matanggap ang naturang utos mula sa arbiter, ang pangalawang (live) na sistema ng imbakan ay karagdagang sinusuri ang pagkakaroon ng nahulog na unang sistema ng imbakan at, kung wala ito, nagpapadala ng kumpirmasyon sa arbiter ng kanyang hula. Talagang hindi available ang storage system.

Matapos matanggap ang naturang kumpirmasyon, ang arbiter ay naglulunsad ng isang malayong pamamaraan para sa paglipat ng replikasyon at pagpapataas ng pagmamapa sa mga replika na iyon na aktibo (pangunahin) sa nahulog na sistema ng imbakan, at nagpapadala ng isang utos sa pangalawang sistema ng imbakan upang baguhin ang mga replika mula sa pangalawa tungo sa pangunahin at itaas ang pagmamapa. Kaya, ang pangalawang sistema ng imbakan, nang naaayon, ay nagsasagawa ng mga pamamaraang ito, at pagkatapos ay nagbibigay ng access sa mga nawawalang LUN mula sa sarili nito.

Bakit kailangan ang karagdagang pag-verify? Para sa korum. Ibig sabihin, dapat kumpirmahin ng mayorya ng kabuuang kakaiba (3) na bilang ng mga miyembro ng cluster ang pagbagsak ng isa sa mga cluster node. Pagkatapos lamang ay tiyak na tama ang desisyong ito. Ito ay kinakailangan upang maiwasan ang maling paglipat at, nang naaayon, split-brain.

Ang hakbang 2 ng oras ay tumatagal ng humigit-kumulang 5 - 10 segundo, kaya, isinasaalang-alang ang oras na kinakailangan upang matukoy ang kawalan (5 segundo), sa loob ng 10 - 15 segundo pagkatapos ng aksidente, ang mga LUN mula sa nahulog na sistema ng imbakan ay awtomatikong magagamit upang gumana sa live sistema ng imbakan.

Malinaw na upang maiwasan ang pagkawala ng mga koneksyon sa mga host, kailangan mo ring mag-ingat upang mai-configure nang tama ang mga timeout sa mga host. Ang inirerekomendang timeout ay hindi bababa sa 30 segundo. Pipigilan nito ang host na putulin ang koneksyon sa storage system habang nagpapalipat-lipat ng load sakaling magkaroon ng sakuna at masisigurong walang mga pagkaantala sa I/O.

Maghintay sandali, lumalabas na kung ang lahat ay napakahusay sa metrocluster, bakit kailangan natin ng regular na pagtitiklop?

Sa katotohanan, ang lahat ay hindi gaanong simple.

Isaalang-alang natin ang mga kalamangan at kahinaan ng metrocluster

Kaya, napagtanto namin na ang mga halatang bentahe ng metrocluster kumpara sa maginoo na pagtitiklop ay:

• Buong automation, tinitiyak ang kaunting oras ng pagbawi sa kaganapan ng isang sakuna;
• Iyon lang :-).

At ngayon, pansin, ang kahinaan:

• Gastos ng solusyon. Kahit na ang metrocluster sa mga sistema ng Aerodisk ay hindi nangangailangan ng karagdagang paglilisensya (ang parehong lisensya ay ginagamit para sa replica), ang halaga ng solusyon ay mas mataas pa rin kaysa sa paggamit ng kasabay na pagtitiklop. Kakailanganin mong ipatupad ang lahat ng kinakailangan para sa isang kasabay na replika, kasama ang mga kinakailangan para sa metrocluster na nauugnay sa karagdagang paglipat at karagdagang site (tingnan ang pagpaplano ng metrocluster);
• Ang pagiging kumplikado ng solusyon. Ang metrocluster ay mas kumplikado kaysa sa isang regular na replika, at nangangailangan ng higit na pansin at pagsisikap para sa pagpaplano, pagsasaayos at dokumentasyon.

Sa bandang huli. Ang Metrocluster ay tiyak na isang napaka-technologically advanced at magandang solusyon kapag kailangan mo talagang magbigay ng RTO sa ilang segundo o minuto. Ngunit kung walang ganoong gawain, at ang RTO sa mga oras ay OK para sa negosyo, kung gayon walang punto sa pagbaril ng mga maya mula sa isang kanyon. Ang karaniwang pagtitiklop ng manggagawa-magsasaka ay sapat na, dahil ang isang metro cluster ay magdudulot ng mga karagdagang gastos at komplikasyon ng imprastraktura ng IT.

Pagpaplano ng Metrocluster

Hindi sinasabi ng seksyong ito na isang komprehensibong gabay sa disenyo ng metrocluster, ngunit ipinapakita lamang ang mga pangunahing direksyon na dapat gawin kung magpasya kang bumuo ng ganoong sistema. Samakatuwid, kapag aktwal na nagpapatupad ng metrocluster, tiyaking isama ang tagagawa ng storage system (iyon ay, kami) at iba pang nauugnay na mga system para sa mga konsultasyon.

Mga lugar

Gaya ng nakasaad sa itaas, ang isang metrocluster ay nangangailangan ng hindi bababa sa tatlong mga site. Dalawang data center kung saan gagana ang mga storage system at mga kaugnay na system, pati na rin ang ikatlong site kung saan gagana ang arbitrator.

Ang inirerekomendang distansya sa pagitan ng mga data center ay hindi hihigit sa 40 kilometro. Malaki ang posibilidad na magdulot ng mga karagdagang pagkaantala ang mas malaking distansya, na sa kaso ng metrocluster ay lubhang hindi kanais-nais. Paalalahanan ka namin na ang mga pagkaantala ay dapat na hanggang 5 millisecond, bagama't ipinapayong panatilihin ang mga ito sa loob ng 2.

Inirerekomenda na suriin din ang mga pagkaantala sa panahon ng proseso ng pagpaplano. Anumang higit pa o mas matanda na provider na nagbibigay ng optical fiber sa pagitan ng mga data center ay maaaring mag-ayos ng isang pagsusuri sa kalidad nang medyo mabilis.

Tulad ng para sa mga pagkaantala bago ang arbitrator (iyon ay, sa pagitan ng ikatlong site at ang unang dalawa), ang inirerekumendang delay threshold ay hanggang sa 200 milliseconds, iyon ay, ang isang regular na corporate VPN na koneksyon sa Internet ay angkop.

Lumipat at Networking

Hindi tulad ng replication scheme, kung saan sapat na upang ikonekta ang mga storage system mula sa iba't ibang mga site, ang metrocluster scheme ay nangangailangan ng pagkonekta sa mga host sa parehong storage system sa iba't ibang mga site. Upang gawing mas malinaw kung ano ang pagkakaiba, ang parehong mga scheme ay ipinapakita sa ibaba.

Tulad ng makikita mula sa diagram, ang aming site 1 host ay tumitingin sa parehong storage system 1 at storage system 2. Gayundin, sa kabaligtaran, ang site 2 host ay tumitingin sa parehong storage system 2 at storage system 1. Iyon ay, nakikita ng bawat host ang parehong mga sistema ng imbakan. Ito ay isang paunang kinakailangan para sa pagpapatakbo ng metrocluster.

Siyempre, hindi na kailangang ikonekta ang bawat host gamit ang optical cord sa isa pang data center; walang port o cord ang magiging sapat. Ang lahat ng koneksyong ito ay dapat gawin sa pamamagitan ng Ethernet 10G+ o FibreChannel 8G+ switch (FC ay para lamang sa pagkonekta ng mga host at storage system para sa IO, ang replication channel ay kasalukuyang available lamang sa pamamagitan ng IP (Ethernet 10G+).

Ngayon ng ilang mga salita tungkol sa topology ng network. Ang isang mahalagang punto ay ang tamang pagsasaayos ng mga subnet. Kinakailangang agad na tukuyin ang ilang mga subnet para sa mga sumusunod na uri ng trapiko:

• Ang replication subnet kung saan isi-synchronize ang data sa pagitan ng mga storage system. Maaaring may ilan sa kanila, sa kasong ito ay hindi mahalaga, ang lahat ay nakasalalay sa kasalukuyang (naipatupad na) topology ng network. Kung mayroong dalawa sa kanila, kung gayon ay malinaw na ang pagruruta ay dapat na i-configure sa pagitan nila;
• Mga subnet ng imbakan kung saan maa-access ng mga host ang mga mapagkukunan ng imbakan (kung ito ay iSCSI). Dapat mayroong isang ganoong subnet sa bawat data center;
• Kontrolin ang mga subnet, iyon ay, tatlong mga routable na subnet sa tatlong site kung saan pinamamahalaan ang mga storage system, at ang arbiter ay matatagpuan din doon.

Hindi namin isinasaalang-alang ang mga subnet para sa pag-access ng mga mapagkukunan ng host dito, dahil lubos silang nakadepende sa mga gawain.

Ang paghihiwalay ng iba't ibang trapiko sa iba't ibang mga subnet ay lubhang mahalaga (lalo na mahalaga na paghiwalayin ang replika mula sa I/O), dahil kung paghaluin mo ang lahat ng trapiko sa isang "makapal" na subnet, ang trapikong ito ay magiging imposibleng pamahalaan, at sa ang mga kondisyon ng dalawang data center na maaari pa rin itong magdulot ng magkaibang mga opsyon sa pagbangga sa network. Hindi namin malalalim ang isyung ito sa loob ng balangkas ng artikulong ito, dahil mababasa mo ang tungkol sa pagpaplano ng network na nakaunat sa pagitan ng mga data center sa mga mapagkukunan ng mga tagagawa ng kagamitan sa network, kung saan ito ay inilarawan nang detalyado.

Pagsasaayos ng arbiter

Ang arbiter ay dapat magbigay ng access sa lahat ng management interface ng storage system sa pamamagitan ng ICMP at SSH protocols. Dapat mo ring isipin ang tungkol sa failsafe ng arbiter. Mayroong isang nuance dito.

Ang arbiter failover ay lubos na kanais-nais, ngunit hindi kinakailangan. Ano ang mangyayari kung ang referee ay bumagsak sa maling oras?

• Ang pagpapatakbo ng metrocluster sa normal na mode ay hindi magbabago, dahil Ang arbtir ay ganap na walang epekto sa pagpapatakbo ng metrocluster sa normal na mode (ang gawain nito ay upang ilipat ang pag-load sa pagitan ng mga sentro ng data sa isang napapanahong paraan)
• Bukod dito, kung ang tagapamagitan para sa isang kadahilanan o iba pa ay bumagsak at "nakatulog" ng isang aksidente sa data center, kung gayon walang paglipat na mangyayari, dahil walang sinuman ang magbibigay ng mga kinakailangang switching command at mag-organisa ng isang korum. Sa kasong ito, ang metrocluster ay magiging isang regular na scheme na may replikasyon, na kailangang manu-manong ilipat sa panahon ng sakuna, na makakaapekto sa RTO.

Ano ang kasunod nito? Kung talagang kailangan mong tiyakin ang isang minimum na RTO, kailangan mong tiyakin na ang arbiter ay fault-tolerant. Mayroong dalawang mga pagpipilian para dito:

• Maglunsad ng virtual machine na may arbiter sa isang fault-tolerant hypervisor, sa kabutihang palad lahat ng adult hypervisors ay sumusuporta sa fault tolerance;
• Kung sa ikatlong site (sa isang maginoo na opisina) ikaw ay tamad na mag-install ng isang normal na kumpol at walang umiiral na hypervozor cluster, pagkatapos ay nagbigay kami ng isang hardware na bersyon ng arbiter, na ginawa sa isang 2U box kung saan dalawang ordinaryong Gumagana ang mga x-86 server at maaaring makaligtas sa isang lokal na pagkabigo.

Lubos naming inirerekumenda na tiyakin ang fault tolerance ng arbiter, sa kabila ng katotohanang hindi ito kailangan ng metrocluster sa normal na mode. Ngunit tulad ng ipinapakita ng parehong teorya at kasanayan, kung bubuo ka ng isang tunay na maaasahang imprastraktura na hindi patunay ng sakuna, mas mabuting gawin itong ligtas. Mas mainam na protektahan ang iyong sarili at ang iyong negosyo mula sa "batas ng kakulitan," iyon ay, mula sa kabiguan ng parehong arbitrator at isa sa mga site kung saan matatagpuan ang sistema ng imbakan.

Arkitektura ng solusyon

Isinasaalang-alang ang mga kinakailangan sa itaas, nakukuha namin ang sumusunod na pangkalahatang arkitektura ng solusyon.

Ang mga LUN ay dapat na pantay na ipamahagi sa dalawang lugar upang maiwasan ang matinding overload. Kasabay nito, kapag sizing sa parehong mga data center, dapat mong isama hindi lamang double volume (na kinakailangan upang mag-imbak ng data nang sabay-sabay sa dalawang storage system), ngunit double performance din sa IOPS at MB/s upang maiwasan ang pagkasira ng application sa ang kaganapan ng pagkabigo ng isa sa mga data center.

Hiwalay, tandaan namin na sa wastong diskarte sa pag-size (iyon ay, sa kondisyon na ibinigay namin ang wastong itaas na limitasyon ng IOPS at MB/s, pati na rin ang mga kinakailangang mapagkukunan ng CPU at RAM), kung isa sa mga sistema ng imbakan sa nabigo ang metro cluster, hindi magkakaroon ng malubhang pagbaba sa pagganap sa ilalim ng mga kondisyon na pansamantalang trabaho sa isang storage system.

Ito ay ipinaliwanag sa pamamagitan ng katotohanan na kapag ang dalawang site ay tumatakbo nang sabay-sabay, ang sabay-sabay na pagtitiklop ay "kumakain" sa kalahati ng pagganap ng pagsulat, dahil ang bawat transaksyon ay dapat na nakasulat sa dalawang sistema ng imbakan (katulad ng RAID-1/10). Kaya, kung nabigo ang isa sa mga sistema ng imbakan, pansamantalang mawawala ang impluwensya ng pagtitiklop (hanggang sa mabawi ang nabigong sistema ng imbakan), at magkakaroon tayo ng dalawang beses na pagtaas sa pagganap ng pagsulat. Matapos ma-restart ang mga LUN ng nabigong sistema ng imbakan sa gumaganang sistema ng imbakan, ang dalawang beses na pagtaas na ito ay mawawala dahil sa katotohanang lumilitaw ang pag-load mula sa mga LUN ng iba pang sistema ng imbakan, at bumalik tayo sa parehong antas ng pagganap na mayroon tayo bago ang "fall", ngunit sa loob lamang ng balangkas ng isang site.

Sa tulong ng karampatang sukat, matitiyak mo ang mga kondisyon kung saan hindi mararamdaman ng mga user ang pagkabigo ng isang buong sistema ng imbakan. Ngunit inuulit namin muli, nangangailangan ito ng napakaingat na sukat, kung saan, sa pamamagitan ng paraan, maaari kang makipag-ugnay sa amin nang libre :-).

Pag-set up ng metrocluster

Ang pag-set up ng metrocluster ay halos kapareho sa pagse-set up ng regular na pagtitiklop, na inilarawan namin sa nakaraang artikulo. Samakatuwid, tumuon lamang tayo sa mga pagkakaiba. Nag-set up kami ng bench sa laboratoryo batay sa arkitektura sa itaas, sa kaunting bersyon lamang: dalawang storage system na konektado sa pamamagitan ng 10G Ethernet, dalawang 10G switch at isang host na tumitingin sa mga switch sa parehong storage system na may 10G port. Ang arbiter ay tumatakbo sa isang virtual machine.

Kapag nag-configure ng mga virtual IP (VIP) para sa isang replika, dapat mong piliin ang uri ng VIP - para sa metrocluster.

Gumawa kami ng dalawang replication link para sa dalawang LUN at ipinamahagi ang mga ito sa dalawang storage system: LUN TEST Primary sa storage system 1 (METRO link), LUN TEST2 Primary para sa storage system 2 (METRO2 link).

Para sa kanila, nag-configure kami ng dalawang magkaparehong target (sa aming kaso iSCSI, ngunit sinusuportahan din ang FC, pareho ang logic ng pag-setup).

Sistema ng imbakan1:

Sistema ng imbakan2:

Para sa mga koneksyon sa pagtitiklop, ginawa ang mga pagmamapa sa bawat sistema ng imbakan.

Sistema ng imbakan1:

Sistema ng imbakan2:

Nag-set up kami ng multipath at ipinakita ito sa host.

Pagse-set up ng arbitrator

Hindi mo kailangang gumawa ng anumang espesyal sa mismong arbiter; kailangan mo lang itong paganahin sa ikatlong site, bigyan ito ng IP at i-configure ang access dito sa pamamagitan ng ICMP at SSH. Ang pag-setup mismo ay ginagawa mula sa mga system ng imbakan mismo. Sa kasong ito, sapat na upang i-configure ang arbiter nang isang beses sa alinman sa mga controllers ng imbakan sa metrocluster; ang mga setting na ito ay awtomatikong ipapamahagi sa lahat ng mga controller.

Sa seksyong Remote replication>> Metrocluster (sa anumang controller)>> ang "Configure" button.

Ipinasok namin ang IP ng arbiter, pati na rin ang mga control interface ng dalawang remote na controllers ng imbakan.

Pagkatapos nito, kailangan mong paganahin ang lahat ng mga serbisyo (ang pindutang "I-restart ang Lahat"). Kung muling na-configure sa hinaharap, dapat na i-restart ang mga serbisyo para magkabisa ang mga setting.

Sinusuri namin na gumagana ang lahat ng mga serbisyo.

Kinukumpleto nito ang pag-setup ng metrocluster.

Crash test

Ang pagsubok sa pag-crash sa aming kaso ay magiging simple at mabilis, dahil ang pag-andar ng pagtitiklop (paglipat, pagkakapare-pareho, atbp.) ay tinalakay sa huling artikulo. Samakatuwid, upang masubukan ang pagiging maaasahan ng metrocluster, sapat na para sa amin na suriin ang automation ng pag-detect ng pagkabigo, paglipat at kawalan ng mga pagkalugi sa pag-record (I/O stops).

Upang gawin ito, tinutularan namin ang isang kumpletong kabiguan ng isa sa mga system ng imbakan sa pamamagitan ng pisikal na pag-off sa parehong mga controllers nito, na sinimulan munang kopyahin ang isang malaking file sa LUN, na dapat na i-activate sa iba pang sistema ng imbakan.

Huwag paganahin ang isang storage system. Sa pangalawang sistema ng imbakan nakikita namin ang mga alerto at mensahe sa mga log na nawala ang koneksyon sa kalapit na sistema. Kung ang mga notification sa pamamagitan ng SMTP o SNMP monitoring ay na-configure, ang administrator ay makakatanggap ng kaukulang mga notification.

Eksaktong 10 segundo mamaya (makikita sa parehong mga screenshot), awtomatikong naging Pangunahin sa gumaganang storage system ang METRO replication connection (ang Primary sa failed storage system). Gamit ang umiiral na pagmamapa, nanatiling available ang LUN TEST sa host, bumaba ng kaunti ang recording (sa loob ng ipinangakong 10 porsiyento), ngunit hindi naantala.

Matagumpay na natapos ang pagsubok.

Summing up

Ang kasalukuyang pagpapatupad ng metrocluster sa AERODISK Engine N-series storage system ay ganap na nagbibigay-daan sa paglutas ng mga problema kung saan kinakailangan na alisin o bawasan ang downtime para sa mga serbisyong IT at tiyakin ang kanilang operasyon 24/7/365 na may kaunting gastos sa paggawa.

Masasabi natin, siyempre, na ang lahat ng ito ay teorya, perpektong kondisyon ng laboratoryo, at iba pa... PERO mayroon tayong ilang ipinatupad na mga proyekto kung saan ipinatupad natin ang functionality ng disaster-resilience, at gumagana nang perpekto ang mga system. Ang isa sa aming medyo kilalang mga customer, na gumagamit lamang ng dalawang sistema ng imbakan sa isang disaster-proof configuration, ay sumang-ayon na mag-publish ng impormasyon tungkol sa proyekto, kaya sa susunod na bahagi ay pag-uusapan natin ang pagpapatupad ng labanan.

Salamat, inaasahan namin ang isang produktibong talakayan.

Pinagmulan: www.habr.com