商用OSのEOSを調べてみた！2018年末版

昨年以下記事でまとめた主要な商用OSのEOSについて、今年も調べてアップデートしてみた。

・商用OSのEOSを調べてみた！2017年末版
https://tech-mmmm.blogspot.com/2017/12/oseos2017.html

2019年にサポート期限を迎える製品については、赤字で強調表示した。

なお、本記事で「EOS」と表現する場合は、製品として完全にすべてのサポートが終了する期限を指すことにする。例えば、通常サポートが終了しても延長サポートが存在するような場合は、EOSとは表現しない。

Windows (PC用)

2019年になっても即座にEOSとなるOSは無い。Windows 7に関しては2020年1月まで延長サポートが続くが、そろそろEOSが1年後に迫ってきたこともあり、Windows 7を使用している企業は更新を検討しなければならないタイミングとなるだろう。

・製品のライフサイクルの検索
https://support.microsoft.com/ja-jp/lifecycle/search

・ご存知ですか？OS にはサポート期限があります！
https://www.microsoft.com/ja-jp/atlife/article/windows10-portal/eos.aspx

・Windows 7 SP 1
延長サポート：2020/01/14 (SP1必須)

・Windows 8.1
延長サポート：2023/01/10

・Windows 10
Windows 10は、今までのWindows OSとサポートポリシーが異なり、モダンライフサイクルポリシーが適用される。なお、今までの単純なメインストリームサポートと延長サポートの構成を「固定ライフサイクルポリシー」と呼ぶ。

Windows ライフサイクルのファクト シート
https://support.microsoft.com/ja-jp/help/13853/windows-lifecycle-fact-sheet

モダンライフサイクルポリシーについて簡単に説明すると、Windows 10では3月と9月の年2回、機能更新プログラムのリリースが予定されており、この機能更新プログラムのリリースから18ヶ月(EnterpriseとEducationのみ9月更新は30ヶ月)が、その機能更新プログラムを適用したWindows 10のサポート期間となる。

機能更新プログラムはYYMMの形式で表現され、2018年12月現在の最新バージョンは1809となる。

以下に2018年12月時点でサポート中のバージョンを以下に記載する。

・Windows 10, version 1709 サポート終了：2019/04/09
・Windows 10, version 1803 サポート終了：2019/11/12
・Windows 10, version 1809 サポート終了：2020/05/12

Windows Server

Windows Serverは今年Windows Server 2019がリリースされており、2018年12月時点で、Windows Server 2008 R2、2012、2012 R2、2016、2019の5つのバージョンがサポート中の状況となっている。ただし、Windows Server 2008 R2はWindows 7同様、2020年1月でEOSとなるため、利用中のシステムは更改検討が必要となるだろう。

・製品のライフサイクルの検索
https://support.microsoft.com/ja-jp/lifecycle/search

・Windows Server 2008 R2 SP1
延長サポート：2020/01/14 (SP1必須)
※プレミアムアシュアランスによる6年の追加サポートが可能な模様
・Introducing Windows Server Premium Assurance and SQL Server Premium Assurance
https://cloudblogs.microsoft.com/hybridcloud/2016/12/08/introducing-windows-server-premium-assurance-and-sql-server-premium-assurance/

・Windows Server 2012 / Windows Server 2012 R2
延長サポート：2023/10/10

・Windows Server 2016
メインストリームサポート：2022/01/11
延長サポート：2027/01/11

・Windows Server 2019
メインストリームサポート：2024/01/09
延長サポート：2029/01/09

vSphere

2019年は特にEOSとなる製品はない。vSphere 6.7が登場したものの、vSphere 6.5とサポート期間は変わらないため注意。

・VMware Lifecycle Product Matrix
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf

・ESXi 5.5 / vCenter Server 5.5
END OF TECHNICAL GUIDANCE：2020/09/19

・ESXi 6.0 / vCenter Server 6.0
END OF GENERAL SUPPORT：2020/03/12
END OF TECHNICAL GUIDANCE：2022/03/12

・ESXi 6.5 / vCenter Server 6.5
END OF GENERAL SUPPORT：2021/11/15
END OF TECHNICAL GUIDANCE：2023/11/15

・ESXi 6.7 / vCenter Server 6.7
END OF GENERAL SUPPORT：2021/11/15
END OF TECHNICAL GUIDANCE：2023/11/15

Red Hat Enterprise Linux

2019年は特にEOSとなる製品はない。

・Red Hat Enterprise Linux Life Cycle
https://access.redhat.com/support/policy/updates/errata

