マルチマスタ構成のOpenstackの構築 pt.1

Pocket

概要

 皆さん、クラウド使ってますか?

 「クラウド」コンピューティングと聞いて多くの人はAWSやGCP、Azureといった大手ITサービスベンダーの製品を思い浮かべるかもしれません。これらのパブリッククラウドは数多くのOSS製品を組み合わせて構成されており、我々一般人でも既存の製品を組み合わせたり手を加えたりすることで再現することができます。

 実際に既製品を用いながら格安に、そしてサービスに使える程度の冗長性を持ったプライベートクラウドを構築していきたいと思います。part1としては冗長構成に必要なvirtual IP addressを付与する為、pacemakerの環境を構築していきます。

前提

 今回はOpenstackを「マルチマスタ構成」として、片系のマスタ(コントローラ)が停止したとしてもサービスが継続できるような構成を目指して組んでいきます。Openstackの企業向けの一般的な構成としては、3ノードからなるマスタノードを用意してMySQLサーバ含む各サービスにアクセスを分散するActive-Activeで構成しているパターンが多いと思います。しかしながら、今回はホームラボなどの家庭環境に設置できるより小規模な構成を目指してActive-Backupを採用していきます。

システム構成図

 Active-Backupのシステムを簡単に実現する方法としては、keepalivedpacemaker, corosyncを利用してVirtual IPを2台のノード間で共有する方法が取られます。今回はpacemakerを利用してVIPを設定して、障害時にVIPを委譲することにより正副の切り替えを行います。

 またこの構成では省略していますが、haproxyを用いることによりOpenstackの各サービスを負荷分散させる構成も取ることができます。

環境情報

今回のセットアップにはUbuntu 20.04 LTSを使用しています。

# cat /etc/os-release
N# cat /etc/os-release | grep VERSION
VERSION="20.04.4 LTS (Focal Fossa)"
VERSION_ID="20.04"
VERSION_CODENAME=focal

 controllerの冗長化に今回使用したpacemaker, corosync, pcs各パッケージのバージョンは下記のとおりです。いずれも2022年1月時点での最新のパッケージです。

# apt list --installed | grep -e pacemaker -e pcs -e corosync

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

corosync/focal-updates,now 3.0.3-2ubuntu2.1 amd64 [installed,automatic]
libcorosync-common4/focal-updates,now 3.0.3-2ubuntu2.1 amd64 [installed,automatic]
libpacemaker1/focal-updates,now 2.0.3-3ubuntu4.3 amd64 [installed,automatic]
libpcsclite1/focal,now 1.8.26-3 amd64 [installed,automatic]
pacemaker-cli-utils/focal-updates,now 2.0.3-3ubuntu4.3 amd64 [installed,automatic]
pacemaker-common/focal-updates,now 2.0.3-3ubuntu4.3 all [installed,automatic]
pacemaker-resource-agents/focal-updates,now 2.0.3-3ubuntu4.3 all [installed,automatic]
pacemaker/focal-updates,now 2.0.3-3ubuntu4.3 amd64 [installed,automatic]
pcs/focal,now 0.10.4-3 all [installed]

pacemaker, corosyncインストール

pacemaker, corosyncおよびpcsとは

pacemaker

 クラスタ構成ソフトウェアの一つで、主にリソース管理や監視、検知等の仕組みを持ちます。単体で使用するのではなく、corosyncやheartbeatなど他のソリューションと組み合わせて使用されます。

corosync

 クラスタ内の各ノードの状態監視を行って、必要に応じて展開されたリソースを他ノードに振り替えるなどの機能を持つクラスタ管理ソフトウェアです。

pcs

 pacemaker configuration systemの略で、pacemaker/corosyncの構成設定を補助する為のソフトウェアです。今回のpacemaker, corosyncのクラスタ環境を構築する為に主に操作するコマンドです。

pacemaker, corosyncパッケージのインストール

 Ubuntu/Debianユーザの方には説明不要ですが、パッケージ管理のaptよりpacemaker, corosync pcsの各パッケージを導入します。RHEL/CentOSユーザの方はyum, dnfに置き換えて実行してください。

