1. 管理者ガイド
  2. Oracle Key Vaultマルチマスター・クラスタの概念

3 Oracle Key Vaultマルチマスター・クラスタの概念

マルチマスター・クラスタは、ノードと呼ばれるOracle Key Vaultサーバーの完全に接続されたネットワークです。

3.1 Oracle Key Vaultマルチマスター・クラスタの概要

マルチマスター・クラスタ・ノードは、高可用性、障害時リカバリ、負荷分散および地理的分散をOracle Key Vault環境に提供します。

Oracle Key Vaultマルチマスター・クラスタ・デプロイメントの使用は、どのOracle Key Vaultデプロイメントよりもお薦めできます。

Oracle Key Vaultマルチマスター・クラスタには、最大の可用性と信頼性を実現するために、Oracle Key Vaultノードの読取り/書込みペアを作成するメカニズムがあります。読取り専用のOracle Key Vaultノードをクラスタに追加して、Oracleウォレット、暗号化キー、Javaキーストア、証明書、資格証明ファイルおよびその他のオブジェクトを必要とするエンドポイントにさらに高い可用性を提供できます。

Oracle Key Vaultマルチマスター・クラスタは、Oracle Key Vaultノードの相互接続されたグループです。クラスタ内の各ノードは、完全に接続されたネットワーク内の他のすべてのノードと接続するように自動的に構成されます。ノードは地理的に分散できます。Oracle Key Vaultエンドポイントは、クラスタ内の任意のノードと対話します。

この構成では、データが他のすべてのノードにレプリケートされるため、データ損失のリスクが軽減されます。データの損失を防ぐには、双方向同期レプリケーションを有効にするために、読取り/書込みペアと呼ばれるノードのペアを構成する必要があります。この構成では、あるノードへの更新を他のノードにレプリケートでき、他のノードで更新を検証した後、その更新が成功とみなされます。クリティカル・データは、読取り/書込みペア内でのみ追加または更新できます。追加または更新されたデータはすべて、残りのクラスタに非同期にレプリケートされます。

アップグレード・プロセスを完了した後、Oracle Key Vaultクラスタ内のすべてのノードはOracle Key Vaultリリース18.1以降になっていて、他のすべてのノードから1つのリリース更新の範囲内である必要があります。クラスタに追加する新しいOracle Key Vaultサーバーは、クラスタと同じリリース・レベルである必要があります。

クラスタのすべてのノードでクロックを同期する必要があります。したがって、クラスタ内のすべてのノードでネットワーク・タイム・プロトコル(NTP)設定が有効になっている必要があります。

クラスタ内の各ノードは、クラスタ全体の継続的なレプリケーションを通して同じデータセットを維持しながら、アクティブかつ独立してエンドポイントにサービスを提供できます。可能な最小の構成は2ノード・クラスタで、最大の構成では、複数のデータ・センターにまたがる複数のペアを備えた最大16のノードを保持できます。

親トピック: Oracle Key Vaultマルチマスター・クラスタの概念

3.2 Oracle Key Vaultマルチマスター・クラスタリングの利点

Oracle Key Vaultマルチマスター・クラスタ構成は、プライマリ/スタンバイ環境よりも優れた高可用性に対応します。

地理的に分散したエンドポイントの高可用性を確保するために、異なるデータ・センターにデプロイされたOracle Key Vaultノードは、アクティブ-アクティブのマルチマスター・クラスタ構成で動作し、キーを作成および共有します。アクティブ-アクティブ構成では、クラスタにパッシブ・マシンがないため、リソースの使用率が向上します。マルチマスター・クラスタ構成のその他の利点は負荷分散です。マルチマスター構成の複数のOracle Key Vaultノードがデータ・センターにデプロイされている場合は、そのデータ・センターのエンドポイント・データベースのキー・リクエストをアクティブに共有できます。

一般的な大規模デプロイメントでは、Oracle Key Vaultは地理的に離れたデータ・センターに分散している可能性のある多数のエンドポイントにサービスを提供する必要があります。

マルチマスター・デプロイメントと比較すると、スタンドアロンのOracle Key Vaultデプロイメントでは最小限の可用性が提供され、プライマリ・スタンバイのデプロイメントでは制限付き可用性が提供されます。

  • プライマリ・スタンバイ構成には、クライアントをアクティブに処理できる単一のプライマリOracle Key Vaultサーバーのみが含まれます。

  • スタンバイ・ロールで実行されているサーバーが使用できない場合、プライマリ・ロールで実行されているサーバーは読取り専用モードで、書込み操作は許可されません。

  • プライマリ・スタンバイ・モードでは、同じデータ・センターでの高可用性または複数のデータ・センター間の障害リカバリをサポートできます。

  • 永続マスター暗号化キー・キャッシュが有効になっていない場合は、メンテナンス期間中のデータベースの停止時間は避けられません。

Oracle Key Vaultマルチマスター・クラスタ構成は、これらの制限に対処します。ノードを地理的に分散し、同時に高可用性と障害時リカバリ機能を提供できます。

Oracle Key Vaultマルチマスター・クラスタ構成には、次のような大きな利点があります。

  • プライマリ/スタンバイ・デプロイメントと同様のマルチマスター・クラスタ・ノード間のデータ互換性

    すべてのノードのデータ・セットが同じであるため、エンドポイントは任意のノードから情報を取得できます。クラスタでは、Oracle Key Vaultノードが使用できない場合もエンドポイントの操作には影響しません。特定のノードが使用できない場合、エンドポイントはクラスタ内の別のノードと透過的に対話します。

  • フォルト・トレランス

    正常にエンロールされたクライアントは、クラスタ内で使用可能なOracle Key Vaultノードの独自のリストを透過的に更新します。これにより、クライアントは、追加の介入なしでいつでも使用可能なノードを見つけることができます。したがって、少なくとも1つの動作中のOracle Key Vault読取り/書込みペアがエンドポイントにアクセス可能なかぎり、ノードの予期しない障害やネットワークの中断によってエンドポイントのサービスが中断されることはありません。すべての読取り/書込みペアがエンドポイントに対して使用できなくても、読取り専用制限ノードが使用可能な場合、エンドポイントは読取り専用操作を呼び出すことができます。

  • ゼロ・データ損失

    読取り/書込みノードで追加または更新されたデータは、読取り/書込みピアにすぐにレプリケートされ、そのピアでコミットとみなされることを確認する必要があります。その後、クラスタ全体に配布されます。したがって、データの更新は、更新されたデータが複数のサーバーに存在することが保証されている場合にのみ成功とみなされます。

  • システムにパッシブ・マシンがない

    プライマリ/スタンバイ構成にはパッシブ・スタンバイ・サーバーが必要です。Oracle Key Vaultマルチマスター・クラスタには、アクティブなサーバーのみが含まれます。これにより、ハードウェアの使用率が向上します。

  • スケール・アップおよびスケール・ダウン

    クライアントへのOracle Key Vaultサービス全体を中断することなく、クラスタにOracle Key Vaultノードを追加したり、クラスタから既存のノードを削除できます。これは、予想されるワークロードを満たすために、クラスタ内のノードの数を必要に応じて増減できることを意味します。

  • メンテナンス

    ハードウェアまたはソフトウェアのメンテナンスが必要な場合、Oracle Key Vaultノードはクラスタを離れ、メンテナンス後にクラスタに戻ることができます。残りのノードは、引き続きクライアントにサービスを提供します。適切に計画されたメンテナンスによりサービスの停止時間が発生しないため、エンドポイントへのサービスの中断を回避できます。

親トピック: Oracle Key Vaultマルチマスター・クラスタの概念

3.3 マルチマスター・クラスタのアーキテクチャ

Oracle Key Vaultノードは、異なるモードで動作する読取り/書込みノードまたは読取り専用ノードにできます。ノードはサブグループを形成することもできます。

親トピック: Oracle Key Vaultマルチマスター・クラスタの概念

3.3.1 Oracle Key Vaultクラスタ・ノード

Oracle Key Vaultノードは、マルチマスター・クラスタのメンバーとして動作するOracle Key Vaultサーバーです。

Oracle Key Vaultサーバーをクラスタのメンバーとして動作するように構成するには、そのサーバーをマルチマスター・クラスタ・ノードに変換する必要があります。このプロセスは、ノード・インダクションと呼ばれます。Oracle Key Vault管理コンソールの「Cluster Management」ページでインダクションを開始します。

インダクションでは、Oracle Key Vaultが「Cluster」タブを変更して、ノードの管理コンソールでの管理、監視および競合解決機能を有効にします。管理コンソールのクラスタ固有の機能(クラスタ設定、監査レプリケーション、ネーミング解決、クラスタ・アラートなど)も有効化されます。

「Primary-Standby Configuration」ページは、ノードのOracle Key Vault管理コンソールでは使用できません。ノードはパッシブ・スタンバイ・サーバーを持つことも、パッシブ・スタンバイ・サーバーになることもできません。

ノードは、追加のサービスを実行して、クラスタの他のノードと通信できるようにします。ノードからエンロールされたエンドポイントは、クラスタ・トポロジを認識します。

クラスタ内の各ノードには、ユーザーが割り当てたノード識別子があります。ノード識別子はクラスタ内で一意である必要があります。

ノードが作成されたOracle Key Vaultリリースは、ユーザー、ユーザー・グループ、エンドポイント、エンドポイント・グループおよび仮想ウォレットの名前のバイト長に影響します。「オブジェクトのネーミング・ガイドライン」を参照してください。

親トピック: マルチマスター・クラスタのアーキテクチャ

3.3.2 クラスタ・ノードの制限

クラスタ・ノードの制限事項は、ノードが非同期か同期かによって異なります。

Oracle Key Vaultマルチマスター・クラスタのノードは、相互にデータを非同期でレプリケートします。唯一の例外は、データを読取り/書込みピアにレプリケートすることです。非同期レプリケート操作の結果として発生する様々な制限があります。たとえば、クラスタ内のノードのIPアドレスは静的であり、ノードをクラスタに追加した後は変更できません。ノードに別のIPアドレスが必要な場合は、そのノードをクラスタから削除し、正しいIPアドレスを使用して新しいノードを追加するか、正しいIPアドレスを使用して、削除したノードを再イメージ化してからクラスタに再度追加します。

一度に1つのクラスタ変更操作(ノードの追加、無効化、削除など)しか実行できません。

ノードIDはクラスタ全体で一意です。インダクション・プロセスでノードを選択する場合は、ノードIDが一意であることを確認する必要があります。

Oracle Key Vaultクラスタは、ユーザーがサポートされていないアクションを実行できないように最善を尽くします。ユーザー・インタフェースのノード・インダクション・ドロップダウンから使用中のノードIDを削除し、すでに読取り/書込みピアが存在しているときには、ユーザーが別のピアを追加できないようにします。同様に、マルチマスター・クラスタでは、読取り/書込みピアがすでに存在する場合、ユーザーは2つ目の読取り/書込みピアを追加できません。

親トピック: マルチマスター・クラスタのアーキテクチャ

3.3.3 クラスタ・サブグループ

クラスタ・サブグループは、クラスタの1つ以上のノードのグループです。

クラスタは、概念的に1つ以上のクラスタ・サブグループに分割できます。

ノードをマルチマスター・クラスタに追加すると、ノードはサブグループに割り当てられます。証明書のローテーション操作が進行中でないかぎり、割当てはいつでも変更できます。ノードのクラスタ・サブグループ割当ては個々のノードのプロパティであり、読取り/書込みペアのメンバーは異なるクラスタ・サブグループに存在できます。

クラスタ・サブグループは、エンドポイント・アフィニティの概念を表します。ノードのクラスタ・サブグループ割当てを使用して、エンドポイントのノード・スキャン・リストの検索順序を設定します。エンドポイントと同じクラスタ・サブグループ内のノードは、エンドポイントに対してローカルであるとみなされます。これが参照するノードを確認するには、「Endpoints」ページの「Cluster Subgroup」列のチェック・ボックスを選択します。ローカル・サブグループに存在しないノードと通信する前に、エンドポイントのローカル・サブグループ内のノードが最初にスキャンされます。

クラスタ・トポロジは、クラスタに対して新規ノードを追加または削除するときに変更できます。ローカル・クラスタ・サブグループに対してノードを追加または削除することもできます。各エンドポイントは、エンドポイントが開始した正常な操作の空でないレスポンス・メッセージとともに、この情報の更新を取得できます。クラスタ・トポロジに変更がない場合も、更新されたエンドポイントのノード・スキャン・リストはエンドポイントに定期的に返送されます。これは、失われたメッセージを補うためのものです。

親トピック: マルチマスター・クラスタのアーキテクチャ

3.3.4 Oracle Key Vaultのクリティカル・データ

Oracle Key Vaultには、エンドポイントの操作に必要なクリティカル・データを格納します。読取り専用ノードもクリティカル・データの読取りが可能です。

この情報が失われると、エンドポイントのデータが消失する可能性があります。Oracle Key Vaultのクリティカル・データの例として、エンドポイント暗号化キー、証明書およびOracle Key Vaultが管理する同様のセキュリティ・オブジェクトがあります。エンドポイントのリカバリと継続的な操作を保証するために、Oracle Key Vaultサーバーの障害発生時にもクリティカル・データを保持する必要があります。

Oracle Key Vaultサーバーの障害後に再作成または破棄可能なOracle Key Vaultデータは非クリティカル・データです。クリティカルでないデータの例として、クラスタ構成設定、アラート設定、電子メール設定などが挙げられます。

親トピック: マルチマスター・クラスタのアーキテクチャ

3.3.5 Oracle Key Vault読取り/書込みノード

