OS再起動後にAnsible AWXのコンテナ起動ができなくなる問題

以前、Ansible AWXのインストール手順について以下記事にて記載したが、インストール時に発生した問題の一つに、インストール後にOS再起動すると、なぜかAWXのコンテナが起動しないという事象があった。

★以前の記事はこちら↓

Ansible AWXをインストールしてみた
https://tech-mmmm.blogspot.com/2018/09/ansible-awx.html

以下はAWX起動失敗の事象発生時のログとなる。docker psコマンドでは何も表示されず、docker startコマンドでコンテナを起動しようとしても失敗する。

# docker ps　　　←★何も表示されない
# docker ps -a
------------------------------
CONTAINER ID IMAGE                      COMMAND                  CREATED             
STATUS                        PORTS               NAMES
dc063a8e3de0 ansible/awx_task:latest    "/tini -- /bin/sh ..."   25 hours ago        
Exited (143) 22 minutes ago                       awx_task
705aceeb6ed8 ansible/awx_web:latest     "/tini -- /bin/sh ..."   25 hours ago        
Exited (143) 22 minutes ago                       awx_web
24b247a05f54 memcached:alpine           "docker-entrypoint..."   25 hours ago        
Exited (128) 22 minutes ago                       memcached
edd9864f0f44 ansible/awx_rabbitmq:3.7.4 "docker-entrypoint..."   25 hours ago        
Exited (137) 22 minutes ago                       rabbitmq
2061929d6cf7 postgres:9.6               "docker-entrypoint..."   25 hours ago        
Exited (128) 22 minutes ago                       postgres
------------------------------

# docker ps start awx_task awx_web memcached rabbitmq postgres
------------------------------
Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/df4e19d15cbdb563d55602931631de5d08c2b99692c6efc1ffcb5277569a3b66/merged: invalid argument
Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/8a56664e15b48857218f4c68345350ed9155a5c142baa30fb2e619d7e16fc571/merged: invalid argument
Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/67a0d9de802d8833e30b0d4c6edec9e8ee60ed7698f1585ea3fd059999bb908d/merged: invalid argument
Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/f49a15172956a3572d94652d38f2c9716c6de54f5ecf23a0c1cc609fc53f79af/merged: invalid argument
Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/b4e8287273c50c3909024b910166fab055b51888e0fbcd07df09a02c24404cca/merged: invalid argument
Error: failed to start containers: awx_task, awx_web, memcached, rabbitmq, postgres
------------------------------

最初は「error creating overlay mount」というメッセージから、ファイルシステムの問題を疑っていたのだが、最終的には以下問題であることに行き着いた。

Error response from daemon: devmapper: Error mounting '/dev/mapper/docker-253:2-8652374-' on '/var/lib/docker/devicemapper/mnt/': invalid argument
https://github.com/moby/moby/issues/29622

どうやら、SELinuxをきちんと無効化しない状態でOSを再起動すると発生するらしい。たしかに、「setenforce 0」のコマンドで「Permissive」の状態でAWXをインストールしたのち、/etc/sysconfig/selinuxのファイルに「SELINUX=disabled」を設定してOS再起動したら発生したので、事象としては合致している。

ということで回避策は、SELinuxを「Permissive」ではなく「Disabled」の状態にしてからAWXをインストールする、ということになる。
※前回の記事もSELinux無効化設定後、一度OSを再起動するよう手順を記載している

VyOSでDHCPサーバーを構築する

VyOSは仮想ネットワークアプライアンスであり、単純なルーターとしての機能以外にも様々な機能を持っている。DHCPサーバーもそのうちの1つである。

今回、VyOSでDHCPサーバーを構築して動作を確認してみた。結論から言うと、非常に簡単に実装できる。

設定手順

設定投入前にDHCPサーバーの状態を確認しておく。未設定の場合はnot configuredと表示される。

$ show dhcp server statistics
------------------------------
DHCP server not configured
------------------------------

VyOSの設定モードに遷移し、以下コマンドを投入していく。

