ProHoster > Blogs > Administrācija > Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Ievads

Pirms kāda laika man tika dots uzdevums izstrādāt kļūmjpārlēces klasteru priekÅ” PostgreSQL, kas darbojas vairākos datu centros, kas savienoti ar optisko Ŕķiedru vienā pilsētā, un spēj izturēt viena datu centra atteici (piemēram, strāvas padevi). Kā programmatÅ«ru, kas ir atbildÄ«ga par kļūdu toleranci, es izvēlējos Elektrokardiostimulatorsjo tas ir oficiālais RedHat risinājums kļūmjpārlēces klasteru izveidei. Tas ir labi, jo RedHat nodroÅ”ina tam atbalstu, un tāpēc, ka Å”is risinājums ir universāls (modulārs). Ar tās palÄ«dzÄ«bu bÅ«s iespējams nodroÅ”ināt kļūdu toleranci ne tikai PostgreSQL, bet arÄ« citiem servisiem, vai nu izmantojot standarta moduļus, vai veidojot tos konkrētām vajadzÄ«bām.

Å is lēmums radÄ«ja pamatotu jautājumu: cik kļūmju izturÄ«gs bÅ«s kļūmjpārlēces klasteris? Lai to izpētÄ«tu, es izstrādāju testa stendu, kas simulē dažādas kļūmes klastera mezglos, gaida, lÄ«dz pakalpojums tiks atjaunots, atkopj neveiksmÄ«go mezglu un turpina testÄ“Å”anu cilpā. Å is projekts sākotnēji tika saukts par hapgsql, taču laika gaitā man kļuva garlaicÄ«gi nosaukums, kurā bija tikai viens patskanis. Tāpēc es sāku izsaukt defektu tolerantās datu bāzes (un peldoŔā IP, kas norāda uz tām) krogan (varonis no datorspēles, kurā tiek dublēti visi svarÄ«gie orgāni), un mezgli, kopas un pats projekts ir tuchanka (planēta, uz kuras dzÄ«vo krogani).

Tagad vadÄ«ba atļāvusi atveriet projektu atvērtā koda kopienai saskaņā ar MIT licenci. README drÄ«zumā tiks pārtulkots angļu valodā (jo paredzams, ka galvenie patērētāji bÅ«s Pacemaker un PostgreSQL izstrādātāji), un es nolēmu Ŕī raksta veidā (daļēji) prezentēt README veco krievu versiju.

Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Klasteri tiek izvietoti virtuālajās maŔīnās VirtualBox. Pavisam tiks izvietotas 12 virtuālās maŔīnas (kopā 36GiB), kas veido 4 pret defektiem izturÄ«gas kopas (dažādas iespējas). Pirmie divi klasteri sastāv no diviem PostgreSQL serveriem, kas atrodas dažādos datu centros, un kopēja servera Liecinieks c kvoruma ierÄ«ce (mitināts lētā virtuālajā maŔīnā treÅ”ajā datu centrā), kas novērÅ” nenoteiktÄ«bu 50% / 50%, atdodot savu balsi kādai no partijām. TreÅ”ais klasteris trÄ«s datu centros: viens galvenais, divi vergu, Nr kvoruma ierÄ«ce. Ceturtais klasteris sastāv no četriem PostgreSQL serveriem, diviem katrā datu centrā: viens galvenais, pārējās replikas un arÄ« izmanto Liecinieks c kvoruma ierÄ«ce. Ceturtais var izturēt divu serveru vai viena datu centra kļūmi. Ja nepiecieÅ”ams, Å”o risinājumu var palielināt lÄ«dz lielākam kopiju skaitam.

