oracle grid とdell poweredge によるサーバーリソースの自動的 … · as oracle...

Oracle GRID と Dell PowerEdge によるサーバーリソースの自動的なプロビジョニング検証結果報告

Creation Date: May 6, 2007

Last Update: Oct 18, 2007

Version: 1.3

目次目次 ..................................................................................................................................................2 謝辞 ..................................................................................................................................................3 1. 検証の背景 ..............................................................................................................................4

1.1. 検証の目的 ......................................................................................................................4 1.2. 検証サマリー ..................................................................................................................4 1.3. 検証環境説明 ..................................................................................................................5

2. FCF（高速接続フェイルオーバー）検証 ...........................................................................8 2.1. FCFとは ...........................................................................................................................8 2.2. FCFの利点 .....................................................................................................................11 2.3. FCFの設定方法 .............................................................................................................12 2.4. 検証項目と方法について ............................................................................................16 2.5. FCFの動作を確認する方法 .........................................................................................18 2.6. 検証結果 ........................................................................................................................21

3. ランタイム接続ロードバランス検証 ................................................................................24 3.1. Oracle Application Server 10gとOracle RAC間のロードバランシング....................24 3.2. ランタイム接続ロードバランシングの設定 ............................................................27 3.3. 検証方法 ........................................................................................................................28 3.4. 検証結果 ........................................................................................................................31 3.5. 考察 ................................................................................................................................32

4. サービス構成変更に伴う挙動 ............................................................................................40 4.1. サービス再構成のシチュエーション ........................................................................40 4.2. 検証 ................................................................................................................................41

5. 総括 ........................................................................................................................................45

Oracle GRID Center:「Oracle GRID と Dell PowerEdge によるサーバーリソースの自動的なプロビジョニング」 2

謝辞 2006 年 11 月、日本オラクル株式会社は、Grid 戦略パートナー企業各社の協賛のもと、

Oracle GRID Center を設立しました。本稿は、Oracle GRID Center の趣旨にご賛同頂いたデ

ル株式会社、EMC 株式会社の技術およびハードウェア・ソフトウェアのご支援を得て作成

しております。ここに協賛企業各社および技術者に謝意を表します。


1. 検証の背景 Web2.0 技術により、近年の Web アプリケーションシステムのユーザビリティは非常に

高くなりました。社内イントラ内での情報アクセスインタフェースはもちろん、オンライ

ンネットバンクやショッピング、ブログなど Web アプリケーションに対する依存度は年々

増加の一途をたどっています。それに伴い、フロントエンドとしてのアプリケーション・

サーバー、バックエンドのデータベースに求められる堅牢性およびパフォーマンスは非常

に高くなっています。また、限られたリソースを有効に活用しインフラに対する高い費用

対効果も同時に求められるようになっています。デル株式会社では、その解のひとつとし

てオラクル社が提供するアプリケーション・サーバー「Oracle Application Server 10g」とデ

ータベースシステムとして「Oracle Real Application Clusters 10g（以降、Oracle RAC）」を

提案しています。本検証ではデル株式会社の PowerEdge2950、PowerEdge1950 および EMC

社の CLARiX CX3-40 上に、この Oracle Application Server 10g と Oracle RAC の Grid 環境を

構築し以下の観点で検証を行いました。

1.1. 検証項目 Oracle Application Server 10g を使用するにあたり、以下の機能と動作について検証

を行いました。

① 高速接続フェイルオーバー（以降、FCF）

② ランタイム接続ロードバランシング

③ サービスの動的変更

本検証では、上記の通り Oracle Application Server 10g に重点を置いた項目に重点を

おいて検証をしました。2 章からは上記のそれぞれの検証について報告します。

1.2. 検証結果サマリー FCF の検証では、Oracle RAC のパブリックネットワーク障害／ノード障害／イン

スタンス障害／サービス障害発生時に Oracle Application Server 10g 側に Fast

Application Notification（以降、FAN）イベントが通知され、無効となったコネクショ

ンプールがクリアされることを確認しました。

Oracle RAC のノード間に負荷の偏りが発生した場合は、ランタイム接続ロード

バランシングによりコネクション使用率の適化が自動で行われることで、Oracle

RAC のリソースが有効に使用されることが確認できました。

また、高負荷がかかっているサービスに対して新たなノードを割り当てると、

FAN イベントとランタイム接続ロードバランシングにより、その割り当てたノード

に処理が分散され、負荷の適化が行われました。


1.3. 検証環境今回の検証で利用した GridCenter の環境は、以下の通りです。

【システム構成概要】

用途ホスト名

in20-6d クライアント

in20-6e

d01-0b

d01-0c

d01-0d

アプリケーション・サーバー

d01-0e

d02-0b

d02-0c

d02-0d

データベース・サーバー

d02-0e

負荷を生成するクライアントマシンは、インテル株式会社様よりご提供していただ

きました。


各システム構成詳細は、以下の通りです。

① データベース・サーバー（DELL PowerEdge2950：4 台構成）

【サーバースペック】

CPU Intel® Xeon® CPU 5160 @ 3.00GHz（Dual Core ×2）

Memory 8GB

HDD 146GB

【ソフトウェア構成】

OS Red Hat Enterprise Linux AS release 4 (Nahant Update 4) 64bit

Kernel 2.6.9-42.Elsmp

Oracle Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit

Cluster Oracle Clusterware

PSR 10.2.0.3

② ストレージ

ストレージ装置 EMC CX3-40

ソフトウェア EMC powermt for PowerPath ©Version 4.5.1 (build 22)

【物理構成】

Logical

Logical


③ アプリケーション・サーバー（DELL PowerEdge1955：4 台構成）



Memory 4GB

HDD 146GB




AS Oracle Application Server 10g Release 3 (10.1.3.1.0) for Linux x86

JDBC

Driver

10.2.0 ※

※ ランタイム接続ロードバランシングは JDBC ドライバ 10.2.0 からの

新機能であり、Oracle Application Server 10g Release 3 (10.1.3.1.0)に同

梱されている JDBCドライバ 10.1.0.5では機能しません。本検証では、

別途インストールした Oracle Client 10g Release 2 に同梱されている

JDBC ドライバ 10.2.0 を、Oracle Application Server 10g の共有ライブ

ラリに追加登録して使用しました。

④ クライアントマシン（2 台）



Mem 4GB

HDD 120GB




Oracle Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 32bit

【負荷生成ツール】

本検証では、負荷生成ツール「Apache Jakarta Project の JMeter」と、オンライ

ンペットショップ・アプリケーションである「JPetStore」を使用しました。


2. FCF（高速接続フェイルオーバー）検証

2.1. FCF とは FCF は Fast Connection Failover（高速接続フェイルオーバー）の略です。Oracle RAC

を構成するノード/インスタンス/サービス/パブリックネットワークに障害が発生し

た際に、データベース・サーバーとアプリケーション・サーバー間でイベント通知を

行い、コネクションプールから障害によって無効となったコネクションのみをクリー

ンアップします。以下では、FCF のイベント通知の仕組みや利点について述べます。

2.1.1. データベース・サーバーの障害時にアプリケーション・サーバ

ー（クライアント）側で発生する問題コネクションプールを使用するアプリケーションでは、Oracle データベース

に限らず、一般的に次のような問題を抱えています。

① すぐにデータベース側の障害を検知できないことによる問題

② 復旧したデータベース・インスタンスに新規コネクションを張らない

RAC-B に障害発生したにもかかわら

ずコネクションが残っている状態

データベース・サーバーアプリケーション・サーバー

この無効なコネクションを使用して

RAC-B からの SQL 応答待ちをしてい

た場合、待ち続けることになる。

① すぐにデータベース側の障害を検知できない


【パターン 1】SQL 発行前に障害

アプリケーション・サーバーのコネクションプールには、障害が発生

したインスタンス（上図の RAC-B）に対する無効なコネクションが残っ

ています。この無効なコネクションを使用した場合、データベースに接

続できないためエラーとなります。

【パターン 2】SQL 発行後結果待ち時に障害

SQL 実行中のインスタンスで障害が発生した場合、クライアント（今回

の場合は、アプリケーション・サーバー）は SQL の結果を待ち続けること

になります。

データベース・クラスタには仮想 IP アドレスが実装されており、上記の【パタ

ーン 1】に対しては効果が期待できますが、【パターン 2】のような対処し切れな

い場合があります。このような仮想 IP アドレスだけでは解決できないパターンを

補う機能が FCF です。

FCF が利用できない環境では、クライアント側で ENABLE=BROKEN を設定し

て TCP keepalive を出すようにし、かつ、keepalive のアイドル・タイマーを短くす

ることで、仮想 IP アドレスとの組み合わせで有効に機能します。


② 復旧したデータベース・インスタンスに新規コネクションを張らない問題

RAC-B が復旧したにも関わらず、アプリ

ケーション・サーバー側から RAC-B へ新

規コネクションが張られない

アプリケーションサーバデータベース・サーバー

もちろん、既存コネクションが不足してコネクションを追加生成した際には、

接続ロードバランシング機能（次章で説明）により RAC-B に新規コネクション

が張られることが考えられますが、RAC-B の復旧タイミングとは無関係です。

新規コネクションが RAC-B に張られない場合、RAC-A 側に処理が偏り続け

ることになり、システム全体の性能が向上しない可能性があります。

FCF を使用することで、データベース・サーバー側の障害や復旧のイベント

（FAN イベント）をクライアントやアプリケーション・サーバー側に通知し、

これらの問題を解決することができます。

これは Oracle Application Server 10g と Oracle RAC を使用する利点のひとつと

言えます。以降では、FCF の具体的な仕組みや設定方法、及び検証結果につい

て記述します。


2.2. FCF の利点 JDBC ドライバの FCF は Oracle Application Server 10g と Oracle RAC の各 ONS プロ

セスの通信による FAN イベントに従って、コネクションキャッシュがコネクション

を操作することで実現されています。FAN HA イベントには、リソースの起動を知ら

せる UP イベントとリソースの停止を知らせる DOWN イベントがあります。

【障害発生時】

③FANイベント

（RAC-B:DOWN) ②RAC-B の障害検知

①障害発生

Oracle Clusterware が障害を検知すると、即時に DOWN イベントが RAC を構成す

る各ノードの ONS プロセスから送信されます。DOWN イベントを受け取ると、コネ

クションプールから無効なコネクションがクリアされます。

③FANイベント

（RAC-B:DOWN)

④無効なコネクション

のクリア

③FANイベント ②RAC-B の復旧検知

【障害復旧時】

障害からの復旧の場合も、FAN イベント通知の流れは同じです。UP イベントを受

け取ると、コネクションプールに新規コネクションが生成されます。

①障害復旧

（RAC-B:UP)

④新規コネクションの生成

③FANイベント

（RAC-B:UP)


2.3. FCF の設定方法ここでは、Oracle Application Server 10g と Oracle RAC に必要な FCF の設定方法に

ついて説明します。設定に必要な項目の概要は、以下の通りです。

② 各データベース・サーバーの ONS が、全アプリケーション・サーバーの

ONS と通信できていること

① 検証で使用するサービス「srvA」を構成しておくこと

【Oracle RAC（データベース・サーバー）側の設定】

① 各アプリケーション・サーバーの ONS が、全データベース・サーバー、

アプリケーション・サーバーの ONS と通信できていること

② 各 OC4J インスタンスが使用するコネクションプールの FCF 設定が有効

になっていること

【Oracle Application Server10g（アプリケーション・サーバー）側の設定】

2.3.1. サービスの作成サービスは、Oracle Enterprise Manager Database Control の「クラスタ管理デー

タベースサービス」画面にて作成/変更/削除します。また、以下の srvctl コマン

ドでも実行できます。

srvctl modify service -n <ノード名> -d <データベース名> -s <サービス名> -r

<Preferred なインスタンス名>,<インスタンス名> -a <Available なインスタンス名>,

<インスタンス名>

●サービス変更時の書式：

srvctl add service -n <ノード名> -d <データベース名> -s <サービス名> -r

<Preferred なインスタンス名>,<インスタンス名> -a <Available なインスタンス名>,

<インスタンス名>

●サービス作成時の書式：


2.3.2. Oracle RAC 側の ONS 設定 1） Oracle RAC の ONS 設定ファイルに、ONS プロセスが使用するローカル

とリモートのポート番号が設定されていることを確認します。

useocr=on

loglevel=3

remoteport=6200

$ORA_CRS_HOME/opmn/conf/ons.config

localport=6101

2）次に、racgons コマンドでアプリケーション・サーバー側の ONS を登録

します。これは、Oracle RAC 側のひとつのノードでのみ実行します。

その後、全ノードで ONS プロセスを再起動します。

設定が反映されていることを確認します。

$ORA_CRS_HOME/bin/racgons add_config [AS1 のホスト名] : [AS1 の ONS リモートポート

番号] , [AS2 のホスト名] : [AS2 の ONS リモートポート番号] , ･･･

