Contents
気になったのでやってみた
CentOS環境だと試しにクラスタを構築してmastodon用DBとして稼働を続けているんですが、RHEL環境だとそういえばどうなるんだろう?と思って、ドキュメントを読みながらクラスタの基礎構築までをやってみました。
やっていく中で、割と想定と異なる箇所がちょいちょいあったんで備忘録として残そうと思います。
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環境を構成した上で、そこを用いたクラスタ構成を組む必要がありそうです。はてさてどうしたもんかなーと悩み中だったり。