LinuxベースのSQLServerのAlwaysON可用性グループの構成に関する理論についてはすでに説明しました。現在の記事は練習に焦点を当てます。
2つの同期レプリカ間でSQLServerのAlwaysON可用性グループを構成する手順を段階的に説明します。また、自動フェイルオーバーを実行するための構成のみのレプリカの使用法についても説明します。
始める前に、その前の記事を参照して知識を更新することをお勧めします。
次の設計図は、自動フェイルオーバーとデータ保護を確保するのに役立つ2ノードの同期レプリカと構成のみのレプリカを示しています。
この設計については前述の記事で説明したので、実際のタスクに進む前に、情報を参照してください。
UbuntuシステムにSQLServerをインストールする
上記の設計図は、3つのUbuntuシステム– aoagvm1 、 aoagvm2 、および aoagvm3 SQLServerインスタンスがインストールされている。 UbuntuにSQLServerをインストールする手順を参照してください。この例は、Ubuntu18.04システム上のSQLServer2019に関連しています。先に進んで、3つのノードすべてにSQL Server 2019をインストールできます（必ず同じビルドバージョンをインストールしてください）。
ライセンスコストを節約するために、3番目のノードのレプリカにSQLServerExpressエディションをインストールできます。これは、可用性データベースをホストせずに、構成のみのレプリカとして機能します。
SQL Serverが3つのノードすべてにインストールされると、それらの間に可用性グループを構成できます。
3つのノード間で可用性グループを構成する
先に進む前に、環境を検証してください：
- 3つのノードすべての間に通信があることを確認してください。
- コマンドsudovi / etc / hostname を実行して、各ホストのコンピューター名を確認および更新します。
- 各ノードのIPアドレスとノード名でホストファイルを更新します。コマンドsudovi / etc / hostsを使用できます。 これを行うには
- SQL Server 2019を使用していない場合は、SQL Server2017CU1以降ですべてのインスタンスが実行されていることを確認してください
それでは、3ノード間でSQLServerのAlwaysON可用性グループの構成を開始しましょう。 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
プライマリノードで上記のコマンドを実行しました。残りの2つのノードに対して繰り返す必要があります。
出力は以下のとおりです–プロンプトが表示されたらいつでもユーザー名とパスワードを入力してください。
[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:
次のステップは、常にオンの拡張イベントを有効にすることです。 SQLServerインスタンスごとに。これはオプションの手順ですが、後で発生する可能性のある問題のトラブルシューティングを行うために有効にする必要があります。 SQLCMDを使用してSQLServerインスタンスに接続します 次のコマンドを実行します：
--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ノードでも同じことを行います。
Linuxで実行されているSQLServerインスタンスは、証明書を使用してミラーリングエンドポイント間の通信を認証します。したがって、次のオプションは、プライマリレプリカ 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>
プライマリレプリカノードに2つの新しいファイルが追加されました。 1つは、証明書ファイル dbm_certificate.cerです。 および秘密鍵ファイルdbm_certificate.pvk / var / opt / mssql / data / 場所。
上記の2つのファイルを、可用性グループ構成に参加する残りの2つのノード（AOAGVM2およびAOAGVM3）の同じ場所にコピーします。 SCPコマンドまたはサードパーティのユーティリティを使用して、これら2つのファイルをターゲットサーバーにコピーできます。
ファイルが残りの2つのノードにコピーされたら、 mssqlにアクセス許可を割り当てます。 ユーザーは、3つのノードすべてでこれらのファイルにアクセスします。そのためには、以下のコマンドを実行してから、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.*
残りの2つのノードに上記の2つのコピーされたファイルを使用して、マスターキーと証明書ファイルを作成します aoagvm2 およびaoagvm3 。これらの2つのノードで以下のコマンドを実行して、マスターキーを作成します。 ：
--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]');
2番目のノード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、 これらのノードでのみ、以下のステートメントを実行します。 3番目のノードは証人のように機能するため、 ROLEを変更するだけです。 目撃者へ 以下のスクリプトで、3番目のノード aoagvm3に対してT-SQLを実行します。 。スクリプトは次のとおりです。
--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つのノードで実行したら、3番目のノード用に変更する必要があります。ROLEをWITNESSに変更します。
以下のスクリプトを実行して、監視ノード AOAGVM3にデータベースミラーリングエンドポイントを作成します。 。そこで可用性データベースをホストする場合は、3つのレプリカノードでも上記のコマンドを実行します。ただし、この機能を実現するには、適切なエディションのSQLServerがインストールされていることを確認してください。
SQL Server Expressエディションを3ノードにインストールして、構成のみを実装した場合 レプリカ 、構成できるのは ROLE のみです 証人として このノードの場合：
--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という名前の可用性グループを作成する必要があります。 。
sqlcmdを使用してSQLServerインスタンスに接続します ユーティリティを使用して、プライマリレプリカノード 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 =EXTERNAL LinuxベースのSQLServerインストールで可用性グループを構成しているため
- SEEDING_MODE =AUTOMATIC SQLServerは各セカンダリレプリカにデータベースを自動的に作成します。可用性データベースは、構成のみのレプリカでは作成されません
- FAILOVER_MODE =EXTERNAL プライマリレプリカとセカンダリレプリカの両方。これは、レプリカがPacemakerなどの外部クラスターリソースマネージャーと相互作用することを意味します
- AVAILABILITY_MODE =SYNCHRONOUS_COMMIT 自動フェイルオーバー用のプライマリレプリカとセカンダリレプリカの場合
- AVAILABILITY_MODE =CONFIGURATION_ONLY 構成のみのレプリカとして機能する3番目のレプリカの場合
また、すべてのSQLServerインスタンスでPacemakerログインを作成する必要があります。このユーザーにはALTERを割り当てる必要があります 、 CONTROL 、および VIEW 定義 すべてのレプリカの可用性グループに対する権限。アクセス許可を付与するには、3つのレプリカノードすべてで以下のT-SQLスクリプトをすぐに実行します。まず、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
3つのレプリカすべてのPacemakerログインに適切なアクセス許可を割り当てた後、以下の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 。プライマリノードaoagvm1で以下のT-SQLステートメントを実行します 。 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可用性グループが3つのノードすべての間に構成されました。ただし、これらのノードはまだクラスター化されていません。次のステップは、ペースメーカーをインストールすることです。 それらのクラスター。次に、可用性グループ ag1を追加します そのクラスターへのリソースとして。
3つのノード間の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からのものです 。上記のコマンドは、3つのノードすべてで1つずつ実行する必要があります。出力は似ているはずです。
[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)
ペースメーカーをインストールします およびcorosync 3つのノードすべてのパッケージ。各ノードで以下のコマンドを実行します– Pacemakerを構成します 、 corosync 、およびフェンシングエージェント 。
--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]
…………
--------
かつてペースメーカー クラスタのインストールが完了しました。hacluster 以下のコマンドを実行すると、ユーザーに自動的にデータが入力されます：
[email protected]:~$ cat /etc/passwd|grep hacluster
hacluster:x:111:115::/var/lib/pacemaker:/usr/sbin/nologin
これで、 Pacemakerのインストール中に作成されたデフォルトユーザーのパスワードを設定できます。 および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 。残りの2つのノードでも実行してください。
--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
ペースメーカーを構成しました パッケージ。次に、クラスターを作成します。
まず、これらのシステムに以前に構成されたクラスターがないことを確認します。以下のコマンドを実行することにより、すべてのノードから既存のクラスター構成を破棄できます。クラスタ構成を削除すると、すべてのクラスタサービスが停止し、 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
次に、プライマリレプリカ aoagvm1の3つのノードすべての間に3ノードクラスターを作成します。 。 重要 ：以下のコマンドをプライマリノードからのみ実行します ！
--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クラスターを使用する際の重要な構成の1つです。 クラスターのフェンシングを構成して、停止が発生した場合にデータが破損しないようにする必要があります。 。
フェンシングの実装には2つのタイプがあります：
- リソースレベル –ノードが1つ以上のリソースを使用できないようにします。
- ノードレベル –ノードがリソースをまったく実行しないようにします。
通常、 STONITHを使用します フェンシング構成として– PACEMAKERのノードレベルのフェンシング 。
ペースメーカーの場合 ノードまたはノード上のリソースの状態を判別できない場合、フェンシングはクラスターを既知の状態に戻します。これを実現するために、PACEMAKERでは STONITHを有効にする必要があります 、 Shot The Other Node In the Headの略です 。
ノードレベルのフェンシング構成は個々の環境に大きく依存するため、この記事ではフェンシング構成に焦点を当てません。このシナリオでは、次のコマンドを実行して無効にします。
--Disable fencing (STONITH)
sudo pcs property set stonith-enabled=false
ただし、ペースメーカーを使用する場合 実稼働環境では、環境に応じてSTONITHの実装を計画し、有効にしておく必要があります。
次に、いくつかの重要なクラスタープロパティを設定します： cluster-recheck-interval、start-failure-is-fatal、 およびfailure-timeout 。
MSDNによると、 failure-timeout は60秒に設定されており、 cluster-recheck-interval が120秒に設定されている場合、再起動は60秒より長く120秒未満の間隔で試行されます。 cluster-recheck-intervalの値を設定することをお勧めします failure-timeoutの値より大きい 。別の設定start-failure-is-fatal 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を統合するプロセスを説明することです。 新しく作成されたペースメーカーへ クラスターグループ。
まず、 Pacemakerと統合するためのSQLServerリソースエージェントをインストールします。 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つのノードで上記の手順を繰り返します。
すでにペースメーカーを作成しています 可用性グループag1 を構成したら、3つのノードでホストされているすべてのSQLServerインスタンスにログインします。 。ここで、3つのSQLServerインスタンスすべてにsysadminロールを割り当てます。 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.