oracle database 11g release 2 oracle clusterware ......oracle clusterware...

本資料では、以下の省略表記を使用している箇所があります。

名称省略表記

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

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 11 R2 では G id I f t t をインストリが、/etc/inittab に3行追加されていました。RAC 11g R2 では、Grid Infrastructure をインストールすると、/etc/inittab に下記の ohasd 用のエントリが1行追加されます。

スタンドアロン・サーバー用 Grid Infrastructureスタンドアロン・サーバー用 Grid Infrastructure は、RAC 11g R2 から導入された新しいインストのオプシンですシングインタン環境に従来の CRS リのような障害時の

h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null

トールのオプションです。シングル・インスタンス環境に従来の CRS リソースのような障害時の自動再起動の仕組みを実装したインストール・オプションです。

13

RAC 11g R2 では、Oracle Custerware プロセスおよび、リソースはエージェントにより監視を行い O l Cl t の高可用性を実現します OHAS エジントは主に O l行い、Oracle Clusterware の高可用性を実現します。OHAS エージェントは主に、Oracle 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

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 stvm20ONLINE ONLINE stvm21

ora.LISTENER.lsnrONLINE ONLINE stvm20ONLINE ONLINE stvm21

ora.asmONLINE ONLINE stvm20ONLINE ONLINE stvm21

ora.eonsONLINE ONLINE stvm20ONLINE ONLINE stvm20ONLINE ONLINE stvm21

ora.gsdOFFLINE OFFLINE stvm20OFFLINE OFFLINE stvm21

ora.net1.networkONLINE ONLINE stvm20ONLINE ONLINE stvm21

ora.onsONLINE ONLINE stvm20ONLINE ONLINE t 21ONLINE ONLINE stvm21

ora.registry.acfsONLINE ONLINE stvm20ONLINE ONLINE stvm21

--------------------------------------------------------------------------------Cluster Resources--------------------------------------------------------------------------------ora.LISTENER_SCAN1.lsnr

1 ONLINE ONLINE stvm20ora.LISTENER SCAN2.lsnr_

1 ONLINE ONLINE stvm20ora.LISTENER_SCAN3.lsnr

1 ONLINE ONLINE stvm21ora.oc4j

1 OFFLINE OFFLINEora.orcl.db

1 ONLINE ONLINE stvm202 ONLINE ONLINE stvm21

ora.orcl.srv_a.svc1 ONLINE ONLINE t 201 ONLINE ONLINE stvm202 ONLINE ONLINE stvm21

ora.scan1.vip1 ONLINE ONLINE stvm20



ora.stvm20.vip1 ONLINE ONLINE stvm20