PrecÄ«za laika apkalpoÅ”ana ntpd arÄ« pārkonfigurēts, lai nodroÅ”inātu kļūdu toleranci, taču tajā tiek izmantota pati metode ntpd (bāreņu režīms). Koplietots serveris Liecinieks darbojas kā centrālais NTP serveris, sadalot savu laiku visiem klasteriem, tādējādi sinhronizējot visus serverus savā starpā. Ja Liecinieks neizdodas vai kļūst izolēts, tad viens no klastera serveriem (klastera ietvaros) sāks sadalÄ«t savu laiku. Papildu keÅ”atmiņa HTTP proxy arÄ« paaugstināts lÄ«dz Liecinieks, ar tās palÄ«dzÄ«bu citām virtuālajām maŔīnām ir piekļuve Yum krātuvēm. PatiesÄ«bā tādi pakalpojumi kā precÄ«zs laiks un starpniekserveri, visticamāk, tiks mitināti specializētos serveros, bet kabÄ«nē tie tiek mitināti Liecinieks tikai, lai ietaupÄ«tu virtuālo maŔīnu skaitu un vietu.

Versijas

v0. Darbojas ar CentOS 7 un PostgreSQL 11 uz VirtualBox 6.1.

Klasteru struktūra

Visas kopas ir paredzētas izvietoÅ”anai vairākos datu centros, apvienotas vienā plakanā tÄ«klā, un tām ir jāiztur viena datu centra atteice vai tÄ«kla izolācija. Tāpēc nav iespējams izmantot aizsardzÄ«bai pret sadalÄ«tās smadzenes sauc par standarta elektrokardiostimulatora tehnoloÄ£iju STONITS (NoÅ”aut otru mezglu galvā) vai žogs. Tās bÅ«tÄ«ba: ja klastera mezgliem rodas aizdomas, ka ar kādu mezglu kaut kas nav kārtÄ«bā, tas nereaģē vai uzvedas nepareizi, tad viņi to piespiedu kārtā izslēdz caur ā€œÄrējāmā€ ierÄ«cēm, piemēram, IPMI vai UPS vadÄ«bas karti. . Bet tas darbosies tikai gadÄ«jumos, kad vienas kļūmes gadÄ«jumā IPMI vai UPS serveris turpina darboties. Å eit mēs plānojam aizsargāties pret daudz katastrofālāku atteici, kad viss datu centrs sabojājas (piemēram, pazÅ«d strāva). Un ar tādu atteikumu viss stonis-ierÄ«ces (IPMI, UPS utt.) arÄ« nedarbosies.

Tā vietā sistēmas pamatā ir kvoruma ideja. Visiem mezgliem ir balss, un var darboties tikai tie, kas var redzēt vairāk nekā pusi no visiem mezgliem. Å o summu "puse + 1" sauc kvorums. Ja kvorums netiek sasniegts, tad mezgls nolemj, ka atrodas tÄ«kla izolācijā un ir jāizslēdz savi resursi, t.i. tas ir tas, kas tas ir Ŕķelto smadzeņu aizsardzÄ«ba. Ja programmatÅ«ra, kas ir atbildÄ«ga par Å”o uzvedÄ«bu, nedarbojas, tad bÅ«s jādarbojas sargsunim, piemēram, pamatojoties uz IPMI.

Ja mezglu skaits ir pāra (klasteris divos datu centros), tad var rasties tā sauktā nenoteiktÄ«ba 50% / 50% (puse uz pusi), kad tÄ«kla izolācija sadala kopu tieÅ”i uz pusēm. Tāpēc pāra skaitam mezglu mēs pievienojam kvoruma ierÄ«ce ir mazprasÄ«gs dēmons, ko var palaist lētākajā virtuālajā maŔīnā treÅ”ajā datu centrā. ViņŔ atdod savu balsi vienam no segmentiem (kuru viņŔ redz) un tādējādi atrisina 50%/50% nenoteiktÄ«bu. Es nosaucu serveri, kurā tiks palaista kvoruma ierÄ«ce Liecinieks (terminoloÄ£ija no repmgr, man patika).