$ORA_CRS_HOME/bin/onsctl stop

$ORA_CRS_HOME/bin/onsctl start

Number of onsconfiguration retrieved, numcfg = 8 onscfg[0] {node = d02-0b, port = 6200} Adding remote host d02-0b:6200 onscfg[1] {node = d02-0c, port = 6200} Adding remote host d02-0c:6200 onscfg[2] {node = d02-0d, port = 6200}

$ORA_CRS_HOME/bin/onsctl debug

Adding remote host d02-0d:6200 onscfg[3] {node = d02-0e, port = 6200} Adding remote host d02-0e:6200 onscfg[4] {node = d01-0b, port = 6200} Adding remote host d01-0b:6200 onscfg[5] {node = d01-0c, port = 6200} Adding remote host d01-0c:6200 onscfg[6] {node = d01-0d, port = 6200}


2.3.3. Oracle Application Server 10g 側の ONS 設定 1） Oracle Application Server 10g 側の ONS 通信設定

各アプリケーション・サーバーの opmn.xml ファイルに、OPMN プロ

セスが FAN で使用するホスト名とポート番号と、Oracle RAC 側の ONS

プロセスのホスト名とポート番号が設定されていることを確認します。

opmn.xml を再読み込みし、設定が反映されていることを確認します。

<topology>

<nodes list="d02-0b:6200,d02-0c:6200,d02-0d:6200,d02-0e:6200"/>

<discover list="*225.0.0.33:9250"/>

</topology>

</notification-server>

$ORACLE_HOME/opmn/bin/opmnctl reload

$ opmnctl debug comp=ons Server connections: ID CONNECTION ADDRESS PORT FLAGS SENDQ REF SUB WSA -------- ------------------------------------- ------- ---------- ---------- ------ ------ ------- 0 10.196.2.11 6200 010405 00000 001 000 - 1 10.196.2.12 6200 010405 00000 001 000 - 2 10.196.2.13 6200 010405 00000 001 000 - 3 10.196.2.14 6200 010405 00000 001 000 - 6 10.196.1.14 6200 050026 00000 002 000 - Client connections: ID CONNECTION ADDRESS PORT FLAGS SENDQ REF SUB WSA -------- ------------------------------------- ------- ---------- ---------- ------ ------ ------- 4 internal |0| ||01008a 00000 001 003 7 127.0.0.1 6100 01001a 00000 001 001 8 127.0.0.1 6100 01001a 00000 001 002 9 127.0.0.1 6100 01001a 00000 001 001

00||request 127.0.0.1 6100 03201a 00000 001 000

<port local="6100" remote="6200" request="6003"/>

<ssl enabled="false" wallet-file="$ORACLE_HOME/opmn/conf/ssl.wlt/default"/>

<notification-server interface="ipv4">

<?xml version = '1.0' encoding = 'UTF-8'?>

<opmn xmlns="http://www.oracle.com/ias-instance">

<log path="$ORACLE_HOME/opmn/logs/opmn.log" comp="internal;ons;pm" rotation-size="1500000"/>

<debug path="$ORACLE_HOME/opmn/logs/opmn.dbg" comp="" rotation-size="1500000"/>

[oracle@d01-0b conf]$ cat $ORACLE_HOME/opmn/conf/opmn.xml


また、使用するコネクションプールのプロパティに、次の設定されていることを

Oracle Enterprise Manager Application Server Control から確認してください。

fastConnectionFailoverEnabled=TRUE

connectionCachingEnabled=TRUE


2.4. 検証項目と方法について基本動作検証では、動作確認を単純化するためにアプリケーション・サーバー：

1 台とデータベース・サーバー：2 台の、合計 3 ノードで行いました。

ここでの確認ポイントは、以下の通りです。

次の 3 つの障害パターンにおける FCF の挙動を確認しました。

【障害発生時】

① DOWN イベントの発生

② DOWN イベントの受信

③ コネクションのクリア

【障害復旧時】

④ UP イベントの発生

⑤ UP イベントの受信

⑥ 新規コネクションの生成

① パブリックネットワーク障害（物理的に LAN ケーブルを引き抜く）

② インスタンス障害（pmon プロセスの kill）

③ ノード障害（reboot –f によるノードの強制再起動）

サービスは、Oracle RAC の全インスタンス又は、いくつかのインスタンスに定義

できます。サービスを作成する際は、通常時に動作する Preferred インスタンスと障

害発生時に動作する Available インスタンスを定義できます。もちろん、Oracle RAC

の全インスタンスが Preferred の場合、Available インスタンスは存在しません。

Preferred インスタンスで障害となった場合、Available に設定されていたインスタン

スがあれば、そのインスタンス上でサービスが有効になり、ONS が UP イベントを送

信します。


検証方法としては、以下の方法をとりました。

1）アプリケーション・サーバーの OC4J を起動（コネクションプールの生成）

2） Oracle RAC 側で障害発生（FAN イベント及びコネクションクリアを確認）

3）障害復旧（FAN イベント及びコネクション生成を確認）

この基本動作検証の目的は、イベント通知とコネクション数についての確認である

為、各サーバー共に低負荷な状況とします。

次に、SQL 実行タイミングについて検証しました。

以下のような画面遷移を行い、FCF を設定したコネクションプールを使用する Web

アプリケーションを準備しました。

そのコネクションが接続しているインスタンスを表示

① コネクションプールからひとつのコネクションを GET し② INSERT または SELECT 文を発行

①の操作で GET したコネクションの接続先インスタンスを把握し、障害を起こす

ノードを決定します。

②の SELECT 文では、障害を発生させる時間を確保する為に、数十秒の全表走査

をしています。


2.5. FCF の動作を確認する方法以下の 5 つのログ及び情報を取得することで、FCF の動作を確認しました。

① evmwatch ログ

ログ内容：障害発生、及び FAN イベント送信ログをリアルタイム表示

コマンド：$ORA_CRS_HOME/bin/evmwatch @@ -A -t "@timestamp @@"

出力先：標準出力

② Oracle RAC の ONS ログ

ログ内容：FAN イベント送信ログ

出力先：$ORA_CRS_HOME/opmn/ons.log

【出力例】

"15-Mar-2007 21:06:10 CRS ora.d02-0b.vip is transitioning from state OFFLINE to state ONLINE on member d02-0c"

"15-Mar-2007 21:06:13 RAC: ora.d02-0b.vip: up: "

