| Oracle® Database高可用性ベスト・プラクティス 12cリリース1 (12.1) E57730-02 |
|
 前 |
 次 |
Oracle Clusterwareを使用すると、複数のサーバーが相互に通信することにより、1つの集合単位として機能するように見えます。Oracle Clusterwareでは、Oracle Real Application Clusters (Oracle RAC)とOracle RAC One Nodeの実行に必要なインフラストラクチャが提供されます。Grid Infrastructureはエンタープライズ・グリッド・アーキテクチャ用のインフラストラクチャを提供するソフトウェアです。クラスタの場合、このソフトウェアにはOracle Clusterwareと Oracle ASMが含まれます。スタンドアロン・サーバーの場合、Grid InfrastructureにはOracle RestartとOracle ASMが含まれます。Oracle Database 12cでは、このようなインフラストラクチャ製品がGrid Infrastructureホームと呼ばれる1つのソフトウェア・インストールに組み込まれています。Oracle Restartでは、単一インスタンスの(クラスタ化されていない)Oracle Database、Oracle ASMインスタンス、サービス、リスナー、およびサーバー上で実行されているその他のプロセスの起動および再起動が管理されます。ハードウェア障害またはソフトウェア障害後にサービスの割込みが発生すると、Oracle Restartは自動的にコンポーネントを再起動するために必要な処置を取ります。
この章には、次の項目が含まれます。
Oracle Clusterwareは、Oracle Grid Infrastructureの構成要素で、ユーザー・アプリケーションとOracleデータベースの可用性を管理するソフトウェアです。Oracle RACの稼働するほとんどのプラットフォームで必要なクラスタウェアは、Oracleクラスタウェアのみです。必要ならば、同じシステム上でOracle Clusterwareに加えて他のベンダーのクラスタウェアも使用できます。ただし、Oracleクラスタウェアにより提供されている機能に対して不要なソフトウェア・レイヤーを追加すると、複雑さとコストが増大し、特に計画メンテナンスなどでシステムの可用性が低下する可能性があります。
|
注意: Oracle RACまたはOracle RAC One Nodeをインストールする前に、Oracle ClusterwareおよびOracle Automatic Storage Management (ASM)で構成されたOracle Grid Infrastructureを最初にインストールする必要があります。Oracle ClusterwareおよびOracle ASMの作動開始後、Oracle Universal Installerを使用してOracle RACコンポーネントとともにOracle Databaseソフトウェアをインストールできます。 |
Oracleクラスタウェアには、任意のアプリケーションを管理するためのインフラストラクチャを提供する高可用性フレームワークが含まれます。Oracleクラスタウェアにより、システムの起動時に管理対象アプリケーションが開始されることが保証され、アプリケーションが常に使用できるよう監視も行われます。プロセスに障害が発生した場合、Oracleクラスタウェアは、エージェント・プログラム(エージェント)を使用してそのプロセスを再起動します。Oracleクラスタウェアにはビルトイン・エージェントが用意されているため、シェル・スクリプトまたはバッチ・スクリプトを使用してアプリケーションを保護および管理できます。Oracleクラスタウェアには、いくつかのアプリケーション(たとえば、Oracle TimesTen In-Memory Database)のための事前構成済エージェントも用意されています。クラスタ内のノードに障害が発生した場合、通常は障害の発生したノードで稼働するプロセスをプログラムして別のノードで再起動できます。アプリケーションの監視の頻度、アプリケーションの開始と停止、およびアプリケーションの依存性は、構成可能です。
Oracle RAC One Nodeは、クラスタ内の1つのノードで実行されるOracle RACデータベースの単一インスタンスです。Oracle RAC One Nodeの操作の詳細は、6.2項「Oracle RAC One Nodeを使用したOracle Databaseの構成」を参照してください。
|
関連項目:
|
Oracleに備わっている次の機能を使用すると、ノード間でクライアント接続を移行できます。これらの機能により、クライアントに対するノード障害の影響を最小限に抑えられます。
クライアント側のロード・バランシングおよび接続ロード・バランシング。詳細は、5.2.6項「クライアント側およびサーバー側でのロード・バランシングの使用」を参照してください。
高速接続フェイルオーバー(FCF) (FAN対応クライアントによる使用が適切)
サービスは、接続要求とOracle RACインスタンス間のあらゆる固有マッピングを切り離します。サービスはOracle RACデータベースのワークロードの管理を可能にする、Oracle RACデータベース用に定義されたエンティティです。サービスは、Oracleデータベースで実行中の全ワークロードを相互に独立したクラスに分割します。各サービスは、共通属性、サービス・レベルのしきい値および優先度を使用してワークロードを表します。グループ化の基準となる属性が属す操作には、呼出し中のアプリケーション、呼出し対象のアプリケーション機能、アプリケーション機能の実行優先度、管理対象のジョブ・クラス、またはアプリケーション機能またはジョブ・クラスで使用されるデータ範囲などがあります。
ワークロードまたはアプリケーションのグループを管理するために、特定のアプリケーションまたはアプリケーションの一部の操作に割り当てるサービスを定義できます。また、作業の種類ごとにサービスとしてグループ化することもできます。たとえば、オンライン・ユーザーはあるサービスを使用し、バッチ処理は別のサービスを使用し、レポートはまた別のサービスを使用してデータベースに接続することができます。
1つのサービスを共有するすべてのユーザーで、サービス・レベルの要件を同じにすることをお薦めします。サービスには個別の特性を定義できるため、各サービスはそれぞれ別々の作業単位にできます。サービスの使用時には、多数のオプションを使用できます。これらのオプションを実装する必要はありませんが、それらを使用すると、アプリケーションのパフォーマンスが最適化できます。
高速アプリケーション通知(FAN)は、登録済クライアントに構成およびサービス・レベルの情報を通知するためにOracle Clusterwareに統合されている通知メカニズムであり、この情報にはUPイベントやDOWNイベントなどのサービス・ステータスの変更が含まれます。アプリケーションはFANイベントに応答して、すぐにアクションを実行できます。FANの UP イベントおよび DOWN イベントは、インスタンス、サービスおよびノードに適用できます。
高速アプリケーション通知(FAN)を使用するには、サービスの使用が必要です。
クラスタの構成が変更されて、クラスタ内で状態の変更が発生した場合、Oracle RACの高可用性フレームワークは、ただちにFANイベントを発行します。アプリケーションでは、データベースをポーリングして問題を検出するまで待機するかわりにFANイベントを受信して、ただちにアクションを実行できます。FANを使用すると、インフライト・トランザクションをただちに終了でき、インスタンスの失敗時にクライアントに通知することができます。
また、FANは、 ロード・バランシング・アドバイザ・イベントも発行します。アプリケーションでFANのロード・バランシング・アドバイザ・イベントを使用して、現在、クラスタ内で最適なサービス品質を提供しているインスタンスに作業要求を割り当てることができます。
|
関連項目: 高速アプリケーション通知の概要は、『Oracle Database管理者ガイド』を参照してください。 |
単一クライアント・アクセス名(SCAN)はOracle Real Application Clusters (Oracle RAC) 11gリリース2で導入され、クライアントがクラスタ内で実行中のOracle Databaseにアクセスするための単一名です。SCANを使用するクライアントの利点は、クラスタ内のノードを追加または削除しても接続文字列を変更する必要がないことです。クラスタにアクセスするための単一名を保持することで、クライアントではEZConnectクライアントとシンプルなJDBC thin URLを使用して、クラスタ内のどのサーバーでデータベースがアクティブな場合でも、クラスタで実行中のあらゆるデータベースにアクセスできます。SCANは、データベースへのクライアント接続のロード・バランシングおよびフェイルオーバーを提供します。SCANは、node1-vipのような、仮想IPアドレスに使用される名前に類似した仮想IP名です。ただし、仮想IPと異なり、SCANは個別のノードではなくクラスタ全体と関連付けられており、1つではなく複数のIPアドレスと関連付けられています。Oracle Real Application Clusters 12c SCANでは、クラスタ内で複数のサブネットがサポートされます(サブネット当たり1つのSCAN)。
|
関連項目:
|
アプリケーション・コンティニュイティ(AC)は、影響を受けた"処理中の"トランザクションをクラスタ内の別のデータベース・インスタンスでリプレイして、インスタンスおよびセッションの障害からアプリケーションを保護する新しいテクノロジです。
データベース・セッションを使用不能にするリカバリ可能なエラーの後に、データベースに対するリクエストを中断せず、迅速な方法でリプレイできるようにします。リクエストには、データベースへのトランザクション・コールおよび非トランザクション・コールが含まれることがあります。リプレイが成功した後、アプリケーションはデータベース・セッションが停止した位置から続行できます。
ユーザーは、トランザクションが無事に通過したかどうか不確かな状態に置かれたままになることはありません。
トランザクション・ガードは信頼性の高いプロトコルで、データベース・セッションを使用不能にしている、停止後に処理中だった最後のトランザクションの結果を返すツールです。トランザクション・ガードを使用しないと、停止後に操作を再試行しようとするアプリケーションおよびユーザーが、トランザクションを重複してコミットしたり、不適切な順序でトランザクションをコミットすることによって、論理破損が発生することがあります。
アプリケーション・コンティニュイティおよびトランザクション・ガードには、UCPリリース12.1.0.2以降を使用します。
|
関連項目: アプリケーション・コンティニュイティおよびトランザクション・ガードの詳細は、『Oracle Database開発ガイド』を参照してください。 |
次のようなOracle Clusterwareの構成ベスト・プラクティスを使用します。
Oracle ASMを使用した、Oracle Cluster Registry (OCR)のミラー化と複数の投票ディスクの構成
Oracle Clusterware、Oracle RACおよびOracle ASMで同じインターコネクト・ネットワークを使用していることの確認
クラスタ検証ユーティリティ(CVU)はインストール中に主なクラスタ・コンポーネントの検証を行い、このユーティリティを使用して構成およびコンポーネントを検証できます。コンポーネントは、ディスクの空き領域などの基本的なコンポーネントの場合と、Oracle Clusterwareの整合性チェックなどの複雑なコンポーネントの場合があります。たとえば、CVUは、Oracle Clusterwareレイヤー全体の複数のOracle Clusterwareサブコンポーネントを検証できます。また、CVUは、ディスク領域、メモリー、プロセスおよびその他の重要なクラスタ・コンポーネントをチェックできます。
|
関連項目: クラスタ検証ユーティリティの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
すべてのローリング・パッチ機能の要件は、パッチの適用を受けるソフトウェア・ホームが、共有されていないローカル・ホームであることです。ソフトウェアは、クラスタ内の各ノードのローカル・ファイル・システムに物理的に存在しており、共有クラスタ・ファイル・システム上には存在していない必要があります。
この要件の理由は、共有クラスタ・ファイル・システムが使用されている場合、1つのノード上のソフトウェアにパッチを適用すると、すべてのノードに影響を与えることになり、すべてのノード上のソフトウェアを使用するすべてのコンポーネントを停止する必要が生じるためです。ローカル・ファイル・システムを使用すると、他のノードに存在するソフトウェアに影響を与えることなく、1つのノードでソフトウェアにパッチを適用できます。
Oracle Grid Infrastructureをインストールし、Oracle Clusterwareを構成する場合は、次の点に注意します。
Oracle RACデータベースにはデータベース・ファイルのための共有ストレージが必要です。
Oracle Cluster Registry (OCR)と、Oracle ASMを使用するための投票ファイルを構成します。詳細は、5.2.7項「Oracle ASMを使用した、Oracle Cluster Registry (OCR)のミラー化と複数の投票ディスクの構成」を参照してください。
共有記憶域で共有ホームを使用するのではなく、ローカル・ホームにOracle Databaseをインストールすることをお薦めします。Oracle Databaseホームには共有ファイル・システムを使用しないことをお薦めします(共有ホームを使用すると、その共有場所から実行中のすべてのソフトウェアは、パッチを適用する前に停止することが必要なため、ローリング・アップグレードが実行できなくなります)。
Oracle ClusterwareとOracle ASMは両方とも、Grid Infrastructureホーム(Grid_home)と呼ばれる非共有ファイル・システム上の1つのホームにインストールされます。
|
関連項目: Oracle ASMのインストールの詳細は、『Oracle Database 2日でReal Application Clustersガイド』を参照してください。 |
サービスにただ1つの優先インスタンスが存在する場合、そのサービスは、優先インスタンス上での停止後に、使用可能なインスタンスで即座に起動できるようにする必要があります。サービスを即座に起動すると、影響を受けるクライアントは、即座に再接続して作業を継続できます。Oracleクラスタウェアがこの処理を担当しますが、これは計画外の停止時にきわめて重要です。
計画メンテナンス時にサービスの起動をOracleクラスタウェアに任せる場合でも、早めに代替優先インスタンスを手動で起動し、代替インスタンス上でサービスを使用できるようにする方が安全です。代替インスタンスを手動で起動することにより、単一の優先インスタンスに伴うシングル・ポイント障害が排除されます。また、計画済のアクティビティであることから余裕を持ってこの処理を実行できます。サービス定義に少なくとも第2の優先インスタンスを追加し、計画メンテナンスの前にそのサービスを起動しておきます。その後、別のサービス・メンバーが使用できることを確認して、メンテナンスを実行するインスタンス上のサービスを停止します。1つ以上の優先インスタンスの追加は、永続的な変更である必要はありません。計画メンテナンスの実行後に、元のサービス定義に戻すことができます。
サービス・プロファイルを変更せずにサービスを手動で再配置すると、次のような場合にメリットを得ることができます。
Oracle XAを使用中の場合は、手動によるサービスの再配置の使用が適切です。XAの指定ではトランザクション・ブランチをTMによって中断および再開できますが、接続ロード・バランシングが利用されている場合は、トランザクション・ブランチが開始されたインスタンスの代替Oracleインスタンスに再開された接続が配置される可能性があり、単一の分散トランザクションが複数のデータベース・インスタンスに及ぶ場合はパフォーマンスに関係してくるためです。
アプリケーションが複数のサービス・メンバーとともに適切に動作するよう設計されていない場合、アプリケーション・エラーまたはパフォーマンス問題が発生する可能性があります。
すべての構成変更と同じように、本番環境に変更を実装する前に、複数のメンバーを含むサービスの効果をテストし、テスト環境でその存続可能性と影響を評価する必要があります。
|
関連項目: Oracle Real Application ClustersのWebサイト(http://www.oracle.com/technetwork/database/clustering/overview/index.html)のテクニカル記事『XAとOracle制御の分散トランザクション』を参照してください。 |
作業中のノードに対して、またはそのノードからクライアント接続を移行できる機能は、計画メンテナンスの重要な側面です。クライアント接続の移行は、ソフトウェアの停止を必要とする計画メンテナンス・アクティビティ(ローリング・アップグレードの実行時など)において常に最初の手順となります。サービスのスイッチオーバーが開始したときにまだアクティブなデータベース接続があると、問題の発生する可能性が高まります。
計画メンテナンス中におけるクライアントのリダイレクトのベスト・プラクティス・プロセスの例には、次の手順が含まれる可能性があります。
クライアントはFAN通知を受け取るように構成され、実行時接続ロード・バランシングと高速接続フェイルオーバーのために適切に構成されています。
Oracleクラスタウェアは、停止されるインスタンス上のサービスを停止するか、それらのサービスを代替インスタンスに再配置します。
Oracleクラスタウェアは、Service-Member-Downイベントを戻します。
FAN通知を受け取るように構成されているクライアントは、Service-Member-Downイベントの通知を受け取り、サービスを提供する他のインスタンスに接続を移動します。
|
関連項目:
|
Oracle Database 12cでは、アプリケーション・ワークロードを自動または手動で管理および制御できるように、それらのワークロードをサービスとして定義できます。手動で管理するサービスについて、DBAは、通常運用時と障害対応時において各サービスにどの処理リソースを割り当てるかを制御します。サービスによりパフォーマンス・メトリックが追跡され、一定の値を超えたときにアラートを自動生成するためのしきい値が設定されます。サービスでのCPUリソース割当てとリソース使用量制御は、データベース・リソース・マネージャを通じて管理されます。ジョブ・スケジューラ、パラレル問合せ、Oracle Streamsアドバンスト・キューイングなどのOracleツールおよび機能でも、サービスの使用によりそのワークロードが管理されます。
Oracle Database 12cでは、処理リソースをサービスに自動で割り当てるためのルールを定義できます。Oracle Database 12cインスタンスのOracle RACは、個々のサービスまたは複数のサービスを処理するために必要に応じて割り当てることが可能です。これらの割当てルールは、変化するビジネス要件に合せて動的に変更できます。たとえば、重要な財務処理を予定どおり完了するのに十分な処理リソースを確保するため、これらのルールを四半期後に変更できます。ルールを定義して、重要度の高いサービスを実行するインスタンスに障害が発生したときに、そのワークロードを重要度の低いワークロードを実行するインスタンスに自動で移行することも可能です。SRVCTLユーティリティまたはOracle Enterprise Managerを使用して、サービスを作成および管理できます。
最高度の可用性と管理性を実現するには、VIPアドレス(可能ならばSCAN)をサービスと組み合せて使用して、データベースへのアプリケーション接続を行います。
VIPアドレスは、クライアント接続で標準のパブリックIPアドレスのかわりに使用される代替パブリック・アドレスです。あるノードに障害が発生すると、そのノードのVIPアドレスは別のノードにフェイルオーバーされますが、そのVIP上にはリスニングするリスナーがいないため、クライアントがそのVIPアドレスに接続を試みると、長い時間TCP接続のタイムアウト・メッセージを待機することなく、接続拒否エラー(ORA-12541)を受信します。このエラーの結果、クライアントはアドレス・リスト内の次のアドレスに迅速に移動して有効なデータベース接続を確立します。新規のクライアント接続はフェイルオーバーしたVIPに最初に接続しようとしますが、そのVIPにリスナーが実行されていなければ、「リスナーがありません。」というエラー・メッセージがクライアントに返されます。クライアントはアドレス・リスト内の次のアドレスに移動します。このリストには、フェイルオーバーしていないVIPがそこで実行中のリスナーとともに示されています。
単一クライアント・アクセス名(SCAN)は完全修飾名(ホスト名+ドメイン)で、SCANに割り当てられたすべての3つのVIPアドレスに解決するように構成されています。アドレスは、DNSサーバー上またはGNS構成のクラスタ内で、ラウンドロビンDNSによって解決します。SCANリスナーはクラスタ内の任意のノードで実行でき、複数のSCANリスナーは1つのノードで実行できます。
Oracle Database 12c以降では、インスタンスがデフォルトでリモート・リスナーとしてSCANリスナーに登録されます。
SCANはクラスタ・リソースです。SCAN VIPおよびSCANリスナーはランダム・クラスタ・ノードで実行されます。SCANは、クライアント構成が特定のデータベースを実行するノードに依存する必要がないように、データベースに位置の独立性を提供します。たとえば、クラスタにポリシー管理型のサーバー・プールを構成した場合、サーバー・プールにどのノードが割り当てられているかにかかわらず、SCANによってサーバー・プールのデータベースに接続できます。
SCAN名は仮想クラスタ・アドレスのように機能します。SCANは、クラスタ内の任意のノードで実行される可能性がある3つのSCAN VIPに解決されます。したがってエントリ・ポイントのようなノードごとのVIPアドレスとは異なり、SCANに接続中のクライアントには、仮想IPアドレスが追加、変更、またはクラスタから削除されても接続方法に関する更新は必要ありません。SCANアドレスは特定のノード・アドレスではなく、クラスタに解決されます。
Oracle Grid Infrastructureのインストールでは、SCANを解決するために割り当てられるIPアドレスと同数のSCANリスナーが作成されます。高可用性とスケーラビリティのため、SCANは3つのアドレスに解決することをお薦めします。SCANを3つのアドレスに解決する場合は、3つのSCANリスナーが作成されます。
Oracle RACはノードVIPアドレスを使用した フェイルオーバーを提供します。これは、同じデータベース・サービスに対するクライアント接続要求を管理するために、複数のノードで複数のリスナーを構成することで実現します。ノードに障害が発生した場合、VIPに接続中のサービスは動作可能なノードに透過的に再配置されます。クライアントまたはサービスが透過的アプリケーション・フェイルオーバー・オプションを使用して構成されている場合、そのクライアントは動作可能なノードに再接続されます。SCANリスナーが接続要求を受け取ると、SCANリスナーは最もロードされていない、要求されたサービスを提供しているインスタンスをチェックします。次に、最もロードされていないインスタンスが実行中のノードのローカル・リスナーに接続要求をリダイレクトします。続いて、クライアントにローカル・リスナーのアドレスが付与されます。ローカル・リスナーは最後にデータベース・インスタンスへの接続を作成します。
Oracle Database 11gリリース2より前のOracle DatabaseリリースのIPアドレスを使用するように構成されたクライアントは、既存の接続アドレスを引き続き使用できるため、SCANを使用する必要はありません。この場合、Database 11gリリース2より前のクライアントは、クラスタのノードVIPに解決されるTNS接続記述子を使用します。以前のバージョンのOracle DatabaseをアップグレードするとSCANリスナーに登録されるため、クライアントがSCANを使用してそのデータベースに接続できるようになります。データベースはinit.oraファイルのリモート・リスナー・パラメータを通じてSCANリスナーに登録されます。REMOTE_LISTENERパラメータは、SCAN:PORTに設定する必要があります。SCANをHOST=SCANとして設定した単一のアドレスを持つTNSNAMES別名には設定しないでください。クラスタにアクセスするための単一名を保持することで、クライアントではEZConnectクライアントとシンプルなJDBC thin URLを使用して、クラスタ内のどのサーバーでデータベースがアクティブな場合でも、クラスタで実行中のあらゆるデータベースにアクセスできます。たとえば、次のようになります。
sqlplus system@sales1-scan:1521/oltp
|
関連項目:
|
クライアント側のロード・バランシングは、LOAD_BALANCEパラメータをLOAD_BALANCE=ONに設定して、クライアントの接続定義(tnsnames.ora fileファイルなど)に定義します。このパラメータをONに設定した場合は、Oracle Databaseによってアドレス・リストから無作為にアドレスが選択されて、そのノードのリスナーに接続されます。これによって、クラスタ内で使用可能なSCANリスナー間で、クライアント接続が均等に分散されます。
SCANリスナーは、最もロードされていない、要求されたサービスを提供しているインスタンスのローカル・リスナーに接続要求をリダイレクトします。接続要求を受信したリスナーは、要求されたサービスを提供するとリスナーが認識しているインスタンスにユーザーを接続します。リスナーがサポートしているサービスを確認するには、lsnrctlサービス・コマンドを実行します。
クライアントがSCANを使用して接続する場合、Oracle NetはSCANに対して定義された3つのIPアドレスの間でクライアント接続要求のロード・バランシングを自動的に行います。ただし、EZConnectを使用している場合は行いません。
サーバー側のロード・バランシングでは、DBCAを使用してOracle RACデータベースを作成すると次のことが自動的に行われます。
サーバー側のロード・バランシングの構成および有効化
リモート・リスナー・パラメータのSCANリスナーへの設定(注意: DBCAを使用しない場合は、REMOTE_LISTENERデータベース・パラメータをscan_name:scan_portに設定する必要があります。)
サーバー上の tnsnames.ora ファイルにおけるクライアント側のロード・バランシング接続定義のサンプルの作成
|
注意: 次の機能はデフォルト・データベース・サービスでは動作しません。このような機能を活用するには、クラスタ管理サービスを作成する必要があります。自分が作成したサービスのみ管理できます。データベース・サーバーによって自動的に作成されたサービスはデータベース・サーバーによって管理されます。 |
接続ロード・バランシングをさらに強化するには、ロード・バランシング・アドバイザを使用して各サービスの接続ロード・バランシングを定義します。ロード・バランシング・アドバイザは、データベースとそのインスタンスが提供する現在のサービス・レベルについてアプリケーションに情報を提供します。ロード・バランシング・アドバイザは、サービス用に定義したポリシーに基づいて最適なサービスを得るために、アプリケーション要求の宛先に関する推奨事項をアプリケーションに提供します。ロード・バランシング・アドバイザのイベントは、ONSを介してパブリッシュされます。ランタイム接続のロード・バランシングにおけるサービス・レベルの目標値には、次の2つのタイプがあります。
SERVICE_TIME: 応答時間に基づいて、作業要求をインスタンスに割り当てます。ロード・バランシング・アドバイザのデータは、サービスで完了した作業の経過時間およびサービスに対して使用可能な帯域幅に基づきます。SERVICE_TIMEの使用例としては、需要が変動するインターネット・ショッピングなどのワークロードがあります。次の例は、オンライン・サービスを使用して、目標を接続のSERVICE_TIMEに設定する方法を示します。
srvctl modify service -d db_unique_name -s online -B SERVICE_TIME -j SHORT
THROUGHPUT: スループットに基づいて、作業要求をインスタンスに割り当てます。ロード・バランシング・アドバイザのデータは、サービスで完了した作業の処理速度およびサービスに対して使用可能な帯域幅に基づきます。THROUGHPUTの使用例としては、前のジョブが完了してから次のジョブを開始するバッチ処理などのワークロードがあります。次の例は、sjobサービスを使用して、目標を接続のTHROUGHPUTに設定する方法を示します。
srvctl modify service -d db_unique_name -s sjob -B THROUGHPUT -j LONG
|
関連項目:
|
Oracle Cluster Registry (OCR)と、Oracle ASMを使用するための投票ファイルを構成します。可能であれば、OCRをミラー化し、Oracle ASMの高冗長性ディスク・グループを使用して複数の投票ディスクを構成することをお薦めします。
Oracle Cluster Registry (OCR)には、クラスタ・リソースに関する重要な構成データが含まれます。たとえばOracle ASMの冗長性ディスク・グループなどを使用して、OCRを常に保護します。Oracle Clusterwareでは、Oracle Cluster Registry(OCR)を使用して、Oracle Clusterwareで制御するOracle RACデータベース、 リスナー、仮想IPアドレス(VIP)、サービスと任意のアプリケーションなどのコンポーネントの情報を格納および管理します。共有クラスタ・ファイル・システムの使用時にクラスタの高可用性を確保するには、Oracle ASMの使用時とは対照的に、複数のOCRの場所を定義することをお薦めします。
さらに、次の場合もあります。
最大5つのOCRの場所を使用できます。
各OCRの場所は、クラスタ内のすべてのノードがアクセスできる共有記憶域に存在している必要があります。
障害が発生したOCRの場所がOCRの唯一の場所でないかぎり、オンラインで交換できます。
OCRは、Oracle Enterprise Manager、サーバー制御ユーティリティ(SRVCTL)、OCR構成ユーティリティ(OCRCONFIG)、Database Configuration Assistant (DBCA)などのサポートされているユーティリティを介して更新する必要があります。
各OCRの場所は、クラスタ内のすべてのノードがアクセスできる共有ストレージに存在している必要があり、投票ディスクも共有ストレージに存在している必要があります。高可用性を確保するため、可能であれば、コントローラの異なる複数のストレージ・デバイス上に複数の投票ディスクを保持することをお薦めします。Oracleクラスタウェアでは、複数の投票ディスクを使用できますが、投票ディスクの数は3、5などの奇数である必要があります。単一の投票ディスクを定義する場合は、外部冗長ストレージを使用して冗長性を確保します。
拡張されたOracle RACには、メイン・サイト(データ・センター)とは異なる場所にあるアービタ・サイト上に存在するクォーラム(投票)ディスクが必要です。詳細は、6.3.2項「クォーラム・ディスクをホストするための第3の投票ディスクの追加」を参照してください。
|
関連項目:
|
Cluster Time Synchronization Service (CTSS)はOracle Clusterwareの要素としてインストールされます。デフォルトでは、時刻同期化サービスまたは時刻同期化サービス構成が、有効でも無効でもシステム上で検知されれば、CTSSはオブザーバ・モードで実行されます。時刻同期化サービスまたは時刻同期化サービス構成がクラスタ内のノードに存在しないことがCTSSで検知されれば、CTSSはアクティブ・モードになり、クラスタの時間管理を継承します。
ネットワーク・タイム・プロトコル(NTP)は、クライアント・マシンで正しい時間設定を維持するためにクライアント・アプリケーションとサーバー・アプリケーションが使用するプロトコルです。Oracle Clusterwareを実行している各データベース・サーバーはNTPクライアントであり、NTPクライアント・ソフトウェアをインストールし、クロックをネットワーク・タイム・サーバーと同期するように構成しておく必要があります。Windows TimeサービスはNTPの完全な実装ではありませんが、NTPの仕様に基づいています。
ベスト・プラクティスでは会社全体でNTPを使用します。
|
関連項目:
|
最も効率的なネットワーク検出およびフェイルオーバーと最適なパフォーマンスを実現するため、Oracle Clusterware、Oracle RACおよびOracle ASMでは、接続とアクセス可能性について同じ認識を共有するように同じ専用インターコネクト・サブネットを使用する必要があります。
次の手順を実行し、インターコネクト設定を確認します。
Oracle RACまたはOracle ASMインスタンスのインターコネクト設定を確認するには、次のいずれかを実行します。
次のコマンドを発行します。
SQL> select * from v$cluster_interconnects; NAME IP_ADDRESS IS_PUBLIC SOURCE ----- ---------- --------- ------- bond0 192.168.32.87 NO cluster_interconnects parameter
アラート・ログを調べて、インスタンスのインターコネクト設定を確認します。
クラスタウェアで使用されているインターコネクト・サブネットを検証する手順:
prompt> $GI_HOME/bin/oifcfg getif | grep cluster_interconnect bond0 192.168.32.0 global cluster_interconnect
|
注意: 1つのインスタンスには、複数のインターコネクトを指定できます。冗長性によって高可用性を保証するためにネットワーク・ボンディングを使用することがベスト・プラクティスとなります。 |
|
関連項目: アラート・ログの表示方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
冗長インターコネクトを使用するための複数のインタフェースは、インストール時またはインストール後にoifcfg setifコマンドを使用して、インタフェースをプライベートとして分類することで定義できます。これを実行する際、Oracle Clusterwareでは(定義するインスタンスの数に応じて)1つから4つのHighly Available IP (HAIP)アドレスが作成されます。このアドレスは、Oracle DatabaseおよびOracle ASMインスタンスによって使用され、可用性の高いロード・バランシングされた通信が確保されます。HAIPでは、デフォルトで、インターコネクト・トラフィックがすべてのアクティブなインターコネクト・インタフェースに対してロード・バランシングされ、あるアドレスに障害または通信不可が発生すると、対応するHAIPアドレスが他のアダプタに対して透過的にフェイルオーバーされます。Oracle Clusterwareは、予約された169.254.*.*サブネットから空いているリンク・ローカル・アドレスをHAIP用に自動で選択します。
Oracleソフトウェア(Oracle RAC、Oracle ASMおよびOracle ACFS、すべてのOracle Database 11gリリース2 (11.2.0.2)以降のリリースを含む)は、デフォルトでこれらのHAIPアドレスをトラフィックのすべてに使用するため、用意されたクラスタ・インターコネクト・インタフェースのセット全体に対するロード・バランシングが可能になります。定義済クラスタ・インターコネクト・インタフェースに障害が発生するか、または通信できなくなった場合、Oracle Clusterwareは、機能している残りのインタフェースに対応するHAIPアドレスを透過的に移動します。
|
注意: Oracle Database 11gリリース2より前のリリースのOracle Databaseでは、冗長インターコネクト使用機能は利用できないため、オペレーティング・システム・ベースのインタフェース関連テクノロジを使用する必要があります。 |
|
関連項目:
|
障害分離は、障害が発生したノードをクラスタの残りのノードから分離させ、障害が発生したノードでデータが失われるのを防ぐプロセスです。理想的なフェンシングには、Oracle Clusterwareまたはそのノードで実行されているオペレーティング・システムとの連携がなくても、ノードをクラスタから取り除くことができる外部メカニズムが含まれます。この機能を提供するために、Oracle Clusterware 11gリリース2(11.2)以降では、業界標準の管理プロトコルであるIntelligent Management Platform Interface仕様(IPMI)をサポートしています。
通常、障害分離はIPMIを使用してGrid Infrastructureのインストール中に構成します。この際、「障害の分離のサポート」画面でIPMIの構成オプションが示されます。インストール中にIPMIを構成しない場合は、インストール後にOracle Clusterware Controlユーティリティ(CRSCTL)を使用して構成できます。
|
関連項目: IPMIの詳細と、障害分離のためのIPMIの構成の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
イーサネットは、クラスタ・インターコネクトに広く使用されているネットワーク・テクノロジです。イーサネットの可変フレーム・サイズ46-1500バイトは、イーサネットに関係するもの(ホストやスイッチなど)すべての間での転送単位です。上限(この場合1500)は、MTU (最大転送単位)と呼ばれます。アプリケーションが1500バイト(MTU)を超えるメッセージを送信すると、一方のエンドポイントから他方まで1500バイト以下のフレームに断片化されます。Oracle RACでは、DB_BLOCK_SIZEの設定にMULTI_BLOCK_READ_COUNTを乗じた値によってグローバル・キャッシュに対するメッセージの最大サイズが決まり、PARALLEL_EXECUTION_MESSAGE_SIZEよってパラレル問合せで使用されるメッセージの最大サイズが決まります。これらのメッセージ・サイズは2Kから64Kまたはそれより大きくなることがあるため、さらに小さいMTUかデフォルトMTUに断片化されます。
超特大フレームでは、イーサネットのフレームがIEEE 802で指定された最大転送単位の1500バイトを超えて最大9000バイトになる機能が導入されています。
注意: 超特大フレームは、プライベート・クラスタ・インターコネクト用に実装できますが、慎重に構成してそのメリットをよく理解するためにテストする必要があります。また、Oracle Engineered Systemsで最適設定がすでに事前構成されていることもあります。
大規模ワークロードが要件としてある場合、インターコネクトでInfiniBandを使用することを検討してください。InfiniBandは、待機時間を短縮することでパフォーマンスを向上させることもできます。InfiniBandを導入すると、RDSプロトコルを使用して待機時間をさらに削減できます。
Oracle Clusterwareの運用ベスト・プラクティスには次のようなものがあります。
適切なキャパシティ・プランニングは、Oracleのクラスタリング・テクノロジのあらゆる側面にとって重要な成功要因ですが、計画メンテナンスにとっては特に重要です。あるクラスタの一部分のみ(ノードなど)が使用できなくなったときでも、そのクラスタの担当する作業が確実に実行されるようにする必要があります。計画済または計画外の停止の発生後にクラスタを実行できなくなると、システム・リソースの不足から連鎖的に問題が発生する可能性が高まります。
クラスタのサイズを決定する場合、一般的な計画済または計画外の停止の発生後に残されるコンピューティング・リソースの量をnパーセントとして、そのクラスタのnパーセントでサービス・レベルを満たすことができるようにする必要があります。たとえば、4ノード構成のクラスタがあり、一度に1つのノードをアップグレードするローリング・アップグレードの方法でパッチを適用する場合、残りの3つのノードでアプリケーションからリクエストされる作業を実行できます。
計画メンテナンス時に重要なキャパシティ・プランニングのもう1つの留意点は、計画メンテナンスの一部として実行される作業を、可能であればアプリケーション作業から分離することです。たとえば、すべてのノードへのパッチ適用後にSQLスクリプトを実行する必要がある場合のベスト・プラクティスは、パッチが適用される最後のノードで、そのノードを使用してアプリケーションを起動する前にそのスクリプトを実行することです。この方法を使用すると、SQLスクリプトは、ノード上のオペレーティング・システム・リソースをすべて使用できるため、アプリケーションに影響を与える可能性が低下します。たとえば、CATCPU.SQLスクリプトは、CPUパッチをすべてのノードにインストールした後に実行する必要があります。
Oracleクラスタウェアでは、クラスタ内の1つのノード上で、4時間ごとに自動的にOracle Cluster Registry (OCR)のバックアップが作成されます。これがOCRマスター・ノードです。Oracleでは、OCRの最新の3つのバックアップ・コピーが常に保存されます。また、バックアップを作成するCRSDプロセスによって、毎日および各週の終わりにもOCRのバックアップが作成され、保存されます。Oracle Secure Backup、標準のオペレーティング・システム・ツールまたはサード・パーティ・ツールを使用して、Oracle Clusterwareで作成されたバックアップ・ファイルをオペレーティング・システム・バックアップの一環としてバックアップします。
自動作成されたOCRバックアップ・ファイルを使用する他、ocrconfigコマンドで-manualbackupオプションを使用して、リクエストごとに手動バックアップを実行することができます。たとえば、OCRに対して変更(現在の環境でのノードの追加または削除、Oracleクラスタウェア・リソースの変更、データベースの作成など)を行う前後に、手動バックアップを実行できます。ocrconfig -manualbackupコマンドを使用すると、OCRの内容がファイル形式でエクスポートされます。ocrconfigで作成したエクスポート・ファイルは、Oracle Secure Backup、標準のオペレーティング・システム・ツールまたはサード・パーティ・ツールを使用して、オペレーティング・システム・バックアップの一環としてバックアップできます。
|
関連項目: OCRのバックアップ方法の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
クラスタ状態モニター(CHM)は、Oracle ClusterwareおよびOracle RACが稼働しているクラスタ内で発生する様々な問題(ノードの排除など)の説明強化のために、オペレーティング・システム(OS)およびクラスタのリソースに関連する低下および障害を検出して分析するように設計されています。このツールは、OSリソースの消費状況を、各ノード、プロセスおよびデバイス・レベルで継続的に追跡します。また、このクラスタ全体のデータを収集し分析します。リアルタイム・モードでは、しきい値に達するとオペレータに対してアラートが表示されます。根本原因分析のため、履歴データを再生し、障害発生時に何が起きていたのかを理解できます。