Resursus var pārvietot no vienas vietas uz otru, piemēram, no bojātiem serveriem uz veseliem vai pēc sistēmas administratoru pavēles. Lai klienti zinātu, kur atrodas viņiem nepiecieÅ”amie resursi (kur pieslēgties?), peldoÅ”s IP (peldoÅ”s IP). Tie ir IP, kurus elektrokardiostimulators var pārvietot pa mezgliem (viss ir plakanā tÄ«klā). Katrs no tiem simbolizē kādu resursu (pakalpojumu) un atradÄ«sies vietā, kur nepiecieÅ”ams izveidot savienojumu, lai piekļūtu Å”im pakalpojumam (mÅ«su gadÄ«jumā datubāzei).

Tuchanka1 (shēma ar blīvējumu)

Struktūra

Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Ideja bija tāda, ka mums ir daudz mazu datu bāzu ar zemu slodzi, kurām ir neizdevÄ«gi uzturēt speciālu vergu serveri karstā gaidÄ«Å”anas režīmā tikai lasÄ«Å”anas transakcijām (nav vajadzÄ«ga tāda resursu izŔķērdÄ“Å”ana).

Katrā datu centrā ir viens serveris. Katram serverim ir divi PostgreSQL gadÄ«jumi (PostgreSQL terminoloÄ£ijā tos sauc par klasteriem, taču, lai izvairÄ«tos no neskaidrÄ«bām, es tos saukÅ”u par gadÄ«jumiem (pēc analoÄ£ijas ar citām datu bāzēm), bet Pacemaker klasterus es saukÅ”u tikai par klasteriem). Viena instance darbojas galvenajā režīmā un tikai tā nodroÅ”ina pakalpojumus (uz to ved tikai float IP). Otrā instance darbojas kā otrā datu centra vergs un sniegs pakalpojumus tikai tad, ja tā galvenā ierÄ«ce neizdosies. Tā kā lielākoties pakalpojumus (izpildÄ«s pieprasÄ«jumus) sniegs tikai viens gadÄ«jums no diviem (galvenais), visi servera resursi tiek optimizēti galvenajam (atmiņa tiek atvēlēta share_buffers keÅ”atmiņai utt.), bet tā, lai otrā instance. ir arÄ« pietiekami daudz resursu (lai gan neoptimālai darbÄ«bai, izmantojot failu sistēmas keÅ”atmiņu), ja kāds no datu centriem nedarbojas. Slave nesniedz pakalpojumus (neveic tikai lasÄ«Å”anas pieprasÄ«jumus) klastera normālas darbÄ«bas laikā, lai tajā paŔā maŔīnā nebÅ«tu karÅ” par resursiem ar galveno.

Divu mezglu gadÄ«jumā kļūdu tolerance ir iespējama tikai ar asinhrono replikāciju, jo ar sinhrono replikāciju vergu kļūme novedÄ«s pie galvenās ierÄ«ces apturÄ“Å”anas.

Nespēja liecināt

Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Nespēja liecināt (kvoruma ierÄ«ce) IzskatÄ«Å”u tikai par Tuchanka1 klasteru, ar visiem pārējiem bÅ«s tas pats stāsts. Ja liecinieks neizdosies, klastera struktÅ«rā nekas nemainÄ«sies, viss turpinās darboties tāpat kā strādāja. Bet kvorums kļūs par 2 no 3, un tāpēc jebkura turpmāka neveiksme bÅ«s liktenÄ«ga klasterim. Tas joprojām bÅ«s steidzami jālabo.

Tuchanka1 atteikums

Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Viena no Tuchanka1 datu centriem atteice. Å ajā gadÄ«jumā Liecinieks nodod savu balsi otram mezglam otrā datu centrā. Tur bijuÅ”ais vergs pārvērÅ”as par saimnieku, kā rezultātā abi saimnieki strādā uz viena servera un abi viņu peldoÅ”ie IP norāda uz tiem.

Tuchanka2 (klasiskā)

Struktūra

Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Klasiskā divu mezglu shēma. Saimnieks strādā pie viena, vergs pie otrā. Abi var izpildÄ«t pieprasÄ«jumus (pakalpojums ir tikai lasāms), tāpēc uz abiem ir norādÄ«ts peldoÅ”ais IP: krogan2 ir galvenais, krogan2s1 ir slavens. Gan kapteinim, gan vergam bÅ«s kļūdu tolerance.

