| Oracle® Grid Infrastructureインストレーション・ガイド 11gリリース2 (11.2) for Linux B56271-15 |
|
 前 |
 次 |
この付録では、インストール前に実行を要求される作業の理由、およびその他のインストールの概要について説明します。
この付録の内容は次のとおりです。
この項では、クラスタ用Oracle Grid Infrastructureのインストール前に必要な作業の概要を確認します。内容は次のとおりです。
この項の内容は次のとおりです。
メンバーにOracle Inventory(oraInventory)ディレクトリへの書込み権が付与されたグループを所有する必要があります。このディレクトリは、サーバー上のすべてのOracleソフトウェア・インストールの中央インベントリ・レコードです。このグループのメンバーはOracle中央インベントリ(oraInventory)ディレクトリに対する書込み権限を所有します。また、様々なOracle Clusterwareリソース、OCRキー、DBAが書込み権限を必要とするOracle Clusterwareホーム内のディレクトリに対する権限やその他の必要な権限が付与されます。このグループのデフォルトはoinstallです。Oracle Inventoryグループは、Oracleソフトウェアのインストール所有者のプライマリ・グループである必要があります。
oraInventoryディレクトリには、次のものが含まれています。
システム上のOracleホーム・ディレクトリ(Oracle Grid InfrastructureおよびOracle Database)のレジストリ。
Oracleソフトウェアのインストール時のインストール・ログおよびトレース・ファイル。これらのファイルは、将来参照するためにそれぞれのOracleホームにもコピーされます。
Oracleインストールに関するその他のメタデータ・インベントリ情報は、個々のOracleホーム・インベントリ・ディレクトリに格納されており、中央インベントリとは分離されています。
1つのグループをアクセス制御グループとして構成し、Oracle Inventory、データベース管理者(OSDBA)、およびOracleソフトウェアがオペレーティング・システムの認証に使用する他のすべてのアクセス制御グループに適用できます。ただし、すべてのシステム権限のオペレーティング・システム認証の提供に1つのグループを使用する場合、このグループは、管理システム権限を付与する対象のすべてのユーザーに対するプライマリ・グループである必要があります。
|
注意: Oracleソフトウェアがすでにシステムにインストールされている場合は、既存のOracle Inventoryグループが、Oracle Grid Infrastructureのインストールに使用するオペレーティング・システム・ユーザー(oracleまたはgrid)のプライマリ・グループである必要があります。既存のOracle Inventoryグループを確認するには、「Oracle InventoryおよびOracle Inventoryグループの存在の確認」を参照してください。 |
Oracle Inventoryディレクトリ(oraInventory)には、サーバーにインストールされたすべてのOracleソフトウェア用の中央インベントリがあります。
Oracleソフトウェアをシステムにはじめてインストールする場合は、oraInventoryディレクトリのパスを入力するように求められます。
インストール時の指示に従ってOracleベースのパスを指定するか、Oracle Grid Infrastructureのインストールを実行しているユーザーに対して環境変数$ORACLE_BASEが設定されている場合は、OUIによってOracle Inventoryディレクトリがパス$ORACLE_BASE/../oraInventoryに作成されます。たとえば、$ORACLE_BASEが/opt/oracle/11に設定されている場合は、すべてのインストールの中央インベントリがこの特定のOracleインストール・ユーザーのOracleベースの外部になるように、パス/opt/oracle/oraInventoryにOracle Inventoryディレクトリが作成されます。
パスの入力も、ORACLE_BASEの設定も行わなければ、Oracle Inventoryディレクトリはインストールを実行しているユーザーのホーム・ディレクトリに格納されます。次に例を示します。
/home/oracle/oraInventory
この配置によって、複数のOracleソフトウェア所有者で後続のインストールを行うときに権限エラーが発生する可能性があるため、このオプションを受け入れずにOFA準拠のパスを使用することをお薦めします。
新規インストールの場合は、OFA準拠の構造でOracleパス(/u01/app/oraInventoryなど、所有者がOracleソフトウェア所有者)を作成するか、Oracleベース環境変数をOFA準拠の値に設定することをお薦めします。
Oracleベースの変数を/u01/app/gridや/u01/app/oracleなどのパスに設定すると、Oracle Inventoryは、デフォルトでパスu01/app/oraInventoryになり、すべてのOracleインストール所有者がこの中央インベントリ・ディレクトリに書込みができるように正しい権限を使用するようになります。
デフォルトでは、Oracle Inventoryディレクトリはインストール所有者のOracleベース・ディレクトリ下にはインストールされません。これは、すべてのOracleソフトウェア・インストールが同じOracle Inventoryを共有し、1つしかないOracle Inventoryをすべてのユーザーが使用するためです。一方、Oracleベースは各ユーザーに個別に存在します。
この項では、Oracleベース・ディレクトリの準備について説明します。
インストール時に、Oracleベースの場所を指定するように求められます。Oracleベースは、インストールを実行するユーザーが所有します。既存のOracleホームが含まれるディレクトリを選択するか、またはOracleベース・ディレクトリの構造を持っていない別のディレクトリを選択できます。
Oracleベース・ディレクトリ・パスを使用すると、Oracleインストールの構造が簡略化され、複数のデータベース・インストールでOptimal Flexible Architecture(OFA)構成を保持しやすくなります。
Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)のインストールとOracle Databaseのインストールに同じソフトウェア所有者を使用しない場合でも、Oracle Grid Infrastructureのインストールでroot.shスクリプトを実行することによって、クラスタウェア・バイナリが配置されるホーム・ディレクトリの所有権がrootに変更されることに注意してください。また、ルート・レベル(/)までのすべての祖先ディレクトリもrootに変更されます。このため、クラスタ用Oracle Grid Infrastructureのホームは、他のOracleソフトウェアと同じ場所に置くことができません。
ただし、スタンドアロン・データベース用のOracle Grid Infrastructure(Oracle Restart)は、他のOracleソフトウェアと同じ場所に配置できます。
|
関連項目: Oracle Restartの詳細は、使用しているプラットフォームのOracle Databaseインストレーション・ガイドを参照してください。 |
インストール時に、OUIがクラスタ・ノードで検出するネットワーク・インタフェースごとに計画された使用方法を指定するように求められます。各インタフェースを、パブリック・インタフェースまたはプライベート・インタフェース、あるいはOracle Clusterwareで使用しないインタフェースとして指定します。パブリックIPアドレスと仮想IPアドレスは、パブリック・インタフェース上に構成されます。プライベート・アドレスはプライベート・インタフェース上に構成されます。
各アドレス・タイプの詳細は、次の項を参照してください。
パブリックIPアドレスは、DHCPを使用して動的に割り当てられるか、DNSまたはホスト・ファイルで静的に定義されます。パブリック・インタフェース(クライアントからアクセス可能なインタフェース)が使用されます。
Oracle Clusterwareは、プライベートとマークされたインタフェースを使用してノード間通信を行います。各クラスタ・ノードは、インストール時にプライベート・インタフェースとして指定されたインタフェースを持つ必要があります。プライベート・インタフェースはそのインタフェース用に構成されたアドレスを持つ必要がありますが、それ以上の構成は必要ありません。Oracle Clusterwareは、プライベートと指定されたインタフェースを、クラスタ・インターコネクトとして使用します。プライベート・ネットワークに関する情報に複数のインタフェースを指定すると、Oracle Clusterwareはそれらを冗長インターコネクトを使用して構成します。プライベートとして指定するインタフェースはいずれも、クラスタのすべてのノードに接続するサブネット上に存在しなければなりません。Oracle Clusterwareは、プライベート・インタフェース用に指定された、すべてのインタフェースを使用します。
プライベート・インターコネクトの場合は、ノード間のキャッシュ・フュージョンおよびその他のトラフィックのため、物理的に別のプライベート・ネットワークを使用することをお薦めします。DNSを使用してアドレスを構成する場合は、プライベートIPアドレスがクラスタ・ノードからのみ到達可能であることを確認する必要があります。
インストール後、CLUSTER_INTERCONNECTS初期化パラメータを使用してOracle RACのインターコネクトを変更する場合は、パブリックIPアドレスで使用されていないサブネット上で、パラメータをプライベートIPアドレスに変更する必要があります。パブリック・サブネットとして指定したサブネットを使用するインタフェースにインターコネクトを変更することはできません。
プライベート・ネットワークIPアドレスを使用したネットワークではファイアウォールを使用しないでください。プライベート・ネットワークIPアドレスによってインターコネクト・トラフィックがブロックされる可能性があるためです。
仮想IP(VIP)アドレスは、GNSまたはDNSに登録されています。次の要件を満たすVIPのアドレスを選択します。
IPアドレスとホスト名は、現在未使用である(DNSに登録できるが、pingコマンドでアクセスできない)
VIPはパブリック・インタフェースと同じサブネット上にある
GNS仮想IPアドレスは、DNSで構成される静的なIPアドレスです。DNSはGNS仮想IPアドレスに問合せを委任し、GNSデーモンはそのアドレスで、受信した名前解決要求に応答します。
GNSは、Oracle Clusterwareで提供されるマルチキャスト・ドメイン・ネーム・サービス(mDNS)をサブドメイン内で使用し、クラスタにノードが追加または削除されると、ホスト名およびIPアドレスを動的にマップできるようにします。DNSで新たにホスト構成を行う必要はありません。
GNSを有効にするには、クラスタに割り当てられたサブドメインのIPアドレス(grid.example.comなど)をネットワーク管理者に教えてもらい、そのサブドメインへのDNS要求を、クラスタのGNS仮想IPアドレスに委任してもらう必要があります。GNSはそのアドレスで機能します。一連のIPアドレスはDHCP経由でクラスタに提供されます。これらのアドレスは、クラスタのパブリック・ネットワーク上で使用できる状態でなくてはなりません。
|
関連項目: グリッド・ネーミング・サービスの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
Oracle Database 11gリリース2のクライアントは、SCANを使用してデータベースに接続します。SCANとそれに関連付けられたIPアドレスは、クラスタを構成するノードとは無関係に、クライアントが接続に使用する安定した名前を提供します。SCANアドレス、仮想IPアドレス、およびパブリックIPアドレスはすべて、同じサブネット上に存在する必要があります。
SCANは、node1-vipのような、仮想IPアドレスに使用される名前に類似した仮想IP名です。ただし、仮想IPと異なり、SCANは個別のノードではなくクラスタ全体と関連付けられており、1つではなく複数のIPアドレスと関連付けられています。
SCANは、パブリック・クライアント接続を処理するクラスタ内の複数のIPアドレスに解決可能であることで機能します。クライアントから要求が送信されると、SCAN IPアドレスおよびSCANポート上でリスニングしているSCANリスナーがクライアントから使用可能になります。クラスタ上のすべてのサービスがSCANリスナーに登録されているため、SCANリスナーは、現在サービスを提供している最も負荷が低いノードのローカル・リスナー・アドレスを使用して応答します。最後に、サービスが提供されているノード上のリスナーを通じて、クライアントがサービスへの接続を確立します。これらすべての動作はクライアントに対して透過的に行われ、クライアントでの明示的な構成は必要ありません。
リスナーはインストール時に作成されます。リスナーは、SCAN IPアドレスのノードで指定されたSCAN IPアドレス上でリスニングします。Oracle Net Servicesは、サービスを提供している最も負荷が低いインスタンスに、アプリケーションの要求をルーティングします。SCANアドレスはクラスタ内のノード・アドレスではなくクラスタに解決されるため、SCANアドレス構成に影響を与えることなく、クラスタでノードを追加または削除できます。
SCANは、クラスタ内のグリッド・ネーミング・サービス(GNS)、またはドメイン・ネーム・サービス(DNS)解決のいずれかで解決できるように構成する必要があります。高い可用性とスケーラビリティを実現するために、3つのIPアドレスに解決されるようにSCAN名を構成することをお薦めします。SCANは少なくとも1つのアドレスに解決される必要があります。
GNSドメインを指定する場合、SCAN名のデフォルトはclustername-scan.GNS_domainです。指定しない場合のデフォルトはclustername-scan.current_domainです。たとえば、Oracle Grid Infrastructureインストールをサーバーnode1から起動し、クラスタ名がmycluster、GNSドメインがgrid.example.comの場合、SCAN名はmycluster-scan.grid.example.comです。
Oracle Database 11g リリース2より前のOracle DatabaseリリースのIPアドレスを使用するように構成されたクライアントは、既存の接続アドレスを引き続き使用できるため、SCANを使用する必要はありません。Oracle Clusterware 11gリリース2(11.2)にアップグレードするとSCANが有効になり、Oracle Database 11g リリース2以降のデータベースへの接続にSCANが必要になります。以前のバージョンのOracle DatabaseをアップグレードするとSCANリスナーに登録されるため、クライアントがSCANを使用してそのデータベースに接続できるようになります。データベースはinit.oraファイルのリモート・リスナー・パラメータを通じてSCANリスナーに登録されます。REMOTE_LISTENERパラメータは、SCAN:PORTに設定する必要があります。SCANをHOST=SCANとして設定した単一のアドレスを持つTNSNAMES別名には設定しないでください。
SCANはほとんどのデプロイメントでオプションです。ただし、Oracle Database 11gリリース2以上でサーバー・プールを使用しているポリシー管理データベースを使用しているクライアントは、SCANを使用してデータベースにアクセスする必要があります。これは、ポリシー型管理のデータベースは異なるサーバーで異なる時刻に実行されることがあるため、あるポリシー型管理のデータベースの特定ノードの仮想IPアドレスへの接続はできないためです。
Oracle Clusterware 11g リリース2(11.2)には、クラスタ時刻同期化サービス(CTSS)が自動的に構成されます。このサービスでは、デプロイしたクラスタのタイプに最適な同期方法で、すべてのクラスタ・ノードが自動的に同期されます。NTPなどの既存のクラスタ同期サービスがある場合、このサービスはオブザーバ・モードで開始されます。既存のサービスがない場合、このサービスはアクティブ・モードで開始され、クラスタ・ノード間の時刻の同期を確実にします。CTSSで互換性の問題が発生することはありません。
CTSSモジュールはOracle Grid Infrastructureのインストールの一環としてインストールされます。CTSSデーモンはOHASデーモン(ohasd)によって起動されるため、コマンドライン・インタフェースは必要ありません。
Oracle Automatic Storage Managementクラスタ・ファイル・システムの理解
スタンドアロンのOracle ASMインストール環境からクラスタ化されたOracle ASMインストール環境への変換について
Oracle Automatic Storage Managementは、拡張されて汎用ファイル・システムであるOracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)を含むようになりました。Oracle ACFSは、複数のプラットフォームに対応するスケーラブルな新しいファイル・システムとしてストレージを管理します。このテクノロジにより、Oracle Automatic Storage Management (Oracle ASM)機能は、Oracle Databaseの外で保持されているカスタマ・ファイルをサポートするように拡張されます。Oracle ACFSがサポートするファイルには、アプリケーション・バイナリ、アプリケーション・レポートなどがあります。他にも、ビデオ、オーディオ、テキスト、イメージ、設計図、その他の汎用アプリケーションのファイル・データがサポートされます。
以前のリリースのOracle ASMが、サーバー上または既存のOracle Clusterwareインストール環境内にインストールされている場合は、パスGrid_home/binにあるOracle Automatic Storage Managementコンフィギュレーション・アシスタント(ASMCA)を使用して、既存のOracle ASMインスタンスをOracle ASM 11gリリース2(11.2)にアップグレードし、その後で障害グループ、ASMボリュームおよびOracle Automatic Storage Managementクラスタ・ファイル・システム(ACFS)を構成できます。
|
注意: 既存のOracle ASMインスタンスのアップグレードは、そのノード上のすべてのデータベース・インスタンスおよびアプリケーションを停止してから実行する必要があります。 |
インストール時に、Oracle ASMを使用することを選択したときに、以前のOracle ASMバージョンが別のホームにインストールされていることがASMCAで検出された場合は、Oracle ASM 11gリリース2(11.2)のバイナリをインストールした後に、ASMCAを起動して既存のOracle ASMインスタンスをアップグレードできます。次に、Oracle ASMボリュームを作成し、アップグレードしたOracle ASMを使用してOracle ACFSを作成することで、Oracle ACFSのデプロイメントを構成できます。
Oracle ClusterwareまたはOracle RACの既存のインストール環境で、すべてのノード上のOracle ASMインスタンスの旧バージョンがOracle ASM 11gリリース1の場合は、Oracle ASMインスタンスのローリング・アップグレードを実行できます。Oracle RACのインストール環境で、旧バージョンのOracle ASMインスタンスがOracle ASM 11gリリース1よりも前のリリースの場合は、ローリング・アップグレードを実行できません。Oracle ASMは、すべてのノードで11gリリース2(11.2)にアップグレードされます。
クラスタのメンバー・ノードの中に、既存のスタンドアロンのOracle ASMがインストールされているノードが1つ以上ある場合でも、OUIは、クラスタ用のOracle Grid Infrastructureのインストールを開始します。
Oracle Clusterwareファイル(OCRおよび投票ディスク)をOracle ASM上に配置すると、クラスタウェアのインストール終了時にASMCAが起動し、ローカル・ノード上のOracle ASMインスタンスを移行およびアップグレードするためのプロンプトが表示され、Oracle ASM 11gリリース2(11.2)環境が作成されます。
リモート・ノードでスタンドアロンのOracle ASMインスタンスが実行されていることをASMCAが認識すると、そのOracle ASMインスタンスと、そのOracle ASMインスタンスを使用しているデータベース・インスタンスを停止するように求められます。次に、ASMCAは、クラスタ化されたOracle ASMインスタンスをクラスタ内のすべてのノードに展開します。ただし、クラスタ対応のOracle ASMインスタンスのディスク・グループ名は、既存のスタンドアロンのディスク・グループ名と異なっている必要があります。
|
関連項目: 『Oracle Automatic Storage Management管理者ガイド』 |
次の項で、サーバー・プールの概要を簡単に説明します。内容は次のとおりです。
|
関連項目: サーバー・プールの構成および管理の方法については、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
Oracle Clusterware 11g リリース2(11.2)以上では、Oracle Clusterwareが管理するリソースは、サーバー・プールという、サーバーの論理グループに格納されます。リソースは共有インフラストラクチャ上でホスト指定され、サーバー・プールに格納されます。リソースは、ポリシーによってハードウェア・リソース(CPUやメモリーなど)の使用量にのみ制限され、単一システム環境にデプロイされているように動作します。
リソースは、サーバー・プールを使用して動的に管理することで、クラスタ内のリソースをポリシー・ベースで管理することができます。また、特定のノードで実行するように物理的にリソースを割り当てる従来の方法で管理することもできます。
|
注意: デフォルトでは、すべての名前付きユーザーがサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するには、CRS管理者リストに特定のユーザーを追加することをお薦めします。 |
|
関連項目: CRS管理者リストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
Oracle Grid Infrastructureのインストール所有者には、SRVCTL、Oracle Enterprise Manager Database ControlまたはOracle Database Configuration Assistant(DBCA)を使用して、サーバー・プールを作成および構成する権限があります。
ポリシー・ベースの管理:
必要時に動的な容量の割当てが可能で、ポリシーで設定した優先度に従ってサーバーの容量を指定できます。
重要度ごとにリソースの割当てが可能で、アプリケーションが可能なかぎり必要最小限のリソースを取得できます。また、優先度が低いアプリケーションが、より重要なアプリケーションのリソースを消費しないようにすることもできます。
必要時には分離が保証され、アプリケーションとデータベースについて、クラスタの専用サーバーを指定できます。
サーバー・プールで実行しているアプリケーションとデータベースは、リソースを共有しません。このため、サーバー・プールは必要に応じてリソースを分離しますが、必要時は動的な容量の割当てが可能です。役割区分による管理とともにこの機能を使用することで、標準化されたクラスタ環境を持つ組織のニーズに対応できますが、複数の管理者グループが共通のクラスタ・インフラストラクチャを共有できるようになります。
サーバー・プールは、クラスタを同じまたは類似したリソースのホスティングするサーバーのグループに分割します。サーバー・プールによって、クラスタの複数のサーバーに対し、統一されたワークロード(一連のOracle Clusterwareリソース)が分散されます。たとえば、Oracle Databaseが特定のサーバー・プールのみで実行されるように制限できます。役割区分管理を有効にすると、特定のサーバー・プールの属性を変更する権限をオペレーティング・システム・ユーザーに明示的に付与できます。
最上位のサーバー・プール:
クラスタを論理的に分割します。
常に排他的です。これは、1つのサーバーが特定の時期に1つの特定のサーバー・プールにのみ存在できることを意味します。
各サーバー・プールには、作成時に割り当てられる3つの属性があります。
MIN_SIZE: サーバー・プールに含まれるサーバーの最小数。サーバー・プール内のサーバーの数がこの属性値を下回る場合、Oracle Clusterwareは、サーバーの数がこの属性値に達するまで、またはより重要性の低いプールに空きサーバーがなくなるまで、他のサーバー・プールからこのサーバー・プールにサーバーを自動的に移動します。
MAX_SIZE: サーバー・プールに含まれるサーバーの最大数。
IMPORTANCE: クラスタ内のすべてのサーバー・プールをランク付けする、0から1000の数値(0は重要性が最も低いことを示す)。
Oracle Clusterwareをインストールすると、汎用サーバー・プールと空きサーバー・プールという2つのサーバー・プールが自動的に作成されます。はじめは、新規インストールのすべてのサーバーは空きサーバー・プールに割り当てられます。空きサーバー・プールにあるサーバーは、新しく定義したサーバー・プールに自動的に移動します。Oracle Clusterwareをアップグレードすると、すべてのノードが汎用サーバー・プールに割り当てられます。これによって、Oracle Database 11g リリース2(11.2)より前のデータベース・リリースとの互換性が保証されます。
空きサーバー・プールには、他のサーバー・プールに割り当てられないサーバーが含まれます。空きサーバー・プールの属性は、次のように制限されます。
SERVER_NAMES、MIN_SIZEおよびMAX_SIZEをユーザーが編集することはできません。
IMPORTANCEおよびACLはユーザーが編集できます。
|
関連項目: 『Oracle Clusterware管理およびデプロイメント・ガイド』 |
汎用サーバー・プールには、11g リリース2(11.2)より前のデータベース、および管理者が管理する構成が固定されたデータベースが格納されます。また、次のいずれかを満たすサーバーも含まれます。
アプリケーション・リソース・タイプのすべてのリソースのHOSTING_MEMBERS属性で指定したサーバー
汎用サーバー・プールを親サーバー・プールとするサーバー・プールのSERVER_NAMES属性で指定した名前を持つサーバー
汎用サーバー・プールの属性は、次のように制限されています。
汎用サーバー・プールの構成属性は誰も変更できません(すべての属性は読取り専用です)。
HOSTING_MEMBERS属性でサーバー名を指定した場合、サーバーが次の状態であるときにOracle Clusterwareはその名前を許可します。
オンラインで汎用サーバー・プールに存在する。
オンラインで空きサーバー・プールに存在する。この場合、Oracle Clusterwareによってサーバーが汎用サーバー・プールに移動されます。
オンラインで、他のサーバー・プールに存在し、クライアントがCRS管理者(サーバー・プールのリソース管理を制御するユーザー・ロール)であるか、またはサーバー・プールのサーバーを使用することが許可されている。この場合、サーバーは汎用サーバー・プールに移動されます。
オフラインで、クライアントがCRS管理者である。
子サーバー・プールを汎用サーバー・プールに登録した場合、リソースに対して以前に指定したものと同じ要件をサーバー名が満たす場合にのみ、Oracle Clusterwareはその子サーバー・プールを許可します。
サーバーは、クラスタの起動時またはサーバーがクラスタに追加されるときに汎用サーバー・プールに割り当てられ、その後で、他のサーバー・プールに割り当てられます。
アウトオブプレース・アップグレードでは、インストーラは新しいバージョンを別のOracle Clusterwareホームにインストールします。Oracle Clusterwareの新旧バージョンが各クラスタ・メンバー・ノードに存在することになりますが、アクティブになるバージョンは1つのみです。
ローリング・アップグレードは、ソフトウェアの新バージョンへのアップグレード中、停止時間をなくし、可用性の継続を保証します。
各ノード上に別々のOracle Clusterwareホームがある場合、すべてのノードでアウトオブプレース・アップグレードを行うか、またはアウトオブプレース・ローリング・アップグレードを行うことができます。そうすることで、あるノードでは旧バージョンのOracle ClusterwareホームからOracle Clusterwareを実行し、別のノードでは新バージョンのOracle ClusterwareホームからOracle Clusterwareを実行することが可能です。
Oracle Clusterware 11gリリース2のインプレース・アップグレードはサポートされていません。
