85
1
1
2
3
RAC 11g R2 では、データベースからインフラストラクチャに 適化の範囲を広げるため、物理サ バ に対する制限を排除し RAC デ タベ スやアプリケ シ ンを柔軟に配置可能な仕サーバーに対する制限を排除し、RAC データベースやアプリケーションを柔軟に配置可能な仕組みを提供します。Oracle Clusterware は、Oracle Grid Infrastructure の一部です。
4
従来は、システム (データベース) ごとにリソースの 適化を行っていました。一方、データセン
タ のような多くのシステムを扱う場合 個々のシステム管理や ドウ ア資産は非常に大きターのような多くのシステムを扱う場合、個々のシステム管理やハードウェア資産は非常に大きなコストになり、運用も複雑になります。企業はデータセンターインフラストラクチャを進化させながら、増え続けるビジネス要求に柔軟に対応していく必要があります。そのためには、可用性、拡張性、柔軟性に優れたインフラ ストラクチャの構築が必要です。
5
サード・パーティ製アプリケーションやデータベースを同じクラスタ配下で稼動させることが可能です 様々なシステムを同じクラスタ化されたインフラストラクチ に配置します 結果として 以です。様々なシステムを同じクラスタ化されたインフラストラクチャに配置します。結果として、以下の効果が期待できます。
• 専用のサーバーを削減
• 低コストなインフラストラクチャで実現するデータセンター
• 運用の標準化
6
Oracle Clusterware は、サーバー・プールで定義されたポリシーに基づいて、サーバーを自動的に割り当てます ポリシ には サ バ の数や重要度が含まれます的に割り当てます。ポリシーには、サーバーの数や重要度が含まれます。
サーバー・プール
サーバー・プールは、サーバーを仮想化する機能です。RAC 11g R2 では、データベースやアプリケーションを物理サーバーに配置するではなく、「サーバー・プール」 に配置します (データベースやアプリケーションは、サーバー・プールに紐付く)。サーバー・プールでサーバーを仮想化することで、RAC データベースと物理サーバーの関係を排除し、RAC データベースを柔軟にクラスタ配下の任意のサーバー上に配置することが可能です。にクラ タ配下の任意のサ に配置する とが可能です。
7
8
9
ポリシーベース管理のメリット
• より低コストなハートウェアで実現 (コスト削減)• システムリソースの柔軟な活用と利用率の 適化
• ワークロードの変動にも柔軟に対応
• 障害時のサーバー自動割り当て
• サービスの配置ノードを意識する必要性の排除
10
11
サーバー・プールの確認方法
srvctl コマンドを利用して作成済みのサーバー・プールを確認できます。(４ ノードのクラスタ環境)
--サーバー・プールの作成
$ srvctl add srvpool -g racdb -l 2 -u 2 -i 1$ srvctl add srvpool -g apps -l 1 -u 1 -i 1
--サーバー・プールの状態を確認
$ srvctl status srvpoolサーバー・プール名: Freeアクティブ・サーバー数: 1サーバー・プール名: Genericアクティブ・サーバー数: 0サーバー・プール名: appsアクティブ・サーバー数: 1サーバー・プール名: racdbアクティブ・サーバー数: 2
4 個のサーバー・プールが存在
「Generic」 と 「Free」 はデフォルトで作成されるサーバー・プールです。 「racdb」 と 「apps」 はユーザー定義のサーバー・プールです。 「racdb」 には、2 個のサーバーを割り当て、「apps」には、1個のサーバーが割り当てられていることが確認できます。現在利用されていないサーバー (Free プールに配置) も１個あります。
アクティブ・サーバー数: 2
アクティブ・サーバー数 : 現在、サーバー・プールに割り当てられているサーバーの数
12
サーバー・プールの属性を確認する方法
srvctl config srvpool –g <pool_name> を実行することで、サーバー・プールの属性情報を確認できます。
$ srvctl config srvpool -g racdbサーバー・プール名: racdb重要度: 1、 小: 2、 大: 2候補サーバー名:
小 : サーバー・プールに含まれるサーバーの 小数
大 : サーバー・プールに含まれるサーバーの 大数
候補サーバー名 : サーバーを配置する候補ノード名のリスト。
空の場合は、どのサーバーも割り当て可能
13
14
srvctl status srvpool コマンドの結果項目の意味
項目 説明
サーバー・プール名 サーバー・プール名
アクティブ・サーバー数 現在、割り当てられているサーバーの数
アクティブ・サーバー名 現在、割り当てられているサーバー名のリスト
NAME サーバーの状態
「サーバー」 の管理
RAC 11g R2 では、サーバーもリソース管理されます。これにより、サーバー・プールの割り当
て状況やクラスタとしてのサーバーの状態を管理しています。サーバーの状態を確認するためには、以下のコマンドで確認可能です。
$ srvctl status server -n serv1 -aサーバー名: serv1
サーバーの状態には、次の状態があります。
• ONLINE• OFFLINE• JOINING
サーバーの状態: ONLINEアクティブなサーバー・プール: ora.pool1サーバーの状態の詳細:
15
• LEAVING• VISIBLE• RECONFIGURING
Oracle Clusterware インストール後の状態
デフォルトで、「Generic」 と 「Free」 というサーバー・プールが作成されます。Oracle Clusterware インストール直後は、まだ、データベースは作成されていないため、全サーバーは、Free プールに配置されます。
$ srvctl status srvpoolサーバー・プール名: Freeアクティブ・サーバー数: 4 全てのサーバーが Free プールに存在
サーバー・プール名: Genericアクティブ サ バ 数: 0
RAC One NodeRAC One Node は、11g R2 Enterprise Edition の新しいオプションです。RAC One Node は、シングルインスタンスとして稼動するものの、Oracle Clusterware と統合することで以下の機能を提供します。
• サーバーをまたがったインスタンスのライブマイグレーション
アクティブ・サーバー数: 0
• ローリングパッチ
• クラスタに組み込まれた自動フェイルオーバー
• オンラインで RAC にアップグレード
RAC One Node は、Generic プールに配置された管理者管理データベースとして作成しますが、HA やサーバー間の移動を可能にするよう構成されます。
16
17
クラスタ管理者
クラスタ管理者は、サーバー・プールの作成が可能です。デフォルトでは、どの OS ユーザでもサーバー・プールの作成が可能です。これは、OS グループ (oinstall / dba グループの有無) に依存しません。クラスタ管理者の設定を行うことで、サーバー・プールの管理および、サーバー・プールへのリソース配置のアクセス制御が可能になります。root ユーザは、クラスタ管理者の設定に依存せず、全サーバー・プールのアクセス権限を持っています。
18
19
RAC 11g R2 では、「管理者管理」 と 「ポリシー管理」 の構成タイプがあり、RAC データベースを配置するサ バ プ ルが異なります RAC デ タベ スの作成は DBCA もしくは スクを配置するサーバー・プールが異なります。RAC データベースの作成は、DBCA もしくは、スクリプトで構築可能です。ASM インスタンスは、クラスタを構成する全サーバー上で稼動するため、ASM インスタンスはサーバー・プールに配置しません。
管理者管理とポリシー管理の使い分け
構成タイプ 適したシステム
管理者管理 • 単一のデータベースを考慮するなら、管理者管理でも充分• UNIX サーバー / ハイエンドのサーバーで構築するシステム
•シビアなレスポンスが要求されるシステム•高トランザクションのシステム
• 高度な管理が要求されるシステム
ポリシー管理 • データセンター全体としてサーバーリソースを有効活用したいシステム低コストなサ バ (IA サ バ ) で構築するシステム• 低コストなサーバー (IA サーバー) で構築するシステム
• システム統合、運用の標準化を促進したいシステム
20
DBCA の注意事項
DBCA では、下記の場合、警告メッセージがポップアップされます。
管理者管理
指定したサーバーが、既に他のサーバー・プールに割り当てられている場合
ポリシー管理
指定されたカーディナリティに対して、サーバーの数が不足している場合
DBCA でポリシー管理データベースを削除しても サーバー・プールは残ります サーバー・プDBCA でポリシ 管理デ タベ スを削除しても、サ バ プ ルは残ります。サ バ プールも削除する場合は、明示的に srvctl でサーバー・プールを削除してください。
21
DBCA でサーバーを選択することで、そのサーバー上でのみ RAC インスタンスが起動します。例えば、サーバーを 2 個選択した場合は 2 ノード RAC データベースが作成されますサーバーを 2 個選択した場合は、2 ノード RAC データベースが作成されます。
下記は、管理者管理で作成した RAC データベースの設定確認の例です。
$ srvctl config database -d orcl一意のデータベース名: orclデータベース名: orclOracleホーム: /opt/oracle/dbOracleユーザー: oraclespfile: +DG1/orcl/spfileorcl oraspfile: +DG1/orcl/spfileorcl.oraドメイン: world開始オプション: open停止オプション: immediateデータベース・ロール: PRIMARY管理ポリシー: AUTOMATICサーバー・プール: orclデータベース・インスタンス: orcl1,orcl2ディスク・グループ: DG1サービス:データベースは管理者によって管理されています ← 管理者管理の DB
22
DBCA でポリシー管理の RAC データベースを作成する場合は、上記の画面で指定した RAC を配置するためのサ バ プ ルも自動的に作成されます 例えば カ ディナリティを 「2」を配置するためのサーバー・プールも自動的に作成されます。例えば、カーディナリティを 「2」と指定した場合は、2 ノード RAC データベースが作成されます。
下記は、ポリシー管理で作成した RAC データベースの設定確認の例です。
$ srvctl config database -d orcl一意のデータベース名: orclデータベース名: orclOracleホーム: /opt/oracle/dbOracleユ ザ : oracleOracleユーザー: oraclespfile: +DG1/orcl/spfileorcl.oraドメイン: world開始オプション: open停止オプション: immediateデータベース・ロール: PRIMARY管理ポリシー: AUTOMATICサーバー・プール: pool1データベース・インスタンス:
既存のサーバー・プールの選択では、Generic サーバー・プールおよび、ネストされたサーバー・プールの選択はできません。
ディスク・グループ: DG1サービス:データベースはポリシーによって管理されています ← ポリシー管理の DB
23
srvctl add database 時に、CRS リソースとしてデータベースの登録を行い、RAC データベースを G i サ バ プ ルに自動的に配置します tl dd i t 時にサ バ 名をスを Generic サーバー・プールに自動的に配置します。srvctl add instance 時にサーバー名を指定することで、Generic サーバー・プールにサーバーが確保されます。スライドの例実行後のサーバー・プールの状態は次の通りです。
$ srvctl status srvpool –aサーバー・プール名: Freeアクティブ・サーバー数: 2アクティブ・サーバー名: serv3,serv4NAME=serv3 STATE=ONLINENAME=serv3 STATE=ONLINENAME=serv4 STATE=ONLINEサーバー・プール名: Genericアクティブ・サーバー数: 2アクティブ・サーバー名: serv1,serv2NAME=serv1 STATE=ONLINENAME=serv2 STATE=ONLINE
Generic に 「serv1」 と 「serv2」 の
サーバーが割り当てられていることを確認
24
srvctl add srvpool 時に、サーバー・プールの作成と、サーバーの割り当てが行われます。tl dd d t b 時に CRS リソ スとしてデ タベ スの登録が行われ RAC デ タデsrvctl add database 時に、CRS リソースとしてデータベースの登録が行われ、RAC データデ
ータベースをサーバー・プールに配置します。スライドの例実行後のサーバー・プールの状態は次の通りです。
$ srvctl status srvpool –aサーバー・プール名: Freeアクティブ・サーバー数: 2アクティブ・サーバー名: serv3,serv4NAME=serv3 STATE=ONLINENAME=serv3 STATE=ONLINENAME=serv4 STATE=ONLINEサーバー・プール名: Genericアクティブ・サーバー数: 0アクティブ・サーバー名:サーバー・プール名: pool1アクティブ・サーバー数: 2アクティブ・サーバー名: serv1,serv2NAME=serv1 STATE=ONLINE
サーバー・プール 「pool1」 が作成され、
「serv1」 と 「serv2」 のサーバーが
割り当 られ る とを確認NAME=serv2 STATE=ONLINE 割り当てられていることを確認
25
26
srvctl modify service コマンドを使用して、UNIFORM と SINGLETON を切り替えることも可能ですです。
27
RAC 11g R1 までは、srvctl でサービスを作成した場合、一部の機能 (ロード・バランシング・アドバイザなど) を有効化するために DBMS SERVICE MODIFY SERVICE プロシ ジャを使ドバイザなど) を有効化するために、DBMS_SERVICE.MODIFY_SERVICE プロシージャを使って別途設定をしていました。EM Database Control でサービスを作成する場合は不要です。
RAC 11g R2 では、上記のスライドの通り、srvctl で設定可能なオプションが追加されました。
ポリシー管理データベースでは、-P オプションを指定した TAF ポリシーの設定は不可です。
28
CRSCTL と SRVCTL の使い分け
通常、RAC データベースを配置するサーバー・プールおよび、組み込み CRS リソース (「ora」という接頭辞が付くサーバー・プールおよび、リソース) を管理する際は、SRVCTL を使用してください。アプリケーション用のサーバー・プールおよび、リソースの管理は、CRSCTL を使用します。
crsctl でもデータベースやサービスが起動されているサーバーや状態を確認することも可能ですが、サーバー・プールの縮小 ( 大数の変更) を行うと、下記のように余分なメンバーのエントリが残ったまま出力されます。(4 ノードクラスタ上で、2 ノード RAC が稼動している例)トリが残 たまま出力されます。( ドクラ タ で、 ド が稼動して る例)
$ crsctl status resource -t...ora.orcl.db
1 ONLINE ONLINE serv1 Open2 ONLINE ONLINE serv2 Open3 ONLINE OFFLINE Instance Shutdown
これは、今後の拡張のためにエントリを残しています。直接エントリを削除するコマンドはありません。srvctl remove database / srvctl add database コマンドを使用して、DB リソースを再作成することでエントリを削除することは可能です。
3 ONLINE OFFLINE Instance Shutdownora.orcl.srv_a.svc
1 ONLINE ONLINE serv12 ONLINE ONLINE serv23 ONLINE OFFLINE
...
2 ノード RAC にも関わらず
メンバーのエントリが3個出力される
(以前は 3 ノード RAC)
29
30
ポリシー管理は、特定のサーバーを管理するのではなく、サービスを提供するカーディナリティ(サ バ の数) を指定することで サ バ のキャパシティ管理を行います RAC デ タベ(サーバーの数) を指定することで、サーバーのキャパシティ管理を行います。RAC データベースやサービスもカーディナリティに基づいて動的に稼動します。
小数=1 のサーバー・プール上に RAC データベースを配置した場合は、1 ノード RAC として構成可能です。
31
32
33
データベースを作成すると、 CRS リソースにデータベースの登録は行われるものの、自動的に開始はされません デ タベ スを開始 (インスタンスを起動) するためには 下記のコマンドを開始はされません。データベースを開始 (インスタンスを起動) するためには、下記のコマンドを実行する必要があります。
$ srvctl start database -d orcl
34
サービスを作成すると、CRS リソースにサービスの登録は行われるものの、自動的に開始はされません サ ビスを開始するためには 下記のコマンドを実行する必要がありますれません。サービスを開始するためには、下記のコマンドを実行する必要があります。
$ srvctl start service -d orcl -s OLTP$ srvctl start service -d orcl -s BATCH$ srvctl start service -d orcl -s CRM
35
サーバー・プールの 大数を変更することで、自動的に、RAC インスタンスおよび、サービスの拡張も行われます拡張も行われます。
サーバー・プールの拡張 / 縮小時は、RAC 再構成が伴うため、RAC 再構成時に若干パフォーマンスが劣化する可能性があります。
36
srvctl modify srvpool コマンドでサーバー・プールの縮小を実行する際、そのサーバー上でRAC インスタンスやアプリケ シ ンが稼動していると エラ が発生しますRAC インスタンスやアプリケーションが稼動していると、エラーが発生します。
強制的に、RAC インスタンスやサービスを停止したい場合
-f オプションを指定することでサーバー・プールの縮小を実行することができます。この場合、Free プールに返されるサーバー上の RAC インスタンスは shutdown immediate が実行されます。サーバー・プールから排除されるサーバーは Oracle Clusterware が自動的に決定します。
明示的に Free プールに返すサーバーを指定したい場合
以下のように、そのサーバー上で稼動している RAC インスタンスを停止させた後、そのサーバーを Free プールに再配置することも可能です。(サーバー stvm5 上で、RAC インスタンスorcl_5 が起動しているとします)
$ srvctl modify srvpool -g pool1 -u 4 –f $
1. orcl_5 インスタンスの停止
$ srvctl stop instance -d orcl -i orcl_52. サーバー (stvm5) を Free プールに手動配置
$ srvctl relocate server -n stvm5 -g Free３．サーバー・プールの縮小
$ srvctl modify srvpool -g pool1 -u 4
37
38
39
RAC One NodeRAC One Node は、11g R2 Enterprise Edition の新しいオプションです。RAC One Node は、シングルインスタンスとして稼動するものの、Oracle Clusterware と統合することで以下の機能を提供します。
• サーバーをまたがったインスタンスのライブマイグレーション
• ローリングパッチ
• クラスタに組み込まれた自動フェイルオーバー
• オンラインで RAC にアップグレード
RAC One Node は、DBCA で Generic プールに配置された管理者管理データベースとして作成後、オラクル提供のスクリプトにより、HA やサーバー間の移動を可能にするよう構成されます。
40
41
サーバー・プールのポリシー属性を基に、Oracle Clusterware が自動的にサーバーの割り当てを行います 割り当てるサ バ の選択には ハ ドウ アの性能差は考慮していませんてを行います。割り当てるサーバーの選択には、ハードウェアの性能差は考慮していません。
42
パフォーマンス (サービス品質) を考慮したポリシー管理
RAC 11g R2 のポリシー管理は、サーバー・プールの管理および、サーバー障害時におけるサ
ーバーの自動割り当てを実現しているものの、パフォーマンスを考慮したサーバーの自動割り当て (レスポンス低下が見られる場合は自動的にサーバー追加など) の機能は実装されていま
せん。そのため、サービス品質によるポリシー管理を実現させるためには、レスポンス監視を行い、しきい値を下回るとサーバー・プールを拡張するスクリプトを実行するなどの仕組みを別途実装する必要があります。
43
44
サーバー割り当てのアルゴリズム
1. サーバーの割り当ては、Generic サーバー・プールから行われます。
2. Generic サーバー・プールで管理するサーバーでない場合は、ユーザー定義サーバー・プールへの割り当てを考慮します。
3. 小数を満たしていないサーバー・プールの中で、重要度の高いサーバー・プールから小数を満たすまでサーバーの割り当てを行います。サーバーの数が不足している場合、サーバー・プールの 小数を下回ることもあります。
4. 全てのサーバー・プールの 小数を満たしている場合、 大数を満たしていないサーバー・プールの中で 重要度の高いサーバー・プールから 大数を満たすまでサーバーのー・プールの中で、重要度の高いサーバー・プールから 大数を満たすまでサーバーの
割り当てを行います。サーバーの数が不足している場合、サーバー・プールの 大数を下回ることもあります。
5. 全てのユーザー定義サーバー・プールの 大数を満たしている場合、Free プールにサーバーが配置されます。
補足事項
• Generic サーバー・プールに配置されているサーバーを他のサーバー・プールが割り当てGeneric サ バ プ ルに配置されているサ バ を他のサ バ プ ルが割り当てることはありません。Generic の場合、 小数 / 大数/ 重要度は考慮する必要はありません。
• デフォルトは、 小数=0 / 重要度=0 のため、Free プールにサーバーが存在している限り、全てのサーバー・プールが 大数を満たすようにサーバーが割り当てられます。
• 小数=0 のサーバー・プールが他のサーバー・プールからサーバーを割り当てることはありません。 小数を下回ることはないためです。
• 小数は下限値ではありません。他に重要なサーバー・プールがある場合は、 小数を下回る ともあります
45
回ることもあります。
46
47
48
初期状態
初期状態は、全てのサーバーが Free プールに配置されています。サーバーを割り当てる際は、
小数を満たしていないサーバー・プールの中で、重要度の高いサーバー・プールからサーバーの割り当てを行います。サーバーの数が不足している場合、サーバー・プールの 小数を下回ることがあります。
SP4 の縮小
サーバー・プールを縮小させることで、サーバーの割り当ての検討がされます。SP1 は、 小数を満たしていないため SP1 にサーバーが割り当てられます数を満たしていないため、SP1 にサーバーが割り当てられます。
49
サーバーの手動割り当てが失敗するケース
以下のケースでは、srvctl relocate server コマンドはエラーになります。サーバーを手動で割り当てる際は、以下の条件に該当しないことを確認してください。
• そのサーバー上で RAC インスタンスが稼動している場合 (-f オプションなし)• 移動元のサーバー・プールの 小数を下回る場合
• 移動先のサーバー・プールの 大数を超える場合
上記、2点目、3点目は –f オプションを指定してもエラーになります。その場合は、 小数 / 大数を変更することで対応してください。
補足事項
• 大数を満たしていないサーバー・プールが存在しても、Free プールに配置することは可能
• Free プールに配置されたサーバーは、サーバー障害時やサーバー・プール変更時などのタ
イミングで他のサーバー・プールに割り当てられる可能性があるため、どのサーバー・プールにも利用させたくない場合は、一時的に配置するサーバー・プールを作成してそちらに退避することをお奨めします
50
51
52
53
1つのサーバー・プールに複数のデータベースを配置
1つのサーバー・プールを複数のデータベースで共有することは可能です。サーバー・プールの拡張 / 縮小を行うと、全てのデータベースで RAC インスタンス数が増減します。
複数のサーバー・プールに1つのデータベースを配置
データベースは複数のサーバー・プール上に配置することはできるものの、サービスは1つサーバー・プールのみ配置可能です。RAC インスタンス間でサービスを分離したい場合は、サーバー・プールを複数作成し、それぞれにサービスの紐付けを行います。DBCA でもポリシー管理選択時に 複数のサーバー・プールが選択可能になっています選択時に、複数のサーバー・プールが選択可能になっています。
srvctl コマンドで作成する場合は、以下のような指定になります。
-- サーバー・プールの作成
srvctl add srvpool -g pool1 -u 2srvctl add srvpool -g pool2 -u 2
-- 複数のサーバー・プールを指定したデータベースの作成
複数指定
srvctl add database -d orcl -o /opt/oracle/db -g pool1,pool2
54
候補サーバーを指定すると、そのサーバー・プールは、候補サーバーからしかサーバーの割り当てを行いません そのため サ バ プ ルごとに候補サ バ を指定することでサ バ当てを行いません。そのため、サーバー・プールごとに候補サーバーを指定することでサーバー・プールに割り当てられるサーバーを分離することが可能です。ただし、候補サーバーを指定しない他のサーバー・プールが存在する場合、 小数 / 重要度に応じてサーバーが奪われる
可能性があるため注意してください。候補サーバーの指定は、他のサーバー・プールに割り当てられることを防ぐものではありません。
サーバー・プールに割り当て可能なサーバーを制限する方法
srvctl add srvpool のオプション 「-n」 で割り当てるサーバーをリストすることで、サーバー・プーp のオ ション 」 で割り当てるサ をリ トする とで、サルに割り当て可能なサーバーを制限することができます。
$ srvctl add srvpool -g pool1 -l 0 -u 2 -i 5 –n serv1,serv2$ srvctl config srvpool -g pool1サーバー・プール名: pool1重要度: 5、 小: 0、 大: 2候補サーバー名: serv1,serv2
候補サーバー名 : サーバーを配置する候補ノード名のリスト。
空の場合は、どのサーバーも割り当て可能
55
Free プールの属性は、重要度 (IMPORTANCE) と権限 (ACL) のみ変更可能です。 小数 / 大数などの他の属性は変更することはできません F プ ルの 小数 / 重要度のデフォ大数などの他の属性は変更することはできません。Free プールの 小数 / 重要度のデフォ
ルトは 0 なので、全てのサーバー・プールに対して割り当て可能です。以下のように、Free プールの重要度を変更することが可能です。
$ srvctl config srvpool -g Freeサーバー・プール名: Free重要度: 0、 小: 0、 大: -1候補サーバー名:
$ srvctl modify srvpool -g Free -i 10 ← 重要度を 10 に設定
$ srvctl config srvpool -g Freeサーバー・プール名: Free重要度: 10、 小: 0、 大: -1候補サーバー名:
56
57
58
従来の接続時フェイルオーバーおよび、クライアント・サイド・ロード・バランシングのt の設定例tnsnames.ora の設定例
ORCL =(DESCRIPTION =(LOAD_BALANCE=on)(FAILOVER=on)(ADDRESS = (PROTOCOL = TCP)(HOST = vip1)(PORT = 1525))(ADDRESS = (PROTOCOL = TCP)(HOST = vip2)(PORT = 1525))(ADDRESS = (PROTOCOL = TCP)(HOST = vip3)(PORT = 1525))(ADDRESS = (PROTOCOL = TCP)(HOST = vip4)(PORT = 1525))
VIP アドレスを
複数指定
従来のサーバー・サイド・ロード・バランシングの tnsnames.ora の設定例
(ADDRESS (PROTOCOL TCP)(HOST vip4)(PORT 1525))(CONNECT_DATA = (SERVICE_NAME = srv_a.world))
)
LISTENERS_ORCL =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = vip1)(PORT = 1525))(ADDRESS = (PROTOCOL = TCP)(HOST = vip2)(PORT = 1525))(ADDRESS = (PROTOCOL = TCP)(HOST = vip3)(PORT = 1525))(ADDRESS = (PROTOCOL = TCP)(HOST = vip4)(PORT = 1525))
)
VIP アドレスを
複数指定
59
従来の課題
クライアント側
• 接続時フェイルオーバーもしくは、クライアント・サイド・ロードバランシングを利用する場合は、tnsnames.ora に全ノードの VIP アドレスをリストする必要があった
• ノードの追加 / 削除の度に、全クライアントの tnsnames.ora を編集する必要があった
サーバ側
• サーバー・サイド・ロードバランシングを利用している (初期化パラメータREMOTE_LISTENER を設定) 場合、ノード追加 / 削除の度に、全ノードの tnsnames.ora を編集する必要があ たを編集する必要があった
60
DNS へ SCAN の登録
1つの名前に 3 個の IP アドレスを DNS サーバに事前に登録します。下記は、「grid1.jp.oracle.com」 という名前に、3 個の IP アドレスを登録した例です。 DNS ラウンドロビンにより、nslookup で表示される IP アドレスの順番は毎回異なります。
# nslookup grid1.jp.oracle.comServer: xxx.xxx.xxx.54Address: xxx.xxx.xxx.54#53
DNS サーバを使用しない場合の SCAN の使用
Name: grid1.jp.oracle.comAddress: xxx.xxx.xxx.100Name: grid1.jp.oracle.comAddress: xxx.xxx.xxx.101Name: grid1.jp.oracle.comAddress: xxx.xxx.xxx.102
DNS サーバを使用しない場合の SCAN の使用
RAC 11g R2 では、DNS サーバの使用が必須です。クラスタを構成する各サーバーの/etc/hosts に SCAN の IP アドレスを設定することは可能なものの、解決可能な IP アドレスは１つのみです。そのため、DNS サーバを使用できない環境での /etc/hosts への記述は、テスト環境のみとしてください。SCAN を DNS サーバに登録した場合は、/etc/hosts には SCAN のIP アドレスを記述しないようにしてください。
SCAN に登録する IP アドレスの数
61
SCAN に登録する IP アドレスはクラスタを構成するサーバーの数に依存せず、常に３個です。2 ノード RAC 環境でも、今後の拡張性を考慮して、３個の IP アドレスを登録してください。
クラスタ用 Grid Infrastructure インストール
クラスタ用 Grid Infrastructure インストールは、RAC 11g R2 から導入された Oracle Clusterware と ASM を統合したインストールです。RAC 11g R2 では、Oracle Clusterware をインストールする場合、クラスタ用 Grid Infrastructure インストールを選択します。
１つのクラスタ環境で構成可能な SCAN は１つのみです。複数の SCAN を作成することはできません。
62
SCAN VIP と SCAN リスナーは、SCAN 名で解決される各 IP アドレスに対応しています。SCAN 名には 3個の IP アドレスが DNS に登録されているため 3 個の SCAN VIP とSCAN 名には、3個の IP アドレスが DNS に登録されているため、3 個の SCAN VIP とSCAN リスナーの CRS リソースが作成されます。SCAN VIP / SCAN リスナーのリソースの数は、クラスタを構成するサーバーの数に依存しません。
下記は、srvctl コマンドを利用して、SCAN VIP と SCAN リスナーの構成を確認した例です。
$ srvctl config scanSCAN名: grid1、ネットワーク: 1/10.185.144.0/255.255.248.0/eth0gSCAN VIP名: scan1、IP: /grid1.jp.oracle.com/ xxx.xxx.xxx.100SCAN VIP名: scan2、IP: /grid1.jp.oracle.com/ xxx.xxx.xxx.101SCAN VIP名: scan3、IP: /grid1.jp.oracle.com/ xxx.xxx.xxx.102
$ srvctl config scan_listenerSCANリスナーLISTENER_SCAN1は存在します。ポート: TCP:1521SCANリスナーLISTENER_SCAN2は存在します。ポート: TCP:1521SCANリスナーLISTENER_SCAN3は存在します。ポート: TCP:1521
３ 個の SCAN VIP
３ 個の SCAN リスナー
VIP とデフォルト・リスナー
従来の VIP とデフォルト・リスナーは、クラスタ用 Grid Infrastructure インストール後に、クラスタを構成する全サーバー上で自動的に構成されます。RAC 11g R2 でも VIP とデフォルト・リスナーは必須です。
63
JDBC で簡易接続ネーミング・メソッドを使用した SCAN を利用する場合
JDBC Thin ドライバで SCAN を使用した接続を行う場合は、以下のように指定します。
簡易接続ネーミング・メソッドは、10g から利用可能ではあるものの、ホスト名の指定は1つのみです。そのため、接続時フェイルオーバーの設定を行うことはできませんでした。RAC 11g R2 では、接続時フェイルオーバーの機能を備えた SCAN を利用することで、RAC データベース
の接続でも簡易接続ネ ミング メ ドが利用可能にな ています
jdbc:oracle:thin:@grid1:1521/srv_a.world
への接続でも簡易接続ネーミング・メソッドが利用可能になっています。
下位バージョンのクライアントで SCAN を使用する場合
11g R1 / 10g R2 などの下位バージョンのクライアントで SCAN を利用した接続を行う場合は、tnsnames.ora に以下のように SCAN VIP をリストした形でご利用ください。
ORCL =(DESCRIPTION =(LOAD_BALANCE=on)(ADDRESS = (PROTOCOL = TCP)(HOST = xxx.xxx.xxx.100)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = xxx.xxx.xxx.101)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = xxx.xxx.xxx.102)(PORT = 1521))(CONNECT_DATA =(SERVICE_NAME = srv_a.world)
))
SCAN VIP をリスト
64
下位バージョンのクライアントの場合は、簡易接続ネーミング・メソッドで SCAN を指定
した際の接続に完全に対応していないためです。(複数 IP アドレスを展開した接続文字列の生成は不可)
)
SCAN を使用した接続の流れ
1. DNS サーバにより、SCAN 名から3個の SCAN VIP を取得
2. SCAN リスナーに対して接続リクエストを送信
3. SCAN リスナーはサービスが稼動している接続先情報をクライアントに送信 (接続のリダイレクト)4. クライアントは接続先サーバーのデフォルトリスナーを介してデータベースに接続
そのため、SCAN を利用した接続においても、VIP やデフォルトリスナーは利用されています。
65
VIP と接続時フェイルオーバーについて
RAC 11g R1 までは、VIP を利用して RAC データベースに接続していました。ノード障害時では、VIP はフェイルオーバーするものの、リスナーはフェイルオーバーしないため、クライアントからの接続要求は、「ORA-12541: TNS: リスナーがありません。」 のエラーが返されます。これは、ダウンしたノードに対する接続が TCP タイムアウトを待ってしまうことを避けるためにVIP が導入されており、早期にクライアントにエラーを返すことを目的としているためです。そのため、このエラーを受けて正常なノード上で稼動する VIP に自動的に再接続を試みる接続時フェイルオーバーの設定を行うこともありました。
RAC 11g R2 (SCAN) を利用する場合は、自動的に、複数の SCAN VIP を使用した接続時フバ が 続 ド障害ェイルオーバーの設定が行われた状態で接続を行います。また、ノード障害などで、SCAN VIP
がフェイルオーバーした先でも、接続要求を処理できるため、接続時フェイルオーバーの明示的な設定は不要です。
66
(*1) SCAN により生成される接続文字列
DNS によって名前解決された SCAN VIP アドレスを取得すると、内部的に以下のような接続文字列に変換されます。(LOAD_BALANCE=off / FAILOVER=on)
(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=srv_a.world))(ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxx.xxx.102)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxx.xxx.100)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxx.xxx.101)(PORT=1521))
)
← 初の接続時に
試行される IP アドレス
初の IP アドレスに対して接続を試行し、失敗すれば、次のエントリにある IP アドレスに向けて接続を試行します。これにより、明示的な接続時フェイルオーバーの設定は不要になります。 終的に、どの RAC インスタンスに接続するかは、サーバー・サイド・ロード・バランシングにより決定されます。
(*2) クライアント・サイド・ロードバランシング
どの SCAN リスナーに対して接続リクエストを行うかは、DNS によって返される IP アドレスの順番に依存します。ただし、同一のクライアントマシンから連続で接続リクエストを行う場合は、DNS のキャッシュやプラットフォームに依存して、同じ IP アドレスの順番で SCAN を取得し、特定の SCAN リスナーに接続リプラットフォ ムに依存して、同じ IP アドレスの順番で SCAN を取得し、特定の SCAN リスナ に接続リ
クエストが偏る可能性があります。対応が必要な場合は、簡易接続ネーミング・メソッドではなく、tnsnames.ora で LOAD_BALANCE=on を指定して SCAN による接続をおこなってください。 終的に、どの RAC インスタンスに接続するかは、サーバー・サイド・ロード・バランシングにより決定されます。
ORCL =(DESCRIPTION =
(LOAD_BALANCE=on)(ADDRESS (PROTOCOL TCP)(HOST grid1)(PORT 1521))
67
(ADDRESS = (PROTOCOL = TCP)(HOST = grid1)(PORT = 1521))(CONNECT_DATA =
(SERVICE_NAME = srv_a.world))
)
LOCAL_LISTENER と REMOTE_LISTENERRAC 11g R2 の DBCA で RAC データベース (管理者管理 / ポリシー管理両方) を作成する際は、デフォルトで以下のように構成されます。
• LOCAL_LISNTENER (設定なし)• REMOTE_LISTENER=“<SCAN 名>:<ポート番号>“
LOCAL_LISTENER は、インスタンス起動時に、CRS エージェントによって動的に設定されます (初期化パラメータの設定は不要)。デフォルトリスナーには、ローカルで起動しているインスタン のサ ビ のみが登録されますタンスのサービスのみが登録されます。
REMOTE_LISTENER に SCAN を指定した設定はクラスタ内の全サーバーで共通、かつ、ノード追加 / 削除時も設定を変更する必要はありません。SCAN リスナーは、クラスタで稼動している全サービス (全インスタンス) への接続情報を保持しています。SCAN リスナーは、クラスタで稼動するサービスに接続するための 「中継リスナー」 の役割を担います。
デフォルトのロードバランシング
デフォルトでは以下の設定でサ ビスが作成されるため RAC インスタンス間で均等に接続をデフォルトでは以下の設定でサービスが作成されるため、RAC インスタンス間で均等に接続を割り振るようにバランシングを行います。
• CLB_GOAL=LONG• GOAL=NONE
68
高速接続フェイルオーバー
高速接続フェイルオーバーで使用するコネクション・キャッシュは、それぞれの物理コネクションがどのインスタンスに接続されているかを把握しています。
DOWN イベント
サービスやインスタンスに障害が発生すると DOWN イベントが送られます。コネクション・キャ
ッシュは、その障害に関連するインスタンスに接続されている物理コネクションをシャットダウンします。そのため、コネクション・キャッシュの中には有効なコネクションのみが残るようになります これにより アプリケーション・スレッドに無効なコネクションが渡されるのを防ぎますす。これにより、アプリケーション・スレッドに無効なコネクションが渡されるのを防ぎます。
UP イベント
サービスやインスタンスが起動すると UP イベントが送られます。コネクション・キャッシュはこの
新しいインスタンスに対して物理コネクションを生成します。インスタンスの起動に対し､アプリケーション・サーバー側では管理者は何も操作する必要はありません。新しいインスタンスに対しても自動的に負荷分散するようになります。
ランタイム接続ロード・バランシング
ランタイム接続ロード・バランシングは RAC 10g R2 で実装されたロードバランスです。Oracle クライアント側のコネクション・キャッシュから、クライアント・アプリケーションが取り出すコネクションの接続先を制御するものになります。ロード・バランシング・アドバイザによって負荷配分の割合が計算され、これが FAN イベントによってクライアントに伝播されます。クライアントのコネ
クション・キャッシュは、この負荷配分の指示に従って、クライアント・アプリケーションにコネクションを渡します。RAC を構成するハードウェアのスペックが異なる場合、高い性能を示すインスタンスに対して 多くリクエストが流れるように作用します
69
タンスに対して、多くリクエストが流れるように作用します。
70
71
72
73
サーバー・プールの属性 (詳細) を確認する方法
crsctl stat serverpool ora.<pool_name> -f コマンドで、詳細なサーバー・プールの属性情報を確認できます。crsctl コマンドを利用する場合は、サーバー・プール名の接頭辞に 「ora」 が付くことにご注意ください。
$ crsctl stat serverpool ora.racdb -fNAME=ora.racdbIMPORTANCE=1MIN_SIZE=2MAX SIZE=2MAX_SIZE=2SERVER_NAMES=PARENT_POOLS=EXCLUSIVE_POOLS=ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--ACTIVE_SERVERS=serv1 serv2
74
スライドの作業は、root ユーザもしくは、Grid Infrastructure インストールユーザで実施して下さい ユ ザ名に 「*」 (全ユ ザ) を指定する場合は ダブルクォ テ シ ンで囲 てくださいい。ユーザ名に 「*」 (全ユーザ) を指定する場合は、ダブルクォーテーションで囲ってください。
クラスタ管理者のグループに存在しない OS ユーザ (test1 ユーザ) で、サーバー・プールを作成しようとすると、以下のようなエラーが発生します。
$ srvctl add srvpool -g pool1 -l 2 -u 2 -i 1PRCS-1040 : ユーザーtest1にはCRS管理者ロールがありません
75
76
EM のトップ画面の [クラスタ] タブ - [管理] タブ - 「サーバー・プールの管理」 に移動します。
77
EM のトップ画面の [クラスタ] タブ - [管理] タブ - 「サーバー・プールの管理」 に移動します。移動先のサ バ プ ルを選択してから 「サ バ の移動」 ボタンをクリ クします動先のサーバー・プールを選択してから、「サーバーの移動」 ボタンをクリックします。
78
EM のトップ画面の [データベース] タブ - [可用性] タブ - 「クラスタ管理データベース・サービス」 に移動しますス」 に移動します。
79
「サービスの作成」 ボタンをクリックすると、サービス作成の画面が表示されます。
80
81
82
RAC 9.2 との共存について
Oracle Clusteware 11g R2 と RAC 9.2 は共存することは可能です。ただし、RAC 9.2 の要件通り、UNIX 環境では、ベンダー製クラスタウェアが必要です。Linux / Windows 環境では、Oracle Cluster Manager (ORACM) が必要になります。
83
8484
85