Divu mezglu gadÄ«jumā kļūdu tolerance ir iespējama tikai ar asinhrono replikāciju, jo ar sinhrono replikāciju vergu kļūme novedÄ«s pie galvenā apstāŔanās.

Tuchanka2 atteikums

Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Ja kāds no datu centriem neizdodas Liecinieks balsis par otro. VienÄ«gajā strādājoÅ”ajā datu centrā tiks pacelts galvenais, un uz to norādÄ«s abas peldoŔās IP ā€” galvenais un pakārtotais. Protams, eksemplārs ir jākonfigurē tā, lai tai bÅ«tu pietiekami daudz resursu (savienojumu ierobežojumi utt.), lai vienlaikus pieņemtu visus savienojumus un pieprasÄ«jumus no galvenā un pakārtotā peldoŔā IP. Tas ir, normālas darbÄ«bas laikā tam vajadzētu bÅ«t pietiekamam ierobežojumu piedāvājumam.

Tuchanka4 (daudzi vergi)

Struktūra

Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Jau cita galējÄ«ba. Ir datu bāzes, kas saņem daudz tikai lasāmu pieprasÄ«jumu (tipisks augstas slodzes vietnes gadÄ«jums). Tuchanka4 ir situācija, kad Ŕādu pieprasÄ«jumu apstrādei var bÅ«t trÄ«s vai vairāk vergu, taču ne pārāk daudz. Ar ļoti lielu vergu skaitu bÅ«s jāizgudro hierarhiska replikācijas sistēma. Minimālajā gadÄ«jumā (attēlā) katrā no diviem datu centriem ir divi serveri, katrs ar PostgreSQL gadÄ«jumu.

Vēl viena Ŕīs shēmas iezÄ«me ir tāda, ka jau tagad ir iespējams organizēt vienu sinhronu replikāciju. Tas ir konfigurēts, lai, ja iespējams, replicētu citā datu centrā, nevis replikā tajā paŔā datu centrā, kurā atrodas galvenais datu centrs. Uz galveno un katru vergu norāda peldoÅ”ais IP. Par laimi, starp vergiem vajadzēs kaut kā lÄ«dzsvarot pieprasÄ«jumus sql starpniekserveris, piemēram, klienta pusē. Dažādu veidu klientiem var bÅ«t nepiecieÅ”ami dažādi veidi sql starpniekserveris, un tikai klientu izstrādātāji zina, kam kas ir vajadzÄ«gs. Å o funkcionalitāti var ieviest vai nu ārējs dēmons, vai klienta bibliotēka (savienojumu pÅ«ls) utt. Tas viss pārsniedz tēmu par kļūmjpārlēces datu bāzes klasteru (kļūmjpārlēce SQL starpniekserveris var Ä«stenot neatkarÄ«gi, kopā ar klienta kļūdu toleranci).

Tuchanka4 atteikums

Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Ja viens datu centrs (t.i., divi serveri) neizdodas, liecinieks balso par otro. Rezultātā otrajā datu centrā darbojas divi serveri: vienā darbojas galvenais, un galvenais peldoÅ”ais IP norāda uz to (lasÄ«Å”anas-rakstÄ«Å”anas pieprasÄ«jumu saņemÅ”anai); un otrajā serverÄ« ir slavens, kas darbojas ar sinhrono replikāciju, un viens no slavenajiem peldoÅ”ajiem IP norāda uz to (tikai lasāmiem pieprasÄ«jumiem).