読取り/書込みノードは、Oracle Key Vaultまたはエンドポイント・ソフトウェアを使用してクリティカル・データを追加または更新できるノードです。

追加または更新されるクリティカル・データには、キー、ウォレット・コンテンツおよび証明書などのデータがあります。

Oracle Key Vault読取り/書込みノードは、常にペアで存在します。読取り/書込みペアの各ノードは、クリティカル・データおよび非クリティカル・データの更新を受け入れることができ、これらの更新は、ペアの他のメンバーである読取り/書込みピアに即時にレプリケートされます。読取り/書込みピアは、クラスタ内の唯一の読取り/書込みペアの特定のメンバーです。読取り/書込みピア間には双方向の同期レプリケーションがあります。特定のノードの読取り/書込みピアではないすべてのノードへのレプリケーションは非同期で行われます。

ノードは、最大で1つの読取り/書込みペアのメンバーにできます。1つのノードは読取り/書込みピアを1つのみ保持できます。ノードは、インダクション・プロセス中に読取り/書込みペアのメンバーになるため、読取り/書込みノードになります。読取り/書込みピアが削除されると、読取り/書込みノードは読取り専用ノードに戻り、その時点で新しい読取り/書込みペアを形成できます。

読取り/書込みノードは、その読取り/書込みピアに正常にレプリケートできた場合および両方のピアがアクティブである場合に、読取り/書込みモードで動作します。読取り/書込みノードは、その読取り/書込みピアにレプリケートできない場合または読取り/書込みピアが無効になった場合に、一時的に読取り専用制限モードになります。

Oracle Key Vaultマルチマスター・クラスタが完全に動作するには、少なくとも1つの読取り/書込みペアが必要です。最大8つの読取り/書込みペアを使用できます。

親トピック: マルチマスター・クラスタのアーキテクチャ

3.3.6 Oracle Key Vault読取り専用ノード

読取り専用ノードでは、ユーザーは非クリティカル・データを追加または更新できますが、クリティカル・データは追加または更新できません。ただし、読取り専用ノードはクリティカル・データの読取りが可能です。

クリティカル・データは、他のノードからのレプリケーションでのみ更新されます。

読取り専用ノードは読取り/書込みペアのメンバーではなく、アクティブな読取り/書込みピアがありません。

読取り専用ノードは、マルチマスター・クラスタに新しいサーバーをインダクションできます。新しいノードは、別の読取り専用ノードにできます。ただし、読取り専用ノードは、別のノードを読取り/書込みピアとしてインダクションすると、読取り/書込みノードになります。

クラスタ内の最初のノードは読取り専用ノードです。読取り専用ノードは、クラスタを拡張するために使用されます。マルチマスター・クラスタの作成後に、読取り専用ノードを追加する必要はありません。読取り専用ノードのみのマルチマスター・クラスタは、有用なクリティカル・データをこのようなマルチマスター・クラスタに追加できないため、理想的ではありません。

親トピック: マルチマスター・クラスタのアーキテクチャ

3.3.7 クラスタ・ノードのモード・タイプ

Oracle Key Vaultでは、クラスタ・ノードに対して読取り専用制限モードまたは読取り/書込みモードの2種類のモードがサポートされます。

  • 読取り専用制限モード: このモードでは、非クリティカル・データのみがノードで更新または追加されます。このモードでは、レプリケーションを介してのみクリティカル・データを更新または追加できます。ノードが読取り専用制限モードに設定される状況は次の2つです。
    • ノードが読取り専用であり、読取り/書込みピアがまだ存在しない場合。
    • ノードが読取り/書込みペアの一部であり、その読取り/書込みピアと通信中に障害が発生したか、ノードに障害が発生した場合。2つのノードのいずれかが動作不能になると、残りのノードは読取り専用制限モードに設定されます。読取り/書込みノードがその読取り/書込みピアと再度通信できるようになると、ノードは読取り専用制限モードから読取り/書込みモードに戻ります。
  • 読取り/書込みモード: このモードでは、クリティカル・データと非クリティカル・データの両方をノードに書込みできます。読取り/書込みノードは常に読取り/書込みモードで動作します。

クラスタ・ノードのモード・タイプは、ノード管理コンソールの「Cluster」タブの「Monitoring」ページで確認できます。ノード管理コンソールの「Cluster」タブには、クラスタ内のすべてのノードのモード・タイプが表示されます。

親トピック: マルチマスター・クラスタのアーキテクチャ

3.3.8 異なるモードのクラスタ・ノードで許可される操作

Oracle Key Vaultマルチマスター・クラスタでは、ノードおよびノードの操作モードに基づいて操作が使用可能または制限されます。

関連項目

親トピック: マルチマスター・クラスタのアーキテクチャ

3.4 マルチマスター・クラスタの構築および管理

単一のOracle Key Vaultサーバーを使用して、マルチマスター・クラスタを初期化します。

親トピック: Oracle Key Vaultマルチマスター・クラスタの概念

3.4.1 マルチマスター・クラスタの構築および管理について

Oracle Key Vaultサーバーで初期クラスタが作成された後、クラスタに必要な様々なタイプのノードを追加できます。

このOracle Key Vaultサーバーでは、クラスタ・データがシードされ、サーバーが初期ノードと呼ばれる最初のクラスタ・ノードに変換されます。クラスタは、追加のOracle Key Vaultサーバーをインダクションし、それらを読取り/書込みノードまたは単純な読取り専用ノードとして追加する際に拡張されます。

マルチマスター・クラスタには、最小で2つのノード、最大で16のノードを含めることができます。

親トピック: マルチマスター・クラスタの構築および管理

3.4.2 マルチマスター・クラスタの初期ノードの作成

マルチマスター・クラスタの初期ノードは、初期ノードにする前に特定の要件に従う必要があります。

単一のOracle Key Vaultサーバーを初期ノードになるよう変換して、マルチマスター・クラスタを作成します。Oracle Key Vaultサーバーは、新しくインストールされたOracle Key Vaultサーバーでも、既存のデータを含むサービスにすでに存在しているサーバーでもかまいません。スタンドアロン・サーバーまたはプライマリ・スタンバイ構成のプライマリ・サーバーは、クラスタの初期ノードに変換できます。

プライマリ・スタンバイ構成のプライマリ・サーバーを使用するには、事前にプライマリ・スタンバイ構成のペアを解除する必要があります。プライマリ・スタンバイ構成では、次のいずれかの方法を使用してクラスタにアップグレードできます。

  • 方法1:
    1. サーバーをバックアップします。
    2. プライマリ・サーバーとスタンバイ・サーバーの両方を最新リリースにアップグレードします。
    3. ペアのプライマリ・サーバーとスタンバイ・サーバーのペアを解除します。(サーバーをアンペアする前に、アンペア・プロセスに関する既知の問題について、『Oracle Key Vaultリリース・ノート』を参照してください。)
    4. クラスタの最初のノードとなるようにプライマリ・サーバーを変換します。
  • 方法2:
    1. サーバーをバックアップします。
    2. ペアのプライマリ・サーバーとスタンバイ・サーバーのペアを解除します。
    3. 以前のプライマリ・サーバーを最新リリースにアップグレードします。
    4. クラスタの最初のノードとなるようにプライマリ・サーバーを変換します。

