はじめに

こんにちは。NTTテクノクロス株式会社の金澤です。

私が所属するデータベースチームでは、現在データベースのクラウド環境移行に力を入れています。
その一環で、PostgreSQLとPacemakerを組み合わせた高可用ソリューションである「PG-REX」を Microsoft AzureのVirtual Machines環境(以降Azure VM)で構築することに取り組んでいます。

今回は、"PG-REX on Azure VM"の取り組み第一弾として、Azure VM上でPG-REXを構築する際の課題点について整理しました。
ブログ第二弾では、整理した課題を元にPG-REX環境を構築し、手段等をブログ記事で公開することを考えています。

サマリ

PG-REX構成をAzure VM上で組むには2つ課題があることがわかりました。

• 課題1. VIPを割り当てるリソースエージェントが動作しない
• 課題2. STONITHエージェントが動作しない

PG-REXとは

PG-REXとは、RDBMSのひとつであるPostgreSQLで高可用なデータベースシステムを構成するためのソリューションとなります。
オンプレミス環境でPostgreSQLの高可用構成を構築する際に利用されます。
PG-REXの概要について、以下の記事でわかりやすく記載されていましたので引用いたします。

PostgreSQLとPacemakerによる高可用ソリューション PG-REX 9.6 の構築

PG-REXとはPostgreSQLの同期レプリケーション機能とPacemakerを組み合わせたHAクラスタの名称となります。 Pacemakerが管理すること - 障害検知時の自動フェイルオーバ - スイッチオーバ - VIPの管理（PGのプライマリ、スタンバイを監視して自動で設定してくれる）

(引用した記事内では、オンプレミス環境でのPG-REX構築の手順もまとまっているので参考となります。)

検証目的

「はじめに」の項で簡単に触れましたが、現在私の所属するチームでは"データベースのクラウド環境移行"に力を入れており、その一環でクラウドVM上でのPG-REX構成の検証を進めています。

クラウド上でデータベースを運用する方法としては以下の2つがあります。

・DBaaS（マネージドデータベースサービス）を用いる方法 ・クラウドVM上にインストールして、自分でデータベース環境を構築する方法

弊社が推奨する運用方法は、基本方針として前者のDBaaSを用いる方法ですが、
今回のテーマである "PG-REX構成"は、後者の方法で運用する際に必要となる手順となります。

後者の方法については、例えば、

• 「DBaaSでサポートしてない機能拡張を使用したい」
• 「(将来的にはDBaaSへ移行したいが)試験工数等の関係でオンプレでの構成をそのまま使いたい」

しかしながら、後者の方法で構築するデータベース環境は、可用性の対応も自前で用意する必要があるため、クラウド環境移行へのハードルとなっています。

今回の検証を通じて、最終的に２つの動作をクラウドVM上のPostgreSQLサーバで実現できることを目標としています。

動作①. フェイルオーバー
障害が発生したサーバから、正常なサーバに切り替える機能

• プライマリ側がダウンすると、スタンバイサーバが自動でプライマリサーバへ切り替わることを確認
• DB接続に使用する仮想IPアドレス等のシステム構成要素が正常に切り替わることの確認

動作② フェンシング
正常なサーバから故障したサーバを停止したり、再起動する機能

• プライマリ⇔スタンバイ間がNW障害等で分断されたとき、プライマリからスタンバイへフェンシングが実行されることを確認

検証の進め方とゴール

「PG-REXとは」の項で記載した通り、PG-REXはオンプレミス環境で構築することを前提としたソリューションのため、クラウドVMで構築可能か判明しておりません。

そのため、以下の方法で作業を進め検証していきます。

• ・手順が確立しているオンプレミス環境の手順をベースにして、クラウドVM上で環境構築を進める
• ・作業内で判明したクラウドVM独自の課題点を一つずつ対応していきPG-REXを動作させる

今回のブログ記事では、課題点の整理までを行います。

検証環境

早速検証を進めていきたいと思いますが、今回はクラウドVMとして、Microsoft Azureの"Virtual Machines"環境を使用します。
今回の検証で使用する「環境構築手順」「環境情報」及び「最終的な構成イメージ」を以下に示します。

環境構築手順

今回はPG-REXプロジェクトより取得可能な「PG-REX利用マニュアル」の手順を元に環境構築を進めます。
マニュアルは以下PG-REXの公式サイトよりダウンロード可能です。

https://ja.osdn.net/projects/pg-rex/

環境情報

今回使用するVMの構成等の情報および利用するソフトウェアのバージョン情報は以下の通りです。

Azure VM環境情報

VMイメージ	Red Hat Enterprise Linux with HA add-on - Gen 2
リージョン	Japan East
VMサイズ	Standard B2s (2 vcpu 数、4 GiB メモリ)

ソフトウェア情報

PostgreSQL	13.7
Pacemaker	2.1.2-4

最終的な構成イメージ

最終的な構成イメージを図で示します。

2つの図は、それぞれAzure VM 上の接続イメージとAzure VM内のソフトウェアとネットワークの構成図となります。

▼Azure VM上の接続イメージ

▼Azure VM内のソフトウェアとネットワークの構成図