"15-Mar-2007 21:06:13 CRS ora.d02-0b.vip started on member d02-0c"

【出力例】

07/03/15 21:06:06 [8] Connection 28,127.0.0.1,6101 body: VERSION=1.0

host=d02-0b incarn=0 status=nodedown reason=public_nw_down

【設定方法】

$ORA_CRS_HOME/opmn/conf/ons.config

localport=6101

remoteport=6200

loglevel=9

useocr=on

※ 各 ONS プロセスを再起動して、設定を反映させます。

$ORA_CRS_HOME/bin/onsctl stopall

$ORA_CRS_HOME/bin/onsctl start


③ Oracle Application Server 10g の OPMN ログ

ログ内容：FAN イベントの受信

出力先：$ORACLE_HOME/opmn/opmn.dbg

④

Content-Length: 70 VERSION=1.0 host=d02-0c incarn=0 status=nodedown reason=public_nw_down

【設定方法】

$ORACLE_HOME/opmn/conf/opmn.xml

<opmn xmlns="http://www・・・・">

</opmn>

・・・・・・

<notification-server interface="ipv4">

<debug path="$ORACLE_HOME/opmn/logs/opmn.dbg" comp="ons" rotation-size="1500000" />

<log path="$ORACLE_HOME/opmn/logs/opmn.log" comp="inter・・・" rotation-size="1500000" />

【出力例】 07/03/15 20:35:42 [ons-messages] Connection 2,d02-0d,6200: received notification (546,70) 0x00001005 POST /event HTTP/1.1 Version: 3 eventType: database/event/host affectedNodes: generatingComponent: database/rac/service generatingProcess: d02-0d.gridcenter.jp.oracle.com:19498 creationTime: 1173958542


④ JDBC ログ

ログ内容：コネクションプールクリアおよび生成時に呼ばれるクラス

出力先：$ORACLE_HOME/jdbc/log/jdbc.log

【出力例】 2007/03/15 21:06:07 oracle.jdbc.pool.OracleImplicitConnectionCache cleanupFailoverConnections "詳細レベル (低): OracleImplicitConnectionCache.cleanupFailoverConnections(serviceDownEvent=falsehostDownEvent=true,instName=null,dbUniqName=null,hostName=d02-0b,status=nodedown) ：詳細レベル (低): OracleImplicitConnectionCache.processFailoverEvent(eventType=256,instName=dell1,dbUniqName=dell, hostName=d02-0b,status=up, card=2) 2007/03/15 21:13:45 oracle.jdbc.pool.OracleImplicitConnectionCache processUpEvent 詳細レベル (低): OracleImplicitConnectionCache.processUpEvent(Cardinality=2)"

【設定方法】 ①デバッグ用の JDBC ドライバーに入れ替え $ORACLE_HOME/jdbc/lib 配下の ojdbc14dms.jar を同ディレクトリの ojdbc14dms_g.jar と置き換える。 ②logging.properties にログレベルを追記 $ORACLE_HOME/ｊdk/jre/lib/logging.properties に下記二行を追記 oracle.jdbc.level=FINEST oracle.jdbc.pool.level=FINEST

③OC4J の設定ファイル変更（$ORACLE_HOME/opmn/conf/opmn.xml)

<ias-component id="default_group"> <process-type id="home" module-id="OC4J" status="enabled"> <module-data> <category id="start-parameters"> <data id="java-options" value="-server -XX:MaxPermSize=128M -ms512M -mx1024M -XX:+AggressiveHeap -XX:AppendRatio=3 -Djava.security.policy=$ORACLE_HOME/j2ee/home/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false -Doracle.jdbc.Trace=true -Doracle.jdbc.LogFile=/home/oracle/product/10.1.3.1/OracleAS_1/opmn/log/jdbc.log -Djava.util.logging.config.file=/home/oracle/product/10.1.3.1/OracleAS_1/opmn/conf/logging.properties"/> </category> <category id="stop-parameters"> <data id="java-options" value="-Djava.security.policy=$ORACLE_HOME/j2ee/home/config/java2.policy -Djava.awt.headless=true -Dhttp.

:


⑤GV$SESSION を監視

内容：各インスタンスに接続しているコネクション数

取得間隔：2 秒毎

【設定方法】 select 'Instance-' || to_char(sysdate,'mm/dd-hh24:mi:ss') as

"TimeStamp", .host_name,s.service_name,s.username,count(s.username) from gv$session s, gv$instance i where username in ('XXX') and s.inst_id = i.inst_id group by i.host_name,s.service_name,s.username order by 3,2; select 'AS- ' || to_char(sysdate,'mm/dd-hh24:mi:ss') as "TimeStamp",machine,service_name,count(username)from gv$session where username in ('XXX') group by machine,service_name,username order by 2,3;

2.6. 検証結果

2.6.1. FCF の基本動作検証結果次のいずれの障害パターンにおいても、FAN イベントにより無効なコネクシ

ョンのクリアと新規コネクションの生成が行われることを確認できました。

① パブリックネットワーク障害

② インスタンス障害

③ ノード障害


2.6.2. SQL 実行タイミングにおける障害時の動作検証結果

① SQL 実行前に障害が発生した場合

「dell2」インスタンス接続しているコネクションプールを使用し

ています。この後、dell2 インスタンスを停止しました。次に、

「insert」ボタンを押してトランザクションを実行します。

すぐにエラーとなりました。これは障害検知により DOWN イ

ベントが通知された結果コネクションがクリアされたためです。

FCF を使用していない場合もエラーとなりますが、無効なコネク

ションがクリアされていないため、クライアントはこの無効なコ

ネクションを使用する可能性があります。


② SQL 実行後に障害が発生した場合

「dell2」インスタンス接続しているコネクションプールを使用

しています。次に「insert ＆ dummy select」ボタンを押してトラ

ンザクションを実行します。この後、結果待ちの間に dell2 イン

スタンスを停止しました。

すぐにエラーとなりました。

これは障害検知により DOWN イベントが通知された結果コネ

クションプールがクリアされたためです。


3. ランタイム接続ロードバランス検証

3.1. Oracle Application Server 10gとOracle RAC間のロードバランシング

3.1.1. ランタイム接続ロードバランシングとはランタイム接続ロードバランシングの設定をしていると、JDBC コネクショ

ンプールは Oracle RAC 側から通知されるロードバランシング・アドバイザの

情報にしたがって、使用するコネクションの割合を決定します。これは ONS

通信を用いた Oracle Application Server 10g と Oracle RAC の有効な機能のひとつ