18


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 が起動を開始 (*1)7. CSS 起動完了後に、ASM が起動を開始 ( 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

RAC 11g R1 までは、ネットワークや投票ディスクなどの情報は、OCR で管理されていました。OCR を ASM で管理する場合 OCR へアクセスするためには ASM インスタンスが起動してOCR を ASM で管理する場合、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 プロファイルも自動的に更新されますィスクの配置を変更した場合は、 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>

ネットワーク情報

</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 ではインタコネクト情報を GP P プロフイルから取得しますそのため ASM / DB Al t lは、インターコネクト情報を GPnP プロファイルから取得します。そのため、ASM / DB Alert.log では、インスタンス起動時に以下のメッセージが出力されます。

DB Alert.log の例

Thu Aug 13 02:20:30 2009Starting ORACLE instance (normal)LICENSE_MAX_SESSION = 0LICENSE SESSIONS WARNING = 0

GPNPD 障害などで通信に失敗した場合は、以下のメッセージが出力されます。

LICENSE_SESSIONS_WARNING = 0Interface type 1 eth1 10.10.1.0 configured from GPnP Profile for use as a cluster interconnectInterface type 1 eth0 10.185.144.0 configured from GPnP Profile for use as a public interfacePicked latch-free SCN scheme 2

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 = 10interconnect information is not available from GPnP ProfileWARNING: No cluster interconnect has been specified. Depending on

the communication driver configured Oracle cluster trafficb di t d t th bli i t f f thi hi

26

may be directed to the public interface of this machine.Oracle recommends that RAC clustered databases be configuredwith a private interconnect for enhanced security andperformance.

Picked latch-free SCN scheme 2

GPnP プロファイルは、バージョン管理されています。プロファイルに変更があった場合は、内部的に保持しているシケンス番号が増えます O l Cl t 起動時には fil l部的に保持しているシーケンス番号が増えます。Oracle Clusterware 起動時には、profile.xml / OLR / OCR 間、および他ノードのシーケンス番号の比較を行い、シーケンス番号がも大きいプロファイル ( 新のプロファイル) が採用されます。この仕組みにより、以下の状況にも対応可能です。

• OLR / OCR の破損などで、以前のバックアップをリストアした場合

次回 Oracle Clusterware 起動時に、自動的に新のプロファイルに更新されます。

• 他ノードが停止していた場合のプロファイルの更新

他ノードが停止していた状況で、ASM SPFILE や投票ディスクの配置変更を行った場合、停止ノードではプロファイルの更新は行われませんが、次回 Oracle Clusterware 起動時に、自動的に新のプロファイルに更新されます。

ここでのバージョン管理は、GPnP プロファイル部分のみです。OCR / OLR 全体が新に更新されるという意味ではありません。新されるという意味ではありません。

27

RAC 11g R2 では、Oracle Clusterware プロセスも内部的にリソース管理されます。そのため、O l Cl t プロセスは OHAS リソスと呼ばれることもあります従来の CRS リソOracle Clusterware プロセスは、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.olrcrs_home=/opt/gridhome

root.sh 実行時の OLR の自動バックアップ

Grid Infrastructure インストール時の root.sh 実行時に、以下のように、OLR のバックアップが取得されます。

# ./root.sh... OLR のバックアップを取得CRS-2672: 'ora.evmd'('stvm17')の起動を試行しています

CRS-2676: 'ora.evmd'('stvm17')の起動が成功しました

stvm17 2009/08/27 00:33:35 /opt/gridhome/cdata/stvm17/backup_20090827_003335.olrConfigure Oracle Grid Infrastructure for a Cluster ... succeededクラスタウェアのインベントリ・プロパティの更新中

Oracle Universal Installerを起動中です...…

ックアッを取得

29

各 Oracle Clusterware プロセスの監視間隔は、OLR 内のリソース属性 CHECK_INTERVAL として定義されていますプロセス障害が発生するとエジントがプロセスの再起動を行いとして定義されています。プロセス障害が発生すると、エージェントがプロセスの再起動を行います (CSS 障害の場合は、ノードリブート)。また、リソース名や使用するエージェントの定義もリソース属性として定義されています。

(*1) oraagent は、1 秒間隔で ASM インスタンスを監視し、インスタンス障害が発生した場合は、即時に ASM インスタンスを再起動させます。oraagent は、11g R1 までのインスタンス・モニタ(racgimon) と同等の監視を行います。

(*2) CSS に障害が発生すると、cssdagent は即時にノードを再起動させます。30 秒間隔の監視は、CSS のステータスを監視しています。

31

OLR の手動バックアップの実行例新たにバックアップされたファイル

OLR のバックアップ情報の確認

# ocrconfig -local -manualbackup

stvm16 2009/08/15 23:24:09 /opt/gridhome/cdata/stvm16/backup_20090815_232409.olr


# ocrconfig -local -showbackup



32

補足事項

• OLR の自動バックアップの機能はありません

• OLR の多重化は不可 (各ノード1つのみ)• OLR の追加 / 削除は不可

• OLR が破損すると、Oracle Clusterware は起動不可 (バックアップからのリストアが必要)

33

RAC 11g R1 までは、ASM は、CRS リソースとして管理されていました。CRS デーモンがOCR をオプンし各リソスを起動する中で ASM インスタンスも起動していましたしかしOCR をオープンし、各リソースを起動する中で、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 restore neverAUTO_START restore never

CHECK_INTERVAL 1 60

34

ASMCA で ASM を構成すると、デフォルトで ASM の SPFILE は ASM 管理されます。

SQL*Plus もしくは、SRVCTL で ASM インスタンスを起動する場合も、GPnP プロファイルから情報を取得するため、ASM SPFILE を使用した ASM インスタンスの起動は可能です。

インスタンス起動中の SPFILE へのアクセスは読み込みのみ許可されています。そのため、SPFILE 内の初期化パラメータを変更するためには、ASM インスタンスが起動されている必要があります。

SPFILE を格納したディスクグループは、ASM インスタンス起動時に自動的にマウントされます。

SPFILE の確認方法SPFILE の確認方法

以下のコマンドで、GPnP プロファイル内の SPFILE のパスやディスク検出文字列を確認することが可能です。

$ asmcmd spget+DATA/jpintl cluster/asmparameterfile/registry 253 696194007+DATA/jpintl-cluster/asmparameterfile/registry.253.696194007

$ asmcmd dsgetparameter:/dev/xvdb*profile:/dev/xvdb*

36

RAC 11g R2 では、Oracle Clusterware と ASM を統合した Grid Infrustructure を提供します。また O l Cl t に必要な OCR / 投票ディスクを ASM 管理するため従来のようなまた、Oracle Clusterware に必要な OCR / 投票ディスクを ASM 管理するため、従来のようなASM インスタンスのみ停止する操作に制限がかけられています。

以下は、各種停止コマンドにおける ASM の停止の可否を表しています。

ASM で管理しているファイル

停止方法 SPFILE OCR / 投票ディスク

tl t (*1) × ×svctl stop asm (*1) × ×

svctl stop asm –f (*2) ○ ×

shutdown (normal / immediate)

○ ×

shutdwn abort ○ ○

crsctl stop crs ○ ○

(*1) OCR / 投票ディスクを ASM 管理している場合は、ASM の停止は不可

(*2) SPFILE のみ ASM 管理している場合は、-f オプションを指定することで停止することは可能 (この場合、OCR / 投票ディスクは、共有ファイルシステムに配置)

crsctl stop cluster ○ ○

37

CSS は自ら投票ディスクを検出し、I/O を実行することができるため、ASM インスタンス障害が発生しても O l Cl t は稼動し続けることが可能です発生しても、Oracle Clusterware は稼動し続けることが可能です。

38

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 環境で利用されるデモン。GNS を使用して名前解決を行う際のレスポンダとしての役割を担います。

Oracle Agent (oraagent)Oracle Clusterware プロセスの障害監視を行うエージェント (root 所有以外)。監視対象としては、GPNPD, EVM などが含まれます。

Oracle Root Agent (orarootagent)Oracle Clusterware プロセスの障害監視を行うエージェント (root 所有)。監視対象としては、CRS, CTSS などが含まれますCTSS などが含まれます。

cssdagent / cssdmonitorCSS の状態を監視するエージェント。CSS の起動 / 停止 / 監視の主要な役割は、cssdagent が担います。

Oracle ACFS ドライバ

Oracle ACFS / Oracle Kernel Services (OKS) / Oracle ADVM ドライバを管理。リソースを開始すると、ドライバは OS 上にロードされます。Grid Infrastructure インストール時に Oracle ACFS ドライバも自動的にインストルされます

40

的にインストールされます。

cssdagent / cssdmonitor に障害が発生しても、OHAS デーモンが即時に、エージェントの再起動を行います d t 障害時から再起動するまでの間も CSS の継続監視を行うために動を行います。cssdagent 障害時から再起動するまでの間も CSS の継続監視を行うために、cssdmonitor が導入されています。

RAC 11g R1 までは、CSS 障害発生時のノード再起動は、init スクリプト (init.ocssd) で行われていまいた。RAC 11g R2 では、cssdagent がノードの再起動を行います。

oprocd / oclsvmon / oclsomondoprocd

プロセッサ・デーモンとしての役割を担います。プロセッサ (CPU) がストールしているか否かをチェックし、ストールしている場合はノードを強制的に再起動します。これにより、 I/O Fencing に似たメカニズムを提供し、データ障害を未然に防ぎます。

oclsvmonCSS プロセス障害時にログを出力させる役割を担います。特定のベンダークラスタウェアが動作している環境下でのみ起動します。

oclsomonoclsomonCSS がハングしていないかどうかを監視する役割を担います。CSS がハングしている場合は、ノードを強制的に再起動します。

hangcheck timer モジュールの必要性

Linux 環境では、10.2.0.4 / 11.1 からノードハングの監視を目的として、 oprocd が導入されました。また、ノードハングの監視として、hangcheck timer モジュールも併用するようご案内していました RAC 11g R2 ではノードおよび CSS の状態を CSS エージェントが統合監視するこ

41

いました。RAC 11g R2 では、ノドおよび CSS の状態を CSS エジェントが統合監視することで、障害に対する精度の高い監視が可能になっています。そのため、RAC 11g R2 では、hangcheck timer モジュールの設定は要件から外れました (設定する必要はありません)。

CSS のハングは、CSS エージェントが監視を行います。CSS エージェント (cssdagent / d it のいずれか) がハングすると CSS がハングしているかどうかの監視を行うことcssdmonitor のいずれか) がハングすると、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 misscount30# crsctl get css reboottime3# crsctl get css disktimeout200

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 ASMOCR / 投票ディスクを配置するディスク管理として利用します。

Disk Monitor (DISKMON) デーモン

HP Oracle Exadata Storage Server ストレージの監視および、I/O フェンシングを実行します。CSS を開g トジの監視および、ンシングを実行します。を開始する際は、DISKMON も同時に開始されます。

Oracle Agent (oraagent)Oracle Clusterware リソースの障害監視を行うエージェント (root 所有以外)。監視対象としては、DB, リスナー, ONS などが含まれます。また、FAN イベントが起きた場合、サーバー・コールアウトを実行します。

Oracle Root Agent (orarootagent)Oracle Clusterware リソースの障害監視を行うエージェント (root 所有)。監視対象としては、VIP, ネットワークなどが含まれます。

43

ワクなどが含まれます。

全てのリソースは、リソースタイプを持ちます。RAC 11g R1 までは、リソースタイプは、「 li ti 」のみでリソス作成時に必要なリソス属性を全て定義する必要がありました「application」のみで、リソース作成時に必要なリソース属性を全て定義する必要がありました。RAC 11g R2 では、予めリソースタイプでリソース属性を定義できるため、リソース作成時は、必要小限の定義で済みます。RAC 11g R2 でも、「application」タイプは利用可能ですが、下位互換のために存在します。

リソースタイプの利点

• リソースの特性に応じて、属性テンプレートの作成が可能

• リソース作成時は必要なリソース属性のみ定義• リソース作成時は、必要なリソース属性のみ定義

• リソースタイプに基づく依存性の構築が可能

リソースタイプの確認方法

現在、作成されているリソースタイプを確認するためには、crsctl status type コマンドを実行します。TYPE_NAME はタイプ名、BASE_TYPE は参照元 (親となる) タイプです。

$ crsctl status typeTYPE_NAME=applicationBASE_TYPE=cluster_resource

TYPE_NAME=cluster_resourceBASE_TYPE=resource

TYPE_NAME=local_resourceBASE TYPE=resource

47

BASE_TYPE=resource

TYPE_NAME=resourceBASE_TYPE=

「local_resource」、「cluster_resource」タイプは、組み込みリソースタイプで、Grid I f t t インストル時に自動的に作成されます組み込み CRS リソスやカスタムアInfrastructure インストール時に自動的に作成されます。組み込み CRS リソースやカスタム・アプリケーションで利用されます。「cluster_resource」タイプは、フェイルオーバー関連のリソース属性 (PLACEMENT, SERVER_POOLS など) が定義されています。「local_resource」にはその定義はありません。

ローカル・リソース / クラスタ・リソースの稼動確認

カスタム・アプリケーションの apps1 (ローカル・リソース) と apps2 (クラスタ・リソース) を作成および、開始した後の状態出力例を以下に示します。および、開始した後の状態出力例を以下に示します。

-- ローカル・リソース

-- 各サーバー上で起動 (ONLINE)$ crsctl status resource apps1NAME=apps1TYPE=local_resourceTARGET=ONLINE , ONLINE , ONLINE , ONLINESTATE=ONLINE on serv1, ONLINE on serv2, ONLINE on serv3, ONLINE on serv4STATE ONLINE on serv1, ONLINE on serv2, ONLINE on serv3, ONLINE on serv4

-- クラスタ・リソース

-- クラスタ内のいずれかのサーバー上で起動 (ONLINE)$ crsctl status resource apps2NAME=apps2TYPE=cluster_resourceTARGET=ONLINESTATE=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_RESOURCESREQUIRED_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 ユーティリティをご利用ください。従来の fil などの * コマンドは下位互換のために存在します従来の crs_profile などの crs_* コマンドは、下位互換のために存在します。

