PostgreSQLを使用した読み取り専用サーバー継続性を備えたセカンダリサーバーモデル


重要

  • PostgreSQL高可用性モデルは、ビルド8400以降向けにサポートされており、PostgreSQLのネイティブストリーミングレプリケーションを使用します。初期のRubyrepベースのレプリケーションモデルは提供終了しており、既にサポート対象外です。
  • PAM360ビルド8400以降にアップグレード済みで、PostgreSQLの高可用性セットアップをRubyrepレプリケーションにて使用している場合、手順を進める前に、PAM360アプリケーションおよびデータベースの完全なバックアップを取る必要があります。バックアップを取った後、下記の手順を進めて、読み取り専用の継続性を備える新たな高可用性セカンダリーサーバーモデルを設定してください。
  • この手順はビルド8400以降に適用されます。ビルド8310以前のバージョンについては、こちらのヘルプドキュメントを参照してください。

ミッションクリティカルな環境では、パスワードへの途切れることのないアクセスが不可欠です。PAM360の読み取り専用継続性を備えたPostgreSQLセカンダリサーバーモデルは、共有データベースを持つプライマリサーバーとセカンダリサーバー、およびリアルタイムレプリカを維持する読み取り専用サーバーを使用することで、継続的な可用性、耐障害性、および最適なパフォーマンスを保証します。このアーキテクチャにより、プライマリサーバーとセカンダリサーバーが利用不能になった場合でも、シームレスな運用が可能になります。このドキュメントでは、読み取り専用サーバーの継続性設定を使用して、PostgreSQLセカンダリサーバーモデルを環境内で構成および維持するための手順について説明します。

このヘルプドキュメントでは、以下のトピックについて説明します。

  1. 前提条件
  2. 読み取り専用サーバーの継続性を備えたセカンダリサーバーモデル
  3. アプリケーションサーバーの可用性構成
  4. 高可用性監視
  5. 高可用性監査証跡
  6. よくある質問
  7. トラブルシュートのヒント

1.前提条件

  1. 環境内でPostgreSQLデータベースを使用した既存のセカンダリサーバーモデルを使用している場合は、この新しい高可用性構成を設定する前に、既存の構成を削除する必要があります。お使いの環境から既存の設定を削除するための詳細な手順については、こちらのリンクをご覧ください。
  2. すべてのサーバーでWebサーバーポート（8282）が開いていること、およびプライマリサーバーと読み取り専用サーバーでデータベースサーバーポート（2345）が開いていることを確認してください。環境内でWebサーバーとデータベースサーバーにカスタムポートを設定している場合は、それらのポートが開いていることを確認してください。
  3. 環境内でアプリケーションゲートウェイを展開している場合は、セカンダリサーバーまたは読み取り専用サーバーとして展開を予定しているサーバーに、Microsoft Visual C++ 再頒布可能パッケージ（Visual Studio 2015 以降用）がインストールされていることを確認してください。

2.読み取り専用サーバーの継続性を備えたセカンダリサーバーモデル

PAM360の読み取り専用継続性を備えたPostgreSQLセカンダリサーバーモデルは、堅牢なパフォーマンス、耐障害性、およびサービス継続性を提供するように設計されています。このアーキテクチャは、プライマリサーバーとセカンダリサーバーで構成され、どちらも完全に機能し、読み書き操作を処理できます。これらは、プライマリサーバー上で独立したサービスとして実行される共有PostgreSQLデータベースに接続されています。さらに、専用のPostgreSQLデータベースを備えた読み取り専用サーバーが含まれており、PostgreSQLのネイティブなストリーミングレプリケーションを通じてプライマリデータベースのリアルタイムレプリカを維持し、読み取り操作のみをサポートします。

pgsql-ha

