| Oracle® Grid Infrastructureインストレーション・ガイド 11gリリース2 (11.2) for Microsoft Windows x64 (64-Bit) B58876-07 |
|
 前 |
 次 |
| Oracle® Grid Infrastructureインストレーション・ガイド 11gリリース2 (11.2) for Microsoft Windows x64 (64-Bit) B58876-07 |
|
前 |
次 |
この付録では、インストール前に実行を要求される作業の理由、およびその他のインストールの概要について説明します。
この付録の内容は次のとおりです。
この項では、クラスタ用Oracle Grid Infrastructureのインストール前に必要な作業の概要を確認します。この章には次の項目があります。
Oracleインベントリ・ディレクトリには、サーバーにインストールされたすべてのOracleソフトウェア用の中央インベントリがあります。Oracleインベントリ・ディレクトリの場所は<System_drive>:\Program Files\Oracle\Inventoryです。
システムにOracleソフトウェアを初めてインストールする場合、Oracleインベントリ・ディレクトリが存在するかどうかがインストーラによって確認されます。Oracleインベントリ・ディレクトリの場所は、Windowsレジストリ・キーHKEY_LOCAL_MACHINE\SOFTWARE\Oracle\inst_locによって判断されます。Oracleインベントリ・ディレクトリが存在しない場合は、インストーラによってC:\Program Files\Oracle\Inventoryのデフォルトの場所に作成されます。
|
注意: Windowsレジストリでのinst_locの値の変更は、サポートされていません。 |
デフォルトでは、Oracle Inventoryディレクトリはインストール所有者のOracleベース・ディレクトリ下にはインストールされません。これは、すべてのOracleソフトウェア・インストールで共通のOracleインベントリを共有するため、Oracleインベントリはすべてのユーザー用に1つしかありませんが、Oracleベース・ディレクトリはユーザーごとにあるからです。
インストール時に、Oracleベースの場所を指定するように求められます。Oracleベースは、インストールを実行するユーザーが所有します。既存のOracleホームが含まれるディレクトリを選択するか、またはOracleベース・ディレクトリの構造を持っていない別のディレクトリを選択できます。Oracleベース・ディレクトリのデフォルトの場所は、<SYSTEM_DRIVE>:\app\user_name\です。
Oracleベース・ディレクトリ・パスを使用すると、Oracleインストール、パラメータ・ファイル、診断ファイルおよびログ・ファイルの構造が簡略化され、複数のデータベース・インストールでOptimal Flexible Architecture(OFA)構成を保持しやすくなります。
複数のOracle Databaseインストールで、同じOracleベース・ディレクトリを使用できます。Oracle Grid Infrastructureインストールは、異なるディレクトリ・パス(Oracleベース以外のパス)を使用します。異なるオペレーティング・システム・ユーザーでOracleソフトウェアをインストールする場合は、各ユーザーが異なるデフォルトのOracleベースの場所を持つことになります。
インストール時に、Oracle Universal Installer(OUI)がクラスタ・ノードで検出するネットワーク・インタフェースごとに計画された使用方法を指定するように求められます。各インタフェースを、パブリック・インタフェースまたはプライベート・インタフェース、あるいはOracle Clusterwareで使用しないインタフェースとして指定します。パブリック・アドレスおよび仮想インターネット・プロトコル(VIP)・アドレスは、パブリック・インタフェース上に構成されます。プライベート・アドレスはプライベート・インタフェース上に構成されます。
各アドレス・タイプの詳細は、次の項を参照してください。
パブリックIPアドレスは、動的ホスト構成プロトコル(DHCP)を使用して動的に割り当てられるか、ドメイン・ネーム・システム(DNS)またはhostsファイルで静的に定義されます。パブリック・インタフェース(クライアントからアクセス可能なインタフェース)が使用されます。
Oracle Clusterwareは、プライベートとマークされたインタフェースを使用してノード間通信を行います。各クラスタ・ノードは、インストール時にプライベート・インタフェースとして指定されたインタフェースを持つ必要があります。プライベート・インタフェースはそのインタフェース用に構成されたアドレスを持つ必要がありますが、それ以上の構成は必要ありません。Oracle Clusterwareは、プライベートと指定されたインタフェースを、クラスタ・インターコネクトとして使用します。プライベートとして指定するインタフェースはいずれも、クラスタのすべてのノードに接続するサブネット上に存在しなければなりません。Oracle Clusterwareは、プライベート・インタフェース用に指定された、すべてのインタフェースを使用します。
プライベート・インターコネクトの場合は、ノード間のキャッシュ・フュージョンおよびその他のトラフィックのため、物理的に別のプライベート・ネットワークを使用することをお薦めします。DNSを使用してアドレスを構成する場合は、プライベートIPアドレスがクラスタ・ノードからのみ到達可能であることを確認する必要があります。
インストール後、CLUSTER_INTERCONNECTS初期化パラメータを使用してOracle Real Application Clusters(Oracle RAC)のインターコネクトを変更する場合は、パブリックIPアドレスで使用されていないサブネット上またはoifcfgでパブリック・サブネットとしてマークされていないサブネット上で、インターコネクトをプライベートIPアドレスに変更する必要があります。パブリック・サブネットとして指定したサブネットを使用するインタフェースにインターコネクトを変更することはできません。
プライベート・ネットワークIPアドレスを使用したネットワークではファイアウォールを使用しないでください。プライベート・ネットワークIPアドレスによってインターコネクト・トラフィックがブロックされる可能性があるためです。
仮想IP(VIP)アドレスは、グリッド・ネーミング・サービス(GNS)またはDNSに登録されています。次の要件を満たすVIPのアドレスを選択します。
IPアドレスとホスト名は、現在未使用である(DNSに登録できるが、pingコマンドでアクセスできない)
VIPはパブリック・インタフェースと同じサブネット上にある
GNS VIPアドレスは、DNSで構成される静的なIPアドレスです。DNSはGNS VIPアドレスに問合せを委任し、GNSデーモンはそのアドレスで、受信した名前解決要求に応答します。
GNSは、Oracle Clusterwareで提供されるマルチキャスト・ドメイン・ネーム・サービス(mDNS)をサブドメイン内で使用し、クラスタにノードが追加または削除されると、ホスト名およびIPアドレスを動的にマップできるようにします。DNSで新たにホスト構成を行う必要はありません。
GNSを有効にするには、クラスタに割り当てられたサブドメインのIPアドレス(grid.example.comなど)をネットワーク管理者に教えてもらい、そのサブドメインへのDNS要求を、クラスタのGNS VIPアドレスに委任してもらう必要があります(GNSはそのアドレスで機能します)。一連のIPアドレスはDHCP経由でクラスタに提供されます。これらのアドレスは、クラスタのパブリック・ネットワーク上で使用できる状態でなくてはなりません。
|
関連項目: GNSの詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
Oracle Database 11gリリース2のクライアントは、単一クライアント・アクセス名(SCAN)を使用してデータベースに接続します。SCANとそれに関連付けられたIPアドレスは、クラスタを構成するノードとは無関係に、クライアントが接続に使用する安定した名前を提供します。SCANアドレス、仮想IPアドレス、およびパブリックIPアドレスはすべて、同じサブネット上に存在する必要があります。
SCANは、node1-vipのような、VIPアドレスに使用される名前に類似したVIP名です。ただし、VIPと異なり、SCANは個別のノードではなくクラスタ全体と関連付けられており、1つではなく複数のIPアドレスと関連付けられています。
SCANは、パブリック・クライアント接続を処理するクラスタ内の複数のリスナーを反映し、複数のIPアドレスに解決されます。クライアントから要求が送信されると、SCAN IPアドレスおよびSCANポート上でリスニングしているSCANリスナーがクライアントから使用できるようになります。クラスタ上のすべてのサービスがSCANリスナーに登録されているため、SCANリスナーは、現在サービスを提供している最も負荷が低いノードのローカル・リスナー・アドレスを使用して応答します。最後に、サービスが提供されているノード上のリスナーを通じて、クライアントがサービスへの接続を確立します。これらすべての動作はクライアントに対して透過的に行われ、クライアントでの明示的な構成は必要ありません。
インストール中にリスナーが作成されます。これらのSCANリスナーは、SCAN IPアドレスでリスニングを行います。SCANリスナーは、Oracle Clusterwareによって決定されるノードで起動されます。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形式で設定する必要があります。HOST= SCAN_nameなどのように、SCANが指定された1つのアドレスのTNSNAMES別名は設定しないでください。
SCANはほとんどのデプロイメントでオプションです。ただし、サーバー・プールを使用するOracle Database 11gリリース2以上のポリシー管理データベースを使用するクライアントは、SCANを使用してデータベースにアクセスする必要があります。ポリシー管理データベースは異なるサーバーで異なる時刻に実行されることがあるため、これは必須であり、そのため、あるポリシー管理データベースの仮想IPアドレスを使用して特定ノードに接続することはできません。
Oracle Clusterware 11gリリース2 (11.2)には、クラスタ時刻同期化サービス(CTSS)が自動的に構成されます。このサービスでは、デプロイしたクラスタのタイプに最適な同期方法で、すべてのクラスタ・ノードの時刻設定が自動的に同期されます。ネットワーク・タイム・プロトコル(NTP)、Windows Timeサービスなどの既存のクラスタ同期サービスがある場合、このサービスはオブザーバ・モードで開始されます。既存のサービスがない場合、このサービスはアクティブ・モードで開始され、クラスタ・ノード間の時刻の同期を確実にします。CTSSで互換性の問題が発生することはありません。
CTSSモジュールはOracle Grid Infrastructureのインストールの一環としてインストールされます。CTSSデーモンはOracle高可用性サービス・デーモン(ohasd)によって起動されるため、コマンドライン・インタフェースは必要ありません。
次の項では、Oracle Automatic Storage Management (Oracle ASM)の記憶域の概要について説明します。
Oracle ASMは、拡張されて汎用ファイル・システムであるOracle Automatic Storage Management (Oracle ACFS)を含むようになりました。Oracle ACFSは、複数のプラットフォームに対応するスケーラブルな新しいファイル・システムとしてストレージを管理し、このテクノロジにより、Oracle ASM機能は、Oracle Databaseの外で保持されているカスタマ・ファイルをサポートするように拡張されます。Oracle ACFSがサポートするファイルには、アプリケーション実行可能ファイル、アプリケーション・レポートなどがあります。他にも、ビデオ、オーディオ、テキスト、イメージ、設計図、その他の汎用アプリケーションのファイル・データがサポートされます。
|
注意:
|
以前のリリースのOracle ASMが、サーバー上または既存のOracle Clusterwareインストール環境内にインストールされている場合は、パスGrid_home\binにあるOracle Automatic Storage Management Configuration Assistant(ASMCA)を使用して、既存のOracle ASMインスタンスをOracle ASM 11gリリース2 (11.2)にアップグレードし、その後で障害グループ、Oracle ASMボリュームおよびOracle ACFSを構成できます。
|
注意: 既存のOracle ASMインスタンスのアップグレードは、そのノード上のすべてのデータベース・インスタンスおよびアプリケーションを停止してから実行する必要があります。 |
インストール時に、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リリースの場合は、ローリング・アップグレードを実行できません。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やメモリーなど)の使用量にのみ制限され、単一システム環境にデプロイされているように動作します。
リソースは、サーバー・プールを使用して動的に管理することで、クラスタ内のリソースをポリシー・ベースで管理することができます。また、特定のノードで実行するように物理的にリソースを割り当てる従来の方法で管理することもできます。
Oracle Grid Infrastructureのインストール所有者には、サーバー制御ユーティリティ(SRVCTL)、Oracle Enterprise Manager Database ControlまたはOracle Database Configuration Assistant(DBCA)を使用して、サーバー・プールを作成および構成する権限があります。
ポリシー・ベースの管理では、次の機能が提供されます。
必要時に動的な容量の割当てが可能で、ポリシーで設定した優先度に従ってサーバーの容量を指定できます。
重要度ごとにリソースの割当てが可能で、アプリケーションが可能なかぎり必要最小限のリソースを取得できます。また、優先度が低いアプリケーションが、より重要なアプリケーションのリソースを消費しないようにすることもできます。
必要時には分離が保証され、アプリケーションとデータベースについて、クラスタの専用サーバーを指定できます。
サーバー・プールで実行しているアプリケーションとデータベースは、リソースを共有しません。このため、サーバー・プールは必要に応じてリソースを分離しますが、必要時は動的な容量の割当てが可能です。役割区分による管理とともにこの機能を使用することで、標準化されたクラスタ環境を持つ組織のニーズに対応できますが、複数の管理者グループが共通のクラスタ・インフラストラクチャを共有できるようになります。
サーバー・プールは、クラスタを同じまたは類似したリソースのホスティングするサーバーのグループに分割します。サーバー・プールによって、クラスタの複数のサーバーに対し、統一されたワークロード(一連のOracle Clusterwareリソース)が分散されます。たとえば、Oracle Databaseが特定のサーバー・プールのみで実行されるように制限できます。役割区分管理を有効にすると、特定のサーバー・プールの属性を変更する権限をオペレーティング・システム・ユーザーに明示的に付与できます。
|
注意: デフォルトでは、すべての名前付きユーザーがサーバー・プールを作成できます。この権限を持つオペレーティング・システム・ユーザーを制限するには、CRS管理者リストに特定のユーザーを追加することをお薦めします。CRS管理リストへのユーザーの追加の詳細は、『Oracle Clusterware管理およびデプロイメント・ガイド』を参照してください。 |
最上位のサーバー・プール:
クラスタを論理的に分割します。
常に排他的です。これは、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管理およびデプロイメント・ガイド』を参照してください。 |
汎用サーバー・プールには、Oracle Database 11gリリース1 (11.1)以前のデータベース、および管理者が管理する構成が固定されたデータベースが格納されます。また、次のいずれかを満たすサーバーも含まれます。
アプリケーション・リソース・タイプのすべてのリソースのHOSTING_MEMBERS属性で指定したサーバー
汎用サーバー・プールを親サーバー・プールとするサーバー・プールのSERVER_NAMES属性で指定した名前を持つサーバー
汎用サーバー・プールの属性は、次のように制限されます。
汎用サーバー・プールの構成属性は変更できません(すべての属性は読取り専用です)。
HOSTING_MEMBERS属性でサーバー名を指定した場合、サーバーが次の状態であるときにOracle Clusterwareはその名前を許可します。
オンラインで汎用サーバー・プールに存在する。
オンラインで空きサーバー・プールに存在する。この場合、Oracle Clusterwareによってサーバーが汎用サーバー・プールに移動されます。
オンラインで、他のサーバー・プールに存在し、クライアントがCRS管理者であるか、またはサーバー・プールのサーバーを使用することが許可されている。この場合、サーバーは汎用サーバー・プールに移動されます。
オフラインで、クライアントがCRS管理者。
子サーバー・プールを汎用サーバー・プールに登録した場合、リソースに対して以前に指定したものと同じ要件をサーバー名が満たす場合にのみ、Oracle Clusterwareはその子サーバー・プールを許可します。
サーバーは、クラスタの起動時またはサーバーがクラスタに追加されるときに汎用サーバー・プールに割り当てられ、その後で、他のサーバー・プールに割り当てられます。
Oracle Grid Infrastructureのアウトオブプレース・アップグレードでは、インストーラは新しいバージョンのソフトウェアを別のGridホームにインストールします。Oracle Clusterwareの新旧バージョンが各クラスタ・メンバー・ノードに存在することになりますが、アクティブになるバージョンは1つのみです。
各ノード上に別々のOracle Clusterwareホームがある場合、すべてのノードでアウトオブプレース・アップグレードを行うか、またはアウトオブプレース・ローリング・アップグレードを行うことができます。そうすることで、あるノードでは旧バージョンのOracle ClusterwareホームからOracle Clusterwareを実行し、別のノードでは新バージョンのOracle ClusterwareホームからOracle Clusterwareを実行することが可能です。ローリング・アップグレードは、ソフトウェアの新バージョンへのアップグレード中、停止時間をなくし、可用性の継続を保証します。
Oracle Clusterware 11gリリース2のインプレース・アップグレードはサポートされていません。
