Вовед

Пред извесно време ми беше дадена задача да развијам фајловер кластер за PostgreSQL, кои работат во неколку центри за податоци поврзани со оптичко влакно во еден град и способни да издржат дефект (на пример, затемнување) на еден центар за податоци. Како софтвер кој е одговорен за толеранција на грешки, го избрав Пејсмејкерзатоа што ова е официјалното решение од RedHat за креирање фајловер кластери. Добро е затоа што RedHat обезбедува поддршка за тоа, и затоа што ова решение е универзално (модуларно). Со негова помош, ќе биде можно да се обезбеди толеранција на грешки не само на PostgreSQL, туку и на други услуги, или користејќи стандардни модули или креирајќи ги за специфични потреби.

Оваа одлука покрена разумно прашање: колку ќе биде толерантен за грешки кластерот за неуспех? За да го истражам ова, развив тест клупа која симулира различни неуспеси на јазлите на кластерот, чека да се врати услугата, го обновува неуспешниот јазол и продолжува со тестирање во циклус. Овој проект првично беше наречен hapgsql, но со текот на времето ми здодеа името, кое имаше само една самогласка. Затоа, почнав да повикувам бази на податоци толерантни за грешки (и да ја плови IP адресата покажувајќи кон нив) кроган (лик од компјутерска игра во која се дуплираат сите важни органи), а јазлите, кластерите и самиот проект се тучанка (планетата каде што живеат кроганите).

Сега управата дозволи отворете го проектот за заедницата со отворен код под лиценцата MIT. README наскоро ќе биде преведен на англиски (бидејќи се очекува дека главни потрошувачи ќе бидат развивачите на Pacemaker и PostgreSQL), и решив да ја претставам старата руска верзија на README (делумно) во форма на овој напис.

Кластерите се распоредени на виртуелни машини VirtualBox. Ќе бидат распоредени вкупно 12 виртуелни машини (вкупно 36GiB), кои формираат 4 кластери толерантни на грешки (различни опции). Првите два кластери се состојат од два PostgreSQL сервери, кои се наоѓаат во различни центри за податоци, и заеднички сервер сведок c уред за кворум (хостирано на евтина виртуелна машина во трет центар за податоци), што ја решава неизвесноста 50% / 50%, давајќи го својот глас на една од партиите. Трет кластер во три центри за податоци: еден господар, два робови, бр уред за кворум. Четвртиот кластер се состои од четири PostgreSQL сервери, два по центар за податоци: еден главен, останатите реплики, а исто така користи сведок c уред за кворум. Четвртиот може да издржи неуспех на два сервери или еден центар за податоци. Ова решение може да се зголеми на поголем број реплики доколку е потребно.

Прецизна временска услуга НТПД исто така е реконфигуриран за толеранција на грешки, но го користи самиот метод ntpd (режим на сираче). Заеднички сервер сведок делува како централен NTP сервер, дистрибуирајќи го своето време до сите кластери, а со тоа ги синхронизира сите сервери еден со друг. Ако сведок не успее или станува изолиран, тогаш еден од кластерските сервери (во рамките на кластерот) ќе почне да го дистрибуира своето време. Помошно кеширање HTTP прокси исто така подигнат на сведок, со негова помош, другите виртуелни машини имаат пристап до складиштата на Yum. Во реалноста, услугите како точното време и прокси-серверите најверојатно ќе бидат хостирани на посветени сервери, но во кабината на која се хостирани сведок само за да се зачува бројот на виртуелни машини и простор.

Верзии

v0. Работи со CentOS 7 и PostgreSQL 11 на VirtualBox 6.1.

Структура на кластерот

Сите кластери се дизајнирани да бидат лоцирани во повеќе центри за податоци, комбинирани во една рамна мрежа и мора да издржат дефект или мрежна изолација на еден центар за податоци. Затоа е невозможно употреба за заштита од поделен мозок стандардна пејсмејкер технологија наречена СТОНИТ (Снимајте го другиот јазол во главата) или мечување. Неговата суштина: ако јазлите во кластерот почнат да се сомневаат дека нешто не е во ред со некој јазол, тој не реагира или се однесува неправилно, тогаш тие насилно го исклучуваат преку „надворешни“ уреди, на пример, контролна картичка IPMI или UPS . Но, ова ќе работи само во случаи кога, во случај на еден неуспех, серверот IPMI или UPS продолжува да работи. Овде планираме да се заштитиме од многу покатастрофален дефект, кога целиот центар за податоци откажува (на пример, губи напојување). И со такво одбивање, сè стонит-Уредите (IPMI, UPS, итн.) исто така нема да работат.