# ↓「dhcp_scope_01」という名前でDHCPサーバーのプールを作成
# set service dhcp-server shared-network-name dhcp_scope_01
# ↓dhcp_scope_01でリースされた際に設定するデフォルトゲートウェイ
# set service dhcp-server shared-network-name dhcp_scope_01 subnet 192.168.11.0/24 default-router 192.168.11.31
# ↓dhcp_scope_01でリースされた際に設定するDNSサーバー
# set service dhcp-server shared-network-name dhcp_scope_01 subnet 192.168.11.0/24 dns-server 192.168.11.62
# ↓dhcp_scope_01でリースされた際に設定するIPアドレス
# ↓今回であれば、192.168.11.221-230の範囲の10個のIPアドレスがリースされる
# set service dhcp-server shared-network-name dhcp_scope_01 subnet 192.168.11.0/24 start 192.168.11.221 stop 192.168.11.230

反映前にcompareで設定内容を確認する。今回リース期間を明示的にしていないが、デフォルトで86400秒 (24時間) が設定されている。

# compare
------------------------------
[edit service]
+dhcp-server {
+    disabled false
+    shared-network-name dhcp_scope_01 {
+        authoritative disable
+        subnet 192.168.11.0/24 {
+            default-router 192.168.11.31
+            dns-server 192.168.11.62
+            lease 86400　　　←★リース期間はデフォルトで24時間
+            start 192.168.11.221 {
+                stop 192.168.11.230
+            }
+        }
+    }
+}
------------------------------

問題なければ、commitして反映させ、saveで設定保存する。

# commit
# save
------------------------------
Saving configuration to '/config/config.boot'...
Done
------------------------------

設定後のDHCPサーバーの状態を確認すると、先ほど設定したdhcp_scope_01の状態が表示されるようになる。「Pool size」が割り当て可能なIPアドレスの最大値となる。

$ show dhcp server statistics
------------------------------
Pool                      Pool size   # Leased    # Avail
----                      ---------   --------    -------
dhcp_scope_01             10          0           10
------------------------------

実際にDHCPにてIPアドレスがリースされると、「Leased」増えることがわかる。

$ show dhcp server statistics
------------------------------
Pool                      Pool size   # Leased    # Avail
----                      ---------   --------    -------
dhcp_scope_01             10          1           9
------------------------------

リース状況の確認は以下コマンドで行う。割り当てられたMACアドレスや、リース執行の期限が表示される。

$ show dhcp server leases
------------------------------
IP address      Hardware address   Lease expiration     Pool           Client Name
----------      ----------------   ----------------     ----           -----------
192.168.11.221  00:0c:29:00:f4:a7  2018/07/24 06:28:35  dhcp_scope_01  t1000cent
------------------------------

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する③ (障害試験編)

PacemakerとCorosyncで構築するクラスターの記事も今回で最後となる。

★前回の記事はこちら↓

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する① (準備・インストール編)
https://tech-mmmm.blogspot.com/2018/11/centos-7-pacemaker-corosyncmariadb.html

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する② (クラスター・リソース構成編)

https://tech-mmmm.blogspot.com/2018/11/centos-7-pacemaker-corosyncmariadb_65.html

3回目となる最後は、実際に前回までに設定したクラスターで疑似障害を発生させ、その際のリソースのフェイルオーバーの動きを見ることにする。

障害発生のパターンは複数考えられるが、今回は、手動でのフェイルオーバー手順と、サーバー障害とNIC障害を代表的な障害として、動作確認を行う。

手動フェイルオーバー① (コマンドでリソースグループを移動)

手動でフェイルオーバーさせるために、わざわざサーバーを再起動したりするのは面倒なので、コマンドでリソースグループをフェイルオーバーさせてみる。

# pcs resource show

------------------------------

 Resource Group: rg01

     VirtualIP  (ocf::heartbeat:IPaddr2):       Started t1113cent

     ShareDir   (ocf::heartbeat:Filesystem):    Started t1113cent

     MariaDB    (systemd:mariadb):      Starting t1113cent

------------------------------

以下コマンドでリソースグループrg01をノードt1114centに移動させる。

# pcs resource move rg01 t1114cent

確認してみると、確かにリソースグループがt1114centに移動していることがわかる。

# pcs resource show

------------------------------

 Resource Group: rg01

     VirtualIP  (ocf::heartbeat:IPaddr2):       Started t1114cent

     ShareDir   (ocf::heartbeat:Filesystem):    Started t1114cent

     MariaDB    (systemd:mariadb):      Starting t1114cent

------------------------------

リソースグループをフェイルバックさせる場合は、以下の通りもともと起動していたノードにリソースグループを移動しなおすことで対応する。

# pcs resource move rg01 t1113cent

手動でフェイルオーバー② (ノードをスタンバイにする)