新しくインストールするサーバーは、初期ノードと同じ現行バージョンにする必要があります。初期ノードは、クラスタの初期化に使用されるデータ全体を提供するという点で特殊です。これは、クラスタの作成時に1回のみ実行されます。初期ノードから提供されるデータには、次のコンポーネントが含まれますが、これらに限定されているわけではありません。

  • 証明書、キー、ウォレットおよびその他のセキュリティ・オブジェクト
  • ユーザーとグループ
  • エンドポイント情報
  • 監査
  • レポート

初期ノードの後に追加された他のすべてのノードは、新しくインストールされたOracle Key Vaultサーバーから作成する必要があります。

クラスタ名は、初期ノードの作成時に選択されます。この名前を選択した後、クラスタ名は変更できません。

初期ノードの作成時には、初期ノードのクラスタ・サブグループも構成されます。変換を開始する前に、有効なネットワーク・タイム・プロトコル(NTP)設定を使用するように、初期ノードに変換されたOracle Key Vaultサーバーを構成する必要があります。初期ノードは、常に読取り専用制限モードの読取り専用ノードとして起動されます。

関連項目

親トピック: マルチマスター・クラスタの構築および管理

3.4.3 マルチマスター・クラスタの拡張

クラスタを初期化した後、読取り/書込みペアまたは読取り専用ノードとして最大15個のノードを追加することで、クラスタを拡張できます。

親トピック: マルチマスター・クラスタの構築および管理

3.4.3.1 マルチマスター・クラスタの拡張について

ノード・インダクションは、マルチマスター・クラスタ・ノードとして動作するようにOracle Key Vaultサーバーを構成するプロセスです。

コントローラ・ノードにより、候補ノードに変換したOracle Key Vaultサーバーがクラスタにインダクションされます。

マルチマスター・クラスタを拡張するには、Oracle Key Vault管理コンソールの「Cluster」タブにあるインダクション・プロセスを使用します。Oracle Key Vaultマルチマスター・クラスタに追加されたノードは、現在のクラスタ・データで初期化されます。ノードは、読取り/書込みピアまたは読取り専用ノードとして追加できます。

3.4.3.2 コントローラ・ノードを使用したクラスタ再構成変更の管理

コントローラ・ノードは、ノードの追加、有効化、無効化、削除など、クラスタ再構成の変更を制御または管理するノードです。 

ノードは、変更の存続期間中のみのコントローラ・ノードです。インダクション時に、コントローラ・ノードは、サーバー証明書および候補ノードの初期化に使用されるデータを提供します。他のノードは、後続のクラスタ変更のコントローラ・ノードになります。1つのコントローラ・ノードは、一度に1つのクラスタ構成の変更のみを制御できます。Oracle Key Vaultでは、同時に複数のクラスタ操作を許可していません。

一度に1つのクラスタ操作を実行することをお薦めします。各同時操作には、独自のコントローラ・ノードがあります。 

次の表に、様々なクラスタ構成におけるコントローラおよび制御対象ノードの役割を示します。

クラスタ構成操作 コントローラ・ノード 制御されるノード
最初のノードとしてのインダクション 任意のサーバー コントローラ・ノード自体
読取り専用ノードとしてのインダクション 任意のノード 任意のサーバー
読取り/書込みノードとしてのインダクション 読取り/書込みピアのないノード 任意のサーバー
ノードの無効化 クラスタ内の任意のノード クラスタ内の任意のノード
ノードの有効化 無効化されたノードのみがそのノード自体を再度有効化でき、その他のノードを再度有効化することはできません 無効化されたノード自体
ノードの削除 クラスタ内の任意のノード クラスタ内のその他のノード
ノードの強制削除 クラスタ内の任意のノード クラスタ内のその他のノード
インバウンド・レプリケーションの管理 クラスタ内の任意のノード ノード自体
3.4.3.3 マルチマスター・クラスタへの候補ノードの追加

クラスタに追加される新しくインストールしたOracle Key Vaultサーバーは、候補ノードと呼ばれます。

クラスタにサーバーを追加する過程で、Oracle Key Vaultは、サーバーをクラスタのノードになる前に候補ノードに変換します。Oracle Key Vaultサーバーをクラスタにインダクションするには、コントローラ証明書、サーバーIPアドレス、リカバリ・パスフレーズなどの必要な情報を提供して、新しい候補がコントローラ・ノードと正常かつ安全に通信できるようにする必要があります。

Oracle Key Vault管理コンソールの「Cluster」タブを使用して、Oracle Key Vaultサーバーを候補ノードに変換できます。候補ノードがマルチマスター・クラスタにインダクションされるときに、そのノード上の既存のデータはすべて消去され、クラスタからのデータのコピーに置き換えられます。

3.4.3.4 マルチマスター・クラスタへのノードの追加

ノードは一度に1つずつ、最初は単一の読取り専用ノードとして、その後は読取り/書込みペア・ノードとして追加します。

Oracle Key Vaultマルチマスター・クラスタが最初に作成され、1つのノードのみが含まれている場合、その初期ノードは読取り専用ノードです。初期ノードを作成した後は、追加の読取り専用ノードまたは読取り/書込みピアをインダクションできます。これらのノードを追加した後、読取り専用ノードをさらに追加したり、読取り/書込みピアを追加できます。

初期ノードは読取り専用制限モードであり、その中にクリティカル・データを追加できないため、2番目のノードをインダクションして第1ノードと読取り/書込みペアにすることをお薦めします。クリティカル・データと非クリティカル・データを読取り/書込みノードに追加できるように、クラスタを拡張して読取り/書込みペアを確保してください。

