3 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では、クラスタ内の矛盾の解決およびネーミング競合の解決に役立つ機能と、エンドポイント・ノード・スキャン・リストが提供されています。

3.1 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のノードを保持できます。

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

• ゼロ・データ損失

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

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

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

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

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

• メンテナンス

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

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

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読取り専用ノード
  読取り専用ノードでは、ユーザーは非クリティカル・データを追加または更新できますが、クリティカル・データは追加または更新できません。
• クラスタ・ノードのモード・タイプ
  Oracle Key Vaultでは、クラスタ・ノードに対して読取り専用制限モードまたは読取り/書込みモードの2種類のモードがサポートされます。
• 異なるモードのクラスタ・ノードで許可された操作
  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管理コンソールでは使用できません。ノードにはパッシブ・スタンバイ・サーバーを使用できません。

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

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

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

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

Oracle Key Vaultマルチマスター・クラスタのノードは、相互にデータを非同期でレプリケートします。唯一の例外は、データを読取り/書込みピアにレプリケートすることです。非同期レプリケート操作の結果として発生する様々な制限があります。

クラスタ内のノードのIPアドレスは静的であり、ノードをクラスタに追加した後は変更できません。ノードに別のIPアドレスが必要な場合は、そのノードをクラスタから削除し、正しいIPアドレスを使用して新しいノードを追加するか、正しいIPアドレスを使用して、削除したノードを再イメージ化してからクラスタに再度追加します。

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

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

Oracle Key Vaultクラスタは、インダクション・プロセス中にコントローラ・ノードがアクセスする必要のあるノードIDを削除しようとするなど、サポートされていないアクションをユーザーが実行できないように可能なかぎり対処します。同様に、マルチマスター・クラスタでは、読取り/書込みピアがすでに存在する場合、ユーザーは2つ目の読取り/書込みピアを追加できません。

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

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

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

ノードをマルチマスター・クラスタに追加すると、ノードはサブグループに割り当てられます。ノードの存続期間中は割当てを変更できません。ノードのクラスタ・サブグループ割当ては個々のノードのプロパティであり、読取り/書込みペアのメンバーは異なるクラスタ・サブグループに存在できます。

クラスタ・サブグループは、エンドポイント・アフィニティの概念を表します。ノードのクラスタ・サブグループ割当てを使用して、エンドポイントのノード・スキャン・リストの検索順序を設定します。エンドポイントが追加されたノードと同じクラスタ・サブグループ内のノードは、エンドポイントに対してローカルとみなされます。ローカル・サブグループに存在しないノードと通信する前に、エンドポイントのローカル・サブグループ内のノードが最初にスキャンされます。

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

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

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サーバーで初期クラスタが作成された後、クラスタに必要な様々なタイプのノードを追加できます。
• マルチマスター・クラスタの初期ノードの作成
  マルチマスター・クラスタの初期ノードは、初期ノードにする前に特定の要件に従う必要があります。
• マルチマスター・クラスタの拡張
  クラスタを初期化した後、読取り/書込みペアまたは読取り専用ノードとして最大15個のノードを追加することで、クラスタを拡張できます。
• 既存のデプロイメントからクラスタへの移行
  既存の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. プライマリ・サーバーとスタンバイ・サーバーの両方をリリース18.1にアップグレードします。
  3. ペアのプライマリ・サーバーとスタンバイ・サーバーのペアを解除します。(サーバーをアンペアする前に、アンペア・プロセスに関する既知の問題について、『Oracle Key Vaultリリース・ノート』を参照してください。)
  4. クラスタの最初のノードとなるようにプライマリ・サーバーを変換します。
• 方法2:
  1. サーバーをバックアップします。
  2. ペアのプライマリ・サーバーとスタンバイ・サーバーのペアを解除します。
  3. 以前のプライマリ・サーバーをリリース18.1にアップグレードします。
  4. クラスタの最初のノードとなるようにプライマリ・サーバーを変換します。

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

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

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

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

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

クラスタを作成するには、Oracle Key Vault管理コンソールの「Cluster」タブで「Add Node」ボタンを選択します。

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

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

• マルチマスター・クラスタの拡張について
  ノード・インダクションは、マルチマスター・クラスタ・ノードとして動作するようにOracle Key Vaultサーバーを構成するプロセスです。
• コントローラ・ノードを使用したクラスタ再構成の変更の管理
  コントローラ・ノードは、ノードの追加、有効化、無効化、削除など、クラスタ再構成の変更を制御または管理するノードです。
