1. Real Application Clusters管理およびデプロイメント・ガイド
  2. 設計およびデプロイメント方法

13 設計およびデプロイメント方法

Oracle RACを設計およびデプロイする方法について説明します。

この章では、Oracle Real Application Clusters(Oracle RAC)環境でのデータベースの設計およびデプロイメント方法について簡単に説明します。また、高可用性を実現するための考慮事項を説明し、Oracle RACの様々なデプロイメントに関する一般的なガイドラインを示します。

注意:

マルチテナント・コンテナ・データベースは、Oracle Database 20cで唯一サポートされているアーキテクチャです。ドキュメントが改訂されている間は、従来の用語が残っている可能性があります。ほとんどの場合、"データベース"と"非CDB"は、文脈に応じてCDBまたはPDBを指しています。アップグレードなどでは、"非CDB"が以前のリリースの非CDBを指している場合もあります。

13.1 高可用性を実現するOracle RACのデプロイ

高可用性を実現するためにOracle RACをデプロイする方法について説明します。

多数のお客様がOracle RACを実装してそれぞれのOracle Databaseアプリケーションで高可用性を実現しています。真の高可用性を得るには、アプリケーションのインフラストラクチャ全体を高可用性にする必要があります。これには、インフラストラクチャ全体でシングル・ポイント障害の発生をなくすための詳細な計画が必要です。Oracle RACによってデータベースが高可用性になったとしても、重要なアプリケーションが使用不可になれば、ビジネスに悪影響が生じる可能性があります。たとえば、認証にLightweight Directory Access Protocol(LDAP)を使用する場合は、LDAPサーバーを高可用性にする必要があります。データベースが起動していても、LDAPサーバーへのアクセスに障害があってユーザーがデータベースに接続できないと、ユーザーにはシステム全体が停止しているように見えます。

親トピック: 設計およびデプロイメント方法

13.1.1 高可用性システムの設計について

ミッション・クリティカルなシステムの場合は、フェイルオーバーとリカバリが実行可能であることに加えて、あらゆるタイプの障害に対して環境にリジリエンスがある必要があります。

ミッション・クリティカルなシステムの場合は、フェイルオーバーとリカバリが実行可能であることに加えて、あらゆるタイプの障害に対して環境にリジリエンスがある必要があります。これらの目標に到達するには、ビジネスのサービス・レベルの要件を定義することから始めます。この要件には、データ・センター内の障害(ノード障害など)または障害時リカバリ(データ・センター全体に障害が発生した場合)に対する最大のトランザクション応答時間およびリカバリ予測の定義が含まれる必要があります。通常、サービス・レベルの目標は、障害の内容にかかわらず、作業の目標応答時間になります。各冗長コンポーネントにリカバリ時間を設定します。アクティブ/アクティブ・モードで実行されている複数のハードウェア・コンポーネントがある場合でも、1つのコンポーネントに障害が発生したときに、そのコンポーネントの修理中に、他のハードウェア・コンポーネントが稼働状態を保持できるとは想定しないでください。また、コンポーネントがアクティブ・モードまたはパッシブ・モードで実行されている場合は、通常のテストを実行してフェイルオーバー時間を検証します。たとえば、ストレージ・チャネルのリカバリ時間は、何分もかかる場合があります。停止時間がビジネスのサービス・レベル契約の範囲内であることを確認し、この範囲を超えている場合は、ハードウェア・ベンダーと協力して構成および設定をチューニングします。

ミッション・クリティカルなシステムをデプロイする場合は、テストに機能試験、破壊試験および性能試験を含める必要があります。破壊試験では、システム内に様々な障害を発生させてリカバリをテストし、サービス・レベルの要件に適合しているかどうかを確認します。また、破壊試験によって、本番システム用の操作手順を作成できます。