クラスタにノードを追加する一般的なプロセスでは、一度に1つのノードを追加して、それらを読取り/書込みペアになるようにペアにします。

  1. 初期ノード(例: N1)を追加します。N1は読取り専用ノードです。
  2. 2番目のノードN2を追加します。N2は、インダクション・プロセスで読取り専用制限モードになります。

    N2をN1の読取り/書込みピアとして追加している場合は、N2がクラスタに追加されるとN1とN2の両方が読取り/書込みノードになります。それ以外の場合は、N2をクラスタに追加した後、N1およびN2は読取り専用ノードのままになります。N2をN1の読取り/書込みピアとして追加する場合は、インダクション処理時に「Add Candidate Node as Read-Write Peer」を「Yes」に設定する必要があります。N2をN1とペアにしない場合は、「Add Candidate Node as Read-Write Peer」を「No」に設定します。この例では、N2とN1が読取り/書込みピアになるものと仮定しています。

  3. 3番目のノードN3を追加します。クラスタ内の他の2つのノードがすでに読取り/書込みピアであるため、N1とN2を読取り/書込みピアにした場合は、N3を読取り専用ノードにする必要があります。

    実際には、このクラスタに複数の読取り専用ノードを追加できますが、書込み操作が行われると、クラスタ内のいくつかの読取り/書込みノードが過負荷になるため、このようにしないことをお薦めします。最適なパフォーマンスとロード・バランシングのためには、さらに多くの読取り/書込みペアが必要です。

  4. クラスタに2つ目の読取り/書込みペアを作成するには、次のノード(N4)を追加する際、「Add Candidate Node as Read-Write Peer」を「Yes」に設定して、N3とペアにするノードN4を追加します。

    この時点ではN3が読取り/書込みピアのない唯一のノードであるため、N3からノードN4を追加して2番目の読取り/書込みペアを作成する必要があります。このステップを完了すると、この段階でクラスタには2つの読取り/書込みペア(N1-N2ペアとN3-N4ペア)があります。

  5. 次のペアを作成するには、次の読取り専用ノード(N5など)を追加して、続いてノードN6を追加します。

    N6を追加するときは、「Add Candidate Node as Read-Write Peer」を「Yes」に設定してください。この時点ではN5が読取り/書込みピアのない唯一のノードであるため、ノードN6をN5に追加する必要があります。このステップを完了すると、クラスタの読取り/書込みペアは3つ(N1-N2ペア、N3-N4ペアおよびN5-N6ペア)となります。

クラスタ内の他のノードと同じバージョン、つまり、リリース18.1以降に新しくインストールされたOracle Key Vaultサーバーは、候補ノードに変換されます。候補にネットワーク・タイム・プロトコル(NTP)が構成されていることを確認してください。

他のクラスタ変更操作が進行中でないことを前提として、クラスタ内の任意のノードをコントローラ・ノードにできます。候補ノードとコントローラ・ノードは、コントローラ・ノードがインダクションの実行可能性を確認できるようにする情報を交換します。インダクションは、クラスタ・データ・セットを候補ノードにレプリケートします。正常にインダクションした後は、クラスタ全体の構成設定を使用するようにノードを構成できます。クラスタ・データ・セットには、次のコンポーネントが含まれますが、これらに限定されているわけではありません。

  • 証明書、キー、ウォレットおよびその他のセキュリティ・オブジェクト
  • ユーザーとユーザー・グループ
  • エンドポイントおよびエンドポイント・グループ情報
  • 監査データ
  • クラスタ名およびクラスタ・ノードの詳細
  • クラスタ設定

コントローラ・ノードは、候補ノードのノードIDおよびクラスタ・サブグループを割り当てます。インダクション時にコントローラ・ノードが既存のクラスタ・サブグループを提供する場合、候補ノードはそのサブグループの一部になります。コントローラ・ノードが、存在しないクラスタ・サブグループの名前を指定した場合は、クラスタ・サブグループがインダクション・プロセスの一環として作成され、候補ノードがクラスタ・サブグループに追加されます。必要に応じて、すべてのエンドポイントを1つのサブグループに関連付けることができます。たとえば、データ・センターAのすべてのエンドポイントを1つのサブグループに配置し、データ・センターBのすべてのエンドポイントを別のサブグループに配置できます。同じサブグループ内のエンドポイントは、他のサブグループのノードに接続する前に、そのサブグループ内のノードへの接続が優先されます。

その読取り/書込みピアが削除されると、読取り/書込みノードは読取り専用ノードになります。この読取り専用ノードを使用して、別の読取り/書込みペアを形成できます。

3.4.4 既存のデプロイメントからのクラスタへの移行

既存のOracle Key Vaultデプロイメントは、マルチマスター・クラスタ・ノードに移行できます。

親トピック: マルチマスター・クラスタの構築および管理

3.4.4.1 マルチマスター・クラスタへのOracle Key Vaultスタンドアロン・サーバーの変換

古いリリースのスタンドアロンOracle Key Vaultデプロイメントをマルチマスター・デプロイメントに移行できます。

まず、サーバーを最新のOracle Key Vaultリリースにアップグレードする必要があります。アップグレードを完了すると、初期ノードに変換できます。

Oracle Key Vaultサーバー・デプロイメントがすでに最新のリリースである場合は、それを初期ノードに直接変換できます。

初期ノードには、既存のOracle Key Vaultスタンドアロン・デプロイメントのすべてのデータが保持されます。クラスタの初期ノードを作成した後、必要に応じて、このクラスタにノードをさらに追加できます。追加する新しいノードが、初期ノードの現在のバージョンでインストールされていることを確認します。

3.4.4.2 プライマリ・サーバーからマルチマスター・クラスタへの変換

Oracle Key Vaultプライマリ・スタンバイ・デプロイメントは、マルチマスター・デプロイメントに移行できます。

最初に、プライマリ/スタンバイ・サーバー構成のペアを解除する必要があります。次に、ペアになっていない以前のプライマリ・サーバーを最新のOracle Key Vaultリリースにアップグレードします。(または、アップグレードを実行してから、プライマリ/スタンバイ・サーバー構成のペアを解除することもできます)。これらのステップを完了すると、アップグレードした以前のプライマリ・サーバーを初期ノードに変換できます。

最新のリリースのOracle Key Vaultがプライマリ/スタンバイ・デプロイメント内にある場合は、マルチマスター・クラスタに移動する前にそのペアを解除する必要もあります。その後、以前のプライマリ・サーバーを初期ノードに直接変換できます。

この種類の移行を実行する前に、プライマリ/スタンバイ・デプロイメントで現在使用されているサーバーをバックアップしてください。

3.5 Oracle Key Vaultマルチマスター・クラスタのデプロイメント・シナリオ

マルチマスター・クラスタ・ノードはすべて、アクティブかつ独立してエンドポイントにサービスを提供できます。

これは、クラスタ間での継続的なレプリケーションを通して同じクラスタ・データセットを維持しながら実現できます。マルチマスター・クラスタのデプロイメント・シナリオは、小規模な2ノード・クラスタから、データ・センター全体にわたる大規模な16ノード・デプロイメントまであります。

親トピック: Oracle Key Vaultマルチマスター・クラスタの概念

3.5.1 デプロイメントでのクラスタ・サイズおよび可用性

一般に、エンドポイントに対するクリティカル・データの可用性は、クラスタのサイズが大きくなるにつれて増加します。

パッチ適用やアップグレードなどのメンテナンスを実行するために、クラスタから読取り/書込みペアの両方のノードを同時に無効にすることが必要になる場合があります。ノードが2つのみのクラスタがある場合は、エンドポイントに停止時間が発生する可能性を意味します。

2ノード・クラスタは、エンドポイントの停止時間が重要でない開発およびテスト環境に適しています。クリティカル・データの追加や更新がまれであったり、制御可能な小規模なデプロイメントでは、3ノード・クラスタを適用できます。負荷の高い大規模なデプロイメントでは、エンドポイントの継続性を確保するために、少なくとも2つの読取り/書込みペアをデプロイしてください。

