[Linux][HA][RHEL] RHELでHAクラスタを組む本来のやり方って？

by

気になったのでやってみた

CentOS環境だと試しにクラスタを構築してmastodon用DBとして稼働を続けているんですが、RHEL環境だとそういえばどうなるんだろう？と思って、ドキュメントを読みながらクラスタの基礎構築までをやってみました。

Red Hat Customer Portal
 
第1章 High Availability Add-On の概要 Red Hat Enterprise Linux 8 | Red Hat Cu...
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_overview-of-high-availability-configuring-and-managing-high-availability-clusters
The Red Hat Customer Portal delivers the knowledge, expertise, and guidance available through your Red Hat subscription.

やっていく中で、割と想定と異なる箇所がちょいちょいあったんで備忘録として残そうと思います。

Subscriptionを適用する

まず必要となるのが、RHELのサブスクリプション適用です。私の場合、昨年頃に一度RHEL8.3のベースイメージをテンプレート化させていたので、これを用いて構築をしています。古いSubscriptionが日もついてると色々面倒なので、これを解除するところから始めています。

■期限切れSubscriptionが存在する場合、情報を削除する
[root@ND001 ~]# subscription-manager remove --all
このシステムから 0 サブスクリプションが削除されました。

[root@ND001 ~]# subscription-manager unregister
このシステムは現在登録されていません。

[root@ND001 ~]# subscription-manager clean
ローカルデータがすべて削除されました

解除が完了したら、改めてRHNに登録をし、Developer Subscriptionを適用しました。
本来はRHEL自体のSubscriptionとは別にHigh-Availability Addonのサブスクリプション適用が必要ですが、私が使用しているDeveloper SubscriptionはこのAdd-onを含んでいるのでこれが登録できればOK。

■Suscriptionの登録
[root@ND001 ~]# subscription-manager register
登録中: subscription.rhsm.redhat.com:443/subscription
ユーザー名: words@bluecore.net
パスワード: 
このシステムは、次の ID で登録されました: 9a0ddf1f-bfa7-4891-a472-24a2db1c2089
登録したシステム名: ND001

■Suscriptionの情報更新
[root@ND001 ~]# subscription-manager refresh
ローカルデータがすべて更新されました

■Suscriptionの適用
[root@ND001 ~]# subscription-manager attach --auto
インストール済み製品の現在の状態:
製品名: Red Hat Enterprise Linux for x86_64
状態:   サブスクライブ済み

パッケージの導入

続いてパッケージを導入するんですが、CentOSと異なるポイントとして、RHELはサブスクリプション単位で使えるリポジトリが細かくわかれています。主なものとしては以下の通り。

  • BaseOS
  • AppStream
  • CodeReady Linux Builder
  • Supplementary
  • HighAvailability Add-on
  • Resilient Storage Add-on

CentOSですと便利なのがEPELなんですが、そうではなくて各種Subscriptionで使用可能なリポジトリを有効化した上でdnfコマンドを実行していくことになります。

■RHEL HAリポジトリの有効化
[root@ND001 ~]# subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms
リポジトリー 'rhel-8-for-x86_64-highavailability-rpms' は、このシステムに対して有効になりました。

そしてインストール

■RHEL HA必要パッケージのインストール
[root@ND001 ~]# dnf -y install pcs pacemaker fence-agents-all
Updating Subscription Management repositories.
......
完了しました!

クラスタの構築

クラスタの構築それ自体はCentOSのときと殆ど変わり有りません。
なおこのとき、/etc/hostsにIPv6アドレスの設定内容が残ってると正常にクラスタセットアップができないようです。「::1」に対する設定を削除することをおすすめします。

■ノード間認証の設定
[root@ND001 ~]# passwd hacluster
ユーザー hacluster のパスワードを変更。
新しいパスワード:
新しいパスワードを再入力してください:
passwd: すべての認証トークンが正しく更新できました。

■PCSdの起動
[root@ND001 ~]# systemctl start pcsd
[root@ND001 ~]# systemctl enable pcsd
Created symlink /etc/systemd/system/multi-user.target.wants/pcsd.service → /usr/lib/systemd/system/pcsd.service.

■PCSdの認証設定実装
[root@ND001 ~]# pcs host auth nd001.bluecore.net
Username: hacluster
Password: 
nd001.bluecore.net: Authorized

[root@ND001 ~]# pcs host auth nd002.bluecore.net
Username: hacluster
Password: 
nd002.bluecore.net: Authorized