58

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 R2 では O l Cl t および ASM を統合したインストル (G idた。RAC 11g R2 では、Oracle Clusterware および ASM を統合したインストール (Grid 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


ora.LISTENER.lsnrONLINE ONLINE stvm20ONLINE ONLINE stvm21

ora.asmONLINE ONLINE stvm20ONLINE ONLINE stvm21

ora.eonsONLINE ONLINE stvm20

ローカル・リソース

各サーバー上で起動



ora.net1.networkONLINE ONLINE stvm20ONLINE ONLINE stvm21

ora.onsONLINE ONLINE stvm20ONLINE ONLINE t 21ONLINE ONLINE stvm21

ora.registry.acfsONLINE ONLINE stvm20ONLINE ONLINE stvm21

--------------------------------------------------------------------------------Cluster Resources--------------------------------------------------------------------------------ora.LISTENER_SCAN1.lsnr

1 ONLINE ONLINE stvm20ora.LISTENER SCAN2.lsnr

クラスタ・リソース

_1 ONLINE ONLINE stvm20

ora.LISTENER_SCAN3.lsnr1 ONLINE ONLINE stvm21

ora.oc4j1 OFFLINE OFFLINE

ora.orcl.db1 ONLINE ONLINE stvm202 ONLINE ONLINE stvm21

ora.orcl.srv_a.svc1 ONLINE ONLINE t 20 クラスタリソス

クラスタ内のいずれかの

サーバー上で起動

1 ONLINE ONLINE stvm202 ONLINE ONLINE stvm21





66


RAC 11g R1 までは、クラスタ・リソースのみで管理していました。全サーバーで稼動するリソース (ロカルリソス) を作成する際はクラスタリソスを全サバ分作成して個々のリス (ローカル・リソース) を作成する際は、クラスタ・リソースを全サーバー分作成して、個々のリソースとして管理していました。RAC 11g R2 では、クラスタ・リソース / ローカル・リソースの概念を取り入れることで、ローカル・リソースも単一のリソースとして管理します。

68

RAC 11g R1 までは、ノードアプリケーションを構成するリソースは、クラスタ内のサーバー別に

リソスが作成されそれを識別するためにリソスの名前にはホスト名が付いていましたリソースが作成され、それを識別するためにリソースの名前には、ホスト名が付いていました。RAC 11g R2 では、単一のリソースと扱うため、リソースの名前からホスト名を排除しています。

$ crsctl status resource -t…ora.LISTENER.lsnr

ONLINE ONLINE stvm16

単一のリソースとして管理

各メンバーごとのステータスを表示

ONLINE ONLINE stvm17ora.asm

ONLINE ONLINE stvm16 StartedONLINE ONLINE stvm17 Started


ora.onsONLINE ONLINE stvm16ONLINE ONLINE stvm16ONLINE ONLINE stvm17

…ora.stvm16.vip

1 ONLINE ONLINE stvm16ora.stvm17.vip

1 ONLINE ONLINE stvm17

VIP は従来と同じ

69

RAC 11g R2 ではインスタンスおよび、サービス・メンバーのリソースは排除され、それぞれ単のリソスとして管理されます一のリソースとして管理されます。

$ crsctl status resource -t…ora.asm

ONLINE ONLINE stvm16 StartedONLINE ONLINE stvm17 Started

...ora.orcl.db

単一のリソースとして管理

ora.orcl.db1 ONLINE ONLINE stvm16 Open2 ONLINE ONLINE stvm17 Open

ora.orcl.srv1.svc1 ONLINE ONLINE stvm162 ONLINE ONLINE stvm17

70

メンバー固有で管理するリソース属性に関しては、-v オプションを付けて確認することができますす。

$ crsctl status resource ora.orcl.db -vNAME=ora.orcl.dbTYPE=ora.database.typeLAST_SERVER=stvm16STATE=ONLINE on stvm16TARGET=ONLINECARDINALITY ID=1

インスタンスのステータスCARDINALITY_ID=1CREATION_SEED=65CURRENT_RCOUNT=0FAILURE_COUNT=0FAILURE_HISTORY=ID=ora.orcl.db 1 1INCARNATION=2LAST_RESTART=1250954892STATE_DETAILS=Open

インスタンス障害が起きると、

CURRENT_RCOUNT がカウントアップされる

_ p

LAST_SERVER=stvm17STATE=ONLINE on stvm17TARGET=ONLINECARDINALITY_ID=2CREATION_SEED=65CURRENT_RCOUNT=0FAILURE_COUNT=0FAILURE HISTORY

71

FAILURE_HISTORY=ID=ora.orcl.db 2 1INCARNATION=1LAST_RESTART=1250954995STATE_DETAILS=Open

ネットワーク・リソース

crsctl status resource では、以下のようにネットワーク・リソースのステータスを確認できます。

ネットワーク番号

$ crsctl status resource –t…ora.net1.network


ネットワク番号

ネットワーク・リソースは、ネットワーク番号を持ちます。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 リスナ• SCAN リスナー

• サービス

• VIP (デフォルトリスナー、全サービス停止後)• SCAN VIP (SCAN リスナー停止後)

5. サービスを別のインスタンスで起動 (SINGLETON の場合)6. VIP / SCAN VIP をフェイルオーバー先のサーバーで起動

7. SCAN リスナーをフェイルオーバー先のサーバーで起動 (SCAN VIP 起動後)

75

RAC 11g R1 までは、ネットワーク障害の回復後、DB インスタンスの監視 (5分間隔) の際に、VIP をフイルバクすることは可能でしたただしネトワクが回復したことを直接検知する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.vipNAME=ora.stvm16.vipTYPE=ora.cluster_vip_net1.typeTARGET=ONLINESTATE=ONLINE on stvm16

* 「stvm16」のサーバーに障害が発生

$ crsctl status resource ora.stvm16.vipNAME=ora.stvm16.vipTYPE=ora.cluster_vip_net1.typeTARGET=ONLINESTATE=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 stvm19ora.LISTENER_SCAN2.lsnr

1 ONLINE ONLINE stvm18ora LISTENER SCAN3 lsnrora.LISTENER_SCAN3.lsnr

1 ONLINE ONLINE stvm17…ora.scan1.vip

1 ONLINE ONLINE stvm19ora.scan2.vip

1 ONLINE ONLINE stvm18ora.scan3.vip

1 ONLINE ONLINE stvm17

scan1 / scan2 / scan3 の VIP とリスナーは、

それぞれ同じサーバー上に配置

78

SCAN VIP / SCAN リスナーの手動再配置

通常は、クラスタ内のサーバー上で分散配置されるため、手動での再配置は必要ありません。以下のように、サーバーのメンテナンスなどで、SCAN を他のサーバーに移動させたい場合に手動で再配置することが可能です。いずれのコマンドも SCAN VIP / SCAN リスナー両方、同じサーバー上に再配置します。

SCAN VIP の再配置

srvctl relocate scan -i <scan number> [-n <node name>]

SCAN リスナーの再配置

s ct e ocate sca sca _ u be [ ode_ a e ]例) srvctl relocate scan -i 1 -n serv1

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つの VIP を構成できブネットごとに VIP を作成することが可能になります。1つのサブネットに1つの VIP を構成できます。同じサブネットに複数の VIP は構成できません。

セキュリティ要件や負荷分散の観点で、サブネットを分離したい場合に有効です。


複数サブネットに対して VIP を作成した際のネットワーク・リソースのステータスは以下のようになります。

$ crsctl status resource –t…ora.net1.network


ora.net2.networkONLINE ONLINE stvm16ONLINE ONLINE t 17

デフォルトのネットワーク・リソース

異なるサブネットに VIP を作成した際の


ネットワーク番号

ネットワーク・リソースは、ネットワーク番号を持ちます。Grid Infrastructure インストール時に構成されるネットワークのネットワーク番号は 1 (デフォルト) です。RAC 11g R2 の新機能で、複数サブネットに対して、VIP を作成することが可能です。その場合は、サブネットごとにネットワーク番号 (2,3…) を割り当て、それに応じたネットワーク・リソース (ora.net(2,3…).network) が作成されます。

ONLINE ONLINE stvm17

80

RAC 11g R2 では、listener.ora にエンドポイントの設定は行いません。エンドポイントの情報

はリソスの属性として保持しリスナ起動時にエジントが動的に設定を行いますそは、リソースの属性として保持し、リスナー起動時にエージェントが動的に設定を行います。そのため、リスナーの構成を変更 (ポート番号の変更など) することによる listener.ora の編集は不要です。

リスナー起動時の動作

1. リスナー起動 (srvctl start listener を実行)2. CRS が oraagent にリスナー開始を実行

3 t はリナを起動3. oraagent は、リスナーを起動

4. oraagent は、ローカルの VIP とリスナーのポート番号からエンドポイントを生成

5. oraagent は、リスナーにエンドポイントを登録

登録されたリスナーのエンドポイントの確認

lsnrctl コマンドにより、リスナーのエンドポイントの確認が可能です。リスナーのエンドポイントの先頭は、常に IPC のエントリがくるため、ネットワーク障害時などにおけるリスナー停止で時間を要する (TCP タイムアウトを待つ) ことはありません。

$ lsnrctl status LISTENER…リスニング・エンドポイントのサマリー...(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=<VIP Address>)(PORT=1521)))