ミッション・クリティカルなシステムまたは高可用性システムの設計と実装を支援するため、Oracleでは規模に関係なくすべての組織に適用可能な様々なソリューションを提供しています。小規模な作業グループとグローバル企業が同じように組織の重要なビジネス・アプリケーションの可用性を拡張できます。Oracleとインターネットを使用することで、現在では常にどこからでも確実にアプリケーションとそのデータにアクセスできます。Oracle Maximum Availability Architecture(MAA)は、Oracleの実証済高可用性テクノロジと推奨事項に基づいたOracleのベスト・プラクティスのブループリントです。MAAの目的は、最適な高可用性アーキテクチャの設計から複雑な仕組みを排除することです。

関連項目

親トピック: 高可用性を実現するOracle RACのデプロイ

13.1.2 高可用性環境にOracle RACをデプロイするためのベスト・プラクティス

ここで説明するベスト・プラクティスに従うことで、Oracle RAC環境のパフォーマンスを向上させることができます。

アプリケーションは、Oracle Database、Oracle ClusterwareおよびOracle RACの多数の機能を使用してOracle RAC環境の障害を最小限に抑えたり、マスクすることができます。たとえば、次のことが可能です。

  • VIPアドレスを使用してデータベースに接続することで、TCP/IPのタイムアウト待機時間をなくします。

  • 詳細な操作手順を作成し、インフラストラクチャ内のすべてのコンポーネントに対して、定義されたサービス・レベルを満たす適切で有効なサポート契約があることを確認します。

  • 接続時フェイルオーバー、高速接続フェイルオーバー、高速アプリケーション通知、ロード・バランシング・アドバイザなどのOracle RACの自動ワークロード管理機能を使用します。

  • 個別のボリューム・グループに投票ディスクを配置して、I/Oスループットの低下による停止を減らします。x個の投票デバイスの障害に対応するには、2x + 1個のミラーを構成します。

  • Oracle Database Quality of Service Management (Oracle Database QoS Management)を使用して、システムを監視し、パフォーマンスのボトルネックを検出します。

  • 約2ミリ秒(ms)以下のI/Oサービス時間でOCRを配置します。

  • FAST_START_MTTR_TARGET初期化パラメータを使用してデータベース・リカバリをチューニングします。

  • Oracle Automatic Storage Management(Oracle ASM)を使用してデータベース記憶域を管理します。

  • 厳密変更制御手順が有効であることを確認します。

  • LDAP、NIS、DNSなどの周辺のインフラストラクチャに高可用性およびリジリエンスがあることを確認します。これらのエンティティは、Oracle RACデータベースの可用性に影響します。可能な場合は、ローカルのバックアップ手順を定期的に実行します。

  • Oracle Enterprise Managerを使用して、Oracle RACデータベースのみでなく、Oracle RAC環境全体を管理します。Oracle Enterprise Managerを使用して、サービスの作成と変更、およびクラスタ・データベース・インスタンスとクラスタ・データベースの起動と停止を実行できます。

  • Recovery Manager (RMAN)を使用して、データ・ファイル、制御ファイル、サーバー・パラメータ・ファイル(SPFILE)およびアーカイブREDOログ・ファイルのバックアップ、リストアおよびリカバリを実行します。RMANをメディア・マネージャとともに使用すると、ファイルを外部記憶域にバックアップできます。また、Oracle RACデータベースのバックアップまたはリカバリの実行時にパラレル化を構成できます。Oracle RACでは、RMANのチャネルは、すべてのOracle RACインスタンス間で動的に割り当てられます。チャネルのフェイルオーバーによって、1つのノード上で失敗した操作を別のノードで継続できます。RMANは、Oracle Enterprise Manager Backup Managerまたはコマンドラインから実行できます。

  • 順序番号を使用している場合、常にNOORDERオプションを指定したCACHEを使用することによって、順序番号生成のパフォーマンスを最適化します。ただし、CACHEオプションを使用すると、連続しない順序番号が生成される場合があります。連続しない順序番号を使用できない環境では、NOCACHEオプションを使用するか、または順序番号の事前生成を検討してください。アプリケーションでは順序番号の順序付けが必要で、連続しない順序番号を使用できる場合は、CACHEおよびORDERを使用して、Oracle RACの順序番号のキャッシュおよび順序付けを行います。アプリケーションで連続した順序番号の順序付けが必要な場合は、NOCACHEおよびORDERを使用します。NOCACHEとORDERの組合せは、その他のキャッシュおよび順序付けの組合せと比較すると、パフォーマンスに最も大きな影響を及ぼします。

    注意:

    連続しない順序番号を使用できない環境では、順序番号の事前生成を検討するか、またはORDERおよびCACHEオプションを使用してください。

    Oracle Database 18c以降では、大規模な順序キャッシュを構成するかわりに、スケーラブルな順序を使用して、データのロードのスケーラビリティを向上させることができます。特に順序値が表の主キー列の移入に使用される場合、スケーラブルな順序により同時データ・ロード操作のパフォーマンスが向上します。

  • 索引を使用する場合は、逆キー索引などの方法を検討してパフォーマンスを最適化します。逆キー索引は、挿入日付に基づいた索引のように、索引の一方に頻繁に挿入を行う場合に特に有効です。

