Halo, para pembaca Habr! Ing artikel pungkasan, kita ngomong babagan cara pemulihan bencana sing gampang ing sistem panyimpenan AERODISK ENGINE - replikasi. Ing artikel iki, kita bakal nyilem menyang topik sing luwih rumit lan menarik - metrocluster, yaiku, sarana perlindungan bencana otomatis kanggo rong pusat data, ngidini pusat data bisa digunakake ing mode aktif-aktif. Kita bakal pitutur marang kowe, nuduhake, break lan ndandani.
Kaya biasane, teori pisanan
Metrocluster minangka kluster sing nyebar ing sawetara situs ing sawijining kutha utawa wilayah. Tembung "kluster" jelas nuduhake manawa komplek kasebut otomatis, yaiku, ngoper simpul kluster yen ana kegagalan kanthi otomatis.
Ing kene ana prabédan utama antarane metrocluster lan replikasi biasa. Otomasi operasi. Yaiku, yen ana kedadeyan tartamtu (gagal pusat data, saluran sing rusak, lan liya-liyane), sistem panyimpenan bakal nindakake tumindak sing dibutuhake kanggo njaga kasedhiyan data. Nalika nggunakake replika biasa, tumindak kasebut ditindakake kanthi manual utawa sebagian dening administrator.
Apa kanggo?
Tujuan utama sing ditindakake para pelanggan nalika nggunakake implementasi metrocluster tartamtu yaiku nyilikake RTO (Tujuan Wektu Pemulihan). Yaiku, kanggo nyilikake wektu pemulihan layanan IT sawise gagal. Yen sampeyan nggunakake replikasi biasa, wektu pemulihan bakal luwih suwe tinimbang wektu pemulihan kanthi metrocluster. Kenging punapa? Prasaja banget. Administrator kudu ana ing mejane lan ngalih replikasi kanthi manual, lan metrocluster nindakake iki kanthi otomatis.
Yen sampeyan ora duwe administrator khusus sing ora turu, ora mangan, ora ngrokok utawa lara, lan ngawasi kahanan sistem panyimpenan 24 jam saben dina, mula ora ana cara kanggo njamin manawa pangurus bakal bisa. kasedhiya kanggo ngalih manual nalika gagal.
Patut, RTO yen ora ana metrocluster utawa admin abadi saka tingkat 99 saka layanan tugas administrator bakal padha karo jumlah wektu ngoper kabeh sistem lan wektu maksimum sawise administrator wis dijamin kanggo miwiti karya. karo sistem panyimpenan lan sistem sing gegandhengan.
Mangkono, kita teka menyang kesimpulan sing jelas yen metrocluster kudu digunakake yen syarat kanggo RTO yaiku menit, dudu jam utawa dina, yaiku, nalika ana kegagalan pusat data sing paling awon, departemen IT kudu nyedhiyakake wektu kanggo bisnis kanggo mulihake akses menyang IT -layanan ing menit, utawa malah detik.
Carane ora iku bisa?
Ing tingkat ngisor, metrocluster nggunakake mekanisme kanggo replikasi data sinkron, sing diterangake ing artikel sadurunge (pirsani. ). Wiwit replikasi sinkron, syarat kasebut cocog, utawa luwih tepat:
- serat optik minangka fisika, 10 gigabit Ethernet (utawa luwih);
- jarak antarane pusat data ora luwih saka 40 kilometer;
- tundha saluran optik antarane pusat data (antarane sistem panyimpenan) nganti 5 milliseconds (optimal 2).
Kabeh syarat kasebut minangka penasihat, yaiku, metrocluster bakal bisa digunakake sanajan syarat kasebut ora ditindakake, nanging kita kudu ngerti manawa akibat saka ora netepi syarat kasebut padha karo kalem ing operasi loro sistem panyimpenan ing metrocluster.
Dadi, replika sinkron digunakake kanggo nransfer data ing antarane sistem panyimpenan, lan kepiye replika otomatis ngalih lan, sing paling penting, kepiye supaya ora pamisah-otak? Kanggo nindakake iki, ing tingkat sing luwih dhuwur, entitas tambahan digunakake - arbiter.
Kepiye cara arbitrator lan apa tugase?
Arbiter minangka mesin virtual cilik utawa kluster hardware sing kudu diluncurake ing situs katelu (contone, ing kantor) lan menehi akses menyang sistem panyimpenan liwat ICMP lan SSH. Sawise diluncurake, arbiter kudu nyetel IP, banjur saka sisih panyimpenan nuduhake alamate, ditambah karo alamat pengontrol remot sing melu metrocluster. Sawise iki, wasit wis siyap kerja.
Arbiter terus-terusan ngawasi kabeh sistem panyimpenan ing metrocluster lan yen sistem panyimpenan tartamtu ora kasedhiya, sawise ngonfirmasi ora kasedhiya saka anggota kluster liyane (salah sawijining sistem panyimpenan "urip"), dheweke mutusake kanggo miwiti prosedur kanggo ngoper aturan replikasi. lan pemetaan.
Titik penting banget. Arbitrator kudu tansah ana ing situs sing beda karo sing ana ing sistem panyimpenan, yaiku, ora ana ing pusat data 1, ing ngendi sistem panyimpenan 1 dipasang, utawa ing pusat data 2, ing ngendi sistem panyimpenan 2 dipasang.
Kenging punapa? Amarga iki mung siji-sijine cara arbitrator, kanthi bantuan salah sawijining sistem panyimpenan sing isih urip, bisa kanthi jelas lan akurat nemtokake tiba ing rong situs sing dipasang ing sistem panyimpenan. Cara liya kanggo nyelehake arbiter bisa nyebabake pamisah-otak.
Saiki ayo nyilem menyang rincian karya arbitrator.
Arbiter mbukak sawetara layanan sing terus-terusan polling kabeh pengontrol panyimpenan. Yen asil polling beda karo sing sadurunge (kasedhiya / ora kasedhiya), banjur dicathet ing database cilik, sing uga bisa digunakake ing arbiter.
Ayo ndeleng logika saka karya arbitrator luwih rinci.
Langkah 1: Nemtokake ora kasedhiya. Acara gagal sistem panyimpenan yaiku ora ana ping saka loro pengontrol sistem panyimpenan sing padha sajrone 5 detik.
Langkah 2. Miwiti prosedur ngoper. Sawise wasit wis nyadari yen salah sawijining sistem panyimpenan ora kasedhiya, dheweke ngirim panjaluk menyang sistem panyimpenan "urip" kanggo mesthekake yen sistem panyimpenan "mati" pancen mati.
Sawise nampa prentah kasebut saka arbiter, sistem panyimpenan kapindho (urip) tambahan mriksa kasedhiyan sistem panyimpenan pisanan sing tiba lan, yen ora ana, ngirim konfirmasi menyang arbiter saka guess. Sistem panyimpenan pancen ora kasedhiya.
Sawise nampa konfirmasi kasebut, arbiter ngluncurake prosedur remot kanggo ngoper replikasi lan ngunggahake pemetaan ing replika sing aktif (utama) ing sistem panyimpenan sing tiba, lan ngirim prentah menyang sistem panyimpenan kapindho kanggo ngganti replika kasebut saka sekunder menyang primer lan mundhakaken pemetaan. Inggih, sistem panyimpenan kaloro, miturut, nindakake prosedur kasebut, lan banjur menehi akses menyang LUNs ilang saka dhewe.
Napa verifikasi tambahan dibutuhake? Kanggo kuorum. Tegese, mayoritas saka total ganjil (3) jumlah anggota kluster kudu konfirmasi tiba saka salah siji simpul kluster. Mung banjur keputusan iki mesthi bener. Iki perlu kanggo ngindhari owah-owahan sing salah lan, kanthi mangkono, pamisah-otak.
Wektu langkah 2 njupuk kira-kira 5 - 10 detik, mangkono, njupuk menyang akun wektu sing dibutuhake kanggo nemtokake unavailability (5 detik), ing 10 - 15 detik sawise kacilakan, LUN saka sistem panyimpenan tiba bakal kasedhiya kanthi otomatis kanggo nggarap urip. sistem panyimpenan.
Cetha yen supaya ora kelangan sambungan karo host, sampeyan uga kudu ati-ati kanggo ngatur wektu entek kanthi bener ing host. Wektu entek sing disaranake paling sethithik 30 detik. Iki bakal nyegah inang saka severing sambungan kanggo sistem panyimpenan sak mbukak ngoper ing acara saka bilai lan bisa mesthekake yen ana I / O interruptions.
Ngenteni sedhela, ternyata yen kabeh apik banget karo metrocluster, kenapa kita kudu replikasi biasa?
Ing kasunyatan, kabeh ora dadi prasaja.
Ayo nimbang pros lan cons saka metrocluster
Dadi, kita ngerti manawa kaluwihan metrocluster dibandhingake karo replikasi konvensional yaiku:
- Otomatisasi lengkap, njamin wektu pemulihan minimal nalika ana bencana;
- Iku kabeh :-).
Lan saiki, manungsa waé, cons:
- Biaya solusi. Sanajan metrocluster ing sistem Aerodisk ora mbutuhake lisensi tambahan (lisensi sing padha digunakake kanggo replika), biaya solusi kasebut bakal luwih dhuwur tinimbang nggunakake replikasi sinkron. Sampeyan kudu ngleksanakake kabeh syarat kanggo replika sinkron, plus syarat kanggo metrocluster sing digandhengake karo ngoper tambahan lan situs tambahan (ndeleng perencanaan metrocluster);
- Kompleksitas solusi. Metrocluster luwih rumit tinimbang replika biasa, lan mbutuhake perhatian lan usaha luwih akeh kanggo perencanaan, konfigurasi lan dokumentasi.
wekasane. Metrocluster mesthi dadi solusi teknologi sing maju lan apik nalika sampeyan pancene kudu menehi RTO ing sawetara detik utawa menit. Nanging yen ora ana tugas kuwi, lan RTO ing jam OK kanggo bisnis, banjur ora ana titik kanggo njupuk sparrows saka mriem. Replikasi buruh-tani biasa cukup, amarga kluster metro bakal nyebabake biaya tambahan lan komplikasi infrastruktur IT.
Perencanaan Metrocluster
Bagean iki ora ngaku minangka pandhuan lengkap kanggo desain metrocluster, nanging mung nuduhake pituduh utama sing kudu ditindakake yen sampeyan mutusake kanggo mbangun sistem kasebut. Mulane, nalika bener ngleksanakake metrocluster, mesthine kudu melu produsen sistem panyimpenan (yaiku, kita) lan sistem liyane sing gegandhengan kanggo konsultasi.
Panggonan
Kaya kasebut ing ndhuwur, metrocluster mbutuhake minimal telung situs. Loro pusat data ing ngendi sistem panyimpenan lan sistem sing gegandhengan bakal dioperasikake, uga situs katelu ing ngendi arbitrator bakal bisa digunakake.
Jarak sing disaranake antarane pusat data ora luwih saka 40 kilometer. Jarak sing luwih gedhe bisa nyebabake penundaan tambahan, sing ing kasus metrocluster pancen ora dikarepake. Ayo kita ngelingake yen wektu tundha kudu nganti 5 milidetik, sanajan luwih becik tetep ing 2.
Dianjurake kanggo mriksa telat uga sak proses planning. Sembarang panyedhiya luwih utawa kurang diwasa sing nyedhiyakake serat optik ing antarane pusat data bisa ngatur pemeriksaan kualitas kanthi cepet.
Kanggo telat sadurunge arbitrator (yaiku, ing antarane situs katelu lan loro pisanan), ambang tundha sing disaranake nganti 200 milidetik, yaiku, sambungan VPN perusahaan biasa liwat Internet cocok.
Ngalih lan Jaringan
Ora kaya skema replikasi, sing cukup kanggo nyambungake sistem panyimpenan saka macem-macem situs, skema metrocluster mbutuhake nyambungake host karo loro sistem panyimpenan ing situs sing beda. Kanggo luwih cetha apa bedane, loro skema ditampilake ing ngisor iki.
Kaya sing bisa dideleng saka diagram, host situs 1 kita ndeleng sistem panyimpenan 1 lan sistem panyimpenan 2. Kajaba iku, host situs 2 ndeleng sistem panyimpenan 2 lan sistem panyimpenan 1. Sing, saben host ndeleng loro sistem panyimpenan. Iki minangka prasyarat kanggo operasi metrocluster.
Mesthi wae, ora perlu nyambungake saben host nganggo kabel optik menyang pusat data liyane ora ana port utawa kabel sing cukup. Kabeh sambungan kasebut kudu digawe liwat switch Ethernet 10G + utawa FibreChannel 8G + (FC mung kanggo nyambungake host lan sistem panyimpenan kanggo IO, saluran replikasi saiki mung kasedhiya liwat IP (Ethernet 10G +).
Saiki sawetara tembung babagan topologi jaringan. Titik penting yaiku konfigurasi subnet sing bener. Sampeyan kudu langsung nemtokake sawetara subnet kanggo jinis lalu lintas ing ngisor iki:
- Subnet replikasi ing ngendi data bakal disinkronake ing antarane sistem panyimpenan. Bisa uga ana sawetara, ing kasus iki ora masalah, kabeh gumantung saka topologi jaringan sing saiki (wis dileksanakake). Yen ana loro, banjur temenan nuntun kudu diatur ing antarane;
- Subnet panyimpenan ing ngendi host bakal ngakses sumber daya panyimpenan (yen iku iSCSI). Mesthine ana siji subnet ing saben pusat data;
- Subnet kontrol, yaiku, telung subnet sing bisa diowahi ing telung situs sing dikelola sistem panyimpenan, lan arbiter uga ana ing kana.
Kita ora nganggep subnet kanggo ngakses sumber daya host ing kene, amarga padha gumantung banget marang tugas kasebut.
Misahake lalu lintas sing beda-beda menyang subnet sing beda-beda iku penting banget (utamane penting kanggo misahake replika saka I / O), amarga yen sampeyan nyampur kabeh lalu lintas dadi siji subnet "kandel", banjur lalu lintas iki ora bisa diatur, lan ing kahanan loro pusat data iki isih bisa nimbulaké opsi tabrakan jaringan beda. Kita ora bakal njlèntrèhaké masalah iki ing framework saka artikel iki, amarga sampeyan bisa maca babagan planning jaringan digawe dowo antarane pusat data ing sumber daya saka manufaktur peralatan jaringan, ngendi iki diterangake ing rinci.
Konfigurasi arbiter
Arbiter kudu menehi akses menyang kabeh antarmuka manajemen sistem panyimpenan liwat protokol ICMP lan SSH. Sampeyan uga kudu mikir babagan failsafe saka arbiter. Ana nuansa ing kene.
Arbiter failover banget dikarepake, nanging ora dibutuhake. Apa sing kedadeyan yen wasit nabrak ing wektu sing salah?
- Operasi saka metrocluster ing mode normal ora bakal ngganti, amarga arbtir pancen ora ana pengaruh ing operasi metrocluster ing mode normal (tugase yaiku ngalih beban ing antarane pusat data kanthi pas wektune)
- Menapa malih, yen arbiter kanggo siji utawa alesan liyane tiba lan "turu liwat" kacilakan ing pusat data, banjur ora ngoper bakal kelakon, amarga ora bakal ana siji kanggo menehi prentah ngoper perlu lan ngatur kuorum. Ing kasus iki, metrocluster bakal dadi skema reguler kanthi replikasi, sing kudu diowahi kanthi manual sajrone bencana, sing bakal mengaruhi RTO.
Apa sing diterusake saka iki? Yen pancene kudu mesthekake RTO minimal, sampeyan kudu mesthekake arbiter punika fault-tolerant. Ana rong pilihan kanggo iki:
- Bukak mesin virtual karo arbiter ing hypervisor toleran fault, bok manawa kabeh hypervisor diwasa ndhukung toleransi fault;
- Yen ing situs katelu (ing kantor konvensional) sampeyan kesed nginstal kluster normal lan ora ana kluster hypervozor sing wis ana, mula kita wis nyedhiyakake versi hardware saka arbiter, sing digawe ing kothak 2U sing ana loro biasa. server x-86 bisa digunakake lan bisa slamet saka kegagalan lokal.
Disaranake banget kanggo mesthekake toleransi fault saka arbiter, senadyan kasunyatan sing metrocluster ora perlu ing mode normal. Nanging minangka teori lan praktik nuduhake, yen sampeyan mbangun infrastruktur tahan bencana sing bisa dipercaya, mula luwih apik kanggo muter kanthi aman. Iku luwih apik kanggo nglindhungi dhewe lan bisnis saka "hukum meanness," yaiku, saka Gagal loro arbitrator lan salah siji saka situs ngendi sistem panyimpenan dumunung.
Arsitektur solusi
Ngelingi syarat ing ndhuwur, kita entuk arsitektur solusi umum ing ngisor iki.
LUN kudu disebarake kanthi merata ing rong situs supaya ora kakehan. Ing wektu sing padha, nalika ukuran ing loro pusat data, sampeyan kudu nyakup ora mung volume pindho (sing perlu kanggo nyimpen data bebarengan ing rong sistem panyimpenan), nanging uga kinerja pindho ing IOPS lan MB / s kanggo nyegah degradasi aplikasi ing. acara Gagal salah siji pusat data.
Kapisah, kita nyathet yen kanthi pendekatan sing tepat kanggo ukuran (yaiku, yen kita wis nyedhiyakake wates ndhuwur IOPS lan MB / s sing tepat, uga sumber daya CPU lan RAM sing dibutuhake), yen salah sawijining sistem panyimpenan ing kluster metro gagal, ora bakal ana penurunan kinerja sing serius ing kahanan kerja sementara ing siji sistem panyimpenan.
Iki diterangno dening kasunyatan sing nalika loro situs sing operasi bebarengan, réplikasi sinkron "mangan" setengah saka kinerja nulis, wiwit saben transaksi kudu ditulis kanggo loro sistem panyimpenan (padha RAID-1/10). Dadi, yen salah sawijining sistem panyimpenan gagal, pengaruh replikasi sauntara (nganti sistem panyimpenan sing gagal pulih) ilang, lan kita entuk peningkatan kinerja nulis kaping pindho. Sawise LUN sistem panyimpenan sing gagal diwiwiti maneh ing sistem panyimpenan sing digunakake, paningkatan kaping pindho iki ilang amarga kasunyatane beban katon saka LUN sistem panyimpenan liyane, lan kita bali menyang tingkat kinerja sing padha sadurunge. "tiba", nanging mung ing framework siji situs.
Kanthi bantuan ukuran sing kompeten, sampeyan bisa njamin kahanan sing pangguna ora bakal ngrasakake kegagalan kabeh sistem panyimpenan. Nanging kita mbaleni maneh, iki mbutuhake ukuran sing ati-ati, sing, kanthi cara, sampeyan bisa ngubungi kita kanthi gratis :-).
Nggawe metrocluster
Nyetel metrocluster meh padha karo nyetel replikasi biasa, sing diterangake ing . Mulane, ayo fokus mung ing beda. Kita nyiyapake bangku ing laboratorium adhedhasar arsitektur ing ndhuwur, mung ing versi paling tithik: rong sistem panyimpenan disambungake liwat 10G Ethernet, loro 10G ngalih lan siji inang sing katon liwat ngalih ing loro sistem panyimpenan karo 10G bandar. Arbiter mlaku ing mesin virtual.
Nalika ngonfigurasi IP virtual (VIP) kanggo replika, sampeyan kudu milih jinis VIP - kanggo metrocluster.
Kita nggawe rong tautan replikasi kanggo rong LUN lan disebarake ing rong sistem panyimpenan: LUN TEST Utama ing sistem panyimpenan 1 (link METRO), LUN TEST2 Utama kanggo sistem panyimpenan 2 (link METRO2).
Kanggo wong-wong mau, kita ngatur loro target sing padha (ing kasus iSCSI, nanging FC uga didhukung, logika persiyapan padha).
Sistem panyimpenan 1:
Sistem panyimpenan 2:
Kanggo sambungan replikasi, pemetaan digawe ing saben sistem panyimpenan.
Sistem panyimpenan 1:
Sistem panyimpenan 2:
Kita nyiyapake multipath lan diwenehi menyang host.
Nggawe arbitrator
Sampeyan ora perlu nindakake apa-apa khusus karo arbiter dhewe, sampeyan mung kudu ngaktifake ing situs katelu, menehi IP lan ngatur akses liwat ICMP lan SSH. Persiyapan kasebut dhewe ditindakake saka sistem panyimpenan dhewe. Ing kasus iki, cukup kanggo ngatur arbiter sapisan ing sembarang pengontrol panyimpenan ing metrocluster setelan kasebut bakal disebarake menyang kabeh pengontrol kanthi otomatis.
Ing bagean Replikasi remot>> Metrocluster (ing pengontrol apa wae)>> tombol "Konfigurasi".
Kita ngetik IP saka arbiter, uga antarmuka kontrol loro pengontrol panyimpenan remot.
Sawise iki, sampeyan kudu ngaktifake kabeh layanan (tombol "Wiwiti maneh kabeh"). Yen dikonfigurasi maneh ing mangsa ngarep, layanan kudu diwiwiti maneh supaya setelan bisa ditrapake.
Kita mriksa manawa kabeh layanan mlaku.
Iki ngrampungake persiyapan metrocluster.
Tes kacilakan
Tes kacilakan ing kasus kita bakal cukup prasaja lan cepet, amarga fungsi replikasi (ngoper, konsistensi, lan sapiturute) wis dibahas ing . Mulane, kanggo nguji linuwih metrocluster, cukup kanggo mriksa otomatisasi deteksi kegagalan, ngoper lan ora ana kerugian rekaman (I / O mandheg).
Kanggo nindakake iki, kita niru kegagalan lengkap salah sawijining sistem panyimpenan kanthi mateni loro pengontrol kasebut kanthi fisik, kanthi miwiti nyalin file gedhe menyang LUN, sing kudu diaktifake ing sistem panyimpenan liyane.
Pateni siji sistem panyimpenan. Ing sistem panyimpenan kapindho kita ndeleng tandha lan pesen ing log sing sambungan karo sistem tetanggan wis ilang. Yen kabar liwat pemantauan SMTP utawa SNMP dikonfigurasi, administrator bakal nampa kabar sing cocog.
Persis 10 detik sabanjure (katon ing loro gambar), sambungan replikasi METRO (sing dadi Utama ing sistem panyimpenan gagal) kanthi otomatis dadi Utama ing sistem panyimpenan sing digunakake. Nggunakake pemetaan sing wis ana, LUN TEST tetep kasedhiya kanggo host, rekaman dicelupake sethithik (ing 10 persen sing dijanjekake), nanging ora diselani.
Tes rampung kanthi sukses.
Kanggo ngringkes
Implementasi metrocluster saiki ing sistem panyimpenan AERODISK Engine N-seri ngidini ngrampungake masalah sing perlu kanggo ngilangi utawa nyuda downtime kanggo layanan IT lan njamin operasi 24/7/365 kanthi biaya tenaga kerja minimal.
Kita bisa ngomong, mesthine, kabeh iki minangka teori, kondisi laboratorium sing becik, lan liya-liyane ... NANGING kita duwe sawetara proyek sing wis dileksanakake ing ngendi kita wis ngetrapake fungsionalitas tahan bencana, lan sistem kasebut bisa digunakake kanthi sampurna. Salah sawijining pelanggan sing cukup kondhang, sing mung nggunakake rong sistem panyimpenan ing konfigurasi tahan bencana, wis sarujuk kanggo nerbitake informasi babagan proyek kasebut, mula ing bagean sabanjure kita bakal ngomong babagan implementasine pertempuran.
Matur nuwun, kita ngarepake diskusi sing produktif.
Source: www.habr.com