# apt install pacemaker corosync pcs
Reading package lists... Done
Building dependency tree
Reading state information... Done

Processing triggers for man-db (2.9.1-1) ...
Processing triggers for mime-support (3.64ubuntu1) ...
Processing triggers for libc-bin (2.31-0ubuntu9.7) ...
Processing triggers for systemd (245.4-4ubuntu3.15) ...

 pacemaker, corosyncおよびpcsの各サービスが、OSのブート時に自動的に起動するように systemdのserviceとして有効化します。Ubuntuのディストリビューションとして提供されるパッケージを使用する限り、systemdのunitファイルは自動的に配置される(/usr/lib/systemd以下に)のでユニットファイルを新規に作成する必要はありません。

# systemctl enable pacemaker corosync pcsd
Synchronizing state of pacemaker.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable pacemaker
Synchronizing state of corosync.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable corosync
Synchronizing state of pcsd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable pcsd

pcsのセットアップ

 pcsからpacemaker, corosyncを設定していきましょう。まずsystemd経由で先程インストールしたpcsのデーモンpcsdを起動します。

# systemctl start pcsd
# systemctl status pcsd
● pcsd.service - PCS GUI and remote configuration interface
     Loaded: loaded (/lib/systemd/system/pcsd.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2022-03-17 07:32:43 UTC; 11min ago
       Docs: man:pcsd(8)
             man:pcs(8)
   Main PID: 39795 (pcsd)
      Tasks: 1 (limit: 77104)
     Memory: 23.3M
     CGroup: /system.slice/pcsd.service
             └─39795 /usr/bin/python3 -Es /usr/sbin/pcsd

Mar 17 07:32:42 controller01-dev systemd[1]: Starting PCS GUI and remote configuration interface...
Mar 17 07:32:43 controller01-dev systemd[1]: Started PCS GUI and remote configuration interface.

 各サービスでノードを指定する際に、一部IPアドレスが指定できない箇所がある為、使用するホスト名とIPアドレスをhostsファイルに記述して、正引きできるようにしておきます。VIP(192.168.60.100)をcontroller-dev、正系(192.168.60.101)をcontroller01-dev、副系(192.168.60.102)をcontroller02-devでそれぞれ対応させました。

 この設定は今回用意した正副の両ノード上で必ず設定してください。

/etc/hosts
192.168.60.100 controller-dev
192.168.60.101 controller01-dev
192.168.60.102 controller02-dev

 pacemaker, corosyncで利用するhaclusterユーザのパスワードを設定していきます。このパスワードは後程使用するので、必ず記録してください。また正副両系で同一のパスワードを設定してください。

# passwd hacluster
New password:
Retype new password:
passwd: password updated successfully

 ここまでは両controller系で設定しますが、次の手順以降は正系のcontroller01-dev上でのみ実行します。pcsより正副両系のhaclusterユーザの認証情報を設定します。ここで設定した内容はcorosyncでのpacemakerの管理やstonithで対向の機器のリソースの停止などに利用されます。

# pcs host auth controller01-dev controller02-dev
Username: hacluster
Password:
controller01-dev: Authorized
controller02-dev: Authorized

 実際にpcsコマンドを使用してクラスタをセットアップしていきましょう。引数として正副両系のホスト名とIPアドレスを指定します。Cluster has been successfully set up.のメッセージが表示されれば、クラスタの起動シーケンスに入りpacemaker, corosyncが自動的に起動します。

 –forceオプションを付加しない場合、既存設定を上書きする形でclusterが展開できない為エラーが出て停止します。また、–startオプションを付与して実行するとclusterの作成時に自動的にpacemakerおよびcorosyncが起動します。

# pcs cluster setup --start controller-dev controller01-dev addr=192.168.60.101 controller02-dev addr=192.168.60.102
Error: Invalid character '=' in node name 'addr=192.168.60.101'
root@controller01-dev:/home/yamashita# ^C
root@controller01-dev:/home/yamashita# pcs cluster setup --start controller-dev controller01-dev addr=192.168.60.101 controller02-de
v addr=192.168.60.102
Destroying cluster on hosts: 'controller01-dev', 'controller02-dev'...
controller02-dev: Successfully destroyed cluster
controller01-dev: Successfully destroyed cluster
Requesting remove 'pcsd settings' from 'controller01-dev', 'controller02-dev'
controller01-dev: successful removal of the file 'pcsd settings'
controller02-dev: successful removal of the file 'pcsd settings'
Sending 'corosync authkey', 'pacemaker authkey' to 'controller01-dev', 'controller02-dev'
controller01-dev: successful distribution of the file 'corosync authkey'
controller01-dev: successful distribution of the file 'pacemaker authkey'
controller02-dev: successful distribution of the file 'corosync authkey'
controller02-dev: successful distribution of the file 'pacemaker authkey'
Sending 'corosync.conf' to 'controller01-dev', 'controller02-dev'
controller01-dev: successful distribution of the file 'corosync.conf'
controller02-dev: successful distribution of the file 'corosync.conf'
Cluster has been successfully set up.
Starting cluster on hosts: 'controller01-dev', 'controller02-dev'...

corosync, pacemakerの正常性確認

 正常にクラスタが構成されたかどうか、実際にpcsコマンドから確認していきましょう。Node Listに正副両系のノードがOnlineとして表示されていれば、両系のノードの状態が正しく取得できていることが確認できます。また現在のDCがどちらになっているかも確認できます。

# pcs status
Cluster name: controller-dev

WARNINGS:
No stonith devices and stonith-enabled is not false

Cluster Summary:
  * Stack: corosync
  * Current DC: controller02-dev (version 2.0.3-4b1f869f0f) - partition with quorum
  * Last updated: Fri Mar 18 09:50:31 2022
  * Last change:  Fri Mar 18 09:50:22 2022 by hacluster via crmd on controller02-dev
  * 2 nodes configured
  * 0 resource instances configured

Node List:
  * Online: [ controller01-dev controller02-dev ]

Full List of Resources:
  * No resources

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

 corosyncコマンドからcorosyncの現在の状態も確認しましょう。各Nodeへの疎通が取れているかどうか等の情報が取得できます。

# corosync-cfgtool -s
Printing link status.
Local node ID 1
LINK ID 0
        addr    = 192.168.60.101
        status:
                nodeid  1:      link enabled:1  link connected:1
                nodeid  2:      link enabled:1  link connected:1

 Active-Backup構成をとる場合、対向機器が正常に停止していない(一部のサービスのみが中途半端に生存する)障害状態がしばしば発生します。この状態では副系に正常に切り替えを行うことが出来ないので、pacemaker/corosyncでは対向機器の生存しているサービスを停止するstonithという機構が実装されています。

 stonithはデフォルトでは有効化状態で、かつ対向ノードを停止させるデバイスが導入されていない状態でセットアップされます。このままだと正常に機能を利用できない為、stonithを停止するか、device(ssh等)をセットアップする必要がります。

 今回は暫定的にstonithを無効化して対応しますが、正副自動切替えを行う場合はdeviceをセットアップしましょう。

# pcs property set pe-warn-series-max=1000 pe-input-series-max=1000 pe-error-series-max=1000 cluster-recheck-interval=5min stonith-enabled=false

Virtual IP addressのresource追加

 クラスタの稼働状態が正常と確認できたので、今度は実際に使用するVirtual IPアドレスをクラスタ上に展開していきます。pcsコマンドでresourceを追加していきましょう。

# pcs resource create vip ocf:heartbeat:IPaddr2 ip="192.168.60.100" cidr_netmask="24" op monito
r interval="30s"

 実際にVirtual IPアドレスがデバイスに付与されているかどうか確認しましょう。予期しないデバイスに付与されている場合は、一旦リソースを削除した上でnic=オプションを追加して再作成してください。

# ip -4 address show dev br300
7: br300: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 192.168.60.101/24 brd 192.168.60.255 scope global br300
       valid_lft forever preferred_lft forever
    inet 192.168.60.100/24 brd 192.168.60.255 scope global secondary br300
       valid_lft forever preferred_lft forever

参考情報


次回はOpenstackの各サービスを稼働させるために必要な、RDBMSやAMQPなどをセットアップしていきます。

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください