...

Oracle Real Application Clusters 11g Release 2(Oracle Databaseの

by user

on
Category: Documents
12

views

Report

Comments

Transcript

Oracle Real Application Clusters 11g Release 2(Oracle Databaseの
Oracleホワイト・ペーパー
2009 年 9 月
Oracle Real Application Clusters 11g Release 2
(Oracle Databaseのオプション)
Oracle ホワイト・ペーパー - Oracle Real Application Clusters 11g Release 2
はじめに.............................................................................................................................. 1
Oracle Real Application Clusters について......................................................................... 2
Oracle Real Application Clusters アーキテクチャ......................................................... 2
Oracle Real Application Clusters の利点 ............................................................................ 6
高可用性 ........................................................................................................................ 6
スケーラビリティ .......................................................................................................... 7
Oracle Real Application Clusters データベースの管理....................................................... 8
Oracle Enterprise Manager ........................................................................................... 8
ローリング方式でのパッチの適用................................................................................. 9
ローリング方式でのアップグレードのサポート........................................................... 9
Oracle Real Application Clusters のワークロード管理..................................................... 10
サーバー・プール ........................................................................................................ 10
サービス .......................................................................................................................11
接続時ロード・バランシング.......................................................................................11
高速アプリケーション通知(FAN) ........................................................................... 12
ロード・バランシング・アドバイザ ........................................................................... 12
結論................................................................................................................................... 13
Oracle ホワイト・ペーパー - Oracle Real Application Clusters 11g Release 2
はじめに
Oracle Real Application Clusters(Oracle RAC)は、Oracle Databaseですべてのパッケージ・アプリケー
ションやカスタム・アプリケーションを変更することなく、クラスタ化されたサーバー全体で実行
できるようにします。これにより、最高レベルの可用性ともっとも柔軟なスケーラビリティが得ら
れます。クラスタ化されたサーバーに障害が発生すると、Oracleは残りのサーバーで稼働し続けます。
より高い処理能力が必要な場合は、ユーザーをオフラインにすることなく、新しいサーバーを追加
できます。コストを低く抑えるため、一般的で標準なパーツを用いて、最高クラスのハイエンド・
システムを構築することも可能です。
Oracle Real Application Clustersは、Oracleのエンタープライズ・グリッド・コンピューティング・アー
キテクチャの基盤を提供します。Oracle RACテクノロジーでは、低コスト・ハードウェアによるプ
ラットフォームを使用して、可用性およびスケーラビリティという点で、もっとも高価なメインフ
レームSMPコンピュータと同等もしくはそれ以上の高品質のサービスを提供できます。管理コスト
を大幅に削減し、管理の柔軟性に対して新しいレベルを提供することで、エンタープライズ・グリッ
ド環境を実現します。Oracle RAC 11g Release 2 を使用すると、企業向けの動的なグリッド・インフ
ラストラクチャを構築できます。
本書では、業務アプリケーションに向けた最高の可用性とスケーラビリティを実現するための機能
を中心に、Oracle Real Application Clusters 11gの技術概要を紹介します。
1
「我が社では、メインフレームからOracle Real Application Clustersにプラットフォームを変更することで、年
間 500 万ドルの費用を節約できました」
- PG&E、Senior Director of Platform Services、Eugene Park
Oracle Real Application Clustersについて
Oracle Real Application Clustersは、Oracle9iで初めて導入されたOracle Databaseのオプションです。さまざまな業界のあら
ゆる種類のアプリケーションにおいて、数千の顧客に使用されている実績のあるテクノロジーになります。Oracle RAC
は、単一サーバーという枠を超えてアプリケーションを拡張できるオプションを提供します。これにより、低コストの一
般的なハードウェアを活用して総所有コストを削減しながら、アプリケーション・ワークロードをサポートする拡張性の
高いコンピューティング環境を実現できます。また、一般的なパッケージ製品(Oracle Applications、Peoplesoft、SAPな
ど)、自社開発アプリケーション(OLTPやDSS)、または混合ワークロードなど、クラスタ上のあらゆる種類の基幹業
務アプリケーションをOracle Databaseで実行できるようにします。
Oracle Real Application Clustersは、Oracle高可用性アーキテクチャの重要なコンポーネント 1 であり、アプリケーションの
最高の可用性を構築する方向性を確立します。Oracle RACを使用することで、どのようなデータベース・アプリケーショ
ン環境においても、サーバーがシングル・ポイント障害となることはありません。
Oracle Real Application Clusters アーキテクチャ
Oracle RACデータベースは、クラスタ化されたデータベースです。クラスタは独立したサーバーのグループであり、1 つ
のシステムとして協調して作動します。また、単一の対称型マルチプロセッサ(SMP)システム上で、耐障害性を高め、
段階的なモジュラー方式のシステム拡張を実現します。システム障害が発生した場合でも、クラスタ化により高可用性が
保証されます。ミッション・クリティカルなデータへのアクセスは失われません。追加ノード、インターコネクト、ディ
スクなど、冗長性のあるハードウェア・コンポーネントにより、クラスタで高度な可用性を実現できます。このような冗
長ハードウェア・アーキテクチャによって、シングル・ポイント障害が回避され、極めて高い耐障害性が実現します。
1
Oracle高可用性アーキテクチャの詳細は、以下のURLを参照してください。
http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
図 1 Oracle Real Application Clustersアーキテクチャ
Oracle Real Application Clustersでは、Oracleデータベース(一般にデータ・ファイルと呼ばれ、実際のデータを格納するス
トレージ上に存在する物理構造)からOracleインスタンス(データへのアクセスを可能にする、サーバーで稼働するプロ
セスおよびメモリ構造)を切り離します。クラスタ化されたデータベースは単一のデータベースで、複数のインスタンス
によってアクセスできます。それぞれのインスタンスは、クラスタ内の独立したサーバーで実行されます。追加のリソー
スが必要な場合、システムを停止することなく、ノードとインスタンスを簡単にクラスタへ追加できます。新しいインス
タンスが開始すると、サービスを使用するアプリケーションは、アプリケーションまたはアプリケーション・サーバーに
変更を加えることなく、すぐにそれを活用できます。
Oracle Real Application Clustersは、Oracle Databaseの拡張機能です。そのため、Oracle Database 11gに組み込まれた管理性、
信頼性、およびセキュリティ機能を活用できます。
Oracle Clusterware
Oracle Database 10g以降、オラクルでは、Oracle Databaseに特化して設計され統合された移植性の高いクラスタウェア・ソ
リューションとして、Oracle Clusterwareを提供しています。Oracle Clusterwareは、完全なクラスタリング・ソリューショ
ンを実現し、あらゆるアプリケーションに対応しています。Oracle Clusterwareは、Oracle RACを実装する際の前提条件と
なります。クラスタウェアおよびクラスタ・データベースを 1 社でサポートしていることで、サポートも容易になりまし
た。Oracleは認定されたサード・パーティ製クラスタウェアで機能するため、特定のサード・パーティのクラスタウェア
でOracle RACを実行することも可能です。ただし、Oracle RACデータベースは、すべてOracle Clusterwareで管理する必要
があります。
Oracle Clusterwareは、Oracle Real Application Clustersデータベースの監視および管理を行います。クラスタ上のノードが開
始されると、すべてのインスタンス、リスナー、サービスが自動的に開始します。インスタンスに障害が発生した場合に
は、そのインスタンスがクラスタウェアによって自動的に再起動するため、管理者がインスタンスの停止に気付く前に、
サービスがリストアされることがよくあります。
Oracle Database 10g Release 2 では、Oracle以外のプロセスをOracle Clusterware内の高可用性フレームワークで管理できる
ように、高可用性APIが追加されました。Oracle Clusterwareにプロセスを登録すると、プロセスの開始、停止、および監
視のための情報が提供されます。また、ノードが停止した場合、プロセスをクラスタ上の別のノードに再配置するかどう
かを指定できます。Oracle Database 11g Release 2 では、Oracle Enterprise Managerのグラフィカル・インタフェースにより、
アプリケーションの管理を容易に行えるようになりました。また、Oracle Clusterwareの高可用性フレームワークによって、
管理性および依存性オプションが強化されています。
ハードウェア・アーキテクチャ
Oracle Real Application Clustersは、シェアード・エブリシング型アーキテクチャです。クラスタ上のすべてのサーバーは、
Oracle RACデータベースで使用されるすべてのストレージを共有する必要があります。使用できるディスク・ストレージ
には、ネットワーク接続ストレージ(NAS)、ストレージ・エリア・ネットワーク(SAN)、またはSCSIディスクがあ
ります。選択できるストレージは、サーバー・ハードウェアの種類と、ハードウェア・ベンダーがサポートする種類に依
存します。ストレージの選択で重要なポイントは、アプリケーションに拡張性の高いI/Oを提供するストレージ・システ
ムであること、つまりサーバーをクラスタに追加して拡張できるI/Oシステムを選択することです。
クラスタ構成ではアプリケーションを接続するために処理するデータベース・サーバーの、ローカル・エリア・ネットワー
ク(LAN)にネットワークを追加する必要があります。クラスタには、一般的にインターコネクトとして知られる第 2 のプ
ライベート・ネットワークが必要です。高可用性を実現するために、このネットワークに対して 2 つのネットワーク・イ
ンタフェースを使用することをお勧めします。フェイルオーバーおよびロード・バランシングの実現には、Oracleに対し
て外部結合されたネットワーク・インタフェースを使用する必要があります。インターコネクトは、ノード間メッセージ
ングのためにクラスタが使用します。また、Oracle RACでもキャッシュ・フュージョン・テクノロジーの実装にインター
コネクトを使用します。クラスタ・インターコネクトをギガビット・イーサネット上のUDPで使用することをお勧めしま
す。本番環境のRACデータベースでは、インターコネクトとしてクロスオーバー・ケーブルを使用することはできませ
ん。
クラスタは 1 つまたは複数のサーバーで構成されます。各サーバーは、LAN接続用インタフェースとインターコネクト
接続用インタフェースを備え、共有ストレージに接続されている必要があります。Oracle ClusterwareおよびOracle Real
Application Clustersは、クラスタ内で最大 100 ノードをサポートします。クラスタ内の各サーバーは、まったく同じであ
る必要はありませんが、同一のオペレーティング・システムと、同じバージョンのOracleを実行している必要があります。
すべてのサーバーは、32 ビットまたは 64 ビットが混在しない、同一のアーキテクチャをサポートする必要があります。
Oracle Real Application Clustersに関する認定情報や技術的制限については、Oracle Metalink(http://metalink.oracle.com)を
参照してください。
ファイル・システムおよびボリューム管理
Oracle RACはシェアード・エブリシング型アーキテクチャであるため、使用するボリューム管理およびファイル・システ
ムはクラスタに対応している必要があります。Oracle Database 11gの機能で、データベースに対するストレージ管理を自
動化するOracle Automatic Storage Management(Oracle ASM)の使用をお勧めします。Oracle ASMは、ファイル・システ
ムの容易な管理を実現しながら、非同期I/Oのパフォーマンスを提供します。また、利用可能なすべてのリソース間でI/O
の負荷を分散し、手動でのI/Oチューニングを行わずにパフォーマンスを最適化できます。Oracle Database 11g Release 2
のOracle ASMでは、動的なボリューム管理機能と汎用ファイル・システムが追加されています。
さらに、OracleではRAWデバイスや、WindowsおよびLinuxで使用できるOracle Cluster File System(Oracle CFS)など、い
くつかのクラスタ・ファイル・システムの使用をサポートします。Oracle Database 11g Release 2 のOracle Universal Installer
およびDatabase Configuration Assistantでは、データベース・ファイルにrawデバイスまたはブロック・デバイスを使用でき
ません。現在rawデバイスを使用しているデータベースは、11g Release 2 にアップグレードすることでそのままrawデバイ
スを使用し続けることができます。SQLなどのコマンドライン・インタフェースでも、rawデバイスを従来どおりそのま
ま使用できます。
Oracle Grid InfrastructureOracle RAC 11g Release 2 では、クラスタにグリッド・インフラストラクチャが導入されています。
グリッド・インフラストラクチャは、Oracle Database外の必須ソフトウェアであり、ボリューム管理、ファイル・システ
ム、クラスタ管理などの必要なインフラストラクチャを提供します。これは、Oracle Clusterwareと自動ストレージ管理の
両方を含む単一のバイナリ・セットとして提供されます。グリッド・インフラストラクチャは通常、システム管理者によっ
て管理されますが、システム管理チームに簡単に移行できます。
仮想 IP(VIP)アドレス
Oracle Real Application Clusters 11gは、クラスタの各サーバーで仮想IPアドレスを必要とします。仮想IPアドレスは、ロー
カル・エリア・ネットワーク(LAN)と同じサブネット上にある未使用のIPアドレスのことです。このアドレスを使用し
て、アプリケーションはOracle RACデータベースに接続されます。ノードが停止した場合、仮想IPはクラスタの他のノー
ドにフェイルオーバーし、接続リクエストに対するノード停止の応答を即時配信します。これにより、ネットワークのタ
イムアウトを待ってから接続リクエストがクラスタ内の他のインスタンスへフェイルオーバーすることがなくなるため、
アプリケーションの可用性は向上します。
グリッド・ネーミング・サービス
Oracle RAC 11g Release 2 では、クラスタにグリッド・ネーミング・サービスが導入されています。スケーラビリティを
高めるため、クラスタ内の仮想IP要件の管理が自動化されました。最初に、ネットワーク管理者と協力して、ドメイン・
ネーム・サービス(DNS)内に委任ドメインを設定し、グリッド・ネーミング・サービス(GNS)用の仮想IPアドレスを
設定する必要があります。クラスタのIPアドレスの管理を処理するグリッド・ネーミング・サービスは、クラスタ構成時
に構成されます。クラスタに対してサーバーの追加または削除を行う際に、ネットワーク管理者に問い合わせてIPアドレ
スを追加してもらう必要はありません。これにより、クラスタを構成する際に必要となるネットワーク管理者の作業量が
軽減され、ワークロードの増大に伴ってクラスタを拡張する際も余分な作業が発生することはありません。
クラスタ内のネットワーク管理の自動化をさらに進めるには、グリッド・ネーミング・サービス(GNS)を使用するため
にパブリック・ネットワーク上でDHCPサーバーを稼働する必要があります。クラスタにサーバーが追加されると、DHCP
を使用して、必要な仮想IPアドレスが動的に割り当てられます。
単一クライアント・アクセス名(SCAN)
Oracle RAC 11g Release 2 では、単一クライアント・アクセス名(SCAN)を導入することで、クライアントからOracle RAC
データベースへのアクセスを簡素化しています。SCANを使用すると、クラスタを拡張したり、時間の経過とともにクラ
スタを構成するノードが変化したりしても、常に同じ名前でクライアント接続リクエストを発行できます。これにより、
EZConnect
(
sqlplus
system/manager@sales1scan:1521/oltp
)
や
JDBC
thin
url
(jdbc:oracle:thin:@sales1scan:
1521/oltp)といった簡素化された接続メカニズムを利用できます。GNSを使用する場合は、SCANの名前とリスナー・
ポートを指定するだけで済みます。GNSを使用しない場合は、SCANをDNS内に 1 つの名前として定義する必要がありま
す。その名前に、3 つのIPアドレスがラウンドロビン方式で割り当てられます。3 つのIPアドレスは、クラスタのパブリッ
ク・ネットワークと同一サブネット上に存在していなければなりません。
Oracle Cluster Verification Utility
Oracle RACには、クラスタ構成検証ツールが含まれています。クラスタ検証ツールは、インストール手順や設定変更時の
事前および事後の妥当性チェックを行うことで、エラーを削減します。また、継続的なクラスタの検証にも使用できます。
このツールは、コマンドライン・インタフェースまたはOracle Universal Installerなど、他のプログラムのAPIを通じて起動
できます。Oracle RAC 11g Release 2 では、Cluster Verification Utility(CVU)がOracle Universal Installerに組み込まれてお
り、インストール時のやり取りで入力された構成情報、およびOracle Clusterware、ASM、Oracle Databaseに関するシステ
ム前提条件が検証されます。サーバーが必要な前提条件を満たさない場合は、CVUによって修正スクリプトが作成され
ます。修正可能な項目には、Oracle Universal Installerによるインストール時のやり取りで表示される「前提条件のチェッ
ク」ページの「修正可能」列に"Yes"というマークが付きます。修正スクリプトを生成するには、「修正および再チェッ
ク」ボタンをクリックします。root(またはAdministrator)は、要求され次第、すべてのサーバー上でこのスクリプトを
実行する必要があります。これにより、システムの前提条件に不足があれば容易に検出できます。
「高可用性はわれわれにとって必要不可欠な要素です。そこで、Oracle RACを使用して、インスタンス・フェイルオーバーやData Guardによるサイトのフェ
イルオーバー、およびASMを使用したストレージ管理を実現し、これらすべてをOracle clusterwareで統合しています。」
- Commonwealth Bank of Australia、Executive Architect、Jon Waldron
長距離クラスタ上の Oracle RAC
長距離クラスタ上のOracle RACは、クラスタ内のサーバーが物理的に分離された場所にあるアーキテクチャです。長距離
クラスタ上のOracle RACでは、サイト障害からの迅速なリカバリが可能となり、すべてのサイトのすべてのノードで、ト
ランザクションを単一データベース・クラスタの一部としてアクティブに処理できます。このアーキテクチャは大きな関
心を呼び、多数の実績をもっていますが、とくに距離、待機時間、保護レベルを考慮した場合の有効性を理解することは
重要です。
待機時間、すなわち距離による影響が大きいため、現実には、このアーキテクチャを配置できる場所に何らかの制限が生
じることがあります。このアーキテクチャは、2 つのデータセンターが比較的近く(100km以内)にあり、すでに高額な
費用を支払ってサイト間の専用チャネルが敷設されている環境に適しています。
長距離クラスタ上のOracle RACは、ローカルRACよりも高い可用性を実現しますが、企業の完全な障害時リカバリ要件を
満たさない可能性があります。障害の種類(局地的停電、飛行機の墜落、サーバー室の浸水など)によっては、適切な分
離は最大の保護策となりますが、最善でない場合もあります。地震、台風、大洪水などの災害は、広範囲に影響を与えま
す。顧客は、両方の場所が同じ災害の影響を受ける可能性があるかどうかを分析して決定する必要があります。故障や地
域災害に対する保護も含め、オラクルでは災害における包括的な保護として、『Oracle High Availability Architecture』の説明
にあるように、Oracle RACとともにOracle Data Guardを使用することを推奨します。Oracle Data Guardを使用することに
より、Oracleの各バージョンに対するローリング・アップグレードもサポートされるという利点も得られます。
長距離クラスタは、ローカル・クラスタよりも構成が複雑です。長距離クラスタを構成する際には、ノードのレイアウト、
投票ディスク、データ・ディスクの配置に、特に注意が必要です。正しく実装すると、このアーキテクチャはローカルの
Oracle RACデータベースよりも高い可用性を実現できます。Oracle Clusterware、Oracle Real Application Clustersおよび
Oracle Automatic Storage Managementを組み合わせることで、長距離クラスタを拡張できます。
Oracle Real Application Clustersの利点
高可用性
Oracle Real Application Clusters 11gは、データセンターの高可用性を実現するインフラストラクチャを提供します。また、
Oracle高可用性アーキテクチャの必須コンポーネントでもあり、最高の可用性を備えたデータ管理ソリューションを実現
するためのベスト・プラクティスを提供します。Oracle Real Application Clustersは、高可用性ソリューションの主要特性
に対して保護を提供します。
信頼性 - Oracle Databaseは、信頼性において定評があります。Oracle Real Application Clustersは、シングル・ポイント障害
となるデータベース・サーバーを排除することで信頼性をさらに高めます。インスタンスが停止すると、クラスタのその
他のインスタンスがオープンされ、アクティブになります。Oracle Clusterwareは、すべてのOracleプロセスを監視して、
いずれかのコンポーネントで障害が発生すると即座に再起動します。
リカバリ機能 - Oracle Databaseには、すべての種類の障害から簡単にリカバリするための機能が多数用意されています。
Oracle RACデータベースで、あるインスタンスが停止すると、クラスタの別のインスタンスがそれを認識し、自動的にリ
カバリを実行します。高速アプリケーション通知、高速接続フェイルオーバー、および透過的アプリケーション・フェイ
ルオーバーにより、アプリケーションはユーザーが障害を認識しないよう簡単に設定できます。
「我が社では、メインフレーム・システムからクラスタ・サーバー環境への移行を無事に完了できました。Oracle環境は非常に安定しており、高いパフォー
マンスを備え、拡張が容易なため、ユーザーの満足度や顧客サービスが向上しました。」
- SK Telecom、CIO & Senior VP、NoCheol Park
エラー検出 - Oracle Clusterwareは、Oracle RACデータベースおよびその他のOracleプロセス(ASM、リスナーなど)を自
動監視し、環境内の問題を即座に検出します。また、多くの場合、発生した障害にユーザーが気づく前に障害を自動的に
リカバリします。高速アプリケーション通知は、アプリケーションがクラスタ・コンポーネント障害に関する通知をすぐ
に受け取るための機能です。クラスタ内で障害が発生していないノードに対し、トランザクションを再送信することで、
ユーザーに障害を認識させません。
継続的運用 - Oracle Real Application Clustersでは、計画停止および計画外停止のどちらが発生しても、サービスの継続が
可能です。ノード(またはインスタンス)が停止した場合でも、データベースはオープンの状態にあり、アプリケーショ
ンはデータにアクセスできます。ほとんどのデータベース・メンテナンス作業は、システムを停止させることなく実施で
き、ユーザーがそれを認識することもありません。その他のメンテナンス作業は、ローリング方式で行うことができます。
そのため、アプリケーションの停止時間は最低限またはゼロに抑えることができます。高速アプリケーション通知および
高速接続フェイルオーバーは、アプリケーションがサービス・レベルを満たし、クラスタのコンポーネント障害を認識さ
せないよう支援します。
スケーラビリティ
Oracle Real Application Clustersは、アプリケーションの拡張に独自の技術を採用しています。これまでは、データベース・
サーバーの容量が不足すると、容量の大きい新規サーバーと置き換えていました。サーバーの容量が大きいほどに、価格
は上がります。Oracle RACを使用するデータベースの場合、容量は増加させない別の方法があります。大規模なSMPサー
バー上で稼働する従来のアプリケーションは、小規模なサーバーのクラスタに移行して稼働できます。また、既存ハード
ウェアの投資を維持しながら新規サーバーをクラスタに追加(またはクラスタを作成)することで、容量を増加できます。
Oracle ClusterwareおよびOracle RACを使用するクラスタへサーバーを追加する際は、システムを停止させる必要はなく、
新規インスタンスが開始すると同時にアプリケーションは追加された容量を利用できます。クラスタ内の各サーバーは、
同一のオペレーティング・システムと同じバージョンのOracleを実行している必要はありますが、容量が同じである必要
はありません。現在、各サーバーが 2CPUのコモディティサーバーであるサーバーのクラスタから、各サーバーに 32 ま
たは 64 のCPUを搭載するクラスタまで、顧客のニーズに合ったクラスタを構成できます。
Oracle Real Application Clustersアーキテクチャは、急速に変化するビジネス要件と、その結果としてのワークロードの変
化に自動的に対応します。アプリケーション・ユーザー、または中間層アプリケーション・サーバー・クライアントは、
サービス名でデータベースに接続します。Oracleは、クラスタ内の複数のノード間でユーザーの負荷を自動的に分散しま
す。異なるノードにあるOracle Real Application Clustersのデータベース・インスタンスは、データベース・サービスのす
べてまたは一部のサブセットをサブスクライブします。これにより、特定のデータベース・サービスに接続する特定のア
プリケーション・クライアントがデータベース・ノードの一部またはすべてに接続できるかどうかを、DBAは柔軟に選
択できます。管理者は、アプリケーション要件の拡大に合わせて、簡単に処理能力を追加できます。Oracle RACのキャッ
シュ・フュージョン・アーキテクチャでは、新しいノードのCPUおよびメモリ・リソースをすぐに活用できます。DBA
が手動でデータの再パーティションを行う必要はありません。
Oracleデータベースのワークロードを分散するもう 1 つの方法は、Oracle Databaseのパラレル実行機能を利用することで
す。パラレル実行(パラレル問合せまたはパラレルDMLなど)は、SQL文の実行に伴う負荷を複数のプロセスに分割し
ます。Oracle Real Application Clusters環境では、これらのプロセスを複数のインスタンス間で分散できます。Oracleのコス
トベース・オプティマイザは、最適な実行計画を実現するための基本コンポーネントとして、パラレル実行の使用も検討
します。Oracle Real Application Clusters環境では、ノード内およびノード間の並列性に対してインテリジェントな決定が
行われます。たとえば、ある問合せが作業完了までに 6 つの問合せプロセスを必要とし、ローカル・ノード(ユーザーが
接続しているノード)で 6 つのCPUがアイドル状態にある場合、問合せはローカル・リソースのみを使用して処理されま
す。これは、ノード内並列処理の効率性を示すもので、複数のノード間における問合せ調整のオーバーヘッドが排除され
ます。ただし、ローカル・ノードで利用できるCPUが 2 つのみの場合は、その 2 つのCPUと別のノードの 4 つのCPUを使
用して問合せが処理されます。この方法により、ノード内およびノード間の両方の並列性を利用でき、問合せ処理を高速
化できます。
Oracle Real Application Clustersデータベースの管理
Oracle Real Application Clustersは、単一のシステム・イメージを採用することで簡単な構成および管理を実現しています。
Oracle RACデータベースは、一箇所でのインストール、構成、および管理が可能です。データベースを管理するために提
供されるすべてのツールおよびユーティリティは、Oracle Universal InstallerからOracle Enterprise Managerに至るまで、す
べてクラスタ対応となります。たとえば、Database Configuration Assistant(DBCA)、Database Upgrade Assistant(DBUA)、
Network Configuration Assistant(NETCA)、srvctlなどのコマンドライン・インタフェースが含まれます。
Oracle Enterprise Manager
Oracle Enterprise Manager 10g Grid Control(Oracle Grid Control)は、Oracle環境で推奨される管理インタフェースです。Oracle
Grid Controlは、完全なOracle ITインフラストラクチャ(OracleおよびOracle以外のテクノロジーを実行するシステムを含
む)のための集中管理機能を実現します。Oracle Grid Controlでは、広範な管理機能、構成管理、プロビジョニング、エ
ンド・ツー・エンドのモニタリング、セキュリティ機能によって、グリッド・コンピューティング環境管理のコストと複
雑さを軽減し、顧客がITインフラストラクチャのサービス・レベルを維持できるようにします。Oracle Enterprise Manager
Database Controlは、Oracle Databaseを管理するためのGUI管理ツールです。Oracle Database Controlは、データベースを作
成するとDBCAによって自動的に構成されます。どちらの製品もクラスタ対応であり、Oracle RACを使用したクラスタ化
データベースの管理と、Oracle Clusterwareによって作成されたクラスタの管理に使用できます。
Oracle Enterprise Manager Grid Control 10g Release 5 を使用すると、データベースのASMへの移行、およびシングル・イン
スタンス・データベースからRACへの変換を、最小限の停止時間で実行できます。また、新しいHA(高可用性)コンソー
ルにさまざまなHA領域(クラスタリング、バックアップとリカバリ、レプリケーション、障害時リカバリなど)の監視
機能が統合されているため、全体のHA構成ステータスを確認でき、適切な措置を講じることができます。
Oracle Enterprise Manager 10g Grid Controlは、クラスタ・ハードウェアおよびオペレーティング・システム全体をまとめて
閲覧できるクラスタ・ページを提供します。これは、クラスタが複数のデータベースをサポートしているときに便利なペー
ジです。クラスタ・プラットフォーム全体のステータスを簡単に把握できるだけでなく、必要に応じて個別のデータベー
スに簡単にドリルダウンできます。クラスタ・ページでは、次の作業を実行できます。
♦
クラスタ・データベースのノード数や各ノードの現在のステータスなど、システム全体の状況を把握できます。
♦
すべてのインスタンスから集計されたアラートを閲覧できます。また、各アラートのソースや、その他の詳細ま
でドリルダウンすることもできます。
♦
クラスタ・データベース全体に対するアラート生成のしきい値を設定できます。
♦
すべてのインスタンスから集計したパフォーマンス・メトリックを監視できます。また、各インスタンスを素早
く比較できるように、パフォーマンス・メトリックを並べて表示することや、必要に応じてドリルダウンするこ
ともできます。
♦
クラスタのキャッシュ一貫性に関する統計を監視します(global buffer getsなど)。
♦
バックアップおよびリカバリ操作の開始や、インスタンスの起動または停止操作など、クラスタ・データベース
全体を対象とした操作を実行できます。
♦
サービスの作成、変更、開始または停止、有効化または無効化、再配置、サービス・パフォーマンスの監視など
の操作を行うことで、サービスを管理できます。
Oracle Enterprise Manager 10g Release 2 から、Oracle Real Application Clustersデータベースのプロビジョニングを簡単に実
行できる機能が、Grid Controlに追加されました。Oracleホームの設定やクラスタウェアの構成などを含むクラスタの初期
作成は、Oracle Enterprise Managerで簡単に行うことができます。Oracle Homeソフトウェアは、既知の"ゴールド・イメー
ジ"としてEnterprise Manager内に保持することも、既知の参照ホストから提供することもできます。"ゴールド・イメージ
"は、Oracle ClusterwareまたはOracle Real Application Clusters環境の既知の優れた実装のコピーで作成します。Oracle Grid
Control 10g Release 3 では、クローニング・アプリケーションが新しいOracle RACとOracle Clusterwareソフトウェアをエン
ド・ツー・エンドで作成するためにフル・サポートします。それには、スーパーユーザー・アクション(root.sh)および
カスタマイズ可能な事前手順および事後手順の実行が含まれます。これは、既存クラスタに新しいノードを追加する際に
も使用できます。
Linuxオペレーティング・システムの場合、ベア・メタル・ノードに"イメージ"をプロビジョニングすることもできます。
イメージは、オペレーティング・システム、Oracle Enterprise Managerエージェント、Oracle Clusterware、およびOracle Real
Application Clustersを使用するOracle Databaseで構成できます。このイメージは、ハードウェア・プロファイルと関連付け
ることができます。このイメージのすべてのコンポーネントは、Enterprise Managerの"ゴールド・イメージ"として格納さ
れます。ウィザードを使用すると、ハードウェアの選択や、スタック全体の新しいハードウェアへのプロビジョニングが
可能です。新しいノードは、自動的にクラスタへ追加されます。
Oracle Enterprise Manager Database Controlには、クラスタ管理用の新しいタブが導入されています。クラスタ・タブを使用
すると、Oracle Clusterwareによって作成されたクラスタを監視および管理することができます。Clusterタブでは、Oracle
とユーザーが作成したクラスタ・リソースを作成および管理できます。ユーザーは依存性を備えたクラスタ・リソースを
作成でき、クラスタはクラスタ内のサーバーで実行されているすべてのプロセスを監視および管理できます。Oracle
Clusterwareには高度な依存性オプションが用意されており、あらゆる基幹系ビジネス・アプリケーションを容易にモデル
化できます。Oracle Enterprise Manager Database Controlは、Oracle RAC 11g Release 2 ホームを必要としますが、データベー
スがダウン状態のときでも、Oracle Clusterwareとそのリソースを管理できます。
ローリング方式でのパッチの適用Oracleは、Oracle RACデータベースのノードへのパッチ適用を、停止時間のないローリ
ング方式によってサポートします。パッチは 1 ノードごとに適用され、その間Oracle RACシステムの他のノードは稼働を
続けます。そのために、各ノードは独立したOracle Homeを持つ必要があります。パッチは、その変更内容によって、ロー
リング・アップグレードでインストール可能かどうかを分類します。インスタンス間で共有される共通の構造やデータ
ベース内容を変更する一部のパッチは、ローリング・アップグレードできません。また、ローリング・アップグレードの
対象となるのは、個別パッチのみで、パッチ・セットは対象外です。この機能は、Oracle Database 9.2.0.2 からサポートさ
れています。Oracle Clusterwareのすべてのパッチは、ローリング方式で適用できます。Oracle Database 11gでは、Automatic
Storage Managementがローリング方式でアップグレード可能です。
Oracle Database 11g Release 2 では、クラスタ内でのパッチの適用処理が簡素化されています。パッチ・ユーティリティ
Opatchでは、数段階の簡単な手順でパッチ・セットおよびパッチ・バンドルを適用できます。
ローリング方式でのアップグレードのサポートOracle Clusterwareは、ローリング・アップグレードをサポートします。こ
れにより、クラスタのサービスを停止させることなくクラスタウェアをアップグレードでき、連続で稼働することが可能
となります。Oracle Automatic Storage Managementを 11gにアップグレードすると、ローリング・アップグレードを実行で
きるようになります。
Oracle RAC 11gは、Data Guard SQL Applyを使用することにより、データベースの停止時間をほとんど必要としないロー
リング方式でデータベース・ソフトウェアをアップグレードできます(Oracle Database 10g Release 1 パッチ・セット 1
以降)。この手順には、ロジカル・スタンバイ・データベースの次のリリースへのアップグレード、アップグレードのテ
ストと妥当性チェックのための混在モードによる実行、アップグレードしたデータベースへのスイッチ・オーバーによる
ロール反転、旧プライマリ・データベースのアップグレードなどが含まれます。テスト目的で、混在モードで実行すると
きは、データを損失することなくアップグレードを中止してソフトウェアをダウングレードできます。上記の手順中、さ
らにデータ保護を強化するには、第 2 のスタンバイ・データベースを使用する方法があります。Oracle Data Guardでは、
停止時間を最小限度に抑えたローリング・アップグレードによって、通常多くの管理タスクに伴う長いメンテナンス所要
時間を短縮し、24 時間 365 日の業務体制を可能にします。
Oracle Real Application Clustersのワークロード管理
Oracle RACデータベースを使用するアプリケーションは、クラスタ全体のワークロードを管理する必要があります。
Oracle Real Application Clustersには、現在の構成で最大のアプリケーション・スループットとアプリケーションの高可用
性を提供するようにワークロードを管理する革新的なテクノロジーが搭載されています。Oracle RAC 11g Release 2 では、
クラスタ内でのOracle RACの管理を簡素化することによって、複数のアプリケーションを 1 つのクラスタに統合するプロ
セスを単純化し、同時にリソースの割当てとロール分離型管理を行っています。Oracle RAC 11g Release 2 では、ポリシー
によって管理されたデータベースを用いてサーバー・プールを実装できます。
図 2 サーバー・プールを使用した低コスト・サーバーへの統合
サーバー・プール
Oracle RAC 11g Release 2 では、サーバー・プール内で実行されるようにデータベースを定義できます。サーバー・プー
ルとは、クラスタ内の論理エンティティです。管理者は、サーバー・プールから、個々のアプリケーションにリソースを
割り当てることができます。サーバー・プールは、3 つのパラメータによって定義されます。すなわち、min(プール内
の最小サーバー数)、max(プール内の最大サーバー数)、importance(クラスタ内のさまざまなアプリケーションに相
対的重要度を与える)の 3 つです。クラスタがサーバーをユーザー定義のプールに割り当てると、クラスタの再構成が実
行されます。Oracle Clusterwareは、重要度の高い順にサーバーを割り当てます。特定のデータベースに対して保持される
インスタンスの数は、サーバー・プールのカーディナリティによって決まります。新規のインスタンスを追加するには、
単純にサーバー・プールのmaxパラメータを増やします。クラスタ内に使用可能なサーバーが存在していれば、新規のイ
ンスタンスが開始されます。インスタンスの数を減らすには、サーバー・プールのmaxパラメータを小さくします。
Database Configuration Assistant(DBCA)では、カーディナリティと名前を定義することによって、ポリシーで管理され
たデータベースを作成するオプションが用意されています。サーバー・プールは、定義済みのカーディナリティに等しい
maxパラメータを使用して自動作成されます。Oracle Clusterwareは、クラスタ内に存在する使用可能なサーバーの数を上
限として、サーバー・プール内のサーバーを管理します。
サービス
ワークロード管理は、Oracle Databaseの機能であるサービスを使用して実行されます。サービスは、単一のシステム・イ
メージによってワークロードを管理することにより、Oracle RACデータベースの複雑さを隠ぺいします。サービスによっ
て、アプリケーションはクラスタの信頼性を享受できます。従来のデータベースでは単一のサービスを提供しており、名
前はSQL*NETに指定された接続データと同一のものでした。Oracle Database 11gにおいて、DBAは単一のデータベースに
よって提供される最大 100 のデータベース・サービスを定義できます。これにより、サービス・レベルやプロパティのよ
うなビジネス要件に基づいて、アプリケーションに伴うワークロードを管理可能なコンポーネントに分割できます。サー
ビスは、Oracle Databaseの多くの機能と統合されています。アプリケーション・ユーザーは、CPUなどのリソースを制限
するリソース・マネージャの顧客グループへ自動的に割り当てることも可能です。バッチ・ジョブは、そのサービスに基
づいて特定のジョブ・クラスに割り当てることができます。Oracle Streams Advanced Queuingを使用している場合、サー
ビスはキューに対する位置の透過性を得ることができます。Oracle RAC 11gでは、ノード間のパラレル問合せは、サービ
スがアクティブなインスタンスに制限されます。
サービスは、Oracleデータベースの 1 つ以上のインスタンスに及び、インスタンスは複数のサービスをサポートできます。
サービスを提供するインスタンスの数は、DBAによって動的に管理され、アプリケーションとは独立して存在します。
停止が発生した場合、サービスは停止していないインスタンスへ自動的にリストアされます。インスタンスがリストアさ
れると、稼働していないサービスはすべて自動的にリストアされます。
ポリシー型管理のデータベースでは、サービスは 1 つのサーバー・プール内でのみ実行可能であり、均一サービス(サー
バー・プール内のすべてのインスタンスによって提供される)またはシングルトン・サービス(サーバー・プール内の特
定のインスタンス上でのみ実行される)として定義されます。
接続時ロード・バランシング
Oracle Net Servicesは、データベース接続のための接続時ロード・バランシングを提供します。クラスタのすべてのSCAN
リスナーに接続リクエストを分散するクライアント側ロード・バランシングは、クライアント接続文字列のアドレス・リ
ストにSCANを使用することによって実現します。SQL*NETは、SCAN VIPのアドレスの 1 つをランダムに選択します。
選択されたサーバーが利用できない場合、リストの次のサーバーが試されます。サーバー側ロード・バランシングは、
SCANリスナーで達成されます。各SCANリスナーは、各サービスを提供するクラスタのインスタンス全てを認識します。
サービスに定義された目標に基づき、リスナーは目標を達成するのに最適なインスタンスを選択し、ローカル・リスナー
を通じてそのインスタンスへの接続を確立します。
「我が社ではクラスタ化されたデータベース・アーキテクチャを開発することでビジネス要件およびパフォーマンス要件を満たすことができました。また、
将来の成長に必要な柔軟性も実現できました。プロセッサの処理能力の向上に加え、新しいアーキテクチャによって再構築されたグローバル・データウェ
アハウス機能によって、パフォーマンスが向上し、より多くのアプリケーションとユーザーに対処できるようになりました。」
- Alcoa、Manager, Business Information & Technologies、Matthew Schroeder
高速アプリケーション通知(FAN)
高速アプリケーション通知を使用すると、Oracle RACデータベースとアプリケーションを統合できます。高速アプリケー
ション通知により、アプリケーションはクラスタにおける現在の構成を任意の時点で認識できるため、その時点でアプリ
ケーション・リクエストに応答できるインスタンスに対してのみアプリケーション接続が確立されます。Oracle RAC HA
フレームワークでは、クラスタ内の状態が変化すると、すぐにFANイベントが発生します。
統合されたクライアントは、イベントを受信すると瞬時に対応を開始します。DOWNイベントが発生した場合は、停止
したインスタンスに対する接続をクリーンアップすることで、アプリケーションの中断時間を最小限に抑えます。実行中
のトランザクションは中止され、アプリケーションにはエラーが返されます。接続を確立するアプリケーションは、アク
ティブなインスタンスにのみ送られます。サーバー側のコールアウトは、トラブル・チケットの記録や障害を通知するた
め、管理者へ連絡する場合に使用できます。UPイベントでは新規接続が作成され、アプリケーションは利用可能になっ
たリソースをすぐに活用できます。FANには、Oracle JDBC、Oracle Universal Connection Pool for Java、ODP.NET、および
OCIクライアントが統合されています。独自の接続プールを持つアプリケーションでFANを利用するには、Oracle RAC
FAN APIとOracle Database 11g Release 2 JDBCドライバを組み合わせて使用するか、Oracle Call Interfaceコールバック機能
を使用します。
ロード・バランシング・アドバイザ
データベース・ワークロードは、クラスタ構成が変化するのと同様に、時間とともに変化します。そのため、最新の情報
に基づいてデータベース接続を作成し、割り振ることが重要です。Oracle Real Application Clustersは、ロード・バランシ
ング・アドバイザを提供します。Oracle RACは、サービスを提供する各インスタンスに対して、そのサービスの実行に伴
うワークロードを常時監視しています。この情報はAutomatic Workload Repositoryに発行され、FANイベントを使用して
アプリケーションにも発行されます。FANイベントには現在提供されているサービス・レベルと、各インスタンスに対し
て送られる接続の割合に関するリコメンデーションが含まれます。
統合されたOracle Clientsは、これらのイベントを使用して、アプリケーション・リクエストのインテリジェントなロード・
バランシングを提供します。多くの接続プールはランダムまたはラウンドロビン・アルゴリズムを使用して、アプリケー
ションが接続の取得を試みる際に、プールからアイドル状態の接続を選択します。ロード・バランシング・アドバイザで
FANイベントを使用すると、接続プールはその時点で最適なサービスを提供する接続を選択します。Oracle JDBC、Oracle
UCP、OCI、およびODP.NETは、ロード・バランシング・アドバイザとの統合によって、ランタイム接続ロード・バラン
シングを提供します。固有の接続プールを保持するアプリケーションは、JDBC Oracle RAC APIまたはOracle Call Interface
コールバック機能を介して、ロード・バランシング・アドバイザを利用できます。
結論
Oracle Real Application Clustersは、高い可用性と高いスケーラビリティを実現するために設計されました。ハードウェア
およびソフトウェア障害からの保護を提供することで、継続的なデータ・アクセスを確実にするシステム可用性を提供し
ます。そのスケールアウトおよびスケールアップ機能により、どの方向にも拡張できるプラットフォームが提供されるの
で、企業はビジネスを成長させることができます。新たに開発されたアプリケーションだけではなく、既存のアプリケー
ションも、Oracle Real Application Clustersが提供する透過性により利益を得ることができます。アプリケーション開発、
および管理と変更管理がはるかに簡単になり、総所有コストの削減が可能になりました。Oracle Real Application Clusters
は、市場にはない一意の性能や機能を持ち合わせています。ミッション・クリティカルなアプリケーション環境および他
の多数のアプリケーション環境において、世界中のあらゆる業界で何千もの顧客に使用されています。
Oracle Real Application Clusters 11g
Release 2
2009 年 9 月
著者:BarbLundhild
共著者:
Copyright © 2009, Oracle and/or its affiliates.All rights reserved.
本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあ
ります。本文書は一切間違いがないことを保証するものではなく、さらに、口述による明示または法律によ
る黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる他の
保証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認
し、本文書によって直接的または間接的に確立される契約義務はないものとします。本文書はオラクル社の
書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる形式や
手段によっても再作成または送信することはできません。
Oracleは米国Oracle Corporationおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの
会社の商標です。
0109
Fly UP