1
2
本資料では 以下の省略表記を使用している箇所があります 名称 省略表記 Baseboard Management Controller BMC Cluster Ready Services CSS Cluster Time Synchronization Service CTSS Cluster Verification Utility CVU Database Configuration Assistant DBCA Domain Name Service DNS Dynamic Host Configuration Protocol DHCP Enterprise Manager EM Grid Plug and Play ( プロファイル ) GPnP ( プロファイル ) Grid Naming Service GNS Intelligent Platform Management Interface IPMI multicast Domain Name Service mdns Network Interface Card NIC Network Time Protocol NTP Oracle Universal Installer OUI Oracle Automatic Storage Management Oracle ASM (ASM) Oracle ASM Cluster File System Oracle ACFS (ACFS) Oracle High Availability Services OHAS Oracle Cluster Registry OCR Single Client Access Name SCAN Virtual IP VIP 3
4
5
6
従来は システムごとにサーバーが管理され リソースの配置は物理サーバーに制限されていました そのため RAC データベースのインスタンスが起動する物理サーバーは固定され システムごとに RAC データベースが別々に構築され 管理されていました クラスタへのノードの追加作業や構成変更は ノード固有の情報の指定や更新を全てのノードに対して行う必要がありました 7
8
9
GPnP プロファイルの詳細について Oracle Clusterware アーキテクチャ の資料を参照ください Single Client Access Name (SCAN) の詳細については Real Application Clusters ( ポリシーベース管理 ) の資料を参照ください 10
11
12
13
14
クラスタ名は作成するクラスタのメンバー ノードの識別に使用されます ネットワークドメインは node1.oracle.com という名前のノードの場合 oracle.com を指します GNS を構成する場合 ネットワークドメインとは別に GNS が管理するサブドメインを用意します (GNS サブドメイン ) GNS を構成する場合 クラスタのリソースは GNS サブドメイン内に構成されます GNS を構成するには Oracle Universal Installer (OUI) で以下のように指定します ( ステップ1) クラスタ用の Grid Infrastructure ソフトウェアのインストールおよび構成 を選択 ( ステップ 2) 拡張インストール を選択 ( ステップ4) GNS の構成 のチェックボックスにチェック GNS サブドメイン と GNS VIP アドレス の情報を指定 補足 : スタンドアロン サーバー用の環境では GNS は構成できません 11g R1 以前からのアップグレードでは GNS の構成は行えません 15
16
17
補足 : 複数サブネットの環境 ( 複数のネットワーク リソースを構成する環境 ) で GNS を構成することはサポートしていません 18
GNS を使用したクラスタ内のリソースの名前解決の流れ 1 DNS サーバーが GNS サブドメイン内の名前解決のリクエストを GNS に転送 2 GNS がリクエストされた情報を得るため ( この場合は node4 というノードの情報) マルチキャスト 3 該当する情報を持つ mdns が GNS に情報を返信 4 GNS が DNS サーバーのリクエストに対する情報を返信 19
補足 : 複数サブネットの環境で 2 番目以降のネットワークの VIP リソースに対して DHCP による動的な IP アドレスの割り当ては行われません 20
21
GNS の構成確認 状態確認の結果の例 : [grid@node1]$ srvctl config gns -a GNSは有効です GNSは ポート53でDNSサーバーのリクエストをリスニングしています GNSは ポート5353を使用してmDNSに接続しています GNSステータス : OK ドメインはGNSによってサービスを提供されています : grid.oracle.com GNSバージョン : 11.2.0.1.0 GNS VIPネットワーク : ora.net1.network [grid@node1]$ srvctl status gns GNSはノードnode1で実行中です GNSはノードnode1で有効です [grid@node1]$ crsctl stat res -t ora.gns 1 ONLINE ONLINE node1 ora.gns.vip 1 ONLINE ONLINE node1 [grid@node1]$ 22
GNS を構成している場合 クラスタのリソースは GNS によって内部的に次のような名前で管理され ています ノード VIP : < ホスト名 >-vip.<gns サブドメイン > SCAN : < スキャン名 >.<GNS サブドメイン > SCAN VIP : < クラスタ名 >-scan[1-3]-vip.<gns サブドメイン > GNS VIP : < クラスタ名 >-gns-vip.<gns サブドメイン > ノード : < ホスト名 >.<GNS サブドメイン > ノードに対する問い合わせはノードに割り当てられている全ての IP アドレスの情報が返ります GNS の構成確認 状態確認の結果の例 : [grid@node1]$ nslookup scan.grid.oracle.com Server: 172.20.0.1 Address: 172.20.0.1#53 Non-authoritative answer: Name: scan.grid.oracle.com Address: 172.20.0.174 Name: scan.grid.oracle.com Address: 172.20.0.172 Name: scan.grid.oracle.com Address: 172.20.0.173 [grid@node1]$ 23
24
GNS を構成した場合 クラスタのリソースは GNS VIP を除き 全て GNS によって名前解決が行われます GNS VIP SCAN VIP はホームノードを持たないため 自動フェイルバックの動作はありません DHCP を使用した IP アドレスの割り当ては ノード またはクラスタ リソースの起動時に行われます NODE VIP SCAN VIP がフェイルオーバーする場合 フェイルオーバー前の IP アドレスが引き継がれます GNS を構成しない場合は 従来までと同様に DNS や /etc/hosts によって名前解決が行われます GNS を構成しない場合 ( 基本構成 ) タイプ 起動するノード IP アサイン 名前解決 ノード1 パブリック ノード1 固定 DNS ノード1 VIP ノード1(*1) 固定 DNS ノード1 プライベート ノード1 固定 DNS ノード2 パブリック ノード2 固定 DNS ノード2 VIP ノード2(*1) 固定 DNS ノード 2 プライベート ノード 2 固定 DNS SCAN VIP1 いずれかのノード 固定 DNS SCAN VIP2 いずれかのノード 固定 DNS SCAN VIP3 いずれかのノード 固定 DNS 25
GPnP 関連プロセスの起動の流れ 1 OHASD が oraagent を介して GPNPD MDNSD を起動 2 MDNSD がローカルノードのネットワークインターフェースに割り当てられている IP アドレスを取得し ネットワーク上の MDNSD に向けて通知 3 GPNPD がローカルノードの GPnP プロファイルを読み込み 4 GPNPD が MDNSD を介して他ノードの GPNPD の存在を確認し 各ノードの GPnP プロファイルで最も新しいものを取得 5 CRS が orarootagent を起動 # 以上は GNS を構成しない場合も共通して行われます 以下の 7 9 は GNS を構成している場合固有の起動時の動作です 7 orarootagent が GNSD.VIP リソースと GNSD を起動 8 orarootagent が SCAN VIP リソースと NODE VIP リソースを起動 GNS 環境 : DHCP によって VIP 用の IP アドレスを取得非 GNS 環境 : OLR/OCR から VIP 用の IP アドレスを取得 9 orarootagent が VIP の名前と IP アドレスの情報を GNS に通知 26
27
28
29
GNS を使用したデータベースへの接続 ( 専用サーバー構成 ) の流れ 1 SCAN リスナー経由で ORCL サービスへの接続要求 2 scan.grid.oracle.com は GNS ドメイン内のリソースであるため DNS は GNS に名前解決のリクエストを転送 3 GNS が SCAN リスナーのアドレスを解決し DNS に SCAN VIP の情報を通知 4 DNS が SCAN VIP の情報をクライアントに通知 5 クライアントは SCAN VIP のアドレス ポート番号を使用し SCAN リスナーに対して接続要求を送信 6 SCAN リスナーは ORCL サービスが稼動している接続先情報をクライアントに送信 ( 接続のリダイレクト ) 7 クライアントは接続先サーバーのデフォルトリスナーを介してデータベースに接続 GNS に対して行われた名前解決は DNS サーバー上にキャッシュされます (TTL は 120 秒 ) 30
クラスタ リソースは クラスタのいずれかのサーバーに配置され サーバー障害時など リソースが起動できない場合はフェイルオーバーするリソースであることを表しています スであることを表しています GNS と GNS VIP は orarootagent によって監視が行われており ダウンまたは異常を検知した場合 再起動またはフェイルオーバーが行われます GNS/GNS VIP のフェイルオーバーが発生した場合 GNS/GNS VIP はホームノードが存在しないため フェイルバックは行われません GPnP 関連プロセスのログ 分類 mdns GNS GPNPD OHAS エージェント CRS エージェント ログの場所 <Grid_Home> /log/<hostname> /mdnsd/* <Grid_Home> /log/<hostname> /gnsd/* <Grid_Home> /log/<hostname> /gpnpd/* <Grid_Home> /log/<hostname> /agent/ohasd/* <Grid_Home> /log/<hostname> /agent/crsd/* GNS のログレベルの変更 srvctl start gns -l < ログレベル > を使用して GNS を起動することで ログレベルを変更することが可能です デフォルトのログレベルは 0 です (root.sh で起動時のみ ログレベル 6 で起動 ) 最も詳細なログを出力する場合は 6 を指定します ただし ログの出力量が多く CPU も多く必要とするため 注意が必要です ログレベル 5 はログ出力量 CPU 消費量も抑えられます 31
32
GNS を構成する場合 少なくとも GNS VIP 用の IP アドレスは固定 IP アドレスとして必要です パブリック IP アドレスを DHCP を使用して動的に割り当てる場合 ダイナミック DNS などを使用して クラスタ内のノード間の名前解決が行える必要があります NIC については GNS を構成する場合も GNS を構成しない場合と同様に 少なくとも 2 枚が必要です 33
GNS サブドメインを別途用意する必要があります node1.jp.mycompany.com / node2.jp.mycompany.com の 2 台のマシンを使用してクラスタを構築する場合 例えば GNS サブドメインを mycluster.jp.mycompany.com として準備します また GNS サブドメインはクラスタを構築するマシンのネットワークドメインの子ゾーンを含むサブドメインである必要はなく 上記のマシンに対して 例えば mycomp.co.jp を GNS サブドメインとすることもできます DNS サーバーには GNS サブドメイン内の名前解決のリクエストを GNS へ転送するための設定を予め行っておく必要があります 設定例 1) 親ゾーン側で GNS サブドメインに対して権限委譲 GNS サブドメイン : mycluster.jp.mycompany.com jp.mycompany.com ドメインのゾーンファイルで mycluster サブドメインに対する NS レコードを作成 設定例 2) GNS サブドメインのゾーンに対して forward を指定 GNS サブドメイン : mycomp.co.jp mycomp.co.jp ゾーンに対する名前解決リクエストを forward するよう設定 DNS サーバー DHCP サーバーの設定例については後述します 34
DHCP サーバーはパブリック ネットワーク上で稼動している必要があります DHCP サーバーによる IP アドレスの割り当てが行えない場合 NODE VIP/SCAN VIP リソースの起動が失敗します インターコネクトで使用するプライベート IP アドレスも DHCP を使用して動的割り当てを行う場合は プライベート ネットワーク上で DHCP サーバーが稼動している必要があります 35
36
クラスタ用 Grid Infrastructure のインストール時の指定例 : 補足 : /etc/named.conf の options ステートメント内に forwarders 設定をしている場合 GNS サブドメインに適切に転送されない場合があります 37
クラスタ用 Grid Infrastructure のインストール時の指定例 : 38
39
40
41
42
43
本資料では 4 ノード (node1, node2, node3, node4) の 11g R2 RAC クラスタ環境に 1 ノード (node5) d を追加するケースについて addnode.sh d を使用した手順を説明します インストールユーザー : Oracle Grid Infrastructure Oracle RAC : grid : oracle db_name : orcl ノード追加を行う場合 以下の作業が完了している必要があります 物理的な接続の確立 オペレーティング システムのインストール グループ / ユーザーとディレクトリの作成 SSH の設定 クラスタ検証ユーティリティ (Cluster Verification i Utility: CVU) による確認 $ cluvfy stage -post hwos -n node5 [-verbose] $ cluvfy comp peer [-refnode ref_node] -n node5 [-verbose] 44
11g R2 ではプライベート ネットワークに関するパラメータ指定は必要ありません また Oracle Universal Installer の対話モードを使用した Grid Infrastructure の拡張する方法はありません クラスタ検証ユーティリティ (Cluster Verification Utility: CVU) によるノード追加前の確認 $ cluvfy stage -pre nodeadd -n node5 [-fixup [-fixupdir fixup_dir]] [- verbose] クラスタ検証ユーティリティ (Cluster Verification Utility: CVU) によるノード追加後の確認 $ cluvfy stage -post nodeadd -n node5 [-verbose] 注意 : *1 : 現時点では GNS 環境も非 GNS 環境と同様に VIP 情報の指定が必要 45
46
Enterprise Manager Database Control を使用して サーバープールの属性変更を行うことも可能です 47
Enterprise Manager Database Control を使用して クラスタ データベースへのインスタンスの追加を行うことも可能です 48
プロビジョニング デプロイメント プロシージャを使用する場合 ソフトウェア ライブラリが構成されている必要があります ソフトウェア ライブラリの構成は以下の手順で行います 1 クラスタ データベース: ホーム ページで ソフトウェアとサポート タブをクリックします 2 デプロイメント プロシージャ マネージャ セクションの ソフトウェア ライブラリのデプロイとプロビジョニング をクリックします 3 管理 タブをクリックします 4 プロビジョニング ページで ソフトウェア ライブラリ構成 セクションまで下にスクロールします 5 追加 ボタンをクリックし テキストボックスにソフトウェア ライブラリのディレクトリの場所を指定します 49
Enterprise Manager Database Control によって SCAN リスナーまたはノードの構成が変更されたことが検知された場合 クラスタ のホーム画面の 一般 セクションに再構成アクティビティの情報が出力されます ノードをコマンドラインで追加した場合 新しく追加したノードも Enterprise Manager で管理する場合 構成を行う必要があります 再構成アクティビティのリンクのナビゲーションに従って Enterprise Manager の再構成を行うことが可能です また コマンドラインの emca コマンドを addnode オプションを指定して実行することで同様に再構成行うことも可能です $ <DB_home>/bin/emca -addnode db -silent -DB_UNIQUE_NAME orcl - MODIFY_NODE node5 -SERVICE_NAME orcl 50
51
本資料では 5 ノード (node1, node2, node3, node4, node5) の 11g R2 RAC クラスタ環境から 1 ノード (node5) d を削除するケースの手順を説明します 52
Enterprise Manager Database Control を構成している場合 削除するノードを含まないように再構成します コマンドラインの emca コマンドを deletenode オプションを指定して実行します $ <DB_home>/bin/emca -deletenode db -silent -DB_UNIQUE_NAME orcl - MODIFY_NODE node5 -SERVICE_NAME orcl 53
削除するインスタンスで稼動するサービスを作成している場合 インスタンスを削除する前にサービスの構成を削除するインスタンスを含まないように変更します Enterprise Manager Database Control を使用して クラスタ データベースからインスタンスを削除を行うことも可能です Enterprise Manager Database Control を構成している場合 削除するノードを含まないように再構成します コマンドラインの emca コマンドを deletenode オプションを指定して実行します $ <DB_home>/bin/emca -deletenode db -silent -DB_UNIQUE_NAME orcl - MODIFY_NODE node5 -SERVICE_NAME orcl 54
55
56
57
クラスタ検証ユーティリティ (Cluster Verification Utility: CVU) によるノード削除後の確認 $ cluvfy stage -post nodedel -n node5 [-verbose] 58
59
60
61
62
63
基本的に クラスタ以外のサーバーとも時刻同期を行う必要がある場合は NTP を使用した時刻同期を行うことを推奨します クラスタ用 Grid Infrastructure をインストールすると 自動的に CTSS デーモンが起動されます 特に事前の設定は必要ありません サーバー上で NTP が設定されている場合は CTSS デーモンは起動するのみで何も処理しません (observer mode) その場合 システム時刻の同期は NTP に任せるためです CTSS の時刻調整は Slew モード ( 時刻の後戻りをしないで徐々に時刻を調整する ) で時刻補正を行います クラスタ時刻同期化サービスの注意点 NTP を利用しない場合は NTP の設定ファイル (Linux 環境では /etc/ntp.conf) がないことを確認してください NTP が起動していない状況でも NTP の設定ファイルが存在する場合 CTSS は時刻同期を行いません (observer mode) クラスタ用 Grid Infrastructure をインストールする前に 一旦 全サーバーで時刻を合わせておくことをお奨めします サーバー間で時刻の格差が大きい場合 時刻同期に時間を要するためです 64
CTSS の稼動モードの確認例 : - Active mode [grid@node1]$ crsctl check ctss CRS-4701: クラスタ時刻同期化サービスはアクティブ モードになっています CRS-4702: オフセット ( ミリ秒 ): 0 - Observer mode [grid@node1]$ crsctl check ctss CRS-4700: クラスタ時刻同期化サービスはオブザーバ モードになっています 65
OUI では NTP の起動の有無だけではなく NTP の設定ファイル (/etc/ntp.conf) の有無もチェックしています OUI のチェックでは 以下のケースは成功します クラスタを構成する全サーバーで NTP が起動されている かつ 設定ファイルが存在する NTP による時刻同期が有効と判断 CTSS の時刻同期サービスを無効 (observer mode) にする クラスタを構成する全サーバーで NTP が起動されていない かつ 設定ファイルも存在しない NTP による時刻同期は無効と判断 CTSS の時刻同期サービスを有効 (active mode) にする チェックに失敗するケースとしては 以下があります 設定ファイルは存在するものの NTP が起動されていない サーバー間で NTP の起動や設定ファイルの整合性が取れていない slew オプション -x を指定して起動されていない slew オプション -x は /etc/sysconfig/ntpd で指定します /etc/sysconfig/ntpd の設定例 : # Drop root to id 'ntp:ntp' by default. OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid" # Set to 'yes' to sync hw clock after successful ntpdate SYNC_HWCLOCK=no # Additional options for ntpdate NTPDATE_OPTIONS="" 66
67
68
crsctl stop cluster による停止 crsctl stop cluster コマンドを使用して Oracle Clusterware stack を停止した場合 次のデーモンとエージェント以外が全て停止されます OHAS デーモン GIPC デーモン mdns デーモン GPNP デーモン OHAS エージェント (orarootagent, oraagent) OHAS デーモンの起動 / 停止 OHAS デーモンの起動と停止は ローカルノードから実行します リモートノードから行うことができません 69
パッチの適用時など o オプションで指定したホームから起動されるリソースを一括して起動と停止を行うことができます DB_home を指定して実行した場合に起動 / 停止されるリソース サービス (svc) データベース (db) Grid_home を指定して実行した場合に起動 / 停止されるリソース ディスクグループ (diskgroup) リスナー (lsnr) スキャン リスナー (scan_listener) スキャン VIP (scan_vip) ONS (ons) eons (eons) GNS (gns) NODE VIP (vip) ネットワーク (net) 70
71
サーバーが複数のサブネットのネットワークに接続されている場合は RAC 11g R2 では サブネットごとに VIP を作成することが可能になります 1 つのサブネットに 1 つの VIP を構成できます 同じサブネットに複数の VIP は構成できません セキュリティ要件や負荷分散の観点で サブネットを分離したい場合に有効です ネットワーク リソース 複数サブネットに対して VIP を作成した際のネットワーク リソースのステータスは以下のようになります $ crsctl status resource t ora.net1.network ONLINE ONLINE ONLINE ONLINE ora.net2.network ONLINE ONLINE ONLINE ONLINE デフォルトのネットワーク リソース node1 異なるサブネットに VIP を作成した際の node2 ネットワーク リソース node1 node2 ネットワーク番号ネットワーク リソースは ネットワーク番号を持ちます Grid Infrastructure インストール時に構成されるネットワークのネットワーク番号は 1 ( デフォルト ) です RAC 11g R2 の新機能で 複数サブネットに対して VIP を作成することが可能です その場合は サブネットごとにネットワーク番号 (2,3 ) を割り当て それに応じたネットワーク リソース (ora.net(2,3 ).network) が作成されます 72
サービスを作成する際に -k オプションを指定すると サービスとそのネットワーク上で稼動する VIP との依存関係が構築されます パブリックネットワーク障害時に ク障害時に VIP がフェイルオーバーすると そのノード上のサービスは OFFLINE (UNIFORM の場合 ) になります リスナーに対するサービスの登録 (PMON による登録 ) は サブネットが異なるリスナーに対しても行われますが -k オプションで指定したネットワーク以外からそのサービスを使用した接続が行われないようにしてください 73
ポリシー管理 RAC データベースでの利用について ポリシー管理 RAC データベースでは RAC インスタンスの配置先が動的に変わるため LISTENER_NETWORKS の LOCAL_LISTENER / REMOTE_LISTENER にクラスタを構成する全サーバーの VIP をリストする必要があります 74
75
11g R2 では CLUSTER と SERVICE_NAME パラメータが追加されました CLUSTER パラメータで Y と指定されている場合 Data Pump のプロセス ( ワーカープロセス ) を複数のインスタンス上で起動が可能となります ( デフォルト CLUSTER=Y) 実際に複数のインスタンスでワーカープロセスが起動するかどうかは データ量などによって決定されます パラレル スレーブ プロセスについては 11g R1 までも 複数ノードで起動する場合がありました SERVICE_NAME パラメータを使用することで サービスが稼動しているインスタンス上で Data Pump の処理が行われるように指定することが可能です また Data Pump を複数のインスタンスで並列実行する場合 ダンプファイルが各ノードからアクセス可能である必要があります 76
user1 と user2 でそれぞれ node1 と node4 から同時に Data Pump を実行した場合の DBA_DATAPUMP_SESSIONS DATAPUMP の出力例 : SQL> select * from dba_datapump_sessions order by 1; OWNER_NAME JOB_NAME INST_ID SADDR SESSION_TYPE ---------- ------------------------- ---------- -------- --------------- USER1 SYS_EXPORT_TABLE_01 1 36EEF430 DBMS_DATAPUMP USER1 SYS_EXPORT_TABLE_01 1 36D49B1C MASTER USER1 SYS_EXPORT_TABLE_01 TABLE 2 36DF361C WORKER USER1 SYS_EXPORT_TABLE_01 2 36E951D8 WORKER USER1 SYS_EXPORT_TABLE_01 3 36E52D4C EXTERNAL TABLE USER1 SYS_EXPORT_TABLE_01 3 36DEE144 EXTERNAL TABLE USER1 SYS_EXPORT_TABLE_01 3 36D4C588 EXTERNAL TABLE USER1 SYS_EXPORT_TABLE_01 3 36CAD438 WORKER USER2 SYS_EXPORT_TABLE_01 4 36CAFEA4 DBMS_DATAPUMP USER2 SYS_EXPORT_TABLE_01 4 36DE6200 MASTER USER2 SYS_EXPORT_TABLE_01 TABLE 4 36E52D4C WORKER USER2 SYS_EXPORT_TABLE_01 5 36E87DBC EXTERNAL TABLE USER2 SYS_EXPORT_TABLE_01 5 36E3AF80 EXTERNAL TABLE USER2 SYS_EXPORT_TABLE_01 5 36E8D294 EXTERNAL TABLE USER2 SYS_EXPORT_TABLE_01 5 36E52D44 WORKER 14 行が選択されました SQL> Worker プロセスが複数ノードで起動 Data Pump のジョブが複数ノードで実行 77
78
ノード障害やインターコネクト障害など クラスタからノードを排除する際に CSS は LAN 経由の IPMI power off コマンドで障害ノードを強制的に停止させることが可能です これにより よドを強制的に停止させることが可能ですこれによりより確実に 早期にノードを排除することができ ダウンタイムを最小化します また CSS により power off の後に power on コマンドも実行されるため 障害ノードは 自動的に再起動されます Intelligent Platform Management Interface (IPMI) IPMI は サーバー プラットフォームの状態 ( 温度 電圧 ファン バスなど ) 監視や復旧 リモート制御を行うための標準インターフェイス仕様です 特定のハードウェアシステムやイ OS に依存することなく 遠隔からハードウェアの監視 管理が可能です Baseboard Management Controller (BMC) BMC は ベースボードに実装されたサーバーから独立した管理チップです サーバーがダウンした状態からでもシステムを制御することが可能です IPMI ドライバを利用して ユーザープロセスから BMC に IPMI メッセージを送信することで ハードウェアの監視 管理が可能です 79
80
IPMI ドライバがロードされている場合は デフォルトで Intelligent Platform Management Interface (IPMI) を使用します にチェックがされます 81
82
次の OTN (US) のサイトからダウンロード可能です http://otn.oracle.com/rac または http://www.oracle.com/technology/products/database/clustering/ipd_download_homepage.html Linux ( カーネル 2.6.9 以上 ) と Windows (Windows Server 2003 Service Pack 以上 ) プラットフォームで使用可能です インストールは サーバーとクライアントの 2 つの方法があります 1) サーバーのインストールクラスタを構成する全てのノードにインストールを行います クラスタが node1 node2 node3 node4 で構成されており node1 をマスターとする場合の Linux プラットフォームでのインストール例 : $./crfinst.pl -i node1,node2,node3,node4node2 node3 node4 -b /data/oracrfdb -m node1 2) クライアントのインストール収集した情報を参照するためにクライアント環境にインストールを行います クラスタの一部ではないクライアントマシンにインストールします $./crfinst.pl -g < インストールディレクトリ > 83
NODENAME 列のノード名をダブルクリックすると 該当のノードのノード ビューのウィンドウが出現します 84
DEVICE 列のデバイス名をダブルクリックすると 該当のデバイスのデバイス ビューのウィンドウが出現します 85
86
87
88
89
90