関連項目

親トピック: 高可用性を実現するOracle RACのデプロイ

13.1.3 クラスタ・データベースにおける複数のアプリケーションの統合

Oracle RACデータベースでのアプリケーションの統合について説明します。

多くのユーザーが1つのクラスタ内での複数のデータベースの統合を必要とします。Oracle ClusterwareおよびOracle RACは、両方のタイプの統合をサポートしています。

Oracle ASMによって管理される単一の記憶域のプールでクラスタを作成すると、シングル・インスタンス・データベースであろうとOracle RACデータベースであろうと複数のデータベースを管理するためのインフラストラクチャが提供されます。

親トピック: 高可用性を実現するOracle RACのデプロイ

13.1.3.1 統合時の容量管理

統合時の容量の管理方法について説明します。

Oracle RACデータベースでは、ワークロードの要件に基づいてインスタンスの数、および特定のデータベース内でインスタンスを実行するノードを調整できます。クラスタで管理されるサービスなどの機能を使用すると、単一データベースまたは複数のデータベース間で複数のワークロードを管理できます。

作業を追加する場合は、クラスタの容量を適切に管理することが重要です。クラスタを管理するプロセス(Oracle Clusterwareとデータベースの両方のプロセスを含む)は、CPUリソースを適時に取得できる必要があり、システム内で優先度が高く設定される必要があります。Oracle Database Quality of Service Management (Oracle Database QoS Management)は、パフォーマンス目標を満たすようにCPUリソースを動的に割り当てることで、クラスタまたはデータベース内での複数のアプリケーションの統合を支援できます。クラスタ構成ポリシーを使用して、クラスタ・レベルのリソースを管理することもできます。

13.1.3.2 統合時のグローバル・キャッシュ・サービス・プロセスの管理

統合時にグローバル・キャッシュ・サービス・プロセスを管理する方法について説明します。

サーバー上のリアルタイム・グローバル・キャッシュ・サービス・プロセス(LMSn)の数は、プロセッサ数と同じか、それより少なくすることをお薦めします。(これは、コアを含めて認識されるCPUの数です。たとえば、デュアル・コアCPUは、2つのCPUとみなされます。)ノード上にインスタンスを追加するときは、システムで負荷試験を実行して、ワークロードをサポートするのに必要な容量があることを確認することが重要です。

多数の小規模なデータベースをクラスタに統合する場合は、Oracle RACインスタンスによって作成されるLMSnの数を減らすことが必要になる場合があります。デフォルトでは、サーバーで検出されるCPUの数に基づいてプロセスの数がOracle Databaseによって算出されます。この計算の結果、LMSnプロセスがOracle RACインスタンスで必要とされるプロセス数より多くなることがあります。1つのLMSプロセスは、最大4個のCPUで対応できます。LMSnプロセスの数を減らすには、GCS_SERVER_PROCESSES初期化パラメータを最小限度の値1に設定します。CPU4個ごとに、アプリケーションで必要とされるプロセスを1つ追加します。通常は、ビジー状態のLMSnプロセスを少なくすることをお薦めします。Oracle Databaseはインスタンスの起動時にプロセスの数を算出するため、その値を変更するにはインスタンスを再起動する必要があります。

13.1.3.3 統合へのOracle Database Cloudの使用

データベース・クラウドは、Global Data Servicesフレームワークによって単一の仮想サーバーに統合された一連のデータベースであり、1つ以上のグローバル・サービスを提供すると同時に、高いパフォーマンス、可用性、およびリソースの最適な使用を実現します。

Global Data Servicesでは、これらの仮想化リソースを最小限の管理オーバーヘッドで管理し、追加のクライアント要求を処理するために迅速にデータベース・クラウドを拡張できます。クラウドを構成するデータベースは、グローバルに分散させることができ、クライアントは、サービス名を指定するのみでデータベース・クラウドに接続でき、クラウドのコンポーネントやトポロジを把握する必要はありません。

データベース・クラウドは、複数のデータベース・プールで構成できます。データベース・プールは、データベース・クラウド内の一連のデータベースであり、一意のグローバル・サービス・セットを提供し、特定の管理ドメインに属しています。クラウド・データベースを複数のプールにパーティション化すると、サービス管理が簡素化され、かつ、各プールを異なる管理者が管理できることによって、セキュリティが向上します。データベース・クラウドは、複数の地理的リージョンにまたがることができます。リージョンは、互いに近くに存在すると考えられるデータベース・クライアントおよびサーバーが含まれる論理的な境界です。通常、1つのリージョンが1つのデータ・センターに対応しますが、データ・センター間のネットワーク待機時間が、これらのデータ・センターにアクセスするアプリケーションの品質保証契約を満たす場合、複数のデータ・センターを同じリージョンに配置できます。

グローバル・サービスによって、ローカルまたはグローバルに分散している、疎結合の異機種データベースを、スケーラブルで可用性の高いプライベート・データベース・クラウドに統合できます。このデータベース・クラウドは、地球上のすべてのクライアントで共有できます。プライベート・データベース・クラウドを使用すると、使用可能なリソースの使用率が最適化され、データベース・サービスのプロビジョニングが簡素化されます。

13.1.4 Oracle RACのスケーラビリティ

Oracle RACのスケーラビリティを向上させるための選択肢について説明します。

Oracle RACでは、複数のシステムからデータの単一コピーへのトランザクション的に一貫性のある同時アクセスが可能です。単一のサーバーの容量を超えたスケーラビリティも実現します。アプリケーションが対称型マルチプロセッシング(SMP)サーバー上で透過的にスケール変更する場合、アプリケーションはアプリケーション・コードを変更しなくてもOracle RAC上で適切にスケール変更します。

従来、データベース・サーバーの容量が不足する場合は、より規模の大きい新しいサーバーに置き換えられてきました。サーバーの容量が大きくなると、価格も上がります。ただし、Oracle RACデータベースには、容量を増やすための別の手段があります。

  • 従来はより大きいSMPサーバーで実行していたアプリケーションを移行して、小規模なサーバーのクラスタで実行できます。

  • 現行のハードウェアへの投資を維持し、新しいサーバーをクラスタに追加する(あるいは新しいクラスタを作成または追加する)ことで、容量を増やすことができます。

Oracle ClusterwareおよびOracle RACを使用してクラスタにサーバーを追加する場合、停止は必要ありません。新規インスタンスが起動されると同時に、アプリケーションは追加された容量を使用できます。

クラスタ内のすべてのサーバーは、同じオペレーティング・システムと同じバージョンのOracle Databaseを実行する必要がありますが、各サーバーの容量を揃える必要はありません。Oracle RACを使用すると、要件にあったクラスタ(デュアルCPUの汎用サーバーで構成されるクラスタや、32または64のCPUが組み込まれたサーバーで構成されるクラスタなど)を構築できます。Oracleのパラレル実行機能を使用すると、1つのSQL文を複数のプロセスに分割でき、それぞれのプロセスで作業のサブセットが実行されます。Oracle RAC環境では、パラレル・プロセスをユーザーが接続されているインスタンスでのみ実行するように定義したり、クラスタ内の複数のインスタンス間で実行するように定義することができます。