1つの読取り/書込みペアと1つの読取り専用ノードがある3ノード・クラスタは、クリティカル・データが追加または更新されないかぎりエンドポイントの継続性が維持されるため、2ノード・クラスタより優れています。

2つの読取り/書込みペアの4ノード・クラスタは、ノードがメンテナンスされている間、すべてのエンドポイント操作に継続性を提供します。

クラスタは、理想的には読取り/書込みのペアで構成されるようにしてください。データ・センター間のネットワーク・レイテンシまたはネットワークの中断がほとんど問題にならない場合は、データ・センター間で読取り/書込みペアをデプロイしてください。読取り/書込みペアの1つのノードが失われる障害の場合、キーは読取り/書込みピアに保持されます。一方、ネットワーク・レイテンシまたは中断が懸念される場合は、同じデータ・センターに読取り/書込みペアを配置してください。読取り/書込みペアが失われる障害が発生すると、キーなどのデータが失われる可能性があります(作成されたデータが他のノードに非同期にレプリケートされる前に、その障害が発生していた場合)。

親トピック: Oracle Key Vaultマルチマスター・クラスタのデプロイメント・シナリオ

3.5.2 2ノード・クラスタ・デプロイメント

2つのOracle Key Vaultノードで形成される単一の読取り/書込みペアは、最も単純なマルチマスター・クラスタです。

2ノード・マルチマスター・クラスタは、2つのノードのみが存在する点で、標準のプライマリ・スタンバイ環境と似ています。大きな違いは、スタンバイがパッシブであるプライマリ・スタンバイ構成とは異なり、両方のノードがアクティブで、同時にエンドポイント・リクエストに応答できることです。

2ノード・マルチマスター・クラスタを使用すると、プライマリ・スタンバイ環境に比べて次の利点があります。

  • プライマリ・サーバーのみに問合せを実行できるプライマリ・スタンバイ構成とは異なり、エンドポイントによって両方のノードをアクティブに問合せおよび更新できます。
  • マルチマスター・クラスタは、停止時間なしで3つ以上のノードに拡張できます。
  • ノードが別々のデータ・センターにある場合、エンドポイントは、ネットワークを通じてプライマリ・サーバー・ノードに到達するのではなく、同じサブグループ内のノードとの相互作用を優先できます。

次の図は、2ノードの単一データ・センターに使用されるデプロイメントを示しています。

図3-1 単一データ・センターでのOracle Key Vaultマルチマスター・クラスタ・デプロイメント

図3-1の説明が続きます
「図3-1 単一データ・センターでのOracle Key Vaultマルチマスター・クラスタ・デプロイメント」の説明

このシナリオでは、Atlantaデータ・センターは次のように3つのデータベースをホストします。

  • 単一インスタンス・データベース
  • マルチインスタンスのOracle Real Applications Clusters (Oracle RAC)データベース
  • Oracle RACデータベース用のマルチインスタンス・スタンバイ・データベース

Oracle RACデータベースおよび関連するスタンバイ・データベースは、Atlanta Bを使用して登録されたものです。Atlanta BとAtlanta Cは異なるクラスタ・サブグループ内にあるため、Oracle RACデータベースおよび関連するスタンバイ・データベースのエンドポイント・ノード・スキャン・リストの先頭にはAtlanta Bがあり、Atlanta CよりもAtlanta Bへの接続が優先されます。各Oracle RACインスタンスが、Atlanta Cにも接続できることは示されていません。

Atlanta BおよびAtlanta Cというラベルが付いた2つのOracle Key Vaultサーバーがあり、Oracle Key Vaultノードの読取り/書込みペアを表しています。これらのノードは、読取り/書込みピアであることを示す双方向の線で接続されています。読取り/書込みピア・ノードは同期しているため、あるノードへの更新を別のノードにレプリケートして、更新が成功したと見なされる前に、別のノードで検証できます。

下側のデータベース・インスタンスはAtlanta Cノードを使用して登録されたものです。この接続を示すために、このデータベースはOracle Key Vault Atlanta Cへの矢印で接続されています。Atlanta BとAtlanta Cは異なるクラスタ・サブグループ内にあるため、このデータベースの場合、Atlanta Cはエンドポイント・ノード・スキャン・リストの先頭にあります。つまり、このデータベースではAtlanta Cへの接続が優先されます。

いずれかのOracle Key Vaultノードがオフラインの場合(たとえば、メンテナンスの場合)、すべてのエンドポイントは別の使用可能なOracle Key Vaultサーバーに自動的に接続します。

親トピック: Oracle Key Vaultマルチマスター・クラスタのデプロイメント・シナリオ

3.5.3 2つのデータ・センター間の中規模クラスタ・デプロイメント

2データ・センターの構成は、高可用性、障害時リカバリおよび負荷分散を提供します。

少なくとも2つの読取り/書込みペアが必要です。読取り/書込みペアは、読取り/書込みピアとして新しいノードを読取り専用ノードとペアにしたときにのみ作成されます。ベスト・プラクティスとしては、障害時リカバリを懸念している場合は異なるデータ・センターでピアを構成し、ネットワーク待機時間やネットワークの中断を懸念している場合は同じデータ・センターに読取り/書込みピアを配置します。同じデータ・センターのクラスタ・ノードは、同じクラスタ・サブグループに属しているようにします。データ・センターのすべてのエンドポイントが、そのデータ・センターのノードと同じクラスタ・サブグループにあることを確認する必要があります。これにより、特定のデータ・センター内のノードは、同じデータ・センターのエンドポイントのエンドポイント・ノード・スキャン・リストの先頭にあることが保証されます。

大規模なデプロイメントの場合、高可用性のためにデータ・センター内に少なくとも4つのOracle Key Vaultサーバーを持つことをお薦めします。これにより、サーバーの1つに障害が発生した場合、キー更新用に追加のサーバーを使用できます。データベース・エンドポイントを登録するとき、これらのエンドポイントをOracle Key Vaultサーバー間で均等に分散します。たとえば、データ・センターに登録するデータベース・エンドポイントが1000個あり、それらに対応するためのOracle Key Vault 4台のサーバーがある場合、4台のサーバーそれぞれに250個のエンドポイントをエンロールします。

各エンドポイントは、最初にローカル・データ・センターのOracle Key Vaultノードに接続します。停止によって1つのデータ・センターですべてのOracle Key Vaultノードが使用できない場合は、別のデータ・センターへの接続が使用可能なかぎり、エンドポイント・ノード・スキャン・リストによって、別のデータ・センターの使用可能なOracle Key Vaultノードにエンドポイントがリダイレクトされます。

図3-2は、2つのデータ・センターを使用したデプロイメント・シナリオを示しており、各データ・センターには他のデータ・センター内の読取り/書込みノードとペアになっている2つの読取り/書込みノードがあります。データ・センターでは、ロード・バランシング、信頼性または拡張の目的で、必要に応じて1つ以上の読取り専用ノードをホストすることもできます。次の図で説明するシナリオでは、各データ・センターが単一の読取り専用ノードをホストしています。