です。

以下の図では、ランタイム接続ロードバランシングの動作を示しています。

FCF における FAN イベントの通知経路を説明した図と似ていることからも推

測できますが、ランタイム接続ロードバランシングは、FCF と同じ経路の FAN

イベントを利用しています。

AS RAC-A

ONS

OCR

Voting

80%

ONS

20%

① RAC-A の負荷

20%

① RAC-A の負

②コネクションの

比率のAdvisory

RAC-A：80%

RAC-B：20%

で通知 ①

RAC-Aの負荷低い

RAC-B の負荷高い

① RAC-A の負

荷20% RAC-B の負

③コネクションの

比率のAdvisory

RAC-A：80%

RAC-B：20%

で使用


③ 通知に従い、アプリケーション・サーバー側ではコネクションを使用（上図の場合、

RAC-A に接続しているコネクションの方が、RAC-B に接続しているコネクションよ

りも多く選択されます）

① ロードバランシング・アドバイザは各サービスの負荷（スループット又はサービス

タイム）について統計情報を収集しています。（上図の場合、RAC-A の負荷が低い）

② 各インスタンス間のサービス負荷が適になるようなコネクションの比率の

Advisory を通知します。

ランタイム接続ロードバランシングは、既に生成されているコネクションの内、

どのコネクションを使用するかを判断してロードバランシングします。

これに対して、コネクションを生成する際に、どのインスタンスに接続するか

を判断してロードバランシングさせる、接続時ロードバランシングがあります。

接続時ロードバランシングには、「クライアントサイド接続ロードバランシング」

と「サーバーサイド接続ロードバランシング」があります。

クライアントはこの 2 段階の接続時ロードバランシングを経て、Oracle RAC の

インスタンスに接続します。

1）クライアントサイド接続ロードバランシングについて

TNSNAMES.ORA に以下の設定をします。

(SERVICE_NAME = dell)

)

)

(CONNECT_DATA =

(ADDRESS = (PROTOCOL = TCP)(HOST = d02-0d-vip)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = d02-0e-vip)(PORT = 1521))

(ADDRESS = (PROTOCOL = TCP)(HOST = d02-0c-vip)(PORT = 1521))

(load_balance = yes)

(ADDRESS = (PROTOCOL = TCP)(HOST = d02-0b-vip)(PORT = 1521))

(FAILOVER = yes)

(DESCRIPTION =

DELL =

このとき、クライアントからは ADDRESS として列挙された接続先を

ランダムに選んで、接続リクエストを発行します。


2）サーバーサイド接続ロードバランシングについて

設定パターンは、以下の通りです。

①の場合は、接続要求を受けたリスナーが各インスタンスに接続されて

いるサービスごとのコネクション数を判断し、適切なノードに接続要求をリ

ダイレクトします。

②の場合は、接続要求を受けたリスナーが各ノードのサービス負荷を判

断し、適切なノードに接続要求をリダイレクトします。

RAC-A

RAC-B

リスナー

リスナー

コネクション

②新規接続要求各ノードのリスナーは、どのノードにいくつセッションが張られている

か、各ノードの負荷がどれくらいか

①各ノードのリスナーは、どのインスタンスにいくつセ

ッションが張られているか、各インスタンスの負荷がど

れくらいかを統計情報により把握している

① 各インスタンスのコネクション数を均等

② ロードバランシング・アドバイザのガイドに従う

（サービスタイム適化 or スループット適化）

③接続数均等か、ロードバランシ

・アドバイザのガイドに従う

適切なノード

ング

かの設定によって、

に接続要求をリダイレクト

コネクション


3.2. ランタイム接続ロードバランシングの設定

3.2.1. ロードバランシング・プロパティの設定ロードバランシング・アドバイザを有効にするには、サービスごとにロ

ードバランシング・プロパティを設定します。

各メトリックには以下を設定します。

CLB_GOAL => 接続ロードバランシングのメトリック

)

GOAL => ロードバランシング・アドバイザのメトリック,

SERVICE_NAME => サービス名,

DBMS_SERVICE.MODIFY_SERVICE（

GOAL：ランタイム接続ロードバランシングの設定

▼THROUGHPUT

→スループットが適になるようにアドバイザが通知します。

▼SERVICE_TIME

→サービス時間が適になるようにアドバイザが通知します。

▼NONE

→アドバイザ通知をしません。

CLB_GOAL：サーバーサイドロードバランシングの設定

▼SHORT

→GOAL パラメータの設定に従い、ロードバランシングします。

▼LONG

→セッション数が均等になるようにロードバランシングします。

※ CLB_GOAL：SHORT 且つ GOAL：NONE の設定 Oracle9i の動作と同

じサーバーサイド接続ロードバランシングが行われます。


3.3. 検証方法

3.3.1. 検証環境についてこの検証では、2 種類の負荷を 1 つの Oracle RAC データベースにかけま

す。それぞれの負荷を区別するために、以下の 2 つのサービスを作成しま

した。

▼サーバー環境

アプリケーション・サーバー:1 台

ノード名

① jpet サービス：標準的な WEB オンラインショッピングを行うアプリケ

ーション「JPetStore」から使用されるサービス

② srvB サービス：特定ノードに過負荷を与えるための検索主体のアプリ

ケーション「sampleApp」から使用されるサービス

デプロイした

アプリケーション

使用する

サービス

d01-0c JPetStore jpet

d01-0d sampleApp srvB

データベース・サーバー:4 台

サービス割り当てノード名インスタンス名

jpet srvB

d02-0b dell1 ● ×

d02-0c dell2 ● ×

d02-0d dell3 ● ●

d02-0e dell4 ● ●

jpet は Preferred で dell1～dell4 の全ノードに割り当てられています。

srvB は Preferred で dell3 および dell4 のみに割り当てられています。


3.3.2. 検証シナリオ以下のような、業務上起こりうる現象を想定しました。

→ このときランタイム接続ロードバランシングにより、Oracle RAC の

リソースの利用が改善され、全体のスループット（またはサービスタイム）

が回復するかどうかが、今回の検証の焦点となります。

以下のシナリオを実行し、スループット及びサービスタイム（レスポン

スタイム）を観察します。

※ 過負荷の想定としては、バッチ処理や jpet サービスに接続するプロセス

が処理負荷の重い SQL を実行した場合等が考えられます。

あるサービス A が全ノード上で稼動しています。

このときひとつのノードに過負荷がかかり、そのノード上におけるサービス

A のスループットが低下（またはサービスタイムが増加）しました。