関連項目

親トピック: 高可用性を実現するOracle RACのデプロイ

13.2 Oracle RACの設計に関する一般的な考慮事項

Oracle RACの設計に関する考慮事項について説明します。

この項では、Oracle RAC環境でのデータベースの設計およびデプロイメント方法について簡単に説明します。また、高可用性を実現するための考慮事項を説明し、Oracle RACの様々なデプロイメントに関する一般的なガイドラインを示します。

Oracle RACデータベース上にデプロイするアプリケーションの設計および開発時には、次のステップの実行を検討してください。

  1. 設計とアプリケーションのチューニング

  2. メモリーとI/Oのチューニング

  3. 競合のチューニング

  4. オペレーティング・システムのチューニング

注意:

アプリケーションをSMPシステムで拡張できない場合は、アプリケーションをOracle RACデータベースに移動してもパフォーマンスは向上しません。

挿入集中型オンライン・トランザクション処理(OLTP)アプリケーションには、ハッシュ・パーティション化を使用することを検討します。ハッシュ・パーティション化の特長は次のとおりです。

  • 単一データベース構造への同時挿入による競合を軽減します。

  • 索引がローカルで表を使用してパーティション化され、表が順序ベースのキーでパーティション化されている場合、順序ベースの索引に適用されます。

  • アプリケーションに対して透過的です。

OLTP環境に対して表および索引のハッシュ・パーティション化を使用すると、Oracle RACデータベースでのパフォーマンスが大幅に向上します。ハッシュ・パーティション化された索引では、索引レンジ・スキャンは使用できないことに注意してください。

親トピック: 設計およびデプロイメント方法

13.3 Oracle RACでのデータベースの一般的なデプロイメント

表領域の使用、オブジェクトの作成、分散トランザクションなど、Oracle RACの様々なデプロイメントに関する考慮事項について説明します。

この項では、Oracle RACデータベースをデプロイする際の考慮事項について説明します。ここで説明する方法を採用しない場合でも、Oracle RACデータベースのパフォーマンスが低下することはありません。効率的な非クラスタ設計であれば、アプリケーションはOracle RACで効率的に実行されます。

親トピック: 設計およびデプロイメント方法

13.3.1 Oracle RACでの表領域の使用

Oracle RACで表領域の使用を最適化する方法について説明します。

ローカル管理表領域の使用の他に、自動セグメント領域管理(ASSM)および自動UNDO管理を使用して領域管理をさらに簡単にすることができます。

ASSMでは、挿入を行うためのブロックの各インスタンスのサブセット間にインスタンスのワークロードが分散されます。これによってブロック転送が最小限に抑えられるため、Oracle RACパフォーマンスが向上します。自動UNDO管理をOracle RAC環境にデプロイするには、各インスタンスに固有のUNDO表領域が必要です。

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

13.3.2 Oracle RACでのオブジェクトの作成およびパフォーマンス

Oracle RACでのオブジェクトの作成およびパフォーマンスについて説明します。

原則として、DDL文の使用はメンテナンス・タスクのみに限定し、システム操作のピーク時には実行しないようにします。ほとんどのシステムでは、新しいオブジェクトの生成量とその他のDDL文に対する制限が必要です。非クラスタのOracle Databaseの場合と同様に、オブジェクトの作成と削除が多くなるとパフォーマンスのオーバーヘッドが増加する可能性があります。

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

13.3.3 Oracle RACでのノードの追加と削除およびSYSAUX表領域

Oracle RACでノードの追加および削除がSYSAUX表領域にどのように影響を与えるかについて説明します。

