高可用性(PostgreSQLデータベースの場合)

(本機能は、Enterprise Editionでのみサポートされています。

本手順はビルド13200以降を対象としています。 13200より前のビルドでPostgreSQLデータベースを使用した高可用設定については、こちらを参照してください

ミッションクリティカルな環境において、パスワードへの継続的なアクセスを提供するということは必要不可欠な要素です。PMPの高可用性の機能により、サーバー障害などの不慮の事態においてもパスワードにアクセスできる環境を提供することができます。

本ナレッジでは、次の項目について説明します。

  1. 前提条件
  2. 高可用性モデル
  3. 高可用性のためのアプリケーションサーバーの構成
  4. 高可用性の監視
  5. 高可用性の監査証跡
  6. よくある質問
  7. トラブルシューティング

1.前提条件

  1. 既存の環境でPostgreSQLデータベースを使用したHA構成を構築している場合、新しいHA構成を構築する前に既存の構成を解除する必要があります。解除方法に関しては、こちらから確認してください。
  2. すべてのサーバーにおいてwebサーバーのポート(7272)、およびプライマリとリードオンリーサーバ-にてデータベースサーバーポート(2345)が開放されていることを確認してください。webサーバーとデータベースサーバのポートとして、カスタムポートを設定している場合、それらのポートが開放されていることを確認してください。

2. 高可用性モデル

Password Manager ProにおけるPostgreSQLベースの高可用性(HA)アーキテクチャは、堅牢なパフォーマンス、耐障害性、およびサービスの継続性を実現するように設計されています。このアーキテクチャは、プライマリサーバーとセカンダリサーバーで構成されており、どちらも読み取りおよび書き込み操作が可能なフル機能を有しています。これらは、プライマリサーバー上で独立したサービスとして動作する共有PostgreSQLデータベースに接続されています。さらに、専用のPostgreSQLデータベースを備えたリードオンリーサーバーも含まれています。このデータベースは、PostgreSQLネイティブのストリーミングレプリケーションを通じてプライマリデータベースのリアルタイムな複製を保持し、読み取り操作のみをサポートします。

この完全なHA(高可用性)モデルは、最大限の可用性とディザスタリカバリ(災害復旧)への備えを求める組織にとって、弊社が推奨するデプロイメント構成です。本モデルは、サーバーやデータベースの障害時であっても、業務を停止させることなく継続できることを保証します。プライマリサーバー上でPassword Manager Proのサービス障害が発生した場合、セカンダリサーバー上のPassword Manager Proサービスがシームレスに引き継ぎを行うため、サービスが中断することはありません。万が一、プライマリとセカンダリの両サーバーが完全にダウンした場合でも、リードオンリーサーバーを介して特権パスワードへのアクセスを継続できます。さらに、管理者はリードオンリーサーバーを一時的に昇格させて、完全な読み取り・書き込み機能を復旧させることも可能です。これにより、すべてのインスタンス間でデータの一貫性を維持しながら、業務への影響を最小限に抑えることができます。

ただし、お客様のインフラストラクチャや運用上の要件において、ここまでの完全なセットアップが必要ない場合、あるいは複数のサーバーを構築することがリソース的に困難な場合は、サポートされている以下の代替デプロイメント構成の中から1つを選択することも可能です。

  1. プライマリサーバーとリードオンリーサーバー - このモデルは、完全な読み取り・書き込み機能を備えたプライマリサーバーと、読み取り専用操作のみをサポートするリードオンリーサーバーで構成されています。リードオンリーサーバーは、プライマリサーバーの障害発生時におけるフォールバックオプションとして機能し、保存されているパスワードへの継続的なアクセスを保証します。このセットアップでは、プライマリサーバーとリードオンリーサーバーの両方が、それぞれ専用のデータベースを保持します。
  2. 共有データベースを持つプライマリサーバーとセカンダリサーバー - このモデルはプライマリサーバーとセカンダリサーバーで構成され、両サーバーともに完全な読み取り・書き込み機能を提供します。プライマリサーバー上のPassword Manager Proサービスが利用不能になった際、セカンダリサーバーがフォールバックとして機能します。このセットアップでは、両方のサーバーが単一のPostgreSQLデータベースに依存しており、そのデータベースはプライマリサーバー上で独立したサービスとして稼働します。

これらの各モデルは、組織ごとの多様なニーズに適応できるよう、それぞれ異なるレベルの可用性と拡張性を備えています。

シナリオ 特権パスワードへのアクセス経路 サポートされる機能
プライマリサーバー上でPassword Manager Proとデータベースサービスが稼働中 プライマリサーバー 読み取り・書き込み操作を含むフルアクセス
プライマリサーバーのPassword Manager Proサービスが停止しているが、データベースサービスは稼働中 セカンダリサーバー 読み取り・書き込み操作を含むフルアクセス
プライマリサーバーが完全にダウン 読み取り専用サーバー 読み取り操作のみの限定的アクセス
プライマリおよびセカンダリサーバーが完全にダウン 読み取り専用サーバー 読み取り操作のみの限定的アクセス

注記:

  • 本構成におけるリードオンリーサーバ-は、定常的なアクセスのためではなく、フォールバックサーバーとして機能します。
  • スケジュールはプライマリサーバー上でのみ実行されます。
  • プライマリとセカンダリサーバーがアクティブである間、リードオンリーサーバ-にはアクセスできません。リードオンリーサーバ-のアクセスURLを用いて、Password Manager Proにアクセスしたとき、次のリダイレクトロジックが適用されます。
    1. プライマリサーバーがアクティブの場合、自動的にプライマリサーバーにリダイレクトされます。
    2. プライマリサーバーがダウンしているが、セカンダリサーバーがアクティブな場合、セカンダリサーバーへリダイレクトされます。
    3. プライマリサーバーおよびセカンダリサーバーの両方がダウンしている場合、リードオンリーサーバーを介して、中断されることなく特権IDにアクセスできます。
  • アプリケーションサーバーが異なるネットワークに展開されている場合、ネットワーク制限のためにリードオンリーサーバーからプライマリまたはセカンダリサーバーへのリダイレクトが失敗する可能性があります。このようなケースでは、リードオンリーサーバーのアクセスURLではなく、プライマリサーバーのアクセスURLを使用してPassword Manager Proにアクセスすることを推奨します。
  • フルHA構成においてプライマリサーバーが完全にダウンした場合、保存されたパスワードやその他の特権データへのアクセスは利用不能になります。これは、PostgreSQLデータベースがプライマリサーバー上で独立したサービスとして稼働しており、プライマリサーバーの停止に伴いデータベース自体もアクセス不能になるためです。

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

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

さまざまな運用ニーズに対応するための、3種類の構成方式があります。構築手順については、希望するモデルのいずれかを参照してください。

4. 高可用性の監視

注:以下で説明する高可用性の監視は、共有データベースを持つプライマリサーバーとセカンダリサーバー、および追加のリードオンリーサーバーに関するものです。これは、選択した構成方式によって異なる場合があります。

高可用性の継続的な監視と独立したデータベースは、ビジネスの継続性と予期しないサーバーのフェイルのダウンタイムのリスクを最小限にするために非常に重要です。Password Manager Proは、プライマリと読み取り専用のデータベースだけでなく、プライマリ、セカンダリ、リードオンリーサーバ-などのすべてのコンポーネントをリアルタイム表示する高可用性監視モニターダッシュボード画面を提供します。サーバーの可用性、接続状態、データベースのレプリケーションの健全性、サーバーの役割に関するリアルタイムの分析情報を提供します。高可用性監視ダッシュボードを確認するためには、[管理]タブ→[設定]→[高可用性]へ移動します。

ダッシュボードは、環境に展開されている高可用性モデルに関する詳細情報を表示します。

  1. サーバー - ホスト名、DNS名、状態、サーバの種類、使用中のポート、アクティブユーザーのセッション数
  2. データベース - ホスト名、データベースの種類、使用中のポート、構成されたサーバーの総数、アクティブなサーバーの数

加えて、環境内のサーバーを把握しやすくするために、サーバー名を編集可能です。手順は以下の通りです。

  1. 高可用性ダッシュボードは上で、任意のサーバーのホスト名右横の編集アイコンをクリックします。
  2. [ホスト名を編集]ウィンドウが表示され、[ホスト名]フィールドに、選択したサーバーの新しい名前を入力します。
  3. 変更を保存するため。[確認]をクリックします。

この監視機能により、管理者がすべてのサーバーとデータベースの状態と接続性をリアルタイムで確認できるため、ダウン状態に対する対応を助け、環境全体で中断なく特権へのアクセス可能となるよう維持します。

5. 高可用性の監査証跡

Password Manager Proはデフォルトで、リソース、ユーザー、鍵、証明書そして、タスクのアクティビティをカバーする包括的な監査証跡を提供します。高可用性が有効化されているとき、リソース、ユーザー、そしてタスク監査をサーバごとに追跡できるようになり、監査機能がより強化されます。それぞれの監査カテゴリーは、プライマリ、セカンダリ、そしてリードオンリーサーバ-の個別のタブが用意されており、管理者は元のサーバーに基づいて、アクションを追跡できます。この機能強化により、クラスタ環境全体のすべてのアクティビティを包括的に監視できます。Password Manager Proの監査証跡の詳細については、こちらを参照してください。

6. よくある質問

  1. 既存のセットアップを崩すことなく、PostgreSQLを使用した高可用性を有効化できますか?
    いえ、できません。PostgreSQLを使用した既存の高可用性設定がある場合、新しいセットアップを構成する前に必ず既存の設定を解除する必要があります。既存のセットアップを安全に解除する手順は、こちらを参照してください。
  2. プライマリおよびセカンダリサーバーがダウンした場合、何が起こりますか?
    このような場合、ユーザーはリードオンリーサーバーを介して、特権パスワードへの継続的なアクセスが可能です。必要に応じて、管理者権限をもつユーザーは、リードオンリーサーバーを一時的にプライマリサーバーとして再設定し、完全な機能を維持できます。詳細な手順は、こちらを参照してください。
  3. すべてのノードのステータスを確認するにはどうすればよいですか?
    すべてのサーバーの状態は、[管理]タブ→[設定]→[高可用性]で確認できます。

7. トラブルシューティング

1.HAを構成するサーバーの一つが非アクティブと表示されます。どうすればよいですか?

[管理]タブ→[設定]→[高可用性] において、いずれかのサーバーのステータスが『非アクティブ(inactive)』と表示される場合、Password Manager Proサービスが稼働していないか、PostgreSQLのレプリケーション設定に問題があるか、あるいはプライマリ・セカンダリ・リードオンリーサーバー間のネットワーク通信に問題が発生している可能性があります。この問題を解決するには、以下の手順に従ってください。

  1. 非アクティブと表示されているサーバーがプライマリまたはセカンダリサーバーの場合、各サーバーおよび各Password Manager Proサービスが正常に動作中か確認してください。
  2. 非アクティブと表示されているサーバーがリードオンリーサーバーの場合、リードオンリーサーバーおよびリードオンリーサーバーのPassword Manager Proサービスが正常に動作中か確認してください。
  3. サービスが起動しているにもかかわらず、非アクティブと表示されているサーバーがある場合、データベースの複製に問題が発生している可能性があります。下記の手順に従い、プライマリサーバーのレプリケーション構成を確認してください
    1. プライマリの<PMP_インストールディレクトリ>/pgsql/dataフォルダ₋へ移動します。
    2. pg_hba.confファイルを開き、以下のエントリが正しく記載されているか確認してください。
      • プライマリとリードオンリーサーバーのIPアドレス
      • リードオンリーサーバーによって使用されるレプリケーションユーザー名
      • 「# TYPE DATABASE USER ADDRESS METHOD」セクション配下に、有効なレプリケーション構成行が、host replication userName roIPAddress /32 md5 の形式で記載されていることを確認します。

2.プライマリサーバーおよびセカンダリサーバーが復旧不可能な場合、どうすればよいですか?

プライマリサーバーとセカンダリサーバーの両方が復旧不可能な場合、リードオンリーサーバーを一時的にプライマリサーバーとして機能させ、読み取り・書き込み両方の操作をサポートするように構成できます。リードオンリーサーバーをプライマリサーバーに切り替えるには、以下の手順に従ってください。

  1. リードオンリーサーバーで起動中のPMPを停止します。
  2. <PMP_インストールディレクトリ>/pgsql/dataフォルダーへ移動し、standby.signal ファイルを取り除きます。
  3. <PMP_インストールディレクトリ>/pgsql/ext_conf フォルダへ移動し、postgres_ext.conf ファイルを開いて、「recovery props」セクション配下のすべてのエントリを削除します。
  4. <PMP_インストールディレクトリ>/conf/configuration.properties ファイル内のreadonly.mode=true のエントリを削除します。
  5. <PMP_インストールディレクトリ>/conf フォルダへ移動し、serverstate.conf ファイルを開いて、「ro」「master」へ変更します。
  6. このサーバー上で、PMPサービスを起動します。これで、プライマリサーバーとしてフル機能をサポートするようになりました。
  7. <PMP_インストールディレクトリ>/binフォルダへ移動し以下のコマンドを実行して、古い読み取り専用設定へのデータベース参照をクリーンアップしてください。
    • Windows
      1. <PMP_インストールディレクトリ>\bin\DeleteROServerIP.bat <プライマリへ変更するリードオンリーサーバーのIPアドレス>
      2. <PMP_インストールディレクトリ>\bin\DeleteSlot.bat <プライマリへ変更するリードオンリーサーバーのslotName>
    • Linux
      1. <PMP_インストールディレクトリ>\bin\DeleteROServerIP <プライマリへ変更するリードオンリーサーバーのIPアドレス>
      2. <PMP_インストールディレクトリ>\bin\DeleteSlot.sh <プライマリへ変更するリードオンリーサーバーのslotName>

以上で、高可用性(HA)構成において、リードオンリーサーバーをプライマリサーバーとして再設定することに成功しました。環境内のプライマリサーバーおよびセカンダリサーバーが復旧した後は、現在プライマリとして動作しているサーバーを元の役割(フォールバック)に戻すことができます。 なお、プライマリおよびセカンダリサーバーを復旧させた後、現在プライマリとして動作しているサーバー(旧リードオンリーサーバー)から取得したデータベースのバックアップを、復旧したプライマリデータベースへリストアする前に、それらのサーバー上で Password Manager Pro サービスを開始しないよう注意してください。 これを怠ると、データ消失につながる恐れがあります。

注:プライマリサーバーをデータベースバックアップを復元せずに再起動すると、データ損失が発生することに注意してください。

リードオンリーサーバーのデータベースからプライマリデータベースへ、データベースバックアップをリストアするには、以下の手順に従ってください。

  1. 仮プライマリサーバー(旧リードオンリーサーバー)上で、[管理]タブ→[設定]→[データベースバックアップ]へ移動し、「いますぐバックアップ」ボタンをクリックしバックアップファイルを作成します。作成したバックアップファイルは、「保存先ディレクトリ」に指定されたフォルダ₋へ保存されます。
  2. 仮プライマリサーバーのPMPサービスを停止します。

    注:プライマリサーバーにデータベースバックアップを復元している間、環境内のサーバーはユーザーの要求を処理できません。

  3. 作成したバックアップファイルを使用して、仮プライマリサーバーから旧プライマリサーバーにデータをリストアします。リストア手順については、こちらのページを確認してください。
  4. データベースバックアップをリストアした後、復旧したプライマリサーバーでPassword Manager Proサービスを起動して、サーバーとデータベースを初期化します。

仮プライマリサーバーは、リードオンリーサーバーへ再構成することができません。本サーバーは環境から削除し、再度リードオンリーサーバーをセットアップしてください。

  1. 復旧したプライマリサーバーで実行されているPassword Manager Proサービスを停止します。
  2. 復旧したプライマリサーバーで、3章の内容に従って読み取り専用サーバーのセットアップパックを生成します。
  3. 3章の内容に記載されている手順に従って、新しく生成されたセットアップパックを使用して読み取り専用サーバーを構成します。

上述の通り、プライマリおよびセカンダリサーバーの復旧が困難な場合、または迅速にオンラインに戻せない場合は、リードオンリーサーバーを「仮のプライマリサーバー」に昇格させ、ビジネスの継続性を確保できます。 プライマリおよびセカンダリサーバーが復旧した後は、現在プライマリとして動作しているサーバーからデータベースバックアップを作成し、復旧したプライマリサーバーへリストアしてください。これにより、元のプライマリが停止していた間に行われた最新の変更内容とのデータ整合性が確保されます。その後、現在プライマリとして動作しているサーバー(旧リードオンリーサーバー)を廃止し、新たなリードオンリーサーバーをフォールバック用として再設定してください。

トラブルシューティングを実行後も事象が解消できない場合、お手数をおかけしますが、弊社保守サポートまでお問い合わせください。また、こちらを参考に次のログファイルを、アップロードしてください。ログのアップロード後に事象を確認した日時をお知らせください。

  • <PMP_インストールディレクトリ>/logs フォルダー
  • <PMP_インストールディレクトリ>/pgsql/data/pg_log フォルダー