Pambuka

Sawetara wektu kepungkur aku diwenehi tugas ngembangake kluster failover kanggo PostgreSQL, beroperasi ing sawetara pusat data sing disambungake dening serat optik ing sawijining kutha, lan bisa nahan kegagalan (contone, blackout) saka siji pusat data. Minangka piranti lunak sing tanggung jawab kanggo toleransi fault, Aku milih pacemakeramarga iki minangka solusi resmi saka RedHat kanggo nggawe klompok failover. Iku apik amarga RedHat nyedhiyakake dhukungan, lan amarga solusi iki universal (modular). Kanthi bantuan, bisa njamin toleransi kesalahan ora mung PostgreSQL, nanging uga layanan liyane, nggunakake modul standar utawa nggawe kanggo kabutuhan tartamtu.

Kaputusan iki wungu pitakonan cukup: carane fault-tolerant bakal failover kluster? Kanggo neliti iki, Aku dikembangaké bench test sing simulates macem-macem gagal ing kelenjar kluster, ngenteni layanan dibalèkaké, waras simpul gagal, lan terus testing ing daur ulang. Proyek iki asline diarani hapgsql, nanging suwe-suwe aku bosen karo jeneng kasebut, sing mung duwe siji vokal. Mulane, aku wiwit nelpon database fault-tolerant (lan ngambang IP nuding wong-wong mau) krogan (karakter saka game komputer sing kabeh organ penting diduplikasi), lan simpul, kluster lan proyek kasebut dhewe. tuchanka (planet sing manggon ing krogans).

Saiki manajemen wis ngidini mbukak proyek menyang komunitas open source miturut lisensi MIT. README bakal rauh diterjemahake menyang Inggris (amarga samesthine konsumen utama bakal Pacemaker lan PostgreSQL pangembang), lan aku mutusaké kanggo saiki versi Russian lawas README (sebagean) ing wangun artikel iki.

Kluster disebarake ing mesin virtual VirtualBox. Gunggunge 12 mesin virtual (total 36GiB) bakal disebarake, sing mbentuk 4 klompok fault-tolerant (pilihan beda). Rong kluster pisanan kalebu rong server PostgreSQL, sing ana ing pusat data sing beda, lan server umum. saksi c piranti kuorum (host ing mesin virtual murah ing pusat data katelu), sing ngatasi kahanan sing durung mesthi 50% / 50%, menehi voting kanggo salah siji partai. Kluster katelu ing telung pusat data: siji master, loro budak, ora piranti kuorum. Kluster papat kasusun saka papat server PostgreSQL, loro saben pusat data: siji master, replika liyane, lan uga nggunakake. saksi c piranti kuorum. Papat bisa nahan kegagalan loro server utawa siji pusat data. Solusi iki bisa ditambahake menyang replika sing luwih akeh yen perlu.

Layanan wektu sing akurat ntpd uga reconfigured kanggo toleransi fault, nanging nggunakake cara dhewe ntpd (modus yatim piatu). Server sing dienggo bareng saksi tumindak minangka server NTP tengah, nyebarake wektu kanggo kabeh kluster, saéngga nyinkronake kabeh server karo saben liyane. Yen saksi gagal utawa dadi terisolasi, banjur salah siji saka server kluster (ing kluster) bakal miwiti kanggo mbagekke wektu. Caching tambahan proxy HTTP uga wungu kanggo saksi, kanthi bantuan, mesin virtual liyane duwe akses menyang repositori Yum. Kasunyatane, layanan kayata wektu lan proxy sing akurat bakal di-host ing server khusus, nanging ing stan kasebut di-host ing saksi mung kanggo nyimpen nomer mesin virtual lan papan.

Versi

v0. Bisa digunakake karo CentOS 7 lan PostgreSQL 11 ing VirtualBox 6.1.

Struktur klaster