Oracle RACデータベース環境にノードを追加する場合は、SYSAUX表領域のサイズを大きくする必要があります。また、クラスタ・データベースのノードを削除する場合は、SYSAUX表領域のサイズを小さくできる場合もあります。

関連項目:

複数のインスタンスに対するSYSAUX表領域のサイズの設定方法については、プラットフォーム固有のOracle RACのインストレーション・ガイドを参照してください。

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

13.3.4 分散トランザクションおよびOracle RAC

Oracle RACでの分散トランザクションについて説明します。

Oracle RAC環境でXAトランザクションを実行しているときにパフォーマンスが低い場合は、複数のOracle分散トランザクション処理(DTP)サービス(各Oracle RACインスタンスで1つ以上)を作成することにより、密結合分散トランザクションのすべてのブランチを同じインスタンスに送ります。

各DTPサービスは、1つのみのOracle RACインスタンスで使用可能な単一のサービスです。分散トランザクション処理のためのデータベース・サーバーへのアクセスは、すべてDTPサービスを経由する必要があります。単一のグローバル分散トランザクションのすべてのブランチが、同じDTPサービスを使用することを確認してください。つまり、TNS名やJDBC URLなどのネットワーク接続記述子には、分散トランザクション処理をサポートするためにDTPサービスを使用する必要があります。

関連項目

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

13.3.5 Oracle RACでのOLTPアプリケーションのデプロイ

Oracle RACでのOTLPアプリケーションのデプロイについて説明します。

Oracle RACデータベースはキャッシュ・フュージョンによって、オンライン・トランザクション処理(OLTP)アプリケーションに最適なデプロイメント・サーバーになります。これは、これらのアプリケーションには次の要件があるためです。

  • 障害発生時の高可用性

  • 増加するシステム需要に対応するためのスケーラビリティ

  • 需要変動に応じたロード・バランシング

Oracle DatabaseおよびOracle RACの高可用性機能は、処理を中断することなく、障害が発生していないインスタンスにワークロードを再分散し、ロード・バランシングを実行できます。さらに、Oracle RACは、優れたスケーラビリティも提供するため、ノードを追加または置換した場合、Oracle Databaseは、リソースを再マスター化してロードの処理を再分散します。

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

13.3.6 キャッシュ・フュージョンによる柔軟な実装

Oracle RACでのキャッシュ・フュージョンによる柔軟なワークロードの実装について説明します。

オンライン・トランザクション処理システムの頻繁に変化するワークロードに対応するには、Oracle RACは、システム負荷やシステム可用性が変化しても、柔軟かつ動的に対応します。Oracle RACは、たとえば次のような原因で変動する幅広いサービス・レベルに対応します。

  • ユーザーの需要の変化

  • 取引の集中(大量取引の発生)など、ピーク時のスケーラビリティの問題

  • システム・リソースの可用性の変化

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

13.3.7 Oracle RACでのデータ・ウェアハウス・アプリケーションのデプロイ

Oracle RACでデータ・ウェアハウス・アプリケーションをデプロイする方法について説明します

この項では、Oracle RAC環境でのデータ・ウェアハウス・システムのデプロイ方法について説明します。また、共有ディスク・アーキテクチャで使用可能なデータ・ウェアハウス機能についても説明します。

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

13.3.7.1 Oracle RACでのデータ・ウェアハウス・アプリケーションの並列処理

Oracle RACでのデータ・ウェアハウス・アプリケーションの並列処理について説明します。

Oracle RACは、Oracle Databaseの非クラスタのメリットを拡大するため、データ・ウェアハウス・アプリケーションには理想的です。Oracle RACではこれを実現するために、Oracle RACデータベースに属するすべてのノード上で使用可能な処理を最大限に活用して、データ・ウェアハウス・システムをスピードアップします。