図3-2 2つのデータ・センター間のOracle Key Vaultマルチマスター・クラスタ・デプロイメント


図3-2の説明が続きます
「図3-2 2つのデータ・センター間のOracle Key Vaultマルチマスター・クラスタ・デプロイメント」の説明

このシナリオでは、Atlantaデータ・センターとBerkeleyデータ・センターの両方が、次のように3つのデータベースをホストしています。

  • 単一インスタンス・データベース
  • マルチインスタンスのOracle RACデータベース
  • Oracle RACデータベース用のマルチインスタンス・スタンバイ・データベース

Oracle RACデータベースをスタンバイ・データベースに接続する点線は、データベース・トランザクションを表しています。このデータは、データベースからスタンバイへの一方向のみに移動することに注意してください。Atlantaデータ・センターのOracle RACデータベースはBerkeleyのスタンバイ・データベースにデータを送信し、BerkeleyのOracle RACデータベースはAtlantaのスタンバイ・データベースにデータを送信します。

Atlantaデータ・センターとBerkeleyデータ・センターには、それぞれ3つのOracle Key Vaultノードがあり、2つは読取り/書込み、1つは読取り専用で、すべてが同じクラスタ内にあります。これらのノードは次のように構成されています。

  • Atlanta A Read-Only NodeとBerkeley A Read-Only Nodeは読取り専用ノードで、クリティカル・データの追加または更新は読取り/書込みノードから読取り専用ノードに一方向に移動します。
  • Atlanta B読取り/書込みノードは、Berkeley B読取り/書込みノードがある読取り/書込みピアです。これら2つのノード間の接続は双方向であり、常に同期化できます。
  • Atlanta C読取り/書込みノードは、Berkeley C読取り/書込みノードがある読取り/書込みピアです。これら2つのノード間の関係は、Atlanta BノードとBerkeley Bノード間の関係と同様に動作します。

すべてのノードがその他のすべてのノードとの間でデータをレプリケートし、レプリケートされたデータを受信します。わかりやすさを維持するために、具体的にはこれらの接続の一部のみを示しています。

  • 2つのデータ・センターのAtlanta B読取り/書込みノードとBerkeley B読取り/書込みノード間の読取り/書込みペア接続(データ・フローは双方向)
  • 2つのデータ・センターのAtlanta C読取り/書込みノードとBerkeley C読取り/書込みノード間の読取り/書込みペア接続(データ・フローは双方向)
  • Atlantaデータ・センターのAtlanta B読取り/書込みノードとAtlanta C読取り/書込みノード間の通常の接続(データ・フローは双方向)
  • Berkeleyデータ・センターのBerkeley B読取り/書込みノードとBerkeley C読取り/書込みノード間の通常の接続(データ・フローは双方向)
  • Atlantaデータ・センターのAtlanta B読取り/書込みノードからAtlanta A読取り専用ノードへの通常の接続(クリティカル・データのフローは読取り/書込みノードから読取り専用ノードへの一方向)
  • Berkeleyデータ・センターのBerkeley B読取り/書込みノードからBerkeley A読取り専用ノードへの通常の接続(クリティカル・データのフローは読取り/書込みノードから読取り専用ノードへの一方向)

同じデータ・センター内のノードには、同じクラスタ・サブグループが割り当てられています。たとえば、Atlantaデータ・センターのノードにはクラスタ・サブグループAtlantaが指定されていて、Berkeleyデータ・センターのノードにはクラスタ・サブグループBerkeleyが指定されています。Atlantaデータ・センターにあるエンドポイントは、同じAtlantaデータ・センターに存在するOracle Key Vaultノードのいずれかを使用してエンロールされるため、エンドポイントは同じデータ・センター内のノードに優先的に接続されます。Berkeleyデータ・センターのエンドポイントについても、それぞれに同じことが当てはまります。図3-2には、次の接続が示されています。これは、各クライアント・エンドポイント・ノード・スキャン・リストの最初のエントリを表しています。エンドポイントがクラスタ内の少なくとも1つのノードと同じクラスタ・サブグループ内にある場合、エンドポイント・ノード・スキャン・リストの最初のエントリは、エンドポイントと同じクラスタ・サブグループ内のノードからランダムに選択される点に注意してください。

  • Atlantaデータ・センター:
    • Oracle RACデータベースは、Atlanta B読取り/書込みノードに接続し、データ・フローは双方向になります。
    • Atlanta A読取り専用ノードはスタンバイに接続し、データ・フローは読取り専用ノードからスタンバイへの一方向になります。
    • データベースはAtlanta C読取り/書込みノードに接続し、データ・フローは双方向になります。
  • Berkeleyデータ・センター:
    • Oracle RACデータベースはBerkeley B読取り/書込みノードに接続し、データ・フローは双方向になります。
    • Berkeley A読取り専用ノードはスタンバイに接続し、データ・フローは読取り専用ノードからスタンバイへの一方向になります。
    • データベースはBerkeley C読取り/書込みノードに接続し、データ・フローは双方向になります。

Atlanta C読取り/書込みノードにアクセスできない場合や必要なキーがない場合、そのノードに接続しようとしていたデータベースは、別のOracle Key Vaultノードに接続してキーをフェッチします。

関連項目

親トピック: Oracle Key Vaultマルチマスター・クラスタのデプロイメント・シナリオ

3.6 マルチマスター・クラスタ機能

Oracle Key Vaultには、クラスタ内の矛盾の解決および名前の競合の解決に役立つ機能と、エンドポイント・ノード・スキャン・リストが用意されています。

親トピック: Oracle Key Vaultマルチマスター・クラスタの概念

3.6.1 マルチマスター・クラスタのクラスタの矛盾の解決

ネットワークの停止によって、クラスタ内のデータに不整合が発生することがありますが、停止から回復してネットワーク接続が再開されると、データの整合性が再度維持されます。

ノードは、クラスタ内の他のノードから自発的または意図せずに切断されることがあります。ノードが自発的に切断された後にクラスタに対してノードが使用可能になると、クラスタ内のすべてのデータ変更がそのノードにレプリケートされます。Oracle Key Vaultノードには、ネットワークの中断、停電およびその他の切断がいつでも発生する可能性があり、クラスタ内の他のノードからの意図しない切断を引き起こします。このような障害により、マルチマスター・クラスタ内のデータ・レプリケーション・プロセスに割込みが発生します。一時的な障害では、クラスタとの矛盾が常に発生するわけではありません。問題が対処され次第、データ・レプリケーション・プロセスは停止した時点から再開されます。これにより、切断後も、切断されたOracle Key Vaultノードは最終的にクラスタ内の他のノードと同期できます。

読取り/書込みノードで行われた変更は、他のペアの読取り/書込みノードにレプリケートされることが保証されます。そのため、読取り/書込みノードに障害が発生したとしても、データはクラスタ内の少なくとも1つの別のノードで使用できます。

