Разгръщането на клъстер от база данни не е ракетна наука - има много инструкции как да направите това. Но как да разберете, че това, което току-що разположихте, е готово за производство? Ръчното внедряване също може да бъде досадно и повтарящо се. В зависимост от броя на възлите в клъстера, стъпките за внедряване може да отнемат време и да са податливи на грешки. Инструментите за управление на конфигурацията като Puppet, Chef и Ansible са популярни при разгръщането на инфраструктура, но за клъстери на база данни с данни за състояние трябва да изпълните значителни скриптове, за да се справите с разгръщането на целия HA стек на базата данни. Освен това избраният шаблон/модул/готварска книга/роля трябва да бъде внимателно тестван, преди да можете да му се доверите като част от автоматизацията на вашата инфраструктура. Промените във версиите изискват скриптовете да бъдат актуализирани и тествани отново.
Добрата новина е, че ClusterControl автоматизира внедряването на целия стек - и то безплатно! Внедрихме хиляди производствени клъстери и предприехме редица предпазни мерки, за да гарантираме, че са готови за производство. Поддържат се различни топологии, от главен-подчинен репликация до Galera, NDB и InnoDB клъстер, с различни прокси сървъри на базата данни отгоре.
Стек с висока наличност, разгърнат чрез ClusterControl, се състои от три слоя:
- Слой на базата данни (напр. клъстер Galera)
- Обратно прокси слой (напр. HAProxy или ProxySQL)
- Keepalived слой, който, с използването на виртуален IP, гарантира висока наличност на прокси слоя
В този блог ще ви покажем как да разположите производствен клас Galera Cluster в комплект с балансьори на натоварване за настройка на висока наличност. Пълната настройка се състои от 6 хоста:
- 1 хост - ClusterControl (сървър за внедряване, наблюдение, управление)
- 3 хоста - MySQL Galera Cluster
- 2 хоста – Обратните прокси сървъри действат като балансиращи натоварването пред клъстера.
Следната диаграма илюстрира нашия краен резултат, след като внедряването приключи:
Предварителни условия
ClusterControl трябва да се намира на независим възел, който не е част от клъстера. Изтеглете ClusterControl и страницата ще генерира уникален за вас лиценз и ще покаже стъпките за инсталиране на ClusterControl:
$ wget -O install-cc https://severalnines.com/scripts/install-cc
$ chmod +x install-cc
$ ./install-cc # as root or sudo userСледвайте инструкциите, където ще бъдете напътствани с настройката на MySQL сървър, MySQL root парола на ClusterControl възела, cmon парола за използване на ClusterControl и така нататък. Трябва да получите следния ред, след като инсталацията приключи:
Determining network interfaces. This may take a couple of minutes. Do NOT press any key.
Public/external IP => http://{public_IP}/clustercontrol
Installation successful. If you want to uninstall ClusterControl then run install-cc --uninstall.След това на сървъра ClusterControl генерирайте SSH ключ, който ще използваме за настройка на SSH без парола по-късно. Можете да използвате всеки потребител в системата, но той трябва да има способността да извършва операции на суперпотребител (sudoer). В този пример избрахме root потребител:
$ whoami
root
$ ssh-keygen -t rsaНастройте SSH без парола за всички възли, които искате да наблюдавате/управлявате чрез ClusterControl. В този случай ще настроим това на всички възли в стека (включително самия възел ClusterControl). На възел ClusterControl изпълнете следните команди и посочете root паролата, когато бъдете подканени:
$ ssh-copy-id [email protected] # clustercontrol
$ ssh-copy-id [email protected] # galera1
$ ssh-copy-id [email protected] # galera2
$ ssh-copy-id [email protected] # galera3
$ ssh-copy-id [email protected] # proxy1
$ ssh-copy-id [email protected] # proxy2След това можете да проверите дали работи, като изпълните следната команда на възел ClusterControl:
$ ssh [email protected] "ls /root"Уверете се, че можете да видите резултата от командата по-горе, без да е необходимо да въвеждате парола.
Разгръщане на клъстера
ClusterControl поддържа всички доставчици за Galera Cluster (Codership, Percona и MariaDB). Има някои малки разлики, които могат да повлияят на решението ви за избор на доставчик. Ако искате да научите за разликите между тях, вижте предишната ни публикация в блога – Сравнение на клъстерите на Galera – Codership срещу Percona срещу MariaDB.
За производствено внедряване, клъстер Galera с три възела е минимумът, който трябва да имате. Винаги можете да го мащабирате по-късно, след като клъстерът бъде разгърнат, ръчно или чрез ClusterControl. Ще отворим нашия потребителски интерфейс на ClusterControl на адрес https://192.168.55.160/clustercontrol и ще създадем първия потребител с администратор. След това отидете в горното меню и щракнете върху Разгръщане -> MySQL Galera и ще ви бъде представен следния диалогов прозорец:
Има две стъпки, първата е „Общи и SSH настройки“. Тук трябва да конфигурираме SSH потребителя, който ClusterControl трябва да използва за свързване към възлите на базата данни, заедно с пътя към SSH ключа (както е генериран в раздел Предпоставки), както и SSH порта на възлите на базата данни. ClusterControl предполага, че всички възли на базата данни са конфигурирани с един и същ SSH потребител, ключ и порт. След това дайте име на клъстера, в този случай ще използваме "MySQL Galera Cluster 5.7". Тази стойност може да бъде променена по-късно. След това изберете опциите, за да инструктирате ClusterControl да инсталира необходимия софтуер, да деактивира защитната стена и също така да деактивира модула за подобряване на сигурността в конкретната дистрибуция на Linux. Всички те се препоръчват да бъдат включени, за да се увеличи максимално потенциалът за успешно внедряване.
Щракнете върху Продължи и ще ви се покаже следният диалогов прозорец:
В следващата стъпка трябва да конфигурираме сървърите на базата данни - доставчик, версия, datadir, порт и т.н. - които са доста разбираеми. „Шаблон за конфигурация“ е името на файла на шаблона под /usr/share/cmon/templates на възела ClusterControl. "Хранилище" е как ClusterControl трябва да конфигурира хранилището на възела на базата данни. По подразбиране той ще използва хранилището на доставчика и ще инсталира най-новата версия, предоставена от хранилището. Въпреки това, в някои случаи потребителят може да има вече съществуващо хранилище, огледално от оригиналното хранилище поради ограничение на политиката за сигурност. Въпреки това ClusterControl поддържа повечето от тях, както е описано в ръководството за потребителя, под Хранилище.
И накрая, добавете IP адреса или името на хоста (трябва да е валидно FQDN) на възлите на базата данни. Ще видите зелена икона за отметка отляво на възела, което показва, че ClusterControl е успял да се свърже с възела чрез SSH без парола. Вече сте готови. Щракнете върху Разгръщане, за да започнете внедряването. Това може да отнеме от 15 до 20 минути. Можете да наблюдавате напредъка на внедряването под Дейност (горно меню) -> Работни места -> Създаване на клъстер :
След като внедряването приключи, в този момент нашата архитектура може да бъде илюстрирана, както следва:
Разгръщане на балансьорите на натоварване
В Galera Cluster всички възли са равни – всеки възел има една и съща роля и един и същ набор от данни. Следователно няма превключване при отказ в клъстера, ако възел се повреди. Само от страната на приложението се изисква отказ, за да се пропуснат неработещите възли, докато клъстерът е разделен. Ето защо е силно препоръчително да поставите балансьори на натоварване върху клъстер на Galera, за да:
- Обединете множеството крайни точки на базата данни в една крайна точка (хост за балансиране на натоварването или виртуален IP адрес като крайна точка).
- Балансирайте връзките към базата данни между сървърите на задната база данни.
- Извършвайте проверки на състоянието и препращайте връзките към базата данни само към здрави възли.
- Пренасочване/пренаписване/блокиране на обидни (лошо написани) заявки, преди да попаднат на сървърите на базата данни.
Има три основни избора на обратни прокси сървъри за Galera Cluster - HAProxy, MariaDB MaxScale или ProxySQL - всички могат да бъдат инсталирани и конфигурирани автоматично от ClusterControl. При това разгръщане ние избрахме ProxySQL, защото той проверява всичко по-горе, плюс разбира MySQL протокола на задните сървъри.
В тази архитектура искаме да използваме два ProxySQL сървъра, за да елиминираме всяка една точка на неизправност (SPOF) към нивото на базата данни, които ще бъдат свързани заедно с помощта на плаващ виртуален IP адрес. Ще обясним това в следващия раздел. Единият възел ще действа като активен прокси, а другият като горещ режим на готовност. Който и възел, който държи виртуалния IP адрес в даден момент, е активният възел.
За да разположите първия ProxySQL сървър, просто отидете в менюто за действие на клъстера (вдясно на лентата с обобщение) и щракнете върху Добавяне на Load Balancer -> ProxySQL -> Разгръщане на ProxySQL и ще видите следното:
Отново повечето от полетата се обясняват сами. В секцията „Потребител на база данни“ ProxySQL действа като шлюз, през който вашето приложение се свързва с базата данни. Приложението се удостоверява срещу ProxySQL, следователно трябва да добавите всички потребители от всички backend MySQL възли, заедно с техните пароли, в ProxySQL. От ClusterControl можете или да създадете нов потребител, който да бъде използван от приложението - можете да решите неговото име, парола, достъп до кои бази данни се предоставят и какви привилегии на MySQL ще има този потребител. Такъв потребител ще бъде създаден както от страна на MySQL, така и на ProxySQL. Вторият вариант, по-подходящ за съществуващи инфраструктури, е да се използват съществуващите потребители на база данни. Трябва да подадете потребителско име и парола и такъв потребител ще бъде създаден само на ProxySQL.
Последният раздел, "Неявна транзакция", ClusterControl ще конфигурира ProxySQL да изпраща целия трафик към главната, ако сме започнали транзакция с SET autocommit=0. В противен случай, ако използвате BEGIN или START TRANSACTION за създаване на транзакция, ClusterControl ще конфигурира разделяне на четене/запис в правилата на заявката. Това е, за да се гарантира, че ProxySQL ще обработва транзакциите правилно. Ако нямате представа как приложението ви прави това, можете да изберете второто.
Повторете същата конфигурация за втория възел на ProxySQL, с изключение на стойността "Адрес на сървъра", която е 192.168.55.182. След като приключите, и двата възела ще бъдат изброени в раздела „Възли“ -> ProxySQL, където можете да ги наблюдавате и управлявате директно от потребителския интерфейс:
В този момент нашата архитектура сега изглежда така:
Ако искате да научите повече за ProxySQL, разгледайте този урок – Балансиране на натоварването на базата данни за MySQL и MariaDB с ProxySQL – Урок.
Разгръщане на виртуалния IP адрес
Последната част е виртуалният IP адрес. Без него нашите балансьори на натоварване (обратни прокси сървъри) биха били слабата връзка, тъй като биха били единична точка на повреда - освен ако приложението няма способността автоматично да пренасочва неуспешни връзки към базата данни към друг балансьор на натоварване. Въпреки това е добра практика да ги обедините както с помощта на виртуален IP адрес, така и да опростите крайната точка на връзката към слоя на базата данни.
От Потребителски интерфейс на ClusterControl -> Добавяне на Load Balancer -> Keepalived -> Внедряване на Keepalived и изберете двата ProxySQL хоста, които сме разположили:
Също така посочете виртуалния IP адрес и мрежовия интерфейс, за да свържете IP адреса. Мрежовият интерфейс трябва да съществува и на двата възела на ProxySQL. След като бъде разгърнат, трябва да видите следните зелени отметки в лентата за обобщение на клъстера:
В този момент нашата архитектура може да бъде илюстрирана по-долу:
Нашият клъстер от база данни вече е готов за производствена употреба. Можете да импортирате съществуващата си база данни в нея или да създадете нова нова база данни. Можете да използвате функцията за управление на схеми и потребители, ако пробният лиценз не е изтекъл.
За да разберете как ClusterControl конфигурира Keepalived, вижте тази публикация в блога Как ClusterControl конфигурира виртуален IP адрес и какво да очаквате по време на отказ.
Свързване с клъстера на базата данни
От гледна точка на приложението и клиента, те трябва да се свържат с 192.168.55.180 на порт 6033, който е виртуалният IP адрес, плаващ отгоре на балансиращите устройства. Например, конфигурацията на базата данни на Wordpress ще бъде нещо подобно:
/** The name of the database for WordPress */
define( 'DB_NAME', 'wp_myblog' );
/** MySQL database username */
define( 'DB_USER', 'wp_myblog' );
/** MySQL database password */
define( 'DB_PASSWORD', 'mysecr3t' );
/** MySQL hostname - virtual IP address with ProxySQL load-balanced port*/
define( 'DB_HOST', '192.168.55.180:6033' );Ако искате да получите достъп до клъстера на базата данни директно, заобикаляйки балансира на натоварването, можете просто да се свържете с порт 3306 на хостовете на базата данни. Това обикновено се изисква от персонала на DBA за администриране, управление и отстраняване на неизправности. С ClusterControl повечето от тези операции могат да се извършват директно от потребителския интерфейс.
Последни мисли
Както е показано по-горе, разгръщането на клъстер от база данни вече не е трудна задача. Веднъж разгърнат, има пълен набор от безплатни функции за наблюдение, както и търговски функции за управление на архивиране, отказ/възстановяване и други. Бързото разгръщане на различни типове клъстерни/репликационни топологии може да бъде полезно при оценка на решенията за бази данни с висока наличност и как те пасват на вашата конкретна среда.