エージェントによって、動的に登録されたエンドポイント

(VIP とパブリック IP がリスニングアドレスとして登録)

83

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=<Public IP>)(PORT=1521)))サービスのサマリー...サービス"+ASM"には、1件のインスタンスがあります。

インスタンス"+ASM1"、状態READYには、このサービスに対する1件のハンドラがあります...コマンドは正常に終了しました。

RAC 11g R2 で、listener.ora の設定が無効 (無視) になったわけではありません。リスナーを起動する際は li t を読み込んで起動しているため li t のパラメタなどの起動する際は、listener.ora を読み込んで起動しているため、listener.ora のパラメータなどの設定は11g R2 でも有効です。

リスナーの設定確認

現在のリスナーの設定を確認するためには、srvctl config listener を実行します。

$ srvctl config listener -l LIS112名前: LIS112

listener.ora の内容

listener.ora には、以下のようにエージェントが動的に追加した IPC のエントリがあります。これはエージェントがリスナーに接続するための情報になります。

名前: LIS112ネットワーク: 1、所有者: gridホーム: <CRS home>エンド・ポイント: TCP:1525

はジントがリナに接続するための情報になります。

endpoints_listener.ora ファイル

<Grid_home>/network/admin 配下には、endpoints_listener.ora というファイルがあります。これは Oracle Clusterware 配下に下位のバジョンのデタベスが共存し 11g R2

LISTENER=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))) # line added by Agent

84

これは、Oracle Clusterware 配下に、下位のバージョンのデータベースが共存し、 11g R2 ASM を認識する際に利用されるファイルになります。11g R2 のみの環境ではこのファイルは利用されません。