読み取り専用の継続性を備えたこの完全なセカンダリサーバーモデルは、最大限の可用性とディザスターリカバリ対策を求める組織に推奨される導入形態です。サーバーやデータベースの障害発生時でも、中断のない運用を保証します。プライマリサーバーでPAM360サービスに障害が発生した場合、セカンダリサーバー上のPAM360サービスがサービスの中断なくシームレスに引き継ぎます。プライマリサーバーとセカンダリサーバーの両方が完全にダウンした場合でも、読み取り専用サーバーを介して特権パスワードへのアクセスは継続されます。管理者は、読み取り専用サーバーを一時的に昇格させることで、完全な読み書き機能を復元し、すべてのノード間で最小限の混乱とデータの一貫性を確保することもできます。

ただし、インフラストラクチャや運用上の要件で完全なセットアップが必要ない場合、または複数のサーバーのプロビジョニングが制約となる場合は、サポートされている代替デプロイメントタイプのいずれかを選択できます。

  1. プライマリサーバーと読み取り専用サーバー — このモデルは、完全な読み取りおよび書き込み機能を備えたプライマリサーバーと、読み取り専用操作をサポートする読み取り専用サーバーで構成されます。読み取り専用サーバーは、プライマリサーバーに障害が発生した場合の代替手段として機能し、保存されているパスワードへのアクセスを継続的に確保します。この構成では、プライマリサーバーと読み取り専用サーバーの両方が、それぞれ専用のデータベースを保持します。
    pgsql-ha-1
  2. 共有データベースを持つプライマリサーバーとセカンダリサーバー - このモデルは、プライマリサーバーとセカンダリサーバーで構成され、完全な読み取りおよび書き込み機能を提供します。セカンダリサーバーは、プライマリーサーバー上のPAM360サービスが利用できない場合の代替手段として機能します。この構成では、両方のサーバーは単一のPostgreSQLデータベースに依存しており、そのデータベースはプライマリサーバー上で独立したサービスとして実行されています。
    pgsql-ha-2

これらの各モデルは、組織のさまざまなニーズに合わせて、可用性と拡張性の度合いが異なります。

シナリオ

特権パスワードへのアクセス

サポートされている機能

PAM360およびデータベースサービスは、プライマリサーバー上で稼働しています。

プライマリサーバー

読み書き操作を含むフルアクセス

プライマリサーバー上のPAM360サービスは停止しているが、データベースサービスは稼働している。

セカンダリサーバー

読み書き操作を含むフルアクセス

プライマリサーバーの完全停止

読み取り専用サーバー

読み取り操作のみに制限されたアクセス

プライマリサーバーとセカンダリサーバーが完全に停止

読み取り専用サーバー

読み取り操作のみに制限されたアクセス



メモ：

  1. 読み取り専用サーバー継続性を備えたセカンダリサーバーモデルにおける読み取り専用サーバーは、フォールバックサーバーとして提供されるものであり、永続的なアクセスを目的としたものではありません。
  2. スケジュールはプライマリサーバーでのみ実行されます。
  3. プライマリサーバーまたはセカンダリサーバーがアクティブで、かつPAM360サービスが実行されている場合、読み取り専用サーバーに直接アクセスすることはできません。ユーザーが読み取り専用サーバーのURLを使用してPAM360アプリケーションにアクセスする場合、以下のリダイレクトロジックが適用されます。
    1. PAM360とPostgreSQLデータベースサービスの両方がプライマリサーバー上で稼働している場合、ユーザーは自動的にプライマリサーバーにリダイレクトされます。
    2. プライマリサーバーでPAM360サービスが停止している場合でも、PostgreSQLデータベースサービスが稼働している場合は、セカンダリサーバーでPAM360サービスが稼働していれば、ユーザーはセカンダリサーバーにリダイレクトされます。
    3. プライマリサーバーとセカンダリサーバーの両方が完全にダウンした場合でも、ユーザーは読み取り専用サーバーを介して特権パスワードへのアクセスを中断することなく維持できます。
  4. アプリケーションサーバーが環境内の異なるネットワークに分散して配置されている場合、ネットワークの制限により、読み取り専用サーバーからプライマリサーバーまたはセカンダリサーバーへのリダイレクトが失敗する可能性があります。このような場合、ユーザーは読み取り専用サーバーのURLではなく、プライマリサーバーのURLを使用してPAM360に直接アクセスすることをお勧めします。
  5. 共有データベースを持つプライマリサーバーとセカンダリサーバーモデルにおいて、プライマリサーバーが完全に停止した場合、PostgreSQLデータベースはプライマリサーバー上で独立したサービスとして動作するため、プライマリサーバーの停止中はアクセス不能となり、保存されているパスワードやその他の特権データへのアクセスはできなくなります。