■クラスタセットアップ
[root@ND001 ~]# pcs cluster setup cluster-bc-prod --start nd001.bluecore.net nd002.bluecore.net --force
No addresses specified for host 'nd001.bluecore.net', using 'nd001.bluecore.net'
No addresses specified for host 'nd002.bluecore.net', using 'nd002.bluecore.net'
Warning: nd001.bluecore.net: Cluster configuration files found, the host seems to be in a cluster already
Warning: nd002.bluecore.net: Cluster configuration files found, the host seems to be in a cluster already
Destroying cluster on hosts: 'nd001.bluecore.net', 'nd002.bluecore.net'...
nd001.bluecore.net: Successfully destroyed cluster
nd002.bluecore.net: Successfully destroyed cluster
Requesting remove 'pcsd settings' from 'nd001.bluecore.net', 'nd002.bluecore.net'
nd001.bluecore.net: successful removal of the file 'pcsd settings'
nd002.bluecore.net: successful removal of the file 'pcsd settings'
Sending 'corosync authkey', 'pacemaker authkey' to 'nd001.bluecore.net', 'nd002.bluecore.net'
nd002.bluecore.net: successful distribution of the file 'corosync authkey'
nd002.bluecore.net: successful distribution of the file 'pacemaker authkey'
nd001.bluecore.net: successful distribution of the file 'corosync authkey'
nd001.bluecore.net: successful distribution of the file 'pacemaker authkey'
Sending 'corosync.conf' to 'nd001.bluecore.net', 'nd002.bluecore.net'
nd001.bluecore.net: successful distribution of the file 'corosync.conf'
nd002.bluecore.net: successful distribution of the file 'corosync.conf'
Cluster has been successfully set up.
Starting cluster on hosts: 'nd001.bluecore.net', 'nd002.bluecore.net'...
[root@ND001 ~]#

セットアップできたぽいなーと思ったら今度は状態確認を行います。

■構成中はこんな感じ
[root@ND001 ~]# pcs cluster status
Cluster Status:
 Cluster Summary:
   * Stack: unknown
   * Current DC: NONE
   * Last updated: Wed Feb  3 17:58:40 2021
   * Last change:  Wed Feb  3 17:58:30 2021 by hacluster via crmd on nd001.bluecore.net
   * 2 nodes configured
   * 0 resource instances configured
 Node List:
   * Node nd001.bluecore.net: UNCLEAN (offline)
   * Node nd002.bluecore.net: UNCLEAN (offline)

PCSD Status:
  nd001.bluecore.net: Online
  nd002.bluecore.net: Online

■構成完了したらこんな感じ
[root@ND001 ~]# pcs cluster status
Cluster Status:
 Cluster Summary:
   * Stack: corosync
   * Current DC: nd001.bluecore.net (version 2.0.4-6.el8_3.1-2deceaa3ae) - partition with quorum
   * Last updated: Wed Feb  3 17:59:13 2021
   * Last change:  Wed Feb  3 17:58:51 2021 by hacluster via crmd on nd001.bluecore.net
   * 2 nodes configured
   * 0 resource instances configured
 Node List:
   * Online: [ nd001.bluecore.net nd002.bluecore.net ]

PCSD Status:
  nd001.bluecore.net: Online
  nd002.bluecore.net: Online

FloatingIPとかの設定はまだまだ実装できてませんが、クラスタとして最低限の構成はこれで完了です。

STONITHの設定

STONITHについて（Fenceとも言う）

普段、CentOSのTipsとかではよく無効化されるStonithですが、実は商用環境とかだと重要な役割を持ってます。クラスタにはよく「スプリットブレーン」という用語が出てきます。これは、ハートビートと呼ばれる互いの性依存状態を監視するネットワークが損傷を受けた場合に、お互いの生存状況が確認できなくなったので同一時期に同じサービスのリソースがActiveとして動いてしまう現象です。

複数のノードが同じサービスのデータに対して「自分が親玉！」と主張して稼働しようとするため、データ領域を破壊することも確率としては高く、かなーり危ない障害に直結します。

例えばMicrosoft Failover Clusterや東芝のCluster Perfectなどは、ディスクの接続状態をSCSIコマンドで投げ合うことにより「hard排他制御」というものを使って厳密に同時書き込みリスクを抑え込む作りになっています。RedHatのHAクラスタ技術を支える「Pacemaker/Corosync」はこの部分の制御にSTONITHという機能を使用します。

VMware向けStonithデバイス

RedHatのHAクラスタはVMwareの仮想マシンで動作することもサポート内として含まれており、そうした環境に合わせてVMware向けのStonithデバイスが構成できるようになっています。そのときに使うコマンドが「fence_vmware_rest」です。

fence_vmware_restではこんな事ができます。

環境内で動作するVM一覧の取得