Kabeh kluster dirancang kanggo dumunung ing sawetara pusat data, digabungake dadi siji jaringan warata lan kudu tahan Gagal utawa isolasi jaringan saka pusat data siji. Mulane punika mokal digunakake kanggo pangayoman marang pamisah-otak teknologi Pacemaker standar disebut STONITH (Tembak Node Liyane Ing Kepala) utawa pager. Intine: yen kelenjar ing kluster wiwit curiga yen ana sing salah karo sawetara simpul, mula ora nanggapi utawa tumindak salah, banjur mateni kanthi paksa liwat piranti "eksternal", umpamane, kertu kontrol IPMI utawa UPS. . Nanging iki mung bisa digunakake ing kasus-kasus ing ngendi, yen ana kegagalan siji, server IPMI utawa UPS terus bisa digunakake. Kene kita rencana kanggo nglindhungi saka Gagal luwih catastrophic, nalika kabeh pusat data gagal (contone, ilang daya). Lan kanthi penolakan kasebut, kabeh stonith-piranti (IPMI, UPS, etc.) uga ora bisa.

Nanging, sistem kasebut adhedhasar ide quorum. Kabeh simpul duwe swara, lan mung sing bisa ndeleng luwih saka setengah saka kabeh kelenjar sing bisa digunakake. Jumlah "setengah + 1" iki diarani kuorum. Yen kuorum ora tekan, banjur simpul mutusake yen ana ing isolasi jaringan lan kudu mateni sumber daya, i.e. iki apa iku pangayoman pamisah-otak. Yen piranti lunak sing tanggung jawab kanggo prilaku iki ora bisa digunakake, mula watchdog, contone, adhedhasar IPMI, kudu bisa.

Yen jumlah simpul genap (kluster ing rong pusat data), mula sing diarani kahanan sing durung mesthi bisa kedadeyan. 50% / 50% (seket seket) nalika isolasi jaringan mbagi klompok persis ing setengah. Mulane, kanggo nomer malah saka simpul, kita nambah piranti kuorum iku daemon undemanding sing bisa dibukak ing mesin virtual paling murah ing pusat data katelu. Dheweke menehi voting menyang salah sawijining segmen (sing dideleng), lan kanthi mangkono ngrampungake kahanan sing durung mesthi 50%/50%. Aku jenenge server sing piranti kuorum bakal diluncurake saksi (terminologi saka repmgr, aku seneng).

Sumber daya bisa dipindhah saka papan menyang papan, contone, saka server sing rusak menyang sing sehat, utawa kanthi prentah saka administrator sistem. Supaya klien ngerti ing ngendi sumber daya sing dibutuhake (ing ngendi nyambungake?), IP ngambang (IP ngambang). Iki minangka IP sing bisa dipindhah Pacemaker ing simpul (kabeh ana ing jaringan sing rata). Saben wong nglambangake sumber daya (layanan) lan bakal ana ing ngendi sampeyan kudu nyambungake supaya entuk akses menyang layanan iki (ing kasus kita, database).

Tuchanka1 (sirkuit kanthi pemadatan)

struktur

Ing idea iki kita duwe akeh database cilik karo mbukak kurang, kang ora duwe bathi kanggo njaga server budak darmabakti ing mode siyaga panas kanggo mung diwaca transaksi (ora perlu kanggo sampah kuwi sumber).

Saben pusat data duwe siji server. Saben server wis loro kedadean PostgreSQL (ing PostgreSQL terminologi padha disebut kluster, nanging supaya kebingungan aku bakal nelpon kedadean (kanthi analogi karo database liyane), lan aku mung bakal nelpon kluster Pacemaker kluster). Siji conto beroperasi ing mode master, lan mung nyedhiyakake layanan (mung IP ngambang sing ndadékaké). Kayata kapindho dianggo minangka abdi kanggo pusat data kapindho, lan bakal nyedhiyani layanan mung yen master sawijining gagal. Wiwit biasane mung siji saka loro (master) bakal nyedhiyani layanan (nglakoni panjalukan), kabeh sumber daya server optimized kanggo master (memori diparengake kanggo shared_buffers cache, etc.), Nanging supaya Kayata kapindho. uga nduweni sumber daya sing cukup (sanajan kanggo operasi suboptimal liwat cache sistem file) yen gagal salah sawijining pusat data. Abdi ora nyedhiyani layanan (ora nindakake maca mung panjalukan) sak operasi normal kluster, supaya ora ana perang kanggo sumber daya karo master ing mesin padha.

