Толерантността към грешки и високата достъпност са големи теми, така че ще посветим отделни статии на RabbitMQ и Kafka. Тази статия е за RabbitMQ, а следващата е за Kafka срещу RabbitMQ. Статията е дълга, така че се настанете удобно.

Нека да разгледаме стратегиите за устойчивост на грешки, последователност и висока достъпност (HA) и компромисите, които всяка стратегия трябва да направи. RabbitMQ може да работи на клъстер от възли - и тогава се класифицира като разпределена система. Когато става въпрос за разпределени системи, често говорим за последователност и достъпност.

Тези концепции описват как системата се държи, когато се провали. Неуспешна мрежова връзка, повреда на сървъра, повреда на твърдия диск, временна недостъпност на сървъра поради събиране на отпадъци, загуба на пакети или забавяне на мрежовата връзка. Всичко това може да доведе до загуба на данни или конфликти. Оказва се, че е почти невъзможно да се създаде система, която е едновременно напълно последователна (без загуба на данни, без несъответствие в данните) и достъпна (ще приема четене и запис) за всички сценарии на повреда.

Ще видим, че последователността и наличността са в различни краища на спектъра и вие трябва да изберете кой начин да оптимизирате. Добрата новина е, че с RabbitMQ този избор е възможен. Разполагате с някакви "изперкански" лостове за изместване на баланса към повече последователност или повече достъпност.

Ще обърнем специално внимание на това кои конфигурации водят до загуба на данни поради потвърдено записване. Има верига от отговорност между издатели, брокери и потребители. След като съобщението бъде предадено на брокера, негова задача е да не загуби съобщението. Когато брокер потвърди съобщение до издател, ние не очакваме то да бъде загубено. Но ще видим, че това действително може да се случи в зависимост от конфигурацията на вашия брокер и издател.

Примитиви за устойчивост на единичен възел

Устойчиви опашки/маршрутизиране

Има два типа опашка в RabbitMQ: трайна/стабилна (трайна) и нестабилна (нетрайна). Всички опашки се съхраняват в базата данни Mnesia. Устойчивите опашки се предекларират при стартиране на възела и по този начин оцеляват при рестартиране, срив на системата или срив на сървъра (докато данните продължават). Това означава, че докато декларирате маршрутизирането (обмяната) и опашката за постоянни, инфраструктурата за опашка/маршрутизиране ще се върне онлайн.

Променливите опашки и маршрутизирането се премахват, когато възелът се рестартира.

Устойчиви послания

Само защото една опашка е издръжлива, не означава, че всички нейни съобщения ще оцелеят след рестартиране на възел. Само съобщения, определени от издателя като продължителен (постоянен). Постоянните съобщения наистина натоварват брокера допълнително, но ако загубата на съобщение е неприемлива, тогава няма друга опция.

Ориз. 1. Матрица на стабилност

Клъстериране с дублиране на опашка

За да преживеем загубата на брокер, имаме нужда от съкращения. Можем да клъстерираме множество RabbitMQ възли и след това да добавим допълнително излишък чрез репликиране на опашки в множество възли. По този начин, ако един възел падне, ние не губим данни и оставаме достъпни.

Дублиране на опашка:

• една главна опашка (главна), която получава всички команди за запис и четене
• едно или повече огледала, които получават всички съобщения и метаданни от главната опашка. Тези огледала не съществуват за мащабиране, а чисто за излишък.

Ориз. 2. Огледално копиране на опашката

Дублирането се задава от съответната политика. В него можете да изберете фактора на репликация и дори възлите, на които да бъде поставена опашката. Примери:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (един майстор и едно огледало)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Потвърждение на издателя

Потвържденията на издателя са необходими за постигане на последователно писане. Без тях има шанс да загубите съобщения. Потвърждение се изпраща на издателя, след като съобщението е записано на диска. RabbitMQ записва съобщения на диска не при получаване, а на периодична основа, в района на няколкостотин милисекунди. Когато опашката е дублирана, потвърждението се изпраща само след като всички копия на съобщението са записали на диска. Това означава, че използването на потвърждения добавя латентност, но ако сигурността на данните е важна, те са необходими.