Vispirms jāatzÄ«mē, ka ne visi vergu peldoÅ”ie IP bÅ«s darbinieki, bet tikai viens. Un, lai pareizi strādātu ar to, tas bÅ«s nepiecieÅ”ams sql starpniekserveris novirzÄ«ja visus pieprasÄ«jumus uz vienÄ«go atlikuÅ”o peldoÅ”o IP; un ja sql starpniekserveris nē, tad savienojuma vietrādÄ« URL varat uzskaitÄ«t visus peldoÅ”os IP vergus, atdalot tos ar komatiem. Å ajā gadÄ«jumā ar libpq savienojums bÅ«s ar pirmo darba IP, tas tiek darÄ«ts automātiskās testÄ“Å”anas sistēmā. VarbÅ«t citās bibliotēkās, piemēram, JDBC, tas nedarbosies un ir nepiecieÅ”ams sql starpniekserveris. Tas tiek darÄ«ts, jo vergu IP ir aizliegts vienlaikus palielināt vienā serverÄ«, lai tie bÅ«tu vienmērÄ«gi sadalÄ«ti starp vergu serveriem, ja darbojas vairāki no tiem.

Otrkārt: pat datu centra kļūmes gadÄ«jumā tiks saglabāta sinhronā replikācija. Un pat tad, ja rodas sekundāra kļūme, tas ir, viens no diviem serveriem atlikuÅ”ajā datu centrā neizdodas, klasteris, lai gan pārtrauks pakalpojumu sniegÅ”anu, joprojām saglabā informāciju par visiem veiktajiem darÄ«jumiem, par kuriem tas ir apstiprinājis saistÄ«bu izpildi. (sekundāras atteices gadÄ«jumā informācija par zaudējumiem nebÅ«s).

Tuchanka3 (3 datu centri)

Struktūra

Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Å is ir klasteris situācijai, kad ir trÄ«s pilnÄ«bā funkcionējoÅ”i datu centri, no kuriem katram ir pilnÄ«bā funkcionējoÅ”s datu bāzes serveris. Å ajā gadÄ«jumā kvoruma ierÄ«ce nav vajadzÄ«gs. Vienā datu centrā strādā saimnieks, pārējos divos ā€“ vergi. Replikācija ir sinhrona, ierakstiet ANY (slave1, slave2), tas ir, klients saņems apstiprināŔanas apstiprinājumu, kad kāds no vergiem pirmais atbildēs, ka viņŔ ir pieņēmis saistÄ«bu. Resursi ir norādÄ«ti ar vienu peldoÅ”o IP galvenajam un diviem pakārtotajiem. AtŔķirÄ«bā no Tuchanka4, visi trÄ«s peldoÅ”ie IP ir izturÄ«gi pret kļūmēm. Lai lÄ«dzsvarotu tikai lasāmus SQL vaicājumus, varat izmantot sql starpniekserveris (ar atseviŔķu kļūdu toleranci), vai pieŔķirt vienu slavenu peldoÅ”o IP pusei klientu, bet otru pusi - otrajam.

Tuchanka3 atteikums

Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Ja viens no datu centriem neizdodas, paliek divi. Vienā tiek paaugstināts galvenais un peldoÅ”ais IP no galvenā, otrajā - vergu un abiem slavenajiem peldoÅ”ajiem IP (instancē ir jābÅ«t dubultai resursu rezervei, lai pieņemtu visus savienojumus no abiem slavenajiem peldoÅ”ajiem IP). Sinhronā replikācija starp saimniekiem un vergu. Tāpat klasteris saglabās informāciju par veiktajiem un apstiprinātajiem darÄ«jumiem (informācija nezaudēs) divu datu centru iznÄ«cināŔanas gadÄ«jumā (ja tie netiek iznÄ«cināti vienlaikus).

Es nolēmu neiekļaut detalizētu faila struktÅ«ras un izvietoÅ”anas aprakstu. Ikviens, kurÅ” vēlas spēlēties, to visu var izlasÄ«t README. Es sniedzu tikai automatizētās testÄ“Å”anas aprakstu.

Automātiskā testÄ“Å”anas sistēma

Lai pārbaudÄ«tu klasteru kļūdu toleranci, simulējot dažādus defektus, ir izveidota automātiskās testÄ“Å”anas sistēma. Palaists pēc skripta test/failure. Skripts var izmantot kā parametrus to klasteru skaitu, kuras vēlaties pārbaudÄ«t. Piemēram, Ŕī komanda:

test/failure 2 3

pārbaudÄ«s tikai otro un treÅ”o kopu. Ja parametri nav norādÄ«ti, tiks pārbaudÄ«ti visi klasteri. Visas kopas tiek pārbaudÄ«tas paralēli, un rezultāts tiek parādÄ«ts tmux panelÄ«. Tmux izmanto Ä«paÅ”u tmux serveri, tāpēc skriptu var palaist no noklusējuma tmux, kā rezultātā tiek izveidots ligzdots tmux. Es ieteiktu termināli izmantot lielā logā un ar mazu fontu. Pirms testÄ“Å”anas sākÅ”anas visas virtuālās maŔīnas tiek atgrieztas momentuzņēmumā brÄ«dÄ«, kad skripts tiek pabeigts. setup.

Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Terminālis ir sadalÄ«ts kolonnās atbilstoÅ”i pārbaudāmo klasteru skaitam; pēc noklusējuma (ekrānuzņēmumā) ir četras. Es aprakstÄ«Å”u kolonnu saturu, izmantojot Tuchanka2 piemēru. Ekrānuzņēmumā esoÅ”ie paneļi ir numurēti:

  1. Šeit tiek parādīta testa statistika. Kolonnas:
    • neveiksme ā€” testa nosaukums (funkcija skriptā), kas atdarina kļūdu.
    • reakcija ā€” vidējais aritmētiskais laiks sekundēs, kurā klasteris atguva savu funkcionalitāti. Tas tiek mērÄ«ts no kļūdu emulējoŔā skripta sākuma lÄ«dz brÄ«dim, kad klasteris atjauno savu funkcionalitāti un var turpināt sniegt pakalpojumus. Ja laiks ir ļoti Ä«ss, piemēram, seÅ”as sekundes (tas notiek klasteros ar vairākiem vergiem (Tuchanka3 un Tuchanka4)), tas nozÄ«mē, ka vaina bija asinhronajā vergā un nekādā veidā neietekmēja veiktspēju; nebija klasteru stāvokļa slēdži.
    • novirze ā€” parāda vērtÄ«bas izplatÄ«bu (precizitāti). reakcija izmantojot standarta novirzes metodi.
    • skaitÄ«t ā€” cik reizes Ŕī pārbaude tika veikta.
  2. ÄŖss žurnāls ļauj novērtēt, ko klasteris paÅ”laik dara. Tiek parādÄ«ts iterācijas (testa) numurs, laika zÄ«mogs un darbÄ«bas nosaukums. Pārāk ilga skrieÅ”ana (> 5 minÅ«tes) norāda uz problēmu.
  3. sirds (sirds) - paÅ”reizējais laiks. Veiktspējas vizuālai novērtÄ“Å”anai meistari PaÅ”reizējais laiks tiek pastāvÄ«gi ierakstÄ«ts tās tabulā, izmantojot peldoÅ”o IP galveno. Ja tas izdodas, rezultāts tiek parādÄ«ts Å”ajā panelÄ«.
  4. pārspēt (pulss) - ā€œpaÅ”reizējais laiksā€, ko iepriekÅ” ierakstÄ«ja skripts sirds apgÅ«t, tagad lasÄ«t no vergs izmantojot savu peldoÅ”o IP. Ä»auj vizuāli novērtēt vergu un replikācijas veiktspēju. Vietnē Tuchanka1 nav vergu ar peldoÅ”o IP (nav vergu, kas sniedz pakalpojumus), bet ir divi gadÄ«jumi (DB), tāpēc tas Å”eit netiks parādÄ«ts pārspētUn sirds otrā instance.
  5. Klasteru veselības uzraudzība, izmantojot utilītu pcs mon. Parāda struktūru, resursu sadalījumu pa mezgliem un citu noderīgu informāciju.
  6. Å eit tiek parādÄ«ta sistēmas uzraudzÄ«ba no katras klastera virtuālās maŔīnas. Var bÅ«t vairāk Ŕādu paneļu atkarÄ«bā no tā, cik virtuālo maŔīnu ir klasterÄ«. Divi grafiki CPU slodze (virtuālajām maŔīnām ir divi procesori), virtuālās maŔīnas nosaukums, Sistēmas slodze (nosaukts par slodzes vidējo, jo tas ir vidēji 5, 10 un 15 minÅ«tes), apstrādā datus un atmiņas pieŔķirÅ”anu.
  7. Skripta pēdas, kas veic testÄ“Å”anu. Nepareizas darbÄ«bas gadÄ«jumā - pēkŔņs darbÄ«bas pārtraukums vai nebeidzams gaidÄ«Å”anas cikls - Å”eit varat redzēt Ŕādas rÄ«cÄ«bas iemeslu.