コマンドでフェイルオーバーさせる手順以外にも、ノードをスタンバイにすることで強制的にリソースグループを移動させることもできるので、手順を紹介しておこう。

# pcs status
------------------------------
Cluster name: cluster2
Stack: corosync
Current DC: t1114cent (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Sat Nov 24 15:00:47 2018
Last change: Sat Nov 24 15:00:44 2018 by root via cibadmin on t1114cent

2 nodes configured
3 resources configured

Online: [ t1113cent t1114cent ]

Full list of resources:

 Resource Group: rg01
     VirtualIP  (ocf::heartbeat:IPaddr2):       Started t1113cent
     ShareDir   (ocf::heartbeat:Filesystem):    Started t1113cent
     MariaDB    (systemd:mariadb):      Started t1113cent

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled
------------------------------

現在リソースグループが起動しているt1113centをスタンバイにする。

# pcs cluster standby t1113cent

再度クラスターの状態を確認する。

# pcs status
------------------------------
Cluster name: cluster2
Stack: corosync
Current DC: t1114cent (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Sat Nov 24 15:03:50 2018
Last change: Sat Nov 24 15:03:42 2018 by root via cibadmin on t1113cent

2 nodes configured
3 resources configured

Node t1113cent: standby　　　←★standbyになっている
Online: [ t1114cent ]

Full list of resources:

 Resource Group: rg01　　　←★リソースがすべてt1114centに移動している
     VirtualIP  (ocf::heartbeat:IPaddr2):       Started t1114cent
     ShareDir   (ocf::heartbeat:Filesystem):    Started t1114cent
     MariaDB    (systemd:mariadb):      Starting t1114cent

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled
------------------------------

リソースグループをフェイルバックさせる場合は、以下のとおり実施する。

# pcs cluster unstandby t1113cent　←★t1113centのスタンバイを解除

# pcs cluster standby t1114cent　　←★t1114centをスタンバイ

# pcs cluster unstandby t1113cent　←★t1114centのスタンバイを解除

サーバーダウン障害

サーバーの突発停止や再起動が発生した場合を想定して、クラスターの動作を検証する。

VMware Host Clientにて、仮想マシンの再起動を実施する。

リソースグループは正常に切り替わっていることを確認できる。

# pcs status
------------------------------
Cluster name: cluster2
Stack: corosync
Current DC: t1114cent (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Sun Nov 25 06:33:04 2018
Last change: Sun Nov 25 06:25:18 2018 by root via crm_resource on t1113cent

2 nodes configured
3 resources configured

Online: [ t1114cent ]
OFFLINE: [ t1113cent ]　　　←★OFFLINEになる

Full list of resources:

 Resource Group: rg01
     VirtualIP  (ocf::heartbeat:IPaddr2):       Started t1114cent
     ShareDir   (ocf::heartbeat:Filesystem):    Started t1114cent
     MariaDB    (systemd:mariadb):      Started t1114cent
↑★t1114centに切り替わっている

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled
------------------------------

NIC障害

サービス用のNICが切断され、VIPが消えた場合のクラスターの動作を検証する。

本記事では割愛するが、VIPの監視にon-fail=standbyのオプションを指定しないとうまく切り替わらないので、あらかじめ設定しておくことにする。

# pcs resource update VirtualIP op monitor on-fail=standby
# pcs resource show --full
------------------------------
 Group: rg01
  Resource: VirtualIP (class=ocf provider=heartbeat type=IPaddr2)
   Attributes: cidr_netmask=24 ip=192.168.11.115 nic=ens192
   Operations: monitor interval=60s on-fail=standby (VirtualIP-monitor-interval-60s)
               start interval=0s timeout=20s (VirtualIP-start-interval-0s)
               stop interval=0s timeout=20s (VirtualIP-stop-interval-0s)
  Resource: ShareDir (class=ocf provider=heartbeat type=Filesystem)
   Attributes: device=/dev/sharevg/lv001 directory=/share fstype=xfs
   Operations: monitor interval=20 timeout=40 (ShareDir-monitor-interval-20)
               notify interval=0s timeout=60 (ShareDir-notify-interval-0s)
               start interval=0s timeout=60 (ShareDir-start-interval-0s)
               stop interval=0s timeout=60 (ShareDir-stop-interval-0s)
  Resource: MariaDB (class=systemd type=mariadb)
   Operations: monitor interval=60 timeout=100 (MariaDB-monitor-interval-60)
               start interval=0s timeout=100 (MariaDB-start-interval-0s)
               stop interval=0s timeout=100 (MariaDB-stop-interval-0s)
------------------------------

疑似障害を起こすため、仮想マシンのNICを切断する。

1分程度でリソースVirtualIPがFAILEDステータスになり、リソースグループがフェイルオーバーされる。

# pcs status
------------------------------
Cluster name: cluster2
Stack: corosync
Current DC: t1114cent (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Sun Nov 25 06:03:12 2018
Last change: Sat Nov 24 15:16:21 2018 by root via crm_resource on t1113cent

2 nodes configured
3 resources configured

Node t1113cent: standby (on-fail)　　　←★standby (on-fail)になる
Online: [ t1114cent ]

Full list of resources:

 Resource Group: rg01
     VirtualIP  (ocf::heartbeat:IPaddr2):       FAILED t1113cent　←★FAILEDになる
     ShareDir   (ocf::heartbeat:Filesystem):    Started t1113cent
     MariaDB    (systemd:mariadb):      Stopping t1113cent

Failed Actions:
* VirtualIP_monitor_60000 on t1113cent 'not running' (7): call=51, status=complete, exitreason='',
    last-rc-change='Sun Nov 25 06:03:09 2018', queued=0ms, exec=0ms
↑★VirtualIPに関するログが表示される

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled
------------------------------

障害ノードが復旧し、クラスターの状態を戻す場合は、以下コマンドを実行する。

# pcs resource cleanup
------------------------------
Cleaned up all resources on all nodes
Waiting for 1 replies from the CRMd. OK
------------------------------

上記コマンドでクラスターを復旧させると、リソースグループが元のノードにフェイルバックするので注意。どうやらもともと稼働していたノードのスコアがINFINITYのままになるため、フェイルバックするようだ。この辺りをきちんと制御する意味でも、STONITHの設定を有効にし、障害が発生したノードは強制停止する設定をした方がよいかもしれない。

まとめ

以上で、全3回にわたって説明してきたPacemaker + Corosyncの設定手順と動作検証の記事は終了となる。
設定手順自体が多く複雑ではあるが、設定はすべてコマンドで実施できるよう構成されており、複雑な設定ファイルを作成する必要がない分、慣れれば構成しやすいソフトウェアではないかと感じた。
今回は実施していないが、本来はスプリットブレイン対策としてSTONITHの設定が推奨されることから、別途STONITHの設定手順なども検証して記載したいと考えている。

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する② (クラスター・リソース構成編)

前回はPacemakerとCorosyncを使用する準備まで実施したので、クラスターとしての設定を行っていく。

★前回の記事はこちら↓

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する① (準備・インストール編)
https://tech-mmmm.blogspot.com/2018/11/centos-7-pacemaker-corosyncmariadb.html

Pacemaker・Corosyncのクラスターを作成

1. クラスターを作成

スプリットブレイン発生を防止する観点から、クラスター間のハートビートをやり取りするネットワークは2本以上の冗長構成とするのが望ましい。

クラスター作成の際に、ノード名をIPアドレスごとにカンマ区切りで指定することで、複数のIPアドレスでクラスターに登録がされる。

※片方のノードで実施
# pcs cluster setup --start --name cluster2 t1113cent,t1113cent-55 t1114cent,t1114cent-55
------------------------------
Destroying cluster on nodes: t1113cent, t1114cent...
t1113cent: Stopping Cluster (pacemaker)...
t1114cent: Stopping Cluster (pacemaker)...
t1113cent: Successfully destroyed cluster
t1114cent: Successfully destroyed cluster

Sending 'pacemaker_remote authkey' to 't1113cent', 't1114cent'
t1113cent: successful distribution of the file 'pacemaker_remote authkey'
t1114cent: successful distribution of the file 'pacemaker_remote authkey'
Sending cluster config files to the nodes...
t1113cent: Succeeded
t1114cent: Succeeded

Starting cluster on nodes: t1113cent, t1114cent...
t1113cent: Starting Cluster...
t1114cent: Starting Cluster...

Synchronizing pcsd certificates on nodes t1113cent, t1114cent...
t1114cent: Success
t1113cent: Success
Restarting pcsd on the nodes in order to reload the certificates...
t1114cent: Success
t1113cent: Success
------------------------------

設定確認は以下コマンドで実施する。RING ID 0とRING ID 1で2つのIPアドレスが設定されていることがわかる。

# corosync-cfgtool -s
------------------------------
Printing ring status.
Local node ID 1
RING ID 0
        id      = 192.168.11.113
        status  = ring 0 active with no faults
RING ID 1
        id      = 192.168.55.113
        status  = ring 1 active with no faults
------------------------------

2. クラスターのプロパティを設定

クラスターの設定として、STONITHの無効化を行い、no-quorum-policyをignoreに設定する。今回はあくまで検証目的なのでSTONITHは無効化するが、本来はスプリットブレイン時の対策として、STONITHは有効化するべきである。

no-quorum-policyについて、通常クォーラムは多数決の原理でアクティブなノードを決定する仕組みとなるのだが、2台構成のクラスターの場合は多数決による決定ができないため、クォーラム設定は「ignore」に設定するのがセオリーのようだ。この場合スプリットブレインが発生したとしても、各ノードのリソースは特に何も制御されないという設定となるため、STONITHによって片方のノードを強制的に電源を落として対応することになる。

それでは設定をしていこう。まず、現状のプロパティを確認する。

※片方のノードで実施
# pcs property
------------------------------
Cluster Properties:
 cluster-infrastructure: corosync
 cluster-name: cluster2
 dc-version: 1.1.18-11.el7_5.3-2b07d5c5a9
 have-watchdog: false
------------------------------

設定を変更する。

※片方のノードで実施
# pcs property set stonith-enabled=false
# pcs property set no-quorum-policy=ignore
# pcs property
------------------------------
Cluster Properties:
 cluster-infrastructure: corosync
 cluster-name: cluster2
 dc-version: 1.1.18-11.el7_5.3-2b07d5c5a9
 have-watchdog: false
 no-quorum-policy: ignore   ←★クォーラムをignoreに設定
 stonith-enabled: false     ←★STONITHを無効化
------------------------------

リソースエージェントを使ってリソースを構成する

1. リソースを構成

リソースを制御するために、リソースエージェントを利用する。リソースエージェントとは、クラスターソフトで用意されているリソースの起動・監視・停止を制御するためのスクリプトとなる。

今回の構成では以下リソースエージェントを利用する。

• ocf:heartbeat:IPaddr2 : 仮想IPアドレスを制御
• ocf:heartbeat:Filesystem  : ファイルシステムのマウントを制御
• systemd:mariadb : MariaDBを制御

各リソースエージェントの使用方法は、以下コマンドで確認できる。

# pcs resource describe <リソースエージェント>

まずは仮想IPアドレスの設定を行う。付与するipアドレス・サブネットマスク・NICを指定している。また、interval=30sとして監視間隔を30秒に変更している。

※片方のノードで実施
# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.11.115 cidr_netmask=24 nic=ens192 op monitor interval=30s

次に共有ディスクとして作成したファイルシステム「/dev/sharevg/lv001」のマウントの設定を行う。マウントするデバイス・マウントポイント・ファイルシステムタイプを指定している。

※片方のノードで実施
# pcs resource create ShareDir ocf:heartbeat:Filesystem device=/dev/sharevg/lv001 directory=/share fstype=xfs

最後にMariaDBの設定となる。こちらはシンプルに以下コマンドで設定するだけでよい。

※片方のノードで実施
# pcs resource create MariaDB systemd:mariadb

上記3つのリソースは起動・停止の順番を考慮する必要がある。

• 起動：「仮想IPアドレス」→「ファイルシステム」→「MariaDB」
• 停止：「MariaDB」→「ファイルシステム」→「仮想IPアドレス」

この順序を制御するために、リソースの順序を付けてグループ化した「リソースグループ」を作成する。

※片方のノードで実施
# pcs resource group add rg01 VirtualIP ShareDir MariaDB

以上でリソース設定が完了となるので、クラスターの設定を確認してみる。

※片方のノードで実施
# pcs status
------------------------------
Cluster name: cluster2
WARNING: no stonith devices and stonith-enabled is not false
Stack: corosync
Current DC: t1114cent (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Thu Aug 30 23:36:40 2018
Last change: Thu Aug 30 23:36:39 2018 by root via cibadmin on t1113cent

2 nodes configured
3 resources configured

Online: [ t1113cent t1114cent ]

Full list of resources:

 Resource Group: rg01
     VirtualIP  (ocf::heartbeat:IPaddr2):       Stopped
     ShareDir   (ocf::heartbeat:Filesystem):    Stopped
     MariaDB    (systemd:mariadb):      Stopped

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled
------------------------------

2. クラスター起動

設定が完了したので、クラスターの起動を行う。各リソースが「Started」となっていれば問題ない。

※片方のノードで実施
# pcs cluster start --all
------------------------------
t1114cent: Starting Cluster...
t1113cent: Starting Cluster...
------------------------------

起動後のステータスを確認。

※片方のノードで実施
# pcs status
------------------------------
Cluster name: cluster2
Stack: corosync
Current DC: t1114cent (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Thu Aug 30 23:40:06 2018
Last change: Thu Aug 30 23:38:42 2018 by root via cibadmin on t1113cent

2 nodes configured
3 resources configured

Online: [ t1113cent t1114cent ]

Full list of resources:

 Resource Group: rg01
     VirtualIP  (ocf::heartbeat:IPaddr2):       Started t1113cent
     ShareDir   (ocf::heartbeat:Filesystem):    Started t1113cent
     MariaDB    (systemd:mariadb):      Started t1113cent

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled
------------------------------

クラスターのハートビートが二重化されていることも確認しておこう。今回の場合、192.168.11.113と192.168.55.113の2つのIPアドレスが登録されており、「no faults (エラーなし)」となっていることが確認できる。

※片方のノードで実施
# corosync-cfgtool -s
------------------------------
Printing ring status.
Local node ID 1
RING ID 0
        id      = 192.168.11.113
        status  = ring 0 active with no faults
RING ID 1
        id      = 192.168.55.113
        status  = ring 1 active with no faults

------------------------------

次回予告

これでクラスターの作成が完了した。次回は実際に疑似障害を発生させてクラスターのフェイルオーバーの動きを確認することにする。

★次回はこちら↓

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する③ (障害試験編)
https://tech-mmmm.blogspot.com/2018/12/centos-7-pacemaker-corosyncmariadb.html

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する① (準備・インストール編)

RHEL 7やCentOS 7では、サーバークラスターを実装するソフトウェアとして、Pacemaker + Corosyncによる実装が標準となっている。これらの機能は、CentOSでは当然無償で利用することができるが、RHELでは「High Availability Add-On」のサブスクリプション購入が必要となる。

Red Hat Enterprise Linux 7 向け High Availability Add-On のリファレンスドキュメント

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/

Linux環境でクラスターを組んだことがなかったので、勉強がてらCentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化してみた。

実施内容がそこそこ多いので、今回含めて、全3回で記載することにする。

1. 準備・インストール編
   Pacemaker・CorosyncおよびMariaDBをインストールし初期設定を行う。
2. クラスター・リソース構成編
   クラスターを作成し、リソースの構成を行う。
3. 障害試験編
   疑似障害を発生させて、フェイルオーバーの動作確認を行う。

それでは、まずは今回構成する環境からみていこう。

環境および用語

今回はESXi上に仮想マシンを2台作成し、クラスター構成にする。

• ノード#1 ホスト名：t1113cent
• ノード#2 ホスト名：t1114cent

PacemakerとCorosyncがクラスターの機能を提供する。それぞれの役割については、以下に他の用語と合わせて記載をする。

• Pacemaker (ペースメーカー)：クラスターのリソース制御(リソースの起動・監視・停止、フェイルオーバー等)を行う
• Corosync (コロシンク)：クラスターノード間の死活監視を行う。後述するSTONITHもCorosyncの機能
• STONITH (ストニス)：Shoot The Other Node In The Headの略。スプリットブレイン時に、複数ノードがActiveになることを防止する機能
• スプリットブレイン：ネットワーク断によりクラスター間で相互に監視ができなくなり、どのノードがActiveで動作しているか不明となっている状況
• リソース：クラスターが起動・監視・停止を制御する対象。たとえば、仮想IPアドレス、ディスクマウント、DBサービスなど多岐にわたる
• リソースエージェント：起動・監視・停止を制御するためのスクリプト。クラスター管理ソフトウェアで用意されている
• リソースグループ：複数のリソースエージェントをグループ化し、同一ノードで複数のリソースの起動・監視・停止を制御するためのもの

クラスター監視用のネットワークは、すべて切断されるとスプリットブレインとなってしまうため、2本の冗長構成とする。

共有ディスクはSCSIバスの共有を行い、同一のvmdkファイルを2台の仮想マシンからマウントできるように構成し、本ディスクにMariaDBのデータベースを配置する構成とする。

ESXi環境でSCSIバスの共有を行い、共有ディスクを作成

1. ノード#1側にSCSIコントローラーを追加

ESXiにてノード#1の仮想マシンの「設定の編集」を開き、「SCSIコントローラー」を追加する。

「SCSIバスの共有」で仮想または物理を選ぶ。同一のESXiに存在する仮想マシン間でディスクを共有したい場合は「仮想」を選び、複数のESXiをまたいでディスクを共有したい場合は「物理」を選べばよい。今回は、同一ESXiだったので「仮想」で設定した。

2. ノード#1側にディスクを追加

SCSIコントローラーを追加したら、続けて新規ハードディスクを作成する。ディスクを共有する場合は「シック プロビジョニング (Eager Zerod)」を選択する必要がある。「コントローラーの場所」は、先ほど作成した「SCSI コントローラ 1」を選択する。

3. ノード#2側にSCSIコントローラーを追加

もう一台のノード#2側に対しても、同様にSCSIコントローラーを追加する。「SCSIバスの共有」はノード#1と同様「仮想」を選択する。

4. ノード#2側にディスクを追加

新規ではなく「既存のハードディスク」にてディスクを追加する。

ディスク選択画面が表示されるので、ノード#1に作成した共有ディスクとして利用するvmdkファイルを選択する。

最後に、SCSIコントローラーを「SCSI コントローラ 1」に設定すれば完了。

以上で、共有ディスクの作成が完了となる。OS側でも確認すると、以下の通り両ノードでディスクのデバイスが見えていることがわかる。

※ノード#1で実施
# fdisk -l /dev/sdb
------------------------------
Disk /dev/sdb: 5368 MB, 5368709120 bytes, 10485760 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
------------------------------

※ノード#2で実施
# fdisk -l /dev/sdb
------------------------------
Disk /dev/sdb: 5368 MB, 5368709120 bytes, 10485760 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
------------------------------

今回は本題から外れるので詳細な手順は割愛するが、上記領域に適当にファイルシステムを作成し、ノード#1の/shareにマウントしておこう。

MariaDBのインストール・初期設定

1. MariaDBをインストール

yumでインストールするのが手っ取り早い。

※両ノードで実施
# yum install mariadb
# yum install mariadb-server

インストール後、状態を確認する。最終的にクラスターで起動・停止が制御されるため、現時点ではinactive / disabledになっていればよい。

※両ノードで実施
# systemctl status mariadb
------------------------------
● mariadb.service - MariaDB database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
------------------------------

2. 初期設定

MariaDBのデータベース保存先を/share/mysqlに変更するため、/etc/my.cnfに変更と追記を行う。

※両ノードで実施
# vi /etc/my.cnf
------------------------------
[mysqld]
#datadir=/var/lib/mysql           ←★コメントアウト
datadir=/share/mysql              ←★追加
#socket=/var/lib/mysql/mysql.sock ←★コメントアウト
socket=/share/mysql/mysql.sock    ←★追加

[client]                          ←★追加
socket=/share/mysql/mysql.sock    ←★追加
------------------------------

3. MariaDBを起動

設定完了後MariaDBを起動すると、以下の通りエラーとなった。

※ノード#1で実施
# systemctl start mariadb
------------------------------
Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details.
------------------------------

SELinuxが悪さするようなので止めておく。

※両ノードで実施
# setenforce 0

再度起動させると、今度は成功するはず。

※ノード#1で実施
# systemctl start mariadb

4. データベース・テーブル作成

MariaDBの動作確認ができるようにデータベースとテーブルを作っておく。mysqlコマンドを用いて、rootユーザーでMariaDBにログインする。

※ノード#1で実施
# mysql -u root

データベースを作成する。

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
+--------------------+
4 rows in set (0.00 sec)

MariaDB [(none)]> create database cluster_test;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| cluster_test       |　←★作成された
| mysql              |
| performance_schema |
| test               |
+--------------------+
5 rows in set (0.00 sec)

続けてテーブルを作成する。

MariaDB [(none)]> use cluster_test;
Database changed

MariaDB [cluster_test]> show tables;
Empty set (0.00 sec)

MariaDB [cluster_test]> create table test_table(name varchar(20));
Query OK, 0 rows affected (0.00 sec)

MariaDB [cluster_test]> show tables;
+------------------------+
| Tables_in_cluster_test |
+------------------------+
| test_table             |　←★作成された
+------------------------+
1 row in set (0.00 sec)

作成したテーブルに1行追加してみる。

MariaDB [cluster_test]> insert into test_table value('hoge');
Query OK, 1 row affected (0.00 sec)

MariaDB [cluster_test]> select * from test_table;
+------+
| name |
+------+
| hoge |　←★追加された
+------+
1 row in set (0.00 sec)

以上でMariaDBの準備が整った。

Pacemaker・Corosyncのインストール・初期設定

1. Pacemaker・Corosyncをインストール

yumでインストールする。

※両ノードで実施

# yum install pacemaker

# yum install pcs
# yum install fence-agents-all

2. 初期設定

クラスター用ユーザーを設定する。yumでインストールすると、「hacluster」ユーザーが作成されているはずなので確認する。

※両ノードで実施
# cat /etc/passwd | tail

------------------------------

sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin

postfix:x:89:89::/var/spool/postfix:/sbin/nologin

chrony:x:998:996::/var/lib/chrony:/sbin/nologin

ntp:x:38:38::/etc/ntp:/sbin/nologin

rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin

rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin

nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin

tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/sbin/nologin

hacluster:x:189:189:cluster user:/home/hacluster:/sbin/nologin　←★クラスター用ユーザー

unbound:x:997:993:Unbound DNS resolver:/etc/unbound:/sbin/nologin

------------------------------

パスワードを設定しておく。当然、両ノードで同一のパスワードで設定しておくこと。

※両ノードで実施
# passwd hacluster

------------------------------

ユーザー hacluster のパスワードを変更。

新しいパスワード:

新しいパスワードを再入力してください:

passwd: すべての認証トークンが正しく更新できました。

------------------------------

ここで、Pacemakerのサービスを起動させる。

※両ノードで実施
# systemctl start pcsd.service

# systemctl enable pcsd.service

起動後の状態を確認し、エラーなくacitive / enabledとなっていればOK。

※両ノードで実施
# systemctl status pcsd.service
------------------------------

● pcsd.service - PCS GUI and remote configuration interface

   Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; vendor preset: disabled)

   Active: active (running) since 木 2018-08-30 10:28:07 JST; 2min 13s ago

     Docs: man:pcsd(8)

           man:pcs(8)

 Main PID: 2004 (pcsd)

   CGroup: /system.slice/pcsd.service

           mq2004 /usr/bin/ruby /usr/lib/pcsd/pcsd > /dev/null &

 8月 30 10:28:01 t1113cent systemd[1]: Starting PCS GUI and remote configur....

 8月 30 10:28:07 t1113cent systemd[1]: Started PCS GUI and remote configura....

Hint: Some lines were ellipsized, use -l to show in full.

------------------------------

クラスターを組む際に名前解決できるように、hostsにお互いのIPアドレスを登録しておく。

※両ノードで実施
# vi /etc/hosts

------------------------------

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4

::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

192.168.11.113  t1113cent    ←★追加

192.168.55.113  t1113cent-55 ←★追加

192.168.11.114  t1114cent    ←★追加

192.168.55.114  t1114cent-55 ←★追加

------------------------------

クラスターに参加するノードの認証を行う。。。が、失敗してしまった。

※片方のノードで実施
# pcs cluster auth t1113cent t1114cent
------------------------------

Username: hacluster

Password:

Error: Unable to communicate with t1114cent　←★失敗。。。

t1113cent: Authorized

------------------------------

どうやらfirewalldが原因のようなので止めておく。

※両ノードで実施

# systemctl stop firewalld

# systemctl disable firewalld

再度ノードの認証を行うと成功した。

※片方のノードで実施

# pcs cluster auth t1113cent t1114cent

------------------------------

Username: hacluster

Password:

t1114cent: Authorized

t1113cent: Authorized

------------------------------

次回予告

これで準備がようやく終わり、次から本題のクラスター構成作業に進むのだが、長くなってしまったので続きは次回とする。

★次回はこちら↓

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する② (クラスター・リソース構成編)

https://tech-mmmm.blogspot.com/2018/11/centos-7-pacemaker-corosyncmariadb_65.html

CentOS 7 + Pacemaker + CorosyncでMariaDBをクラスター化する③ (障害試験編)
https://tech-mmmm.blogspot.com/2018/12/centos-7-pacemaker-corosyncmariadb.html