今回はPG-REX構成を組めるかどうかの確認のため、まずはPG-REXマニュアルで推奨されているオンプレミス環境と同等のNW構成で検証を進めていきます。

各NWの用法について簡単にまとめます。

• ・S-LAN ：DBがクライアントからの接続を受け付けるのに使用
• ・D-LAN ：DBのレプリケーションに使用
• ・IC-LAN：Pacemaker同士が死活監視に使用

VIP（仮想IPアドレス)は、Pacemakerが管理しマシンの動作状況に応じて配置先のインスタンスが切替っています。
図中にある2つのVIPについて、PG-REX構成における使用方法を以下簡単に記載いたします。

VIP-Primary (図中はVIP-Pri)	- クライアントがプライマリ側DBに接続するために使用する仮想IP - フェイルオーバ発生時には、Pacemakerの機能によって新プライマリ側へとVIPの割り当て先が切替わる ★ クライアント側は当該VIPでDBに接続することで、接続先インスタンスのIPアドレスを気にせずにDBアクセスが可能となる
VIP-Replication (図中はVIP-Rep)	- プライマリ⇔スタンバイ間でのレプリケーション接続用に使用する仮想IP - フェイルオーバ発生時には、Pacemakerの機能によって新プライマリ側へとVIPの割り当て先が切替わる ★ スタンバイ側は当該VIPを指定してレプリケーションを行うことで、フェイルオーバが発生時も設定変更等なく即座に同期レプリケーションを開始できる。

Azure VMでのPG-REX環境構築の課題

Azure VM上で構築を進めていくと、2つのポイントでつまずきました。

2つのポイントについて課題事項を整理します。

ポイント1. VIPを割り当てるリソースエージェントが動作しない

課題

マニュアル通りの手順で環境を構築していくと、Azure VM上ではVIPの付与がうまく動作しません。

詳細

PG-REXのマニュアルでは、VIPを付与するために"IPaddr2"というリソースエージェント(以下RA)を使用しています。
このRAの動作では、Azure VM上でVIPを付与するために必要な手順を満たせていませんでした。

"IPaddr2"の動作について詳細を確認したところ、VIPを付与するためにLinuxコマンドの「ip」コマンドを用いて、対象となるオペレーティングシステムにIPアドレスを付与していました。
●参考：IPaddr2のソースコード
https://github.com/ClusterLabs/resource-agents/blob/main/heartbeat/IPaddr2

Azure VMのIPアドレス付与に必要な手順と比較すると、"IPaddr2"の動作だけではAzure VMにVIPをうまく付与できません。
Azure VM上でIPアドレスを付与するためには、以下の手順が必要となります。

▼Azure VMでのIPアドレス付与手順

• 　①プライベートおよびパブリックIPアドレスを既存のAzureネットワークインターフェイスに追加する
• 　②VMオペレーティングシステムにIP アドレスを追加する

"IPaddr2"では、①部分を実施していないため、VIPの付与がうまく動作しておりませんでした。

●参考：Azure VM上でのIP割り当て
https://docs.microsoft.com/ja-jp/azure/virtual-network/ip-services/virtual-network-multiple-ip-addresses-cli#add

解決策

本課題を解決するためには、付与手順①部分を実施するRAが必要となります。
現状、Pacemakerが扱えるRAで当該動作を実現するものは含まれておりません。
そのため、現時点でAzure VM上でPG-REX構成を実現したい場合には、

• ・付与手順①を可能とするRAを新規に作成
• ・NW構成をPG-REX利用マニュアルのものから組み直す

等対応が必要となります。

ポイント2. STONITH(フェンス)エージェントが動作しない

課題

マニュアル通りの手順で環境を構築していくと、Azure VM上では、オンプレミス環境で使用するSTONITHエージェントがうまく動作しません。

詳細

マニュアルではSTONITHエージェントとして、"fence_ipmilan"を用いております。
当該STONITHエージェントは、Intelligent Platform Management Interface (IPMI)準拠のハードウェア制御ボードを用いて、フェンシングを実現しております。

Azure VMには専用のSTONITHエージェントが用意されているため、そちらを用いる必要がありそうです。

解決策

Azure VM向けのSTONITHエージェントとして、"fence_azure_arm"が用意されています。
PG-REX利用マニュアルのSTONITH関連個所を適宜修正することで、対応が可能となると考えられます。

●参考：AzureのSTONITH(フェンス)エージェント
https://docs.microsoft.com/ja-jp/azure/virtual-machines/workloads/sap/high-availability-guide-rhel-pacemaker

まとめ

PG-REX利用マニュアルの手順だけでは、Azure VM上にPG-REX構成を組むことは難しく、いくつか課題があることがわかりました。

次回の記事では、今回確認した課題の対応として以下の内容を実施し、実際にAzure VM上で動作するPG-REXを構築してきます。

• 1. Azure VM用にカスタマイズしたRAを作成
• 2. Azure VM用のSTONITHエージェントを用いて、フェンシング設定

おわりに

NTTテクノクロス株式会社ではPostgreSQLに関する各種のお問い合わせを受け付けています。 システムの導入、開発、維持管理の際にご活用ください。

定額制チケットサービスはこちら