| Oracle® Real Application Clusters管理およびデプロイメント・ガイド 11g リリース2 (11.2) B56290-06 |
|
 前 |
 次 |
この章では、Oracle Real Application Clusters(Oracle RAC)環境でのデータベースの設計およびデプロイメント方法について簡単に説明します。また、高可用性を実現するための考慮事項を説明し、Oracle RACの様々なデプロイメントに関する一般的なガイドラインを示します。
内容は次のとおりです。
多数のお客様がOracle RACを実装してそれぞれのOracle Databaseアプリケーションで高可用性を実現しています。真の高可用性を得るには、アプリケーションのインフラストラクチャ全体を高可用性にする必要があります。これには、インフラストラクチャ全体でシングル・ポイント障害の発生をなくすための詳細な計画が必要です。Oracle RACによってデータベースが高可用性になったとしても、重要なアプリケーションが使用不可になれば、ビジネスに悪影響が生じる可能性があります。たとえば、認証にLightweight Directory Access Protocol(LDAP)を使用する場合は、LDAPサーバーを高可用性にする必要があります。データベースが起動していても、LDAPサーバーへのアクセスに障害があってユーザーがデータベースに接続できないと、ユーザーにはシステム全体が停止しているように見えます。
この項の内容は次のとおりです。
ミッション・クリティカルなシステムの場合は、フェイルオーバーとリカバリが実行可能であることに加えて、あらゆるタイプの障害に対して環境にリジリエンスがある必要があります。これらの目標に到達するには、ビジネスのサービス・レベルの要件を定義することから始めます。この要件には、データセンター内の障害(ノード障害など)または障害時リカバリ(データセンター全体に障害が発生した場合)に対する最大のトランザクション応答時間およびリカバリ予測の定義が含まれる必要があります。通常、サービス・レベルの目標は、障害の内容にかかわらず、作業の目標応答時間になります。各冗長コンポーネントにリカバリ時間を設定します。アクティブ/アクティブ・モードで実行されている複数のハードウェア・コンポーネントがある場合でも、1つのコンポーネントに障害が発生したときに、そのコンポーネントの修理中に、他のハードウェア・コンポーネントが稼働状態を保持できるとは想定しないでください。また、コンポーネントがアクティブ・モードまたはパッシブ・モードで実行されている場合は、通常のテストを実行してフェイルオーバー時間を検証します。たとえば、ストレージ・チャネルのリカバリ時間は、何分もかかる場合があります。停止時間がビジネスのサービス・レベル契約の範囲内であることを確認し、この範囲を超えている場合は、ハードウェア・ベンダーと協力して構成および設定をチューニングします。
ミッション・クリティカルなシステムをデプロイする場合は、テストに機能試験、破壊試験および性能試験を含める必要があります。破壊試験では、システム内に様々な障害を発生させてリカバリをテストし、サービス・レベルの要件に適合しているかどうかを確認します。また、破壊試験によって、本番システム用の操作手順を作成できます。
ミッション・クリティカルなシステムまたは高可用性システムの設計と実装を支援するため、Oracleでは規模に関係なくすべての組織に適用可能な様々なソリューションを提供しています。小規模な作業グループとグローバル企業が同じように組織の重要なビジネス・アプリケーションの可用性を拡張できます。Oracleとインターネットを使用することで、現在では常にどこからでも確実にアプリケーションとそのデータにアクセスできます。Oracle Maximum Availability Architecture(MAA)は、Oracleの実証済高可用性テクノロジと推奨事項に基づいたOracleのベスト・プラクティスのブループリントです。MAAの目的は、最適な高可用性アーキテクチャの設計から複雑な仕組みを排除することです。
|
関連項目:
|
アプリケーションは、Oracle Database、Oracle ClusterwareおよびOracle RACの多数の機能を使用してOracle RAC環境の障害を最小限に抑えたり、マスクすることができます。たとえば次のようなことが可能です。
VIPアドレスを使用してデータベースに接続することで、TCP/IPのタイムアウト待機時間をなくします。
詳細な操作手順を作成し、インフラストラクチャ内のすべてのコンポーネントに対して、定義されたサービス・レベルを満たす適切で有効なサポート契約があることを確認します。
接続時フェイルオーバー、高速接続フェイルオーバー、高速アプリケーション通知、ロード・バランシング・アドバイザなどのOracle RACの自動ワークロード管理機能を使用します。詳細は、第5章「自動ワークロード管理の概要」を参照してください。
個別のボリューム・グループに投票ディスクを配置して、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を使用して、サービスの作成と変更、およびクラスタ・データベース・インスタンスとクラスタ・データベースの起動と停止を実行できます。Oracle RAC環境でOracle Enterprise Managerを使用する方法の詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。
Recovery Manager (RMAN)を使用して、データ・ファイル、制御ファイル、サーバー・パラメータ・ファイル(SPFILE)およびアーカイブREDOログ・ファイルのバックアップ、リストアおよびリカバリを実行します。RMANをメディア・マネージャとともに使用すると、ファイルを外部記憶域にバックアップできます。また、Oracle RACデータベースのバックアップまたはリカバリの実行時にパラレル化を構成できます。Oracle RACでは、RMANのチャネルは、すべてのOracle RACインスタンス間で動的に割り当てられます。チャネルのフェイルオーバーによって、1つのノード上で失敗した操作を別のノードで継続できます。RMANは、Oracle Enterprise Manager Backup Managerまたはコマンドラインから実行できます。RMANの使用方法の詳細は、第6章「Recovery Managerの構成およびアーカイブ」を参照してください。
順序番号を使用している場合、常にNOORDERオプションを指定したCACHEを使用することによって、順序番号生成のパフォーマンスを最適化します。ただし、CACHEオプションを使用すると、連続しない順序番号が生成される場合があります。連続しない順序番号を使用できない環境では、NOCACHEオプションを使用するか、または順序番号の事前生成を検討してください。アプリケーションでは順序番号の順序付けが必要で、連続しない順序番号を使用できる場合は、CACHEおよびORDERを使用して、Oracle RACの順序番号のキャッシュおよび順序付けを行います。アプリケーションで連続した順序番号の順序付けが必要な場合は、NOCACHEおよびORDERを使用します。NOCACHEとORDERの組合せは、その他のキャッシュおよび順序付けの組合せと比較すると、パフォーマンスに最も大きな影響を及ぼします。
|
注意: 連続しない順序番号を使用できない環境では、順序番号の事前生成を検討するか、またはORDERおよびCACHEオプションを使用してください。 |
索引を使用する場合は、逆キー索引などの方法を検討してパフォーマンスを最適化します。逆キー索引は、挿入日付に基づいた索引のように、索引の一方に頻繁に挿入を行う場合に特に有効です。
多くのユーザーは、複数のアプリケーションの単一データベースへの統合および複数のデータベースの単一クラスタへの統合を望んでいます。Oracle ClusterwareおよびOracle RACは、両方のタイプの統合をサポートしています。
Oracle ASMによって管理された単一の記憶域のプールでクラスタを作成すると、インフラストラクチャで複数のデータベースを(シングル・インスタンス・データベースか、またはOracle RACデータベースかに関係なく)管理できます。
Oracle RACデータベースの場合は、ワークロードの要件に基づいてインスタンスの数、および指定されたデータベースのインスタンスを実行するノードを調整できます。クラスタで管理されるサービスなどの機能を使用すると、単一データベースまたは複数のデータベース間で複数のワークロードを管理できます。
作業を追加する場合は、クラスタの容量を適切に管理することが重要です。クラスタを管理するプロセス(Oracle Clusterwareとデータベースの両方からのプロセスを含む)は、CPUのリソースを適時に取得できる必要があり、システム内で優先度が高く設定される必要があります。Oracle Database Quality of Service Management(Oracle Database QoS Management)は、パフォーマンス目標を満たすようにCPUリソースを動的に割り当てることで、クラスタまたはデータベース内での複数のアプリケーション統合を支援します。
|
関連項目: 詳細は、『Oracle Database Quality of Service Managementユーザーズ・ガイド』を参照してください。 |
サーバー上のリアルタイム・グローバル・キャッシュ・サービス・プロセス(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はインスタンスの起動時にプロセスの数を算出するため、その値を変更する場合はインスタンスを再起動する必要があります。
Oracle RACでは、複数のシステムからデータの個別コピーへのトランザクションに一貫性のある同時アクセスが可能です。単一のサーバーの容量を超えたスケーラビリティも実現します。アプリケーションが対称マルチプロセッシング(SMP)サーバーで透過的にスケール変更する場合は、そのアプリケーションはアプリケーション・コードを変更しなくてもOracle RACで適切にスケール変更すると想定できます。
従来、データベース・サーバーが容量を超えて実行される場合は、より大きな新しいサーバーに置き換えられてきました。サーバーの容量が大きくなると、価格も上がります。ただし、Oracle RACデータベースには、容量を増やすための別の手段があります。
現行のハードウェアへの投資を維持し、新しいサーバーをクラスタに追加する(あるいは新しいクラスタを作成または追加する)ことで、容量を増やすことができます。
Oracle ClusterwareおよびOracle RACを使用してクラスタにサーバーを追加する場合、停止は必要ありません。新規インスタンスが起動されると同時に、アプリケーションは追加された容量を使用できます。
クラスタ内のすべてのサーバーは、同じオペレーティング・システムと同じバージョンのOracle Databaseを実行する必要がありますが、各サーバーの容量を完全に揃える必要はありません。Oracle RACを使用すると、要件にあったクラスタ(デュアルCPUの汎用サーバーで構成されるクラスタや、32または64のCPUが組み込まれたサーバーで構成されるクラスタなど)を構築できます。Oracleのパラレル実行機能を使用すると、1つのSQL文を複数のプロセスに分割でき、それぞれのプロセスで作業のサブセットが実行されます。Oracle RAC環境では、パラレル・プロセスをユーザーが接続されているインスタンスでのみ実行するように定義したり、クラスタ内の複数のインスタンス間で実行するように定義することができます。
この項では、Oracle RAC環境でのデータベースの設計およびデプロイメント方法について簡単に説明します。また、高可用性を実現するための考慮事項を説明し、Oracle RACの様々なデプロイメントに関する一般的なガイドラインを示します。
Oracle RACデータベース上にデプロイするアプリケーションの設計および開発時には、次の手順の実行を検討してください。
設計とアプリケーションのチューニング
メモリーとI/Oのチューニング
競合のチューニング
オペレーティング・システムのチューニング
|
注意: アプリケーションをSMPシステムで拡張できない場合は、アプリケーションをOracle RACデータベースに移動してもパフォーマンスは向上しません。 |
挿入集中型オンライン・トランザクション処理(OLTP)アプリケーションには、ハッシュ・パーティション化を使用することを検討します。ハッシュ・パーティション化の特長は次のとおりです。
OLTP環境に対して表および索引のハッシュ・パーティション化を使用すると、Oracle RACデータベースでのパフォーマンスが大幅に向上します。ハッシュ・パーティション化された索引では、索引レンジ・スキャンは使用できないことに注意してください。
この項では、Oracle RACデータベースをデプロイする際の考慮事項について説明します。ここで説明する方法を採用しない場合でも、Oracle RACデータベースのパフォーマンスが低下することはありません。効率的な非クラスタ設計であれば、アプリケーションはOracle RACデータベースで効率的に実行されます。
この項の内容は次のとおりです。
ローカル管理表領域の使用の他に、自動セグメント領域管理(ASSM)および自動UNDO管理を使用して領域管理をさらに簡単にすることができます。
ASSMでは、挿入を行うためのブロックの各インスタンスのサブセット間にインスタンスのワークロードが分散されます。これによってブロック転送が最小限に抑えられるため、Oracle RACパフォーマンスが向上します。自動UNDO管理をOracle RAC環境にデプロイするには、各インスタンスに固有のUNDO表領域が必要です。
原則として、DDL文の使用はメンテナンス・タスクのみに限定し、システム操作のピーク時には実行しないようにします。ほとんどのシステムでは、新しいオブジェクトの生成量とその他のDDL文に対する制限が必要です。非クラスタのOracle Databaseの場合と同様に、オブジェクトの作成と削除が多くなるとパフォーマンスのオーバーヘッドが増加する可能性があります。
Oracle RACデータベース環境にノードを追加する場合は、SYSAUX表領域のサイズを大きくする必要があります。また、クラスタ・データベースのノードを削除する場合は、SYSAUX表領域のサイズを小さくできる場合もあります。
|
関連項目: 複数のインスタンスに対するSYSAUX表領域のサイズの設定方法については、プラットフォーム固有のOracle RACのインストレーション・ガイドを参照してください。 |
Oracle RAC環境でXAトランザクションを実行しているときに、そのパフォーマンスが低い場合は、密結合分散トランザクションのすべてのブランチを同じインスタンスに割り当てます。
これを実現するには、1つ以上のOracle RACインスタンスで複数のOracle分散トランザクション処理(DTP)サービスを作成します。各DTPサービスは、1つのみのOracle RACインスタンスで使用可能な単一のサービスです。分散トランザクション処理のためのデータベース・サーバーへのアクセスは、すべてDTPサービスを経由する必要があります。単一のグローバル分散トランザクションのすべてのブランチが、同じDTPサービスを使用することを確認してください。つまり、TNS名やJDBC URLなどのネットワーク接続記述子には、分散トランザクション処理をサポートするためにDTPサービスを使用する必要があります。
|
関連項目:
|
Oracle RACデータベースはキャッシュ・フュージョンによって、オンライン・トランザクション処理(OLTP)アプリケーションに最適なデプロイメント・サーバーになります。これは、これらのアプリケーションには次の要件があるためです。
Oracle DatabaseおよびOracle RACの高可用性機能は、処理を中断することなく、障害が発生していないインスタンスにワークロードを再分散し、ロード・バランシングを実行できます。さらに、Oracle RACは、優れたスケーラビリティも提供するため、ノードを追加または置換した場合、Oracle Databaseは、リソースを再マスター化してロードの処理を再分散します。
オンライン・トランザクション処理システムの頻繁に変化するワークロードに対応するには、Oracle RACは、システム負荷やシステム可用性が変化しても、柔軟かつ動的に対応します。Oracle RACは、たとえば次のような原因で変動する幅広いサービス・レベルに対応します。
ユーザーの需要の変化
取引の集中(大量取引の発生)など、ピーク時のスケーラビリティの問題
システム・リソースの可用性の変化
この項では、Oracle RAC環境でのデータ・ウェアハウス・システムのデプロイ方法について説明します。また、共有ディスク・アーキテクチャで使用可能なデータ・ウェアハウス機能についても説明します。
この項の内容は次のとおりです。
Oracle RACは、Oracle Databaseの非クラスタのメリットを拡大するため、データ・ウェアハウス・アプリケーションには理想的です。Oracle RACは、Oracle RACデータベースに属するすべてのノード上で使用可能な処理能力を最大限に活用して、データ・ウェアハウス・システムをスピードアップおよびスケールアップすることによって、Oracleのシングル・インスタンスのメリットを拡大します。
クエリー・オプティマイザは、最適な実行計画の判断に、パラレル実行を検討します。クエリー・オプティマイザのデフォルトのコスト・モデルはCPU+I/Oで、コスト単位は時間です。Oracle RACでは、クエリー・オプティマイザが、プロセッサ数に基づいてパラレル化の適切なデフォルト値を動的に計算します。代替アクセス・パスのコスト評価(表スキャンと索引アクセスなど)では、操作に使用できる並列度(DOP)が考慮されます。これによってOracle Databaseは、Oracle RAC構成用に最適化された実行計画を選択します。
Oracle Databaseのパラレル実行機能では、マルチ・プロセスを使用して1つ以上のCPUでSQL文を実行します。パラレル実行は、非クラスタOracle DatabaseおよびOracle RACデータベースの両方で使用できます。
Oracle RACは、パラレル処理をすべての利用可能なインスタンスに分散することによってパラレル実行を十分に活用します。パラレル操作に使用できるプロセスの数は、各表または索引に割り当てられる DOPによって異なります。
|
関連項目:
|
この項では、2つのOracle RACセキュリティの考慮事項について説明します。内容は次のとおりです。
Oracle Database 11g リリース2(11.2)では、Oracle RACノードでウォレットを共有できます。これによって、すべてのノードにウォレットを手動でコピーし同期化する必要がなくなります。ウォレットは、共有ファイル・システムで作成することをお薦めします。こうすることで、すべてのインスタンスが同じ共有ウォレットにアクセスできるようになります。
Oracle RACでは、次のようにウォレットが使用されます。
ある1つのOracle RACインスタンスで実行されるウォレットのオープン、クローズなどのウォレット操作は、他のすべてのOracle RACインスタンスに適用されます。つまり、1つのインスタンスでウォレットをオープンおよびクローズすると、すべてのOracle RACインスタンスでウォレットがオープンおよびクローズされます。
共有ファイル・システムを使用する場合は、すべてのOracle RACインスタンスのENCRYPTION_WALLET_LOCATIONパラメータが、必ず同じ共有ウォレットの場所を指すようにします。また、セキュリティ管理者は、適切なディレクトリ権限を割り当てることによって、共有ウォレットのセキュリティを確保する必要もあります。
|
注意: オペレーティング・システムでOracle Automatic Storage Managementクラスタ・ファイル・システム(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_wallet)))
このファイル・システムは、インスタンスの起動時に自動的にマウントされます。ウォレットのオープンとクローズ(およびTDEマスター暗号化鍵の設定またはキー更新およびローテーションを行うコマンド)は、すべてのノードで間で同期化されています。 |
ある1つのインスタンスで実行されるmaster key rekeyは、すべてのインスタンスに適用されます。新しいOracle RACノードは、構成されると、現在のウォレットのステータス(オープンまたはクローズ)を認識します。
マスター・キーの設定または変更中に、ウォレットのopenまたはcloseコマンドを発行しないでください。
共有ストレージがウォレット用に存在しないデプロイメントでは、各Oracle RACノードでローカル・ウォレットを保持する必要があります。単一のノードでウォレットを作成およびプロビジョニングした後、次のようにウォレットをコピーして他のすべてのノードで使用可能にする必要があります。
暗号化されたウォレットとともに透過的データ暗号化を使用するシステムでは、任意の標準ファイル転送プロトコルを使用できますが、保護されたファイル転送を使用することをお薦めします。
不明瞭にされたウォレットとともに透過的データ暗号化を使用するシステムでは、保護されたチャネルを介してファイルを転送することをお薦めします。
ウォレットが存在するディレクトリを指定するには、sqlnet.oraファイル内のENCRYPTION_WALLET_LOCATIONパラメータを設定します。SQL文ALTER SYSTEM SET KEYを使用してサーバー・キーが再設定されるまで、透過的データ暗号化の使用中にウォレットのローカル・コピーを同期化する必要はありません。データベース・インスタンスでALTER SYSTEM SET KEY文を発行するたびに、ノードに存在するウォレットを再度コピーし、他のすべてのノードで使用可能にする必要があります。次に、各ノードでウォレットを閉じてから再度開く必要があります。不要な管理オーバーヘッドを回避するために、サーバー・マスター・キーのセキュリティが低下したり、キーを再設定しないと重大なセキュリティ問題が発生することが明確な例外的な場合のためにキーの再設定を予約します。
|
関連項目: ウォレットの作成およびプロビジョニングの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。 |
デフォルトにより、Windows Server 2003 Service Pack 1以上のすべてのインストレーションにおいて、Windowsファイアウォールは、着信接続に対するほとんどすべてのTCPネットワーク・ポートをブロックできます。そのため、TCPポート上で着信接続をリスニングするOracle製品はすべて、これらのどの接続要求も受信せず、これらの接続を行っているクライアントはエラーを報告します。
インストールするOracle製品およびその使用方法によって、Windows Server 2003でファイアウォール製品が機能するように、Windowsのインストール後の追加の構成作業を実行する必要があります。
|
関連項目: Windowsファイアウォールの例外に必要なOracle RACの実行可能ファイルの詳細は、Oracle Real Application Clustersインストレーション・ガイドのMicrosoft Windows版を参照してください。 |