Опашка при отказ

Когато брокер се изключи или се срине, всички лидери на опашка (главни) на този възел отпадат с него. След това клъстерът избира най-старото огледало на всеки мастер и го популяризира като нов мастер.

Ориз. 3. Множество огледални опашки и техните политики

Брокер 3 се срива. Обърнете внимание, че огледалото на опашка C на брокер 2 е повишено до главен. Също така имайте предвид, че е създадено ново огледало за опашка C на брокер 1. RabbitMQ винаги се опитва да поддържа коефициента на репликация, посочен във вашите правила.

Ориз. 4. Брокер 3 пада, причинявайки неуспех на опашка C

Следващият брокер 1 не работи! Остана ни само един брокер. Огледалото на опашка B се повишава до главен.

Фиг. 5

Върнахме брокер 1. Без значение колко добре данните са преживели загубата и възстановяването на брокера, всички огледални съобщения от опашката се отхвърлят при рестартиране. Това е важно да се отбележи, тъй като ще има последствия. Ще прегледаме тези последици скоро. Така че брокер 1 сега отново е член на клъстера и клъстерът се опитва да се съобрази с правилата и следователно създава огледални сървъри на брокер 1.

В този случай загубата на Брокер 1 е пълна, както и загубата на данни, така че неогледалната опашка B е напълно загубена.

Ориз. 6. Брокер 1 се връща към услугата

Брокер 3 отново е онлайн, така че опашки A и B получават своите огледала обратно, за да задоволят своите HA политики. Но сега всички главни опашки са на един и същи възел! Не е перфектно, по-добре е да има равномерно разпределение между възлите. За съжаление няма конкретни опции за ребалансиране на главните. Ще се върнем към този проблем по-късно, тъй като първо трябва да разгледаме синхронизирането на опашката.

Ориз. 7. Брокер 3 се връща към услугата. Всички главни опашки на един възел!

Така че вече трябва да имате представа как огледалата осигуряват излишък и толерантност към грешки. Това гарантира наличност в случай на повреда на единичен възел и предпазва от загуба на данни. Но все още не сме приключили, защото всъщност всичко е много по-сложно.

синхронизация

Когато се създаде ново огледало, всички нови съобщения винаги ще бъдат репликирани към това огледало и всички други. Що се отнася до съществуващите данни в главната опашка, можем да ги копираме в ново огледало, което става пълно копие на главния. Можем също така да изберем да не репликираме съществуващи съобщения и да позволим на главната опашка и новото огледало да се сближат във времето, когато новите съобщения влизат в опашката и съществуващите съобщения напускат главата на главната опашка.

Тази синхронизация е автоматична или ръчна и се контролира от политика за опашка. Помислете за пример.

Имаме две огледални опашки. Опашка A се синхронизира автоматично, докато опашка B се синхронизира ръчно. И двете опашки съдържат десет съобщения.

Ориз. 8. Две опашки с различни режими на синхронизиране

Сега губим Брокер 3.

Ориз. 9. Брокер 3 падна

Брокер 3 отново работи. Клъстерът създава огледало за всяка опашка на новия възел и автоматично синхронизира новата опашка A с главния. Огледалото на новата опашка B обаче остава празно. По този начин имаме пълно резервиране на опашка A и само едно огледало за съществуващите съобщения на опашка B.

Ориз. 10. Новото огледало на опашка A получава всички съществуващи съобщения, но новото огледало на опашка B не

И двете опашки получават още десет съобщения. След това брокер 2 се изключва и опашка А се връща към най-старото огледало, което е на брокер 1. Няма загуба на данни, когато се провали. Опашка B има двадесет съобщения в главния и само десет в огледалото, защото тази опашка никога не е репликирала оригиналните десет съобщения.

Ориз. 11. Опашка А се връща обратно от Брокер 1 без загуба на съобщение