Наместо тоа, системот се заснова на идејата за кворум. Сите јазли имаат глас, а само оние што можат да видат повеќе од половина од сите јазли можат да работат. Оваа количина „половина + 1“ се нарекува кворум. Доколку не се постигне кворум, тогаш јазолот одлучува дека е во мрежна изолација и мора да ги исклучи своите ресурси, т.е. ова е што е заштита од поделен мозок. Ако софтверот кој е одговорен за ова однесување не работи, тогаш ќе мора да работи чувар, на пример, базиран на IPMI.

Ако бројот на јазли е парен (кластер во два центри за податоци), тогаш може да се појави т.н. 50% / 50% (педесет и педесет) кога мрежната изолација го дели кластерот точно на половина. Затоа, за парен број јазли, додаваме уред за кворум е беспрекорен демон кој може да се лансира на најевтината виртуелна машина во трет центар за податоци. Тој го дава својот глас на еден од сегментите (кој го гледа), и со тоа ја разрешува неизвесноста од 50%/50%. Го именував серверот на кој ќе се стартува уредот за кворум сведок (терминологија од repmgr, ми се допадна).

Ресурсите може да се преместуваат од место до место, на пример, од неисправни сервери на здрави или по наредба на системските администратори. Така што клиентите знаат каде се наоѓаат ресурсите што им се потребни (каде да се поврзат?), лебдечка IP адреса (плови IP). Ова се IP-адреси кои Пејсмејкер може да ги движи низ јазлите (сè е на рамна мрежа). Секој од нив симболизира ресурс (услуга) и ќе биде лоциран каде што треба да се поврзете за да добиете пристап до оваа услуга (во нашиот случај, база на податоци).

Тучанка1 (коло со набивање)

Структура

Идејата беше дека имаме многу мали бази на податоци со мало оптоварување, за кои е непрофитабилно да се одржува посветен сервер во режим на подготвеност за само читање (нема потреба од такво губење ресурси).

Секој центар за податоци има еден сервер. Секој сервер има два примери на PostgreSQL (во терминологијата PostgreSQL тие се нарекуваат кластери, но за да се избегне забуна ќе ги наречам инстанци (по аналогија со другите бази на податоци), а кластерите на Pacemaker ќе ги нарекувам само кластери). Еден пример работи во главен режим и само тој обезбедува услуги (само float IP води до него). Втората инстанца работи како роб за вториот центар за податоци и ќе обезбедува услуги само ако неговиот господар не успее. Бидејќи најчесто само еден пример од два (мастерот) ќе обезбедува услуги (извршува барања), сите ресурси на серверот се оптимизирани за главниот (меморијата е распределена за кешот shared_buffers, итн.), но така што втората инстанца исто така има доволно ресурси (иако за неоптимално работење преку кешот на датотечниот систем) во случај на дефект на еден од центрите за податоци. Slave не обезбедува услуги (не извршува барања само за читање) при нормално функционирање на кластерот, така што нема војна за ресурси со господарот на истата машина.

Во случај на два јазли, толеранцијата на грешка е можна само со асинхрона репликација, бидејќи со синхрона репликација, неуспехот на slave ќе доведе до запирање на господарот.

Несведочување

Несведочување (уред за кворум) Ќе сметам само за кластерот Тучанка1, со сите други ќе биде иста приказна. Ако сведокот не успее, ништо нема да се промени во структурата на кластерот, сè ќе продолжи да работи на ист начин како што работеше. Но, кворумот ќе стане 2 од 3, и затоа секој последователен неуспех ќе биде фатален за кластерот. Сè уште ќе треба итно да се поправи.

Тучанка1 одбивање

Неуспех на еден од центрите за податоци за Тучанка1. Во овој случај сведок го дава својот глас на вториот јазол во вториот центар за податоци. Таму, поранешниот роб се претвора во господар, како резултат на тоа, двата господари работат на ист сервер и двете нивни float IP-а укажуваат на нив.

Тучанка2 (класична)

Структура

Класична шема од два јазли. Господарот работи на едното, робот на второто. И двајцата можат да извршуваат барања (робот се чита само), така што и двете се посочени со float IP: krogan2 е господар, krogan2s1 е роб. И господарот и робот ќе имаат толеранција на грешки.

Во случај на два јазли, толеранцијата на грешки е можна само со асинхрона репликација, бидејќи со синхрона репликација, неуспехот на slave ќе доведе до запирање на господарот.

