1. はじめに

とあるお客様のプロジェクトで、IBM APIConnectの1つのコンポーネントであるAPI Manager(以降、APIM)をクラスター構成で構築しました。この記事では、初心者が陥りやすい(クラスター特有の)構築時のポイントをまとめます。

2. この記事の前提

以降の内容は以下を前提としています。

API ConnectのバージョンはV5.0.7.2
クラスターに所属しているAPIMは2つ
1台目のAPIMは構築済み
2台目のAPIMのネットワーク構成までは設定済み

3. APIMをクラスターに追加する際の考慮点

APIMのクラスター環境を構築する際、最初にCloud Managerコンソール上でAPIMのサーバーを追加する必要があります。その際、以下の点に注意する必要があります。

追加対象のAPIM上で、設定(例えばメール・サーバーの設定など)を一切実施しない
ただし、初回ログイン時のプロファイルの更新だけは実施する必要がある

また、1台目のAPIMのクラウド・コンソールで設定した内容(例えば、LDAP設定やグループ設定など)は、2台目のAPIMにも自動的に反映されます。これは、クラスター環境下に存在するAPIMでは定期的に同期が取られるためです。ただし、mgmtコマンドでの設定内容は同期されないので各サーバー上で実施する必要があります(例えば、syslogなどの設定をする場合は注意が必要)。

4. APIMダウン時の考慮点

クラスターに参加しているAPIMには役割があります。1台はPrimaryとして、残りはSecondary(RSS/AA)として振る舞いますが、各サーバーの役割は"ha list"コマンドを実行して確認します。

APIMTest01/APIConnect> ha list
Self  IP               HA    Network  Role       Runtime  FQDN
Yes   xx.xxx.xxx.xxx   Yes   Up       Primary    Up       APIMTest01.pot.ibm
No    yy.yyy.yyy.yyy   Yes   Up       RSS/AA     Up       APIMTest02.pot.ibm

運用手順書の作成や基盤テストの検討の際には、クラスター内でどのようにデータの更新が実施されているのか把握しておく必要があります。正常系では、以下の通りデータが更新されています。

Primaryサーバーでのデータ更新はPrimaryサーバー上で実施され、その後、Secondaryサーバーと同期が取られる
Secondaryサーバー上でのデータ更新はSecondaryサーバー上では実際されず、一度更新処理のリクエストをPrimaryサーバーに依頼する(その後は上と同じ)

では、どちらかのサーバーがダウンした場合、データの更新はどのように実施されるのでしょうか。Secondaryサーバーがダウンした場合、復旧後Primaryサーバーの更新内容が同期されます。問題はPrimaryサーバーがダウンした場合ですが、具体的に以下の通り更新内容が同期されます。

Primaryサーバーがダウンして一定時間が経過した後、SecondaryサーバーがPrimaryサーバーになる
ダウンしているサーバーが復旧するまでの間は、(新しい)Primaryサーバーがデータ更新を実施する
ダウンしていたサーバーが復旧すると、Secondaryサーバーになり、(新しい)Primaryサーバーと同期が取られる

尚、SecondaryサーバーがPrimaryサーバーになるまでの間はPrimaryサーバーとの通信ができないため、この間はデータの更新ができないことになります。

参考: Primaryサーバーがダウンした時のイメージ

5. FixPack適用時の考慮点

クラスター環境下に存在するAPIMにFixPackを適用する場合、適用する順番を遵守する必要があります。

1) SecondaryサーバーすべてにFixPackを適用する(Secondaryサーバー間の適用順序は任意)
2) 1)が完了した後で、PrimaryサーバーにFixPackを適用する

という順序を守る必要があります。そのため、FixPack適用前に、"ha list"コマンドを実行して各APIMの役割(PrimaryかSecondaryか)を確認しておくことが重要です。

因みに、誤ってPrimaryサーバーからFixPackを適用してしまった場合、以下のような事象が発生します。

・PrimaryサーバーのFixPack適用は成功する
・SecondaryサーバーのRuntimeがダウンしたままになり、クラスターから強制的に離脱させられる("dissociation"という状態になる)

この状況になると、APIMの管理者に以下のようなメールが通知されます。

Subject: Cloud dissociation has been detected.

One or more servers have become dissociated from the cloud. This requires administrative action to resolve diverging copies of configuration data.  You can log in to IBM API Connect Console and click on the clusters tab to see more details: https://<host_name>:443/cmc

残念ながら、このメールを読んだだけでは何をすべきか分かりにくいのですが、以下の手順でクラスターから離脱したサーバーを復旧させます。

Cloud Managerコンソール上で、離脱したサーバーを削除する
"system clean apiconfig"コマンドを実行して初期化する(ネットワーク以外の設定はすべて失われるので注意)
Cloud Managerコンソール上で、初期化したサーバーを再追加する

6. まとめ

APIMをクラスタ構成で構築する際の考慮点をまとめました。ご紹介した内容を意識して作業に取り組むと、プロジェクトを円滑に進めることができると思います。

API Managerをクラスター構成で構築する際の考慮点をまとめてみた