Pārbaude tiek veikta divos posmos. Pirmkārt, skripts iziet visu veidu testus, nejauÅ”i atlasot virtuālo maŔīnu, kurai piemērot Å”o testu. Pēc tam tiek veikts nebeidzams testÄ“Å”anas cikls, katru reizi nejauÅ”i tiek atlasÄ«tas virtuālās maŔīnas un kļūda. PēkŔņa testÄ“Å”anas skripta pārtraukÅ”ana (apakŔējais panelis) vai nebeidzama cilpa, kas gaida kaut ko (> 5 minÅ«Å”u izpildes laiks vienai darbÄ«bai, to var redzēt trasē) norāda, ka daži Ŕī klastera testi ir bijuÅ”i neveiksmÄ«gi.

Katrs tests sastāv no Ŕādām darbībām:

  1. Palaidiet funkciju, kas atdarina kļūdu.
  2. Gatavs? ā€” gaida klastera atjaunoÅ”anu (kad ir nodroÅ”ināti visi pakalpojumi).
  3. Parāda klastera atkopŔanas taimautu (reakcija).
  4. Noteikt ā€” klasteris tiek ā€œlabotsā€. Pēc tam tam jāatgriežas pilnÄ«bā darba stāvoklÄ« un jābÅ«t gatavam nākamajam darbÄ«bas traucējumam.

Å eit ir testu saraksts ar aprakstu par to, ko tie veic:

  • ForkBomb: izveido "Out of memory", izmantojot dakÅ”u bumbu.
  • Ārpus Kosmosa: Cietais disks ir pilns. Taču tests ir diezgan simbolisks; ar nenozÄ«mÄ«go slodzi, kas tiek radÄ«ta testÄ“Å”anas laikā, PostgreSQL parasti neizdodas, kad cietais disks ir pilns.
  • Postgres-KILL: nogalina PostgreSQL ar komandu killall -KILL postgres.
  • Postgres-STOP: uzkaras PostgreSQL komanda killall -STOP postgres.
  • Izslēgt: ā€œatslēdzā€ virtuālo maŔīnu ar komandu VBoxManage controlvm "Š²ŠøртуŠ°Š»ŠŗŠ°" poweroff.
  • Atjaunot: pārslogo virtuālo maŔīnu ar komandu VBoxManage controlvm "Š²ŠøртуŠ°Š»ŠŗŠ°" reset.
  • SBD-STOP: aptur SBD dēmonu ar komandu killall -STOP sbd.
  • Izslēgt: nosÅ«ta komandu uz virtuālo maŔīnu, izmantojot SSH systemctl poweroff, sistēma graciozi izslēdzas.
  • AtsaistÄ«t: tÄ«kla izolācija, komanda VBoxManage controlvm "Š²ŠøртуŠ°Š»ŠŗŠ°" setlinkstate1 off.

TestÄ“Å”anas pabeigÅ”ana, izmantojot standarta tmux komandu "kill-window" Ctrl-b &, vai komandu "detach-client". Ctrl-b d: Å”ajā brÄ«dÄ« testÄ“Å”ana beidzas, tmux tiek aizvērts, virtuālās maŔīnas tiek izslēgtas.