И двете опашки получават още по десет съобщения. Сега се срива брокер 1. Опашка A преминава към огледалото без загуба на съобщение. Опашка B обаче има проблеми. На този етап можем да оптимизираме наличността или последователността.

Ако искаме да оптимизираме наличността, тогава политиката ха-промоция-при-неуспех трябва да се инсталира в винаги. Това е стойността по подразбиране, така че можете просто да не посочите правилото изобщо. В такъв случай всъщност ние допускаме грешки в несинхронизирани огледала. Това ще доведе до загуба на съобщения, но опашката остава четима и записвана.

Ориз. 12. Опашка А се връща обратно към Брокер 3 без загуба на съобщение. Опашка B се връща обратно към Брокер 3 с десет загубени съобщения

Можем и да монтираме ha-promote-on-failure в смисъл when-synced. В този случай, вместо да се върне обратно към огледалото, опашката ще изчака, докато Брокер 1 се върне онлайн със своите данни. След като се върне, основната опашка се връща на Брокер 1 без загуба на данни. Наличността се жертва за сигурността на данните. Но това е рисков режим, който може да доведе дори до пълна загуба на данни, което ще разгледаме след малко.

Ориз. 13. Опашка B остава недостъпна след загуба на Брокер 1

Можете да зададете въпроса: "Може би е по-добре никога да не използвате автоматична синхронизация?". Отговорът е, че синхронизирането е блокираща операция. По време на синхронизация главната опашка не може да извършва никакви операции за четене или запис!

Помислете за пример. Сега имаме много дълги опашки. Как могат да пораснат до такъв размер? Поради няколко причини:

• Опашките не се използват активно
• Това са високоскоростни опашки и в момента потребителите работят бавно.
• Това са високоскоростни опашки, има авария и потребителите наваксват

Ориз. 14. Две големи опашки с различни времеви режими

Брокер 3 сега се срива.

Ориз. 15. Брокер 3 се срива, оставяйки по един главен и огледален във всяка опашка

Брокер 3 се връща онлайн и се създават нови огледала. Главна опашка A започва да копира съществуващи съобщения към новото огледало и през това време опашката е недостъпна. Отнема два часа за копиране на данни, което води до два часа престой за тази опашка!

Опашка B обаче остава достъпна през целия период. Тя пожертва малко излишък за достъпност.

Ориз. 16. Опашката остава недостъпна по време на синхронизация

След два часа опашка A също става достъпна и може да започне отново да приема четения и записи.

Актуализации

Това блокиращо поведение по време на синхронизация затруднява актуализирането на клъстери с много големи опашки. В даден момент главният възел трябва да се рестартира, което означава или да отидете до огледалото, или да изключите опашката по време на надстройката на сървъра. Ако изберем преход, ще загубим съобщения, ако огледалата не са синхронизирани. По подразбиране, по време на прекъсване на брокера, не се извършва преход към несинхронизирано огледало. Това означава, че веднага щом брокерът се върне, ние не губим никакви съобщения, единствената щета е просто обикновена опашка. Правилата за поведение при прекъсване на връзката с брокера се определят от политиката ha-promote-on-shutdown. Можете да зададете една от двете стойности:

• always= Разрешено прехвърляне към несинхронизирани огледални сървъри
• when-synced= Преместете само към синхронизирано огледало, в противен случай опашката става нечетима и записваема. Опашката се връща към обслужване веднага щом брокерът се върне

По един или друг начин, с големи опашки, трябва да избирате между загуба на данни и недостъпност.

Когато наличността подобрява сигурността на данните

Има още едно усложнение, което трябва да имате предвид, преди да вземете решение. Докато автоматичното синхронизиране е по-добро за резервиране, как се отразява на сигурността на данните? Разбира се, с по-добро резервиране, RabbitMQ е по-малко вероятно да загуби съществуващи съобщения, но какво да кажем за новите съобщения от издателите?

Тук трябва да имате предвид следното:

• Може ли издателят просто да върне грешка и да накара услугата нагоре или потребителя да опита отново по-късно?
• Може ли издателят да запази съобщението локално или в базата данни, за да опита отново по-късно?

Ако издателят може само да пусне съобщението, тогава всъщност подобряването на достъпността подобрява и сигурността на данните.

Така трябва да се търси баланс, а решението зависи от конкретната ситуация.

Проблеми с ha-promote-on-failure=when-synced

Идея ха-промоция-при-неуспех= при синхронизиране е, че предотвратяваме превключването към несинхронизирано огледало и по този начин избягваме загуба на данни. Опашката остава нечетима или записваема. Вместо това се опитваме да върнем падналия брокер с непокътнати данни, така че да може да се възобнови като главен без загуба на данни.

Но (и това е голямо но), ако брокерът загуби данните си, тогава имаме голям проблем: опашката е загубена! Всички данни са изчезнали! Дори ако имате огледала, които най-вече наваксват основната опашка, тези огледала също се изхвърлят.

За да добавим отново възел със същото име, казваме на клъстера да забрави осиротелия възел (с rabbitmqctl забравете_клъстер_възел) и стартирайте нов брокер със същото име на хост. Докато клъстерът помни изгубения възел, той помни старата опашка и несинхронизираните огледала. Когато на клъстера се каже да забрави загубен възел, тази опашка също се забравя. Сега трябва да го декларираме отново. Загубихме всички данни, въпреки че имахме огледала с частичен набор от данни. Би било по-добре да преминете към несинхронизирано огледало!

Следователно ръчната синхронизация (и неуспешна синхронизация) в комбинация с ha-promote-on-failure=when-syncedдоста рисковано според мен. Документите казват, че тази опция съществува за сигурност на данните, но това е нож с две остриета.

Овладейте повторно балансиране

Както обещахме, връщаме се към проблема с натрупването на всички главни на един или повече възли. Това дори може да се случи в резултат на текуща актуализация на клъстера. В клъстер с три възела всички главни опашки ще се натрупват на един или два възела.

Повторното балансиране на мастъри може да бъде проблематично поради две причини:

• Няма добри инструменти за извършване на ребалансиране
• Синхронизация на опашка

Има трета страна за ребалансиране плъгин, който не се поддържа официално. Относно плъгини на трети страни в ръководството на RabbitMQ казах: „Плъгинът предоставя някои допълнителни инструменти за конфигуриране и отчитане, но не се поддържа или тества от екипа на RabbitMQ. Използвайте на свой собствен риск."

Има още един трик за преместване на основната опашка през HA политики. Ръководството споменава сценарий за това. Работи така:

• Премахва всички огледални сървъри с помощта на временна политика с по-висок приоритет от съществуващата HA политика.
• Променя временната политика на HA, за да използва режим „възли“, като указва възела, към който искате да преместите основната опашка.
• Синхронизира опашката за принудителна миграция.
• След като миграцията приключи, тя изтрива временната политика. Оригиналната HA политика влиза в сила и се създава необходимия брой огледални сървъри.

Недостатъкът е, че този подход може да не работи, ако имате големи опашки или строги изисквания за резервиране.

Сега нека видим как RabbitMQ клъстерите работят с мрежови дялове.

Прекъсване на връзката

Възлите на разпределената система са свързани чрез мрежови връзки, а мрежовите връзки могат и ще бъдат прекъснати. Честотата на прекъсванията зависи от местната инфраструктура или надеждността на избрания облак. Така или иначе, разпределените системи трябва да могат да се справят с тях. Отново имаме избор между наличност и последователност и отново добрата новина е, че RabbitMQ предоставя и двете опции (само не по едно и също време).

С RabbitMQ имаме две основни опции:

• Позволете логическо разделяне (разделен мозък). Това гарантира наличност, но може да причини загуба на данни.
• Деактивирайте логическото разделяне. Може да доведе до краткосрочна загуба на наличност в зависимост от това как клиентите се свързват към клъстера. Може също да причини пълна недостъпност в клъстер с два възела.