クエリー・オプティマイザは、最適な実行計画の判断に、パラレル実行を検討します。クエリー・オプティマイザのデフォルトのコスト・モデルはCPU+I/Oで、コスト単位は時間です。Oracle RACでは、クエリー・オプティマイザが、プロセッサ数に基づいてパラレル化の適切なデフォルト値を動的に計算します。代替アクセス・パスのコスト評価(表スキャンと索引アクセスなど)では、操作に使用できる並列度が考慮されます。これによってOracle Databaseは、Oracle RAC構成用に最適化された実行計画を選択します。

13.3.7.2 データ・ウェアハウス・システムおよびOracle RACにおけるパラレル実行

パラレル実行を使用して、Oracle RACでのデータ・ウェアハウスのパフォーマンスを向上させます。

パラレル実行は、複数のプロセスを使用して1つ以上のCPUでSQL文を実行し、また、非クラスタOracle DatabaseとOracle RACデータベースの両方で使用可能です。

Oracle RACは、パラレル処理をすべての利用可能なインスタンスに分散することによってパラレル実行を十分に活用します。パラレル操作に使用できるプロセスの数は、各表または索引に割り当てられる並列度によって異なります。

13.3.8 Oracle RACでのデータ・セキュリティの考慮事項

透過的データ暗号化と、Oracle RACデータ・セキュリティに関するMicrosoft Windowsファイアウォールの考慮事項について説明します。

親トピック: Oracle RACでのデータベースの一般的なデプロイメント

13.3.8.1 透過的データ暗号化およびキーストア

Oracle RACでの透過的データ暗号化およびキーストアについて説明します。

Oracle Databaseでは、Oracle RACノードはキーストア(ウォレット)を共有できます。これにより、すべてのノードにわたってキーストアを手動でコピーし同期化する必要がなくなります。共有ファイル・システム上にキーストアを作成することをお薦めします。これにより、すべてのインスタンスが同じ共有キーストアにアクセスできます。

Oracle RACは、次の方法でキーストアを使用します。

  1. 任意の1つのOracle RACインスタンスで実行される任意のキーストア操作(キーストアのオープンやクローズなど)は、他のすべてのOracle RACインスタンスに適用されます。つまり、1つのインスタンスでキーストアをオープンおよびクローズすると、すべてのOracle RACインスタンスでキーストアがオープンおよびクローズされます。

  2. 共有ファイル・システムを使用する場合は、すべてのOracle RACインスタンスのENCRYPTION_WALLET_LOCATIONパラメータが、必ず同じ共有キーストアの場所を指すようにします。また、セキュリティ管理者は、適切なディレクトリ権限を割り当てることによって、共有キーストアのセキュリティを確保する必要もあります。

    注意:

    オペレーティング・システムでOracle Automatic Storage Management Cluster File System (Oracle ACFS)が使用可能な場合は、キーストアをOracle ACFSに格納することをお薦めします。Oracle ASMにOracle ACFSがない場合は、Oracle ASMコンフィギュレーション・アシスタント(ASMCA)を使用して作成してください。次のように、各インスタンスのsqlnet.oraファイルに、マウント・ポイントを追加する必要があります。 

    ENCRYPTION_WALLET_LOCATION=
  (SOURCE = (METHOD = FILE)
    (METHOD_DATA =
      (DIRECTORY = /opt/oracle/acfsmounts/data_keystore)))

    このファイル・システムは、インスタンスの起動時に自動的にマウントされます。キーストアのオープンとクローズ(およびTDEマスター暗号化キーの設定またはキー更新およびローテーションを行うコマンド)は、すべてのノード間で同期化されています。

  3. ある1つのインスタンスで実行されるmaster key rekeyは、すべてのインスタンスに適用されます。新しいOracle RACノードは、起動されると、現在のキーストアの状態(オープンまたはクローズ)を認識します。

  4. マスター・キーを設定または変更している場合は、キーストアのADMINISTER KEY MANAGEMENT SET KEYSTORE OPENまたはCLOSE SQL文は発行しないでください。

