Contents
私の経験上でよく見かけたもの
私はもともとWindowsエンジニアとして社会人生活をスタートさせておりまして、わりかし高可用性を追求する構成というのは当時のMicrosoft Cluster Service(MSCS)を使ったHAクラスタが多かったなーと記憶しています。今で言うならMicrosoft Failover Cluster(MSFC)ですね。
Linuxに対しては実はHAを実務で触るケースはそんなに多くなくて、わりかし多いものとしてはディスクスプリット型のクラスタ(例えばPostgreSQLだとStreaming Replicationを使ったもの）が多く、その同期の仕組はDBに頼りつつ、それ単独では担保しきれないFloting-IPなどの仕組みをPacemakerで代替するような、そんな構成を多く見かけます。
ただ、共有ディスク機能がないのか？というと、当然そんなはずはなく。今回Shared-nothing型の共有ボリュームを構成する手順を確認しておくことにしました。前回の記事にて取り扱ったRHEL HighAvailability Add-Onをベースにした環境で試してみようと思います。
構成概要
今回は前回の記事で作成した2ノード構成に対して、Storageセグメント側のNICをそれぞれ追加し、JumboFrameにてストレージのiSCSIインタフェースに接続します。なお、iSCSIターゲット側に関する記載は一切を割愛します。
構成手順
iSCSI接続のための諸々の準備
まずはクラスタノードに対してiSCSI接続に必要となるパッケージの導入と、必要な設定を実施します。もちろん両ノードでやることになります。
■iSCSIイニシエータツールのインストール
[root@ND001 ~]# dnf install iscsi-initiator-utils -y
■イニシエータのIQNを確認
[root@ND001 ~]# cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1994-05.com.redhat:6fccead6b33a
■iSCSI上のターゲットに対してDiscoveryを行う
[root@ND001 ~]# iscsiadm -m discovery -t st -p 192.168.110.20
192.168.110.20:3260,1 iqn.1992-04.com.emc:cx.virt2020bn657m.a0
■iSCSIターゲットにログインする
[root@ND001 ~]# iscsiadm -m node -T iqn.1992-04.com.emc:cx.virt2020bn657m.a0 -l
Logging in to [iface: default, target: iqn.1992-04.com.emc:cx.virt2020bn657m.a0, portal: 192.168.110.20,3260]
Login to [iface: default, target: iqn.1992-04.com.emc:cx.virt2020bn657m.a0, portal: 192.168.110.20,3260] successful.
■iSCSIターゲット間の接続をリスキャンする
[root@ND001 ~]# iscsiadm -m session --rescan
Rescanning session [sid: 1, target: iqn.1992-04.com.emc:cx.virt2020bn657m.a0, portal: 192.168.110.20,3260]
無事にiSCSI接続ができるようになると、以下のようなログを確認することができるようになります。
■/var/log/messages上でKernelログとして記録される。
UnityVSAの場合、まずコントローラが先に認識され、ここでは/dev/sdbとして割り当てられている。
実際のボリュームは/dev/sdcとして割り当てられる。
iSCSIイニシエータはHBA番号33として認識されている。
------
Feb 4 16:21:55 ND001 kernel: sd 33:0:0:0: [sdb] Attached SCSI disk
Feb 4 17:16:50 ND001 kernel: sd 33:0:0:0: Power-on or device reset occurred
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:0: [sdb] Read Capacity(16) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:0: [sdb] Sense Key : Illegal Request [current]
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:0: [sdb] Add. Sense: Logical unit not supported
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:0: [sdb] Sense Key : Illegal Request [current]
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:0: [sdb] Add. Sense: Logical unit not supported
Feb 4 17:33:08 ND001 kernel: scsi 33:0:0:1: Direct-Access DGC VRAID 4000 PQ: 0 ANSI: 6
Feb 4 17:33:08 ND001 kernel: scsi 33:0:0:1: alua: supports implicit and explicit TPGS
Feb 4 17:33:08 ND001 kernel: scsi 33:0:0:1: alua: device naa.600601608971a028e99d1b60c51b87a0 port group 1 rel port 1
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:1: Attached scsi generic sg3 type 0
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:1: Power-on or device reset occurred
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:1: alua: transition timeout set to 60 seconds
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:1: alua: port group 01 state A preferred supports tolUsNA
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:1: [sdc] 209715200 512-byte logical blocks: (107 GB/100 GiB)
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:1: [sdc] Write Protect is off
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:1: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:1: [sdc] Optimal transfer size 4194304 bytes
Feb 4 17:33:08 ND001 kernel: sd 33:0:0:1: [sdc] Attached SCSI disk
パーティション設定
こうして無事に接続できたボリュームに対して、これからパーティションを切っていくことになります。まずは念の為に/dev/sdcの存在を確認します。
■fdisk -l の結果
この状態でfdiskを実行すると以下のように/dev/sdc が認識されていることが分かる。
ディスク /dev/sdc: 100 GiB, 107374182400 バイト, 209715200 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 8192 バイト / 4194304 バイト
できてたのを確認したら、/dev/sdcに対してfdiskを実行し、パーティションを作成します。
■fdisk /dev/sdc の実行からのLVM領域作成
コマンド (m でヘルプ): n->Enter押下
パーティションタイプ
p 基本パーティション (0 プライマリ, 0 拡張, 4 空き)
e 拡張領域 (論理パーティションが入ります)
選択 (既定値 p): <そのままEnter>
既定の回答 p であるものとみなします。
パーティション番号 (1-4, 既定値 1): <そのままEnter>
最初のセクタ (8192-209715199, 既定値 8192): <そのままEnter>
最終セクタ, +セクタ番号 または +サイズ{K,M,G,T,P} (8192-209715199, 既定値 209715199): <そのままEnter>
新しいパーティション 1 をタイプ Linux、サイズ 100 GiB で作成しました。
コマンド (m でヘルプ): t->Enter押下
パーティション 1 を選択
16 進数コード (L で利用可能なコードを一覧表示します): 8e->Enter押下
パーティションのタイプを 'Linux' から 'Linux LVM' に変更しました。
コマンド (m でヘルプ): w->Enter押下
パーティション情報が変更されました。
ioctl() を呼び出してパーティション情報を再読み込みします。
ディスクを同期しています。
ここでミソなのは、パーティションタイプをLinuxではなく、LVMにすることぐらいかなぁ・・と思われます。
LVM上での領域定義を実施
LVMを使ってPV/VG/LVを登録します。
■LVMによる領域作成
[root@ND001 ~]# pvcreate /dev/sdc1
Physical volume "/dev/sdc1" successfully created.
[root@ND001 ~]# vgcreate my_cls_vg /dev/sdc1
Volume group "cls_vg" successfully created
[root@nd001 ~]# lvcreate -n cls_lva cls_vg -l 100%FREE
Logical volume "cls_lva" created.
LVMの設定対象をローカルディスクと共有ディスクに絞る
/etc/lvm/lvm.confの修正を行います。
# vi /etc/lvm/lvm.conf
-----
# This configuration option does not have a default value defined.
volume_list = [ "rhel", "cls_vg" ]
属性確認を念の為行います。
■LVMの属性確認
[root@nd001 pacemaker]# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
cls_lva cls_vg -wi-a----- 99.99g
root rhel -wi-ao---- 74.00g
swap rhel -wi-ao---- 3.96g
->cls_lvaのAttributeを確認して、属性aが付与されてたら取り敢えず大丈夫そう。
共有ボリュームのフォーマット
ext4ファイルシステムによってフォーマットを行います。
■EXT4ファイルシステムの作成
[root@nd001 pacemaker]# mkfs.ext4 /dev/mcls_vg/cls_lva
mke2fs 1.45.6 (20-Mar-2020)
Discarding device blocks: 4096/26212352 528384/26212352 1576960/26212352 2625536/26212352 3674112/26212352 4198400/26212352 5246976/26212352 6295552/26212352 6819840/26212352 7868416/26212352 8392704/26212352 9441280/2621235210489856/2621235211538432/2621235213111296/2621235213635584/2621235214684160/2621235215732736/2621235216781312/2621235217829888/2621235218878464/2621235219927040/2621235220451328/2621235221499904/2621235222548480/2621235224121344/2621235224645632/2621235225694208/26212352 done
Creating filesystem with 26212352 4k blocks and 6553600 inodes
Filesystem UUID: caf00564-80b5-4ddd-8806-0bb65f25e555
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
Allocating group tables: 0/800 done
Writing inode tables: 0/800 done
Creating journal (131072 blocks): done
Writing superblocks and filesystem accounting information: 0/800 done
共有ボリュームをクラスタリソースとして適用
エージェント「ocf:hearteat:LVM-activate」を使用してクラスタリソースを登録します。
これにより、作成したLVM VGはVG丸ごとクラスタリソースとして登録されることになります。
■クラスタボリュームとして適用
[root@nd001 pacemaker]# pcs resource create cls_vol ocf:heartbeat:LVM-activate vgname=cls_vg activation_mode=exclusive vg_access_mode=system_id --group clsgroup
状態確認をすると以下のようになります。
[root@nd001 pacemaker]# pcs status
Cluster name: cluster-bc-prod
Cluster Summary:
* Stack: corosync
* Current DC: nd001.bluecore.net (version 2.0.4-6.el8_3.1-2deceaa3ae) - partition with quorum
* Last updated: Fri Feb 5 09:55:00 2021
* Last change: Fri Feb 5 09:54:51 2021 by root via cibadmin on nd001.bluecore.net
* 2 nodes configured
* 2 resource instances configured
Node List:
* Node nd002.bluecore.net: standby
* Online: [ nd001.bluecore.net ]
Full List of Resources:
* vmfence (stonith:fence_vmware_rest): Started nd001.bluecore.net
* Resource Group: clsgroup:
* cls_vol (ocf::heartbeat:LVM-activate): Started nd001.bluecore.net
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
ファイルシステムリソース/IPアドレスリソースの追加
ファイルシステムリソースを追加します。
[root@nd001 pacemaker]# pcs resource create cls_vfs Filesystem device="/dev/cls_vg/cls_lva" directory="/data" fstype="ext4" --group clsgroup
Assumed agent name 'ocf:heartbeat:Filesystem' (deduced from 'Filesystem')
上記を実行する前に、各ノードで/dataディレクトリを作成しています。
続いてIPアドレスリソースを追加します。
[root@nd001 pacemaker]# pcs resource create VirtualIP IPaddr12 ip=192.168.120.229 cidr_netmask=24 --group clsgroup
Assumed agent name 'ocf:heartbeat:IPaddr2' (deduced from 'IPaddr2')
なお、Assumed agent name…となにかメッセージが出力されていますが、これは「正式にはこういうリソース名称だよ！」というメッセージのようで、LVM Activationリソースなんかそうでしたが、総称で書くのが本当は良いようで、それに添えるようにクラスタの書式も変わってきてるようですよ。
状態確認をするとこんな感じに。
[root@nd001 pacemaker]# pcs status
Cluster name: cluster-bc-prod
Cluster Summary:
* Stack: corosync
* Current DC: nd001.bluecore.net (version 2.0.4-6.el8_3.1-2deceaa3ae) - partition with quorum
* Last updated: Fri Feb 5 09:58:17 2021
* Last change: Fri Feb 5 09:58:07 2021 by root via cibadmin on nd001.bluecore.net
* 2 nodes configured
* 4 resource instances configured
Node List:
* Node nd002.bluecore.net: standby
* Online: [ nd001.bluecore.net ]
Full List of Resources:
* vmfence (stonith:fence_vmware_rest): Started nd001.bluecore.net
* Resource Group: clsgroup:
* cls_vol (ocf::heartbeat:LVM-activate): Started nd001.bluecore.net
* cls_fs (ocf::heartbeat:Filesystem): Started nd001.bluecore.net
* VirtualIP (ocf::heartbeat:IPaddr2): Started nd001.bluecore.net
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
これでクラスタリソースとして最低限の構成ができた状態になります。
クラスタとしての動作詳細について
色々面倒だったのでPowerPointで作成の後、PDF化してSpeakerDeckに貼り付けました。
あんまり深くまで掘りきれてませんが、ある意味脳のリハビリ的なネタだと思ってみてもらえれば幸いです。