| Oracle Database高可用性ベスト・プラクティス 11gリリース1（11.1） B54839-01 |
|
 戻る |
 次へ |
Oracleクラスタウェアは、ユーザー・アプリケーションとOracleデータベースの可用性を管理するソフトウェアです。Oracle RACの稼働するほとんどのプラットフォームで必要なクラスタウェアは、Oracleクラスタウェアのみです。他のベンダーのクラスタウェアでも、Oracle RACでの使用が認定されていれば使用できます。ただし、Oracleクラスタウェアにより提供されている機能に対して不要なソフトウェア・レイヤーを追加すると、複雑さとコストが増大し、特に計画済のメンテナンスなどでシステムの可用性が低下する可能性があります。
Oracleクラスタウェアには、任意のアプリケーションを管理するためのインフラストラクチャを提供する高可用性フレームワークが含まれます。Oracleクラスタウェアにより、システムの起動時に管理対象アプリケーションが開始されることが保証されます。Oracleクラスタウェアは、アプリケーションが常に使用できるよう監視も行います。たとえば、プロセスに障害が発生した場合、Oracleクラスタウェアは、ユーザーがカスタマイズしたスクリプトに基づいてそのプロセスを再起動します。クラスタ内のノードに障害が発生した場合、通常は障害の発生したノードで稼働するプロセスをプログラムして別のノードで再起動できます。アプリケーションの監視の頻度、アプリケーションの開始と停止、およびアプリケーションの依存性は、構成可能です。
|
関連項目: Oracleクラスタウェアでアプリケーションの可用性を管理する方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
計画済および計画外のメンテナンス・アクティビティには、次の構成ベスト・プラクティスを使用します。後続の項では、これらの構成のベスト・プラクティスを運用コンテキストに従って使用します。
クラスタ上に、異なるソフトウェア・リリースのOracleクラスタウェア、ASMおよびOracle Databaseをインストールする場合は、次のベスト・プラクティスに従ってください。
Oracleクラスタウェアには、データベースおよびASMのリリースと同じかそれより番号の大きいリリースをインストールします。
可能な場合、データベース、クラスタウェアおよびASMのリリースを同じにします。混合リリース環境（互換性マトリックス参照）は、サポートされてはいても、管理コストの上昇を招き、また、Oracleのパッチとパッチ・セットの適用にあたって、あらかじめ入念な計画が必要になります。
|
関連項目: ご使用のプラットフォームに対応するOracleクラスタウェアのインストレーション・ガイド |
適切なキャパシティ・プランニングは、Oracleのクラスタリング・テクノロジのあらゆる側面にとって重要な成功要因ですが、計画済のメンテナンスにとっては特に重要です。あるクラスタの一部分のみ（ノードなど）が使用できなくなったときでも、そのクラスタの担当する作業が確実に実行されるようにする必要があります。計画済または計画外の停止の発生後にクラスタを実行できなくなると、システム・リソースの不足から連鎖的に問題が発生する可能性が高まります。
クラスタのサイズを決定する場合、一般的な計画済または計画外の停止の発生後に残されるコンピューティング・リソースの量をnパーセントとして、そのクラスタのnパーセントでサービス・レベルを満たすことができるようにする必要があります。たとえば、4ノード構成のクラスタがあり、一度に1つのノードをアップグレードするローリング・アップグレードの方法でパッチを適用する場合、残りの3つのノードでアプリケーションからリクエストされる作業を実行できます。
計画済のメンテナンス時に重要なキャパシティ・プランニングのもう1つの留意点は、計画済のメンテナンスの一部として実行される作業を、可能であればアプリケーション作業から分離することです。たとえば、すべてのノードへのパッチ適用後にSQLスクリプトを実行する必要がある場合のベスト・プラクティスは脚注1、パッチが適用される最後のノードで、そのノードを使用してアプリケーションを起動する前にそのスクリプトを実行することです。この方法を使用すると、SQLスクリプトは、ノード上のオペレーティング・システム・リソースをすべて使用できるため、アプリケーションに影響を与える可能性が低下します。
すべてのローリング・パッチ機能の要件は、パッチの適用を受けるソフトウェア・ホームが、共有されていないローカル・ホームであることです。ソフトウェアは、クラスタ内の各ノードのローカル・ファイル・システムに物理的に存在しており、共有クラスタ・ファイル・システム上には存在していない必要があります。
この要件の理由は、共有クラスタ・ファイル・システムが使用されている場合、1つのノード上のソフトウェアにパッチを適用すると、すべてのノードに影響を与えることになり、すべてのノード上のソフトウェアを使用するすべてのコンポーネントを停止する必要が生じるためです。ローカル・ファイル・システムを使用すると、他のノードに存在するソフトウェアに影響を与えることなく、1つのノードでソフトウェアにパッチを適用できます。
これまで、Oracleデータベースのパッチ・セットは、インプレースで適用されてきました。つまり、新しいコードが古いコードに直接適用されました。パッチ・セットをインプレースで適用する理由は、領域使用量の節約やインストールの簡略化など様々です。しかし、これらの理由の多くは、今日のIT環境に当てはまらなくなりました。インプレースによるデータベース・パッチ・セット・アップグレードのデメリットは、新しいコードのコピー中にアプリケーションがデータベースに接続できなくなることです脚注2。可用性に対するこの影響を避けるには、Oracleのクローニング・テクノロジとアウトオブプレースによるパッチ・セット・インストールを組み合せて使用します。クローニング・テクノロジにより、既存のソフトウェアを新しいORACLE_HOMEにコピーし、その後でパッチ・セットを適用できます。
クローニングによるアウトオブプレース・パッチ・セット・インストールには、次のメリットがあります。
新規ORACLE_HOMEでのソフトウェアのアップグレード中も、引き続きアプリケーションを使用できます。
クローニング手順にはソフトウェアの物理的なコピー操作が含まれるため、ORACLE_HOME内の構成は保持されます脚注3。
クローニングによるアウトオブプレース・パッチ・セット・インストールのデメリットは、アプリケーション・コードおよびOracle固有のスクリプトにハードコードされている$ORACLE_HOME環境変数をすべて変更する必要があることです。
アプリケーションの可用性がカスタマイズの変更より重要な場合は、クローニングによるアウトオブプレース・パッチ・セット・インストールの実行を検討してください。
|
注意: Oracleには、アップグレード中の停止時間を数秒間にまで短縮するSQL Applyローリング・アップグレードやOracle Streamsなどの他のソリューションもあります。アウトオブプレース・パッチ・セット・インストールを使用すると、これらの機能の利用に伴う特別な手順（および潜在的な制限事項）なしでメリットを得ることができます。たとえば、SQL Applyローリング・アップグレードとOracle Streamsには、その使用を妨げる可能性のあるデータ型の制限があります。 |
作業中のノードに対して、またはそのノードからクライアント接続を移行できる機能は、計画済のメンテナンスの重要な側面です。クライアント接続の移行は、ソフトウェアの停止を必要とする計画済のメンテナンス・アクティビティ（ローリング・アップグレードの実行時など）において常に最初の手順となります。ソフトウェアの停止作業が開始したときにまだアクティブなデータベース接続があると、問題の発生する可能性が高まります。
Oracleでは、この目的を達成するために、各種サービス、FAN、FAN統合クライアント、クライアント側のロード・バランシング、高速接続フェイルオーバーおよび実行時接続ロード・バランシングを提供しています。Oracle RAC環境でのクライアント・フェイルオーバーのベスト・プラクティスの詳細は、Oracle Technology Networkの次の場所にあるホワイト・ペーパー『Workload Management with Oracle Real Application Clusters』を参照してください。
http://www.oracle.com/technology/products/database/clustering/pdf/awmrac11g.pdf
計画済のメンテナンス中におけるクライアント・リダイレクションのベスト・プラクティス・プロセスの例は、次のとおりです（注意: 次の例は、FAN ONS脚注4に固有です）。
FAN ONS統合クライアントを、実行時接続ロード・バランシングと高速接続フェイルオーバーで適切に構成します。
Oracleクラスタウェアは、停止されるインスタンス上のサービスを停止するか、それらのサービスを代替インスタンスに再配置します。
Oracleクラスタウェアは、Service-Member-Downイベントを戻します。
FAN ONS統合クライアントは、イベントを受信し、サービスを提供する他のインスタンスに接続を移動します。
同じORACLE_HOMEからASMとOracleデータベース・インスタンスを実行することは技術的に可能ですが、推奨される構成ではありません。パッチ適用時およびアップグレード時の柔軟性を向上するため、データベース用のORACLE_HOMEとASMインスタンス用のASMホームを作成する必要があります。たとえば、データベースにより排他的に使用されるコードを修正するパッチを適用するために、ボリューム・マネージャ（ASM）を停止せずに済みます。ボリューム・マネージャを停止する場合、パッチの適用されるコードを使用していないデータベースも含め、すべてのデータベースを停止する必要があります。
多くのOracleホームが存在すると、使用中の1つ以上のリスナーを管理する際に混乱してエラーが発生しやすくなります。複数のバージョンが使用できる場合、最新バージョンのリスナーを実行する必要があります。一般的にデータベース・ソフトウェアの前にASMソフトウェアを更新する場合、ASMホームからリスナーを実行すると、ネットワーク構成の管理が簡単になり、古いリスナー・コードの潜在的な不具合を予防的に避けることができます。
サービスにただ1つの優先インスタンスが存在する場合、そのサービスは、優先インスタンス上での停止後に、使用可能なインスタンスで即座に起動できるようにする必要があります。サービスを即座に起動すると、影響を受けるクライアントは、即座に再接続して作業を継続できます。Oracleクラスタウェアがこの処理を担当しますが、これは計画外の停止時にきわめて重要です。計画済のメンテナンス時にサービスの起動をOracleクラスタウェアに任せる場合でも、早めに代替優先インスタンスを手動で起動し、代替インスタンス上でサービスを使用できるようにする方が安全です。代替インスタンスを手動で起動することにより、単一の優先インスタンスに伴うシングル・ポイント障害が排除されます。また、計画済のアクティビティであることから余裕を持ってこの処理を実行できます。サービス定義に少なくとも第2の優先インスタンスを追加し、計画済のメンテナンスの前にそのサービスを起動しておきます。その後、別のサービス・メンバーが使用できることを確認して、メンテナンスを実行するインスタンス上のサービスを停止します。1つ以上の優先インスタンスの追加は、永続的な変更である必要はありません。計画済のメンテナンスの実行後に、元のサービス定義に戻すことができます。サービス・プロファイルを変更せずにサービスを手動で再配置すると、次のような場合にメリットを得ることができます。
Oracle XAを使用中の場合、複数のインスタンス上でサービスを実行することはサポートされないため、手動によるサービスの再配置を使用します。
アプリケーションが複数のサービス・メンバーとともに適切に動作するよう設計されていない場合、アプリケーション・エラーまたはパフォーマンス問題が発生する可能性があります。
すべての構成変更と同じように、本番環境に変更を実装する前に、複数のメンバーを含むサービスの効果をテストし、テスト環境でその存続可能性と影響を評価する必要があります。
Oracle Database 11gでは、アプリケーション・ワークロードを個別に管理および制御できるように、それらのワークロードをサービスとして定義できます。DBAは、通常運用時と障害対応時において各サービスにどの処理リソースを割り当てるかを制御します。サービスによりパフォーマンス・メトリックが追跡され、一定の値を超えたときにアラートを自動生成するためのしきい値が設定されます。サービスでのCPUリソース割当てとリソース使用量制御は、データベース・リソース・マネージャを通じて管理されます。ジョブ・スケジューラ、パラレル問合せ、Oracle Streamsアドバンスト・キューイングなどのOracleツールおよび機能でも、サービスの使用によりそのワークロードが管理されます。
Oracle Database 11gでは、処理リソースをサービスに自動で割り当てるためのルールを定義できます。Oracle Databaseリリース11gインスタンスのOracle RACは、個々のサービスまたは複数のサービスを処理するために必要に応じて割り当てることが可能です。これらの割当てルールは、変化するビジネス要件に合せて動的に変更できます。たとえば、重要な財務処理を予定どおり完了するのに十分な処理リソースを確保するため、これらのルールを四半期後に変更できます。ルールを定義して、重要度の高いサービスを実行するインスタンスに障害が発生したときに、そのワークロードを重要度の低いワークロードを実行するインスタンスに自動で移行することも可能です。サービスは、Oracle Enterprise ManagerおよびDBMS_SERVICE PL/SQLパッケージで作成および管理できます。
データベースへのアプリケーション接続は、サービスに対する仮想インターネット・プロトコル（VIP）・アドレスを通じて行う必要があります（VIPアドレスは、最高度の可用性と管理性を実現するワークロード管理機能の一部として定義されます）。
VIPアドレスは、クライアント接続で標準のパブリックIPアドレスのかわりに使用される代替パブリック・アドレスです。あるノードに障害が発生すると、そのノードのVIPアドレスは別のノードにフェイルオーバーされますが、そのVIP上にはリスニングするリスナーがいないため、クライアントがそのVIPアドレスに接続を試みると、長い時間TCP接続のタイムアウト・メッセージを待機することなく、接続拒否エラー（ORA-12541）を受信します。このエラーの結果、クライアントはアドレス・リスト内の次のアドレスに迅速に移動して有効なデータベース接続を確立します脚注5。VIPアドレスは、仮想インターネット・プロトコル・コンフィギュレーション・アシスタント（VIPCA）を使用して構成します。
|
関連項目: ワークロード管理の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
クライアント側のロード・バランシングにより、接続リクエストがすべてのリスナーに均等に分散されます。クライアント接続の定義でこれを指定するには、LOAD_BALANCEパラメータをONに設定します。（記述リストのデフォルトは、ONです。）このパラメータがONに設定されている場合、Oracleデータベースは、アドレス・リスト内のアドレスをランダムに選択してそのノードのリスナーに接続します。これにより、クライアント接続数が、クラスタ内の使用可能なリスナー全体に分散されます。リスナーは、接続リクエストを受信すると、認識しているサービスのうちで要求されたサービスを提供しているインスタンスにユーザーを接続します。リスナーによりサポートされるサービスを確認するには、LSNRCTLサービス・コマンドを実行します。
サーバー側のロード・バランシングでは、接続リクエストでデータベース・サービスを要求されると、使用可能なインスタンスで実行されている現在のワークロードを使用して、その接続リクエストを、負荷の最も低いノードの負荷の最も低いインスタンスに割り当てます。サーバー側の接続ロード・バランシングでは、各インスタンスを使用可能なすべてのリスナーに登録する必要があります。これを行うには、各インスタンスでLOCAL_LISTENERおよびREMOTE_LISTENERパラメータを設定します。これらのパラメータは、DBCAでデータベースを作成するとデフォルトで設定されます。
接続ロード・バランシングの機能を拡張するには、ロード・バランシング・アドバイザを使用して、DBMS_SERVICE PL/SQLパッケージでGOALおよびCLB_GOAL属性を設定して各サービスの接続ロード・バランシングの目標を定義します。
FAN統合なしで接続プールを使用する場合、CLB_GOALをLONGに設定します。
Oracle Implicit Connection Cache（ICC）などのFAN統合とともに接続プールを使用する場合、CLB_GOALをSHORTに設定します。
ICCおよびUCP（Universal Connection Pool for Java）の実行時接続ロード・バランシング機能には、CLB_GOAL=SHORT属性設定も必要です。この機能では、アプリケーション・サービスを提供する各インスタンスに適切に作業を分散するため、データベースのメトリックを使用します。
|
関連項目:
|
OCRには、クラスタ・リソースに関する重要な構成データが含まれます。Oracleクラスタウェアの機能を使用してOCRをミラー化することにより、OCRを常時保護してください。Oracle Databaseでは、OCRがミラー化されている場合、2つのOCRが自動的に保護されます。
投票ディスクは、共有ディスクに存在する必要があります。高可用性を確保するため、可能であれば、コントローラの異なる複数のストレージ・デバイス上に複数の投票ディスクを保持することをお薦めします。Oracleクラスタウェアでは、複数の投票ディスクを使用できますが、投票ディスクの数は3、5などの奇数である必要があります。単一の投票ディスクを定義する場合は、外部冗長ストレージを使用して冗長性を確保します。
|
関連項目: OCRおよび投票ディスクの管理方法の詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。 |
Oracleクラスタウェアでは、クラスタ内の1つのノード上で、4時間ごとに自動的にOCRのバックアップが作成されます。これがOCRマスター・ノードです。Oracleでは、OCRの最新の3つのバックアップ・コピーが常に保持されます。バックアップを作成するCRSDプロセスにより、1日ごと、および各週の終わりにもOCRのバックアップが作成されて保持されます。Oracleクラスタウェアによって作成されたバックアップ・ファイルは、Oracle Secure Backup、標準のオペレーティング・システム・ツールまたはサード・パーティ・ツールを使用して、オペレーティング・システム・バックアップの一環としてバックアップする必要があります。
自動作成されたOCRバックアップ・ファイルを使用する他、ocrconfigコマンドで-manualbackupオプションを使用して、リクエストごとに手動バックアップを実行することができます。たとえば、OCRに対して変更（現在の環境でのノードの追加または削除、Oracleクラスタウェア・リソースの変更、データベースの作成など）を行う前後に、手動バックアップを実行できます。ocrconfig -manualbackupコマンドを使用すると、OCRの内容がファイル形式でエクスポートされます。ocrconfigで作成したエクスポート・ファイルは、Oracle Secure Backup、標準のオペレーティング・システム・ツールまたはサード・パーティ・ツールを使用して、オペレーティング・システム・バックアップの一環としてバックアップできます。
|
関連項目: OCRのバックアップ方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
最も効率的なネットワーク検出およびフェイルオーバーを実現するため、OracleクラスタウェアとOracle RACでは、接続とアクセス可能性について同じ認識を共有するように同じインターコネクト・サブネットを使用する必要があります。次の手順でインターコネクト・サブネットを確認します。
Oracle RACで使用されているインターコネクト・サブネットを確認するには、インスタンスの警告ログのインスタンス起動セクションで既存のRACデータベースを確認するか、いずれかのインスタンス上でOracle ORADEBUGユーティリティを実行します。たとえば、次のようになります。
SQL> ORADEBUG SETMYPID
Statement processed.
SQL> ORADEBUG IPC
Information written to trace file.
SQL> ORADEBUG tracefile_name
/u01/app/oracle/admin/prod/udump/prod1_ora_24409.trc
トレース・ファイルのSSKGXPTセクションを調べ、Oracle RACで使用されているサブネットを確認します。この例では、次のように使用サブネットは192.168.0.3で、使用プロトコルはUDPです。
SSKGXPT 0xd7be26c flags info for network 0
socket no 7 IP 192.168.0.3 UDP 14727
クラスタウェアで使用されているインターコネクト・サブネットを確認するには、次のようにOCRのキー名SYSTEM.css.node_numbers.noden.privatenameの値を調べます。
prompt> ocrdump -stdout -keyname SYSTEM.css.node_numbers [SYSTEM.css.node_numbers.node1.privatename] ORATEXT : halinux03ic0 . . . [SYSTEM.css.node_numbers.node2.privatename] ORATEXT : halinux04ic0
オペレーティング・システムのツールを使用して、ここでのホスト名（この例ではhalinux03ic0およびhalinux04ic0）が、ORADEBUGで生成されたトレース・ファイルのサブネット（サブネット192.168.0.3）と一致することを検証します。Linux上での実行例を次に示します。
prompt> getent hosts halinux03ic0 192.168.0.3 halinux03ic0.us.oracle.com halinux03ic0
Oracleクラスタウェアを使用して、コールド・フェイルオーバー・クラスタウェアを利用する可用性の高い任意のアプリケーション（単一インスタンス・データベースを含む）を作成します。Oracleクラスタウェアを使用して可用性の高いアプリケーションを作成する例は、Oracle Technology Networkの次の場所で確認できます。
http://www.oracle.com/technology/products/database/clusterware/index.html
脚注の説明
脚注1: この例は、すべてのノードへのCPUパッチのインストール後に実行する必要のあるCATCPU.SQLスクリプトです。LISTENER.ORA、TNSNAMES.ORA、INITSID.ORAなどのファイルがあげられます。DBMS_SERVICEパッケージを使用して、作業対象のインスタンスからセッションを削除できます。