Ing kasus rong simpul, toleransi kesalahan mung bisa ditindakake kanthi replikasi asinkron, amarga kanthi replikasi sinkron, kegagalan budak bakal nyebabake mandeg master.

Gagal dadi saksi

Gagal dadi saksi (piranti kuorum) Aku bakal nimbang mung kanggo cluster Tuchanka1, karo kabeh liyane bakal padha crita. Yen saksi gagal, ora ana sing bakal owah ing struktur kluster, kabeh bakal terus mlaku kanthi cara sing padha. Nanging kuorum bakal dadi 2 saka 3, lan mulane, kegagalan sabanjure bakal nyebabake kluster kasebut. Iki isih kudu didandani kanthi cepet.

Tuchanka1 nolak

Gagal salah sawijining pusat data kanggo Tuchanka1. Ing kasus iki saksi menehi voting menyang simpul kapindho ing pusat data kapindho. Ing kana, mantan budak dadi master, minangka asil, loro master makarya ing server sing padha lan loro-lorone IP ngambang kasebut nuding.

Tuchanka 2 (klasik)

struktur

Skema klasik saka rong simpul. Sing nduwé nyambut gawé ing siji, batur sing kapindho. Loro-lorone bisa nglakokake panjaluk (budhak mung diwaca), mula loro-lorone dituduhake kanthi IP float: krogan2 minangka master, krogan2s1 minangka budak. Loro-lorone majikan lan abdi bakal duwe toleransi kesalahan.

Ing kasus rong simpul, toleransi kesalahan mung bisa ditindakake kanthi replikasi asinkron, amarga kanthi replikasi sinkron, kegagalan budak bakal nyebabake mandeg master.

Tuchanka2 nolak

Yen salah siji saka pusat data gagal saksi vote kanggo sing kapindho. Ing siji-sijine pusat data sing bisa digunakake, master bakal diunggahake, lan loro IP ngambang bakal nuduhake: master lan budak. Mesthi wae, conto kasebut kudu dikonfigurasi kanthi cara sing duwe sumber daya sing cukup (watesan sambungan, lan sapiturute) kanggo nampa kabeh sambungan lan panjaluk saka master lan slave float IP bebarengan. Tegese, sajrone operasi normal kudu duwe watesan sing cukup.

Tuchanka4 (akeh budhak)

struktur

Wis nemen liyane. Ana basis data sing nampa akeh panjalukan mung diwaca (kasus khas situs sing ngemot dhuwur). Tuchanka4 minangka kahanan sing bisa uga ana telu utawa luwih budak kanggo nangani panjaluk kasebut, nanging isih ora akeh banget. Kanthi jumlah budak sing akeh banget, kudu nggawe sistem replikasi hirarkis. Ing kasus minimal (ing gambar), saben loro pusat data duwe loro server, saben karo conto PostgreSQL.

Fitur liyane saka skema iki yaiku wis bisa ngatur siji replikasi sinkron. Dikonfigurasi kanggo niru, yen bisa, menyang pusat data liyane, tinimbang replika ing pusat data sing padha karo master. Master lan saben abdi ditunjuk dening IP ngambang. Begjanipun, antarane babu bakal perlu kanggo imbangan panjalukan piye wae sql proxy, contone, ing sisih klien. Beda jinis klien bisa uga mbutuhake macem-macem jinis sql proxy, lan mung pangembang klien ngerti sapa sing butuh. Fungsi iki bisa dileksanakake dening daemon eksternal utawa perpustakaan klien (kolam sambungan), lsp. Kabeh iki ngluwihi topik kluster database failover (failover SQL proxy bisa ditindakake kanthi mandiri, bebarengan karo toleransi kesalahan klien).

Tuchanka4 nolak

Yen salah siji pusat data (yaiku, loro server) gagal, saksi milih sing kapindho. Akibaté, ana rong server sing mlaku ing pusat data kaloro: siji mbukak master, lan master float IP nunjukake (kanggo nampa panjalukan maca-tulis); lan ing server kapindho ana abdi sing mlaku kanthi replikasi sinkron, lan salah sijine IP float budak kasebut (kanggo panjaluk mung diwaca).