[root@ND001 ~]# fence_vmware_rest -a 192.168.200.70 -l administrator@bluecore.local -p ******** --ssl-insecure -z -o list
T-NT4,
S_BLUEIQ,
T7-DURGA,
T7-Craftman,
T-maestro,
T-Commander,
A_Biwa,
P_Anisakis,
Z_HINOKI,
T-REDEYES,
vCLS (4),
vCLS (5),
vCLS (6),
T-WinVDI-Base,
V-ASAGAO,
cp-template-e07a3b58-2711-43e0-97fe-d9127df564f0,
cp-replica-bf819ba4-aeb1-4b99-bf9f-ced8a4f61b17,
haproxy-for-tanzu,
C-ND002,
C-ND001,
T7-ADFS,
M-MAITREYA,
T7_Hikage,

環境内のとあるVMにおける状態の取得

■VMステータスの取得
[root@ND001 ~]# fence_vmware_rest -a 192.168.200.70 -l administrator@bluecore.local -p ******** --ssl-insecure -z -o status -n C-ND001
Status: ON

STONITHデバイスの作成

まず、Corosync設定から、ノードの名前を取得します。

■corosync設定の確認
[root@ND001 ~]# cat /etc/corosync/corosync.conf
totem {
    version: 2
    cluster_name: cluster-bc-prod
    transport: knet
    crypto_cipher: aes256
    crypto_hash: sha256
}

nodelist {
    node {
        ring0_addr: nd001.bluecore.net
        name: nd001.bluecore.net
        nodeid: 1
    }

    node {
        ring0_addr: nd002.bluecore.net
        name: nd002.bluecore.net
        nodeid: 2
    }
}
・・・・・・・（以下略）

ノードリストにある「name: nd00x.bluecore.net」と書かれてるところがクラスタのノード名です。このノード名とVMware側で認識しているVM名をひもつけることが、VMware Stonith Deviceの作成で必要になります。

作成時のコマンドは以下の通りとなります。

■fenceデバイスの設定
[root@ND001 ~]# pcs stonith create vmfence fence_vmware_rest pcmk_host_map="nd001.bluecore.net:C-ND001;nd002.bluecore.net:C-ND002" ipaddr=192.168.200.70 ssl=1 login=administrator@bluecore.local passwd=******** ssl_insecure=1

ここに記載しているpcmk_host_map というところがNode名とVM名をマッピングしている箇所になります。

pcmk_host_map="nd001.bluecore.net:C-ND001;nd002.bluecore.net:C-ND002"

コロンで区切って左辺にノード名、右辺にVM名が書かれている形で、ノード単位にセミコロンで区切られているのが見てわかると思います。こうしてノードとVMの紐付けを行い、実際にどっちのノードが生存しているかをVMware側（今回の場合はvCenterServer)に確認してもらうというのがどうやらVMware Stonithの動きのようです。

状態確認

■fenceデバイスの状態確認
[root@ND001 ~]# pcs stonith show
Warning: This command is deprecated and will be removed. Please use 'pcs stonith status' instead.
  * vmfence     (stonith:fence_vmware_rest):     Started nd001.bluecore.net

[root@ND001 ~]# pcs stonith show vmfence
Warning: This command is deprecated and will be removed. Please use 'pcs stonith config' instead.
 Resource: vmfence (class=stonith type=fence_vmware_rest)
  Attributes: ipaddr=192.168.200.70 login=administrator@bluecore.local passwd=******** pcmk_host_map=nd001.bluecore.net:C-ND001;nd002.bluecore.net:C-ND002 ssl=1 ssl_insecure=1
  Operations: monitor interval=60s (vmfence-monitor-interval-60s)

こうしたSTONITHデバイスを活用することにより、お互いの死活監視が難しくなった場合に、第三者の観点から死活状態を見てもらい「本来どちらがノードとして機能するべきか？」を正確に把握することは、特にこの手のクラスタでは重要になってきますので、理解を深めておいて損はないのかなという気がしますね。

その他やってみたいこと

Active/Passiveでもいいので、共有ストレージクラスタをやりたいなぁと。Microsoft Failover Clusterだと割とお手軽にやれてたんですが、なかなかどうしてLinuxだとあまりやった経験がありませんで、時々やるにしてもDBMSの力を借りたDisk Split型のクラスタを組むことが多いのです。

ただ、SCSI共有バス型のクラスタを組むには、我が家の環境だとNFSデータストアではだめで、何かしら別途iSCSI環境を構成した上で、そこを用いたクラスタ構成を組む必要がありそうです。はてさてどうしたもんかなーと悩み中だったり。

Tags: , , , , , , , , , , ,
PAGE TOP