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マルチマスター・クラスタのデプロイメント・シナリオ
  マルチマスター・クラスタ・ノードはすべて、アクティブかつ独立してエンドポイントにサービスを提供できます。
• マルチマスター・クラスタの機能
  Oracle Key Vaultでは、クラスタ内の矛盾の解決およびネーミング競合の解決に役立つ機能と、エンドポイント・ノード・スキャン・リストが提供されています。
• クラスタ管理情報
  「Cluster Management」ページには、クラスタの概要と各ノードのステータスが簡潔に表示されます。

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サーバーは、クラスタと同じリリース・レベルである必要があります。

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

クラスタ内の各ノードは、クラスタ全体の継続的なレプリケーションを通して同じデータセットを維持しながら、アクティブかつ独立してエンドポイントにサービスを提供できます。可能な最小の構成は2ノード・クラスタで、最大の構成では、Oracle OCI、Microsoft AzureおよびAmazon AWSのオンプレミス・データ・センターまたはクラウド・テナンシ(あるいはその両方)にまたがる複数のペアを備えた最大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ノードが使用できない場合もエンドポイントの操作には影響しません。特定のノードが使用できない場合、エンドポイントはクラスタ内の別のノードと透過的に対話します。

• フォルト・トレランス

  正常にエンロールされたクライアントは、クラスタ内で使用可能な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では、クラスタ・ノードに対して、読取り専用制限モードまたは読取り/書込みモードという2種類のモードがサポートされています。
• 異なるモードのクラスタ・ノードで許可された操作
  Oracle Key Vaultマルチマスター・クラスタでは、ノードおよびノードの操作モードに基づいて操作が使用可能または制限されます。

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

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

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

インダクションでは、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つのノードで読取り/書込みピアを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. プライマリ・サーバーとスタンバイ・サーバーの両方を最新リリースにアップグレードします。
  3. ペアのプライマリ・サーバーとスタンバイ・サーバーのペアを解除します。(サーバーをアンペアする前に、アンペア・プロセスに関する既知の問題について、『Oracle Key Vaultリリース・ノート』を参照してください。)
  4. クラスタの最初のノードとなるようにプライマリ・サーバーを変換します。
• 方法2:
  1. サーバーをバックアップします。
  2. ペアのプライマリ・サーバーとスタンバイ・サーバーのペアを解除します。
  3. 以前のプライマリ・サーバーを最新リリースにアップグレードします。
  4. クラスタの最初のノードとなるようにプライマリ・サーバーを変換します。

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

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

初期ノードの後に追加される他のノードはすべて、初期ノードと同じバージョンのOracle Key Vaultサーバーを新しくインストールまたはクローニングして作成する必要があります。

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

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

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

ノート:

Oracle Key Vaultリリース21.7では、アップグレードされたサーバーが候補ノードになり、クラスタに誘導されないようにするためのチェックが用意されています。

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を追加します。N1とN2を読取り/書込みピアにした場合は、クラスタ内の他の2つのノードがすでに読取り/書込みピアであるため、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ペア)になります。

新しくインストールされたOracle Key Vaultサーバー(クラスタ内の他のノードと同じバージョン)は、候補ノードに変換できます。候補ノードでNetwork Time Protocol (NTP)が、既存のすべての受信Oracle Key VaultノードでNTPが構成されるように構成されていることを確認する必要があります。

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

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

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

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

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

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

• Oracle Key Vaultスタンドアロン・サーバーからマルチマスター・クラスタへの変換
  古いリリースのスタンドアロンOracle Key Vaultデプロイメントをマルチマスター・デプロイメントに移行できます。
• プライマリ/スタンバイ・サーバーからマルチマスター・クラスタへの変換
  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ノード・デプロイメントまであります。

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

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

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

パッチ適用やアップグレードなどのメンテナンスを実行するために、クラスタから読取り/書込みペアの両方のノードを同時に無効にする必要がある場合があります。ノード2つのみのクラスタがある場合は、継続的な読取り可用性が得られます。アプリケーションやデータベースの停止時間は発生しませんが、キー更新操作や、Oracle Key Vaultへの新規データベースのオンボーディングはできません。

2ノード・クラスタは、OKVのメンテナンス中にキー更新操作および新しいデータベースのオンボーディングを一時停止できるデプロイメント、および開発環境とテスト環境に適しています。負荷の高い大規模なデプロイメントでは、エンドポイントの継続性を確保するために、少なくとも2つの読取り/書込みペアをデプロイしてください。

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

ノード4つの、2つの読取り/書込みペアがあるクラスタでは、1つのノードがパッチ適用やアップグレードのためのメンテナンス中である場合も、すべてのエンドポイント操作について、継続的な読取り/書込み可用性が提供されます。

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

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

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

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データベース用のマルチインスタンス・スタンバイ・データベース

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サーバーに自動的に接続します。

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 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ノードに接続してキーをフェッチします。

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

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

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

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

ネットワークの停止により、クラスタ内のデータに矛盾が発生する可能性がありますが、停止が終了し、最大無効化ノード期間(デフォルトは24時間)内にネットワーク接続が再開されると、再びデータの矛盾がなくなります。

ノードは、クラスタ内の他のノードから自発的または意図せずに切断されることがあります。自発的または意図せずに切断されたノードが最大無効化ノード期間内にクラスタに戻ると、クラスタ内のすべてのデータ変更がノードにレプリケートされます。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」をクリックします。

図218_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ノードの現在のバージョン。