Но какво е логично разделяне? Това е моментът, когато клъстерът се разделя на две поради загуба на мрежови връзки. От всяка страна огледалата се повишават до главния, така че в крайна сметка има няколко главни на опашка.

Ориз. 17. Основна опашка и две огледала, всяко на отделен възел. След това има повреда в мрежата и едно огледало е отделено. Отделеният възел вижда, че другите два са паднали и придвижва своите огледала към главния. Сега имаме две основни опашки, и двете от които могат да се четат и записват.

Ако издателите изпратят данни и на двата главни устройства, ще имаме две различни копия на опашката.

Различните режими на RabbitMQ осигуряват наличност или последователност.

Режим на игнориране (по подразбиране)

Този режим осигурява достъпност. След загубата на връзка настъпва логично разделяне. След като връзката бъде възстановена, администраторът трябва да реши кой дял да даде приоритет. Губещата страна ще бъде рестартирана и всички натрупани данни от тази страна ще бъдат загубени.

Ориз. 18. Трима издатели са свързани с трима брокери. Вътрешно клъстерът насочва всички заявки към главната опашка на Брокер 2.

Сега губим брокер 3. Той вижда, че другите брокери са паднали и придвижва огледалото си към капитана. Така се получава логичното разделяне.

Ориз. 19. Логическо разделение (split-brain). Записите отиват на двете основни опашки, а двете копия излизат.

Връзката е възстановена, но логическото разделяне остава. Администраторът трябва ръчно да избере губещата страна. В следния случай администраторът рестартира Broker 3. Всички съобщения, които той не е имал време да предаде, се губят.

Ориз. 20. Администратор деактивира Брокер 3.

Ориз. 21. Администраторът стартира Broker 3 и той се присъединява към клъстера, губейки всички съобщения, които са останали там.

По време на загубата на връзка и след нейното възстановяване, клъстерът и тази опашка бяха достъпни за четене и запис.

Режим на автоматично лечение

Работи подобно на режима на игнориране, с изключение на това, че самият клъстер автоматично избира губещата страна след разделяне и повторно свързване. Губещата страна се връща към празния клъстер и опашката губи всички съобщения, които са били изпратени само до тази страна.

Поставяне на второстепенен режим на пауза

Ако не искаме да разрешим логическо разделяне, тогава единствената ни възможност е да откажем да четем и записваме от по-малката страна след дяла на клъстера. Когато брокерът види, че е от по-малката страна, той спира работа, тоест затваря всички съществуващи връзки и отказва всякакви нови. Веднъж в секунда той проверява за повторно свързване. Веднага щом връзката бъде възстановена, той възобновява работата и се присъединява към клъстера.

Ориз. 22. Трима издатели са свързани с трима брокери. Вътрешно клъстерът насочва всички заявки към главната опашка на Брокер 2.

След това брокери 1 и 2 се отделят от брокер 3. Вместо да повиши огледалото си до главен, брокер 3 спира и става недостъпен.

Ориз. 23. Брокер 3 спира, изключва всички клиенти и отхвърля заявките за свързване.

Веднага щом връзката бъде възстановена, той се връща в клъстера.

Нека да разгледаме друг пример, където основната опашка е на Broker 3.

Ориз. 24. Основна опашка при Брокер 3.

След това настъпва същата загуба на връзка. Брокер 3 спира, защото е от по-малката страна. От друга страна, възлите виждат, че Брокер 3 е паднал, така че по-старото огледало от Брокери 1 и 2 е повишено в главен.

Ориз. 25. Превключване към Брокер 2, когато Брокер 3 не е наличен.

Когато връзката бъде възстановена, Broker 3 ще се присъедини към клъстера.

Ориз. 26. Клъстерът се върна към нормална работа.

Тук е важно да разберем, че получаваме последователност, но можем да получим и достъпност, ако успешно ще прехвърлим клиенти към по-голямата част от секцията. За повечето ситуации аз лично бих избрал режима Pause Minority, но наистина зависи от конкретния случай.