RAC 11g R2 では、DBCA は LOCAL_LISTENER の設定を行いません。LOCAL LISTENER の設定はロカルの VIP やリスナ情報を読み取りエジントによ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. PMON がロカル上で稼動するリスナに対して、サビスを登録 (リスナ経由の接続が可能に)

インスタンス起動時の ALERT.LOG

Fri Aug 14 23:41:59 2009Starting ORACLE instance (normal) エージェントにより、動的に設定された LOCAL_LISTENER

85

…Completed: ALTER DATABASE OPENFri Aug 14 23:42:28 2009ALTER SYSTEM SET local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=stvip03)(PORT=1521))))' SCOPE=MEMORY SID='orcl_1';

RAC 11g R2 の DBCA で RAC データベース (管理者管理 / ポリシー管理両方) を作成する際はデフォルトで以下のように構成されます際は、デフォルトで以下のように構成されます。

• LOCAL_LISNTENER (設定なし)• REMOTE_LISTENER=“<SCAN 名>:ポート番号“

デフォルトリスナーには、ローカルで起動しているインスタンスのサービスのみが登録されます。SCAN リスナーでは、クラスタで稼動する全サービスの情報が登録されます。

86

リスナーの構成変更を LOCAL_LISTENER に反映する方法

リスナーの新規作成もしくは、変更を行った場合、それを LOCAL_LISTENER に反映させるためには、以下のいずれかの対応が必要です。

• DB インスタンスの再起動

• ALETER SYSTEM SET LOCAL_LISTENER (SCOPE=MEMORY 指定) を明示的に実行

下位バージョンの LOCAL_LISTENER の動的設定について

Oracle Clusterware 11.2 環境に、RAC 11g R1 などの下位バージョンの Oracle データベーgスを共存させる場合は、LOCAL_LISTENER の設定に依存せず、エージェントによるLOCAL_LISTENER の動的設定は行いません。下位バージョンで LOCAL_LISTENER を構成する場合は、従来通り、初期化パラメータの設定が必要です。

88

DB Home から起動するリスナーを利用する場合は、LOCAL_LISTENER を明示的に設定する必要がありまする必要があります。

複数サブネットで、デフォルト以外のネットワーク上に作成するリスナーに関しては、初期化パラメータ LISTENER_NETWORKS を明示的に設定してください。

89

ポリシー管理では、RAC フェイルオーバー時に、SID が変わることがあるため、インスタンス固有の設定は排除すべきです DBCA でポリシ管理を選択した場合はインスタンス固有のパ有の設定は排除すべきです。DBCA でポリシー管理を選択した場合は、インスタンス固有のパラメータは設定されません。従来の <SID>.UNDO_TABLEPSPACE=‘UNDOTBS1‘ といったインスタンスごとに異なる値を取る設定はポリシー管理では行いません。

CLUSTER_INTERCONNECTSCLUSTER_INTERCONNECTS は、RAC のノード間通信で利用するネットワークの IP アドレスを指定します。ポリシー管理では、ノード障害などで、RAC インスタンスが別のサーバーにフ

ェイルオーバーするため、このようにサーバー固有の設定に対応できず、インスタンスの起動にイルオするため、このようにサ固有の設定に対応できず、インスタンスの起動に失敗します。ポリシー管理では、CLUSTER_INTERCONNECTS を設定しないことをお奨めします。

CLUSTER_DATABASE_INSTANCESRAC 11g R1 までは、CLUSTER_DATABASE_INSTANCES を全ノードで同じ値に設定する

必要がありました。インスタンス追加を行う際は、このパラメータも変更する必要がありました。RAC 11g R2 では、ポリシー管理 / 管理者管理共に、CLUSTER_DATABASE_INSTANCES を明示的に設定する必要はありません DBCA で RAC デタベスを作成する際もデフォルを明示的に設定する必要はありません。DBCA で RAC データベースを作成する際もデフォルトでは設定されません。デフォルト値は 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 サービスが起動します。

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 デタベスのサビスで使用可能)理者管理 RAC データベースのサービスで使用可能)

-f オプションを指定したサービスの手動再配置

-f オプションを指定すると、そのサービスで接続されているセッションは kill され、クライアント側には、ORA-3113 などのエラーが返ります。ALERT.LOG では以下のようなメッセージが出力され、セッションが kill されていることが確認できます。

ALERT LOGALERT.LOGTue Aug 25 04:24:00 2009ALTER SYSTEM SET service_names='srv1' SCOPE=MEMORY SID='orcl_1';Immediate Kill Session#: 50, Serial#: 189Immediate Kill Session: sess: 0x3ea6e78c OS pid: 29834