Тучанка2 одбивање

Ако некој од центрите за податоци не успее сведок гласа за вториот. На единствениот работен центар за податоци, господарот ќе биде подигнат и двете float IP-а ќе укажуваат на него: господарот и slave. Се разбира, инстанцата мора да биде конфигурирана на таков начин што има доволно ресурси (ограничувања за поврзување, итн.) за истовремено да ги прифати сите врски и барања од главната и slave float IP. Тоа е, за време на нормална работа треба да има доволно снабдување со граници.

Тучанка4 (многу робови)

Структура

Веќе друга крајност. Постојат бази на податоци кои примаат многу барања само за читање (типичен случај на локација со големо оптоварување). Тучанка4 е ситуација кога може да има три или повеќе робови за да се справат со такви барања, но сепак не премногу. Со многу голем број робови, ќе биде неопходно да се измисли хиерархиски систем за репликација. Во минималниот случај (на сликата), секој од двата центри за податоци има два сервери, секој со инстанца PostgreSQL.

Друга карактеристика на оваа шема е тоа што веќе е можно да се организира една синхрона репликација. Конфигуриран е да се реплицира, ако е можно, во друг центар за податоци, наместо на реплика во истиот центар за податоци како главниот. Кон господарот и секој роб се посочени со float IP. За среќа, меѓу робовите ќе биде неопходно некако да се избалансираат барањата sql прокси, на пример, на страната на клиентот. Различни типови клиенти може да бараат различни типови sql прокси, а само развивачите на клиенти знаат кому му треба што. Оваа функционалност може да се имплементира или со надворешен демон или со клиентска библиотека (базен за поврзување) итн. Сето ова оди подалеку од темата за кластерот за бази на податоци со неуспех (failover SQL прокси може да се имплементира независно, заедно со толеранција на грешка на клиентот).

Тучанка4 одбивање

Ако еден центар за податоци (т.е. два сервери) не успее, сведоците гласаат за вториот. Како резултат на тоа, два сервери работат во вториот центар за податоци: едниот работи на главен, а главниот float IP покажува кон него (за примање барања за читање-запишување); а на вториот сервер има slave што работи со синхрона репликација и една од slave float IP-ите покажува на него (за барања само за читање).

Првото нешто што треба да се забележи е дека не сите slave float IP-а ќе бидат работници, туку само еден. И за правилно работење со него ќе биде неопходно тоа sql прокси ги пренасочи сите барања на единствената преостаната float IP; и ако sql прокси не, тогаш можете да ги наведете сите float IP робови одделени со запирки во URL-то на врската. Во овој случај, со libpq поврзувањето ќе биде со првата работна IP IP, тоа се прави во системот за автоматско тестирање. Можеби во други библиотеки, на пример, JDBC, ова нема да работи и е неопходно sql прокси. Ова е направено затоа што float IP-адресите за slaves се забранети да се подигнуваат истовремено на еден сервер, така што тие се рамномерно распоредени меѓу slave серверите доколку има неколку од нив кои работат.

Второ: дури и во случај на дефект на центарот за податоци, синхроната репликација ќе се одржува. И дури и ако се случи секундарен дефект, односно еден од двата сервери во преостанатиот центар за податоци не успее, кластерот, иако ќе престане да дава услуги, сепак ќе ги задржи информациите за сите извршени трансакции за кои дал потврда за извршената (нема да има информации за загуба во случај на секундарен дефект).

Tuchanka3 (3 центри за податоци)

Структура

Ова е кластер за ситуација каде што има три целосно функционални центри за податоци, од кои секој има целосно функционален сервер за бази на податоци. Во овој случај уред за кворум не потребно. Едниот центар за податоци е опремен со господар, а во другите два има робови. Репликацијата е синхрона, тип ANY (slave1, slave2), односно клиентот ќе добие потврда за извршување кога некој од робовите е првиот што ќе одговори дека го прифатил commit. Ресурсите се означени со една float IP за господарот и две за slaves. За разлика од Tuchanka4, сите три float IP-а се толерантни на грешки. За да ги балансирате SQL барањата само за читање што можете да ги користите sql прокси (со посебна толеранција на грешки), или доделете една slave float IP на половина од клиентите, а другата половина на втората.

Тучанка3 одбивање

Ако еден од центрите за податоци не успее, остануваат два. Во едната, главната и float IP од господарот се подигнуваат, во втората - slave и двете slave float IP (инстанцата мора да има двојна резерва на ресурси за да ги прифати сите врски од двете slave float IP). Синхрона репликација помеѓу господари и робови. Исто така, кластерот ќе зачувува информации за извршени и потврдени трансакции (нема да има губење на информации) во случај на уништување на два центри за податоци (ако не се уништат истовремено).