キーストア用の共有ストレージが存在しないデプロイメントでは、各Oracle RACノードでローカル・キーストアを保持する必要があります。単一ノードでキーストアを作成およびプロビジョニングした後、次のようにキーストアをコピーして他のすべてのノードで使用可能にする必要があります。

  • 暗号化されたキーストアとともに透過的データ暗号化を使用するシステムでは、任意の標準ファイル転送プロトコルを使用できますが、保護されたファイル転送を使用することをお薦めします。

  • 自動ログイン・キーストアとともに透過的データ暗号化を使用するシステムでは、保護されたチャネルを介してファイルを転送することをお薦めします。

キーストアが存在している必要があるディレクトリを指定するには、sqlnet.oraファイルでENCRYPTION_WALLET_LOCATIONパラメータを設定します。ADMINISTER KEY MANAGEMENT SET KEY SQL文を使用してサーバー・キーが再設定されるまで、透過的データ暗号化の使用中にキーストアのローカル・コピーを同期化する必要はありません。データベース・インスタンスでADMINISTER KEY MANAGEMENT SET KEY文を発行するたびに、ノードに存在するキーストアを再度コピーし、他のすべてのノードで使用可能にする必要があります。次に、各ノードでキーストアを閉じてから再度開く必要があります。不要な管理オーバーヘッドを回避するために、サーバー・マスター・キーのセキュリティが低下したり、キーを再設定しないと重大なセキュリティ問題が発生することが明確な例外的な場合のためにキーの再設定を予約します。

13.3.8.2 Windowsファイアウォールの考慮事項

Microsoft Windowsファイアウォールの考慮事項について説明します。

デフォルトにより、Windows Server 2003 Service Pack 1以上のすべてのインストレーションにおいて、Windowsファイアウォールは、着信接続に対するほとんどすべてのTCPネットワーク・ポートをブロックできます。そのため、TCPポート上で着信接続をリスニングするOracle製品はすべて、これらのどの接続要求も受信せず、これらの接続を行っているクライアントはエラーを報告します。

インストールするOracle製品およびその使用方法によって、Windows Server 2003でファイアウォール製品が機能するように、Windowsのインストール後の追加の構成作業を実行する必要があります。

13.3.8.3 ウォレットを使用してONSクライアントを安全に実行

SSL証明書を構成および使用して、データベース層のONSサーバーと中間層の通知クライアント間の認証を設定できます。

JDBC接続プールまたはOracle Universal Connection Poolなどで使用する高速接続フェイルオーバーなどのOracle RAC機能は、Oracle RACノードで実行されているOracle Notification Service (ONS)の通知をサブスクライブします。これらの接続は通常認証されません。

  1. Oracle Database 18c以降、Oracle Grid Infrastructureのインストールにデフォルトのウォレットが作成されます。
  2. 中間層でクライアント側ONSデーモンを実行している場合は、次の2つの構成が可能です。
    • (OracleAS 10.1.3.xなどの) OPMNからONSを起動する場合。この構成にはopmn.xmlを使用します。
    • (ONSCTLの使用時など)スタンドアロンでONSを起動する場合。この構成にはons.configを使用します。

    最初の構成については、Oracle Application ServerリリースのOPMN管理者ガイドを参照してください。この構成では、ウォレットの場所を指定するために、opmn.xmlファイルを変更します。

    2つ目の構成については、クライアント側ONSデーモンが異なるサーバー上で実行される可能性があります。ステップ1のウォレットをクライアント側サーバーにコピーし、そのクライアント側サーバー上のパスをons.configファイルまたはopmn.xmlファイルに指定します。

  3. クライアント側のONSデーモンなしでリモートONS構成を実行する場合は、クライアント側のサーバーを構成します。
    1. クライアント・クラスタにONSリソースをエクスポートします。
      次のようなコマンドを使用します。cluster_nameはリモート・クラスタの名前です。また、filenameは、資格証明のデータを書き込むファイルの名前です。
      $ srvctl export ons -clientcluster cluster_name -clientdata filename
    2. クライアント側サーバーでパスを指定します。
      ons.configファイルまたはopmn.xmlファイルを変更して、コピーしたファイルの場所を指すようにします。