Babagan pisanan sing kudu dicathet yaiku ora kabeh IP float budak bakal dadi buruh, nanging mung siji. Lan kanggo nggarap kanthi bener bakal dibutuhake sql proxy dialihake kabeh panjalukan menyang IP ngambang sing isih ana; lan yen sql proxy ora, sampeyan bisa ndhaftar kabeh budak IP ngambang sing dipisahake karo koma ing URL sambungan. Ing kasus iki, karo libpq sambungan bakal menyang IP apa pisanan, iki rampung ing sistem testing otomatis. Mbok ing perpustakaan liyane, contone, JDBC, iki ora bakal bisa lan perlu sql proxy. Iki ditindakake amarga IP ngambang kanggo budak dilarang diunggahake bebarengan ing siji server, supaya bisa disebarake ing antarane server budak yen ana sawetara sing mlaku.

Kapindho: sanajan ana kegagalan pusat data, replikasi sinkron bakal tetep. Lan sanajan ana kegagalan sekunder, yaiku, salah siji saka rong server ing pusat data sing isih ana gagal, kluster kasebut, sanajan bakal mandheg nyedhiyakake layanan, isih bakal nahan informasi babagan kabeh transaksi sing wis ditindakake sing wis menehi konfirmasi komitmen. (ora bakal ana informasi mundhut yen gagal sekunder).

Tuchanka3 (3 pusat data)

struktur

Iki minangka kluster kanggo kahanan ing ngendi ana telung pusat data sing bisa digunakake kanthi lengkap, sing saben duwe server database sing bisa digunakake. Ing kasus iki piranti kuorum ora perlu. Pusat data siji dikelola dening master, loro liyane dikelola dening budak. Replikasi sinkron, ketik ANY (slave1, slave2), yaiku, klien bakal nampa konfirmasi komitmen nalika ana budak sing pertama nanggapi yen dheweke wis nampa komitmen kasebut. Sumber daya dituduhake dening siji IP ngambang kanggo master lan loro kanggo budak. Ora kaya Tuchanka4, kabeh telung IP ngambang iku toleran kesalahan. Kanggo ngimbangi pitakon SQL mung diwaca sing bisa digunakake sql proxy (karo toleransi fault kapisah), utawa nemtokake IP float abdi kanggo setengah saka klien, lan setengah liyane kanggo liyane.

Tuchanka3 nolak

Yen salah siji saka pusat data gagal, loro tetep. Ing siji, master lan IP ngambang saka master diunggahake, ing kaloro - budak lan loro IP float budak (kayata kudu duwe cadangan sumber daya kaping pindho supaya bisa nampa kabeh sambungan saka IP float budak). Replikasi sinkron antarane master lan budak. Uga, kluster bakal nyimpen informasi babagan transaksi sing setya lan dikonfirmasi (ora bakal ilang informasi) yen ana karusakan saka rong pusat data (yen padha ora numpes bebarengan).

Aku mutusake ora nyakup katrangan rinci babagan struktur file lan panyebaran. Sapa wae sing pengin dolanan bisa maca kabeh ing README. Aku mung menehi katrangan babagan tes otomatis.

Sistem tes otomatis

Kanggo nguji toleransi kesalahan klompok kanthi simulasi macem-macem kesalahan, sistem tes otomatis wis digawe. Dibukak dening script test/failure. Skrip bisa njupuk minangka paramèter nomer klompok sing pengin dites. Contone printah iki:

test/failure 2 3

mung bakal nyoba kluster kapindho lan katelu. Yen paramèter ora ditemtokake, kabeh klompok bakal dites. Kabeh kluster dites ing podo karo, lan asil ditampilake ing panel tmux. Tmux nggunakake server tmux darmabakti, supaya script bisa mbukak saka tmux standar, asil ing tmux nested. Aku nyaranake nggunakake terminal ing jendhela gedhe lan karo font cilik. Sadurunge tes diwiwiti, kabeh mesin virtual digulung maneh menyang snapshot nalika skrip rampung setup.

