高可用性（PostgreSQLデータベースの場合）

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

ミッションクリティカルな環境において、パスワードへの継続的なアクセスを提供するということは必要不可欠な要素です。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ストリーミングレプリケーションを介してプライマリデータベースのライブレプリカを維持し、読み取り操作のみをサポートする専用のリードオンリーサーバーを備えています。

プライマリサーバーがダウンしたとき、セカンダリサーバーを通してユーザーは操作を継続できます。プライマリとセカンダリサーバーがダウンした場合、リードオンリーサーバ－によって中断されることなく特権IDにアクセス可能です。管理者は一時的に、リードオンリーサーバ－をプライマリサーバーとして再構成することで、全機能をリストアできます。本高可用性モデルは、全サーバー間でデータとネットワークの一貫性を維持しながら、シームレスなフェールオーバーを実現します。

この完全なHAモデルは、最大の可用性と災害復旧の準備を必要とする組織に推奨される構成です。この構成により、サーバーやデータベースの障害が発生しても、運用が中断されません。プライマリサーバーが障害を起こした場合、セカンダリはシームレスに引き継ぎます。プライマリとセカンダリの両方のサーバーが利用できない場合でも、リードオンリーサーバーを介して特権パスワードへのアクセスが続行できます。また、管理者は、完全な読み取りおよび書き込み機能を復元するために、一時的にリードオンリーサーバーを昇格させることもでき、すべてのノードで最小限のダウンタイムとデータの整合性を確保します。

しかしながら、あなたのインフラストラクチャや運用要件が上記の完全なHAモデルを必要としない場合や、複数のサーバーを用意することが困難な場合は、次に紹介する別の構成方式のいずれかを選択することができます。

1. プライマリサーバーとリードオンリーサーバー

2. プライマリサーバーとセカンダリサーバー

これらの各モデルは、組織のニーズに応じた異なる可用性やスケーラビリティのレベルを提供します。選択したモデルに適した構築手順については、次のセクションを参照してください。

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を構成するサーバーの一つが非アクティブと表示されます。どうすればよいですか？

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. DeleteリードオンリーServerIP.bat <プライマリへ変更するリードオンリーサーバーのIPアドレス>
2. DeleteSlot.bat <プライマリへ変更するリードオンリーサーバーのslotName>
• Linux
1. DeleteリードオンリーServerIP.sh <プライマリへ変更するリードオンリーサーバーのIPアドレス>
2. DeleteSlot.sh <プライマリへ変更するリードオンリーサーバーのslotName>

以上で、リードオンリーサーバーが仮プライマリサーバーへと変更されます。環境内の旧プライマリサーバーとセカンダリサーバーが復旧した場合、以下の手順でデータベースをリストアします。プライマリおよびセカンダリサーバーを復旧した後は、仮プライマリサーバー（旧リードオンリーサーバー）からプライマリデータベースにデータベースバックアップを復元しない限り、これらのサーバーでPassword Manager Proサービスを起動しないようにしてください。誤って起動すると、データ損失が発生する可能性があります。

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

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

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

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

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

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

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

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