選択したモデルに応じた適切な導入手順については、次のセクションを参照してください。

3.アプリケーションサーバーの可用性構成

以下に、さまざまな運用ニーズに対応するための3種類のデプロイメントモデルを示します。設定手順については、希望するモデルのいずれかを参照してください。

  1. 共有データベースを持つプライマリ/セカンダリサーバーと、追加の読み取り専用サーバー（推奨）
  2. プライマリサーバーと読み取り専用サーバー
  3. 共有データベースを持つプライマリサーバーとセカンダリサーバー

4.高可用性監視


メモ：

現在、PAM360は、バンドルされているPostgreSQLデータベース専用のセカンダリサーバー監視機能を提供しています。ただし、MS SQLデータベースのサポートは今後のアップデートで追加される予定です。


メモ：

ここで説明する高可用性監視は、共有データベースを持つプライマリおよびセカンダリサーバーと、追加の読み取り専用サーバーを対象としています。これは、選択した高可用性導入モデルによって異なる場合があります。

アプリケーションサーバーおよび関連データベースの継続的な監視は、事業継続性を確保し、予期せぬサーバー障害によるダウンタイムのリスクを最小限に抑えるために不可欠です。PAM360は、プライマリ、セカンダリ、読み取り専用サーバー、およびプライマリと読み取り専用のデータベースなど、構成済みのすべてのコンポーネントをリアルタイムで可視化する、集中型の高可用性監視ダッシュボードを提供します。サーバーの可用性、接続状況、データベースレプリケーションの健全性、およびサーバーのロールに関するリアルタイムの情報を提供します。高可用性ダッシュボードにアクセスするには、[管理] >> [Business Continuity] >> [高可用性]に移動します。

pgsql-ha-dashboard

ダッシュボードには、お客様の環境に展開されている読み取り専用の継続性を備えたセカンダリサーバーモデルが、以下の詳細情報とともに表示されます。

  1. Server - ホスト名、DNS名、状態、サーバーの種類、使用中のポート、およびアクティブなセッションの数
  2. Database - ホスト名、データベースの種類、使用中のポート、構成済みサーバーの総数、およびアクティブなサーバーの数

さらに、環境内で利用可能なサーバーの名前を変更して、識別しやすくすることもできます。サーバーの名前を変更するには、以下の手順に従ってください。

  1. 高可用性ダッシュボードで、目的のサーバーのホスト名の横にある編集アイコンをクリックします。
  2. 表示されるホスト名を編集ウィンドウで、ホスト名フィールドに、選択したサーバーに使用する名前を入力します。
  3. 設定変更を保存するには、確認をクリックしてください。
    pgsql-ha2

この監視機能により、管理者はすべてのサーバーとデータベースの状態と接続状況をリアルタイムで追跡できるため、障害発生時に事前に対応し、環境全体で特権アクセスを中断することなく維持することができます。

5.高可用性監査証跡

PAM360はデフォルトで、リソース、ユーザー、キー、証明書、タスクのアクティビティを網羅した包括的な監査証跡を提供します。読み取り専用の継続性を備えたセカンダリサーバーモデルが有効になっている場合、リソース、ユーザー、タスクの監査に関するサーバー固有の追跡機能により、監査機能がさらに強化されます。これらの監査カテゴリにはそれぞれ、プライマリサーバー、セカンダリサーバー、読み取り専用サーバー専用のタブが用意されており、管理者は発生元のサーバーに基づいてアクションを追跡できます。この機能強化により、クラスター環境全体におけるすべてのアクティビティを包括的に把握できるようになります。PAM360の監査証跡について詳しくは、こちらをクリックしてください。

6.よくある質問


1.現在の設定を中断することなく、読み取り専用の継続性を備えたセカンダリサーバーモデルを有効にすることはできますか？

いいえ、PostgreSQLを使用している既存のセカンダリサーバーモデルがある場合は、新しいモデルを設定する前に、この設定を削除する必要があります。既存の設定を安全に削除するには、このリンクに記載されている手順に従ってください。

2.プライマリサーバーとセカンダリサーバーの両方がダウンした場合、どうなりますか？

このような場合、ユーザーは読み取り専用サーバーを介して特権パスワードへの継続的なアクセスを維持できます。必要に応じて、管理者権限を持つユーザーは、読み取り専用サーバーを一時的に再構成してプライマリサーバーとして動作させることで、完全な機能を維持することができます。読み取り専用サーバーをプライマリサーバーとして構成するための詳細な手順については、こちらのリンクを参照してください。

3.すべてのノードの状態を確認するにはどうすればよいですか？

すべてのサーバーのステータスは、[管理] >> [Business Continuity] >> [高可用性]で確認できます。ここにすべてのサーバーのステータスが表示されます。

7.トラブルシュートのヒント


1.高可用性ダッシュボードでサーバーの1つが非アクティブ状態と表示された場合は、どうすればよいですか？

[管理] > [Business Continuity] > [高可用性] の画面において、いずれかのサーバーのステータスが［非アクティブ］と表示されている場合、PAM360サービスが稼働していない、PostgreSQLのレプリケーション設定に潜在的な問題がある、あるいはプライマリ、セカンダリ、および読み取り専用サーバー間のネットワーク通信に問題が生じていることが原因である可能性があります。この問題を解決するには、以下の手順に従ってください。

  1. プライマリサーバーまたはセカンダリサーバーが非アクティブと表示される場合は、それぞれのサーバーが稼働しており、PAM360サービスが正常に実行されていることを確認してください。
  2. 読み取り専用サーバーが非アクティブと表示される場合は、読み取り専用サーバーが稼働しており、PAM360サービスが正しく実行されていることを確認してください。
  3. サービスが実行されているにもかかわらずステータスが非アクティブと表示される場合は、データベースのレプリケーションに問題がある可能性があります。プライマリサーバーのレプリケーション構成を確認するには、以下の手順に従ってください。
    1. <PAM360-Installation-Directory>/pgsql/data フォルダに移動します。
    2. pg_hba.conf ファイルを開き、以下のエントリが存在し、正しく設定されていることを確認してください。
    • プライマリサーバーと読み取り専用サーバーのIPアドレス。
    • 読み取り専用サーバーで使用されるレプリケーションユーザー名。
    • # TYPE DATABASE USER ADDRESS METHOD セクションで、有効なレプリケーション構成行が host replication userName roIPAddress /32 md5 の形式で含まれていることを確認します。

2.プライマリサーバーとセカンダリサーバーの両方が復旧不能になった場合、完全な機能を維持したまま事業継続性を確保するにはどうすればよいでしょうか？

プライマリサーバーとセカンダリサーバーの両方が復旧不能な場合、読み取り専用サーバーを一時的にプライマリサーバーとして構成することで、読み取り操作と書き込み操作の両方をサポートできます。

読み取り専用サーバーをプライマリサーバーとして構成するには、以下の手順に従ってください。

  1. 読み取り専用サーバー上で実行されているPAM360サービスを停止してください。
  2. <PAM360-Installation-Directory>/pgsql/data フォルダから、standby.signal ファイルを削除してください。
  3. <PAM360-Installation-Directory>/pgsql/ext_conf フォルダにある postgres_ext.conf ファイルを開き、リカバリプロパティセクションの下に記載されているすべてのエントリを削除してください。
  4. <PAM360-Installation-Directory>/conf/configurations.properties ファイル内の readonly.mode=true というエントリを削除してください。
  5. <PAM360-Installation-Directory>/conf フォルダにある serverstate.conf ファイルを開き、roというエントリを見つけて、masterに置き換えてください。
  6. このサーバー上でPAM360サービスを開始してください。今後は、フル機能をサポートするプライマリサーバーとして機能します。
  7. 次に、以下のコマンドを実行して、古い読み取り専用構成へのデータベース参照をクリーンアップします。
  • Windows
    • <PAM360-Installation-Directory>\bin\DeleteROServerIP.bat <IP_Address_of_RO_that_was_converted_to_Primary>
    • <PAM360-Installation-Directory>\bin\DeleteSlot.bat <slotName_of_RO_that_was_converted_to_Primary>
  • Linux
    • <PAM360-Installation-Directory>/bin/DeleteROServerIP.sh <IP_Address_of_RO_that_was_converted_to_Primary>
    • <PAM360-Installation-Directory>/bin/DeleteSlot.sh <slotName_of_RO_that_was_converted_to_Primary>

