Избор на вашата HA топология
Има различни начини за запазване на висока наличност с бази данни. Можете да използвате виртуални IP адреси (VRRP), за да управлявате наличността на хост, можете да използвате мениджъри на ресурси като Zookeeper и Etcd, за да (пре)конфигурирате вашите приложения или да използвате балансьори/прокси сървъри, за да разпределите натоварването върху всички налични хостове.
Виртуалните IP адреси се нуждаят или от приложение за управлението им (MHA, Orchestrator), някои скриптове (Keepalived, Pacemaker/Corosync) или инженер, който да се откаже ръчно и вземането на решения в процеса може да стане сложно. Преминаването на виртуален IP адрес е лесен и лесен процес чрез премахване на IP адреса от един хост, присвояването му на друг и използване на arping за изпращане на безвъзмезден ARP отговор. На теория виртуален IP може да бъде преместен за секунда, но ще отнеме няколко секунди, преди приложението за управление на отказ да се увери, че хостът се е провалил и да действа съответно. В действителност това трябва да бъде някъде между 10 и 30 секунди. Друго ограничение на виртуалните IP адреси е, че някои доставчици на облак не ви позволяват да управлявате собствените си виртуални IP адреси или изобщо да ги присвоявате. Например Google не ви позволява да правите това на техните изчислителни възли.
Мениджърите на ресурси като Zookeeper и Etcd могат да наблюдават вашите бази данни и (пре)конфигурират вашите приложения, след като хост се повреди или подчинен бъде повишен в главен. Като цяло това е добра идея, но прилагането на вашите проверки с Zookeeper и Etcd е сложна задача.
Балансьор на натоварване или прокси ще седи между приложението и хоста на базата данни и ще работи прозрачно, сякаш клиентът ще се свърже директно с хоста на базата данни. Точно както при виртуалния IP и мениджърите на ресурси, балансьорите на натоварване и прокси сървърите също трябва да наблюдават хостовете и да пренасочват трафика, ако един хост не работи. ClusterControl поддържа два прокси сървъра:HAProxy и ProxySQL и двата се поддържат за MySQL главен-подчинен репликация и за клъстер Galera. HAProxy и ProxySQL имат свои собствени случаи на употреба, ние ще ги опишем и в тази публикация.
Защо ви е необходим Load Balancer?
На теория нямате нужда от балансьор на натоварването, но на практика ще предпочетете такъв. Ще обясним защо.
Ако имате настройка на виртуални IP адреси, всичко, което трябва да направите, е да насочите приложението си към правилния (виртуален) IP адрес и всичко трябва да е наред по отношение на връзката. Но да предположим, че сте увеличили броя на репликите за четене, може да искате да предоставите виртуални IP адреси за всяка от тези реплики за четене поради причини за поддръжка или наличност. Това може да се превърне в много голям набор от виртуални IP адреси, които трябва да управлявате. Ако една от тези реплики за четене е имала неуспех, трябва да пренастроите виртуалния IP на друг хост или в противен случай приложението ви ще се свърже или с хост, който не работи, или в най-лошия случай, изоставащ сървър с остарели данни. Поради това е необходимо поддържането на състоянието на репликация към приложението, което управлява виртуалните IP адреси.
Също така за Galera има подобно предизвикателство:на теория можете да добавите толкова хостове, колкото искате, към конфигурацията на приложението си и да изберете един на случаен принцип. Същият проблем възниква, когато този хост не работи:в крайна сметка може да се свържете с недостъпен хост. Също така използването на всички хостове както за четене, така и за запис може също да доведе до връщане назад поради оптимистичното заключване в Galera. Ако две връзки се опитат да пишат в един и същи ред едновременно, една от тях ще получи връщане назад. В случай, че вашето работно натоварване има такива едновременни актуализации, се препоръчва да използвате само един възел в Galera, за да пишете. Затова искате мениджър, който следи вътрешното състояние на вашия клъстер от база данни.
И HAProxy, и ProxySQL ще ви предложат функционалността да наблюдавате хостовете на базата данни MySQL/MariaDB и да поддържате състоянието на вашия клъстер и неговата топология. За настройките за репликация, в случай че подчинена реплика не работи, както HAProxy, така и ProxySQL могат да преразпределят връзките към друг хост. Но ако главен код на репликация не работи, HAProxy ще откаже връзката и ProxySQL ще върне правилна грешка на клиента. За настройките на Galera и двата балансира на натоварването могат да изберат главен възел от клъстера на Galera и да изпращат операциите за запис само до този конкретен възел.
На пръв поглед HAProxy и ProxySQL може да изглеждат подобни решения, но те се различават много по функции и начина, по който разпределят връзките и заявките. HAProxy поддържа редица алгоритми за балансиране като най-малко връзки, източник, произволно и кръгово разпределение, докато ProxySQL разпределя връзките, използвайки базирания на тегло алгоритъм за кръгов цикъл (равно тегло означава равно разпределение). Тъй като ProxySQL е интелигентен прокси, той е наясно с базата данни и също така може да анализира вашите заявки. ProxySQL е в състояние да извършва разделяне на четене/запис въз основа на правила за заявка, където можете да препращате заявките към определените подчинени или главни във вашия клъстер. ProxySQL включва допълнителна функционалност като пренаписване на заявки, кеширане и защитна стена на заявки с генериране на задълбочена статистика в реално време за работното натоварване.
Това би трябвало да е достатъчна основна информация по тази тема, така че нека да видим как можете да разположите както балансьорите на натоварване за репликация на MySQL, така и за топологиите на Galera.
Разгръщане на HAProxy
Използването на ClusterControl за разгръщане на HAProxy в клъстер Galera е лесно:отидете на съответния клъстер и изберете „Add Load Balancer“:
И ще можете да разположите HAProxy екземпляр, като добавите адреса на хоста и изберете сървърните екземпляри, които искате да включите в конфигурацията:
По подразбиране HAProxy екземплярът ще бъде конфигуриран да изпраща връзки към сървърните екземпляри, получаващи най-малък брой връзки, но можете да промените тази политика или на кръгов режим, или на източник.
Под разширените настройки можете да зададете изчакване, максимално количество връзки и дори да защитите прокси сървъра, като добавите в белия списък IP диапазон за връзките.
Под раздела възли на този клъстер ще се появи възелът HAProxy:
Сега вашият клъстер Galera е достъпен и чрез новоразгърнатия HAProxy възел на порт 3307. Не забравяйте да ПРЕДОСТАВИТЕ достъп на приложението си от HAProxy IP, тъй като сега трафикът ще идва от прокси сървъра вместо от хостовете на приложението. Също така не забравяйте да насочите връзката на приложението си към възела HAProxy.
Сега да предположим, че единият сървърен екземпляр ще падне, HAProxy ще забележи това в рамките на няколко секунди и ще спре да изпраща трафик към този екземпляр:
Другите два възела все още са добре и ще продължат да получават трафик. Това запазва клъстера много достъпен, без клиентът дори да забележи разликата.
Разгръщане на вторичен HAProxy възел
Сега, след като прехвърлихме отговорността за запазване на висока наличност през връзките към базата данни от клиента към HAProxy, какво ще стане, ако прокси възелът умре? Отговорът е да създадете друг HAProxy екземпляр и да използвате виртуален IP, контролиран от Keepalived, както е показано на тази диаграма:
Предимството в сравнение с използването на виртуални IP адреси на възлите на базата данни е, че логиката за MySQL е на ниво прокси и преминаването при отказ за прокси сървърите е лесно.
Така че нека разположим вторичен HAProxy възел:
След като сме разположили вторичен HAProxy възел, трябва да добавим Keepalived:
И след като Keepalived бъде добавен, прегледът на вашите възли ще изглежда така:
Така че сега вместо да насочвате връзките на приложението си директно към HAProxy възела, трябва да ги насочите към виртуалния IP.
В примера тук използвахме отделни хостове, за да стартираме HAProxy, но можете лесно да ги добавите и към съществуващи сървърни инстанции. HAProxy не носи много допълнителни разходи, въпреки че трябва да имате предвид, че в случай на повреда на сървъра ще загубите както възела на базата данни, така и проксито.
Разгръщане на ProxySQL
Разгръщането на ProxySQL във вашия клъстер се извършва по подобен начин на HAProxy:„Добавяне на Load Balancer“ в списъка с клъстери в раздела ProxySQL.
В съветника за внедряване посочете къде ще бъде инсталиран ProxySQL, потребителя/паролата за администриране, потребителя/паролата за наблюдение за свързване към сървърите на MySQL. От ClusterControl можете или да създадете нов потребител, който да бъде използван от приложението (потребителят ще бъде създаден както на MySQL, така и на ProxySQL) или да използвате съществуващите потребители на база данни (потребителят ще бъде създаден само на ProxySQL). Задайте дали използвате неявни транзакции или не. По принцип, ако не използвате SET autocommit=0 за създаване на нова транзакция, ClusterControl ще конфигурира разделяне на четене/запис.
След като ProxySQL бъде разгърнат, той ще бъде достъпен в раздела Възли:
Отварянето на прегледа на възела ProxySQL ще ви представи интерфейса за наблюдение и управление на ProxySQL, така че вече няма причина да влизате в ProxySQL на възела. ClusterControl обхваща повечето от важните статистически данни за ProxySQL като използване на паметта, кеш на заявки, процесор на заявки и така нататък, както и други показатели като хост групи, бекенд сървъри, посещения на правила за заявки, най-добри заявки и променливи на ProxySQL. В аспекта на управлението на ProxySQL можете да управлявате правилата за заявки, бекенд сървъри, потребители, конфигурация и планировчик направо от потребителския интерфейс.
Вижте нашата страница с урок за ProxySQL, която обхваща подробно как да извършите балансиране на натоварването на базата данни за MySQL и MariaDB с ProxySQL.
Разгръщане на Garbd
Galera внедрява базиран на кворум алгоритъм за избор на основен компонент, чрез който налага последователност. Основният компонент трябва да има мнозинство от гласовете (50% + 1 възел), така че в система с 2 възела няма да има мнозинство, което води до разделяне на мозъка. За щастие е възможно да се добави garbd (Galera Arbitrator Daemon), който е лек демон без състояние, който може да действа като нечетен възел. Допълнителното предимство от добавянето на Galera Arbitrator е, че вече можете да правите само с два възела във вашия клъстер.
Ако ClusterControl открие, че вашият клъстер Galera се състои от четен брой възли, ще получите предупреждение/съвет от ClusterControl да разширите клъстера до нечетен брой възли:
Изберете разумно хоста, на който да разположите garbd, тъй като той ще получава всички репликирани данни. Уверете се, че мрежата може да се справи с трафика и е достатъчно сигурна. Можете да изберете един от хостовете HAProxy или ProxySQL, на които да разположите garbd, като в примера по-долу:
Обърнете внимание, че започвайки от ClusterControl 1.5.1, garbd не може да бъде инсталиран на същия хост като ClusterControl поради риск от конфликти на пакети.
След като инсталирате garbd, ще го видите да се показва до двата ви възела на Galera:
Последни мисли
Показахме ви как да направите настройките на вашия MySQL master-slave и Galera клъстер по-стабилни и да запазите висока наличност, използвайки HAProxy и ProxySQL. Също така garbd е хубав демон, който може да запази допълнителния трети възел във вашия клъстер Galera.
Това финализира страната за внедряване на ClusterControl. В следващия ни блог ще ви покажем как да интегрирате ClusterControl във вашата организация, като използвате групи и присвоите определени роли на потребителите.
