※ 本記事は、Iratxe Etxebarriaによる”WebLogic Administration Server Failover without a floating IP“を翻訳したものです。
2025年5月14日
このブログは、高可用性の概念およびエンタープライズ・デプロイメント・ガイド (EDG)に精通しているOracle WebLogic管理者を対象としています。高可用性要件があるOracle WebLogicドメインに適用されます。
WebLogic管理サーバーは、Oracle WebLogicドメインのシングルトン・コンポーネントです。1つのドメインで実行できるWebLogic管理サーバーは1つのみです。他のWebLogicサーバー(管理対象サーバー)は、高可用性を確保するためにクラスタの一部にできますが、管理サーバーをクラスタ化することはできません。
ただし、ドメイン内のアクティブ/パッシブ高可用性トポロジを使用して管理サーバーを構成できます。これにより、管理サーバーの手動フェイルオーバーを実行して、管理サーバーが実行されているホストに影響する障害からリカバリできます。エンタープライズ・デプロイメント・ガイド(1)は、EDGとも呼ばれ、Fusion Middleware製品の高可用性ベスト・プラクティスを提供するMAAドキュメントです。その他のベスト・プラクティスとして、これらのガイドでは、共有記憶域および浮動IPを使用して管理サーバー用の高可用性保護を構成する方法について詳しく説明します。このブログ投稿では、浮動IPを必要としない管理サーバーのフェイルオーバーの簡略化、このアプローチの長所と短所の分析、およびその使用に関する正確な推奨事項を提供します。
WebLogic管理サーバーのフェイルオーバー (EDG従来のアプローチ)
管理サーバーの手動フェイルオーバーをサポートするために、一般的なエンタープライズ・デプロイメント・トポロジには次の要件があります:
- 管理サーバーの仮想ホスト名 (VHN)および仮想IPアドレス (VIP)。管理サーバーは、浮動IP (100.100.100.100など)に解決される仮想ホスト名(adminvip.example.comなど)をリスニングします。この浮動IPは、管理サーバーを実行するホストの物理IPではなく、WebLogicドメイン内の任意のホストのネットワーク・インタフェースに接続できる仮想IPです。
- 管理サーバーのドメイン・ディレクトリの共有記憶域デバイス。管理サーバーで使用されるドメイン・フォルダは、ドメイン内の任意のホストからアクセスできる共有フォルダです。
管理サーバーを実行するホストでシステム障害が発生した場合、管理サーバーのVIPアドレスをドメイン内の別のホストに手動で再割当てし、新しいホストに管理サーバー・ドメイン・ディレクトリをマウントしてから、新しいホストで管理サーバーを起動できます。
浮動IPなしのWebLogic管理サーバーのフェイルオーバー
浮動IPを必要とせずに、管理サーバーに対して高可用性保護を提供できます。これは従来のアプローチの簡略化です。管理サーバーが仮想ホスト名をリスニングしているにもかかわらず、このホスト名は管理サーバーを実行しているホストの物理IPに解決されます。フェイルオーバーの場合は、管理サーバーを実行している新しいホストの物理IPを指すように、DNSの仮想ホスト名レコードを更新します。仮想ホスト名は変更されませんが、IPは管理サーバーが実行されているノードによって異なります。
たとえば、管理サーバーは仮想ホスト名 adminvip.example.com でリスニングします。host1で実行されると、このアドレスはホスト1のIP (100.100.100.1など)に解決されます。管理サーバーがhost2に移動される場合、仮想ホスト名はhost2のIPを指している必要があります(たとえば、100.100.100.2)。
この方法では、管理サーバーで使用されるリスニング・ポートは、他の管理対象サーバーで使用しないでください。そうしないと、同じIPでリスニングするため競合が発生します。管理サーバーは管理対象サーバーとは異なるIPを常にリスニングするため、EDGの従来のアプローチではこの要件ではありません。そのため、同じポートを使用している場合でも競合しません。
浮動IPを使用しない管理サーバーの手動フェイルオーバーをサポートするために、次の要件があります:
- 仮想ホスト名 (VHN)ですが、VIPは必要ありません。管理サーバーは、サーバーを実行しているホストのIPに解決される仮想ホスト名(adminvip.example.comなど)をリスニングします。
- 管理サーバーのドメイン・ディレクトリの共有記憶域デバイス。したがって、管理で使用されるドメイン・フォルダは、ドメイン内の任意のホストによってマウントできる共有フォルダです。
フェイルオーバー・ステップの比較
浮動IPに基づく管理サーバーのフェイルオーバー手順については、FMWエンタープライズ・デプロイメント・ガイド(2)で説明しています。次の表に、浮動IPに基づくメソッドに必要なフェイルオーバー・ステップと、浮動IPのないメソッドを比較します。
| WebLogic管理サーバーのフェイルオーバー・ステップ (HOST1からHOST2) | ||
|---|---|---|
| 浮動IPを使用したフェイルオーバー | 浮動IPなしのフェイルオーバー | |
| 1 | HOST1で管理サーバーを停止します。 | (同じステップ) |
| 2 | HOST1でノード・マネージャを停止します。 | (同じステップ) |
| 3 | VIPアドレスを他のホストに移行します (「ip addr del..」および「ip addr add..」コマンド)。 | 管理サーバーのリスニング・アドレスのレコードを更新して、他のホストのIPにマップします。この変更は、この名前の解決に使用された内容に応じて、DNSまたは/etc/hosts で実行する必要があります。 |
| 4 | たとえば、arpingを使用してルーティング表を更新します。 |
n/a |
| 5 | HOST1のnodemanager.domainsを編集して、ASERVER_HOMEを削除します。 | (同じステップ) |
| 6 | HOST2のnodemanager.domainsを編集して、ASERVER_HOMEを追加します。 | (同じステップ) |
| 7 | HOST1でノード・マネージャを起動し、HOST2でノード・マネージャを再起動します。 | (同じステップ) |
| 8 | n/a | 管理サーバーを起動する前に、DNSの変更が有効であることを確認します。 |
| 9 | HOST2で管理サーバーを起動します。 | (同じステップ) |
| 10 | HOST2の管理サーバーにアクセスできることをテストします。 | (同じステップ) |
浮動IPなしの管理サーバーのフェイルオーバーの長所と短所
従来のアプローチと比較して、この管理フェイルオーバー方法の長所と短所のサマリーを次に示します。
長所
- 管理サーバーの追加IP (VIP)を予約および管理する必要はありません。これにより、システムのネットワーク要件が簡略化され、ネットワーク・タスクのみをネットワーク・レイヤー(DNS)に委任できます。
短所
- フェイルオーバー手順に複雑さが生じる可能性があります。DNSの変更が必要です。この変更は、通常、WebLogic管理者チームとは異なるITチームによって実行されます。ただし、実際の影響は、各顧客の内部組織によって異なります。
- フェイルオーバー手順で遅延が発生する可能性があります。DNSの変更は、DNS TTL値に応じて有効になるまでに時間がかかります。TTLが適切に設定されていない場合、一部のコンポーネントでは、DNSキャッシュをリフレッシュして新しいIPに接続するために再起動が必要になることがあります。
- (ロード・バランサやSSHトンネルのような)仮想ホスト名に接続するかわりに、管理サーバーのIPに直接接続するコンポーネントには、管理サーバーのフェイルオーバー時に適切な構成または更新が必要です。
まとめと推奨事項
浮動IPなしの管理サーバーのフェイルオーバーは、管理サーバーの有効なフェイルオーバー方法です。ただし、この方法には、従来の浮動IPアプローチには適用されないいくつかの意味があります。使用する場合は、次の推奨事項に従ってください:
- このアプローチは、DNSレコードの変更が組織で柔軟である場合にのみ使用します。
- 管理サーバーで使用される仮想ホスト名のDNSエントリに低いTTL値(120秒など)を使用して、変更がホストによって迅速に消費されるようにします。管理サーバーのフェイルオーバーが計画アクティビティである場合は、DNSエントリを更新する前にTTLのみを減らすことができます。更新および消費されたら、TTLを高い値に戻して、DNSに対するTTLの影響を最小限に抑えます。
- 管理サーバーに接続するコンポーネントのDNSキャッシュにも、低いTTL値を使用します:
- Java DNSキャッシュ: WebLogicサーバー (または任意のJavaプロセス)で、networkaddress.cache.ttlプロパティをカスタマイズします。このプロパティは、$JAVA_HOME/conf/security/java.security ファイルにあります。デフォルトでは、永久にキャッシュされるため、値を設定しないかぎり、DNS解決キャッシュをリフレッシュするには再起動が必要です。
- OHS DNSキャッシュ: システムでOHSを使用して管理サーバーに接続する場合は、mod_wl_ohs.conf(3)のディレクティブWLDNSRefreshIntervalをカスタマイズする必要があります。デフォルトでは0です。つまり、キャッシュは永久に失われます。DNS解決キャッシュをリフレッシュするには、OHSの再起動が必要です。定期的にリフレッシュされ、DNSエントリが変更されたときに新しいIPにリクエストをリダイレクトするように、0とは異なる低い値に構成します。
トレードオフがあることに注意: TTLを減らすと、DNS更新をより迅速に消費できますが、より頻繁なリクエストでDNSサービスをオーバーロードすることもできます。クライアントの数によっては、これによって DNSサーバーが中断されることがあります。
- ロード・バランサは通常、IPを使用してバックエンドに接続します。ロード・バランサが管理サーバーのIPに直接ルーティングする場合(中央にOHSがない場合)、管理サーバーを指す可能性のあるすべてのIPをバックエンドに追加します。管理サーバーがリスニングしているIPのみが有効になります。それ以外の場合は、管理サーバーのフェイルオーバー時にバックエンド定義を更新する必要があります。
- 管理サーバーに関連するセキュリティ・ネットワーク・ルールを定義するときに、特定のIPを使用しないでください。管理サーバーで使用可能なすべてのIPを含むCIDR範囲を使用します。そうしないと、フェイルオーバー後にルールが適用されない可能性があり、新しいIPでルールを更新する必要があります。
- SSHトンネルを使用して管理サーバーに接続する場合は、各時点で適切なIPを使用し、フェイルオーバー時に更新します。
参照
(1) Fusion Middlewareエンタープライズ・デプロイメント・ガイド:
SOA エンタープライズ・デプロイメント・ガイド 12.2.1.4
SOA エンタープライズ・デプロイメント・ガイド 14.1.2
(2) エンタープライズ・デプロイメント・ガイドの管理サーバーのフェイルオーバー手順:
SOA EDG 12.2.1.4 “管理サーバーの手動フェイルオーバーの検証”
SOA EDG 14.1.2 “管理サーバーの手動フェイルオーバーの検証”
(3) Oracle HTTP Server – Oracle WebLogic Serverプロキシ・プラグインの使用 – WLDNSRefreshInterval