• マルチマスター・クラスタへの候補ノードの追加
  クラスタに追加される新しくインストールしたOracle Key Vaultサーバーは、候補ノードと呼ばれます。
• マルチマスター・クラスタへのノードの追加
  ノードを一度に1つずつ、最初は単一の読取り/書込みノードとして、その後は読取り/書込みペア・ノードとして追加します。

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つのクラスタ操作を実行することをお薦めします。各同時操作には、独自のコントローラ・ノードがあります。1つのコントローラ・ノードは、一度に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のすべてのエンドポイントを別のサブグループに配置できます。同じサブグループ内のエンドポイントは、他のサブグループのノードに接続する前に、そのサブグループ内のノードへの接続が優先されます。

読取り/書込みモードまたは読取り専用制限モードの読取り/書込みノードであるコントローラ・ノードは、読取り専用ノードのみを追加できます。読取り専用ノードであるコントローラ・ノードは、読取り/書込みペアを形成するために、1つの候補ノードを自分の読取り/書込みピアとして追加できます。ノードは、インダクション・プロセス中に読取り/書込みペアのメンバーになるため、読取り/書込みノードになります。読取り専用ノードであるコントローラ・ノードは、追加のノードを読取り専用ノードとして追加でき、後で新しい読取り/書込みペアを形成する際に使用できます。

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

次の点に注意してください。

• コントローラが既存の読取り/書込みペアのメンバーである場合、追加されるノードは読取り専用ノードとしてインダクションされます。
• コントローラが既存の読取り/書込みペアのメンバーでない場合、追加されるノードは読取り専用ノードにすることも、コントローラ・ノードへの読取り/書込みピアにすることも可能です。

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

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

• Oracle Key Vaultスタンドアロン・サーバーからマルチマスター・クラスタへの変換
  古いリリースのスタンドアロンOracle Key Vaultデプロイメントをマルチマスター・デプロイメントに移行できます。
• プライマリ/スタンバイ・サーバーからマルチマスター・クラスタへの変換
  18.1より前のリリースのOracle Key Vaultプライマリ/スタンバイ・デプロイメントをマルチマスター・デプロイメントに移行できます。

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

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

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

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

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

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

18.1より前のリリースのOracle Key Vaultのプライマリ/スタンバイ・デプロイメントをマルチマスター・デプロイメントに移行できます。

最初に、プライマリ/スタンバイ・サーバー構成のペアを解除する必要があります。次に、ペアになっていない以前のプライマリ・サーバーをOracle Key Vault 18.1サーバーにアップグレードしてください。以前のプライマリ・サーバーをOracle Key Vaultリリース18.1にアップグレードした後は、初期ノードに変換できます。

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

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

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

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

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

• デプロイメントでのクラスタ・サイズおよび可用性
  一般に、エンドポイントに対するクリティカル・データの可用性は、クラスタのサイズが大きくなるにつれて増加します。
• 2ノード・クラスタ・デプロイメント
  2つのOracle Key Vaultノードで構成される単一の読取り/書込みペアが、最も単純なマルチマスター・クラスタです。
• 2つのデータ・センター間の中規模クラスタ・デプロイメント
  2データ・センターの構成が、高可用性、障害時リカバリおよび負荷分散を提供します。

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

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

通常は、パッチ適用やアップグレードなどのメンテナンスを受けるために、クラスタから読取り/書込みペアを一緒に削除する必要があります。2ノード・クラスタでは使用率が向上しますが、エンドポイントで停止時間が発生することになります。

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

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

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

クラスタは、理想的には読取り/書込みのペアで構成されるようにしてください。データ・センター間のネットワーク・レイテンシまたはネットワークの中断がほとんど問題にならない場合は、データ・センター間で読取り/書込みペアをデプロイしてください。障害の場合、キーは読取り/書込みピアで保持されます。一方、ネットワーク・レイテンシまたは中断が懸念される場合は、同じデータ・センターに読取り/書込みペアを配置してください。キーが作成されてからレプリケーション時間内に障害が発生した場合、読取り/書込みペアが消失する障害によって鍵が消失することがあります。

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

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

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

2つの読取り専用ノードで構成されるクラスタは、クリティカル・データを追加できないため、有益ではありません。2ノード・マルチマスター・クラスタを使用すると、プライマリ・スタンバイ環境に比べて次の利点があります。

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

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

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

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

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

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

Atlanta BおよびAtlanta Cというラベルが付いた2つのOracle Key Vaultサーバーがあり、Oracle Key Vaultノードの読取り/書込みペアを表しています。これらのノードは、読取り/書込みピアであることを示す双方向の線で接続されています。読取り/書込みピア・ノードは同期ノードで、トランザクションはすぐに実行されます。