④ ここで、ランタイム接続ロードバランシングが機能する

→ 不均一な負荷に対して、Oracle RAC リソースの利用が改善される

⑤ ③の追加負荷を停止すると、

→ ランタイム接続ロードバランシングにより、Oracle RAC リソースの

利用が改善される

③ X 分後、

srvB サービスを使用するアプリケーション「sampleApp」へ負荷をかけ始める

→ jpetと srvBの両サービスが割り当てられたノードが過負荷な状態と

なり、そのノード上の jpet サービスのスループットやサービスタイ

ムが性能劣化する

→ 結果、アプリケーション「JPetStore」のスループットが低下する

② jpet サービスを使用するアプリケーション「JPetStore」へ負荷をかける

① アプリケーション・サーバーの OC4J を起動（初期コネクションの生成）


また、この検証の結果として予想されるスループットイメージは、以下

の通りです。図中の丸囲みの数字は、前頁のシナリオと一致しています。

今回の検証のイメージ図は以下の通りとなります。実線の矢印は SQL

が実行されているコネクションを、点線は空きコネクションを意味しま

す。

JPetStore

SrvBサービス

コネクションプール sampleApp

Jpetサービス

ランタイム接続ロードバランシング

JPetStore

コネクションプールsampleApp

SrvBサービス

Jpetサービス


3.4. 検証結果検証の結果、予想通りのスループットの変化が確認できました。

ロードバランシング・プロパティの設定としては、以下の GOAL、CLB_GOAL の

組み合わせを行いました。

No CLB_GOAL GOAL

1 SHORT THROUGHPUT

2 SHORT SERVICE_TIME

3 SHORT NONE

ランタイム接続ロードバランシングを設定しない（SHORT-NONE）場合、サービ

ス「srvB」を使用するアプリケーション「sampleApp」に追加負荷をかけると、スル

ープットが落ちたまま（サービスタイムは増加したまま）となりますが、ランタイム

は減少）することが確認できました。

このことから、ランタイム接続ロードバランシングは、不均一な負荷がかかる場合

に、Oracle RAC リソースの利用が改善される効果が期待できます。

4 ノード RAC（dell1/dell2/dell3/dell4）のうちの 2 ノード(dell3/dell4 インスタンス上

のサービス srvB)に追加負荷をかけたパターン

4 ノード中 2 ノードに対し、

追加負荷をかけた期間

ランタイム接続ロードバランスが無効な

のでレスポンスタイムが遅いまま

ランタイム接続ロードバランスが

効いているためレスポンスタイム

が自然に短くなる


3.5. 考察

3.5.1. ランタイム接続ロードバランシングの負荷分散イベント ONS を通して Oracle RAC データベースからは、以下のようなアドバイ

ザが 30 秒周期で通知されます。（以下は 3 ノードの場合の例）

※ percent：負荷の配分率（アドバイス）

インスタンス間の負荷の均衡がくずれると、Oracle RAC 側で判断してコネクシ

ョン使用率を変更するように通知します。（以下は dell3 の負荷が高くなった例）

{{instance=dell2 percent=31 flag=GOOD}{instance=dell3 percent=34 flag=GOOD}{instance=dell1 percent=35 flag=GOOD}} timestamp=2007-03-08 02:50:58

{{instance=dell2 percent=35 flag=GOOD}{instance=dell3 percent=10 flag=GOOD}{instance=dell1 percent=45 flag=GOOD} } timestamp=2007-03-08 02:55:58

このようにして、dell3 のコネクション使用率を下げて dell1/dell2 の使用率を上

げることでリソースの有効利用を図ります。


3.5.2. データベース側から見たスループット/サービスタイム統計「3.4 検証結果」で示したスループット及びサービスタイムのグラフは、

負荷ツールであるJMeterの実行ログから作成しました。これは、JPetStore

アプリケーションを実際に操作するクライアントが体感するスループット

およびサービスタイムとなります。

そこで、スループットの高低、サービスタイムの長短を判断しているデ

ータベース・サイドでは、どのような統計となっているのかを確認しまし

た。動的パフォーマンスビュー「gv$servicemetric」を参照することで、デ

ータベース内の統計情報を確認することができます。

次の SQL によって各サービスの統計情報を取得しました。

結果例）

SELECT SERVICE_NAME , TO_CHAR(BEGIN_TIME, 'HH:MI:SS') begin_time , TO_CHAR(END_TIME, 'HH:MI:SS') end_time , INSTANCE_NAME , ELAPSEDPERCALL SERVICE_TIME , CALLSPERSEC THROUGHPUT from gv¥$instance i, gv¥$active_services s, gv¥$servicemetric m where s.inst_id = m.inst_id and s.name_hash = m.service_name_hash and i.inst_id = m.inst_id and m.group_id = 10 and m.service_name in ('jpet','srvB') order by SERVICE_NAME , i.INST_ID , BEGIN_TIME ;

rvice Time Service Begin Time End Time Instance mSec/Call Calls/sec -------------------- ---------- ---------- ---------- ------------ --------- jpet 07:56:51 07:56:56 dell1 23581 44.31 07:56:29 07:56:34 dell2 31026 61.48 07:56:18 07:56:23 dell3 159597 32.50 07:56:30 07:56:35 dell4 217981 20.94 srvB 07:56:18 07:56:23 dell3 68300 191.92 07:56:30 07:56:35 dell4 194815 89.82

Service Time mSec/Call : Service Time

Calls/sec : ThroughPut

ロードバランシング・アドバイザは 5 秒間毎の統計情報を収集し、過去

2 分間の平均を計算しています。


環境：4 ノード RAC（dell1/dell2/dell3/dell4）のうちの 2 ノード(dell3/dell4 インスタ

ンス上の srvB)に追加負荷をかけたパターン

★ロードバランシング設定：SHORT-SERVICE_TIME

srvB サービスへの負荷をかけている 300 秒以降は、前項で紹介した動的パフォ

ーマンスビュー「gv$servicemetric」で確認できる「Service Time」統計を元に負荷

分散を行っていると考えられます。srvB サービスに対して負荷をかけ始めた後も

スループットは安定しています。


★ロードバランシング設定：SHORT-THROUGHPUT

srvB サービスへ負荷をかけている 300 秒以降は、動的パフォーマンスビュー

「gv$servicemetric」で確認できる「ThroughPut」統計を元に負荷分散を行っている

と考えられます。srvB サービスに対して負荷をかけ始めた後もスループットは安

定しています。