97

クラスタ・リソースは、サーバー障害時など、フェイルオーバーするリソースであることを表していますます。

リソースタイプの階層構造

「resource」タイプを起点として、「local_resource」、「cluster_resource」タイプが作成されます。各組み込み CRS リソースで使用するリソースタイプは、「local_resource」、「cluster_resource」タイプをベースとして作成されています。

ローカル・リソース

+ local_resource

+ ora.local_resource.type

+ ora.eons.type

+ ora.gsd.type

クラスタ・リソース

+ cluster_resource

+ application

+ ora.cluster_resource.type

+ ora.cluster_vip.type

resource

+ ora.listener.type

+ ora.network.type

+ ora.ons.type

+ ora.asm.type

+ ora.diskgroup.type

+ ora.registry.acfs.type

+ ora.cluster_vip_net1.type

+ ora.scan_vip.type

+ ora.scan_listener.type

+ ora.oc4j.type

+ ora.database.type

+ ora.service.type

99

クラスタ・リソースが、フェイルオーバーの対象リソースになります。サーバー障害発生時、そのサバ上で稼動していたリソスは他のサバにフイルオバしますサーバー上で稼動していたリソースは、他のサーバーにフェイルオーバーします。

ポリシー管理の RAC データベース利用時は、サーバー障害発生時のサーバー・プールの再構成に依存してフェイルオーバー先のサーバーが決まります。

ASM インスタンスは、ローカル・リソースです。クラスタを構成する全サーバー上で稼動するため、ASM インスタンスは、サーバー・プールに非依存、かつ、フェイルオーバーもしません。

11g R2 のシングル・インスタンスも管理者管理となるため、フェイルオーバーしません。

100

各 Oracle Clusterware リソースの監視間隔は、リソース属性 CHECK_INTERVAL で定義されています RAC 11 R2 では従来と較べると VIP およびリスナの監視間隔が短くなりれています。RAC 11g R2 では、従来と較べると、VIP および、リスナーの監視間隔が短くなりました。

(*1) ASM は、OHAS エージェントにより、1 秒間隔で監視

(*2) GSD と OC4J リソースはデフォルトで OFFLINE

101

開始の依存関係は、リソースの起動順序を制御します。上記は、強い依存性 (hard) と弱い依存性 ( k) を図式したものですプルアプ依存性 ( ll ) や分散依存性 (di i ) など存性 (weak) を図式したものです。プルアップ依存性 (pullup) や分散依存性 (dispersion) などの他のオプションは省略しています。

データベースが ASM を利用している場合、RAC 11g R2 では、データベースは、ASM ではなくディスクグループと依存関係を持ちます。

102

停止の依存関係は、リソースの停止順序を制御します。停止の依存関係は、強い依存性(h d) のみです(hard) のみです。

103

GPnP プロファイルから有効な SPFILE を検出できなかった場合は、<Grid_home>/dbs 配下の SPFILE / PFILE を探索しますそれでも SPFILE / PFILE を見つけることができなかた場の SPFILE / PFILE を探索します。それでも SPFILE / PFILE を見つけることができなかった場合は、デフォルトの初期化パラメータ (パラメータの設定なし) で ASM インスタンスは起動します。もし、ASM SPFILE を格納した ASM ディスクが破損した場合は、デフォルトの初期化パラメータで ASM を一旦起動し、SPFILE のバックアップをリストアすることが可能です。

106

RAC 11g R1 までは、DB リソースで管理される SPFILE の位置を直接参照し、インスタンスを起動していました RAC 11 R2 では i it id に設定する情報として利用されますポリシ起動していました。RAC 11g R2 では、initsid.ora に設定する情報として利用されます。ポリシー管理データベースにおいて、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 spfilespfile:→ null にクリアされる

初期化パラメータを定義した $ORACLE_HOME/dbs/initsid.ora を RAC を構成するサーバー上に配置することで、ＰＦＩＬＥでの運用が可能です。

107

(*1) SCAN リスナーのログは、自動診断リポジトリ (ADR) の仕様に基づいて出力されます。そのため O l Cl t を起動する OS ユザの環境変数 ORACLE BASE に依存しまのため、Oracle Clusterware を起動する OS ユーザの環境変数 ORACLE_BASE に依存します。通常、OS 起動時に起動される Oracle Clusterware では、ORACLE_BASE は設定されていないため、<Grid_Home>/log 配下に出力されます。Oracle Clusterware を手動で起動する際に、OS ユーザの環境変数に、ORACLE_BASE が設定されている場合は、その配下にSCAN リスナーのログが出力されます。

108

110110

oracle database 11g release 2 oracle clusterware ......oracle clusterware...

Documents