親トピック: マルチマスター・クラスタの機能

3.6.2 マルチマスター・クラスタの名前の競合の解決

オブジェクトが異なるノードの別のオブジェクトと同じ名前を持つ場合は、名前の競合が発生することがあります。

ユーザーは、仮想ウォレット、ユーザー、ユーザー・グループ、エンドポイントおよびエンドポイント・グループの作成時に名前を指定する必要があります。名前の競合は、オブジェクトがレプリケートされる前に、複数のユーザーが別々のノードに同じ名前で同じタイプのオブジェクトを作成したときに発生します。オブジェクトが他のノードにレプリケートされている場合は、名前が重複するオブジェクトの作成は防止されます。ただし、Oracle Key Vaultクラスタでのレプリケーションは瞬間的ではないため、レプリケーション時間(数秒程度)の間に、同じ名前の別のオブジェクトがこのクラスタに作成されている可能性があります。この場合、名前の競合になります。名前の競合には明白なデメリットがあります。たとえば、システムでは、名前が重複する2つのオブジェクトへの参照を区別できません。したがって、クラスタ内の矛盾を回避するために名前の一意性が強制されます。その他すべてのオブジェクト名は、ウォレット、エンドポイント・グループ、ユーザー・グループ、その他のオブジェクト・タイプなど、そのオブジェクト・タイプ内で一意にする必要があります。たとえば、クラスタ内で2つのウォレットが同じ名前を持つことはありません。ユーザー名とエンドポイント名は競合しないようにしてください。

それでも名前の競合がまれに発生することがあります。発生すると、Oracle Key Vaultでこの名前の競合が検出され、アラートが生成されます。その後、Oracle Key Vaultは、後から作成された競合するオブジェクトの名前に_OKVxxを追加します(xxは、名前変更したオブジェクトが作成されていたノードのノードIDです)。この推奨オブジェクト名を受け入れるか、オブジェクトの名前を変更するかを選択できます。

競合するオブジェクト名を受諾または変更するには、「Cluster」タブをクリックし、左側のナビゲーション・バーから「Conflict Resolution」をクリックし、すべての競合を確認して解決します。

親トピック: マルチマスター・クラスタの機能

3.6.3 エンドポイント・ノード接続リスト(エンドポイント・ノード・スキャン・リスト)

エンドポイント・ノード・スキャン・リストは、エンドポイントが接続可能なノードのリストです。

エンドポイントは、ウォレット、キー、証明書および資格証明を管理またはアクセスするために、Oracle Key Vaultサーバーまたはノードに接続します。

スタンドアロン環境では、エンドポイント・ノード・スキャン・リストにはエントリが1つあります。プライマリ/スタンバイ構成では、エンドポイントは2つのサーバーのいずれかに接続できます。

Oracle Key Vaultマルチマスター・クラスタでは、エンドポイント・ノード・スキャン・リストはクラスタ内のすべてのノードのリストです。読取り専用ノード・リストと読取り/書込みノード・リストがあります。ノード・サブグループの割当ておよびノード・モードは、エンドポイント・ノード・スキャン・リスト内のノードの順序に影響します。このリストは、エンドポイントのエンロール時にエンドポイントに使用可能になります。リストは、クラスタ内の使用可能なノードを反映するように自動的に維持されます。このリストによってクラスタに対する変更を追跡し、エンドポイントで使用できるようにします。次のイベントは、エンドポイント・ノード・スキャン・リストへの変更をトリガーします。

  • ノードの追加やノードの削除などによるクラスタ・サイズの変更
  • ノードのモードに対する変更(たとえば、読取り専用制限モードのノードが読取り/書込みモードに変更された場合)
  • 最後のエンドポイント更新からの1時間の経過
  • エンドポイントまたはノードに割り当てられたクラスタ・サブグループに対する変更

エンドポイントは、次回の成功した空でないレスポンスとともに、更新されたスキャン・リストを取得します。ノードによってスキャン・リストが送信されると、エンドポイントに送信されたものとしてスキャン・リストにマークが付きます。エンドポイントに送信され、ノードに送信済とマークされたスキャン・リストがエンドポイントに適用されない可能性があります。そのため、クラスタ・ノードまたはいずれかのクラスタ・ノードのモードに変更がない場合も、クラスタはスキャン・リストをエンドポイントに定期的に送信します。

親トピック: マルチマスター・クラスタの機能

3.7 クラスタ管理情報

「 Cluster Management」ページには、クラスタの概要と各ノードのステータスが表示されます。 

クラスタの詳細セクションからクラスタを管理することもできます。ノードがクラスタ操作を実行している場合、そのノードはコントローラ・ノードになります。

クラスタ全体のレプリケーションには時間を要するため、「Cluster Management」ページが新しいクラスタ・ステータスでリフレッシュされるまでに時間がかかる場合があります。モニタリング・ページのレプリケーション・ラグは、遅延の推定に役立ちます。

「Cluster Management」ページを表示するには、「Cluster」タブをクリックし、左側のナビゲーション・バーから「Management」をクリックします。

21_cluster_management.pngの説明が続きます
図21_cluster_management.pngの説明_

Cluster Information

  • Cluster Name: クラスタの名前。

  • Cluster Subgroups: クラスタ内のすべてのサブグループ。

  • Maximum Disable Node Duration: ノードが使用不可になるまでにノードを無効化しておける最大時間(時間単位)。

  • Cluster Version: クラスタが動作しているOracle Key Vaultのバージョン。

Current Node Information

  • Node Name: このノードの名前。

  • Node Type: ノードのタイプ(読取り専用、読取り/書込みなど)。

  • Cluster Subgroup: このノードが属するサブグループ。

Cluster Details

  • Select Node: 削除、強制削除、無効化など、特定の操作の対象ノードを選択する場合に使用します。

  • Node ID: ノードのID。

  • Node Name: ノードの名前。ノード名をクリックすると、そのノードの「Cluster Management」ページに移動します。

  • IP Address: ノードのIPアドレス。

  • Mode: ノードの動作モード(読取り/書込みや読取り専用制限など)。

  • Status: ノードのステータス(active、pairing、disabling、disabled、enabling、deleting、deletedなど)。

  • Read-Write Peer: ノードの読取り/書込みピア。空白の場合、読取り/書込みピアはありません。

  • Cluster Subgroup: ノードが属するサブグループ。これを変更するには、1)ノードの横のチェック・ボックスを選択、2)「Edit」ボタンをクリックしてウィンドウを表示、3)フィールドに新しいクラスタ・サブグループを入力、4)「Save」をクリックします。

  • Join Date: ノードがクラスタに追加された日時またはノードが有効化された直近の日時

  • Disable Date: ノードを無効にした日時。

  • Node Version: Oracle Key Vaultノードの現在のバージョン。

親トピック: Oracle Key Vaultマルチマスター・クラスタの概念