Решив да не вклучам детален опис на структурата на датотеката и распоредувањето. Секој што сака да си поигрува може да го прочита сето тоа во README. Обезбедувам само опис на автоматско тестирање.

Систем за автоматско тестирање

За да се тестира толеранцијата на грешки на кластерите со симулирање на различни дефекти, создаден е систем за автоматско тестирање. Лансиран по скрипта test/failure. Скриптата може да ги земе како параметри бројот на кластери што сакате да ги тестирате. На пример оваа команда:

test/failure 2 3

ќе ги тестира само вториот и третиот кластер. Ако параметрите не се наведени, тогаш сите кластери ќе бидат тестирани. Сите кластери се тестираат паралелно, а резултатот се прикажува во панелот tmux. Tmux користи посветен tmux сервер, така што скриптата може да се извршува од стандардниот tmux, што резултира со вгнезден tmux. Препорачувам да го користите терминалот во голем прозорец и со мал фонт. Пред да започне тестирањето, сите виртуелни машини се враќаат на слика во моментот кога сценариото ќе заврши setup.

Терминалот е поделен на колони според бројот на кластери што се тестираат стандардно (на екранот) има четири; Ќе ја опишам содржината на колоните користејќи го примерот на Тучанка2. Панелите на екранот се нумерирани:

Статистиката за тестирање е прикажана овде. Колони:
- неуспех — името на тестот (функција во скриптата) што ја имитира грешката.
- реакција — аритметичко просечно време во секунди за време на кое кластерот ја обнови својата функционалност. Се мери од почетокот на скриптата емулирајќи грешка до моментот кога кластерот ќе ја врати својата функционалност и ќе може да продолжи да дава услуги. Ако времето е многу кратко, на пример, шест секунди (ова се случува во кластери со неколку робови (Tuchanka3 и Tuchanka4)), тоа значи дека дефектот бил на асинхрониот роб и на кој било начин не влијаел на перформансите; прекинувачи на состојбата на кластерот.
- отстапување — го покажува ширењето (прецизноста) на вредноста реакција користејќи го методот на стандардна девијација.
- брои - колку пати е направен овој тест.
Краток дневник ви овозможува да оцените што прави кластерот во моментот. Се прикажуваат бројот на повторување (тест), временскиот печат и името на операцијата. Предолгото трчање (> 5 минути) укажува на проблем.
срцето (срце) - тековно време. За визуелна проценка на перформансите мајстори Тековното време постојано се запишува на неговата табела со помош на float IP master. Ако е успешен, резултатот се прикажува во овој панел.
победи (пулс) - „тековно време“, кое претходно беше снимено од сценариото срцето да го совладате, сега читајте од роб преку неговата пловечка IP адреса. Ви овозможува визуелно да ги процените перформансите на робот и репликацијата. Во Тучанка1 нема робови со float IP (нема робови кои даваат услуги), но има два примери (DB), така што нема да се прикаже овде победиИ срцето втор степен.
Следење на здравјето на кластерите користејќи ја алатката pcs mon. Ја прикажува структурата, дистрибуцијата на ресурсите низ јазлите и другите корисни информации.
Системското следење од секоја виртуелна машина во кластерот е прикажано овде. Може да има повеќе такви панели во зависност од тоа колку виртуелни машини има кластерот. Два графикони Оптоварување на процесорот (виртуелните машини имаат два процесори), име на виртуелна машина, Оптоварување на системот (наречен Load Average бидејќи е просечен за 5, 10 и 15 минути), процесни податоци и распределба на меморијата.
Трага од скриптата која врши тестирање. Во случај на дефект - ненадеен прекин на работата или бесконечен циклус на чекање - овде можете да ја видите причината за ваквото однесување.

Тестирањето се врши во две фази. Прво, скриптата поминува низ сите видови тестови, по случаен избор избирајќи виртуелна машина на која ќе се примени овој тест. Потоа се врши бесконечен циклус на тестирање, виртуелните машини и грешката се избираат по случаен избор секој пат. Ненадејно прекинување на скриптата за тестирање (долниот панел) или бескрајна јамка на чекање за нешто (> 5 минути време на извршување за една операција, ова може да се види во трагата) покажува дека некои од тестовите на овој кластер не успеале.

Секој тест се состои од следните операции:

Стартувајте функција која емулира дефект.
Подготвени? — чекање за обновување на кластерот (кога се обезбедени сите услуги).
Го прикажува истекот на враќањето на кластерот (реакција).
Поправи — кластерот се „поправа“. По што треба да се врати во целосно оперативна состојба и да биде подготвен за следниот дефект.

Еве список на тестови со опис на она што го прават:

ForkBomb: Создава „Од меморија“ користејќи вилушка бомба.
Надвор од просторот: Хард дискот е полн. Но, тестот е прилично симболичен со незначително оптоварување што се создава за време на тестирањето, PostgreSQL обично не пропаѓа кога хард дискот е полн.
Постгрес-УБИЈ: го убива PostgreSQL со командата killall -KILL postgres.
Постгрес-СТОП: виси командата PostgreSQL killall -STOP postgres.
Исклучување: ја „де-енергизира“ виртуелната машина со командата VBoxManage controlvm "виртуалка" poweroff.
Ресетирање: ја преоптоварува виртуелната машина со командата VBoxManage controlvm "виртуалка" reset.
SBD-СТОП: го суспендира демонот SBD со командата killall -STOP sbd.
Исклучи: испраќа команда до виртуелната машина преку SSH systemctl poweroff, системот благодатно се исклучува.
Прекини врска: мрежна изолација, команда VBoxManage controlvm "виртуалка" setlinkstate1 off.

Завршување на тестирањето или со користење на стандардната команда tmux „убиј-прозорец“. Ctrl-b &, или командата „detch-client“. Ctrl-b d: во овој момент тестирањето завршува, tmux се затвора, виртуелните машини се исклучуваат.

Проблеми идентификувани за време на тестирањето

Во овој момент чувар демон sbd работи на запирање на набљудуваните демони, но не и нивно замрзнување. И, како резултат на тоа, грешки кои водат само до замрзнување Коросинк и Пејсмејкер, но не и виси sbd. За проверка Коросинк веќе има ПР # 83 (на GitHub на sbd), прифатена во нишката господар. Ветија (во ПР#83) дека ќе има нешто слично за Пејсмејкер, се надевам дека до Црвенкапа 8 ќе направи. Но, таквите „неисправности“ се шпекулативни и можат лесно да се симулираат вештачки со користење, на пример, killall -STOP corosync, но никогаш не се среќавајте во реалниот живот.
У Пејсмејкер во верзијата за CentOS 7 погрешно поставено sync_timeout у уред за кворум, како резултат ако еден јазол не успеа, со одредена веројатност се рестартира и вториот јазол, на кој мајсторот требало да се пресели. Излечен со зголемување sync_timeout у уред за кворум за време на распоредувањето (во скрипта setup/setup1). Овој амандман не беше прифатен од програмерите Пејсмејкер, наместо тоа тие ветија дека ќе ја редизајнираат инфраструктурата на таков начин (во некоја неодредена иднина) што овој тајмаут ќе се пресметува автоматски.
Ако конфигурацијата на базата на податоци го специфицира тоа LC_MESSAGES (текстуални пораки) Уникод може да се користи, на пр. ru_RU.UTF-8, потоа при стартување postgres во средина каде што локацијата не е UTF-8, да речеме во празна средина (тука пејсмејкер+pgsqlms(paf) трча postgres) тогаш дневникот ќе содржи прашалници наместо UTF-8 букви. Програмерите на PostgreSQL не се договорија што да прават во овој случај. Тоа чини, треба да инсталирате LC_MESSAGES=en_US.UTF-8 при конфигурирање (креирање) пример на база на податоци.
Ако е поставено wal_receiver_timeout (стандардно е 60-ти), тогаш за време на тестот PostgreSQL-STOP на мастерот во кластерите tuchanka3 и tuchanka4 репликацијата повторно не се поврзува со новиот господар. Репликацијата таму е синхрона, па не само робот запира, туку и новиот господар. Работи наоколу со поставување wal_receiver_timeout=0 при конфигурирање на PostgreSQL.
Повремено забележав замрзнување на репликацијата во PostgreSQL во тестот ForkBomb (прелевање на меморијата). По ForkBomb, понекогаш робовите можеби нема повторно да се поврзат со новиот господар. Ова го сретнав само во кластерите tuchanka3 и tuchanka4, каде што мајсторот замрзна поради синхроната репликација. Проблемот помина сам по долго време (околу два часа). Потребни се повеќе истражувања за да се поправи ова. Симптомите се слични на претходната бубачка, која е предизвикана од друга причина, но со исти последици.