Terminal kasebut dipérang dadi kolom miturut jumlah kluster sing diuji; kanthi gawan (ing gambar) ana papat. Aku bakal njlèntrèhaké isi kolom nggunakake conto Tuchanka2. Panel ing gambar diwenehi nomer:

1. Statistik tes ditampilake ing kene. kolom:
   • kegagalan - jeneng test (fungsi ing script) sing emulates fault.
   • reaksi - wektu rata-rata aritmetika ing detik sajrone kluster mbalekake fungsine. Iki diukur saka wiwitan skrip niru kesalahan nganti wektu kluster mulihake fungsine lan bisa terus nyedhiyakake layanan. Yen wektu cendhak banget, contone, enem detik (iki kedadeyan ing kluster karo sawetara budak (Tuchanka3 lan Tuchanka4)), iki tegese fault ana ing abdi bedo lan ora mengaruhi kinerja ing sembarang cara; ngalih negara cluster.
   • penyimpangan - nuduhake panyebaran (akurasi) regane reaksi nggunakake metode standar deviasi.
   • Count - kaping pirang-pirang tes iki ditindakake.
2. Log cendhak ngidini sampeyan ngevaluasi apa sing ditindakake kluster. Nomer pengulangan (test), stempel wektu lan jeneng operasi ditampilake. Mlaku suwe banget (> 5 menit) nuduhake masalah.
3. jantung (jantung) - wektu saiki. Kanggo pambiji kinerja visual juragan Wektu saiki terus ditulis ing meja kanthi nggunakake master IP float. Yen sukses, asil ditampilake ing panel iki.
4. ngalahake (pulsa) - "wektu saiki", sing sadurunge direkam dening naskah jantung kanggo master, saiki maca saka abdi dalem liwat IP float sawijining. Ngidini sampeyan kanthi visual netepake kinerja budak lan replikasi. Ing Tuchanka1 ora ana budak sing duwe IP float (ora ana budak sing nyedhiyakake layanan), nanging ana rong conto (DB), dadi ora bakal ditampilake ing kene. ngalahakelan jantung conto kapindho.
5. Ngawasi kesehatan cluster nggunakake utilitas pcs mon. Nuduhake struktur, distribusi sumber daya ing node lan informasi migunani liyane.
6. Ngawasi sistem saka saben mesin virtual ing kluster ditampilake ing kene. Ana uga panel liyane gumantung carane akeh mesin virtual kluster wis. Loro grafik Beban CPU (mesin virtual duwe rong prosesor), jeneng mesin virtual, Beban Sistem (jenenge Load Rata-rata amarga rata-rata liwat 5, 10 lan 15 menit), data proses lan alokasi memori.
7. Tilak saka script nindakake testing. Yen ana malfunction - gangguan dadakan saka operasi utawa siklus nunggu telas - kene sampeyan bisa ndeleng alesan kanggo prilaku iki.

Pengujian ditindakake ing rong tahap. Kaping pisanan, skrip ngliwati kabeh jinis tes, kanthi acak milih mesin virtual sing bakal ditrapake tes iki. Banjur siklus tes tanpa wates ditindakake, mesin virtual lan kesalahan dipilih kanthi acak saben wektu. Mandap dadakan saka script testing (panel ngisor) utawa daur ulang telas nunggu soko (> 5 menit wektu eksekusi kanggo siji operasi, iki bisa katon ing tilak) nuduhake yen sawetara tes ing kluster iki wis gagal.

Saben tes kasusun saka operasi ing ngisor iki:

1. Bukak fungsi sing niru kesalahan.
2. Siap? — ngenteni kluster dibalekake (nalika kabeh layanan diwenehake).
3. Nuduhake wektu entek pemulihan kluster (reaksi).
4. Ndandani - kluster lagi "didandani." Sawise iku kudu bali menyang negara kanthi operasional lan siap kanggo malfunction sabanjuré.

Ing ngisor iki dhaptar tes kanthi katrangan babagan apa sing ditindakake:

