| Oracle® Grid Infrastructureインストレーション・ガイド 12cリリース1 (12.1) for Linux B71324-15 |
|
 前 |
 次 |
この付録では、インストールの実行に必要な概念および用語の概要を説明します。
この付録の内容は次のとおりです。
この項では、クラスタ用Oracle Grid Infrastructureのインストール前に必要な作業の概要を確認します。内容は次のとおりです。
Oracle Grid Infrastructureに関するOptimal Flexible Architectureガイドライン
クラスタ用Oracle Grid InfrastructureとOracle Restart用Oracle Grid Infrastructureの違い
Oracle Grid Infrastructureのみをインストールする場合は、Oracle Optimal Flexible Architecture(OFA)に準拠したOracleベースおよびGridホームのパスを作成して、Oracle Universal Installer(OUI)がインストール中にそのディレクトリを選択できるようにすることをお薦めします。OUIがパスをOracleソフトウェア・パスとして認識するには、u[0-9][1-9]/appという形式にする必要があります。
OracleベースのOFAパスは、u[0-9][1-9]/app/userであり、ここでのuserはOracleソフトウェア・インストールの所有者アカウントの名前です。
Oracle Grid Infrastructure OracleホームのOFAパスは、u[0-9][1-9]/app/release/gridであり、ここでのreleaseは3桁のOracle Grid Infrastructureリリースです(例: 12.1.0)。
OUIはOFA準拠のソフトウェア・パス(u[0-9][1-9]/app)を検出すると、Oracle Grid Infrastructure GridホームおよびOracleインベントリ(oraInventory)ディレクトリを作成します。たとえば、パス/u01/appおよび/u89/appはOFAに準拠したパスです。
Oracle Grid Infrastructureホームは、Oracle Grid Infrastructureインストール所有者のGridホームとは異なるパスにある必要があります。Oracle Grid Infrastructureベース・パスを手動で作成する場合、このリリース専用の個別のパスであることと、既存のOracleベース・パスの下にないことを確認します。
クラスタ用Oracle Grid Infrastructureの要件は、Oracle Restart構成の単一インスタンスのOracle Grid Infrastructureとは異なります。
|
関連項目: Oracle Restartの要件の詳細は、『Oracle Databaseインストレーション・ガイド』を参照してください。 |
メンバーに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グループを確認するには、第6.1.1項「Oracle InventoryおよびOracle Inventoryグループの存在の確認」を参照してください。 |
Oracle Inventoryディレクトリ(oraInventory)には、サーバーにインストールされたすべてのOracleソフトウェア用の中央インベントリがあります。各クラスタ･メンバー･ノードには、固有の中央インベントリ・ファイルがあります。共有のOracle Inventoryディレクトリを持つことはできません(ノードにインストールされているすべてのOracleソフトウェアのインストール済Oracleホームを指すために使用されるため)。
Oracleソフトウェアをシステムにはじめてインストールする場合は、oraInventoryディレクトリのパスを入力するように求められます。
oraInventoryグループが存在しない場合、デフォルトでは、クラスタ用Oracle Grid Infrastructureソフトウェアのインストール所有者のプライマリ・グループが、oraInventoryグループとして表示されます。使用するOracleソフトウェア・インストール所有者のすべてが、このグループをプライマリ・グループとして利用できることを確認します。
すべてのOracleインストール所有者のプライマリ・グループは、メンバーにサーバーの中央Oracle Inventoryへの書込みやログ・ファイルの書込みができるOINSTALLシステム権限などの権限が付与される、Oracle Inventoryグループ(oinstall)である必要があります。
インストール所有者のプライマリ・グループが、ユーザーのホーム・ディレクトリ(/home/oracleなど)である場合、Oracle Inventoryはインストール所有者のホーム・ディレクトリに格納されます。この配置によって、複数の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)構成を保持しやすくなります。
Oracle Grid InfrastructureインストールのOracleベース・ディレクトリは、Oracle ASMおよびOracle Clusterwareに関する診断ログ、管理ログおよびその他のログが格納される場所です。クラスタのOracle Grid Infrastructureを除くOracleインストールの場合、Oracleホームが配置される場所でもあります。
ただし、Oracle Grid Infrastructureインストールの場合は、別のパスを作成し、Oracleベースのパスをその他のOracleインストールが使用できるようにする必要があります。
OUIがOracleベース・パスをOracleソフトウェアのパスとして認識するためには、u[0-9][1-9]/appの形式を使用する必要があり、oraInventory (oinstall)グループのどのメンバーからも書込み可能である必要があります。OracleベースのOFAパスは、u[0-9][1-9]/app/userであり、ここでのuserはソフトウェア・インストール所有者の名前です。次に例を示します。
/u01/app/grid
クラスタに存在できるOracle Grid Infrastructureインストールは1つのみで、すべてのアップグレードがホーム外アップグレードであるため、Grid Infrastructureソフトウェア所有者(grid)用のOracleベースを作成し、そのインストールのリリース番号を使用して、Oracle Grid Infrastructureバイナリ用のOracleホームを作成することをお薦めします。
Oracle Grid Infrastructureソフトウェア用Oracleホーム(Gridホーム)は、u[0-9][1-9]/app/release/grid形式のパスにある必要があります(ここでのreleaseはOracle Grid Infrastructureソフトウェアのリリース番号)。次に例を示します。
/u01/app/12.1.0/grid
インストール中に、Gridホームへのパスの所有権がrootに変更されます。Gridホームへの一意のパスを作成しない場合は、グリッドのインストール後に、同じパスにある既存のインストールを含むその他のインストールの権限エラーが発生します。
Oracle Grid Infrastructureソフトウェアの場所(Gridホーム)に指定するディレクトリ・パスが次の要件を満たすことを確認します。
インストール前にパスを作成する場合は、Oracle Grid Infrastructureのインストール所有者(通常、すべてのOracleソフトウェアに対して1つのインストール所有者の場合はoracle、ロール・ベースのOracleインストール所有者の場合はgrid)が所有し、権限が775に設定されている必要があります。
Oracle Clusterwareホームを含む、既存のOracleホーム以外のパスに作成する必要があります。
ユーザー・ホーム・ディレクトリには作成できません。
Oracle Grid Infrastructureインストール所有者のOracleベース(grid)または他のOracleインストール所有者のOracleベース(/u01/app/oracleなど)と異なる場所である必要があります。
すべてのファイルをrootによって所有可能なパス内のサブディレクトリとして作成するか、一意のパス内に作成します。
Oracle Grid Infrastructureバイナリを、共有ストレージの共有ホームを使用するのではなく、ローカル・ホームにインストールすることをお薦めします。
Grid Infrastructure(Oracle ClusterwareおよびOracle ASM)のインストールとOracle Databaseのインストールに同じソフトウェア所有者を使用しない場合でも、Oracle Grid Infrastructureのインストールでroot.shスクリプトを実行することによって、クラスタウェア・バイナリが配置されるホーム・ディレクトリの所有権がrootに変更されることに注意してください。また、ルート・レベル(/)までのすべての祖先ディレクトリもrootに変更されます。このため、クラスタ用Oracle Grid Infrastructureのホームは、他のOracleソフトウェアと同じ場所に置くことができません。
ただし、Oracle Restartは他のOracleソフトウェアと同じ場所に置くことができます。
|
関連項目: Oracle Restartの詳細は、使用しているプラットフォームのOracle Databaseインストレーション・ガイドを参照してください。 |
インストール時に、OUIがクラスタ・ノードで検出するネットワーク・インタフェースごとに計画された使用方法を指定するように求められます。各インタフェースを、パブリック・インタフェースまたはプライベート・インタフェース、あるいはOracle Grid InfrastructureやOracle Flex ASMクラスタで使用しないインタフェースとして指定します。パブリックIPアドレスと仮想IPアドレスは、パブリック・インタフェース上に構成されます。プライベート・アドレスはプライベート・インタフェース上に構成されます。
各アドレス・タイプの詳細は、次の項を参照してください。
パブリックIPアドレスは、DHCPを使用して動的に割り当てられるか、DNSまたはホスト・ファイルで静的に定義されます。パブリック・インタフェース(クライアントからアクセス可能なインタフェース)が使用されます。パブリックIPアドレスは、クラスタ･メンバー･ノードのプライマリ・アドレスであり、コマンドhostnameを入力したときに返される名前に解決されるアドレスである必要があります。
IPアドレスを手動で構成した場合は、Oracle Grid Infrastructureをインストールした後で、ドメイン修飾子の追加や削除も含め、ホスト名を変更しないでください。新しいホスト名を持つノードは、新しいホストとみなされるので、クラスタに追加する必要があります。古い名前のノードは、クラスタから削除されるまで、停止状態で表示されます。
Oracle Clusterwareは、プライベートとマークされたインタフェースを使用してノード間通信を行います。各クラスタ・ノードは、インストール時にプライベート・インタフェースとして指定されたインタフェースを持つ必要があります。プライベート・インタフェースはそのインタフェース用に構成されたアドレスを持つ必要がありますが、それ以上の構成は必要ありません。Oracle Clusterwareは、プライベートと指定されたインタフェースを、クラスタ・インターコネクトとして使用します。プライベート・ネットワークに関する情報に複数のインタフェースを指定すると、Oracle Clusterwareはそれらを冗長インターコネクトを使用して構成します。プライベートとして指定するインタフェースはいずれも、クラスタのすべてのノードに接続するサブネット上に存在しなければなりません。Oracle Clusterwareは、プライベート・インタフェース用に指定された、すべてのインタフェースを使用します。
プライベート・インターコネクトの場合は、ノード間のキャッシュ・フュージョンおよびその他のトラフィックのため、物理的に別のプライベート・ネットワークを使用することをお薦めします。DNSを使用してアドレスを構成する場合は、プライベートIPアドレスがクラスタ・ノードからのみ到達可能であることを確認する必要があります。
インストール後、CLUSTER_INTERCONNECTS初期化パラメータを使用してOracle RACのインターコネクトを変更する場合は、パブリックIPアドレスで使用されていないサブネット上で、パラメータをプライベートIPアドレスに変更する必要があります。パブリック・サブネットとして指定したサブネットを使用するインタフェースにインターコネクトを変更することはできません。
プライベート・ネットワークIPアドレスを使用したネットワークではファイアウォールを使用しないでください。プライベート・ネットワークIPアドレスによってインターコネクト・トラフィックがブロックされる可能性があるためです。
グリッド・ネーミング・サービス(GNS)を使用していない場合は、各ノードに仮想ホスト名を指定します。仮想ホスト名は、パブリック・ノード名で、ノードが停止している場合にノードに送信されるクライアントの要求を再ルーティングするために使用されます。Oracle Databaseでは、クライアントとデータベース間の接続にVIPを使用するため、VIPアドレスはパブリックにアクセス可能である必要があります。名前はhostname-vip形式で指定することをお薦めします。たとえば、myclstr2-vipです。
仮想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クライアントは、SCANを使用してOracle Real Application Clustersデータベースに接続します。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 12cリリース1 (12.1)にアップグレードすると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アドレスへの接続はできないためです。
クラスタへのクライアント・アクセス用のSCANアドレスを指定します。このアドレスは、ドメイン・ネーム・サービス(DNS)にラウンド・ロビン・アドレスとして構成してください。SCANアドレスは、3つ指定することをお薦めします。
|
注意: 次に、ノードIPアドレスに関する追加情報を示します。
|
パブリック・インタフェースおよびプライベート・インタフェースを指定します。OUIは、パブリックIPアドレスおよび仮想IPアドレスによって使用されるようにパブリック・インタフェースを構成し、プライベートIPアドレスをプライベート・インタフェース上に構成します。
プライベート・インタフェースが使用するプライベート・サブネットは、クラスタ・メンバーにする予定のすべてのノードに接続する必要があります。
Oracle Clusterware 12cリリース1 (12.1)には、クラスタ時刻同期化サービス(CTSS)が自動的に構成されます。このサービスでは、デプロイしたクラスタのタイプに最適な同期方法で、すべてのクラスタ・ノードが自動的に同期されます。NTPなどの既存のクラスタ時刻同期化サービスがある場合、このサービスはオブザーバ・モードで開始されます。それ以外の場合は、アクティブ・モードで開始され、クラスタ・ノード間の時刻の同期を確実にします。CTSSで互換性の問題が発生することはありません。
CTSSモジュールはOracle Grid Infrastructureのインストールの一環としてインストールされます。CTSSデーモンはOHASデーモン(ohasd)によって起動されるため、コマンドライン・インタフェースは必要ありません。
Oracle Flex Cluster構成でインストールされるOracle Grid Infrastructureは、スケーラブルで動的、強固なノード・ネットワークです。Oracle Flex Clusterでは、高可用性のために調整および自動化が必要な他のサービス・デプロイメントのプラットフォームも提供されます。
Oracle Flex Cluster内のすべてのノードは、単一のOracle Grid Infrastructureクラスタに属します。このアーキテクチャでは、様々なサービス・レベル、負荷、障害のレスポンス、およびリカバリに対処するために、アプリケーション・ニーズに基づいてリソースのデプロイメントに対するポリシー決定が集中管理されます。
Oracle Flex Clusterには、ハブおよびスポーク・アーキテクチャに配置される2つのタイプのノード(ハブ・ノードおよびリーフ・ノード)が含まれます。Oracle Flex Cluster内のハブ・ノードの最大数は64です。リーフ・ノードの数は、さらに多くできます。ハブ・ノードおよびリーフ・ノードでは、様々なタイプのアプリケーションをホストできます。
Oracle Flex Clusterのハブ・ノードは、密接に接続されて共有記憶域に直接アクセスできる点が、標準構成のOracle Grid Infrastructureノードに類似しています。
リーフ・ノードは、共有記憶域への直接アクセスが必要ない点で、標準のOracle Grid Infrastructureノードと異なります。ハブ・ノードは、リーフ・ノードをクラスタ･メンバー･ノードとして含まないOracle Flex Cluster構成で実行できますが、リーフ・ノードは、ハブ・ノードのプールを含むクラスタのメンバーである必要があります。
|
関連項目:
|
Oracle Automatic Storage Managementクラスタ・ファイル・システムの理解
スタンドアロンのOracle ASMインストールのクラスタ・インストールへの変換
Oracle Automatic Storage Managementは、拡張されて汎用ファイル・システムであるOracle Automatic Storage Managementクラスタ・ファイル・システム(Oracle ACFS)を含むようになりました。Oracle ACFSは、複数のプラットフォームに対応するスケーラブルな新しいファイル・システムとしてストレージを管理します。このテクノロジにより、Oracle Automatic Storage Management (Oracle ASM)機能は、Oracle Databaseの外で保持されているカスタマ・ファイルをサポートするように拡張されます。Oracle ACFSがサポートするファイルには、アプリケーション・バイナリ、アプリケーション・レポートなどがあります。他にも、ビデオ、オーディオ、テキスト、イメージ、設計図、その他の汎用アプリケーションのファイル・データがサポートされます。
自動ストレージ管理クラスタ・ファイル・システム(ACFS)では、Oracle Databaseバイナリなど、すべてのOracleファイルのための最適化された記憶域が提供されます。その他のアプリケーション・ファイルも格納できます。ただし、Oracle Clusterwareバイナリには使用できません。
|
参照: ACFSの詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。 |
以前のリリースのOracle ASMが、サーバー上または既存のOracle Clusterwareインストール環境内にインストールされている場合は、パスGrid_home/binにあるOracle Automatic Storage Management Configuration Assistant (ASMCA)を使用して、既存のOracle ASMインスタンスをOracle ASM 12cリリース1 (12.1)にアップグレードし、その後で障害グループ、ASMボリュームおよびOracle Automatic Storage Managementクラスタ・ファイル・システム(ACFS)を構成できます。
|
注意: 既存のOracle ASMインスタンスのアップグレードは、そのノード上のすべてのデータベース・インスタンスおよびアプリケーションを停止してから実行する必要があります。 |
インストール時に、Oracle ASMを使用することを選択したときに、以前のOracle ASMバージョンが別のホームにインストールされていることがASMCAで検出された場合は、Oracle ASM 12cリリース1 (12.1)のバイナリをインストールした後に、ASMCAを起動して既存のOracle ASMインスタンスをアップグレードできます。次に、Oracle ASMボリュームを作成し、アップグレードしたOracle ASMを使用してOracle ACFSを作成することで、Oracle ACFSのデプロイメントを構成できます。
Oracle ClusterwareまたはOracle RACの既存のインストール環境で、すべてのノード上のOracle ASMインスタンスの旧バージョンがOracle ASM 11gリリース1 (11.1)の場合は、Oracle ASMインスタンスのローリング・アップグレードを実行できます。Oracle RACのインストール環境で、旧バージョンのOracle ASMインスタンスがOracle ASM 11gリリース1 (11.1)よりも前のリリースの場合は、ローリング・アップグレードを実行できません。Oracle ASMは、すべてのノードで12cリリース1 (12.1)にアップグレードされます。
クラスタのメンバー・ノードの中に、既存のスタンドアロンのOracle ASMがインストールされているノードが1つ以上ある場合でも、OUIは、クラスタ用のOracle Grid Infrastructureのインストールを開始します。
Oracle Clusterwareファイル(OCRおよび投票ファイル)をOracle ASM上に配置すると、クラスタウェアのインストール終了時にASMCAが起動し、ローカル・ノード上のOracle ASMインスタンスを移行およびアップグレードするためのプロンプトが表示され、Oracle ASM 12cリリース1 (12.1)環境が作成されます。
リモート・ノードでスタンドアロンのOracle ASMインスタンスが実行されていることをASMCAが認識すると、そのOracle ASMインスタンスと、そのOracle ASMインスタンスを使用しているデータベース・インスタンスを停止するように求められます。次に、ASMCAは、クラスタ化されたOracle ASMインスタンスをクラスタ内のすべてのノードに展開します。ただし、クラスタ対応のOracle ASMインスタンスのディスク・グループ名は、既存のスタンドアロンのディスク・グループ名と異なっている必要があります。
|
関連項目: 『Oracle Automatic Storage Management管理者ガイド』 |
アウトオブプレース・アップグレードでは、インストーラは新しいバージョンを別のOracle Clusterwareホームにインストールします。Oracle Clusterwareの新旧バージョンが各クラスタ・メンバー・ノードに存在することになりますが、アクティブになるバージョンは1つのみです。
ローリング・アップグレードは、ソフトウェアの新バージョンへのアップグレード中、停止時間をなくし、可用性の継続を保証します。
各ノード上に別々のOracle Clusterwareホームがある場合、すべてのノードでアウトオブプレース・アップグレードを行うか、またはアウトオブプレース・ローリング・アップグレードを行うことができます。そうすることで、あるノードでは旧バージョンのOracle ClusterwareホームからOracle Clusterwareを実行し、別のノードでは新バージョンのOracle ClusterwareホームからOracle Clusterwareを実行することが可能です。
Oracle Grid Infrastructureのインプレース・アップグレードはサポートされません。
