Вече разгледахме някои теории за конфигурирането на Always ON Availability Groups за базирани на Linux SQL сървъри. Настоящата статия ще се фокусира върху практиката.
Ще представим стъпка по стъпка процеса на конфигуриране на SQL Server Always ON Availability Groups между две синхронни реплики. Освен това ще подчертаем използването на реплика само за конфигурация за извършване на автоматично преминаване при отказ.
Преди да започнем, бих ви препоръчал да се обърнете към тази предишна статия и да опресните знанията си.
Проектната диаграма по-долу показва синхронната реплика с два възела и реплика само за конфигурация, които ни помагат да гарантираме автоматично преминаване при отказ и защита на данните.
Разгледахме този дизайн в по-горе споменатата статия, така че моля, вижте го за информация, преди да преминем към практически задачи.
Инсталирайте SQL Server на Ubuntu Systems
В горната проектна диаграма се споменават 3 Ubuntu системи – aoagvm1 ,aoagvm2 , и aoagvm3 с инсталираните екземпляри на SQL Server. Обърнете се към инструкциите за инсталиране на SQL Server на Ubuntu – примерът се отнася до SQL Server 2019 на Ubuntu 18.04 система. Можете да продължите и да инсталирате SQL Server 2019 на всичките 3 възела (уверете се, че сте инсталирали една и съща версия на компилация).
За да спестите разходи за лиценз, можете да инсталирате SQL Server Express изданието за третата реплика на възел. Този ще работи като реплика само за конфигурация, без да хоства никакви бази данни за наличност.
След като SQL Server е инсталиран на всичките 3 възела, можем да конфигурираме групата за наличност между тях.
Конфигуриране на групи за наличност между три възела
Преди да продължите, проверете вашата среда:
- Уверете се, че има комуникация между всичките 3 възела.
- Проверете и актуализирайте името на компютъра за всеки хост, като изпълните командата sudo vi /etc/hostname
- Актуализирайте хост файла с IP адрес и имена на възли за всеки възел. Можете да използвате командата sudo vi /etc/hosts за да направите това
- Уверете се, че всички екземпляри работят извън SQL Server 2017 CU1, ако не използвате SQL Server 2019
Сега нека започнем да конфигурираме SQL Server Always ON Availability Group между 3 възела. Трябва да активираме функцията за група за наличност на всичките 3 възела.
Изпълнете командата по-долу (обърнете внимание, че трябва да рестартирате услугата SQL Server след това действие):
--Enable Availability Group feature
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
--Restart SQL Server service
sudo systemctl restart mssql-server
Изпълних горната команда на основния възел. Трябва да се повтори за останалите два възела.
Резултатът е по-долу – въведете потребителското име и паролата, когато бъдете подканени.
[email protected]:~$ sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
SQL Server needs to be restarted to apply this setting. Please run
'systemctl restart mssql-server.service'.
[email protected]:~$ systemctl restart mssql-server
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to restart 'mssql-server.service'.
Authenticating as: Ubuntu (aoagvm1)
Password:
Следващата стъпка е да активирате Разширените събития винаги ВКЛЮЧЕНИ за всеки екземпляр на SQL Server. Въпреки че това е незадължителна стъпка, трябва да я активирате, за да отстраните всички проблеми, които могат да възникнат по-късно. Свържете се с екземпляра на SQL Server с помощта на SQLCMD и изпълнете командата по-долу:
--Connect to the local SQL Server instance using sqlcmd
sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
Go
ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
Go
Резултатът е по-долу:
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
2>GO
1>
След като активирате тази опция на основния възел на реплика, направете същото за останалите възли aoagvm2 и aoagvm3.
Инстанциите на SQL Server, работещи на Linux, използват сертификати за удостоверяване на комуникацията между огледалните крайни точки. Така че следващата опция е да създадете сертификата на първичната реплика aoagvm1 .
Първо създаваме главен ключ и сертификат. След това архивираме този сертификат във файл и защитаваме файла с частен ключ. Изпълнете следния T-SQL скрипт на основния възел на репликата:
--Connect to the local SQL Server instance using sqlcmd
sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
--Configure Certificates
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[email protected]$terKEY';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
WITH PRIVATE KEY (FILE = '/var/opt/mssql/data/dbm_certificate.pvk',ENCRYPTION BY PASSWORD = '[email protected]');
Резултатът:
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[email protected]$terKEY';
2>CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
3>GO
1>BACKUP CERTIFICATE dbm_certificate TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
2>WITH PRIVATE KEY (FILE = '/var/opt/mssql/data/dbm_certificate.pvk',ENCRYPTION BY PASSWORD = '[email protected]');
3>GO
1>
Основният възел на реплика вече има два нови файла. Единият е файлът на сертификата dbm_certificate.cer и файла с частен ключ dbm_certificate.pvk в /var/opt/mssql/data/ местоположение.
Копирайте горните два файла на едно и също място на останалите два възела (AOAGVM2 и AOAGVM3), които ще участват в конфигурацията на групата за наличност. Можете да използвате командата SCP или която и да е помощна програма на трета страна, за да копирате тези два файла на целевия сървър.
След като файловете бъдат копирани в останалите два възела, ще зададем разрешения на mssql потребител за достъп до тези файлове на всичките 3 възела. За това изпълнете командата по-долу и след това я изпълнете за третия възел aoagvm3 също така:
--Copy files to aoagvm2 node
cd /var/opt/mssql/data
scp dbm_certificate.* [email protected]:var/opt/mssql/data/
--Grant permission to user mssql to access both newly created files
cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*
Ще създадем главния ключ и файловете на сертификата с помощта на горните два копирани файла на останалите два възела aoagvm2 и aoagvm3 . Изпълнете командата по-долу на тези два възела, за да създадете главния ключ :
--Create master key and certificate on remaining two nodes
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[email protected]$terKEY';
CREATE CERTIFICATE dbm_certificate
FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
WITH PRIVATE KEY (FILE = '/var/opt/mssql/data/dbm_certificate.pvk', DECRYPTION BY PASSWORD = '[email protected]');
Изпълних горната команда на втория възел aoagvm2 за да създадете главния ключ исертификата . Разгледайте изхода за изпълнение. Уверете се, че използвате същите пароли, както при създаване и архивиране на сертификата и главния ключ.
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>CREATE MASTER KEY ENCRYPTION BY PASSWORD = '[email protected]$terKEY';
2>CREATE CERTIFICATE dbm_certificate
3>FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
4>WITH PRIVATE KEY (FILE = '/var/opt/mssql/data/dbm_certificate.pvk', DECRYPTION BY PASSWORD = '[email protected]');
5>GO
1>
Изпълнете горната команда на AOAGVM3 възел също.
Сега конфигурираме огледални крайни точки на база данни – по-рано създадохме сертификати за тях. Огледалната крайна точка с име hadr_endpoint трябва да бъде на всичките 3 възела според съответния им тип роля.
Тъй като базите данни за наличност се хостват само на 2 възела aoagvm1 и aoagvm2, ние ще изпълним оператора по-долу само на тези възли. Третият възел ще действа като свидетел – така че просто ще променим РОЛЯ досвидетели в скрипта по-долу и след това стартирайте T-SQL към третия възел aoagvm3 . Скриптът е:
--Configure database mirroring endpoint Hadr_endpoint on nodes aoagvm1 and aoagvm2
CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE = ALL,
AUTHENTICATION = CERTIFICATE dbm_certificate,
ENCRYPTION = REQUIRED ALGORITHM AES);
--Start the newly created endpoint
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
Ето изхода на горната команда на първичния възел на реплика. Свързах се с sqlcmd и го изпълни. Уверете се, че сте направили същото на 2-ра реплика възел aoagvm2 също.
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>CREATE ENDPOINT [Hadr_endpoint]
2>AS TCP (LISTENER_PORT = 5022)
3>FOR DATABASE_MIRRORING (ROLE = ALL, AUTHENTICATION = CERTIFICATE dbm_certificate, ENCRYPTION = REQUIRED ALGORITHM AES);
4>Go
1>ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
2>Go
1>
След като изпълните горния T-SQL скрипт на първите 2 възела, трябва да го модифицираме за третия възел – променете ROLE на WITNESS.
Изпълнете скрипта по-долу, за да създадете крайната точка за огледално отразяване на базата данни на наблюдателния възел AOAGVM3 . Ако искате да хоствате бази данни за наличност там, изпълнете горната команда и на възела 3 реплика. Но се уверете, че сте инсталирали правилното издание на SQL Server, за да постигнете тази възможност.
Ако сте инсталирали изданието SQL Server Express на възел 3, за да приложите само за конфигуриране реплика , можете да конфигурирате само РОЛЯ като свидетел за този възел:
--Connect to the local SQL Server instance using sqlcmd
sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
----Configure database mirroring endpoint Hadr_endpoint on 3rd node aoagvm3
CREATE ENDPOINT [Hadr_endpoint]
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE = WITNESS, AUTHENTICATION = CERTIFICATE dbm_certificate, ENCRYPTION = REQUIRED ALGORITHM AES);
--Start the newly created endpoint on aoagvm3
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
Сега трябва да създадем групата за наличност с име ag1 .
Свържете се с екземпляра на SQL Server с помощта на sqlcmd помощна програма и изпълнете командата по-долу на първичния възел на реплика aoagvm1 :
--Connect to the local SQL Server instance using sqlcmd hosted on primary replica node aoagvm1
sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
--Create availability group ag1
CREATE AVAILABILITY GROUP [ag1]
WITH (CLUSTER_TYPE = EXTERNAL)
FOR REPLICA ON
N'aoagvm1’ WITH (ENDPOINT_URL = N'tcp://aoagvm1:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC),
N'aoagvm2' WITH (ENDPOINT_URL = N'tcp://aoagvm2:5022',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = EXTERNAL,
SEEDING_MODE = AUTOMATIC),
N'aoagvm3' WITH (ENDPOINT_URL = N'tcp://aoagvm3:5022',
AVAILABILITY_MODE = CONFIGURATION_ONLY);
--Assign required permission
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
Горният скрипт конфигурира репликите на групата наличност със следните конфигурационни параметри (току-що ги използвахме в T-SQL скрипта):
- CLUSTER_TYPE =ВЪНШЕН защото конфигурираме групата за наличност на базирани на Linux инсталации на SQL Server
- SEEDING_MODE =АВТОМАТИЧЕН кара SQL Server автоматично да създава база данни за всяка вторична реплика. Базите данни за наличност няма да се създават на реплика само за конфигурация
- FAILOVER_MODE =ВЪНШЕН както за първични, така и за вторични реплики. това означава, че репликата взаимодейства с външен мениджър на клъстерни ресурси, като Pacemaker
- AVAILABILITY_MODE =SYNCHRONOUS_COMMIT за първични и вторични реплики за автоматично преминаване при отказ
- AVAILABILITY_MODE =CONFIGURATION_ONLY за 3-та реплика, която работи като реплика само за конфигурация
Също така трябва да създадем вход за Pacemaker на всички екземпляри на SQL Server. Този потребител трябва да получи ALTER , КОНТРОЛ , и ПРЕГЛЕД ДЕФИНИЦИЯ разрешения за групата наличност за всички реплики. За да предоставите разрешения, изпълнете незабавно T-SQL скрипта по-долу на всичките 3 реплика възела. Първо, ще създадем вход за Pacemaker. След това ще присвоим горните разрешения на това влизане.
--Create pacemaker login on each SQL Server instance. Run below commands on all 3 SQL Server instances
CREATE LOGIN pacemaker WITH PASSWORD = '[email protected]@12'
--Grant permission to pacemaker login on newly created availability group. Run it on all 3 SQL Server instances
GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO pacemaker
GRANT VIEW SERVER STATE TO pacemaker
След като зададем подходящи разрешения за вход на Pacemaker за всичките 3 реплики, ние изпълняваме следните T-SQL скриптове, за да се присъединим към вторичните реплики aoagvm2 и aoagvm3 към новосъздадената група за наличност ag1 . Изпълнете командите по-долу на вторичните реплики aoagvm2 и aoagvm3 .
--Execute below commands on aoagvm2 and aoagvm3 to join availability group ag1
ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
По-долу е изходът от горните изпълнения на възел aoagvm2 . Не забравяйте да го стартирате на aoagvm3 възел също.
[email protected]:~$ sqlcmd -S localhost -U SA -P 'C0de!n$!ght$'
1>ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
2>Go
1>ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;
2>Go
1>
Така конфигурирахме групата за наличност. Сега трябва да добавим потребител или тестова база данни към тази група за наличност. Ако вече сте създали потребителска база данни на репликата на първичния възел, просто стартирайте пълно архивиране и след това оставете автоматичното засяване да я възстанови на вторичния възел.
По този начин изпълнете командата по-долу:
--Run a full backup of test database or user database hosted on primary replica aoagvm1
BACKUP DATABASE [Test] TO DISK = N'/var/opt/mssql/data/Test_15June.bak';
Нека добавим тази база данни Тест към групата за наличностag1 . Изпълнете следния T-SQL оператор на основния възел aoagvm1 . Можете да използвате sqlcmd помощна програма за изпълнение на T-SQL изрази.
--Add user database or test database to the availability group ag1
ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [Test];
Можете да проверите потребителската база данни или тестовата база данни, която сте добавили към групата за наличност, като разгледате вторичния екземпляр на SQL Server, независимо дали е създаден на вторични реплики или не. Можете да използвате SQL Server Management Studio или да изпълните обикновен T-SQL оператор, за да извлечете подробностите за тази база данни.
--Verify test database is created on a secondary replica or not. Run it on secondary replica aoagvm2.
SELECT * FROM sys.databases WHERE name = 'Test';
GO
Ще получите Тест база данни, създадена на вторичната реплика.
С горната стъпка групата за наличност AlwaysOn е конфигурирана между трите възела. Тези възли обаче все още не са групирани. Следващата ни стъпка е да инсталираме пейсмейкъра струпват върху тях. След това ще добавим групата наличност ag1 като ресурс за този клъстер.
Клъстерна конфигурация на PACEMAKER между три възела
Така че ще използваме външен мениджър на клъстерни ресурси PACEMAKER между всичките 3 възела за поддръжка на клъстер. Нека започнем с активиране на портовете на защитната стена между всичките 3 възела.
Отворете портовете на защитната стена, като използвате командата по-долу:
--Run the below commands on all 3 nodes to open Firewall Ports
sudo ufw allow 2224/tcp
sudo ufw allow 3121/tcp
sudo ufw allow 21064/tcp
sudo ufw allow 5405/udp
sudo ufw allow 1433/tcp
sudo ufw allow 5022/tcp
sudo ufw reload
--If you don't want to open specific firewall ports then alternatively you can disable the firewall on all 3 nodes by running the below command (THIS IS ALTERNATE & OPTIONAL APPROACH)
sudo ufw disable
Вижте изхода – този е от основната реплика AOAGVM1 . Трябва да изпълните горните команди и на трите възела, един по един. Резултатът трябва да е подобен.
[email protected]:~$ sudo ufw allow 2224/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 3121/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 21064/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 5405/udp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 1433/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw allow 5022/tcp
Rules updated
Rules updated (v6)
[email protected]:~$ sudo ufw reload
Firewall not enabled (skipping reload)
Инсталирайте пейсмейкър икоросинхрони пакети на всичките 3 възела. Изпълнете командата по-долу на всеки възел – тя ще конфигурира Пейсмейкър ,коросинхрон , иагент за ограждане .
--Install Pacemaker packages on all 3 nodes aoagvm1, aoagvm2 and aoagvm3 by running the below command
sudo apt-get install pacemaker pcs fence-agents resource-agents
Резултатът е огромен – почти 20 страници. Копирах първите и последните няколко реда, за да го илюстрирам (можете да видите всички инсталирани пакети):
[email protected]:~$ sudo apt-get install pacemaker pcs fence-agents resource-agents
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
cluster-glue corosync fonts-dejavu-core fonts-lato fonts-liberation ibverbs-providers javascript-common libcfg6 libcib4 libcmap4 libcorosync-common4 libcpg4
libcrmcluster4 libcrmcommon3 libcrmservice3 libdbus-glib-1-2 libesmtp6 libibverbs1 libjs-jquery liblrm2 liblrmd1 libnet-telnet-perl libnet1 libnl-3-200
libnl-route-3-200 libnspr4 libnss3 libopenhpi3 libopenipmi0 libpe-rules2 libpe-status10 libpengine10 libpils2 libplumb2 libplumbgpl2 libqb0 libquorum5 librdmacm1
libruby2.5 libsensors4 libsgutils2-2 libsnmp-base libsnmp30 libstatgrab10 libstonith1 libstonithd2 libtimedate-perl libtotem-pg5 libtransitioner2 libvotequorum8
libxml2-utils openhpid pacemaker-cli-utils pacemaker-common pacemaker-resource-agents python-pexpect python-ptyprocess python-pycurl python3-bs4 python3-html5lib
python3-lxml python3-pycurl python3-webencodings rake ruby ruby-activesupport ruby-atomic ruby-backports ruby-did-you-mean ruby-ethon ruby-ffi ruby-highline
ruby-i18n ruby-json ruby-mime-types ruby-mime-types-data ruby-minitest ruby-multi-json ruby-net-telnet ruby-oj ruby-open4 ruby-power-assert ruby-rack
ruby-rack-protection ruby-rack-test ruby-rpam-ruby19 ruby-sinatra ruby-sinatra-contrib ruby-test-unit ruby-thread-safe ruby-tilt ruby-tzinfo ruby2.5
rubygems-integration sg3-utils snmp unzip xsltproc zip
Suggested packages:
ipmitool python-requests python-suds apache2 | lighttpd | httpd lm-sensors snmp-mibs-downloader python-pexpect-doc libcurl4-gnutls-dev python-pycurl-dbg
python-pycurl-doc python3-genshi python3-lxml-dbg python-lxml-doc python3-pycurl-dbg ri ruby-dev bundler
The following NEW packages will be installed:
cluster-glue corosync fence-agents fonts-dejavu-core fonts-lato fonts-liberation ibverbs-providers javascript-common libcfg6 libcib4 libcmap4 libcorosync-common4
libcpg4 libcrmcluster4 libcrmcommon3 libcrmservice3 libdbus-glib-1-2 libesmtp6 libibverbs1 libjs-jquery liblrm2 liblrmd1 libnet-telnet-perl libnet1 libnl-3-200
libnl-route-3-200 libnspr4 libnss3 libopenhpi3 libopenipmi0 libpe-rules2 libpe-status10 libpengine10 libpils2 libplumb2 libplumbgpl2 libqb0 libquorum5 librdmacm1
libruby2.5 libsensors4 libsgutils2-2 libsnmp-base libsnmp30 libstatgrab10 libstonith1 libstonithd2 libtimedate-perl libtotem-pg5 libtransitioner2 libvotequorum8
libxml2-utils openhpid pacemaker pacemaker-cli-utils pacemaker-common pacemaker-resource-agents pcs python-pexpect python-ptyprocess python-pycurl python3-bs4
python3-html5lib python3-lxml python3-pycurl python3-webencodings rake resource-agents ruby ruby-activesupport ruby-atomic ruby-backports ruby-did-you-mean
ruby-ethon ruby-ffi ruby-highline ruby-i18n ruby-json ruby-mime-types ruby-mime-types-data ruby-minitest ruby-multi-json ruby-net-telnet ruby-oj ruby-open4
ruby-power-assert ruby-rack ruby-rack-protection ruby-rack-test ruby-rpam-ruby19 ruby-sinatra ruby-sinatra-contrib ruby-test-unit ruby-thread-safe ruby-tilt
ruby-tzinfo ruby2.5 rubygems-integration sg3-utils snmp unzip xsltproc zip
0 upgraded, 103 newly installed, 0 to remove and 2 not upgraded.
Need to get 19.6 MB of archives.
After this operation, 86.0 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://azure.archive.ubuntu.com/ubuntu bionic/main amd64 fonts-lato all 2.0-2 [2698 kB]
Get:2 http://azure.archive.ubuntu.com/ubuntu bionic/main amd64 libdbus-glib-1-2 amd64 0.110-2 [58.3 kB]
…………
--------
Веднъж напейсмейкъра инсталацията на клъстера е завършена, хаклустерът потребителят ще бъде попълнен автоматично, докато изпълнявате командата по-долу:
[email protected]:~$ cat /etc/passwd|grep hacluster
hacluster:x:111:115::/var/lib/pacemaker:/usr/sbin/nologin
Сега можем да зададем паролата за потребителя по подразбиране, създаден по време на инсталирането на пейсмейкъра и Corosync пакети. Уверете се, че използвате една и съща парола на всичките 3 възела. Използвайте командата по-долу:
--Set default user password on all 3 nodes
sudo passwd hacluster
Въведете паролата, когато бъдете подканени:
[email protected]:~$ sudo passwd hacluster
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Следващата стъпка е да активирате и стартирате pcsd сервиз ипейсмейкър на всичките 3 възела. Позволява на всички 3 възела да се присъединят към клъстера след рестартиране. Изпълнете командата по-долу на всичките 3 възела, за да изпълните тази стъпка:
--Enable and start pcsd service and pacemaker
sudo systemctl enable pcsd
sudo systemctl start pcsd
sudo systemctl enable pacemaker
Вижте изпълнението на първичната реплика aoagvm1 . Уверете се, че сте го стартирали и на останалите два възела.
--Enable pcsd service
[email protected]:~$ sudo systemctl enable pcsd
Synchronizing state of pcsd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable pcsd
--Start pcsd service
[email protected]:~$ sudo systemctl start pcsd
--Enable Pacemaker
[email protected]:~$ sudo systemctl enable pacemaker
Synchronizing state of pacemaker.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable pacemaker
Конфигурирахме пейсмейкъра пакети. Сега създаваме клъстер.
Първо, уверете се, че нямате предварително конфигурирани клъстери на тези системи. Можете да унищожите всички съществуващи конфигурации на клъстер от всички възли, като изпълните командите по-долу. Имайте предвид, че премахването на конфигурация на клъстер ще спре всички клъстерни услуги и ще деактивира пейсмейкъра услуга – трябва да бъде активирана отново.
--Destroy previously configured clusters to clean the systems
sudo pcs cluster destroy
--Reenable Pacemaker
sudo systemctl enable pacemaker
По-долу е изходът от първичния реплика възел aoagvm1 .
--Destroy previously configured clusters to clean the systems
[email protected]:~$ sudo pcs cluster destroy
Shutting down pacemaker/corosync services...
Killing any remaining services...
Removing all cluster configuration files...
--Reenable Pacemaker
[email protected]:~$ sudo systemctl enable pacemaker
Synchronizing state of pacemaker.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable pacemaker
След това създаваме клъстер с 3 възела между всичките 3 възела от първичната реплика aoagvm1 . Важно :Изпълнете командите по-долу само от основния си възел !
--Create cluster. Modify below command with your node names, hacluster password and clustername
sudo pcs cluster auth <node1> <node2> <node3> -u hacluster -p <password for hacluster>
sudo pcs cluster setup --name <clusterName> <node1> <node2...> <node3>
sudo pcs cluster start --all
sudo pcs cluster enable --all
Вижте изхода на първичния реплика възел:
[email protected]:~$ sudo pcs cluster auth aoagvm1 aoagvm2 aoagvm3 -u hacluster -p hacluster
aoagvm1: Authorized
aoagvm2: Authorized
aoagvm3: Authorized
[email protected]:~$ sudo pcs cluster setup --name aoagvmcluster aoagvm1 aoagvm2 aoagvm3
Destroying cluster on nodes: aoagvm1, aoagvm2, aoagvm3...
aoagvm1: Stopping Cluster (pacemaker)...
aoagvm2: Stopping Cluster (pacemaker)...
aoagvm3: Stopping Cluster (pacemaker)...
aoagvm1: Successfully destroyed cluster
aoagvm2: Successfully destroyed cluster
aoagvm3: Successfully destroyed cluster
Sending 'pacemaker_remote authkey' to 'aoagvm1', 'aoagvm2', 'aoagvm3'
aoagvm1: successful distribution of the file 'pacemaker_remote authkey'
aoagvm2: successful distribution of the file 'pacemaker_remote authkey'
aoagvm3: successful distribution of the file 'pacemaker_remote authkey'
Sending cluster config files to the nodes...
aoagvm1: Succeeded
aoagvm2: Succeeded
aoagvm3: Succeeded
Synchronizing pcsd certificates on nodes aoagvm1, aoagvm2, aoagvm3...
aoagvm1: Success
aoagvm2: Success
aoagvm3: Success
Restarting pcsd on the nodes to reload the certificates...
aoagvm1: Success
aoagvm2: Success
aoagvm3: Success
[email protected]:~$ sudo pcs cluster start --all
aoagvm1: Starting Cluster...
aoagvm2: Starting Cluster...
aoagvm3: Starting Cluster...
[email protected]:~$ sudo pcs cluster enable --all
aoagvm1: Cluster Enabled
aoagvm2: Cluster Enabled
aoagvm3: Cluster Enabled
Ограда е една от основните конфигурации при използване на клъстера PACEMAKER в производството. Трябва да конфигурирате ограда за вашия клъстер, за да сте сигурни, че няма да има повреда на данните в случай на прекъсване .
Има два вида изпълнение на ограда:
- На ниво ресурс – гарантира, че възелът не може да използва един или повече ресурси.
- Ниво на възел – гарантира, че възелът изобщо не изпълнява никакви ресурси.
Обикновено използваме STONITH като конфигурация на ограда – оградата на ниво възел за ПЕЙСМЕЙКЪР .
КогатоПЕЙСМЕЙКЪР не може да определи състоянието на възел или ресурс на възел, фехтирането привежда клъстера отново в известно състояние. За да постигне това, ПЕЙСМЕЙКЪР изисква от нас да активираме STONITH , което означава Shoot The Other Node In The Head .
Няма да се фокусираме върху конфигурацията на оградата в тази статия, тъй като конфигурацията на ограда на ниво възел зависи до голяма степен от индивидуалната среда. За нашия сценарий ще го деактивираме, като изпълним командата по-долу:
--Disable fencing (STONITH)
sudo pcs property set stonith-enabled=false
Ако обаче планирате да използвате пейсмейкър в производствена среда трябва да планирате реализацията на STONITH в зависимост от вашата среда и да я поддържате активирана.
След това ще зададем някои основни свойства на клъстера:cluster-recheck-interval, start-failure-is-fatal, и време за изчакване на отказ .
Съгласно MSDN, ако време изчакване на отказ е настроен на 60 секунди и интервал за повторна проверка на клъстера е настроен на 120 секунди, рестартирането се опитва на интервал, по-голям от 60 секунди, но по-малък от 120 секунди. Microsoft препоръчва да зададете стойност за cluster-recheck-interval по-голяма от стойността на failure-timeout . Друга настройка неуспешно стартиране е фатална трябва да се зададе като true . В противен случай клъстерът няма да инициира преминаването на първична реплика към съответната вторична реплика, ако възникнат постоянни прекъсвания.
Изпълнете следните команди, за да конфигурирате всичките 3 важни свойства на клъстера:
--Set cluster property cluster-recheck-interval to 2 minutes
sudo pcs property set cluster-recheck-interval=2min
--Set start-failure-is-fatal to True
sudo pcs property set start-failure-is-fatal=true
--Set failure-timeout to 60 seconds. Ag1 is the name of the availability group. Change this name with your availability group name.
pcs resource update ag1 meta failure-timeout=60s
Интегрирайте групата за наличност към групата на клъстерите на пейсмейкъра
Тук нашата цел е да опишем процеса на интегриране на новосъздадената група за наличност ag1 на новосъздадения пейсмейкър клъстерна група.
Първо, ще инсталираме ресурсния агент на SQL Server за интеграция с Пейсмейкър на всичките 3 възела:
--Install SQL Server Resource Agent on all 3 nodes
sudo apt-get install mssql-server-ha
Изпълних горната команда на всичките 3 възела. Вижте изхода по-долу (взет от aoagvm1 ):
--Install SQL Server resource agent for integration with Pacemaker
[email protected]:~$ sudo apt-get install mssql-server-ha
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
mssql-server-ha
0 upgraded, 1 newly installed, 0 to remove, and 2 not upgraded.
Need to get 1486 kB of archives.
After this operation, 9151 kB of additional disk space will be used.
Get:1 https://packages.microsoft.com/ubuntu/16.04/mssql-server-preview xenial/main amd64 mssql-server-ha amd64 15.0.1600.8-1 [1486 kB]
Fetched 1486 kB in 0s (4187 kB/s)
Selecting previously unselected package mssql-server-ha.
(Reading database ... 90430 files and directories currently installed.)
Preparing to unpack .../mssql-server-ha_15.0.1600.8-1_amd64.deb ...
Unpacking mssql-server-ha (15.0.1600.8-1) ...
Setting up mssql-server-ha (15.0.1600.8-1) ...
Повторете горните стъпки за останалите 2 възела.
Вече създадохме пейсмейкъра влезте във всички екземпляри на SQL Server, хоствани на 3 възела, когато сме конфигурирали групата за наличност ag1 . Сега присвояваме ролята на системния администратор на всички 3 екземпляра на SQL Server. Можете да се свържете с помощта на sqlcmd for running this T-SQL command. If you have not created the Pacemaker login, you can run the below command to do it.
--Create a pacemaker login if you missed creating it in the above section.
USE master
Go
CREATE LOGIN pacemaker WITH PASSWORD = '[email protected]@12'
Go
--Assign sysadmin role to pacemaker login on all 3 nodes. Run this T-SQL on all 3 SQL Server instances.
ALTER SERVER ROLE [sysadmin] ADD MEMBER [pacemaker]
We must save the above SQL Server Pacemaker login and its credentials on all 3 nodes. Run the below command there:
--Save pacemaker login credentials on all 3 nodes by executing below commands on each node
echo 'pacemaker' >> ~/pacemaker-passwd
echo '[email protected]@12' >> ~/pacemaker-passwd
sudo mv ~/pacemaker-passwd /var/opt/mssql/secrets/passwd
sudo chown root:root /var/opt/mssql/secrets/passwd
sudo chmod 400 /var/opt/mssql/secrets/passwd
We will create the Availability Group Resource as master/subordinate .
We are using the pcs resource create command to create the Availability Group resource and set its properties. The following command will create the ocf:mssql:ag resource for the Availability Group ag1 .
The Pacemaker resource agent automatically sets the value of REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT on the Availability Group based on the Availability Group’s configuration during the creation of the Availability Group resource.
Execute the below command:
--Create availability group resource ocf:mssql:ag
sudo pcs resource create ag_cluster ocf:mssql:ag ag_name=ag1 meta failure-timeout=30s --master meta notify=true
Next, we create a virtual IP resource in Pacemaker . Ensure you have the unused private IP address from your network . Replace the IP value with your virtual IP address. This IP will point to the primary replica and you can use it to make databases connections with active nodes.
The command is below:
--Configure virtual IP resource
sudo pcs resource create virtualip ocf:heartbeat:IPaddr2 ip=10.50.0.7
We are adding the colocation constraint and ordering constraint to the Pacemaker cluster configuration . These constraints help the virtual IP resource to make decisions on resources, e.g., where they should run.
Constraints have some scores, and Pacemaker uses these scores to make decisions. Scores are calculated per resource. The cluster resource manager chooses the node with the highest score for a particular resource.
The colocation constraint has an implicit ordering constraint . We need to add an ordering constraint to prevent the IP address from temporarily pointing to the node with the pre-failover secondary . Ordering constraint ensures the cluster comes online in a particular sequential manner.
Run the below commands to add colocation constraint and ordering constraint to the cluster.
--Add colocation constraint
sudo pcs constraint colocation add virtualip ag_cluster-master INFINITY with-rsc-role=Master
--Add ordering constraint
sudo pcs constraint order promote ag_cluster-master then start virtualip
Hence, Two-Node Synchronous Replicas (aoagvm1 &aoagvm2) and a Configuration-Only Replica (aoagvm3) on PACEMAKER Cluster between 3-Node Ubuntu Systems has been completed.
We can test the configuration to validate the automatic failover. Run the below command to check the status of the Pacemaker cluster. The command also initiates the Availability Group failover.
Remember, once you couple your Availability Group with the PACEMAKER cluster, you cannot use T-SQL statements to initiate the Availability Group failovers. You can also shut down the primary replica to initiate the automatic failover.
The command is the following:
--Validate the PACEMAKER cluster configuration
sudo pcs status
--Initiate availability group failover to verify AOAG configuration
sudo pcs resource move ag_cluster-master aoagvm2 –master
Заключение
This article was meant to help you understand the configuration of the Two-Node Synchronous Replicas and a Configuration-Only Replica on PACEMAKER Cluster. We hope that you got useful information that will help you in your workflow.
Always plan all steps carefully and do proper testing in a lower life cycle before deploying to your production environment.
We’ll be glad to hear your thoughts about this topic. Feel free to leave your feedback in a comment section.
