13 設計およびデプロイメント方法
この章では、Oracle Real Application Clusters(Oracle RAC)環境でのデータベースの設計およびデプロイメント方法について簡単に説明します。また、高可用性を実現するための考慮事項を説明し、Oracle RACの様々なデプロイメントに関する一般的なガイドラインを示します。
この章の内容は次のとおりです。
13.1 高可用性を実現する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の目的は、最適な高可用性アーキテクチャの設計から複雑な仕組みを排除することです。
13.1.2 高可用性環境で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以降では、大規模な順序キャッシュを構成するかわりに、スケーラブルな順序を使用して、データのロードのスケーラビリティを向上させることができます。特に順序値が表の主キー列の移入に使用される場合、スケーラブルな順序により同時データ・ロード操作のパフォーマンスが向上します。
-
索引を使用する場合は、逆キー索引などの方法を検討してパフォーマンスを最適化します。逆キー索引は、挿入日付に基づいた索引のように、索引の一方に頻繁に挿入を行う場合に特に有効です。
13.1.3 クラスタ内の単一または複数のデータベースでの複数のアプリケーションの統合
多くのユーザーは、複数のアプリケーションの単一データベースへの統合および複数のデータベースの単一クラスタへの統合を望んでいます。Oracle ClusterwareおよびOracle RACは、両方のタイプの統合をサポートしています。
Oracle ASMによって管理された単一の記憶域のプールでクラスタを作成すると、インフラストラクチャで複数のデータベースを(シングル・インスタンス・データベースか、または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プロセスの数を減らすには、GC_SERVER_PROCESSES
初期化パラメータを手動で最小限度の1の値に設定します。CPU4個ごとに、アプリケーションで必要とされるプロセスを1つ追加します。通常は、ビジー状態のLMSnプロセスを少なくすることをお薦めします。Oracle Databaseはインスタンスの起動時にプロセスの数を算出するため、その値を変更するにはインスタンスを再起動する必要があります。
13.1.3.3 統合へのDatabase Cloudの使用
データベース・クラウドは、Global Data Servicesフレームワークによって、単一の仮想サーバーに統合された一連のデータベースであり、1つ以上のグローバル・サービスを提供すると同時に、高いパフォーマンス、可用性、およびリソースの使用率の最適化を実現します。
Global Data Servicesでは、これらの仮想化リソースを最小限の管理オーバーヘッドで管理し、追加のクライアント要求を処理するために迅速にデータベース・クラウドを拡張できます。クラウドを構成するデータベースは、グローバルに分散させることができ、クライアントは、サービス名を指定するのみでデータベース・クラウドに接続でき、クラウドのコンポーネントやトポロジを把握する必要はありません。
データベース・クラウドは、複数のデータベース・プールで構成できます。データベース・プールは、データベース・クラウド内の一連のデータベースであり、一意のグローバル・サービス・セットを提供し、特定の管理ドメインに属しています。クラウド・データベースを複数のプールにパーティション化すると、サービス管理が簡素化され、かつ、各プールを異なる管理者が管理できることによって、セキュリティが向上します。データベース・クラウドは、複数の地理的リージョンにまたがることができます。リージョンは、互いに近くに存在すると考えられるデータベース・クライアントおよびサーバーが含まれる論理的な境界です。通常、1つのリージョンが1つのデータ・センターに対応しますが、データ・センター間のネットワーク待機時間が、これらのデータ・センターにアクセスするアプリケーションの品質保証契約を満たす場合、複数のデータ・センターを同じリージョンに配置できます。
グローバル・サービスによって、ローカルまたはグローバルに分散している、疎結合の異機種データベースを、スケーラブルで可用性の高いプライベート・データベース・クラウドに統合できます。このデータベース・クラウドは、地球上のすべてのクライアントで共有できます。プライベート・データベース・クラウドを使用すると、使用可能なリソースの使用率が最適化され、データベース・サービスのプロビジョニングが簡素化されます。
13.1.4 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環境では、パラレル・プロセスをユーザーが接続されているインスタンスでのみ実行するように定義したり、クラスタ内の複数のインスタンス間で実行するように定義することができます。
13.2 Oracle RACの設計に関する一般的な考慮事項
この項では、Oracle RAC環境でのデータベースの設計およびデプロイメント方法について簡単に説明します。また、高可用性を実現するための考慮事項を説明し、Oracle RACの様々なデプロイメントに関する一般的なガイドラインを示します。
Oracle RACデータベース上にデプロイするアプリケーションの設計および開発時には、次のステップの実行を検討してください。
-
設計とアプリケーションのチューニング
-
メモリーとI/Oのチューニング
-
競合のチューニング
-
オペレーティング・システムのチューニング
注意:
アプリケーションをSMPシステムで拡張できない場合は、アプリケーションをOracle RACデータベースに移動してもパフォーマンスは向上しません。
挿入集中型オンライン・トランザクション処理(OLTP)アプリケーションには、ハッシュ・パーティション化を使用することを検討します。ハッシュ・パーティション化:
OLTP環境に対して表および索引のハッシュ・パーティション化を使用すると、Oracle RACデータベースでのパフォーマンスが大幅に向上します。ハッシュ・パーティション化された索引では、索引レンジ・スキャンは使用できないことに注意してください。
13.3 Oracle RACでのデータベースの一般的なデプロイメント
この項では、Oracle RACデータベースをデプロイする際の考慮事項について説明します。ここで説明する方法を採用しない場合でも、Oracle RACデータベースのパフォーマンスが低下することはありません。効率的な非クラスタ設計であれば、アプリケーションはOracle RACデータベースで効率的に実行されます。
この項には次のトピックが含まれます:
13.3.3 Oracle RACでのノードの追加と削除およびSYSAUX表領域
Oracle RACデータベース環境にノードを追加する場合は、SYSAUX
表領域のサイズを大きくする必要があります。また、クラスタ・データベースのノードを削除する場合は、SYSAUX
表領域のサイズを小さくできる場合もあります。
関連項目:
複数のインスタンスに対するSYSAUX
表領域のサイズの設定方法については、プラットフォーム固有のOracle RACのインストレーション・ガイドを参照してください。
13.3.4 分散トランザクションおよびOracle RAC
Oracle RAC環境でXAトランザクションを実行しているときに、そのパフォーマンスが低い場合は、1つ以上のOracle RACインスタンスでの複数のOracle Distributed Transaction Processing (DTP)サービスの作成により、密結合分散トランザクションのすべてのブランチを同じインスタンスに割り当てます。
各DTPサービスは、1つのみのOracle RACインスタンスで使用可能な単一のサービスです。分散トランザクション処理のためのデータベース・サーバーへのアクセスは、すべてDTPサービスを経由する必要があります。単一のグローバル分散トランザクションのすべてのブランチが、同じDTPサービスを使用することを確認してください。つまり、TNS名やJDBC URLなどのネットワーク接続記述子には、分散トランザクション処理をサポートするためにDTPサービスを使用する必要があります。
13.3.5 Oracle RACでのOLTPアプリケーションのデプロイ
Oracle RACデータベースはキャッシュ・フュージョンによって、オンライン・トランザクション処理(OLTP)アプリケーションに最適なデプロイメント・サーバーになります。これは、これらのアプリケーションには次の要件があるためです。
Oracle DatabaseおよびOracle RACの高可用性機能は、処理を中断することなく、障害が発生していないインスタンスにワークロードを再分散し、ロード・バランシングを実行できます。さらに、Oracle RACは、優れたスケーラビリティも提供するため、ノードを追加または置換した場合、Oracle Databaseは、リソースを再マスター化してロードの処理を再分散します。
13.3.7 Oracle RACでのデータ・ウェアハウス・アプリケーションのデプロイ
この項では、Oracle RAC環境でのデータ・ウェアハウス・システムのデプロイ方法について説明します。また、共有ディスク・アーキテクチャで使用可能なデータ・ウェアハウス機能についても説明します。
この項には次のトピックが含まれます:
13.3.7.1 Oracle RACでのデータ・ウェアハウス・アプリケーションのスピードアップ
Oracle RACは、Oracle Databaseの非クラスタのメリットを拡大するため、データ・ウェアハウス・アプリケーションには理想的です。Oracle RACは、Oracle RACデータベースに属するすべてのノード上で使用可能な処理能力を最大限に活用して、データ・ウェアハウス・システムをスピードアップおよびスケールアップすることによって、Oracleのシングル・インスタンスのメリットを拡大します。
クエリー・オプティマイザは、最適な実行計画の判断に、パラレル実行を検討します。クエリー・オプティマイザのデフォルトのコスト・モデルはCPU+I/Oで、コスト単位は時間です。Oracle RACでは、クエリー・オプティマイザが、プロセッサ数に基づいてパラレル化の適切なデフォルト値を動的に計算します。代替アクセス・パスのコスト評価(表スキャンと索引アクセスなど)では、操作に使用できる並列度が考慮されます。これによってOracle Databaseは、Oracle RAC構成用に最適化された実行計画を選択します。
13.3.8 Oracle RACでのデータ・セキュリティの考慮事項
13.3.8.1 透過的データ暗号化およびキーストア
Oracle Databaseでは、Oracle RACノードはキーストア(ウォレット)を共有できます。これにより、すべてのノードにわたってキーストアを手動でコピーし同期化する必要がなくなります。共有ファイル・システム上にキーストアを作成することをお薦めします。これにより、すべてのインスタンスが同じ共有キーストアにアクセスできます。
Oracle RACは、次の方法でキーストアを使用します。
-
任意の1つのOracle RACインスタンスで実行されるキーストアのオープンやクローズなどの任意のキーストア操作は、他のすべてのOracle RACインスタンスに適用されます。つまり、1つのインスタンスでキーストアをオープンおよびクローズすると、すべてのOracle RACインスタンスでキーストアがオープンおよびクローズされます。
-
共有ファイル・システムを使用する場合は、すべての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マスター暗号化キーの設定またはキー更新およびローテーションを行うコマンド)は、すべてのノード間で同期化されています。
-
ある1つのインスタンスで実行されるmaster key rekeyは、すべてのインスタンスに適用されます。新しいOracle RACノードは、起動されると、現在のキーストアの状態(オープンまたはクローズ)を認識します。
-
マスター・キーを設定または変更している場合は、キーストアの
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ファイアウォールの考慮事項
デフォルトにより、Windows Server 2003 Service Pack 1以上のすべてのインストレーションにおいて、Windowsファイアウォールは、着信接続に対するほとんどすべてのTCPネットワーク・ポートをブロックできます。そのため、TCPポート上で着信接続をリスニングするOracle製品はすべて、これらのどの接続要求も受信せず、これらの接続を行っているクライアントはエラーを報告します。
インストールするOracle製品およびその使用方法によって、Windows Server 2003でファイアウォール製品が機能するように、Windowsのインストール後の追加の構成作業を実行する必要があります。