・Red Hat Enterprise Linux 5
End of Extended Life-cycle Support：2020/11/30

・Red Hat Enterprise Linux 6
End of Production 3：2020/11/30
End of Extended Life-cycle Support：2024/06/30

・Red Hat Enterprise Linux 7
End of Production 3：2024/06/30
End of Extended Life-cycle Support：未発表

AIX

AIXはTL (Technology Level)毎にサポート期限が異なる。本記事では各メジャーバージョンの最新TLのEOSを記載する。

・AIX support lifecycle information
https://www-01.ibm.com/support/docview.wss?uid=isg3T1012517

・AIX 7.1 TL5
End of Service Pack Support ：2022/04/30

・AIX 7.2 TL3
End of Service Pack Support ：2021/9/31 (予想)

HP-UX

HP-UXはあまり頻繁なバージョンアップはなく、2007年4月に発表されたHP-UX 11i v3が未だに最新という状況となっている。

・長期間利用のための開発方針とサポートポリシー
https://h50146.www5.hpe.com/products/software/oe/hpux/topics/support/

・HP-UX 11i v2
サポート終了：2019/12月

・HP-UX 11i v3
サポート終了：未発表

参考

・End Of Support (EOS) の調べ方
https://tech-mmmm.blogspot.jp/2015/04/end-of-support-eos.html

ESXi Shellを使って、コマンドでESXiの仮想ネットワークの設定を行う方法

先日、検証用ESXiサーバーが突如不調となり、VMware Host Clientにログインできなくなる事象が発生した。再起動しても治らなかったため、再インストールで復旧させる事態となった。

その際にESXiの仮想スイッチの初期設定をVMware Host ClientのGUI画面でポチポチ実施することがどうにも面倒だったので、次回からESXi Shellを使ってコマンドで簡単に実施できるようにしてみた、という話をする。

設定内容

vSwitchの構成は以下の通り。ESXiは6.7を使用している。

コマンドで確認すると、最終形は以下となる。

# esxcfg-vswitch -l
------------------------------
Switch Name      Num Ports   Used Ports  Configured Ports  MTU     Uplinks
vSwitch0         2560        6           128               1500    vmnic0

  PortGroup Name        VLAN ID  Used Ports  Uplinks
  Network_33            0        2           vmnic0
  Manage_33             0        1           vmnic0

Switch Name      Num Ports   Used Ports  Configured Ports  MTU     Uplinks
vSwitch1         2560        6           128               1500    vmnic1

  PortGroup Name        VLAN ID  Used Ports  Uplinks
  Network_1055          1055     0           vmnic1
  Network_1077          1077     0           vmnic1
  Network_1011          1011     2           vmnic1
  Manage_1011           1011     1           vmnic1

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

仮想スイッチの作成

まずは仮想スイッチを作成する。vSwitch0はESXiインストール時に作成されているので特に作業は不要となる。

コマンド

esxcfg-vswitchコマンドを使って仮想スイッチ作成を行う。使用する構文とオプションは以下の通り。

• -a：vSwitch1を追加
  # esxcfg-vswitch -a <仮想スイッチ>
• -L：vSwitch1に物理NICの割り当て
  # esxcfg-vswitch -L <物理NIC> <仮想スイッチ>

実行例

# esxcfg-vswitch -a vSwitch1
# esxcfg-vswitch -L vmnic1 vSwitch1

ポートグループ作成

コマンド

ポートグループ作成も引き続きesxcfg-vswitchコマンドで実施可能となる。

• -A：ポートグループを追加
  # esxcfg-vswitch -A <ポートグループ> <仮想スイッチ>

VLAN IDを設定するポートグループは、先にポートグループを作成したのち、VLAN IDの設定を行う。使用する構文とオプションは以下の通り。

• -A：ポートグループ追加
  # esxcfg-vswitch -A <ポートグループ> <仮想スイッチ>
• -p、-v：-pで指定したポートグループのVLAN IDを-vの値に設定
  # esxcfg-vswitch -p <ポートグループ> -v <VLAN ID> <仮想スイッチ>

実行例

・VLAN IDなしの場合
# esxcfg-vswitch -A Manage_33 vSwitch0
# esxcfg-vswitch -A Network_33 vSwitch0

・VLAN ID指定の場合

# esxcfg-vswitch -A Manage_1011 vSwitch1
# esxcfg-vswitch -p Manage_1011 -v 1011 vSwitch1
# esxcfg-vswitch -A Network_1011 vSwitch1
# esxcfg-vswitch -p Network_1011 -v 1011 vSwitch1
# esxcfg-vswitch -A Network_1055 vSwitch1
# esxcfg-vswitch -p Network_1055 -v 1055 vSwitch1
# esxcfg-vswitch -A Network_1077 vSwitch1
# esxcfg-vswitch -p Network_1077 -v 1077 vSwitch1