これで、読み取り専用サーバーを高可用性構成のプライマリサーバーとして正常に再構成できました。環境内のプライマリサーバーとセカンダリサーバーが復旧したら、現在プライマリとして動作しているサーバーをフォールバックのロールに戻すことができます。プライマリサーバーとセカンダリサーバーを復元した後、動作中のプライマリサーバー（以前は読み取り専用サーバー）からプライマリデータベースにデータベースバックアップを復元せずに、これらのサーバーでPAM360サービスを開始しないようにしてください。そうしないと、データ損失につながる可能性があります。

メモ：

データベースのバックアップを復元せずにプライマリサーバーを再起動すると、データが失われるのでご注意ください。


読み取り専用データベースからプライマリデータベースにデータベースバックアップを復元するには、以下の手順に従ってください。

  1. 現在稼働中のプライマリサーバー上で、[管理] >> [構成] >> [データベースバックアップ] に移動し、[データベースバックアップ] ウィンドウの [今すぐバックアップ] ボタンをクリックします。バックアップファイルは保存先のディレクトリに生成されます。
  2. 現在稼働中のプライマリサーバー上でPAM360サービスを停止してください。

  3. メモ：

    プライマリサーバーでデータベースのバックアップ復元が行われている間、環境内ではユーザーからの要求を処理できるサーバーは利用できなくなります。

  4. 生成されたバックアップファイルを使用して、動作中のプライマリサーバーから復元されたプライマリサーバーにデータを復元します。バックアップデータの復元手順の詳細については、こちらのリンクをご覧ください。
  5. データベースのバックアップを復元した後、復元したプライマリサーバー上でPAM360サービスを開始し、サーバーとデータベースを初期化します。

現在プライマリサーバーとして動作しているサーバー（以前は読み取り専用サーバー）は、以前のフォールバックサーバーとしてのロールに再構成することはできません。以下の手順に従って、このサーバーを廃止し、新しい読み取り専用サーバーをゼロから構築してください。

  1. 復旧したプライマリサーバー上で実行されているPAM360サービスを停止します。
  2. 復元されたプライマリサーバー上で、読み取り専用サーバー設定パックを生成します。
  3. 新しく生成された設定パックを使用して、読み取り専用サーバーを設定します。

上記で詳述したように、プライマリサーバーとセカンダリサーバーが復旧不能な状態にある場合、または迅速にオンラインに戻せない場合は、読み取り専用サーバーを完全に機能するプライマリサーバーとして昇格させることで、業務継続性を確保できます。プライマリサーバーとセカンダリサーバーが復旧したら、稼働していたプライマリサーバーからデータベースのバックアップを作成し、復旧したプライマリサーバーに復元して、プライマリサーバーが停止していた間に行われた最新の変更とのデータの一貫性を確保します。現在稼働中のプライマリサーバー（以前は読み取り専用サーバー）を廃止し、新しい読み取り専用サーバーをフォールバックサーバーとして再構成します。

上記の設定を確認しても問題が解消せず、サーバーが依然として非アクティブと表示される場合は、以下の場所からログを収集し、さらなるサポートを受けるために pam360-support@manageengine.jp までお送りください。

  • <PAM360-Installation-Directory>/logs
  • <PAM360-Installation-Directory>/pgsql/data/pg_log