Oracle RACデータベースおよび関連するスタンバイ・データベースは、このデータベースのエンドポイント・ノード・スキャン・リストの先頭にあるOracle Key Vaultにエンロールされます。各Oracle RACインスタンスがOracle Key Vaultサーバーへの個別の接続を保持していることは表示されていません。

データベース・インスタンスはAtlanta Cノードにエンロールされています。この接続を示すために、データベースは、このデータベースのエンドポイント・ノード・スキャン・リストの先頭にあるOracle Key Vault Atlanta Cに矢印で接続されています。

どちらかのOracle Key Vaultサーバーが(おそらくメンテナンスのために)オフラインになっている場合、すべてのエンドポイントが他方の(使用可能な)Oracle Key Vaultサーバー(Atlanta B)に自動的に接続されます。

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

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

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

大規模なデプロイメントの場合、高可用性のためにデータ・センター内に少なくとも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 2つのデータ・センター間のOracle Key Vaultマルチマスター・クラスタ・デプロイメント」の説明

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

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

Atlantaデータ・センターとBerkeleyデータ・センターには、それぞれ3つのOracle Key Vaultノードがあります。これらのノードは次のように構成されています。

• Atlanta Aの読取り専用ノードおよびBerkeley Bの読取り専用ノードは、読取り専用制限ノードです。
• Atlanta B読取り/書込みノードは、Berkeley B読取り/書込みノードがある読取り/書込みピアです。これらの2つのノードは1つのクラスタ内にあります。この接続は双方向であり、これら2つのノードを常に同期化できます。これらのノードを拡張して、読取り専用ノードを最大16個まで含めることができます。これらのノードはすべて相互に通信できます。
• 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 A読取り/書込みノードとAtlanta B読取り/書込みノード間の通常の接続
• Berkeleyデータ・センターのBerkeley A読取り/書込みノードとBerkeley B読取り/書込みノード間の通常の接続

エンドポイント・ノード・スキャン・リストは各エンドポイントに一意で、データベースからのエンドポイント接続が確立されるOracle Key Vaultノードの順序を制御します。各エンドポイントは、すべてのOracle Key Vaultノードに接続できます。他のクラスタ・サブグループのノードに移動する前に、エンドポイントが追加されたノードと同じクラスタ・サブグループ内のノードにプリファレンスが指定されます。図3-2には、次の接続が表示されています。これは、各クライアント・エンドポイント・ノード・スキャン・リストの最初のエントリを表しています。

• Atlantaデータ・センター:
  • Oracle RACデータベースは、Atlanta A読取り専用ノードに接続します。
  • スタンバイ・サーバーはAtlanta A読取り専用ノードに接続します。
  • データベースはAtlanta C読取り/書込みノードに接続します。
• Berkeleyデータ・センター:
  • Oracle RACデータベースはBerkeley A読取り専用ノードに接続します。
  • スタンバイ・サーバーはBerkeley B読取り/書込みノードに接続します。
  • データベースはBerkeley C読取り/書込みノードに接続します。

Atlanta C読取り/書込みノード(Berkeley C読取り/書込みノードを持つ読取り/書込みピア)に到達できない場合、または必要なキーがない場合、Atlantaデータ・センター接続先データベースは、キーをフェッチするために他のOracle Key Vaultノードに接続します。

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

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

• マルチマスター・クラスタでのクラスタの矛盾の解決
  ネットワークの停止では、クラスタ内のデータに矛盾が発生する可能性がありますが、停止時間が終了すると、再びデータの矛盾がなくなります。
• マルチマスター・クラスタでのネーミング競合の解決
  オブジェクトが異なるノードの別のオブジェクトと同じ名前を持つ場合は、ネーミング競合が発生することがあります。
• エンドポイント・ノード接続リスト(エンドポイント・ノード・スキャン・リスト)
  エンドポイント・ノード・スキャン・リストは、エンドポイントが接続できるノードのリストです。

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

ネットワークの停止では、クラスタ内のデータに矛盾が発生する可能性がありますが、停止時間が終了すると、再びデータの矛盾がなくなります。

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

読取り/書込みノードで行われた変更は、他のペアの読取り/書込みノードにレプリケートされることが保証されます。したがって、読取り/書込みノードに障害が発生した場合も、クラスタ内の他のノードでデータは使用可能です。

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

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

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

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

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

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

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

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

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

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

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

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