Oracle Database 11g Release 2 Oracle Clusterware アーキテクチャ

1
2
本資料では、以下の省略表記を使用している箇所があります。
名称
省略表記
Oracle Local Registry
OLR
Oracle Cluster Registry
OCR
Grid Plug and Play (プロファイル)
GPnP (プロファイル)
Cluster Ready Services
CRS
Oracle High Availability Services
OHAS
Cluster Synchronization Services
CSS
Event Manager
EVM
Oracle Automatic Storage Management
Oracle ASM (ASM)
Oracle ASM Cluster File System
Oracle ACFS (ACFS)
Single Client Access Name
SCAN
Grid Naming Service
GNS
3
4
5
6
7
8
9
10
11
Oracle Clusterware のコンポーネント
• Oracle Clusterware リソース
Oracle Clusterware で管理するリソースを表します。
• Oracle Clusterware スタック
Oracle Clusterware 上で動作するデーモンを表します。
• Oracle Clusterware ファイル
ここでは、Oracle Clusterware で使用されるファイル郡を指します。
Oracle Clusterware のおおまかな起動の流れ
1．OHAS デーモンが起動
2．OHAS デーモンが OHAS エージェントを起動
3. OHAS エージェントが Oracle Clusterware プロセス (CRS デーモン含む) を起動
4. CRS デーモンが CRS エージェントを起動
5. CRS エージェントが Oracle Clusterware リソースを開始
12
RAC 11g R1 までは、Oracle Clusterware をインストールすると、CSS、CRS、EVM 用のエン
トリが / t /i itt b に3行追加されていました。RAC
トリが、/etc/inittab
に3行追加されていました RAC 11
11g R2 では、Grid
では G id IInfrastructure
f t t
をインス
トールすると、/etc/inittab に下記の ohasd 用のエントリが1行追加されます。
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
スタンドアロン・サーバー用 Grid Infrastructure
スタンドアロン・サーバー用 Grid Infrastructure は、RAC 11g R2 から導入された新しいインス
ト
トールのオプションです。シングル・インスタンス環境に従来の
のオプシ ンです シング
イン タン 環境に従来の CRS リソースのような障害時の
リ
のような障害時の
自動再起動の仕組みを実装したインストール・オプションです。
13
RAC 11g R2 では、Oracle Custerware プロセスおよび、リソースはエージェントにより監視を
行い O l Cl
行い、Oracle
Clusterware
t
の高可用性を実現します OHAS エージェントは主に、Oracle
の高可用性を実現します。OHAS
エ ジ ントは主に O l
Clusterware プロセスを監視し、CRS エージェントは、CRS リソースの監視の役割を担います。
Oracle Clusterware プロセスも内部的には、リソースとして扱うため、OHAS リソースと呼ぶこ
ともあります。
OHAS エージェント障害時は、OHAS が即時に再起動を行います。CRS エージェント障害時
は、CRS が即時に再起動を行います。
14
Oracle Clusterware スタックは、以下の2つのスタックから構成されています。
• Cluster Ready Services (CRS) スタック
• Oracle High Availability Services (OHAS) スタック
ベンダー製クラスタウェアが存在する場合は、従来通り、Oracle Clusterware は、ベンダー製ク
ラスタウェアに依存します。
15
エージェントのプロセスについて
エージェントによって監視対象となるプロセスやリソースは異なります。また、起動する OS ユー
ザごとにエージェントのプロセスは異なります (OS ユーザごとに1プロセス起動)。root 権限の
必要なプロセスおよび、リソースは、orarootagent が使用されます。その他は、Grid
Infrastructure インストールユーザで操作する oraagent が使用されます。Grid Infrastructure
と Oracle Database のインストールユーザを分割している場合は、各ユーザに対応した
oraagent (2個) が起動されます。
cssdagent / cssdmonitor は、CSS を監視するためのエージェントです。
16
17
Oracle Clusterware リソースの確認方法
crsctl status resource –t コマンドにより確認します。以下は、2 ノードクラスタ環境で、RAC /
ASM 環境を構成した際の出力例です。
$ crsctl status resource -t
-------------------------------------------------------------------------------NAME
TARGET STATE
SERVER
STATE_DETAILS
-------------------------------------------------------------------------------Local Resources
-------------------------------------------------------------------------------ora.DG1.dg
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
ora.LISTENER.lsnr
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
ora.asm
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
ora.eons
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
ora.gsd
OFFLINE OFFLINE
stvm20
OFFLINE OFFLINE
stvm21
ora.net1.network
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
ora.ons
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
t 21
ora.registry.acfs
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
-------------------------------------------------------------------------------Cluster Resources
-------------------------------------------------------------------------------ora.LISTENER_SCAN1.lsnr
1
ONLINE ONLINE
stvm20
ora.LISTENER_SCAN2.lsnr
1
ONLINE ONLINE
stvm20
ora.LISTENER_SCAN3.lsnr
1
ONLINE ONLINE
stvm21
ora.oc4j
1
OFFLINE OFFLINE
ora.orcl.db
1
ONLINE ONLINE
stvm20
2
ONLINE ONLINE
stvm21
ora.orcl.srv_a.svc
1
ONLINE ONLINE
stvm20
t 20
2
ONLINE ONLINE
stvm21
ora.scan1.vip
1
ONLINE ONLINE
stvm20
ora.scan2.vip
1
ONLINE ONLINE
stvm20
ora.scan3.vip
1
ONLINE ONLINE
stvm21
ora.stvm20.vip
1
ONLINE ONLINE
stvm20
ora.stvm21.vip
1
ONLINE ONLINE
stvm21
18
19
Oracle Clusterware の起動の流れとして、スライドの○で囲った部分に重点をおいて説明しま
す。
20
Oracle Clusterware 起動の流れ (OCR / 投票ディスクを ASM 管理した場合)
1. OHAS デーモン起動時に、OLR をオープン
2. OHAS デーモンは、OHAS エージェントを起動
3. oraagent は GPNPD、cssdagent は、CSS を起動
4. gpnpd は、GPnP プロファイルを読み込み起動完了
5. CSS は、gpnpd と通信を行い、プロファイルを取得
6. CSS は、投票ディスクを検出して I/O を開始。起動完了
7 CSS 起動完了後に、ASM
7.
起動完了後に ASM が起動を開始 ((*1)
1)
8. ASM は gpnpd からプロファイルを取得し、SPFILE を参照して起動を開始
9. ASM の起動完了後、CRS が起動を開始 (*2)
10. CRS は gpnpd からプロファイルを取得
11. CRS は CSS への接続を確立 (*1)
12. CRS は OCR をオープンして、CRS エージェントの起動および、CRS リソースを開始
(*1) CSS の起動に失敗した場合は、ASM や CRS は起動できません。
(*2) OCR / 投票ディスクを共有ファイルシステム上に配置している場合は、CRS と ASM はほ
ぼ同時に起動します。(CRS は ASM の起動を待ちません)
21
22
RAC 11g R1 までは、ネットワークや投票ディスクなどの情報は、OCR で管理されていました。
OCR を ASM で管理する場合、OCR
で管理する場合 OCR へアクセスするためには ASM インスタンスが起動して
いる必要があります。そこで、RAC 11g R2 では、クラスタの構成情報を GPnP プロファイルに
格納し、OCR と分離して管理します。ただし、GPnP プロファイルも OCR の中にも格納される
ため、OCR から情報がなくなったわけではありません。
OCR / 投票ディスクの ASM 管理
CSS が起動する前に、ASM を起動させることはできないため、CSS 自ら投票ディスクを検出
する実装が必要でした。そこで、GPnP
する実装が必要でした。そ
で、
プロファイルに投票ディスクの配置場所を格納し、ASM
ァイルに投票ディ クの配置場所を格納し、
インスタンスの起動の有無に依存しない、投票ディスクの検出および、使用を可能にしています。
ASM 自身の SPFILE を ASM 管理
ASM を起動する前に、SPFILE にアクセスする必要があるため、ASM 自ら SPFILE を検出す
る実装が必要でした。そこで、GPnP プロファイルに SPFILE の配置場所を格納し、ASM イン
スタンスの起動の有無に依存しない、SPFILE の検出および、使用を可能にしています。
23
ネットワーク・プロファイル
クラスタや RAC で使用するインターコネクトの情報として利用されます。Oracle Interface
Configuration (OIFCFG) コマンドでネットワーク情報を変更すると、GPnP プロファイルも自動
的に更新されます。
CSS プロファイル
CSS が投票ディスクを検出するために利用されます。投票ディスクの管理方法 (共有ファイル
システムもしくは、ASM 管理) に依存しないで常に利用されます。crsctl ユーティリティで投票デ
ィスクの配置を変更した場合は GPnP プロファイルも自動的に更新されます。
ィスクの配置を変更した場合は、
プロファイルも自動的に更新されます
ASM プロファイル
ASM が使用する ASM ディスクおよび、ASM 自身の SPFILE を検出する際に利用されます。
ASM で使用される初期化パラメータ ASM_DISKSTRING で指定される文字列と同じ情報で
す。asmcmd で SPFILE の配置場所を変更、もしくは、 ASM_DISKSTRING を変更した場合
は、GPnP プロファイルも自動的に更新されます。投票ディスクが ASM 管理されている場合に
も利用されます。
24
Profile.xml の内容
<?xml version="1.0" encoding="UTF-8"?>
<gpnp:GPnP-Profile Version=“1.0” xmlns=.. <省略> >
<gpnp:Network-Profile>
<gpnp:HostNetwork id="gen" HostName="*">
<gpnp:Network id="net1" IP="10.185.144.0" Adapter="eth0" Use="public"/>
<gpnp:Network id="net2" IP="10.10.1.0" Adapter="eth1" Use="cluster_interconnect"/>
</gpnp:HostNetwork>
</gpnp:Network-Profile>
<orcl:CSS-Profile id="css“ DiscoveryString="+asm" LeaseDuration="400"/>
<orcl:ASM-Profile id="asm" DiscoveryString="/dev/xvdb*“
SPFile="+DATA/stvm-cluster/asmparameterfile/registry.253.694745987"/>
<ds:Signature …<省略> >
</ds:Signature>
</gpnp:GPnP-Profile>
ネットワーク情報
CSS プロファイル
ASM プロファイル
OLR / OCR にも、GPnP プロファイルのコピーが格納されます (「SYSTEM.GPnP.profiles」 キ
ーとして格納)。ただし、OCRDUMP で内容を出力させても、プロファイル部分はバイナリ形式
で出力されるため、OLR / OCR のダンプからプロファイルの内容を確認することはできません。
投票ディスクを ASM 管理している場合は、CSS プロファイルの DiscoveryString は、‘+asm’ とな
り、ASM プロファイルの DiscoveryString を利用して、投票ディスクの検出を行います。投票ディスクを共
有ファイルシステムに配置している場合は、CSS プロファイルの DiscoveryString に投票ディスクのパス
が格納されます。
25
RAC 11g R1 までは、インターコネクトの情報は、OCR から取得していました。RAC 11g R2 で
は インタ コネクト情報を GPnP
は、インターコネクト情報を
GP P プロファイルから取得します。そのため、ASM
プロフ イルから取得します そのため ASM / DB Alert.log
Al t l
では、インスタンス起動時に以下のメッセージが出力されます。
DB Alert.log の例
Thu Aug 13 02:20:30 2009
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE SESSIONS WARNING = 0
LICENSE_SESSIONS_WARNING
Interface type 1 eth1 10.10.1.0 configured from GPnP Profile for use as a cluster interconnect
Interface type 1 eth0 10.185.144.0 configured from GPnP Profile for use as a public interface
Picked latch-free SCN scheme 2
GPNPD 障害などで通信に失敗した場合は、以下のメッセージが出力されます。
DB Alert.log
g の例
2009-08-16 22:08:16.798
[USER(6891)]CRS-2302:GPnPプロファイルを取得できません。
エラーCLSGPNP_NO_DAEMON (GPNPDデーモンは実行されていません)。
WARNING clssnsifquery: return = 1 vec_size = 10
interconnect information is not available from GPnP Profile
WARNING: No cluster interconnect has been specified. Depending on
the communication driver configured Oracle cluster traffic
may be
b di
directed
t d tto th
the public
bli iinterface
t f
off thi
this machine.
hi
Oracle recommends that RAC clustered databases be configured
with a private interconnect for enhanced security and
performance.
Picked latch-free SCN scheme 2
26
GPnP プロファイルは、バージョン管理されています。プロファイルに変更があった場合は、内
部的に保持しているシ ケンス番号が増えます O l Clusterware
部的に保持しているシーケンス番号が増えます。Oracle
Cl t
起動時には
起動時には、profile.xml
fil
l
/ OLR / OCR 間、および他ノードのシーケンス番号の比較を行い、シーケンス番号が最も大き
いプロファイル (最新のプロファイル) が採用されます。この仕組みにより、以下の状況にも対応
可能です。
• OLR / OCR の破損などで、以前のバックアップをリストアした場合
次回 Oracle Clusterware 起動時に、自動的に最新のプロファイルに更新されます。
• 他ノードが停止していた場合のプロファイルの更新
他ノードが停止していた状況で、ASM SPFILE や投票ディスクの配置変更を行った場合、停止
ノードではプロファイルの更新は行われませんが、次回 Oracle Clusterware 起動時に、自動
的に最新のプロファイルに更新されます。
ここでのバージョン管理は、GPnP プロファイル部分のみです。OCR / OLR 全体が最新に更
新されるという意味ではありません。
27
RAC 11g R2 では、Oracle Clusterware プロセスも内部的にリソース管理されます。そのため、
O l Cl
Oracle
Clusterware
t
プロセスは OHAS リソースと呼ばれることもあります。従来の
プロセスは、OHAS
リソ スと呼ばれることもあります 従来の CRS リソ
ースで定義されていたリソース属性 (CHECK_INTERVAL など) を持ち、CRS リソースと同等
の高可用性フレームワークで Oracle Clusterware プロセスも管理されます。
28
Oracle Clusterware 起動時に、OHAS デーモンが OLR を参照して、Oracle Clusterware プ
ロセスやエ ジ ントの起動を行います
ロセスやエージェントの起動を行います。
OLR の設定ファイル
OLR の配置場所は、各ノードの /etc/oracle/olr.loc に格納されています。
olrconfig_loc=/opt/gridhome/cdata/stvm16.olr
crs_home=/opt/gridhome
root.sh 実行時の OLR の自動バックアップ
Grid Infrastructure インストール時の root.sh 実行時に、以下のように、OLR のバックアップが
取得されます。
# ./root.sh
...
CRS-2672: 'ora.evmd'('stvm17')の起動を試行しています
CRS-2676: 'ora.evmd'('stvm17')の起動が成功しました
OLR のバックアップを取得
ックアッ を取得
stvm17 2009/08/27 00:33:35 /opt/gridhome/cdata/stvm17/backup_20090827_003335.olr
Configure Oracle Grid Infrastructure for a Cluster ... succeeded
クラスタウェアのインベントリ・プロパティの更新中
Oracle Universal Installerを起動中です...
…
29
30
各 Oracle Clusterware プロセスの監視間隔は、OLR 内のリソース属性 CHECK_INTERVAL
として定義されています プロセス障害が発生すると エ ジ ントがプロセスの再起動を行い
として定義されています。プロセス障害が発生すると、エージェントがプロセスの再起動を行い
ます (CSS 障害の場合は、ノードリブート)。また、リソース名や使用するエージェントの定義もリ
ソース属性として定義されています。
(*1) oraagent は、1 秒間隔で ASM インスタンスを監視し、インスタンス障害が発生した場合は、
即時に ASM インスタンスを再起動させます。oraagent は、11g R1 までのインスタンス・モニタ
(racgimon) と同等の監視を行います。
(*2) CSS に障害が発生すると、cssdagent は即時にノードを再起動させます。30 秒間隔の監
視は、CSS のステータスを監視しています。
31
OLR の手動バックアップの実行例
新たにバックアップされたファイル
# ocrconfig -local -manualbackup
stvm16
2009/08/15 23:24:09
/opt/gridhome/cdata/stvm16/backup_20090815_232409.olr
stvm16
2009/08/13 01:03:26
/opt/gridhome/cdata/stvm16/backup_20090813_010326.olr
OLR のバックアップ情報の確認
# ocrconfig -local -showbackup
stvm16
2009/08/15 23:24:09
/opt/gridhome/cdata/stvm16/backup_20090815_232409.olr
stvm16
2009/08/13 01:03:26
/opt/gridhome/cdata/stvm16/backup_20090813_010326.olr
32
補足事項
• OLR の自動バックアップの機能はありません
• OLR の多重化は不可 (各ノード1つのみ)
• OLR の追加 / 削除は不可
• OLR が破損すると、Oracle Clusterware は起動不可 (バックアップからのリストアが必要)
33
RAC 11g R1 までは、ASM は、CRS リソースとして管理されていました。CRS デーモンが
OCR をオープンし、各リソースを起動する中で、ASM
をオ プンし 各リソ スを起動する中で ASM インスタンスも起動していました。しかし、
インスタンスも起動していました しかし
11g R2 の新機能である OCR を ASM 管理する場合、OCR をオープンする前に、ASM は起
動されている必要がありました。
RAC 11g R2 では、CRS リソースの中ではなく、Oracle Clusterware スタックの中で起動する
よう変更されています。OHAS エージェント (oraagent) が ASM インスタンスを起動します。
OHAS エージェントは、1 秒間隔で ASM インスタンスを監視し、インスタンス障害が発生した場
合は、即時に ASM インスタンスを再起動させます。OHAS エージェントは、11g R1 までのイン
スタンス・モニタ (racgimon) と同等の監視を行います。
Oracle ASM のリソース属性の違い
Oracle ASM の OHAS リソースと CRS リソースの役割の違いから、リソース属性として以下
が異なります。
リソース属性
OHAS リソースの ASM
CRS リソースの ASM
AUTO START
AUTO_START
restore
never
CHECK_INTERVAL
1
60
34
35
ASMCA で ASM を構成すると、デフォルトで ASM の SPFILE は ASM 管理されます。
SQL*Plus もしくは、SRVCTL で ASM インスタンスを起動する場合も、GPnP プロファイルから
情報を取得するため、ASM SPFILE を使用した ASM インスタンスの起動は可能です。
インスタンス起動中の SPFILE へのアクセスは読み込みのみ許可されています。そのため、
SPFILE 内の初期化パラメータを変更するためには、ASM インスタンスが起動されている必要
があります。
SPFILE を格納したディスクグループは、ASM インスタンス起動時に自動的にマウントされます。
SPFILE の確認方法
以下のコマンドで、GPnP プロファイル内の SPFILE のパスやディスク検出文字列を確認する
ことが可能です。
$ asmcmd spget
+DATA/jpintl cluster/asmparameterfile/registry 253 696194007
+DATA/jpintl-cluster/asmparameterfile/registry.253.696194007
$ asmcmd dsget
parameter:/dev/xvdb*
profile:/dev/xvdb*
36
RAC 11g R2 では、Oracle Clusterware と ASM を統合した Grid Infrustructure を提供します。
また O l Cl
また、Oracle
Clusterware
t
に必要な OCR / 投票ディスクを ASM 管理するため、従来のような
管理するため 従来のような
ASM インスタンスのみ停止する操作に制限がかけられています。
以下は、各種停止コマンドにおける ASM の停止の可否を表しています。
ASM で管理しているファイル
停止方法
SPFILE
OCR / 投票ディスク
svctl
tl stop
t asm (*1)
×
×
svctl stop asm –f (*2)
○
×
shutdown (normal /
immediate)
○
×
shutdwn abort
○
○
crsctl stop crs
○
○
crsctl stop cluster
○
○
(*1) OCR / 投票ディスクを ASM 管理している場合は、ASM の停止は不可
(*2) SPFILE のみ ASM 管理している場合は、-f オプションを指定することで停止することは可
能 (この場合、OCR / 投票ディスクは、共有ファイルシステムに配置)
37
CSS は自ら投票ディスクを検出し、I/O を実行することができるため、ASM インスタンス障害が
発生しても O l Cl
発生しても、Oracle
Clusterware
t
は稼動し続けることが可能です
は稼動し続けることが可能です。
38
39
Oracle High Availability Services (OHAS) デーモン
Oracle Clusterware プロセスの起動および、監視を行います。OLR
プ
起動および 監視を行 ます
の管理を行います。
管理を行 ます
Grid Plug and Play デーモン (GPNPD)
GPnP プロファイルの配布および、メンテナンスの管理を行います。非 GNS 環境でも利用されます。
Grid Interprocess Communication (GIPC) デーモン
RAC 11g R2 初期リリースでは何らかの機能を提供するプロセスではありません。今後のリリースにて、
使用される可能性があります。
Multicast Domain Name Service (mDNS) デーモン
GNS 環境で利用されるデ
環境で利用されるデーモン。GNS
モン。GNS を使用して名前解決を行う際のレスポンダとしての役割を担いま
す。
Oracle Agent (oraagent)
Oracle Clusterware プロセスの障害監視を行うエージェント (root 所有以外)。監視対象としては、
GPNPD, EVM などが含まれます。
Oracle Root Agent (orarootagent)
Oracle Clusterware プロセスの障害監視を行うエージェント (root 所有)。監視対象としては、CRS,
CTSS などが含まれます。
などが含まれます
cssdagent / cssdmonitor
CSS の状態を監視するエージェント。CSS の起動 / 停止 / 監視の主要な役割は、cssdagent が担いま
す。
Oracle ACFS ドライバ
Oracle ACFS / Oracle Kernel Services (OKS) / Oracle ADVM ドライバを管理。リソースを開始すると、
ドライバは OS 上にロードされます。Grid Infrastructure インストール時に Oracle ACFS ドライバも自動
的にインスト ルされます
的にインストールされます。
40
cssdagent / cssdmonitor に障害が発生しても、OHAS デーモンが即時に、エージェントの再起
動を行います
動を行います。cssdagent
d
t 障害時から再起動するまでの間も CSS の継続監視を行うために、
の継続監視を行うために
cssdmonitor が導入されています。
RAC 11g R1 までは、CSS 障害発生時のノード再起動は、init スクリプト (init.ocssd) で行わ
れていまいた。RAC 11g R2 では、cssdagent がノードの再起動を行います。
oprocd / oclsvmon / oclsomon
oprocd
d
プロセッサ・デーモンとしての役割を担います。プロセッサ (CPU) がストールしているか否かを
チェックし、ストールしている場合はノードを強制的に再起動します。これにより、 I/O Fencing
に似たメカニズムを提供し、データ障害を未然に防ぎます。
oclsvmon
CSS プロセス障害時にログを出力させる役割を担います。特定のベンダークラスタウェアが動
作している環境下でのみ起動します。
oclsomon
CSS がハングしていないかどうかを監視する役割を担います。CSS がハングしている場合は、
ノードを強制的に再起動します。
hangcheck timer モジュールの必要性
Linux 環境では、10.2.0.4 / 11.1 からノードハングの監視を目的として、 oprocd が導入されま
した。また、ノードハングの監視として、hangcheck timer モジュールも併用するようご案内して
いました RAC 11g R2 では、ノ
いました。RAC
では ノードおよび
ドおよび CSS の状態を CSS エ
エージェントが統合監視するこ
ジェントが統合監視するこ
とで、障害に対する精度の高い監視が可能になっています。そのため、RAC 11g R2 では、
hangcheck timer モジュールの設定は要件から外れました (設定する必要はありません)。
41
CSS のハングは、CSS エージェントが監視を行います。CSS エージェント (cssdagent /
cssdmonitor
d
it のいずれか) がハングすると、CSS
がハングすると CSS がハングしているかどうかの監視を行うこと
ができません。そのため、MISSCOUNT 秒以上 CSS エージェントがハングした場合は、ハン
グが解消された時点で即時にノード再起動が実行されます。
CSS および、CSS エージェントは、高負荷な場合でもより安定して動作するように Linux 環境
ではスケジューリングクラスが RR (Round Robin) に設定されています。RAC 11g R1 も同様
(oprocd / oclsomon / ocssd は RR に設定) です。
Linux 環境の MISSCOUNT / REBOOTTIME / DISKTIMEOUT の確認
MISSCOUT / REBOOTTIME / DISKTIMEOUT は以下のコマンドで確認できます。RAC 11g
R1 と設定値は同じです。
# crsctl get css misscount
30
# crsctl get css reboottime
3
# crsctl get css disktimeout
200
42
Cluster Ready Services (CRS) デーモン
CRS リソースの可用性を管理します。定期的に
用性を管理 ます 定期的 CRS リソースの状態を監視し、CRS
状態を監視
リソース障害時に
障害時
は必要に応じて再起動の試行や他ノード上へのフェイルオーバー / フェイルバックを行います。また、CRS
リソースの状態変化をイベントとして eONS / EVM に通知します。サーバー・プールの管理も行います。
Cluster Synchronization Services (CSS) デーモン
ノード間でハートビートを送りあうことによるクラスタ・メンバーシップ情報の管理や、投票ディスクを利用し
たスプリット・ブレイン解決を行います。また、クラスタ内で起動しているインスタンスのグループ・メンバー
シップ情報を管理し、ロック機能を提供する役割を担います。
Event Manager (EVM) デーモン
クラスタ内で発生した高可用性イベントの処理を行います。CRS
クラスタ内で発生した高可用性イベントの処理を行います
CRS リソースの状態に変化があった時、イベ
リソ スの状態に変化があ た時 イベ
ントを発行します。
Cluster Time Synchronization Service (CTSS) デーモン
NTP の設定がされていない場合に、クラスタを構成する全サーバーのシステム時刻同期を行います。
Oracle ASM
OCR / 投票ディスクを配置するディスク管理として利用します。
Disk Monitor (DISKMON) デーモン
HP Oracle Exadata Storage
g Server ストレージの監視および、I/O
ト
ジの監視および、
フェンシングを実行します。CSS
ンシングを実行します。
を開
始する際は、DISKMON も同時に開始されます。
Oracle Agent (oraagent)
Oracle Clusterware リソースの障害監視を行うエージェント (root 所有以外)。監視対象としては、DB, リ
スナー, ONS などが含まれます。また、FAN イベントが起きた場合、サーバー・コールアウトを実行します。
Oracle Root Agent (orarootagent)
Oracle Clusterware リソースの障害監視を行うエージェント (root 所有)。監視対象としては、VIP, ネット
ワークなどが含まれます。
ワ
クなどが含まれます。
43
44
45
46
全てのリソースは、リソースタイプを持ちます。RAC 11g R1 までは、リソースタイプは、
「
「application」
li ti 」 のみで、リソース作成時に必要なリソース属性を全て定義する必要がありました。
のみで リソ ス作成時に必要なリソ ス属性を全て定義する必要がありました
RAC 11g R2 では、予めリソースタイプでリソース属性を定義できるため、リソース作成時は、
必要最小限の定義で済みます。RAC 11g R2 でも、「application」 タイプは利用可能ですが、
下位互換のために存在します。
リソースタイプの利点
• リソースの特性に応じて、属性テンプレートの作成が可能
• リソース作成時は、必要なリソース属性のみ定義
リソース作成時は 必要なリソース属性のみ定義
• リソースタイプに基づく依存性の構築が可能
リソースタイプの確認方法
現在、作成されているリソースタイプを確認するためには、crsctl status type コマンドを実行し
ます。TYPE_NAME はタイプ名、BASE_TYPE は参照元 (親となる) タイプです。
$ crsctl status type
TYPE_NAME=application
BASE_TYPE=cluster_resource
TYPE_NAME=cluster_resource
BASE_TYPE=resource
TYPE_NAME=local_resource
BASE TYPE=resource
BASE_TYPE=resource
TYPE_NAME=resource
BASE_TYPE=
47
「local_resource」、「cluster_resource」 タイプは、組み込みリソースタイプで、Grid
I f t t
Infrastructure
インスト ル時に自動的に作成されます 組み込み CRS リソースやカスタム・ア
インストール時に自動的に作成されます。組み込み
リソ スやカスタム ア
プリケーションで利用されます。「cluster_resource」 タイプは、フェイルオーバー関連のリソー
ス属性 (PLACEMENT, SERVER_POOLS など) が定義されています。 「local_resource」 に
はその定義はありません。
ローカル・リソース / クラスタ・リソースの稼動確認
カスタム・アプリケーションの apps1 (ローカル・リソース) と apps2 (クラスタ・リソース) を作成
および、開始した後の状態出力例を以下に示します。
-- ローカル・リソース
-- 各サーバー上で起動 (ONLINE)
$ crsctl status resource apps1
NAME=apps1
TYPE=local_resource
TARGET=ONLINE
, ONLINE
, ONLINE
, ONLINE
STATE=ONLINE
STATE
ONLINE on serv1, ONLINE on serv2, ONLINE on serv3, ONLINE on serv4
-- クラスタ・リソース
-- クラスタ内のいずれかのサーバー上で起動 (ONLINE)
$ crsctl status resource apps2
NAME=apps2
TYPE=cluster_resource
TARGET=ONLINE
STATE=ONLINE on serv1
48
RAC 11g R2 より、新しく追加されたリソース属性 START_DEPENDENCIES /
STOP DEPENDENCIES で、リソースの開始
STOP_DEPENDENCIES
で リソ スの開始 / 停止時における依存関係を別々に定義するこ
とが可能になりました。また、オプションを利用することで、より柔軟な依存関係の構築が可能
になっています。
従来の依存関係の課題
• 依存関係の定義は、リソースによって以下のように分散定義されていました
• Hard Dependency
• リソース属性
リソ ス属性 REQUIRED_RESOURCES
REQUIRED RESOURCES で定義
• Soft Dependency
• バイナリ・ファイル (racgmain) で定義 (ハード・コード)
• 依存関係の制約
• 指定可能な依存関係は、Hard Dependency のみ
• 依存関係は、リソースの開始 / 停止両方に適用される (分離不可)
• 依存リソースは、最初に開始しなければいけない
• 依存関係を持つリソースは、同じノード上で起動しなければいけない
REQUIRED_RESOURCES / OPTIONAL_RESOURCES
REQUIRED_RESOURCES / OPTIONAL_RESOURCES リソース属性は、下位互換として、
application タイプのリソースのみ使用可能です。
49
開始の依存性
• 強い依存性 : リソースを開始する前に、依存するリソースが ONLINE でなければいけない場
合に利用
• 弱い依存性 : 依存するリソースの状態に関係なく、リソースを開始させたい場合に利用
• 集中依存性 : 依存するリソースが配置されているノード上で、リソースを開始させたい場合に
利用
• プルアップ依存性 : 依存するリソースを開始した後に、自動的にリソースを開始させたい場合
に利用
• 分散依存性 : リソースの共存
リ
の共存 (同一サーバー上で稼動)
(同 サ バ 上で稼動) を避けたい場合に利用
停止の依存性
• 強い依存性 : リソースを停止する際、依存するリソースも停止させたい場合に利用
50
構文
hard([intermediate:][global:]resource_name | type:resource_type)
指定可能なパラメータ
パラメータ
説明
intermediate
R2 が ONLINE もしくは、INTERMEDIATE である場合は、R1 は開始可能。
指定がない場合は、R2 は ONLINE である必要がある。
global
R2 がクラスタのいずれかのノード上で稼動していれば、R1 は開始可能。
指定がない場合は、R2 と同じノード上で R1 を配置する必要がある。
強い依存性を定義する場合は、プルアップ依存性も併せて設定することをお奨めします。
51
構文
weak([concurrent:][global:][uniform:]resource_name | type:resource_type)
指定可能なパラメータ
パラメータ
説明
concurrent
R1 の起動は、R2 の起動を待たない (同時実行)。指定がない場合は、R2 の開始
後に、R1 を開始。
global
R2 と同じサーバー上で R1 が稼動することを要求しない。指定がない場合は、R2
と同じノード上で R1 を配置する必要がある。
uniform
リソースが稼動可能な全てのサーバー上で R2 を開始。指定がない場合は、R1
と同じサーバー上で R2 を開始。
52
構文
attraction([intermediate:]resource_name | type:resource_type)
指定可能なパラメータ
パラメータ
説明
intermediate
R2 が ONLINE もしくは、INTERMEDIATE であるノード上で、R1 の開始を試行
。指定がない場合は、R2 は ONLINE である必要がある。
53
構文
pullup[:always]([intermediate:][global:]resource_name | type:resource_type)
指定可能なパラメータ
パラメータ
説明
intermediate
R2 が ONLINE もしくは、INTERMEDIATE である場合は、R1 は開始可能。
指定がない場合は、R2 は ONLINE である必要がある。
global
R2 がクラスタのいずれかのノード上で稼動していれば、R1 は開始可能。
指定がない場合は、R2 と同じノード上で R1 を配置する必要がある。
:always
R1 の TARGET 値に関係なくプルアップする。指定がない場合は、
TARGET=ONLINE のみ。
54
構文
dispersion[:active]([intermediate:]resource_name | type:resource_type)
指定可能なパラメータ
パラメータ
説明
intermediate
R2 が ONLINE もしくは、INはTERMEDIATE であるノード以外のノードで R1 の
開始を試行。指定がない場合は、R2 は ONLINE である必要がある。
:active
同一サーバー上でリソースが共存している場合は、ノード起動時にリソースの再
配置を行う。指定がない場合は、ノード起動時に再配置は行わない。
55
構文
hard([intermediate:][global:][shutdown:]resource_name | type:resource_type)
指定可能なパラメータ
パラメータ
説明
intermediate
R2 が ONLINE もしくは、INTERMEDIATE である場合は、R1 は ONLINE で稼
動し続けることが可能。指定がない場合は、R2 は ONLINE である必要がある。
global
R2 がクラスタ内のいずれかのノードで稼動していれば、R1 は稼動し続けることが
可能。指定がない場合は、同じサーバー上で、R2 が停止する際は、R1 の停止も
行う。
shutdown
crsctl stop crs / crsctl stop cluster を実行した時のみ依存性を適用。個々のリソ
ースの計画停止 / 計画外停止には影響しない。
56
RAC 10g R1 より、CRS リソースの開始 / 停止 / 再起動を行う高可用性フレームワークを提供
しました CRS リソースの監視は、CRS
しました。CRS
リソ スの監視は CRS デーモンが定期的にアクション・プログラムを実行
デ モンが定期的にアクシ ン プログラムを実行
(fork) することで行っていました (ただし、racgimon は常駐プロセス)。また、 RAC / ASM / VIP
のようなアプリケーションの場合は、racgvip や racgimon などを独自実装することで対応して
いました。
RAC 11g R2 では、クラスタ環境の全てのアプリケーションに高可用性サービスを提供するた
め、エージェント・フレームワークを提供します。RAC 11g R2 では、エージェントと呼ばれる常
駐プロセスが CRS リソースの監視を行います。常駐プロセスとすることで、プログラムを fork
するオーバヘッドを削減し、監視間隔の短縮および、より早期な障害検知を可能とします。エー
ジェントに障害が発生した場合は CRS デーモンがエージェントを即時に再起動します。
ジェントに障害が発生した場合は、CRS
デ モンがエ ジェントを即時に再起動します
アプリケーション利用時のエージェント
RAC 11g R2 では、アプリケーションを保護するスクリプトを実行するため、以下のエージェント
が利用可能です。
スクリプト・エージェント
• <Grid_Home>/bin/scriptagent.bin
• cluster_resource / local_resource タイプ利用時
アプリケーション・エージェント
• <Grid_Home>/bin/appagent.bin
• application タイプ利用時 (下位バージョンのデータベースおよび、サービス含む)
• 下位互換のために提供
カスタム・アプリケ ションを作成する際は、スクリプト・エ
カスタム・アプリケーションを作成する際は
スクリプト・エージェントを利用することをお奨めしま
ジェントを利用することをお奨めしま
す。
57
RAC 11g R2 のカスタム・アプリケーションの操作には、crsctl ユーティリティをご利用ください。
従来の crs_profile
fil などの crs_** コマンドは、下位互換のために存在します。
コマンドは 下位互換のために存在します
58
59
RAC 11g R2 では、いくつかのリソースが新しく追加されました。
デフォルトで OFFLINE となるリソース
• GSD リソース
RAC 11g R2 より、GSD リソースは、デフォルトで無効 (disable) に設定されるため、
OFFLINE となります。ベンダー製クラスタウェアがインストールされた RAC 9.2 で、かつ共有
構成ファイル (SRVM) が設定されている環境にて、Oracle Clusterware 11.2 をインストール
する場合は、デフォルトで ONLINE になります。
• OC4J リソース
OC4J リソースは、RAC 11g R2 初期リリースでは利用されないため、デフォルトで OFFLINE
になります。
• Oracle ASM / ディスクグループ / Oracle ACFS レジストリ
クラスタ用 Grid Infrastructure インストール時に、OCR / 投票ディスクを共有ファイルシステム
に配置する場合は、ASM は起動されないため、デフォルトで
デ
OFFLINE になります。OCR / 投
票ディスクを ASM に配置、もしくは、ASMCA により、ディスクグループを作成した場合は、自
動的に ONLINE になります。
ASM ディスクグループのリソースは、ディスクグループ作成時に自動的に作成されます。
60
RAC 11g R1 までは、ASM および、リスナーは、Oracle Database ホームから起動していまし
た RAC 11
た。RAC
11g R2 では、Oracle
では O l Cl
Clusterware
t
および ASM を統合したインストール
を統合したインスト ル (Grid
(G id
Infrastructure) の導入に伴い、ASM および、リスナーは、Grid Infrastructure ホームから起動
されます。
EM Database Control はリソースではありませんが、Oracle Database ホームから起動されま
す。
61
ASM を構成するツール (ASMCA) は、クラスタ用 Grid Infrastructure ホームにインストールさ
れます。
れます
NETCA は、クラスタ用 Grid Infrastructure ホームおよび、Oracle Database ホームの両方に
インストールされますが、RAC 11g R2 では、クラスタ用 Grid Infrastructure ホームの NETCA
を利用することをお奨めします。NETCA でリスナーを作成すると、ローカル・リソースとして
CRS リソースに登録され、クラスタを構成する全サーバーで起動されます(ノードの選択は不
可)。
リ ナ の管理
SCAN リスナーの管理
NETCA で SCAN リスナーを構成することはできません。SCAN リスナーを手動で構成する必
要がある場合は、SRVCTL ユーティリティを使用します。
62
管理する対象や使用するコマンドによって、環境変数 ORACLE_HOME やコマンドのパスの切
り替えが必要になります そのため 以下のような対処をしておくことをお奨めします
り替えが必要になります。そのため、以下のような対処をしておくことをお奨めします。
• Grid Infrastructure と Oracle Database は異なる OS ユーザでインストールを行い、各ユー
ザで読み込む環境変数を分離する
• 単一のインストールユーザの場合は、Grid Infrastructure 用と Oracle Database 用の環境
変数を定義したファイルを用意し、実行コマンドによって読み込む環境変数を切り替える
63
サーバー・プールやリソースを管理するコマンドとして、CRSCTL ユーティリティと SRVCTL ユ
ーティリティがあります。これらのコマンドは用途に応じて使用するユーティリティが異なるため、
テ リテ があります これらの マンドは用途に応じて使用する
テ リテ が異なるため
ご注意ください。
64
crs_stat コマンドは、下位互換のために残されているものの、RAC 11g R2 の新しいリソース・
モデリングに対応していないため使用しないようにしてください。
モデリングに対応していないため使用しないようにしてください
65
Oracle Clusterware リソースの確認方法
crsctl status resource –t コマンドにより確認します。以下は、2 ノードクラスタ環境で、RAC /
ASM 環境を構成した際の出力例です。
$ crsctl status resource -t
-------------------------------------------------------------------------------NAME
TARGET STATE
SERVER
STATE_DETAILS
-------------------------------------------------------------------------------Local Resources
-------------------------------------------------------------------------------ora.DG1.dg
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
ora.LISTENER.lsnr
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
ora.asm
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
ora.eons
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
ローカル・リソース
ora.gsd
各サーバー上で起動
OFFLINE OFFLINE
stvm20
OFFLINE OFFLINE
stvm21
ora.net1.network
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
ora.ons
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
t 21
ora.registry.acfs
ONLINE ONLINE
stvm20
ONLINE ONLINE
stvm21
-------------------------------------------------------------------------------Cluster Resources
-------------------------------------------------------------------------------ora.LISTENER_SCAN1.lsnr
1
ONLINE ONLINE
stvm20
ora.LISTENER_SCAN2.lsnr
1
ONLINE ONLINE
stvm20
ora.LISTENER_SCAN3.lsnr
1
ONLINE ONLINE
stvm21
ora.oc4j
1
OFFLINE OFFLINE
ora.orcl.db
1
ONLINE ONLINE
stvm20
2
ONLINE ONLINE
stvm21
ora.orcl.srv_a.svc
クラスタ・リソース
クラスタ
リソ ス
1
ONLINE ONLINE
stvm20
t 20
2
ONLINE ONLINE
stvm21
クラスタ内のいずれかの
ora.scan1.vip
サーバー上で起動
1
ONLINE ONLINE
stvm20
ora.scan2.vip
1
ONLINE ONLINE
stvm20
ora.scan3.vip
1
ONLINE ONLINE
stvm21
ora.stvm20.vip
1
ONLINE ONLINE
stvm20
ora.stvm21.vip
1
ONLINE ONLINE
stvm21
66
67
RAC 11g R1 までは、クラスタ・リソースのみで管理していました。全サーバーで稼動するリソー
ス (ローカル・リソース)
(ロ カル リソ ス) を作成する際は、クラスタ・リソースを全サーバー分作成して、個々のリ
を作成する際は クラスタ リソ スを全サ バ 分作成して 個々のリ
ソースとして管理していました。RAC 11g R2 では、クラスタ・リソース / ローカル・リソースの概
念を取り入れることで、ローカル・リソースも単一のリソースとして管理します。
68
RAC 11g R1 までは、ノードアプリケーションを構成するリソースは、クラスタ内のサーバー別に
リソ スが作成され それを識別するためにリソ スの名前には ホスト名が付いていました
リソースが作成され、それを識別するためにリソースの名前には、ホスト名が付いていました。
RAC 11g R2 では、単一のリソースと扱うため、リソースの名前からホスト名を排除しています。
$ crsctl status resource -t
…
ora.LISTENER.lsnr
ONLINE ONLINE
ONLINE ONLINE
ora.asm
ONLINE ONLINE
ONLINE ONLINE
ora.gsd
OFFLINE OFFLINE
OFFLINE OFFLINE
ora.ons
ONLINE ONLINE
ONLINE ONLINE
…
ora.stvm16.vip
1
ONLINE ONLINE
ora.stvm17.vip
1
ONLINE ONLINE
単一のリソースとして管理
各メンバーごとのステータスを表示
stvm16
stvm17
stvm16
stvm17
Started
Started
stvm16
stvm17
stvm16
stvm17
VIP は従来と同じ
stvm16
stvm17
69
RAC 11g R2 ではインスタンスおよび、サービス・メンバーのリソースは排除され、それぞれ単
一のリソースとして管理されます。
のリソ スとして管理されます
$ crsctl status resource -t
…
ora.asm
ONLINE ONLINE
ONLINE ONLINE
...
ora.orcl.db
1
ONLINE ONLINE
2
ONLINE ONLINE
ora.orcl.srv1.svc
1
ONLINE ONLINE
2
ONLINE ONLINE
単一のリソースとして管理
stvm16
stvm17
Started
Started
stvm16
stvm17
Open
Open
stvm16
stvm17
70
メンバー固有で管理するリソース属性に関しては、-v オプションを付けて確認することができま
す。
$ crsctl status resource ora.orcl.db -v
NAME=ora.orcl.db
TYPE=ora.database.type
LAST_SERVER=stvm16
STATE=ONLINE on stvm16
TARGET=ONLINE
CARDINALITY ID=1
CARDINALITY_ID=1
CREATION_SEED=65
CURRENT_RCOUNT=0
FAILURE_COUNT=0
FAILURE_HISTORY=
ID=ora.orcl.db 1 1
INCARNATION=2
LAST_RESTART=1250954892
_
p
STATE_DETAILS=Open
インスタンスのステータス
インスタンス障害が起きると、
CURRENT_RCOUNT がカウントアップされる
LAST_SERVER=stvm17
STATE=ONLINE on stvm17
TARGET=ONLINE
CARDINALITY_ID=2
CREATION_SEED=65
CURRENT_RCOUNT=0
FAILURE_COUNT=0
FAILURE HISTORY
FAILURE_HISTORY=
ID=ora.orcl.db 2 1
INCARNATION=1
LAST_RESTART=1250954995
STATE_DETAILS=Open
71
72
73
ネットワーク・リソース
crsctl status resource では、以下のようにネットワーク・リソースのステータスを確認できます。
$ crsctl status resource –t
…
ora.net1.network
ONLINE ONLINE
ONLINE ONLINE
stvm16
stvm17
ネットワーク番号
ネットワ
ク番号
ネットワーク・リソースは、ネットワーク番号を持ちます。Grid Infrastructure インストール時に構
成されるネットワークのネットワーク番号は 1 (デフォルト) です。RAC 11g R2 の新機能で、複
数サブネットに対して、VIP を作成することが可能です。その場合は、サブネットごとにネットワ
ーク番号 (2,3…) を割り当て、それに応じたネットワーク・リソース (ora.net(2,3…).network) が
作成されます。
74
ネットワークと VIP の監視
RAC 11g R1 までは、CRS が VIP リソースの監視 (RACGVIP) の中で、パブリック・ネットワー
クの監視も行っていました。RAC 11g R2 では、パブリック・ネットワークの監視は、ネットワー
ク・リソースのチェックで行います。リンクのステータスを1秒間隔で監視し、パブリックネットワー
ク障害が発生すると、ネットワーク・リソースは、OFFLINE になります。VIP や SCAN VIP の監
視は、NIC 上の VIP の存在の有無をチェックするのみとなります。
VIP / SCAN VIP を開始させるためには、そのノード上でネットワーク・リソースが ONLINE で
ある必要があります。
パブリック・ネットワーク障害時の動作
1. パブリック・ネットワークに障害発生
2. ネットワーク・リソースが障害検知 (即時)
3. ネットワーク・リソースの再起動を1回試行 (再起動に失敗すると、次のステップ)
4. 以下のリソースを停止
• デフォルト・リスナー
• SCAN リスナー
リスナ
• サービス
• VIP (デフォルトリスナー、全サービス停止後)
• SCAN VIP (SCAN リスナー停止後)
5. サービスを別のインスタンスで起動 (SINGLETON の場合)
6. VIP / SCAN VIP をフェイルオーバー先のサーバーで起動
7. SCAN リスナーをフェイルオーバー先のサーバーで起動 (SCAN VIP 起動後)
75
RAC 11g R1 までは、ネットワーク障害の回復後、DB インスタンスの監視 (5分間隔) の際に、
VIP をフェイルバックすることは可能でした。ただし、ネットワークが回復したことを直接検知する
をフ イルバ クすることは可能でした ただし ネ トワ クが回復したことを直接検知する
メカニズムは持っていないため、フェイルバックには少し時間を要していました。
(RAC 11g R1 までは、デフォルトで VIP の自動フェイルバックが無効 (10.2.0.3 を除く))
RAC 11g R2 では、ネットワーク・リソースを導入し、ネットワークの監視を VIP と分離すること
で、ネットワーク障害回復の早期検知および、 早期 VIP フェイルバックを実現させています。
SCAN VIP はホームノードを持たないため、自動フェイルバックの動作はありません。
76
サーバー障害時の VIP リソース
VIP リソースは、フェイルオーバーすると、ステータスが 「INTERMEDIATE」 の状態になります。
$ crsctl status resource ora.stvm16.vip
NAME=ora.stvm16.vip
TYPE=ora.cluster_vip_net1.type
TARGET=ONLINE
STATE=ONLINE on stvm16
* 「stvm16」 のサーバーに障害が発生
$ crsctl status resource ora.stvm16.vip
NAME=ora.stvm16.vip
TYPE=ora.cluster_vip_net1.type
TARGET=ONLINE
STATE=INTERMEDIATE on stvm18
リソースのステータス 「INTERMEDIATE」
「INTEMEDIATE」 は、リソースは部分的に ONLINE の状態 (稼動しているものの、サービス
は提供可能ではない状態) を表します。VIP が正常にフェイルオーバーしても、アプリケーション
からは、この VIP を利用してデータベースに接続することはできないため、「INTEMEDIATE」
というステータスになります。基本的に、対処の必要はありません。
77
SCAN VIP と SCAN リスナーは依存関係を持つため、個々の SCAN VIP / リスナーは、常に
同じサ バ 上で起動します
同じサーバー上で起動します。
$ crsctl status resource –t
…
ora.LISTENER_SCAN1.lsnr
1
ONLINE ONLINE
ora.LISTENER_SCAN2.lsnr
1
ONLINE ONLINE
ora LISTENER SCAN3 lsnr
ora.LISTENER_SCAN3.lsnr
1
ONLINE ONLINE
…
ora.scan1.vip
1
ONLINE ONLINE
ora.scan2.vip
1
ONLINE ONLINE
ora.scan3.vip
1
ONLINE ONLINE
stvm19
stvm18
stvm17
scan1 / scan2 / scan3 の VIP とリスナーは、
それぞれ同じサーバー上に配置
stvm19
stvm18
stvm17
78
SCAN VIP / SCAN リスナーの手動再配置
通常は、クラスタ内のサーバー上で分散配置されるため、手動での再配置は必要ありません。
以下のように、サーバーのメンテナンスなどで、SCAN を他のサーバーに移動させたい場合に
手動で再配置することが可能です。いずれのコマンドも SCAN VIP / SCAN リスナー両方、同
じサーバー上に再配置します。
SCAN VIP の再配置
s ct relocate
srvctl
e ocate sca
scan -i <scan
sca _number>
u be [-n
[ <node
ode_name>]
a e ]
例) srvctl relocate scan -i 1 -n serv1
SCAN リスナーの再配置
srvctl relocate scan_listener -i <scan_number> [-n <node_name>]
例) srvctl relocate scan_listener -i 1 -n serv1
79
サーバーが複数のサブネットのネットワークに接続されている場合は、RAC 11g R2 では、サ
ブネ トごとに VIP を作成することが可能になります。1つのサブネットに1つの
ブネットごとに
を作成することが可能になります 1つのサブネ トに1つの VIP を構成でき
ます。同じサブネットに複数の VIP は構成できません。
セキュリティ要件や負荷分散の観点で、サブネットを分離したい場合に有効です。
ネットワーク・リソース
複数サブネットに対して VIP を作成した際のネットワーク・リソースのステータスは以下のように
なります。
$ crsctl status resource –t
…
ora.net1.network
ONLINE ONLINE
ONLINE ONLINE
ora.net2.network
ONLINE ONLINE
ONLINE ONLINE
デフォルトのネットワーク・リソース
stvm16
stvm17
異なるサブネットに VIP を作成した際の
ネットワーク・リソース
stvm16
stvm17
t 17
ネットワーク番号
ネットワーク・リソースは、ネットワーク番号を持ちます。Grid Infrastructure インストール時に構
成されるネットワークのネットワーク番号は 1 (デフォルト) です。RAC 11g R2 の新機能で、複
数サブネットに対して、VIP を作成することが可能です。その場合は、サブネットごとにネットワ
ーク番号 (2,3…) を割り当て、それに応じたネットワーク・リソース (ora.net(2,3…).network) が
作成されます。
80
81
82
RAC 11g R2 では、listener.ora にエンドポイントの設定は行いません。エンドポイントの情報
は リソ スの属性として保持し リスナ 起動時にエ ジ ントが動的に設定を行います そ
は、リソースの属性として保持し、リスナー起動時にエージェントが動的に設定を行います。そ
のため、リスナーの構成を変更 (ポート番号の変更など) することによる listener.ora の編集は
不要です。
リスナー起動時の動作
1. リスナー起動 (srvctl start listener を実行)
2. CRS が oraagent にリスナー開始を実行
3 oraagentt は、リスナーを起動
3.
は リ ナ を起動
4. oraagent は、ローカルの VIP とリスナーのポート番号からエンドポイントを生成
5. oraagent は、リスナーにエンドポイントを登録
登録されたリスナーのエンドポイントの確認
lsnrctl コマンドにより、リスナーのエンドポイントの確認が可能です。リスナーのエンドポイント
の先頭は、常に IPC のエントリがくるため、ネットワーク障害時などにおけるリスナー停止で時
間を要する (TCP タイムアウトを待つ) ことはありません。
エージェントによって、動的に登録されたエンドポイント
$ lsnrctl status LISTENER
(VIP とパブリック IP がリスニングアドレスとして登録)
…
リスニング・エンドポイントのサマリー...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=<VIP Address>)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=<Public IP>)(PORT=1521)))
サービスのサマリー...
サービス"+ASM"には、1件のインスタンスがあります。
インスタンス"+ASM1"、状態READYには、このサービスに対する1件のハンドラがあります...
コマンドは正常に終了しました。
83
RAC 11g R2 で、listener.ora の設定が無効 (無視) になったわけではありません。リスナーを
起動する際は li t
起動する際は、listener.ora
を読み込んで起動しているため li t
を読み込んで起動しているため、listener.ora
のパラメ タなどの
のパラメータなどの
設定は11g R2 でも有効です。
リスナーの設定確認
現在のリスナーの設定を確認するためには、srvctl config listener を実行します。
$ srvctl config listener -l LIS112
名前: LIS112
ネットワーク: 1、所有者: grid
ホーム: <CRS home>
エンド・ポイント: TCP:1525
listener.ora の内容
listener.ora には、以下のようにエージェントが動的に追加した IPC のエントリがあります。これ
はエージェントがリスナーに接続するための情報になります。
は
ジ ントがリ ナ に接続するための情報になります。
LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)
(KEY=LISTENER))))
# line added by Agent
endpoints_listener.ora ファイル
<Grid_home>/network/admin 配下には、endpoints_listener.ora というファイルがあります。
これは Oracle Clusterware 配下に、下位のバージョンのデータベースが共存し、
これは、Oracle
配下に 下位のバ ジョンのデ タベ スが共存し 11g R2
ASM を認識する際に利用されるファイルになります。11g R2 のみの環境ではこのファイルは
利用されません。
84
RAC 11g R2 では、DBCA は LOCAL_LISTENER の設定を行いません。
LOCAL LISTENER の設定は、ローカルの
LOCAL_LISTENER
の設定は ロ カルの VIP やリスナー情報を読み取り、エージェントによ
やリスナ 情報を読み取り エ ジ ントによ
り自動的に設定されます。そのため、ポリシー管理で動的に、RAC インスタンスの配置が変更
されても、デフォルトリスナーに対するサービスの登録は自動的に対応可能です。また、リスナ
ーの新規作成や構成を変更 (ポート番号の変更など) することによる LOCAL_LISTENER の
設定変更は不要です。
インスタンス起動時の動作
1. イン
インスタンスの起動
タン の起動 ((srvctl start database))
2. CRS が oraagent にデータベース開始を実行
3. oraagent は、インスタンスを起動 (サービスの起動も含む)
4. oraagent は、ローカルの VIP とリスナーのエンドポイントから LOCAL_LISTENER の設定
を生成
5. oraagent は、インスタンスに接続を行い、ALTER SYSTEM SET LOCAL_LISTENER を実
行
6. PMON がロ
6
がローカル上で稼動するリスナーに対して、サービスを登録
カル上で稼動するリスナ に対して、サ ビスを登録 (リスナ
(リスナー経由の接続が
経由の接続が
可能に)
インスタンス起動時の ALERT.LOG
Fri Aug 14 23:41:59 2009
Starting ORACLE instance (normal)
エージェントにより、動的に設定された LOCAL_LISTENER
…
Completed: ALTER DATABASE OPEN
Fri Aug 14 23:42:28 2009
ALTER SYSTEM SET local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)
(HOST=stvip03)(PORT=1521))))' SCOPE=MEMORY SID='orcl_1';
85
RAC 11g R2 の DBCA で RAC データベース (管理者管理 / ポリシー管理両方) を作成する
際は デフォルトで以下のように構成されます
際は、デフォルトで以下のように構成されます。
• LOCAL_LISNTENER (設定なし)
• REMOTE_LISTENER=“<SCAN 名>:ポート番号“
デフォルトリスナーには、ローカルで起動しているインスタンスのサービスのみが登録されます。
SCAN リスナーでは、クラスタで稼動する全サービスの情報が登録されます。
86
87
リスナーの構成変更を LOCAL_LISTENER に反映する方法
リスナーの新規作成もしくは、変更を行った場合、それを LOCAL_LISTENER に反映させるた
めには、以下のいずれかの対応が必要です。
• DB インスタンスの再起動
• ALETER SYSTEM SET LOCAL_LISTENER (SCOPE=MEMORY 指定) を明示的に実行
下位バージョンの LOCAL_LISTENER の動的設定について
Oracle Clusterware 11.2 環境に、RAC 11g
g R1 などの下位バージョンの Oracle データベー
スを共存させる場合は、LOCAL_LISTENER の設定に依存せず、エージェントによる
LOCAL_LISTENER の動的設定は行いません。下位バージョンで LOCAL_LISTENER を構
成する場合は、従来通り、初期化パラメータの設定が必要です。
88
DB Home から起動するリスナーを利用する場合は、LOCAL_LISTENER を明示的に設定す
る必要があります。
る必要があります
複数サブネットで、デフォルト以外のネットワーク上に作成するリスナーに関しては、初期化パラ
メータ LISTENER_NETWORKS を明示的に設定してください。
89
90
91
92
ポリシー管理では、RAC フェイルオーバー時に、SID が変わることがあるため、インスタンス固
有の設定は排除すべきです DBCA でポリシー管理を選択した場合は、インスタンス固有のパ
有の設定は排除すべきです。DBCA
でポリシ 管理を選択した場合は インスタンス固有のパ
ラメータは設定されません。従来の <SID>.UNDO_TABLEPSPACE=‘UNDOTBS1‘ といった
インスタンスごとに異なる値を取る設定はポリシー管理では行いません。
CLUSTER_INTERCONNECTS
CLUSTER_INTERCONNECTS は、RAC のノード間通信で利用するネットワークの IP アドレ
スを指定します。ポリシー管理では、ノード障害などで、RAC インスタンスが別のサーバーにフ
ェイルオーバーするため、このようにサーバー固有の設定に対応できず、インスタンスの起動に
イルオ
するため、このようにサ
固有の設定に対応できず、インスタンスの起動に
失敗します。ポリシー管理では、CLUSTER_INTERCONNECTS を設定しないことをお奨めし
ます。
CLUSTER_DATABASE_INSTANCES
RAC 11g R1 までは、CLUSTER_DATABASE_INSTANCES を全ノードで同じ値に設定する
必要がありました。インスタンス追加を行う際は、このパラメータも変更する必要がありました。
RAC 11g R2 では、ポリシー管理 / 管理者管理共に、CLUSTER_DATABASE_INSTANCES
を明示的に設定する必要はありません DBCA で RAC データベースを作成する際もデフォル
を明示的に設定する必要はありません。DBCA
デ タベ スを作成する際もデフォル
トでは設定されません。デフォルト値は CSS から取得し、クラスタを構成するノード数に設定さ
れます。
93
例えば、2 ノード RAC 環境で、1 ノードがダウンした場合は、生存ノードで稼動するインスタン
スは1つのみです この場合 RAC インスタンスはフェイルオーバーしません。フェイルオーバ
スは1つのみです。この場合、RAC
インスタンスはフ イルオ バ しません フ イルオ バ
ー先がある、つまり、サーバー・プールで新たにサーバーを割り当てることができた場合は、
RAC インスタンスはフェイルオーバーします。
RAC インスタンスがフェイルオーバーすると、必要なファイル (初期化パラメータ・ファイルや
ALERT.LOG、トレースファイル) などは、フェイルオーバー先のサーバー上で自動的に作成さ
れるため、事前の設定は必要ありません。
管理者管理デ タ
管理者管理データベースの場合
の場合
管理者管理のインスタンスはフェイルオーバーしません。インスタンス障害発生時は、従来通り、
即時にインスタンスは再起動されます。
94
サービスの注意点
• ポリシー管理のサービスでは、以下をサポートしていません。
• 優先 / 使用可能
• TAF ポリシー (BASIC / PRECONNECT)
• 複数サブネット環境では、-k オプションを使用してサブネットを指定 (デフォルトはネットワーク
番号 1)。
srvctl add service -d orcl -s srv1 –g pool1 –k 2
• クラスタでサービス名が一意となるようにサービスを作成してください。
• 異なるデータベース間で同じサービス名を持つサービスを作成することは可能
• ただし、クライアントからの接続では、接続先のデータベースが変わる可能性があります
95
SINGLETON サービスは、明示的な優先インスタンスは持たないものの、最初に起動されたイ
ンスタンス上で全ての SINGLETON サービスが起動します。
サ ビスが起動します
SINGLETON サービスの開始
• サービスを起動するノード名、もしくは、インスタンス名を指定して起動可能
srvctl start service -d orcl -s srv1 -n stvm18 (ノード名指定)
srvctl start service -d orcl -s srv1 -i orcl_1 （インスタンス名指定)
• 全サービスを一括で開始 / 停止可能
srvctl start service -d orcl (一括開始)
srvctl stop service -d orcl （一括停止)
96
インスタンス名指定での SINGLETON サービスの手動再配置はサポートされていません。(管
理者管理 RAC データベースのサービスで使用可能)
デ タベ スのサ ビスで使用可能)
-f オプションを指定したサービスの手動再配置
-f オプションを指定すると、そのサービスで接続されているセッションは kill され、クライアント側
には、ORA-3113 などのエラーが返ります。ALERT.LOG では以下のようなメッセージが出力
され、セッションが kill されていることが確認できます。
ALERT.LOG
ALERT
LOG
Tue Aug 25 04:24:00 2009
ALTER SYSTEM SET service_names='srv1' SCOPE=MEMORY SID='orcl_1';
Immediate Kill Session#: 50, Serial#: 189
Immediate Kill Session: sess: 0x3ea6e78c OS pid: 29834
97
98
クラスタ・リソースは、サーバー障害時など、フェイルオーバーするリソースであることを表してい
ます。
ます
リソースタイプの階層構造
「resource」 タイプを起点として、「local_resource」、「cluster_resource」 タイプが作成されます。
各組み込み CRS リソースで使用するリソースタイプは、「local_resource」、
「cluster_resource」 タイプをベースとして作成されています。
resource
ローカル・リソース
クラスタ・リソース
+ local_resource
+ cluster_resource
+ ora.local_resource.type
+ ora.eons.type
+ ora.gsd.type
+ ora.listener.type
+ ora.network.type
+ application
+ ora.cluster_resource.type
+ ora.cluster_vip.type
+ ora.cluster_vip_net1.type
+ ora.scan_vip.type
+ ora.ons.type
+ ora.scan_listener.type
+ ora.asm.type
+ ora.oc4j.type
+ ora.diskgroup.type
+ ora.database.type
+ ora.registry.acfs.type
+ ora.service.type
99
クラスタ・リソースが、フェイルオーバーの対象リソースになります。サーバー障害発生時、その
サ バ 上で稼動していたリソ スは 他のサ バ にフ イルオ バ します
サーバー上で稼動していたリソースは、他のサーバーにフェイルオーバーします。
ポリシー管理の RAC データベース利用時は、サーバー障害発生時のサーバー・プールの再
構成に依存してフェイルオーバー先のサーバーが決まります。
ASM インスタンスは、ローカル・リソースです。クラスタを構成する全サーバー上で稼動するた
め、ASM インスタンスは、サーバー・プールに非依存、かつ、フェイルオーバーもしません。
11g R2 のシングル・インスタンスも管理者管理となるため、フェイルオーバーしません。
100
各 Oracle Clusterware リソースの監視間隔は、リソース属性 CHECK_INTERVAL で定義さ
れています RAC 11
れています。RAC
11g R2 では、従来と較べると、VIP
では 従来と較べると VIP および、リスナーの監視間隔が短くなり
および リスナ の監視間隔が短くなり
ました。
(*1) ASM は、OHAS エージェントにより、1 秒間隔で監視
(*2) GSD と OC4J リソースはデフォルトで OFFLINE
101
開始の依存関係は、リソースの起動順序を制御します。上記は、強い依存性 (hard) と弱い依
存性 (weak)
(
k) を図式したものです。プルアップ依存性
を図式したものです プルア プ依存性 (pullup)
( ll ) や分散依存性 (dispersion)
(di
i ) など
の他のオプションは省略しています。
データベースが ASM を利用している場合、RAC 11g R2 では、データベースは、ASM ではな
くディスクグループと依存関係を持ちます。
102
停止の依存関係は、リソースの停止順序を制御します。停止の依存関係は、強い依存性
(h d) のみです。
(hard)
のみです
103
104
105
GPnP プロファイルから有効な SPFILE を検出できなかった場合は、<Grid_home>/dbs 配下
の SPFILE / PFILE を探索します。それでも
を探索します それでも SPFILE / PFILE を見つけることができなかった場
を見つけることができなか た場
合は、デフォルトの初期化パラメータ (パラメータの設定なし) で ASM インスタンスは起動しま
す。もし、ASM SPFILE を格納した ASM ディスクが破損した場合は、デフォルトの初期化パラ
メータで ASM を一旦起動し、SPFILE のバックアップをリストアすることが可能です。
106
RAC 11g R1 までは、DB リソースで管理される SPFILE の位置を直接参照し、インスタンスを
起動していました RAC 11
起動していました。RAC
11g R2 では、initsid.ora
では i it id
に設定する情報として利用されます ポリシ
に設定する情報として利用されます。ポリシ
ー管理データベースにおいて、RAC インスタンスが再配置された際に、そのサーバー上で
initsid.ora が存在しない場合は、エージェントが自動的にファイルを生成します。ただし、
$ORACLE_HOME/dbs 配下にそれよりも優先順位の高い spfilesid.ora や spfile.ora が配置
されていると、そちらが優先されることにご注意ください。
管理者管理 RAC データベースの PFILE の使用
DBCA で管理者管理 RAC デ
データベースを作成する場合、SPFILE
タ
を作成する場合、
は、ASM もしくは、共有
は、
もしくは、共有フ
ァイルシステム上に作成されます。$ORACLE_HOME/dbs/initsid.ora でテキストファイルとして
初期化パラメータファイルを管理したい場合は、以下のように、SPFILE の場所を指定しないで
DB リソースを再作成する必要があります。
$ srvctl remove database -d orcl
$ srvctl add database -d orcl -o /opt/oracle/db -n orcl -m world -g pool1 -a DG1
→ -p オプションの指定なし
$ srvctl config database -d orcl | grep spfile
spfile:
→ null にクリアされる
初期化パラメータを定義した $ORACLE_HOME/dbs/initsid.ora を RAC を
構成するサーバー上に配置することで、ＰＦＩＬＥ での運用が可能です。
107
(*1) SCAN リスナーのログは、自動診断リポジトリ (ADR) の仕様に基づいて出力されます。そ
のため O l Cl
のため、Oracle
Clusterware
t
を起動する OS ユーザの環境変数
ユ ザの環境変数 ORACLE_BASE
ORACLE BASE に依存しま
す。通常、OS 起動時に起動される Oracle Clusterware では、ORACLE_BASE は設定されて
いないため、<Grid_Home>/log 配下に出力されます。Oracle Clusterware を手動で起動する
際に、OS ユーザの環境変数に、ORACLE_BASE が設定されている場合は、その配下に
SCAN リスナーのログが出力されます。
108
109
110
111