3.5.3. ServiceTime、ThroughPut 設定の使い分けについて

ランタイム接続ロードバランシングの設定には、次のような指針があります。

ここまでの検証で使用した JPetStore アプリケーションは、標準的なオンライ

ンショップを想定しています。JMeter による機械的な負荷のため、実際のユー

ザー操作とは挙動が若干異なりますが、トランザクションとしては長短が混合

しています。

今回の検証において、ランタイム接続ロードバランシングの「ServiceTime」

「ThrougPut」の設定による違いは確認できませんでした。つまり、どちらの設

定を採用しても、データベース・サーバーのリソースを効率良く利用できる挙

動が確認できました。

次に、JPetStore アプリケーションとは異なり、一定の短いトランザクション

を想定したアプリケーションを作成し、srvA サービスに対して、以下のような

検証を行いました。

Service Time ： Web オンラインショップなどさまざまな長さのトランザクションが

混在しているシステム

ThroughPut ：バッチなど一定の長さのトランザクションが混在しているシステム

① アプリケーション・サーバーの OC4J を起動（初期コネクションの生成）

② srvA サービスを使用するアプリケーションへ負荷をかける

③ X 分後、

srvB サービスを使用するアプリケーション「sampleApp」へ負荷をかけ始める

⑤ ③の追加負荷を停止すると、

→ ランタイム接続ロードバランシングにより、Oracle RAC リソースの

利用が改善される

④ ここで、ランタイム接続ロードバランシングが機能する

→ 不均一な負荷に対して、Oracle RAC リソースの利用が改善される

→ srvA と srvB の両サービスが割り当てられたノードが過負荷な状態と

なり、そのノード上の srvA サービスのスループットやサービスタイム

が性能劣化する

→ 結果、アプリケーションのスループットが低下する


検証パターンとしては「2 ノード RAC（dell1/dell2）のうちの 1 ノード(dell1 インス

タンス上の srvB)に追加負荷をかけたパターン」を行いました。

今回の srvA を使用するアプリケーションのテストでも、JPetStore アプリケーショ

ンのときと同様に、「Short-ServiceTime」「Short-ThroughPut」設定ではランタイム接続

ロードバランシングによるリソースの有効利用が確認できました。

このアプリケーションの場合は、「ThroughPut」より「Short-ServiceTime」の設定の

方が、若干スループットが高くなりましたが、大きな差ではないと判断しています。

2 ノード中 1 ノードに

追加負荷をかけた期間

アプリケーションによって若干の差があると思われますが、「ServiceTime」「ThrougPut」の

どちらを選択しても、不均一な負荷がかかってもランタイム接続ロードバランシングにより

RAC リソースの利用が改善される効果が期待できます。


3.5.4. ロードバランシング・アドバイザの通知によるコネクションの

再作成これまでの検証では、ランタイム接続ロードバランスによる生成済みの

コネクションに対するロードバランスの挙動をみてきました。

CLB_GOAL パラメータを SHORT に設定すると、Oracle リスナーもロー

ドバランシング･アドバイザに従うようになります。この場合、新規コネク

ションを生成する過程の中で接続先インスタンスを決定する際に、ロード

バランシング・アドバイザから通知される統計情報に従います。

高負荷により新規にコネクションが必要になれば、負荷の低いノードに

対して新規コネクションが生成されると予想されます。コネクション数の

推移について調べてみました。

前提：Oracle JDBC 10gR2 でランタイム接続ロードバランシングが使用できる環境

4 ノード（dell1/dell2/dell3/dell4）に jpet サービスを割り当て、2 ノード(dell3/dell4)の srvB サ

ービスに追加負荷をかけた際に、各インスタンスの jpet サービスに接続しているコネクシ

ョン数は、以下のグラフの結果となりました。

インスタンス毎のコネクション数の遷移（SHORT-NONE）

インスタンス毎のコネクション数の遷移（SHORT-SERVICETIME）

インスタンス毎のコネクション数の遷移（SHORT-THROUGHPUT）


「SHORT-NONE」ではロードバランシング・アドバイザの通知が無い為、コネク

ション数に変化がありませんが、「SERVICETIME」及び「THROUGHPUT」ではコネ

クション数に変化が見られます。これは次のような説明ができます。

① srvB サービスに追加負荷をかけ、srvB が割り当てられている dell3/dell4 の負荷が

高くなる

② ロードバランシング・アドバイザは、負荷の低い dell1/dell2 に接続しているコネ

クションの使用率を上げる通知をする

③ srvBサービスへの負荷のかかったdell3/dell4に接続しているコネクションの使用

率が下がり、いくつかの空き（使用されていない）コネクションが再作成される

④ 再作成されたコネクションはロードバランシング・アドバイザの通知に従い、適

切なリスナーへリダイレクトする

⑤ 結果、負荷の低いインスタンス（dell1/dell2）のコネクション数が増加

⑥ srvB サービスへの負荷が無くなると、ロードバランシング・アドバイザが各コ

ネクションの使用率を適化する

→ 各ノードとも同程度の負荷になるのでコネクション数がバランスされる。

終的なコネクション数に若干のバラつきが見られますが、この程度は問題ない

と考えます。ロードバランシング・アドバイザは、スループット又はレスポンスタ

イム（サービスタイム）を適化することを目的としており、コネクション数を均

一にすることではありません。

この検証結果より、コネクション数についてもロードバランシング・アドバイザ

に従って必要なノードに必要な数のコネクションが張りなおされることにより、効

率的に Oracle RAC のリソースを使用していることになります。


4. サービス構成変更に伴う挙動

4.1. サービス再構成のシチュエーション多様なサービスを提供するシステム環境において、サーバーリソースの見積もり

は大変難しいものです。特に Web オンラインシステムでは、予期せぬトランザクシ

ョン数の増加に対応する為に新たにノードの追加したり、サーバーリソースに余裕

のあるノードにサービスを新たに割り当てたりすることが考えられます。

上図の例では、

サービス C の負荷が低く、RAC-D のサーバーリソースが他のノードに比べて低い

状態である際に、サービスAの負荷が想定よりも高かったため、サービスAにRAC-D

を追加割り当てしています。

サービスに対してインスタンスを追加割り当てした際の影響について、検証を行い

ました。観点は、以下の 2 つとしました。

1）既存セッションへの影響はないか

2）追加したノードによりスループットがあがるか

この検証では、インスタンスを追加割り当てした際に負荷が分散されるかを確認す

るため、過負荷状態を作り出しました。


4.2. 検証

