Kumusta, mga mambabasa ng Habr! Ang paksa ng artikulong ito ay ang pagpapatupad ng mga tool sa pagbawi ng kalamidad sa mga system ng imbakan ng AERODISK Engine. Sa una, nais naming magsulat sa isang artikulo tungkol sa parehong mga tool: pagtitiklop at metrocluster, ngunit, sa kasamaang-palad, ang artikulo ay naging masyadong mahaba, kaya hinati namin ang artikulo sa dalawang bahagi. Mula sa simple hanggang sa kumplikado. Sa artikulong ito, magse-set up kami at susubok ng kasabay na pagtitiklop - ibababa namin ang isang data center, at sisirain din ang channel ng komunikasyon sa pagitan ng mga data center at tingnan kung ano ang mangyayari.
Ang aming mga customer ay madalas na nagtatanong sa amin ng iba't ibang mga katanungan tungkol sa pagtitiklop, kaya bago magpatuloy sa pag-set up at pagsubok sa pagpapatupad ng mga replika, sasabihin namin sa iyo ang kaunti tungkol sa kung ano ang pagtitiklop sa imbakan.
Isang kaunting teorya
Ang pagtitiklop sa mga storage system ay isang tuluy-tuloy na proseso ng pagtiyak ng pagkakakilanlan ng data sa ilang mga storage system nang sabay-sabay. Sa teknikal, ang pagtitiklop ay ginagawa sa dalawang paraan.
Kasabay na pagtitiklop β ito ay pagkopya ng data mula sa pangunahing storage system patungo sa backup, na sinusundan ng mandatoryong kumpirmasyon mula sa parehong storage system na ang data ay naitala at nakumpirma. Ito ay pagkatapos ng kumpirmasyon sa magkabilang panig (parehong mga sistema ng imbakan) na ang data ay itinuturing na naitala at maaaring magamit. Tinitiyak nito ang garantisadong pagkakakilanlan ng data sa lahat ng storage system na kalahok sa replica.
Ang mga pakinabang ng pamamaraang ito:
- Palaging magkapareho ang data sa lahat ng storage system
Cons:
- Mataas na halaga ng solusyon (mabilis na mga channel ng komunikasyon, mamahaling optical fiber, long-wave transceiver, atbp.)
- Mga paghihigpit sa distansya (sa loob ng ilang sampu-sampung kilometro)
- Walang proteksyon laban sa pagkasira ng lohikal na data (kung ang data ay nasira (sinadya o hindi sinasadya) sa pangunahing sistema ng imbakan, awtomatiko at agad itong masira sa backup, dahil ang data ay palaging magkapareho (iyan ang kabalintunaan)
Asynchronous na pagtitiklop β ito rin ay pagkopya ng data mula sa pangunahing sistema ng imbakan patungo sa backup, ngunit may tiyak na pagkaantala at hindi na kailangang kumpirmahin ang pagsulat sa kabilang panig. Maaari kang magtrabaho kaagad sa data pagkatapos i-record ito sa pangunahing sistema ng imbakan, at sa backup na sistema ng imbakan ang data ay magagamit pagkatapos ng ilang oras. Ang pagkakakilanlan ng data sa kasong ito, siyempre, ay hindi natiyak sa lahat. Ang data sa backup na sistema ng imbakan ay palaging medyo "sa nakaraan."
Mga kalamangan ng asynchronous na pagtitiklop:
- Mababang gastos na solusyon (anumang mga channel ng komunikasyon, opsyonal na optika)
- Walang mga paghihigpit sa distansya
- Sa backup na sistema ng imbakan, ang data ay hindi lumalala kung ito ay nasira sa pangunahing isa (hindi bababa sa ilang oras); kung ang data ay nagiging masira, maaari mong palaging ihinto ang replika upang maiwasan ang pagkasira ng data sa backup na sistema ng imbakan
Cons:
- Ang data sa iba't ibang data center ay palaging hindi magkapareho
Kaya, ang pagpili ng replication mode ay depende sa mga layunin ng negosyo. Kung kritikal para sa iyo na ang backup na data center ay naglalaman ng eksaktong kaparehong data gaya ng pangunahing data center (ibig sabihin, kinakailangan sa negosyo para sa RPO = 0), pagkatapos ay kailangan mong ilabas ang pera at tiisin ang mga limitasyon ng isang kasabay replika. At kung ang pagkaantala sa estado ng data ay katanggap-tanggap o walang pera, tiyak na kailangan mong gamitin ang asynchronous na pamamaraan.
Hiwalay din nating i-highlight ang naturang mode (mas tiyak, isang topology) bilang isang metrocluster. Sa metrocluster mode, ginagamit ang synchronous replication, ngunit, hindi katulad ng regular na replica, pinapayagan ng metrocluster ang parehong storage system na gumana sa active mode. Yung. wala kang paghihiwalay sa pagitan ng aktibo at standby na mga data center. Ang mga application ay gumagana nang sabay-sabay sa dalawang storage system, na pisikal na matatagpuan sa iba't ibang data center. Ang mga downtime sa panahon ng mga aksidente sa naturang topology ay napakaliit (RTO, kadalasang minuto). Sa artikulong ito hindi namin isasaalang-alang ang aming pagpapatupad ng metrocluster, dahil ito ay isang napakalaking at malawak na paksa, kaya't maglalaan kami ng isang hiwalay, susunod na artikulo dito, bilang pagpapatuloy ng isang ito.
Gayundin, kadalasan, kapag pinag-uusapan natin ang tungkol sa pagtitiklop gamit ang mga sistema ng imbakan, maraming tao ang may makatwirang tanong: > βMaraming mga aplikasyon ang may sariling mga tool sa pagtitiklop, bakit gumagamit ng pagtitiklop sa mga sistema ng imbakan? Mas mabuti ba o mas masahol pa?
Walang malinaw na sagot dito, kaya narito ang mga argumento FOR at CONS:
Mga argumento PARA sa pagtitiklop ng imbakan:
- Ang pagiging simple ng solusyon. Sa isang tool, maaari mong kopyahin ang iyong buong set ng data, anuman ang uri ng pag-load at application. Kung gagamit ka ng replika mula sa mga application, kakailanganin mong i-configure nang hiwalay ang bawat application. Kung mayroong higit sa 2 sa kanila, kung gayon ito ay lubhang matrabaho at mahal (karaniwang nangangailangan ng hiwalay at hindi libreng lisensya para sa bawat aplikasyon ang pagtitiklop ng aplikasyon. Ngunit higit pa sa ibaba).
- Maaari mong kopyahin ang anumang bagay - anumang application, anumang data - at ito ay palaging pare-pareho. Maraming (karamihan) na application ang walang kakayahan sa pagtitiklop, at ang mga replika mula sa storage system ay ang tanging paraan upang magbigay ng proteksyon mula sa mga sakuna.
- Hindi na kailangang mag-overpay para sa pagpapagana ng pagtitiklop ng application. Bilang isang patakaran, hindi ito mura, tulad ng mga lisensya para sa isang replika ng sistema ng imbakan. Ngunit kailangan mong magbayad para sa isang lisensya para sa pagtitiklop ng imbakan nang isang beses, at ang isang lisensya para sa replika ng aplikasyon ay kailangang bilhin nang hiwalay para sa bawat aplikasyon. Kung mayroong maraming mga naturang aplikasyon, kung gayon ito ay nagkakahalaga ng isang magandang sentimos at ang halaga ng mga lisensya para sa pagtitiklop ng imbakan ay nagiging isang patak sa karagatan.
Mga argumento LABAN sa pagtitiklop ng imbakan:
- Ang replika sa pamamagitan ng mga application ay may higit na pag-andar mula sa punto ng view ng mga application mismo, mas alam ng application ang data nito (malinaw naman), kaya mayroong higit pang mga pagpipilian para sa pagtatrabaho sa kanila.
- Ang mga tagagawa ng ilang mga application ay hindi ginagarantiya ang pagkakapare-pareho ng kanilang data kung ang pagtitiklop ay ginagawa gamit ang mga tool ng third-party. *
* - kontrobersyal na thesis. Halimbawa, ang isang kilalang tagagawa ng DBMS ay opisyal na nagdedeklara sa napakatagal na panahon na ang kanilang DBMS ay maaari lamang kopyahin nang normal gamit ang kanilang mga paraan, at ang natitirang bahagi ng pagtitiklop (kabilang ang mga sistema ng imbakan) ay "hindi totoo." Ngunit ipinakita ng buhay na hindi ito ganoon. Malamang (ngunit hindi ito tiyak) hindi lang ito ang pinakatapat na pagtatangka na magbenta ng higit pang mga lisensya sa mga customer.
Bilang isang resulta, sa karamihan ng mga kaso, ang pagtitiklop mula sa sistema ng imbakan ay mas mahusay, dahil Ito ay isang mas simple at mas murang opsyon, ngunit may mga kumplikadong kaso kung kailan kinakailangan ang partikular na pag-andar ng application, at kinakailangan upang gumana sa pagtitiklop sa antas ng aplikasyon.
Tapos na sa teorya, ngayon ay magsanay
I-configure namin ang replica sa aming lab. Sa mga kondisyon ng laboratoryo, tinularan namin ang dalawang data center (sa katunayan, dalawang magkatabing rack na tila nasa magkaibang mga gusali). Ang stand ay binubuo ng dalawang sistema ng imbakan ng Engine N2, na konektado sa isa't isa sa pamamagitan ng mga optical cable. Ang isang pisikal na server na nagpapatakbo ng Windows Server 2016 ay konektado sa parehong storage system gamit ang 10Gb Ethernet. Ang paninindigan ay medyo simple, ngunit hindi nito binabago ang kakanyahan.
Sa eskematiko, ganito ang hitsura:
Logically, ang pagtitiklop ay isinaayos tulad ng sumusunod:
Ngayon tingnan natin ang pag-andar ng pagtitiklop na mayroon tayo ngayon.
Dalawang mode ang sinusuportahan: asynchronous at synchronous. Ito ay lohikal na ang synchronous mode ay limitado sa pamamagitan ng distansya at komunikasyon channel. Sa partikular, ang synchronous mode ay nangangailangan ng paggamit ng fiber bilang physics at 10 Gigabit Ethernet (o mas mataas).
Ang sinusuportahang distansya para sa kasabay na pagtitiklop ay 40 kilometro, ang halaga ng pagkaantala ng optical channel sa pagitan ng mga data center ay hanggang 2 millisecond. Sa pangkalahatan, gagana ito sa malalaking pagkaantala, ngunit magkakaroon ng malakas na pagbagal sa panahon ng pag-record (na lohikal din), kaya kung nagpaplano ka ng sabay-sabay na pagtitiklop sa pagitan ng mga sentro ng data, dapat mong suriin ang kalidad ng mga optika at mga pagkaantala.
Ang mga kinakailangan para sa asynchronous na pagtitiklop ay hindi masyadong seryoso. Mas tiyak, wala sila doon. Magagawa ang anumang gumaganang koneksyon sa Ethernet.
Sa kasalukuyan, sinusuportahan ng sistema ng imbakan ng AERODISK ENGINE ang pagtitiklop para sa mga block device (LUNs) sa pamamagitan ng Ethernet protocol (over copper o optical). Para sa mga proyekto kung saan kinakailangan ang pagtitiklop sa pamamagitan ng SAN fabric sa Fiber Channel, kasalukuyan kaming nagdaragdag ng naaangkop na solusyon, ngunit hindi pa ito handa, kaya sa aming kaso, Ethernet lang.
Maaaring gumana ang pagtitiklop sa pagitan ng anumang mga sistema ng imbakan ng serye ng ENGINE (N1, N2, N4) mula sa mga junior system hanggang sa mga mas luma at vice versa.
Ang functionality ng parehong replication mode ay ganap na magkapareho. Nasa ibaba ang higit pang mga detalye tungkol sa kung ano ang magagamit:
- Replikasyon "isa sa isa" o "isa sa isa", iyon ay, ang klasikong bersyon na may dalawang data center, ang pangunahing at ang backup
- Ang pagtitiklop ay "isa sa marami" o "isa sa marami", i.e. ang isang LUN ay maaaring kopyahin sa ilang mga sistema ng imbakan nang sabay-sabay
- I-activate, i-deactivate, at "reverse" replication, ayon sa pagkakabanggit, para paganahin, i-disable, o baguhin ang direksyon ng replication
- Available ang pagtitiklop para sa parehong RDG (Raid Distributed Group) at DDP (Dynamic Disk Pool) pool. Gayunpaman, ang mga LUN ng isang RDG pool ay maaari lamang kopyahin sa isa pang RDG. Pareho sa DDP.
Marami pang maliliit na feature, ngunit walang partikular na punto sa paglilista ng mga ito; babanggitin namin ang mga ito habang nagse-set up kami.
Pag-set up ng replikasyon
Ang proseso ng pag-setup ay medyo simple at binubuo ng tatlong yugto.
- Ang pagsasaayos ng network
- Setup ng storage
- Pagse-set up ng mga panuntunan (koneksyon) at pagmamapa
Ang isang mahalagang punto sa pag-set up ng pagtitiklop ay ang unang dalawang yugto ay dapat na ulitin sa malayong sistema ng imbakan, ang ikatlong yugto - sa pangunahing isa lamang.
Pagse-set up ng mga mapagkukunan ng network
Ang unang hakbang ay upang i-configure ang mga port ng network kung saan ipapadala ang trapiko ng pagtitiklop. Upang gawin ito, kailangan mong paganahin ang mga port at itakda ang kanilang mga IP address sa seksyong Front-end adapters.
Pagkatapos nito, kailangan naming lumikha ng isang pool (sa aming kaso RDG) at isang virtual na IP para sa pagtitiklop (VIP). Ang VIP ay isang lumulutang na IP address na nakatali sa dalawang "pisikal" na address ng mga controller ng storage (ang mga port na kaka-configure lang namin). Ito ang magiging pangunahing interface ng pagtitiklop. Maaari ka ring magpatakbo hindi sa isang VIP, ngunit sa isang VLAN, kung kailangan mong magtrabaho kasama ang naka-tag na trapiko.
Ang proseso ng paglikha ng isang VIP para sa isang replika ay hindi gaanong naiiba sa paglikha ng isang VIP para sa I/O (NFS, SMB, iSCSI). Sa kasong ito, lumikha kami ng isang regular na VIP (walang VLAN), ngunit siguraduhing ipahiwatig na ito ay para sa pagtitiklop (kung wala ang pointer na ito, hindi kami makakapagdagdag ng VIP sa panuntunan sa susunod na hakbang).
Ang VIP ay dapat nasa parehong subnet gaya ng mga IP port kung saan ito lumulutang.
Inuulit namin ang mga setting na ito sa isang malayuang sistema ng imbakan, na may ibang IP, siyempre.
Ang mga VIP mula sa iba't ibang mga sistema ng imbakan ay maaaring nasa iba't ibang mga subnet, ang pangunahing bagay ay mayroong pagruruta sa pagitan nila. Sa aming kaso, ang halimbawang ito ay eksaktong ipinapakita (192.168.3.XX at 192.168.2.XX)
Kinukumpleto nito ang paghahanda ng bahagi ng network.
Pagse-set up ng storage
Ang pag-set up ng storage para sa isang replica ay naiiba lamang sa karaniwan dahil ginagawa namin ang pagmamapa sa pamamagitan ng isang espesyal na menu na "Replication Mapping". Kung hindi, ang lahat ay pareho sa normal na pag-setup. Ngayon, sa pagkakasunud-sunod.
Sa dating ginawang pool R02, kailangan mong gumawa ng LUN. Gawin natin ito at tawagin itong LUN1.
Kailangan din nating lumikha ng parehong LUN sa isang malayuang sistema ng imbakan na magkapareho ang laki. Lumilikha kami. Para maiwasan ang kalituhan, tawagan natin ang remote na LUN LUN1R
Kung kailangan naming kumuha ng LUN na mayroon na, habang nagse-set up ng replica, kakailanganin naming i-unmount ang productive na LUN na ito mula sa host, at gumawa lang ng walang laman na LUN na magkapareho ang laki sa remote storage system.
Kumpleto na ang pag-setup ng storage, magpatuloy tayo sa paggawa ng panuntunan sa pagtitiklop.
Pagse-set up ng mga panuntunan sa pagtitiklop o mga link ng pagtitiklop
Pagkatapos gumawa ng mga LUN sa storage system, na siyang magiging pangunahin sa ngayon, iko-configure namin ang replication rule na LUN1 sa storage system 1 hanggang LUN1R sa storage system 2.
Ginagawa ang setting sa menu na βRemote replicationβ.
Gumawa tayo ng panuntunan. Upang gawin ito, kailangan mong tukuyin ang tatanggap ng replica. Doon din namin itinakda ang pangalan ng koneksyon at ang uri ng pagtitiklop (kasabay o asynchronous).
Sa field na "mga remote system" idinaragdag namin ang aming storage system2. Upang magdagdag, kailangan mong gamitin ang mga management IP storage system (MGR) at ang pangalan ng remote na LUN kung saan kami magsasagawa ng pagtitiklop (sa aming kaso, LUN1R). Ang mga control IP ay kailangan lamang sa yugto ng pagdaragdag ng isang koneksyon; ang trapiko ng pagtitiklop ay hindi ipapadala sa pamamagitan ng mga ito; ang dating na-configure na VIP ay gagamitin para dito.
Nasa yugto na ito maaari tayong magdagdag ng higit sa isang remote system para sa topology na "isa sa marami": i-click ang button na "add node", tulad ng nasa figure sa ibaba.
Sa aming kaso, mayroon lamang isang malayong sistema, kaya nililimitahan namin ang aming sarili dito.
Handa na ang panuntunan. Pakitandaan na awtomatiko itong idinaragdag sa lahat ng mga kalahok sa pagtitiklop (sa aming kaso ay dalawa sa kanila). Maaari kang lumikha ng maraming ganoong panuntunan hangga't gusto mo, para sa anumang bilang ng mga LUN at sa anumang direksyon. Halimbawa, upang balansehin ang pagkarga, maaari nating kopyahin ang bahagi ng LUN mula sa storage system 1 hanggang storage system 2, at ang isa pang bahagi, sa kabaligtaran, mula sa storage system 2 hanggang storage system 1.
Sistema ng imbakan1. Kaagad pagkatapos ng paglikha, nagsimula ang pag-synchronize.
Sistema ng imbakan2. Nakikita namin ang parehong panuntunan, ngunit natapos na ang pag-synchronize.
Ang LUN1 sa storage system 1 ay nasa Pangunahing tungkulin, ibig sabihin, ito ay aktibo. Ang LUN1R sa storage system 2 ay nasa papel na Secondary, ibig sabihin, naka-standby ito kung sakaling mabigo ang storage system 1.
Ngayon ay maaari na nating ikonekta ang ating LUN sa host.
Kami ay kumonekta sa pamamagitan ng iSCSI, bagama't maaari rin itong gawin sa pamamagitan ng FC. Ang pag-set up ng pagmamapa sa pamamagitan ng iSCSI LUN sa isang replica ay halos hindi naiiba sa karaniwang sitwasyon, kaya hindi namin ito isasaalang-alang nang detalyado dito. Kung mayroon man, ang prosesong ito ay inilarawan sa artikulong "'.
Ang pagkakaiba lang ay gumagawa kami ng pagmamapa sa menu na "Replication Mapping".
Nag-set up kami ng pagmamapa at ibinigay ang LUN sa host. Nakita ng host ang LUN.
I-format namin ito sa isang lokal na file system.
Ayan, kumpleto na ang setup. Susunod na darating ang mga pagsubok.
Pagsubok
Susubukan namin ang tatlong pangunahing senaryo.
- Regular na pagpapalit ng tungkulin Pangalawa > Pangunahin. Kailangan ang regular na pagpapalit ng papel kung sakaling, halimbawa, kailangan nating magsagawa ng ilang preventive operations sa pangunahing data center at sa panahong ito, para maging available ang data, ililipat natin ang load sa backup data center.
- Pang-emergency na pagpapalit ng tungkulin Pangalawa > Pangunahin (pagkabigo sa data center). Ito ang pangunahing senaryo kung saan umiiral ang pagtitiklop, na makakatulong na makaligtas sa kumpletong pagkabigo ng data center nang hindi humihinto sa kumpanya sa mahabang panahon.
- Pagkasira ng mga channel ng komunikasyon sa pagitan ng mga data center. Sinusuri ang tamang pag-uugali ng dalawang sistema ng imbakan sa mga kondisyon kung saan sa ilang kadahilanan ay hindi magagamit ang channel ng komunikasyon sa pagitan ng mga data center (halimbawa, ang isang excavator ay naghukay sa maling lugar at sinira ang madilim na optika).
Una, magsisimula kaming magsulat ng data sa aming LUN (pagsusulat ng mga file na may random na data). Agad naming nakita na ang channel ng komunikasyon sa pagitan ng mga storage system ay ginagamit. Madaling maunawaan ito kung bubuksan mo ang pagsubaybay sa pagkarga ng mga port na responsable para sa pagtitiklop.
Ang parehong mga sistema ng imbakan ay mayroon na ngayong "kapaki-pakinabang" na data, maaari naming simulan ang pagsubok.
Kung sakali, tingnan natin ang mga hash sum ng isa sa mga file at isulat ang mga ito.
Regular na pagpapalit ng tungkulin
Ang pagpapatakbo ng paglipat ng mga tungkulin (pagbabago ng direksyon ng pagtitiklop) ay maaaring gawin sa anumang storage system, ngunit kakailanganin mo pa ring pumunta sa pareho, dahil kakailanganin mong i-disable ang pagmamapa sa Primary, at paganahin ito sa Secondary (na magiging Primary ).
Marahil isang makatwirang tanong ang lumitaw ngayon: bakit hindi i-automate ito? Ang sagot ay: ito ay simple, ang pagtitiklop ay isang simpleng paraan ng disaster resilience, batay lamang sa mga manual na operasyon. Upang i-automate ang mga operasyong ito, mayroong metrocluster mode; ito ay ganap na awtomatiko, ngunit ang pagsasaayos nito ay mas kumplikado. Magsusulat kami tungkol sa pag-set up ng metrocluster sa susunod na artikulo.
Sa pangunahing storage system, hindi namin pinapagana ang pagmamapa upang matiyak na hihinto ang pagre-record.
Pagkatapos sa isa sa mga sistema ng imbakan (hindi mahalaga, sa pangunahing o backup) sa menu na "Remote replication", piliin ang aming koneksyon REPL1 at i-click ang "Baguhin ang tungkulin".
Pagkatapos ng ilang segundo, ang LUN1R (backup storage system) ay magiging Pangunahin.
Nagmapa kami ng LUN1R na may storage system2.
Pagkatapos nito, ang aming E: drive ay awtomatikong nakakabit sa host, sa pagkakataong ito ay "dumating" ito mula sa LUN1R.
Kung sakali, ikinukumpara namin ang mga hash sums.
Magkapareho. Lumipas ang pagsusulit.
Failover. Nabigo ang data center
Sa ngayon, ang pangunahing sistema ng imbakan pagkatapos ng regular na paglipat ay ang sistema ng imbakan 2 at LUN1R, ayon sa pagkakabanggit. Para tularan ang isang aksidente, papatayin namin ang power sa parehong storage controllers2.
Wala nang access dito.
Tingnan natin kung ano ang nangyayari sa storage system 1 (ang backup sa ngayon).
Nakita namin na ang Pangunahing LUN (LUN1R) ay hindi magagamit. Ang isang mensahe ng error ay lumitaw sa mga log, sa panel ng impormasyon, at gayundin sa panuntunan ng pagtitiklop mismo. Alinsunod dito, kasalukuyang hindi available ang data mula sa host.
Baguhin ang tungkulin ng LUN1 sa Pangunahin.
Gumagawa ako ng pagmamapa sa host.
Tiyaking lalabas ang drive E sa host.
Sinusuri namin ang hash.
Maayos ang lahat. Ang sistema ng imbakan ay matagumpay na nakaligtas sa pagbagsak ng data center, na aktibo. Ang tinatayang oras na ginugol namin sa pagkonekta sa "reversal" ng replikasyon at pagkonekta sa LUN mula sa backup na data center ay humigit-kumulang 3 minuto. Malinaw na sa totoong produksyon ang lahat ay mas kumplikado, at bilang karagdagan sa mga aksyon na may mga sistema ng imbakan, kailangan mong magsagawa ng higit pang mga operasyon sa network, sa mga host, sa mga application. At sa buhay ang panahong ito ay magiging mas mahaba.
Dito nais kong isulat na ang lahat, ang pagsubok ay matagumpay na nakumpleto, ngunit huwag magmadali. Ang pangunahing sistema ng imbakan ay "nagsisinungaling", alam natin na kapag ito ay "nahulog", ito ay nasa Pangunahing tungkulin. Ano ang mangyayari kung biglang mag-on? Magkakaroon ng dalawang Pangunahing tungkulin, na katumbas ng data corruption? Suriin natin ngayon.
Bigla nating i-on ang pinagbabatayan na sistema ng imbakan.
Naglo-load ito ng ilang minuto at pagkatapos ay bumalik sa serbisyo pagkatapos ng maikling pag-synchronize, ngunit sa papel na Pangalawa.
OK lahat. Hindi nangyari ang split-brain. Pinag-isipan namin ito, at palaging pagkatapos ng pagbagsak, ang sistema ng imbakan ay tumataas sa papel na Pangalawa, anuman ang papel nito sa "habang buhay." Ngayon ay masasabi nating sigurado na matagumpay ang pagsubok sa pagkabigo ng data center.
Pagkabigo ng mga channel ng komunikasyon sa pagitan ng mga data center
Ang pangunahing gawain ng pagsubok na ito ay upang matiyak na ang sistema ng imbakan ay hindi magsisimulang kumilos nang kakaiba kung pansamantalang mawawala ang mga channel ng komunikasyon sa pagitan ng dalawang mga sistema ng imbakan at pagkatapos ay lilitaw muli.
Kaya. Idiskonekta namin ang mga wire sa pagitan ng mga sistema ng imbakan (isipin natin na hinukay sila ng isang excavator).
Sa Primary nakita natin na walang koneksyon sa Secondary.
Sa Sekondarya nakita natin na walang koneksyon sa Primary.
Ang lahat ay gumagana nang maayos, at patuloy kaming nagsusulat ng data sa pangunahing sistema ng imbakan, iyon ay, garantisadong naiiba sila sa backup, iyon ay, sila ay "naghiwalay".
Sa ilang minuto ay "inaayusin" namin ang channel ng komunikasyon. Sa sandaling makita ng mga sistema ng imbakan ang isa't isa, ang pag-synchronize ng data ay awtomatikong naisaaktibo. Walang kailangan mula sa administrator dito.
Pagkaraan ng ilang oras, nakumpleto ang pag-synchronize.
Ang koneksyon ay naibalik, ang pagkawala ng mga channel ng komunikasyon ay hindi naging sanhi ng anumang mga sitwasyong pang-emergency, at pagkatapos ng paglipat, awtomatikong naganap ang pag-synchronize.
Natuklasan
Sinuri namin ang teorya - kung ano ang kailangan at bakit, nasaan ang mga kalamangan at nasaan ang mga kahinaan. Pagkatapos ay nag-set up kami ng kasabay na pagtitiklop sa pagitan ng dalawang sistema ng imbakan.
Susunod, ang mga pangunahing pagsusuri ay isinagawa para sa normal na paglipat, pagkabigo sa sentro ng data at pagkabigo ng channel ng komunikasyon. Sa lahat ng kaso, gumana nang maayos ang storage system. Walang pagkawala ng data at ang mga administratibong operasyon ay pinananatiling pinakamababa para sa manu-manong senaryo.
Sa susunod na gagawin naming kumplikado ang sitwasyon at ipakita kung paano gumagana ang lahat ng logic na ito sa isang automated metrocluster sa active-active mode, iyon ay, kapag ang parehong storage system ay pangunahin, at ang pag-uugali sa kaso ng mga pagkabigo ng storage system ay ganap na awtomatiko.
Mangyaring magsulat ng mga komento, matutuwa kaming makatanggap ng mahusay na pagpuna at praktikal na payo.
Hanggang sa muli.
Pinagmulan: www.habr.com