За да се осигури достъпност, е важно да се гарантира, че клиентите успешно се свързват с хоста. Нека да разгледаме нашите възможности.

Осигуряване на свързаност на клиента

Имаме няколко опции за това как да насочваме клиенти към основната част на клъстера или към работещи възли след загуба на връзка (след повреда на един възел). Първо, нека си припомним, че определена опашка се хоства на конкретен възел, но маршрутизирането и политиките се копират във всички възли. Клиентите могат да се свързват с всеки възел и вътрешното маршрутизиране ще ги насочи там, където трябва да отидат. Но когато даден възел е поставен на пауза, той отхвърля връзките, така че клиентите трябва да се свържат с друг възел. Ако възелът е паднал, той може да направи малко.

Нашите опции:

• Достъпът до клъстера се осъществява от балансьор на натоварването, който просто преминава през възлите и клиентите се опитват да се свържат отново, докато успеят. Ако даден възел не работи или е спрян, тогава опитите за свързване с този възел ще бъдат неуспешни, но последващите опити ще отидат към други сървъри (по кръгов начин). Това е подходящо за моментна загуба на връзка или свален сървър, който ще бъде активиран бързо.
• Достъп до клъстера чрез балансьор на натоварването и премахване на спрени/паднали възли от списъка веднага щом бъдат открити. Ако това стане бързо и ако клиентите могат да опитат отново връзката, тогава ще получим постоянна наличност.
• Дайте на всеки клиент списък с всички възли и клиентът произволно избира един от тях, когато се свърже. Ако получи грешка при опит за свързване, той преминава към следващия възел в списъка, докато не се свърже.
• Премахнете трафика от свален/спрян хост с помощта на DNS. Това се прави с малък TTL.

Данни

Клъстерирането на RabbitMQ има своите предимства и недостатъци. Най-сериозните недостатъци са, че:

• когато се присъединяват към клъстер, възлите изхвърлят своите данни;
• блокиране на синхронизацията кара опашката да стане недостъпна.

Всички трудни решения произтичат от тези две архитектурни характеристики. Ако RabbitMQ може да запазва данни при повторно присъединяване към клъстера, тогава синхронизирането ще бъде по-бързо. Ако беше в състояние на неблокираща синхронизация, щеше да поддържа по-добре големи опашки. Коригирането на тези два проблема значително ще подобри производителността на RabbitMQ като устойчива на грешки и високодостъпна технология за съобщения. Бих се колебал да препоръчам RabbitMQ с групиране в следните ситуации:

• Ненадеждна мрежа.
• Ненадеждно съхранение.
• Много дълги редове.

Що се отнася до настройките за висока наличност, вземете предвид следните:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (Or autoheal)
• устойчиви послания
• уверете се, че клиентите се свързват с активния възел, когато някой възел падне

За съгласуваност (сигурност на данните) помислете за следните настройки:

• Потвърждения на издателя и ръчни потвърждения от страна на потребителя
• ha-promote-on-failure=when-syncedако издателите могат да опитат отново по-късно и ако имате много силно хранилище! Иначе сложи =always.
• ha-sync-mode=automatic (но големите неактивни опашки може да изискват ръчен режим; също така помислете дали недостъпността ще доведе до загуба на съобщения)
• Поставяне на режим на малцинство на пауза
• устойчиви послания

Все още не сме обхванали всички проблеми на толерантността към грешки и високата наличност; например как безопасно да изпълнявате административни процедури (като непрекъснати актуализации). Трябва също да поговорим за федерацията и приставката Shovel.

Ако съм пропуснал нещо друго, моля да ме уведомите.

Вижте и моя посткъдето погромствам RabbitMQ клъстер с Docker и Blockade, за да тествам някои от сценариите за загуба на съобщения, описани в тази статия.

Предишни статии от поредицата:
номер 1 - habr.com/ru/company/itsumma/blog/416629
номер 2 - habr.com/ru/company/itsumma/blog/418389
номер 3 - habr.com/ru/company/itsumma/blog/437446

Източник: www.habr.com