4.2.1. 検証環境について一定の長さのトランザクションを発行するアプリケーションを用意し、

サービス「srvA」を作成しました。

▼ サーバー環境

アプリケーション・サーバー環境

ノード名使用するサービス名

d01-0c srvA

データベース・サーバー環境

初期状態では、dell1/dell2/dell3 の 3 つのインスタンスに srvA が割り

当てられており、検証シナリオの途中で、srvA に dell4 インスタンス

を追加します。アプリケーションからは srvA サービスに接続し、デ

ータベースに負荷をかけます。

ノード名インスタンス名 srvA

d02-0b dell1 ○

d02-0c dell2 ○

d02-0d dell3 ○

d02-0e dell4 ● （後から追加）

前提：Oracle JDBC 10gR2 でランタイム接続ロードバランシングが使用できる環境


4.2.2. 検証シナリオ以下の検証シナリオに沿って、アプリケーションのスループットおよ

びサービスタイム（レスポンスタイム）を観察します。

④ ランタイム接続ロードバランシングが働く

→ 追加したノードのコネクションの使用率を上げ、Oracle

RAC リソースの利用が改善される

⑤ 全体のスループットが上昇する

→ ロードバランシング・アドバイザの情報に従い、適切な Oracle

リスナーへリダイレクト

→ 結果、新たに srvA サービスへ追加したインスタンスに接続

するコネクションが増加

srvA サービスに dell4 インスタンス（d02-0e）を追加

→ UP イベントがアプリケーション・サーバー側へ通知され、

新規コネクションの生成を開始

※ dell1/dell2/dell3 の 3 つのインスタンスに srvA を割り当てた状態

① アプリケーション・サーバーを起動し、初期コネクションの生成

② アプリケーションから srvA サービスに接続し、データベースに負

荷をかける。このとき、d02-0b/d02-0c/d02-0d の 3 つのノードで

CPU 使用率が 100%に近い状態とする。

③ X 分後、

★ 予想されるスループットイメージ

ランタイム接続ロードバランシング


ロードバランス・プロパティの設定として、以下の GOAL、CLB_GOAL

の組み合わせで動作確認を行いました。

この検証では、以下の観点を目的とします。

① 予想したスループットイメージになるか

② サービス構成変更に伴う既存コネクションへの影響は無いか

№ CLB_GOAL GOAL

1 SHORT THROUGHPUT

2 SHORT SERVICE_TIME

3 LONG NONE

4 LONG THROUGHPUT

5 LONG SERVICE_TIME


4.2.3. 検証結果 1）スループットおよびサービスタイム

結果、予想通りのスループットグラフとなりました。

GOAL パラメータが NONE(ランタイムロードバランスしない)の場合、

スループットに変化はありませんでしたが、NONE 以外に設定した場合

は、ロードバランシング・アドバイザに従って、自然にスループットが

上昇（サービスタイムは減少）することを確認しました。

ランタイム接続ロードバランシングにより、スループット

が自然に上昇していく

ランタイム接続ロードバランシングにより、サービスタ

イム（レスポンス時間）が自然に減少していく

今回検証で使用したアプリケーションでは、「LONG-SERVICE_TIME」

設定の場合のパフォーマンスが一番良いようです。上段の「スループッ

トの変化」グラフでは、いち早くスループットが上昇していることが確

認できます。

また、CLB_GOAL の「LONG」「SHORT」の比較では、「LONG」の方

が良い結果となっています。

2）既存コネクションへの影響

サービスを再構成した前後で、クライアントにはエラーは返っていま

せんでした。このことから、サービスへのノード追加は既存コネクショ

ンへの影響を与えることなく行うことができ、ランタイム接続ロードバ

ランシングによるスループットの向上が期待できます。


5. 総括

本検証により、Oracle Application Server 10g と Oracle Real Application Clusters 10g の有効

性の一面が示せたと考えています。Fast Connection Failover（高速接続フェイルオーバー）

とランタイム接続ロードバランシングにより、データベース・サーバーのリソース再配置

が自動的に適化されます。これにより、データベース・サーバーの障害時、高負荷時に

おいて、エンドユーザー、システム管理者の双方にメリットが出てきます。

・エンドユーザー

FCF により、SQL 結果待ちの中にデータベース・サーバーに障害が発生しても、

長時間待たされることはありません。それ以外のタイミングでも、生存しているノー

ドに接続されるので、データベース・サーバーの障害を意識する必要がありません。

また、Oracle RAC のノード間に負荷の偏りが発生した場合は、ランタイム接続ロ

ードバランシングにより、コネクション使用率の適化が自動で行われることで、レ

スポンス時間の急激な悪化を避けることができます。

・管理者

FCF とランタイム接続ロードバランシングを事前に設定しておくことで、突発的

な負荷の増加に対しても柔軟に対応することできます。

また、Oracle RAC リソースを有効に利用できるという点で、ハードウェアコストを抑え

るといった、高い費用対効果もメリットのひとつに挙げられます。


ソリッドスクエア東館 20F

デル株式会社

〒212-8589 神奈川県川崎市幸区堀河町 580 番地

ニューオータニガーデンコート

日本オラクル株式会社

〒102-0094 東京都千代田区紀尾井町 4-1

新宿マインズタワー

EMC ジャパン株式会社

〒151-0053 東京都渋谷区代々木 2-1-1

Copyright © 2007 Oracle Corporation Japan. All Rights Reserved.

Copyright © 1999-2007 Dell Inc.

© Copyright 2007 EMC Corporation. All rights reserved.

無断転載を禁ず

このドキュメントは単に情報として提供され、内容は予告なしに変更される場合があり

ます。このドキュメントに誤りが無いことの保証や、商品性又は特定目的への適合性の黙

示的な保証や条件を含め明示的又は黙示的な保証や条件は一切無いものとします。日本オ

ラクル株式会社は、このドキュメントについていかなる責任も負いません。また、このド

キュメントによって直接又は間接にいかなる契約上の義務も負うものではありません。こ

のドキュメントを形式、手段（電子的又は機械的）、目的に関係なく、日本オラクル株式

会社の書面による事前の承諾なく、複製又は転載することはできません。

Oracle、JD Edwards、PeopleSoft、及び Siebel は、米国オラクル・コーポレーション及びその

子会社、関連会社の登録商標です。その他の名称は、各社の商標または登録商標です。


oracle grid とdell poweredge による サーバーリソースの自動的 … · as oracle...

Documents

oracle grid とdell poweredge によるサーバーリソースの自動的 … · as oracle...