Pārbaudes laikā konstatētas problēmas

  • Å obrÄ«d sargsuns dēmons sbd darbojas, lai apturētu novērotos dēmonus, bet ne iesaldētu tos. Un, kā rezultātā, defekti, kas noved tikai pie sasalÅ”anas Corosync Šø Elektrokardiostimulators, bet ne karājas sbd... Par pārbaudi Corosync jau ir PR#83 (GitHub vietnē plkst sbd), pieņemts pavedienam meistars. Viņi solÄ«ja (PR#83), ka bÅ«s kaut kas lÄ«dzÄ«gs elektrokardiostimulatoram, ceru, ka lÄ«dz RedHat 8 darÄ«Å”u. Taču Ŕādi ā€œdarbÄ«bas traucējumiā€ ir spekulatÄ«vi, un tos var viegli mākslÄ«gi simulēt, izmantojot, piemēram, killall -STOP corosync, bet nekad nesatiekas dzÄ«vē.

  • Š£ Elektrokardiostimulators versijā priekÅ” 7 CentOS nepareizi iestatÄ«ts sync_timeout у kvoruma ierÄ«cekā rezultātā ja viens mezgls neizdevās, ar zināmu varbÅ«tÄ«bu pārstartējās arÄ« otrais mezgls, uz kuru meistaram vajadzēja pārcelties. Izārstēts ar paplaÅ”ināŔanos sync_timeout у kvoruma ierÄ«ce izvietoÅ”anas laikā (skriptā setup/setup1). Å o grozÄ«jumu izstrādātāji nepieņēma Elektrokardiostimulators, tā vietā viņi solÄ«ja pārprojektēt infrastruktÅ«ru tādā veidā (kādā nenoteiktā nākotnē), lai Å”is taimauts tiktu aprēķināts automātiski.

  • Ja datu bāzes konfigurācija to norāda LC_MESSAGES (Ä«sziņas) Var izmantot Unicode, piem. ru_RU.UTF-8, pēc tam startÄ“Å”anas laikā postgres vidē, kurā lokalizācija nav UTF-8, piemēram, tukŔā vidē (Å”eit elektrokardiostimulators+pgsqlms(paf) skrien postgres), tad žurnālā bÅ«s jautājuma zÄ«mes, nevis UTF-8 burti. PostgreSQL izstrādātāji nav vienojuÅ”ies, kā rÄ«koties Å”ajā gadÄ«jumā. Tas maksā, jums ir jāinstalē LC_MESSAGES=en_US.UTF-8 konfigurējot (veidojot) datu bāzes gadÄ«jumu.

  • Ja ir iestatÄ«ts wal_receiver_timeout (pēc noklusējuma tas ir 60 s), tad PostgreSQL-STOP testa laikā galvenajā ierÄ«cē klasteros tuchanka3 un tuchanka4 replikācija neizveido savienojumu ar jauno galveno. Replikācija tur ir sinhrona, tāpēc apstājas ne tikai slavenais, bet arÄ« jaunais galvenais. Darbojas, iestatot wal_receiver_timeout=0, konfigurējot PostgreSQL.

  • Reizēm es novēroju replikācijas sasalÅ”anu PostgreSQL ForkBomb testā (atmiņas pārpilde). Pēc ForkBomb reizēm vergi var nesavienoties ar jauno galveno. Ar to esmu saskāries tikai klasteros tuchanka3 un tuchanka4, kur sinhronās replikācijas dēļ kapteinis iesaldēja. Problēma pazuda pati pēc ilgāka laika (apmēram divas stundas). Lai to labotu, ir nepiecieÅ”ams vairāk pētÄ«jumu. Simptomi ir lÄ«dzÄ«gi iepriekŔējai kļūdai, ko izraisa cits iemesls, bet ar tādām paŔām sekām.

Krogan attēls uzņemts no deviant Art ar autora atļauju:

Kļūmjpārlēces klasteru modelÄ“Å”ana, pamatojoties uz PostgreSQL un Pacemaker

Avots: www.habr.com

Pievieno komentāru