• ForkBomb: Nggawe "Out of memory" nggunakake bom garpu.
• OutOfSpace: Hardisk kebak. Nanging tes kasebut rada simbolis; kanthi beban sing ora pati penting sing digawe sajrone tes, PostgreSQL biasane ora gagal nalika hard drive kebak.
• Postgres-KILL: matèni PostgreSQL karo printah killall -KILL postgres.
• Postgres-STOP: nggantung printah PostgreSQL killall -STOP postgres.
• Power Off: "de-energizes" mesin virtual karo printah VBoxManage controlvm "виртуалка" poweroff.
• Reset: overloads mesin virtual karo printah VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: nundha setan SBD kanthi prentah killall -STOP sbd.
• Mati: ngirim printah menyang mesin virtual liwat SSH systemctl poweroff, sistem mati anggun.
• Mbusak link: isolasi jaringan, perintah VBoxManage controlvm "виртуалка" setlinkstate1 off.

Ngrampungake tes nggunakake printah tmux standar "kill-window" Ctrl-b &, utawa printah "detach-client". Ctrl-b d: ing titik iki testing ends, tmux nutup, mesin virtual dipateni.

Masalah sing diidentifikasi sajrone tes

• Saiki watchdog demon sbd dianggo ing mandeg daemon diamati, nanging ora beku wong. Lan, minangka asil, kesalahan sing mung nyebabake pembekuan Corosync и pacemaker, nanging ora gantung sbd... Kanggo mriksa Corosync wis PR #83 (ing GitHub ing sbd), ditampa menyang thread Master. Padha janji (ing PR # 83) sing bakal ana soko padha kanggo Pacemaker, Mugi sing dening Topi Abang 8 bakal nindakake. Nanging "malfungsi" kuwi spekulatif lan bisa gampang disimulasi kanthi artifisial, contone, killall -STOP corosync, nanging ora tau ketemu ing urip nyata.

• У pacemaker ing versi kanggo CentOS 7 salah nyetel sync_timeout у piranti kuorum, asile yen siji simpul gagal, karo sawetara kemungkinan simpul kapindho uga rebooted, sing kudune dipindhah dening master. Diobati kanthi nggedhekake sync_timeout у piranti kuorum sajrone panyebaran (ing script setup/setup1). Amandemen iki ora ditampa dening pangembang pacemaker, nanging dheweke janji bakal ngrancang maneh infrastruktur kasebut kanthi cara kasebut (ing sawetara mangsa sing ora ditemtokake) supaya wektu entek iki bakal diitung kanthi otomatis.

• Yen konfigurasi database nemtokake manawa LC_MESSAGES (pesen teks) Unicode bisa digunakake, f.eks. ru_RU.UTF-8, banjur ing wiwitan postgres ing lingkungan sing lokal ora UTF-8, ucapake ing lingkungan kosong (kene pacungan+pgsqlms(paf) mlaku postgres), banjur log bakal ngemot tandha pitakonan tinimbang UTF-8 aksara. Pangembang PostgreSQL durung setuju babagan apa sing kudu ditindakake ing kasus iki. Iku biaya, sampeyan kudu nginstal LC_MESSAGES=en_US.UTF-8 nalika ngatur (nggawe) conto database.

• Yen wal_receiver_timeout disetel (kanthi standar yaiku 60s), banjur sajrone tes PostgreSQL-STOP ing master ing kluster tuchanka3 lan tuchanka4 replikasi ora nyambung menyang master anyar. Replikasi ana sinkron, mula ora mung budak sing mandheg, nanging uga master anyar. Bisa ditindakake kanthi nyetel wal_receiver_timeout=0 nalika ngatur PostgreSQL.

• Kadhangkala aku ndeleng replikasi beku ing PostgreSQL ing tes ForkBomb (memori overflow). Sawise ForkBomb, kadhangkala budak bisa uga ora nyambung maneh menyang master anyar. Aku mung ketemu iki ing tuchanka3 lan tuchanka4 kluster, ngendi master froze amarga réplikasi sinkron. Masalah kasebut ilang dhewe sawise suwe (udakara rong jam). Riset luwih akeh dibutuhake kanggo mbenerake iki. Gejala kasebut padha karo bug sadurunge, sing disebabake dening alasan sing beda, nanging kanthi akibat sing padha.

Krogan gambar dijupuk saka sesat Art kanthi idin saka penulis:

Source: www.habr.com