
こんにちは、サイオステクノロジーでLifeKeeperのプリセールスを担当している宇野です。
LifeKeeper for Linux9.5.0より強化された、LifeKeeperのCLI(コマンドラインインターフェイス)とAnsibleを使って、PostgreSQLの冗長構成をVMware上に構築してみました。今回、その手順を共有いたします。
- 1. はじめに
- 2. Ansibleで冗長化構成を構築するメリット
- 3. Playbookの構成
- 4. 環境
- 5.手順
- 5-1. Ansible playbookファイルツリー
- 5-2. inventory
- 5-3. main.yml
- 5-4. varsディレクトリ
- 5-5. 仮想マシンテンプレートのデプロイ / vmwareディレクトリ
- 5-6. LifeKeeperのインストール / lk_installディレクトリ
- 5-7. コミュニケーションパスの作成/ commpathディレクトリ
- 5-8. パーティションの作成、Broadcast ping の無効化、PostgreSQL Serverのインストール
- 5-9. DataKeeperリソース、IPリソース、PostgreSQLリソースの作成と拡張、依存関係の構築
- 6. Ansible playbookによる自動化を実行
1. はじめに
HAクラスタソフトであるLifeKeeper for Linux をAnsibleで自動構築したい、という要望を以前よりたくさんいただいておりました。この背景には、50ノード(25クラスター)を数えるような、大規模なHAクラスター案件での導入が増えているためで、ほぼ同じ構成をいくつも構築しなければならず、なんとか効率化したいというものでした。
2020年5月にリリースした、LifeKeeper for Linux v9.5.0にて、従来提供していたCLIを刷新し、Ansibleなどを使って、より簡単に操作できるようにいたしました。今回、VMware環境上に、PostgreSQLを冗長化する構成をAnsibleで構築してみましたので、ぜひご参考ください。
2. Ansibleで冗長化構成を構築するメリット
構築に入る前に、そもそもAnsibleで冗長化構成を構築すると何が嬉しいのかを、自身の経験も含めて改めて整理してみました。主に以下3つに集約されるかなと思います。
- 手作業に比べ、構築時間が大きく削減できる
- 構築時の設定ミスや作業漏れを防げ、構築品質を平準化しやすい
- 大量のクラスタノード構築時にチェック作業を大幅に簡素化できる
従来の手作業による構築と比べてどう嬉しいのか、もっと具体的に言うとこのようになります。
手動構築と自動構築の比較
手動構築 | Ansibleで自動構築 | |
---|---|---|
1.構築時間(コスト) | 約2時間 | 約13分 |
2.構築品質 | 構築者の技量によってバラつき | 誰が行っても一定の品質 |
3.チェック作業 | 作業漏れがないよう 毎回チェックシートの運用が必要 | 1回目の確認で漏れが無ければ、 2回目以降のチェックはほぼ不要 |
やはり、なんといっても構築時間の短縮です。今回のケースでは、構築時間が約1/9となりました。同様の構成の場合、ノード数が増えれば増えるほどこの効果が高まります。加えてお伝えしたいのが、構築の品質とチェック作業です。私も長年LifeKeeper for Linux の導入作業には携わってきましたが、設定ミスや運用時の作業漏れが無いか、チェック体制やパラメータの管理は大丈夫か、など、大変気を遣う作業が多いです。そのため、構築品質と構築効率の向上は、現場のエンジニアにとっても大変嬉しい話なのではないかと考えます。
なお、Ansibleを使った自動構築のやってみた記事として、仮想環境でのPacemaker, Corosync, DRBDの自動構築もございますので、合わせてご参考ください。
3. Playbookの構成
前置きが長くなりましたが、以降、仮想マシンテンプレートからデプロイ、LifeKeeper for Linux の導入、リソースの作成などをAnsibleで自動化していきます。
ご紹介する手順は2ノードクラスターを構築するplaybookになっていますが、複数クラスターを自動的に構成することも想定しています。そのため以下のような処理を行うplaybookの作成を試みました。
- 1つのVMテンプレートから2ノード分デプロイ
- 各ノードを任意のホスト名、IPアドレスへ変更
- LifeKeeper for Linuxのインストール準備
- LifeKeeper for Linuxのインストール
- コミュニケーションパスの作成
- ミラーリング用ディスクの準備
- PostgreSQLのインストール
- IP, DataKeeper, PostgreSQLリソースの作成
- PostgreSQL, IPリソースの依存関係作成
4. 環境
今回利用したVMware環境、Ansibleサーバー、テンプレートイメージを以下に紹介します。
*4章以降で紹介するコマンドラインは全てrootユーザーで実行しています。
4-1. VMware ESXi Server
ハイパーバイザー | VMware ESXi, 7.0.0, 15843807 | 2台 |
VMware vCenter Server Appliance | 7.0.0.10100 | 1VM |
共有ストレージ | VMFS6 | 1台 |
仮想マシン | 1台 | |
仮想マシンテンプレート | 1台 |
4-2. Ansibleサーバー
Ansible管理サーバー 仮想マシン | CPU | 1CPU |
メモリ | 2GB | |
ハードディスク | 16GB X1 | |
ネットワークアダプタ | ens192(10.0.0.1/16) ens224(192.168.0.1/24) | |
互換性 | ESXi7.0以降(VMバージョン17) | |
OS | CentOS8.2 | |
追加アプリケーション | python3-pip, pyVmomi |
AnsibleでVMwareの管理を行うときはpyVmomiを使用します。pyVmomiはVMware vSphere API の公式の Python SDK であり、VMware環境の管理で必要なPython SDKです。pyVmomiはpipを使用して導入します。そのためAnsibleサーバーには以下のパッケージを追加でインストールします。
dnf install python3-pip |
追加したpipを使用してpyVmomiをインストールします。
/usr/bin/pip3.6 install ansible pyvmomi |
以下はLifeKeeper for Linux のインストールに利用するインストールイメージやレスポンスファイル、ライセンスファイルです。Ansibleサーバーから各ノードにコピーして使用しますので、事前に/root/siosディレクトリを作成して以下のようにファイルを保管します。
LKCONF:LifeKeeper のインストール用のレスポンスファイル。LifeKeeper for Linuxを自動インストールで利用するテンプレートファイルです。以下のように事前に作成して保管します。
1.以下のダウンロード先から create_response_file スクリプトを入手してください。
自動インストール用設定 作成ツール
2.レスポンスファイルのファイル名を指定して、create_response_file スクリプトを実行します。
./create_response_file /root/lifekeeper/LKCONF |
3.create_response_file スクリプトを起動すると、以下のメニュー画面が表示されます。
4. 必要な設定を選択してださい。
- Install Java Runtime (JRE) の選択
- Recovery Kit Selection Menu でインストールする Recovery Kit の選択
5. 設定後、< Done > を選択してください。その後、< Yes > を選択し終了します。
6. 生成された LKCONF ファイルを確認し、設定が正しいことを確認してください。以下はPostgreSQL Recovery Kits、DataKeeper for Linux Recovery Kits を選択した場合のレスポンスファイルです。今回は以下の内容のファイルを作成して使用しました。
# LifeKeeper setup response file # DO NOT EDIT MANUALLY LKCONF_INSTALL_JRE=”y” LKCONF_SELONLY=”y” LKCONF_AUTH=”y” LKCONF_LKUSER_lkadmin=”root” LKCONF_steeleye_lkPGSQL=”y” LKCONF_steeleye_lkDR=”y” |
20210120lkl-evalkeys-30day.txt:評価版ライセンスファイル。ライセンスファイルはどのようなファイル名でも問題ありません。適用するライセンスをホスト名毎のディレクトリを作成して保管してください。
sps_951.img:LifeKeeper for Linux 9.5.1インストールイメージです。ISOイメージの中に保管されています。
4-3.テンプレート
クラスターノード用仮想マシンテンプレート | CPU | 1CPU |
メモリ | 2GB | |
ハードディスク | 16GB X1 10GB X1 (/dev/sdb) | |
ネットワークアダプタ | ens192(10.0.0.1/16) ens224(192.168.0.100/24) | |
互換性 | ESXi7.0以降(VMバージョン17) | |
OS | CentOS7.9 | |
追加作業 | Ansible管理用OSの公開キーを登録 |
今回の構成では以下の準備を行ってから、テンプレートに変換します。
- Ansible管理用サーバーからクラスターノードにsshで接続して設定を行います。その際にパスワードの入力が不要となるようVMテンプレートに対してAnsible管理用サーバーのssh公開キーを登録します。
- ネットワーク経路は2経路用意してください。それぞれAnsible管理用サーバーの各NICから接続できる同じネットワークセグメントのIPアドレスを設定します。
- ディスクは2種類用意しましたが、/dev/sdbにあたる10GBのディスクはレプリケーションで使用します。OSのインストール時には使用しないでください。
- OSのインストールは最小のパッケージ(minimal-environment)で行っています。必要なパッケージはLifeKeeperインストール時に自動的にインストールを行いますので、yumが利用可能な状態にしてください。
- 仮想マシンテンプレートは2台のESXiホストのどちらからでもアクセスできるよう共有ディスク(VMFS6)に配置してください。
構成図としては以下のようなイメージです。
5.手順
複数クラスターへのデプロイの自動化へと応用できるように、デプロイ元の仮想マシンテンプレートを1つだけとしました。デプロイ後にホスト名、IPアドレスを変更してクラスターノードとして利用します。
以下の手順のplaybookを作成しました。それぞれ紹介します。
- VMテンプレートからnode1をデプロイ
- node1のホスト名、IPアドレスを変更
- VMテンプレートからnode2をデプロイ
- node2のホスト名、IPアドレスを変更
- LifeKeeper for Linuxのインストール
ライセンスの適用、LifeKeeper for Linuxの起動
コミュニケーションパスの作成 - ミラーリング用ディスクの準備
Broadcast pingをオフに変更
PostgreSQLのインストール、DBの作成 - DataKeeperリソースの作成
- IPリソースの作成
- PostgreSQLリソースの作成
PostgreSQLリソースとIPリソースの依存関係作成
5-1. Ansible playbookファイルツリー
今回の処理を行うplaybookファイルのツリー構造です。以下のファイルツリー構造で各処理が行われるようにメインのPlaybookファイル”main.yml”が作成されています。
ファイルの役割は以下です。
5-2. inventory
Ansibleサーバーが接続するグループを指定します。playbookで指定したhostsカラムで指定したグループに対してタスクを実行します。
[local] [nodes] [node1] [node2] [template] |
5-3. main.yml
ansible_playbookコマンドで直接指定するYAMLフォーマットのplaybookファイルです。内部では処理毎にタスク分けされていて必要なファイルを呼び出してそれぞれの処理を行います。以下のファイルを指定することでVMのデプロイからリソースの依存関係作成までの処理が行われる内容になっています。なお各処理のタイトルを表示するのが”– name:” の項目ですが、タイトルが日本語だったり英語だったり統一感はないです。ご了承ください。
– name: Create Virtual Machine(Source node) – name: Edit Primary IP and Hostname(Source node). – name: Edit Secondary IP(Source node). – name: Create Virtual Machine(Target node) – name: Edit Primary IP and Hostname(Target node). – name: Edit Secondary IP(Target node). – name: deploy and install lifekeeper on all targets – name: create communication path on source – name: create communication path on target – name: create partition – name: Broadcast ping off/Install postgreSQL server and create DB. – name: Create Resources.(DataKeeper, IP, PostgreSQL) |
実際に実行する際は以下のようにコマンドを実行します。
ansible-playbook main.yml -i inventory |
5-4. varsディレクトリ
playbookの中で呼び出される変数を定義したファイルを保管するディレクトリです。playbook内でinclude_varsカラムを指定して利用されます。
- vars/disk_info.yml
DataKeeperリソース関連の変数を定義しています。
# レプリケーション用デバイス |
- vars/network_info.yml
各ノードで共通のネットワーク情報を変数として定義しています。
# プライマリIPアドレスNIC |
- vars/pgsql_info.yml
PostgreSQLリソースを作成するために必要な情報を変数として定義しています。
# postgresql server port. |
- vars/template_node1_info.yml
VMをデプロイする際にnode1(アクティブノード)として変換するために必要な情報を変数として定義しています。
# 作成するVM Name |
- vars/template_node1_info.yml
VMをデプロイする際にnode2(スタンバイノード)として変換するために必要な情報を変数として定義しています。
# 作成するVM Name |
- vars/vip_info.yml
IPリソースを登録するために必要な情報を変数として定義しています。
# 仮想IPアドレス |
- vars/vmware_info.yml
IPリソースを登録するために必要な情報を変数として定義しています。
# vCenter ホスト |
- vars/works.yml
LifeKeeperをインストールするために必要な準備をするための情報を変数として定義しています。firewallは有効な状態で最低限のポートを有効にします。postgresqlで使用する5432も開けていません。必要な場合はlk_portに追記してください。
# control-node側でインストールに必要なファイルを保存しておくディレクトリ |
5-5. 仮想マシンテンプレートのデプロイ / vmwareディレクトリ
main.ymlファイルは上から順番に読み込まれます。最初はvmwareディレクトリ内にある処理を実行します。ここではVMを2台作成して、それぞれのホスト名、IPアドレスの変更が行われます。なおansibleで接続先のIPアドレスの変更した場合セッションが途切れてしまう問題を引き起こします。
この問題を回避するため、クラスターシステムの特性でもある異なる複数のネットワーク構成を活用しています。1回目の接続ではNIC2から接続を行い、NIC1,hostnameの変更を行います。2回目の接続でNIC2のIPアドレスを変更して、以降の処理は変更したNIC1への接続を使用します。ただこの処理はIPアドレスの重複を避けるためシーケンシャルに実行しますのでPlaybook(main.yml)の内容は以下のように冗長になります。
- アクティブノード用のVMの作成
- アクティブノード用プライマリIPアドレス、ホスト名の変更(接続はNIC2から).
- アクティブノード用セカンダリIPアドレスの変更(接続はNIC1から).
- スタンバイノード用のVMの作成
- スタンバイノード用プライマリIPアドレス、ホスト名の変更(接続はNIC2から).
- スタンバイノード用セカンダリIPアドレスの変更(接続はNIC1から).
main.ymlの処理では以下に該当します。
上記で読み込まれるvmwareディレクトリ内のPlaybookファイルを説明します。
- deploy_guestvm.ym
仮想マシンテンプレートを使用してデプロイするplaybookです。
– name: vCenterに接続してVMを作成 |
- edit_priip_hostname.yml
プライマリIPアドレスとホスト名の変更を行うplaybookです。この処理を行う際はセカンダリIPアドレスに接続して行います。
– name: プライマリIPアドレスの変更 – name: プライマリIPアドレスの更新 – name: ホスト名 “{{ new_hostname }}”への変更. |
- edit_secip.yml
セカンダリIPアドレスの変更を行うplaybookです。この処理を行う際は上記のplaybookで変更したプライマリIPアドレスに接続して行います。
– name: プライマリIPアドレスの変更 – name: プライマリIPアドレスの更新 – name: ホスト名 “{{ new_hostname }}”への変更. |
5-6. LifeKeeperのインストール / lk_installディレクトリ
lk_installディレクトリはLifeKeeper for Linuxのインストールの準備、インストール、LifeKeeperの起動までの手順となります。これらの手順はLifeKeeper for Linuxのテクニカルドキュメント(以下のURL)で公開していますので、テクニカルドキュメントの内容をベースにして手順を作成しています。
https://docs.us.sios.com/spslinux/9.5.1/ja/topic/setting-up-lifekeeper-with-ansible
main.ymlの中では以下の処理が該当します。
lk_installディレクトリには以下のファイルが保管されています。
- hosts.yml
hosts.ymlはLifeKeeper for Linux のインストールに必要な名前解決の設定を各ノードに対して行います。最低限の登録としてアクティブノードとスタンバイノードのみ追加します。
# /etc/hostsにansibleを実行対象のホストをすべて登録する |
- firewall.yml
firewall.ymlはLifeKeeper for Linux のインストールに必要なポートをオープンにします。lk_portはvars ディレクトリ内でリストとして登録されていますので、追加でオープンしたいポートの追加も容易に可能です。
– name: enable lifekeeper port – name: reload |
なお今回はGUIを使用する想定では無いため、LifeKeeper for Linuxで利用するGUI関連のポートは公開していません。GUIを利用する予定がある場合は以下を参考にGUI関連のポートもオープンしてください。
[Linux]LifeKeeperが使用するポート
https://lkdkuserportal.sios.jp/hc/ja/articles/360037514152
- selinux.yml
selinux.ymlはselinuxの設定を”disable”に変更します。変更後にシステムの再起動を行います。既に設定済みの場合は変更されませんので再起動も発生しません。
– name: disable SELinux – name: reboot a node |
- deploy.yml
deploy.ymlはLifeKeeperに必要なインストールイメージ、ライセンスファイルをノードにコピーします。またCentOS7.9でDataKeeperを使用するために必要なPatchをダウンロードします。
– name: deploy to lifekeeper install files – name: Download DataKeeper patch for CentOS 7.9 |
ダウンロードするpatchは以下にリンクがあります。詳細は以下を確認してください。
https://lkdkuserportal.sios.jp/hc/ja/articles/900003788726
- mount.yml
mount.ymlはLifeKeeperに必要なインストールイメージ、ライセンスファイルをノードにコピーします。
– name: mount setup image |
- install.yml
install.ymlはLifeKeeper for Linuxのインストールを行います。
– name: install lifekeeper |
- bash_profile.yml
bash_profile.ymlはLifeKeeperのコマンドファイルのPATHやMANページファイルのMANPATHを/root/.bash_profileに追加します。
– name: update lifekeeper PATH in bash_profile |
- license.yml
license.ymlはLifeKeeperのライセンスを各ノードにインストールするplaybookです。
– name: install lifekeeper license |
- lkstart.yml
lkstart.ymlはLifeKeeperを実行するplaybookです。
– name: start lifekeeper – name: lifekeeper status – name: Show communication path(Source). |
- clean.yml
clean.ymlはLifeKeeperをインストールするにあたり使用した一時ファイルを削除します。
– name: unmount a mounted lifekeeper image – name: delete lifekeeper files |
5-7. コミュニケーションパスの作成/ commpathディレクトリ
commpathディレクトリには、コミュニケーションパスの作成を作成するためのplaybookが保管されています。main.ymlからは以下で読み込まれてコミュニケーションパスを作成します。コミュニケーションパスの作成は各ノード(ソース、ターゲット)からコミュニケーションパスを作成するコマンドを実行する必要があります。
ディレクトリ内のplaybookファイルを紹介します。
- add_source_compath.yml
コミュニケーションパスは2経路作成します。ソースノードから実行しただけではコミュニケーションパスの作成は完了しません。
– name: Create primary communication path(Source). – name: Create secondary communication path(Source). |
- add_target_compath.yml
ターゲットノードからも実行することでコミュニケーションパスがActiveになります。コミュニケーションパスのステータスの確認を行うコマンドを実行して表示します。
– name: Create primary communication path(Target). – name: Create secondary communication path(Target). – name: Check communication paths. – name: Show communication paths. |
5-8. パーティションの作成、Broadcast ping の無効化、PostgreSQL Serverのインストール
main.ymlの以下の項目では、リソース作成の準備を行っています。前半の項目ではDataKeeperリソースで利用するGPTパーティションを作成します。後半の項目では、Broadcast pingを無効化する設定を行い、PostgreSQL serverパッケージのインストールを行います。この項目は全て両ノードに対して行う処理となるため、まとめて行っています。
各ファイルは次の項目でまとめて紹介します。
5-9. DataKeeperリソース、IPリソース、PostgreSQLリソースの作成と拡張、依存関係の構築
ここでは各リソースを作成して、依存関係を構築します。この項目で実施するコマンドは全てアクティブノードからのみの実行となります。
各タスクを実行するplaybookファイル紹介します。
DataKeeperリソースを構築するために必要なplaybookファイル
IPリソースを構築するために必要なplaybookファイル
PostgreSQLリソースを構築するために必要なplaybookファイル
依存関係を作成するplaybookファイル
- disk.yml
/dev/sdbにGPTパーティションを作成します。
– name: “parted {{ disk_device }}” – name: “format {{ disk_device }}{{ disk_num }}” |
- new_replication.yml
作成したパーティションを使用してDataKeeperリソースを作成します。今回はファイルシステムのフォーマットを行う“Replicate New File System”でのリソース作成です。
– name: Create DataKeeper resource. – name: Extend DataKeeper resource. – name: Check resources. – name: Show Resource tree. |
- nobcastping.yml
今回の環境ではbroadcast ping に応答するホストが無いため、事前にIPリソースの機能であるBroadcast pingの無効化を行うパラメータを設定します。/etc/default/LifeKeeper ファイル内のパラメータ”NOBCASTPING=1”の設定を行います。
– name: ブロードキャストPINGの無効化 |
- ip_resource.yml
コマンドラインでIPリソースを作成します。Broadcast pingを無効化している為、unicast ping による確認先IPアドレスの設定も行います。
– name: Create IP resource. – name: Config IP resource. – name: Extend IP resource. – name: Check resources – name: Show Resource tree. |
- inst_pgsql.yml
postgresql-server パッケージのインストールを行います。
– name: install postgresql-server. |
- inst_pgsql.yml
DataKeeperリソースで保護したディレクトリ内にデータベース用ディレクトリを作成して、データベースの初期化を行い起動します。
– name: “データベース用ディレクトリの作成“ – name: “データベース有無の確認“ – name: “データベースの初期化“ – name: “データベースの起動“ |
- pgsql_resource.yml
PostgreSQLリソースを作成します。作成後にリソース状況を表示します。
– name: Create postgresql resource. – name: Extend postgresql resource. – name: Check resources. – name: Show Resource tree. |
6. Ansible playbookによる自動化を実行
それでは作成したplaybookを使用してVMの作成、LifeKeeperのインストール、リソース構築を行ってみます。
6-1. 実行前の環境
仮想マシン環境には以下のように2台のVMしかない状態です。
テンプレートには今回利用する”dbv-temp79”を配置します。
6-2. ansible-playbookコマンドの実行
ansible-playbookコマンドでplaybookファイルとホストを指定するinventory ファイルを指定して実行します。
ansible-playbook main.yml -i inventory |
自動的に処理が行われます。まずはvCenterへの接続をしてアクティブノード(Source node)をデプロイします。その後IPアドレス、ホスト名の変更をします。
続いてスタンバイノード(Target node)を展開します。ホスト名、IPアドレスも変更します。
次はLifeKeeperのインストール処理に入ります。ここでは/etc/hostsファイルの編集とファイアフォールの設定変更を行っています。
LifeKeeperのインストールの続きです。SELinuxをdisableに変更してインストールに必要なファイルの転送、LifeKeeperのインストールを行います。
LifeKeeperのライセンスの適用を行い、LifeKeeperを起動します。
LifeKeeperのインストール処理はアンマウントと不要なファイルを削除して終了します。
LifeKeeperのインストールが完了するとコミュニケーションパスの作成を行います。コミュニケーションパスのステータスがDEADになっていますが、ALIVEまでに時間がかかる影響です。
パーティションの作成、ブロードキャストPINGの無効化、PostgreSQLのインストールなど、リソース作成の前処理が行われます。
リソース作成所に入ってきます。最初はDataKeeperリソースを作成します。時間の経過とともにコミュニケーションパスがALIVEになっていることも確認できます。
IPリソースの作成処理です。
PostgreSQLリソースの作成処理です。リソースの作成は完了です。
最後にPostgreSQLリソースとIPリソースの依存関係を作成します。最終的なステータス表示を見ると、IPリソースがPostgreSQLの下位に入ったことが分かります。
最終的にそれぞれのホストで実行された処理がOKかchangedであれば成功です。既に実施済みの項目についてもskippedとなるため処理は成功となります。unreachable の場合はホストに接続できていない、failedはタスクに失敗したことを示します。それぞれ出力するログを見て原因を探ってplaybookの修正を行ってください。
6-3. Ansibleで構築した環境の確認
仮想マシンは以下のように作成されました。
仮想マシンにログインして構築したLifeKeeper のリソース構成を確認します。
スイッチオーバーやフェイルオーバーを試みてみましたが正常に稼働することを確認しました。