В предишния ни блог обсъдихме ClusterControl CMON HA за висока достъпност на разпределената база данни, написана от Кшищоф Ксиазек в две отделни публикации. В този блог ще разгледаме разпределението на възли чрез on-prem и в публичен облак (с помощта на Google Cloud Platform (GCP)).
Причината, поради която написахме този блог, е, защото получихме въпроси за това как да внедрим екземпляр с висока наличност на ClusterControl с CMON възел(и), работещ предварително и друг(и) CMON възел(и), работещ на различен център за данни (като публичен облак). В предишния ни блог ClusterControl CMON HA за висока наличност на разпределена база данни използвахме възли на Galera Cluster, но този път ще използваме MySQL репликация с помощта на Percona Server 5.7. Идеална настройка за това е винаги да капсулирате комуникацията на възли от вашия on-prem и вашите възли, пребиваващи в публичен облак чрез VPN или защитен канал.
ClusterControl CMON HA е на ранен етап, за който смятаме, че все още не е достатъчно зрял. И все пак, нашият CMON HA е в състояние да ви предостави усещането за функционалност за внедряване на ClusterControl, за да го направи високодостъпен. Нека продължим с това как можете да внедрите и настроите разпространението на възлите чрез on-prem чрез публичния облак.
Какво е CMON?
Преди да преминем към основната тема, нека ви представим какво е CMON. CMON означава ClusterControl Controller, който е „основният мозък“ на ClusterControl. Бекенд услуга, изпълняваща задачи за автоматизация, управление, наблюдение на графика, както и наличността на HA. Събраните данни се съхраняват в базата данни CMON, за която използваме MySQL съвместими бази данни като хранилище.
Архитектурната настройка
Някои от вас може да не са познавали възможностите на ClusterControl, които може да изпълнява и да бъде настроен за висока наличност. Ако имате няколко работещи възли ClusterControl (или CMON), това е възможно безплатно. Може да сте в състояние да изпълнявате тонове възли на ClusterControl, когато имате нужда.
За тази настройка ще имаме възли на ClusterControl върху ClusterControl, за да създаваме или разгръщаме възлите на базата данни и да управляваме автоматично преминаване при отказ, когато възникне грешка, например. Въпреки че можете да използвате MHA, Orchestrator или Maxscale за управление на автоматичния отказ, но за ефективност и скорост ще използвам ClusterControl, за да правя специалните неща, които другите инструменти, които споменах, нямат.
И така, нека да разгледаме диаграмата за тази настройка:
Настройката, базирана на тази диаграма, показва, че върху CMON с три възела , работещ CMON (ClusterControl) е върху тях, който ще наблюдава автоматичното преминаване при отказ. След това HAProxy ще може да балансира натоварването между наблюдаваните три CMON възела, като единият възел се намира в отделен регион, хостван в GCP за този блог. Може да забележите, че не сме включили Keepalived, защото не можем да поставим VIP под GCP, тъй като е в друга мрежа.
Както може би сте забелязали, ние поставяме общо три възела. CMON HA изисква да имаме нужда от поне 3 възела, за да продължим процес на гласуване или така наречения кворум. Така че за тази настройка изискваме да имате поне 3 възела, за да имате по-висока наличност.
Разгръщане на възли за On-Prem ClusterControl
В този раздел очакваме, че вече сте настроили или инсталирали потребителския си интерфейс на ClusterControl, който ще използваме за разгръщане на клъстер MySQL Replication с три възли с помощта на Percona Server.
Нека първо създадем клъстера, като разположим нова MySQL репликация, както е показано по-долу.
Обърнете внимание, че тук използвам Percona Server 5.7, за който по подразбиране настройката от ClusterControl работи ефективно.
След това дефинирайте името на хоста или IP на вашите възли,
В този момент очакваме, че вече сте настроили два възела Главна/подчинена репликация, която се хоства или изпълнява локално. Екранната снимка по-долу трябва да покаже как ще изглеждат вашите възли:
Настройте и инсталирайте ClusterControl и активирайте CMON HA на първия възел
От този предишен блог ClusterControl CMON HA за висока наличност на разпределена база данни сме предоставили накратко стъпките как да направите това. Нека да слезем отново и да направим стъпките, както е посочено, но за тази конкретна настройка за репликация Master/Slave.
Първото нещо, което трябва да направите, изберете един възел, който искате първо да бъде инсталиран ClusterControl (при тази настройка накрая инсталирам първо на възел 192.168.70.80) и изпълнете стъпките по-долу.
Първа стъпка
Инсталирайте ClusterControl
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as root
Обърнете внимание, че след като бъдете подканени, че е открит текущ екземпляр на mysql, трябва да оставите ClusterControl да използва съществуващия mysqld работещ, тъй като това е една от нашите цели тук за CMON HA и тази настройка да използва вече настроих MySQL.
Втора стъпка
Свържете CMON не само, за да разрешите чрез localhost, но и на конкретния IP адрес (тъй като ще активираме HA)
## edit /etc/default/CMON and modify the line just like below or add the line if it doesn't exist
RPC_BIND_ADDRESSES="127.0.0.1,192.168.70.80"
Трета стъпка
След това рестартирайте CMON,
service CMON restart
Четвърта стъпка
Инсталирайте инструментите за CLI на s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.sh
По време на тази инсталация инструментът s9s ще настрои администраторски потребител, за който можете да използвате, когато работите с командата s9s, точно както активирате CMON HA.
Стъпка пета
Активиране на CMON HA
$ s9s controller --enable-CMON-ha
Стъпка шеста
Накрая, променете /etc/my.cnf и добавете,
slave-skip-errors = 1062
под секцията [mysqld]. След като добавите, не забравяйте да рестартирате mysql като,
service mysql restart
или
systemctl restart mysql
В момента това е ограничението, пред което сме изправени с CMON HA, тъй като се опитва да вмъкне записи в регистрационния файл в подчинения, но това може да е добре засега.
Настройте, инсталирайте ClusterControl и активирайте CMON HA на втория възел
Прост като този за първия възел. Сега, на 2-ри възел (192.168.70.70), трябва да направим същите стъпки, но вместо това трябва да направим някои корекции в стъпките, за да направим тази HA възможна.
Първа стъпка
Копирайте конфигурацията във втория възел (192.168.70.70) от първия възел (192.168.70.80)
$ scp -r /etc/CMON* 192.168.70.70:/etc/
Втора стъпка
Във 2-ри възел редактирайте /etc/CMON.cnf и се уверете, че хостът е конфигуриран правилно. напр.
vi /etc/CMON.cnf
След това задайте параметър за име на хост като,
hostname=192.168.70.70
Трета стъпка
Инсталирайте ClusterControl,
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as root
Въпреки това, пропуснете инсталирането на CMON (или ClusterControl Controller), след като срещнете този ред,
=> An existing Controller installation detected!
=> A re-installation of the Controller will overwrite the /etc/CMON.cnf file
=> Install the Controller? (y/N):
Останалото, просто направете това, което сте направили на първия възел, като например настройване на името на хоста, използвайте съществуващия работещ екземпляр на mysqld, предоставяйки паролата за MySQL и паролата за вашия CMON, които трябва да бъдат и двете имат една и съща парола с първия възел.
Четвърта стъпка
Инсталирайте инструментите за CLI на s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.sh
Стъпка пета
Копирайте останалата конфигурация от 1-ви възел във 2-ри възел.
$ scp -r ~/.s9s/ 192.168.70.70:/root/
$ scp /etc/s9s.conf 192.168.70.70:/etc/
$ scp /var/www/html/clustercontrol/bootstrap.php 192.168.70.70:/var/www/html/clustercontrol/
Стъпка шеста
Инсталирайте пакета clustercontrol-controller,
За Ubuntu/Debian,
$ apt install -y clustercontrol-controller
За RHEL/CentOS/Fedora,
$ yum install -y clustercontrol-controller
Стъпка седма
Копирайте файла /etc/default/CMON и променете IP адреса за RPC адреса за свързване
scp /etc/default/CMON 192.168.70.70:/etc/default
RPC_BIND_ADDRESSES="127.0.0.1,10.0.0.103"
След това рестартирайте CMON, както следва,
service CMON restart
Стъпка осма
Променете /etc/my.cnf и добавете,
slave-skip-errors = 1062
под секцията [mysqld]. След като добавите, не забравяйте да рестартирате mysql като,
service mysql restart
или
systemctl restart mysql
В момента това е ограничението, пред което сме изправени с CMON HA, тъй като се опитва да вмъкне записи в регистрационния файл в подчинения, но това може да е добре засега.
Стъпка девет
Накрая проверете как изглеждат възлите CMON HA,
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
Total: 2 controller(s)
Разгръщане на вашия ClusterControl възел в облака
Както споменахме по-рано, идеалната настройка за комуникация е да се капсулират пакетите през VPN или други средства за защитен канал. Ако имате притеснения относно това как да направите това, проверете предишния ни блог Multi-DC PostgreSQL:Настройка на възел в режим на готовност на различно географско местоположение през VPN, за който сме се заели как можете да създадете проста настройка на VPN с помощта на OpenVPN.
Така че в този раздел очакваме, че вече сте настроили VPN връзката. Сега това, което ще направим, е да добавим подчинен, който трябва да разпределя наличността на CMON в Google Cloud Platform. За да направите това, просто отидете на Add Replication Slave, който можете да намерите, като щракнете върху иконата на клъстер близо до десния ъгъл. Вижте как изглежда по-долу:
Сега ето как ще свършим с:
Сега, тъй като имаме добавен нов подчинен, който се хоства под GCP, може да се наложи да проследите отново това, което направихме по-рано на 2-ри възел. Ще ви предам да следвате тези стъпки и да следвате инструкциите за това как направихме на 2-ри възел.
След като го направите правилно, ще получите следния резултат:
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
f 1.7.5.3735 system admins 10.142.0.39 10.142.0.39 9501 Accepting heartbeats.
където във възлите
- 192.168.70.80 - (node8) и се намира в моята on-prem
- 192.168.70.70 - (node7) и се намира в моята on-prem
- 10.142.0.39 - (gnode1) се хоства в GCP и в различен регион
CMON HA в действие
Моят колега Кшищоф Кшиазек вече предостави настройката за HA с помощта на HAProxy тук в този блог ClusterControl CMON HA за висока достъпност на разпределена база данни – част втора (настройка на GUI достъп).
За да следвате процедурата, посочена в блога, уверете се, че имате пакети xinetd и pathlib. Можете да инсталирате xinetd и pathlib, както следва,
$ sudo yum install -y xinetd python-pathlib.noarch
Уверете се също, че имате CMONhachk, дефиниран в /etc/services точно както по-долу:
[[email protected] ~]# grep 'CMONhachk' /etc/services
CMONhachk 9201/tcp
и осигурете промените и рестартирайте xinetd,
service xinetd restart
Ще пропусна процедурата Keepalived и HAProxy и очаквам, че сте настроили съответно. Едно нещо, което трябва да вземете предвид при тази настройка, е, че използването на Keepalived не може да бъде приложимо, ако разпръсквате VIP от on-prem към публичната облачна мрежа, тъй като те са напълно различна мрежа.
Сега нека видим как CMON HA реагира, ако възлите не работят. Както беше показано по-рано, възел 192.168.70.80 (node8) действаше като лидер точно както е показано по-долу:
Където базата данни на главния възел също показва, че node8 е главният от изглед на топология на ClusterControl . Нека се опитаме да убием node8 и да видим как протича CMON HA,
Както виждате, gnode1 (GCP възел) поема като лидер тъй като node8 намалява. Проверка на резултатите от HAProxy до следното,
и нашите възли ClusterControl показват, че node8 не работи, докато GCP възелът заема като господар,
Накрая, достъп до моя HAProxy възел, който работи на хост 192.168.10.100 на адрес 192.168.10.100. порт 81 показва следния потребителски интерфейс,
Заключение
Нашият ClusterControl CMON HA е от версия 1.7.2, но също така е предизвикателство за нас, тъй като има различни въпроси и предпочитания за това как да го внедрим, като например използването на MySQL репликация над Galera Cluster.
Нашата CMON HA все още не е зряла, но вече е готова да задоволи вашите нужди с висока наличност. Могат да бъдат приложими различни подходи, стига проверките ви да определят правилния възел, който работи и работи.
Насърчаваме ви да настроите и внедрите с помощта на CMON HA и ни уведомете колко добре отговаря на вашите нужди или ако проблемът продължава, моля, уведомете ни как да ви помогнем да посрещнете нуждите ви с висока наличност.