VMkernel NICを作成

コマンド

VMkernel NICはesxcfg-vmknicコマンドで設定することができる。使用する構文とオプションは以下の通り。

• -a、-i、-n：それぞれVMkernel NICの追加、IPアドレス、サブネットマスク
  # esxcfg-vmknic -a -i <IPアドレス> -n <サブネットマスク> <ポートグループ>

また、デフォルトで使用している「Management Network」というポートグループ名を変更したいので、一度既存のVMkernel NICを削除してからVMkernel NICを再作成する。削除の際に使用する構文とオプションは以下の通り。削除の際はVMkernel NICの名前ではなく所属するポートグループを指定して削除する。

• -d：VMkernel NICを削除
  # esxcfg-vmknic -d <ポートグループ>

実行例

・VMkernel NICを新規に作成
# esxcfg-vmknic -a -i 192.168.11.11 -n 255.255.255.0 Manage_1011

・VMkernel NICのポートグループ変更 (削除して再度作成)
# esxcfg-vmknic -d "Management Network"
# esxcfg-vmknic -a -i 192.168.33.11 -n 255.255.255.0 Manage_33

不要なポートグループ削除

コマンド

デフォルトで作成されるポートグループ「VM Network」と「Management Network」は不要となるため削除する。使用する構文とオプションは以下の通り。

• -D：ポートグループを削除
  # esxcfg-vswitch -D <ポートグループ> <仮想スイッチ>

実行例

# esxcfg-vswitch -D "VM Network" vSwitch0
# esxcfg-vswitch -D "Management Network" vSwitch0

無差別モードを許可する

ESXi on ESXiやHyper-V on ESXiをよく検証で使うことがあるので、無差別モード (プロミスキャスモード) を許可しておく。

コマンド

コマンドはesxcliで可能となる。使用する構文とオプションは以下の通り。

# esxcli network vswitch standard policy security set -p <true or false> -v <仮想スイッチ>

実行例

・設定
# esxcli network vswitch standard policy security set -p true -v vSwitch1

・確認
# esxcli network vswitch standard policy security get -v  vSwitch1
------------------------------
   Allow Promiscuous: true
   Allow MAC Address Change: true
   Allow Forged Transmits: true
------------------------------

設定反映

vSwitchに対する設定は、コマンドを実行するだけでは反映されない (VMware Host Clientで表示されない) ので、以下コマンドで反映を行う。

# esxcli network vswitch standard set -v vSwitch0
# esxcli network vswitch standard set -v vSwitch1

反映後、VMware Host Clientにて仮想スイッチやポートグループが表示されればOK。

・vSwitch0

・vSwitch1

すべてのコマンドを並べてみた

上記一連のコマンドを並べると以下の通り。次回からはこのコマンドを流すだけでESXiの仮想ネットワークの設定が完了する。

# esxcfg-vswitch -a vSwitch1
# esxcfg-vswitch -L vmnic1 vSwitch1
# esxcfg-vswitch -A Manage_33 vSwitch0
# esxcfg-vswitch -A Network_33 vSwitch0

# esxcfg-vswitch -A Manage_1011 vSwitch1

# esxcfg-vswitch -p Manage_1011 -v 1011 vSwitch1
# esxcfg-vswitch -A Network_1011 vSwitch1
# esxcfg-vswitch -p Network_1011 -v 1011 vSwitch1
# esxcfg-vswitch -A Network_1055 vSwitch1
# esxcfg-vswitch -p Network_1055 -v 1055 vSwitch1
# esxcfg-vswitch -A Network_1077 vSwitch1
# esxcfg-vswitch -p Network_1077 -v 1077 vSwitch1
# esxcfg-vmknic -a -i 192.168.11.11 -n 255.255.255.0 Manage_1011
# esxcfg-vmknic -d "Management Network"
# esxcfg-vmknic -a -i 192.168.33.11 -n 255.255.255.0 Manage_33
# esxcfg-vswitch -D "VM Network" vSwitch0
# esxcfg-vswitch -D "Management Network" vSwitch0
# esxcli network vswitch standard policy security set -p true -v vSwitch1
# esxcli network vswitch standard set -v vSwitch0
# esxcli network vswitch standard set -v vSwitch1

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の設定手順なども検証して記載したいと考えている。