1 Oracle Clusterwareの概要
Oracle Clusterwareの概念とコンポーネントです。
Oracle Clusterwareを使用すると、複数のサーバーが相互に通信することにより、1つの集合単位として機能するように見えます。このようなサーバーの組合せは、一般にクラスタと呼ばれます。これらのサーバーはスタンドアロン・サーバーですが、各サーバーには他のサーバーと通信する追加のプロセスがあります。このように、個々のサーバーはアプリケーションおよびエンド・ユーザーから1つのシステムとして認識されます。
この章の内容は次のとおりです。
1.1 Oracle Clusterwareの概要
Oracle Clusterwareは、統合環境に包括的な複数層の高可用性およびリソース管理を提供するポータブル・クラスタ・ソフトウェアです。独立したサーバーのクラスタリングが単一システムとして連携するようにサポートします。
Oracle Clusterwareは、Oracle Real Application Clusters (Oracle RAC)の統合された基盤であり、任意の主要なプラットフォーム上のすべてのアプリケーションに対する高可用性およびリソース管理フレームワークです。Oracle Clusterwareは最初、Oracle複数インスタンス・データベース(Oracle RAC)に必要なクラスタ技術として、Oracle Database 10gリリース1 (10.1)とともにリリースされました。目的は、クラウドでOracle Clusterwareを活用して、必要な状況でエンタープライズ・クラスの回復性を提供すること、および必要な場所と時間に計算リソースの動的なオンライン割当てを提供することです。
Oracle Flex Cluster
Oracle Clusterware 12c リリース2 (12.2)では、すべてのクラスタがOracle Flex Clusterとして構成されます。つまり、クラスタは1つ以上のハブ・ノードを使用して構成され、多数のリーフ・ノードをサポートできます。以前のバージョンのOracle Clusterwareで現在構成されているクラスタは、Oracle Flex ASM (Oracle Flex Clusterの要件)のアクティブ化を含むアップグレード・プロセスの一部として、適切に変換されます。
Oracle Flex Cluster内のすべてのノードは、単一のOracle Grid Infrastructureクラスタに属します。このアーキテクチャでは、様々なサービス・レベル、負荷、障害のレスポンス、およびリカバリに対処するために、アプリケーション・ニーズに基づいてリソースのデプロイメントに対するポリシー決定が集中管理されます。
Oracle Flexクラスタには、ハブおよびスポーク・アーキテクチャに配置される2つのタイプのノード(ハブ・ノードおよびリーフ・ノード)が含まれます。Oracle Flex Cluster内のハブ・ノードの最小数は1、最大数は64で、リーフ・ノードの数はさらに多くできます。ハブ・ノードおよびリーフ・ノードでは、様々なタイプのアプリケーションをホストできます。
ハブ・ノードは共有記憶域と緊密に接続し、直接アクセスします。従来より、これらはOracle RACまたはOracle RAC Oneデータベース・インスタンスのホストとしてデプロイされます。リーフ・ノードは、共有記憶域への直接アクセスが必要なく、かわりにハブ・ノードを介してデータにアクセスする点が、ハブ・ノードと異なります。
Oracle Flex Clusterは、1つ以上のハブ・ノードと連携できますが、リーフ・ノードはオプションで、1つ以上のハブ・ノードを含むクラスタのメンバーとしてのみ存在できます。
クラスタの使用によるメリットは、次のとおりです。
-
アプリケーションのスケーラビリティ(Oracle RACおよびOracle RAC Oneデータベースを含む)
-
スケーラブルなシステムを低コストの汎用ハードウェアと組み合せることで、インフラストラクチャの総所有コストを削減できます。
-
フェイルオーバーの機能
-
サーバーをクラスタに追加してクラスタ・リソースを増やすことによって、クラスタ対応アプリケーションのスループットが必要に応じて向上します。
-
クラスタ内のすべてのノードでアプリケーションを実行できるため、クラスタ対応アプリケーションのスループットが向上します。
-
依存プロセスが適切な順序で確実に起動するように計画した順序でアプリケーションの起動をプログラムする機能
-
プロセスの監視、およびプロセスが停止した場合に再起動する機能
-
ハードウェアやソフトウェアの障害に起因する計画外停止時間を解消できます。
-
ソフトウェア・メンテナンスのための計画停止時間を削減または解消できます。
Oracle Clusterwareを構成して、ユーザー・アプリケーションとOracle Databaseの可用性を管理できます。Oracle RAC環境では、Oracle Clusterwareによってすべてのリソースが自動的に管理されます。Oracle Clusterwareが管理するすべてのアプリケーションおよびプロセスは、クラスタ・リソースまたはローカル・リソースのいずれかです。
Oracle Clusterwareは、Oracle RACを使用するために必要であり、Oracle RACが動作するプラットフォームで必要とされる唯一のクラスタウェアです。Oracle RACでは、引き続き特定のプラットフォームにおいて多くのサード・パーティ製クラスタウェア製品がサポートされますが、Oracle Clusterwareもインストールして使用する必要があります。Oracle Clusterwareをインストールして実行する各サーバーでは、同じオペレーティング・システムを実行している必要があります。
Oracle Clusterwareの使用により、ベンダー固有のクラスタウェアが不要になり、Oracleソフトウェアのみを使用するメリットが発揮されます。オラクル社では、Oracle Automatic Storage Management(Oracle ASM)によるディスク管理から、Oracle DatabaseおよびOracle RACによるデータ管理までのあらゆるソフトウェア・ソリューションを提供しています。さらに、基礎となるOracle Clusterwareの高可用性フレームワークとともに使用するときに、OracleサービスなどのOracle Database機能によって高度な機能が提供されます。
Oracle Clusterwareには、バイナリ以外に、ノードのメンバーシップ情報を記録する投票ファイルと、クラスタ構成情報を記録するOracle Cluster Registry(OCR)の2つのストアド・コンポーネントがあります。投票ファイルおよびOCRは、すべてのクラスタ・メンバー・ノードに使用可能な共有記憶域に存在する必要があります。
Clusterwareのアーキテクチャ
Oracle Clusterwareでは、インストール・プロセス中に、新しいクラスタに対する2つの異なるデプロイメント・アーキテクチャの選択肢が提供されます。ドメイン・サービス・クラスタと、アプリケーションおよびデータベースをホストするために使用されるメンバー・クラスタのいずれかを選択できます。
ドメイン・サービス・クラスタは、1つ以上のハブ・ノード(データベース・インスタンス用)とゼロ個以上のリーフ・ノードを持つOracle Flex Clusterです。共有記憶域は各ハブ・ノードにローカルにマウントされ、Oracle ASMインスタンスはすべてのハブ・ノードで使用可能です。さらに、管理データベースはクラスタ内でローカルに格納およびアクセスされます。このデプロイメントは、アップグレードされた既存のクラスタにも使用されます。
メンバー・クラスタにより、管理目的で複数のクラスタ構成がグループ化され、そのクラスタ・ドメイン内で使用可能な共有サービスが使用されます。そのクラスタ・ドメイン内のクラスタ構成は、次のとおりです。
-
ドメイン・サービス・クラスタ: クラスタ・ドメイン内の他のクラスタに一元化されたサービスを提供するクラスタ。サービスには、一元化されたグリッド・インフラストラクチャ管理リポジトリ(ここには、クラスタ・ドメイン内の各クラスタの管理データベースが存在します)、トレース・ファイル・アナライザ・サービス、オプションの高速ホーム・プロビジョニング・サービス、および統合されたOracle ASM記憶域管理サービス(多くの場合、提供されます)を含めることができます。
-
データベース・メンバー・クラスタ: Oracle RACまたはOracle RAC Oneデータベース・インスタンスをサポートすることを目的とし、その管理データベースはドメイン・サービス・クラスタにオフロードされ、ローカルのOracle ASM記憶域管理で構成することも、ドメイン・サービス・クラスタで提供される統合されたOracle ASM記憶域管理サービスを使用することもできるクラスタ。
-
アプリケーション・メンバー・クラスタ: Oracle RACまたはOracle RAC Oneデータベース・インスタンスのサポートに必要なリソースを使用せずにアプリケーションをサポートするために構成されるクラスタ。このクラスタ・タイプではローカルの共有記憶域は構成されず、実行されるアプリケーション・プロセスのために可用性が高くスケーラブルなプラットフォームを提供することを意図しています。
1.2 Oracle Clusterwareのシステム要件の理解
Oracle Clusterwareのハードウェアとソフトウェアの概念および要件。
Oracle Clusterwareを使用するには、ハードウェアとソフトウェアの概念および要件を理解する必要があります。
1.2.1 Oracle Clusterwareのハードウェアの概念および要件
ハードウェアの概念および要件の理解は、Oracle Clusterwareの正常なデプロイメントに役立ちます。
クラスタは、1つ以上のサーバーで構成されます。外部ネットワークへのアクセスは、クラスタのサーバー(クラスタ・メンバーまたはノードとも呼ばれる)の場合も、スタンドアロン・サーバーの場合と同じです。
注意:
多くのハードウェア・ベンダーが、1つのクラスタに単一の製品を使用してクラスタ構成を検証しています。クラスタリングを扱うのが初めてのユーザーは、この項の情報を使用することで、クラスタを作成するためのハードウェアを購入する際に、ハードウェアの調達に関する作業を簡素化できます。
クラスタに属するノードには、第2のネットワークが必要です。この第2のネットワークは、インターコネクトと呼ばれます。このため、クラスタ・メンバー・ノードには、2つ以上のネットワーク・インタフェース・カードが必要です(1つはパブリック・ネットワーク用、もう1つはプライベート・ネットワーク用)。インターコネクト・ネットワークは、クラスタ内のノードのみがアクセスできる単一のスイッチ(または複数のスイッチ)を使用するプライベート・ネットワークです。脚注1
注意:
Oracleでは、Oracle Clusterwareのインターコネクトとして、クロスオーバー・ケーブルの使用はサポートされていません。
クラスタのサイズは、クラスタで実行するワークロードの要件と、クラスタで構成したノードの数によって決まります。高可用性対応のクラスタを実装する場合は、インフラストラクチャのすべてのコンポーネントで次の冗長構成を使用します。
-
パブリック・ネットワーク用で、1つのアドレスを提供するために搭載される2つ以上のネットワーク・インタフェース
-
プライベート・インターコネクト・ネットワーク用の2つ以上のネットワーク・インタフェース
クラスタには、クラスタ内の各サーバーの記憶域への共有接続が必要です。Oracle Clusterwareは、ネットワーク・ファイル・システム(NFS)、iSCSI、Direct Attached Storage (DAS)、Storage Area Network (SAN)ストレージおよびNetwork Attached Storage (NAS)をサポートしています。
ストレージの冗長性を確保するには、通常、各サーバーからクラスタ対応ストレージに対して最低2つの接続を用意します。実際のI/O要件によっては、さらに多くの接続を用意することもあります。ストレージ・サブシステムを選択する際に、クラスタ全体のI/O要件を考慮することは重要です。
ほとんどのサーバーには、内部に1つ以上のローカル・ディスクが含まれます。通常、このディスクは、オペレーティング・システム・バイナリ用に使用されますが、ユーザーはこのディスクをOracleソフトウェアのバイナリ用としても使用できます。各サーバーでOracleバイナリの独自コピーを保持することのメリットは、高可用性が向上することであり、このため1つのバイナリの破損が同時にクラスタ内のすべてのノードに影響を及ぼすことがなくなります。また、これによってローリング・アップグレードも可能になり、停止時間を削減できます。
1.2.2 Oracle Clusterwareのオペレーティング・システムの概念および要件
Oracle Clusterwareをインストールする前に、まず、オペレーティング・システムをインストールして、検証する必要があります。
各サーバーには、インストールするOracle Clusterwareのリリースの動作が保証されたオペレーティング・システムが存在する必要があります。詳細は、使用するプラットフォームの『Oracle Grid Infrastructureインストレーションおよびアップグレード・ガイド』またはMy Oracle Support (以前のOracleMetaLink)の保証マトリックスを参照してください。
オペレーティング・システムをインストールして実行したら、Oracle Clusterwareをインストールしてクラスタを作成できます。Oracle Clusterwareは、Oracle Databaseとは別にインストールされます。Oracle Clusterwareのインストール後に、Oracle DatabaseまたはOracle RACをクラスタ内の任意のノードにインストールできます。
1.2.3 Oracle Clusterwareのソフトウェアの概念および要件
Oracle Clusterwareでは、投票ファイルを使用して、フェンシングの提供およびクラスタ・ノードのメンバーシップの判断が行われます。Oracle Cluster Registry (OCR)ではクラスタ構成情報が提供されます。投票ファイルとOCRはまとめてOracle Clustewareファイルと呼ばれます。
Oracle ClusterwareファイルはOracle ASMに格納する必要があります。Oracle ASMディスクの基礎となる記憶域が、RAIDのようにハードウェアによって保護されていない場合は、OCRおよび投票ファイル用に複数の場所を構成することをお薦めします。次に、投票ファイルおよびOCRについて説明します。
-
投票ファイル
Oracle Clusterwareでは、投票ファイルを使用して、クラスタのメンバーであるノードを判断します。投票ファイルはOracle ASMまたは共有記憶域で構成できます。
投票ファイルをOracle ASMで構成する場合は、投票ファイルを手動で構成する必要はありません。ディスク・グループの冗長性に応じて、適切な数の投票ファイルが作成されます。
投票ファイルをOracle ASMで構成しない場合は、高可用性を確保するために、物理的に異なるストレージに3つ以上の投票ファイルを配置することをお薦めします。これによって、シングル・ポイント障害を回避できます。単一の投票ファイルを構成した場合、冗長性のために外部のミラー化を使用することをお薦めします。
最大15の投票ファイルがサポートされていても、6つ以上の投票ファイルを使用しないことをお薦めします。
-
Oracle Cluster Registry
Oracle Clusterwareでは、Oracle Cluster Registry(OCR)を使用して、Oracle Clusterwareで制御するOracle RACデータベース、 リスナー、仮想IPアドレス(VIP)、サービスと任意のアプリケーションなどのコンポーネントの情報を格納および管理します。OCRには、一連のキーと値のペアからなる構成情報がツリー構造に格納されます。クラスタの高可用性を確保するために、複数のOCRの場所を定義することをお薦めします。さらに、次のような特徴があります。
-
最大5つのOCRの場所を使用できます。
-
各OCRの場所は、クラスタ内のすべてのノードがアクセスできる共有記憶域に存在している必要があります。
-
障害が発生したOCRの場所がOCRの唯一の場所でないかぎり、オンラインで交換できます。
-
OCRは、Oracle Enterprise Manager、Oracle Clusterware制御ユーティリティ(CRSCTL)、サーバー制御ユーティリティ(SRVCTL)、OCR構成ユーティリティ(OCRCONFIG)、Database Configuration Assistant(DBCA)などのサポートされているユーティリティを介して更新する必要があります。
-
関連トピック
1.2.4 Oracle Clusterwareのネットワーク構成の概念
Oracle Clusterwareを使用すると、クラスタのネットワーク要件の自己管理により、動的なOracle Grid Infrastructureが可能になります。
Oracle Clusterware 12cは、Dynamic Host Configuration Protocol (DHCP)またはVIPアドレス用のステートレス・アドレス自動構成とSingle Client Access Name (SCAN)アドレスの使用をサポートしていますが、パブリック・アドレスの使用はサポートしていません。DHCPはIPv4 VIPアドレスの動的割当てを行い、ステートレス・アドレス自動構成はIPv6 VIPアドレスの動的割当てを行います。
Oracle RACを使用する場合、すべてのクライアントはデータベースにアクセスできる必要があります。これは、クライアントは、VIP名およびSCAN名をすべてのVIPアドレスおよびSCANアドレスにそれぞれ解決する必要があることを意味しています。この問題は、グリッド・ネーミング・サービス(GNS)をクラスタに追加することによって解決します。GNSは会社のドメイン名サービス(DNS)にリンクされるため、クライアントは、ホスト名をこれらの動的アドレスに解決し、クラスタおよびデータベースに透過的に接続できます。Oracle Clusterware 12cでは、DHCPまたはゾーン委任なしのGNSの使用がサポートされています(ゾーン委任または動的ネットワークなしで構成できるOracle Flex ASMサーバーと同様です)。
注意:
Windows上にDHCPまたはゾーン委任がない場合、GNSの使用はサポートされていません。
Oracle Clusterware 12cから、GNSインスタンスは、1つのクラスタのかわりに複数のクラスタにサービスを提供できるため、DNSのGNSに委任する必要があるのは1つのドメインのみです。GNSは引き続き、以前のバージョンのOracle Clusterwareと同じサービスを提供します。
GNSサーバーが実行されるクラスタは、サーバー・クラスタと呼ばれます。クライアント・クラスタは、サーバー・クラスタを使用して名前を通知します。サーバー・クラスタでは1つのGNSデーモン・プロセスのみを実行できます。Oracle Clusterwareは、可用性を維持するために、GNSデーモン・プロセスをクラスタ内のノードの1つの上に置きます。
以前の単一クラスタ・バージョンのGNSでは、単一クラスタは、その内部でGNSサービス・プロバイダを簡単に探すことができました。ただし、マルチクラスタ環境ではクライアント・クラスタは、サーバー・クラスタのGNSアドレスを知る必要があります。このアドレスが与えられている場合、クライアント・クラスタは、サーバー・クラスタで実行されているGNSサーバーを見つけることができます。
サーバー・クラスタでGNSを動作させるには、次のことが必要です。
-
DNS管理者がゾーンをGNSで使用されるように委任すること
-
GNSインスタンスがネットワーク上のどこかで稼働しており、ファイアウォールでブロックされていないこと
-
GNSが提供するクラスタのセット内のすべてのノード名は一意である必要があります。
1.2.4.1 単一クライアント・アクセス名(SCAN)
Oracle Clusterwareでは、動的VIPアドレス構成に単一クライアント・アクセス名(SCAN)を使用でき、手動でサーバー構成を実行する必要がありません。
SCANは、DNSまたはGNSのIPアドレス(1つ以上3つ以下)に登録されているドメイン名です。GNSおよびDHCPを使用している場合、Oracle Clusterwareでは、クラスタの構成時に指定されるSCAN名のVIPアドレスが構成されます。
ノードVIPおよび3つのSCAN VIPは、GNSを使用時している場合、DHCPサーバーから取得されます。新しいサーバーがクラスタに追加されると、Oracle Clusterwareでは、必要なVIPアドレスはDHCPサーバーから動的に取得されてクラスタ・リソースが更新され、GNSを介してサーバーにアクセスできるようになります。
関連トピック
1.2.4.2 アドレスの手動構成
動的な構成にGNSおよびDHCPを使用するかわりに、手動でアドレスを構成することもできます。
アドレスの手動構成では、次のものを構成します。
-
ノードごとに1つのパブリック・アドレスとホスト名。
-
ノードごとに1つのVIPアドレス。
クラスタ内の各ノードにVIPアドレスを割り当てる必要があります。各VIPアドレスは、ノードのパブリックIPアドレスと同じサブネット上に存在し、DNSで名前を割り当てられているアドレスである必要があります。また、Oracle Clusterwareのインストール前は、各VIPアドレスがネットワーク内から使用されず、pingの実行も不可能であることが必要です。
-
クラスタ全体で最大3つのSCANアドレス。
注意:
SCANは、パブリック・ネットワークの1つ以上のアドレスに解決される必要があります。高可用性およびスケーラビリティを確保するために、パブリック・ネットワーク上の3つのアドレスに解決されるようにSCANを構成することをお薦めします。
1.3 Oracle Clusterwareのプラットフォーム固有のソフトウェア・コンポーネントの概要
稼働しているOracle Clusterware内で、様々なプラットフォーム固有のプロセスまたはサービスが各クラスタ・ノードで実行されます。
この項では、これらのプロセスおよびサービスについて説明します。
1.3.1 Oracle Clusterware技術スタック
Oracle Clusterwareは、クラスタ・レディ・サービス(CRS)デーモン(CRSD)によってアンカーされている上位技術スタックと、Oracle高可用性サービス・デーモン(OHASD)によってアンカーされている下位技術スタックという2つの別個の技術スタックで構成されています。
これらの2つの技術スタックには、クラスタ操作を円滑化する複数のプロセスがあります。次の項では、これらの技術スタックについて詳細に説明します。
1.3.1.1 クラスタ・レディ・サービス技術スタック
クラスタ・レディ・サービス(CRS)技術スタックは、様々なサービスを管理するために複数のプロセスを利用します。
次のリストでは、これらのプロセスについて説明します。
-
クラスタ・レディ・サービス(CRS):クラスタで高可用性操作を管理する主要プログラム。
CRSDは、各リソースのOCRに格納されている構成情報に基づいて、クラスタ・リソースを管理します。これには、起動、停止、監視およびフェイルオーバー操作が含まれます。CRSDプロセスは、リソースのステータスが変更されるとイベントを生成します。Oracle RACをインストールしている場合、CRSDプロセスはOracle Databaseインスタンスやリスナーなどを監視し、障害が発生した場合にこれらのコンポーネントを自動的に再起動します。
-
クラスタ同期サービス(CSS): クラスタのメンバーシップを管理し、ノードがクラスタに対して追加または削除された際にメンバーに通知することによって、クラスタ構成を管理します。保証されているサード・パーティ製クラスタウェアを使用している場合、CSSプロセスは、クラスタウェアとともに動作して、ノードのメンバーシップに関する情報を管理します。
cssdagent
プロセスは、クラスタの監視およびI/Oフェンシングを実行します。このサービスは、以前はOracle Process Monitor Daemon(oprocd
)(WindowsではOraFenceService
とも呼ばれる)によって提供されていました。cssdagent
で障害が発生した場合、Oracle Clusterwareによってノードが再起動されることがあります。 -
Oracle ASM: Oracle ClusterwareおよびOracle Databaseのディスク管理が提供されます。
-
クラスタ時刻同期化サービス(CTSS): Oracle Clusterwareのクラスタで時間管理が提供されます。
-
イベント・マネージメント(EVM): Oracle Clusterwareによって作成されたイベントを発行するバックグラウンド・プロセス。
-
グリッド・ネーミング・サービス(GNS): 外部DNSサーバーから送信されるリクエストを処理し、クラスタで定義されている名前の名前解決を実行します。
-
Oracle Agent (
oraagent
): クラスタウェアを拡張して、Oracle固有の要件および複雑なリソースをサポートします。このプロセスは、FANイベントが発生した場合にサーバー・コールアウト・スクリプトを実行します。このプロセスは、Oracle Clusterware 11gリリース1(11.1)ではRACGと呼ばれていました。 -
Oracle Notification Service (ONS): 高速アプリケーション通知(FAN)イベントの通信用のパブリッシュおよびサブスクライブ・サービス。
-
Oracle Root Agent(
orarootagent
):root
が所有しているネットワークやグリッド仮想IPアドレスなどのリソースをCRSDが管理するのを支援する専用のoraagent
プロセス。
クラスタ同期サービス(CSS)、イベント・マネージメント(EVM)およびOracle Notification Service (ONS)コンポーネントは、同じクラスタ・データベース環境で、他のノードのクラスタ・コンポーネント・レイヤーと通信します。また、これらのコンポーネントは、Oracle Database、アプリケーションおよびOracle Clusterwareの高可用性コンポーネント間における主要通信リンクです。さらに、これらのバックグラウンド・プロセスは、データベース操作を監視および管理します。
1.3.1.2 Oracle高可用性サービス技術スタック
Oracle高可用性サービス技術スタックは、Oracle Clusterwareの高可用性を提供するために複数のプロセスを使用します。
次のリストでは、Oracle高可用性サービス技術スタック内のプロセスについて説明します。
-
appagent
: 以前のバージョンのOracle Clusterwareで使用されていたapplication
リソース・タイプのリソースを保護します。 -
Cluster Logger Service (
ologgerd
): クラスタ内のすべてのノードから情報を受け取り、Oracle Grid Infrastructure管理リポジトリベースのデータベース内で持続します。このサービスは、クラスタ内の2つのノードのみで実行されます。 -
グリッド・プロセス間通信(GIPC): 冗長なインターコネクトの使用を可能にするサポート・デーモン。
-
グリッド・プラグ・アンド・プレイ(GPNPD): グリッド・プラグ・アンド・プレイ・プロファイルへのアクセスを提供し、クラスタのノード間でプロファイルの更新を調整して、すべてのノードで最新のプロファイルが保持されるようにします。
-
マルチキャスト・ドメイン名サービス(mDNS): クラスタ内のプロファイルを特定するためにグリッド・プラグ・アンド・プレイによって使用され、名前解決を実行するためにGNSによって使用されます。mDNSプロセスは、Linux、UNIXおよびWindowsのバックグラウンド・プロセスです。
-
Oracle Agent (
oraagent
): クラスタウェアを拡張して、Oracle固有の要件および複雑なリソースをサポートします。このプロセスは、Oracle Clusterware所有者として実行されるGIPC、GPNPD、GIPCなどのデーモンを管理します。注意:
このプロセスは、Cluster Ready Servicesテクノロジ・スタックで実行する同じ名前のプロセスとはまったく異なります。
-
Oracle Root Agent (
orarootagent
):root
が所有するCluster Health Monitor (CHM)などのリソースをCRSDが管理するのを支援する専用のoraagent
プロセス。注意:
このプロセスは、Cluster Ready Servicesテクノロジ・スタックで実行する同じ名前のプロセスとはまったく異なります。
-
scriptagent
: シェル・スクリプトまたはバッチ・スクリプトを使用してアプリケーションを保護する場合に、application
以外のリソース・タイプのリソースを保護します。 -
システム監視サービス(
osysmond
): 監視して、データをクラスタ・ログ出力サービスに送信するオペレーティング・システム・メトリック収集サービス。このサービスは、クラスタ内のすべてのノードで実行されます。
表1-1に、Oracle Clusterwareコンポーネントに関連付けられたプロセスおよびサービスを示します。表1-1で、UNIXまたはLinuxシステムのプロセスに(r)とある場合、そのプロセスがroot
ユーザーとして実行されることを示します。
注意:
Oracle ASMは1つのプロセスというだけではなく、インスタンスでもあります。Oracle Flex ASMの場合、Oracle ASMはすべてのクラスタ・ノードで必ずしも実行されるわけではなく、一部のクラスタ・ノードでのみ実行されます。表1-1 Oracle Clusterwareコンポーネントに関連付けられたプロセスおよびサービスのリスト
Oracle Clusterwareコンポーネント | LinuxおよびUNIXのプロセス | Windowsのプロセス |
---|---|---|
CRS |
|
|
CSS |
|
|
CTSS |
|
|
EVM |
|
|
GIPC |
|
|
GNS |
|
|
グリッドのプラグ・アンド・プレイ |
|
|
LOGGER |
|
|
マスターDiskmon |
|
|
mDNS |
|
|
Oracle Agent |
|
|
Oracle高可用性サービス |
|
|
ONS |
|
|
Oracle Root Agent |
|
|
SYSMON |
|
|
注意:
LinuxプラットフォームのOracle Clusterwareでは、複数のスレッドが、一意のプロセス識別子を持つ個別のプロセスとして表示される場合があります。
図1-2は、クラスタの起動を表しています。
1.4 Oracle Clusterwareのインストールの概要
インストールおよびデプロイメントの概念を理解していれば、Oracle Clusterwareを正常にデプロイメントできる可能性が高くなります。
注意:
Oracle Clusterwareは、Oracle Universal Installerを使用してインストールします。
1.4.1 Oracle Clusterwareのリリースの互換性
クラスタには、異なるリリースのOracle Clusterware、Oracle ASMおよびOracle Databaseをインストールできます。ただし、互換性に関する考慮事項に注意する必要があります。
クラスタに異なるリリースのソフトウェアをインストールする場合、次のガイドラインに従ってください。
-
クラスタ内で実行できるOracle Clusterwareのインストールは1つのみであり、Oracle Clusterwareは自身のホーム(
Grid_home
)にインストールする必要があります。使用するOracle Clusterwareのリリースは、クラスタ内で実行するOracle ASMおよびOracle RACのバージョン以上である必要があります。クラスタ内で実行するOracle Clusterwareのバージョンより後に公開されたOracle RACのバージョンをインストールすることはできません。つまり、次のようになります。-
Oracle Clusterware 12cは、Oracle ASM 12cのみをサポートしていますが、これは、Oracle ASMがOracle Grid Infrastructureホームにあり、これもOracle Clusterwareを含んでいるためです。
-
Oracle Clusterware 12cでは、Oracle Database 12cおよびOracle Database 11gリリース2 (11.2.0.3以上)がサポートされます
-
Oracle ASM 12cでは、Oracle Clusterware 12cが必要で、Oracle Database 12cおよびOracle Database 11gリリース2 (11.2.0.3以上)がサポートされます
-
Oracle Database 12cには、Oracle Clusterware 12cが必要です。
次に例を示します。
-
Oracle Clusterware 12cリリース2 (12.2)をクラスタウェアとしてインストールしている場合、1つのノードでOracle Database 11gリリース2 (11.2.0.4)単一インスタンス・データベースを実行し、またクラスタで別個のOracle Real Application Clusters 12cリリース1 (12.1.0.2)およびOracle Real Application Clusters 11gリリース2 (11.2.0.4)データベースも実行できます。
-
異なるリリースのOracle ASMおよびOracle Databaseを使用する場合、各製品の機能は、より古いリリースのソフトウェア機能に依存します。したがって、Oracle Clusterware 12cをインストールし、後でOracle ASMを構成し、Oracle Clusterwareを使用して既存のOracle Database 11g リリース2 (11.2.0.4)インストールをサポートする場合、Oracle ASM機能は、11g リリース2 (11.2.0.4)リリース・バージョンで使用可能な機能にのみ相当します。ディスク・グループのcompatible属性は、使用されているソフトウェアの適切なリリースに設定します。
-
-
-
クラスタでは、Oracle Databaseソフトウェア(シングル・インスタンスおよびOracle RACの両方)の複数のOracleホームを使用できます。Oracle RACデータベースのすべてのノードのOracleホームは同じである必要があります。
-
Oracle ClusterwareとOracle Databaseのホームでは、属しているプライマリ・グループが同じであれば異なるユーザーを使用できます。
-
Oracle Clusterware 12c以降では、クラスタ内で実行できるOracle ASMのインストールは1つのみです。Oracle ASMは常にOracle Clusterwareと同じバージョンであり、Oracle Clusterwareは、Oracle Databaseのリリースと同じか、それ以上のリリースである必要があります。
-
Oracle RAC 10gをインストールするには、Oracle Clusterwareもインストールする必要があります。
-
連携して動作する保証がないかぎり、同じサーバーでは異なるクラスタ・ソフトウェアを実行しないことをお薦めします。クラスタの一部であるサーバーにOracle RACを追加する場合は、Oracle Clusterwareに移行するか、次のことを確認します。
-
実行するクラスタウェアは、Oracle RAC 12cで動作するようにサポートされています。
-
Oracle Clusterwareと他のベンダーのクラスタウェアが連携して動作するための適切なオプションをインストール済であることを確認します。
-
1.5 Oracle Clusterwareのアップグレードおよびパッチ適用の概要
インプレース・パッチ適用によって、Oracle Clusterwareソフトウェアは同じGridホームの新しいバージョンに置き換えられます。アウトオブプレース・アップグレードの場合は、同じソフトウェアの両方のバージョンがノードに同時に存在しますが(Gridホームは異なる)、アクティブなバージョンは1つのみです。
Oracle Clusterware 12cの場合、Oracleでは、インプレースまたはアウトオブプレース・パッチ適用がサポートされます。Oracleでは、アウトオブプレース・アップグレードのみがサポートされます。これは、Oracle Clusterware 12cが専用の新しいGridホームを持つ必要があるためです。
Oracleでは、インプレース・パッチ適用についてはパッチ・バンドルおよび個別パッチがサポートされていますが、アウトオブプレース・アップグレードについてはパッチ・セットおよびメジャー・ポイント・リリースのみがサポートされています。
ローリング・アップグレードでは、停止時間が回避され、ソフトウェアが新しいバージョンにアップグレードされる間、Oracle Clusterwareの連続的な可用性が確保されます。Oracle Clusterware 12cにアップグレードすると、Oracle ClusterwareおよびOracle ASMバイナリは、Oracle Grid Infrastructureという単一バイナリとしてインストールされます。Oracle ClusterwareおよびOracle ASMはローリング方式でOracle Clusterware 11g リリース2 (11.2)からアップグレードできます。
Oracleでは、クラスタの一部のノードが停止している場合の強制アップグレードがサポートされます。
1.6 グリッド・インフラストラクチャ管理リポジトリの概要
グリッド・インフラストラクチャ管理リポジトリは、様々なクラスタ・クライアントが収集および必要とするリアルタイム・パフォーマンス・データやメタデータなど、クラスタに関する情報を格納します。
以前のバージョンのOracle Grid Infrastructureでは、グリッド・インフラストラクチャ管理リポジトリはGrid Infrastructureホームのスタンドアロン・データベースでした。これには、作成された最初のディスク・グループのディスク領域が必要で、その領域をOracle Cluster Registry (OCR)および投票ディスクと共有していました。スタンドアロン・クラスタの場合、Oracle Grid Infrastructureのインストール時に、OCRバックアップ・ファイルとともにグリッド・インフラストラクチャ管理リポジトリを独自のMGMTディスク・グループにインストールできます。
Oracleメンバー・クラスタでは、そのグリッド・インフラストラクチャ管理リポジトリがドメイン・サービス・クラスタのグリッド・インフラストラクチャ管理リポジトリ・コンテナ・データベース(CDB)内のプラガブル・データベース(PDB)である、そのドメイン・サービス・クラスタにあるグリッド・インフラストラクチャ管理リポジトリ・サービスが使用されます。これにより、ローカルのグリッド・インフラストラクチャ管理リポジトリを実行して、メンバー・クラスタのディスク・グループにそのデータ・ファイルを配置するための要件がなくなります。
さらに、Oracle Grid Infrastructureのインストール時に、ローカルのグリッド・インフラストラクチャ管理リポジトリとドメイン・サービス・クラスタのグリッド・インフラストラクチャ管理リポジトリの両方をMGMTディスク・グループにインストールできます。ドメイン・サービス・クラスタは、OCRおよび投票ディスクとは別にディスク・グループに配置する必要があります。
グリッド・インフラストラクチャ管理リポジトリについて、次に説明します。
-
クラスタ状態モニターによって収集されたリアルタイムのオペレーティング・システム・メトリックを格納する、Oracle Databaseです。クラスタ上でOracle Clusterware 12cのインストールまたはこれへのアップグレード中に、グリッド・インフラストラクチャ管理リポジトリを構成します。
注意:
Oracle ClusterwareをOracle Clusterware 12cにアップグレード中で、OCRおよび投票ファイルがRAWまたはブロック・デバイス上に格納されている場合、ソフトウェアをアップグレードする前に、これらをOracle ASMに移動する必要があります。
-
ハブ・ノードで実行し、ノードまたは記憶域の障害が発生したときの他のノードへのフェイルオーバーをサポートする必要があります。
-
プライベート・ネットワークを介して、あらゆるクラスタ・クライアント(クラスタ状態アドバイザ、クラスタ・リソース・アクティビティ・ログ、高速ホーム・プロビジョニング・サーバー、OLOGGERDおよびOCLUMONなど)との通信を行います。グリッド・インフラストラクチャ管理リポジトリは、パブリック・ネットワークを介して外部クライアント、ドメイン・サービス・クラスタおよびメンバー・クラスタのみと通信します。
-
Oracle Grid Infrastructureをインストールする際に作成できる独自のOracle ASMディスク・グループ
MGMT
にデータ・ファイルを格納することをお薦めします。インストール中にこのディスク・グループを作成しなかった場合、データ・ファイルはOCRおよび投票ファイルと同じ場所に配置されます。オラクル社では、グリッド・インフラストラクチャ管理リポジトリ(ネットワーク・ファイル・システム(NFS)、クラスタ・ファイル・システム、Oracle ASMディスク・グループなど)に対応するために、Oracle Clusterwareの共有ストレージ要件を増加しました。
-
mgmtdb
とmgmtlsnr
の名詞を使用したSRVCTLコマンドで管理されます。 -
保存については、その各クライアントのコマンドの1つのユーティリティで管理されます。
1.7 ドメイン・サービス・クラスタの概要
ドメイン・サービス・クラスタは、単一の管理ドメイン内にクラスタ・システムをデプロイするためのサービス指向インフラストラクチャのベースです。ドメイン・サービス・クラスタは、その管理ドメイン内のメンバー・クラスタにサービスを提供するために単独でデプロイされるOracleクラスタです。
メンバー・クラスタでは、必要なときに構成済サービスが使用されます。サービスには、一元化されたドメイン管理リポジトリ、記憶域管理サービスおよび高速ホーム・プロビジョニングが含まれます。
-
デプロイメントとプロビジョニングが簡単
-
構成した共有サービスは、何回でも再利用できます。
-
メンバー・クラスタごとに共有記憶域をプロビジョニングして構成する必要はありません。
-
共有記憶域管理サービスまたはローカルに構成された記憶域を使用するオプションでデータベース・メンバー・クラスタをデプロイします。
-
データベースのサポートなしでアプリケーション・メンバー・クラスタをデプロイして、消費リソースを抑えて、ローカルの共有記憶域が不要になります。
-
-
一元化された共有サービス
-
記憶域管理をドメイン・サービス・クラスタに統合すると、次のメリットがあります。
-
スケーリングの効率(記憶域と労力の節約)
-
すべての記憶域の同時管理
-
-
ローカル・クラスタからドメイン管理リポジトリにデータベース管理が遷移します。
-
メンバー・クラスタはドメイン・サービス・クラスタのOracle ACFSファイル・システムにアクセスできます。
-
クラスタ・ドメインは、ドメイン・サービス・クラスタと、提供されたサービスを使用するメンバー・クラスタで構成されます。すべてのクラスタはOracle Universal Installerを使用してデプロイされ、同じ標準のOracle Clusterwareを使用します。最初にドメイン・サービス・クラスタをデプロイして、その後それを使用して、デプロイされて必要なサービスに対して構成されたメンバー・クラスタにサービスを提供する必要があります。
-
Oracleデータベースとデータベース・リソースをサポートしないため、消費するメモリー・リソースが非常に少なくなります。
-
データベース・クラスタが必要とする共有記憶域にアクセスしません。
-
Oracle Cluster Registryの管理リポジトリと記憶域および一元化された記憶域で提供される投票ファイル。
-
共有記憶域をローカルで構成し、クラスタでローカルのOracle ASMインスタンスを使用します。
-
ドメイン・サービス・クラスタ上のリモートのOracle ASMを介して管理される記憶域に直接アクセスします。
-
ドメイン・サービス・クラスタ上のOracle ASM IOサービスを介して、Oracle ASM記憶域に間接的にアクセスします。
1.8 Oracle Clusterware環境の管理の概要
Oracle Clusterwareでは、環境を管理するためのいくつかの異なるユーティリティを用意しています。
次のリストに、Oracle Clusterware環境を管理するユーティリティを示します。
-
Cluster Health Monitor (CHM): Cluster Health Monitorは、オペレーティング・システムおよびクラスタ・リソースに関連した低下および障害を検出および分析して、ノードの削除など、Oracle ClusterwareおよびOracle RACの数多くの問題について詳細情報をユーザーに提供します。このツールは、オペレーティング・システム・リソースの消費状況を、ノード、プロセスおよびデバイス・レベルで継続的に追跡します。また、クラスタ全体のデータを収集し分析します。リアルタイム・モードでは、しきい値に達すると、ツールによってユーザーにアラートが表示されます。根本原因分析のため、履歴データを再生し、障害発生時に何が起きていたのかを理解できます。
-
クラスタ検証ユーティリティ(CVU): CVUは、クラスタとOracle RAC固有の様々なコンポーネントの検証に使用するコマンドライン・ユーティリティです。CVUを使用して、共有ストレージ・デバイス、ネットワーク構成、システム要件、Oracle Clusterware、およびオペレーティング・システムのグループやユーザーを検証します。
CVUをインストールして使用し、インストール前およびインストール後のクラスタ環境をチェックします。CVUは、Oracle ClusterwareおよびOracle RACコンポーネントのインストール前およびインストール時に特に役立ち、これによって、現在の構成がインストールの最小要件を満たしていることを確認できます。また、CVUを使用して、ノードの追加や削除などの管理タスクの完了後にその構成を検証できます。
-
Oracle Cluster Registryコンフィギュレーション・ツール(OCRCONFIG): OCRCONFIGは、OCR管理のためのコマンドライン・ツールです。また、OCRCHECKおよびOCRDUMPユーティリティを使用して、OCRに影響を及ぼす構成の問題のトラブルシューティングを実行できます。
-
Oracle Clusterware制御(CRSCTL): CRSCTLは、Oracle Clusterwareを管理するためのコマンドライン・ツールです。一般的なクラスタウェア管理、データベース以外のアプリケーション用の個々のリソース、構成ポリシーおよびサーバー・プールの管理には、CRSCTLを使用します。
Oracle Clusterware 12cには、クラスタ対応コマンドが導入されています。これらのコマンドを使用すると、操作に応じて、クラスタ内の別のノードに対して、またはクラスタ内のすべてのノードに対して、クラスタ内の任意のノードから操作を実行できます。
crsctl
コマンドを使用すると、クラスタ・リソースを監視したり(crsctl status resource
)、サーバー、および接頭辞ora.*
を持つ名前のサーバー・プール以外のサーバー・プールを監視および管理できます(crsctl status server
、crsctl status serverpool
、crsctl modify serverpool
、crsctl relocate server
など)。ノード固有のオプション引数-n
または-all
を使用して、クラスタ全体でOracle高可用性サービスを管理することもできます(crsctl start | stop | enable | disable | config crs
)。また、CRSCTLを使用して個々のノードでOracle Clusterwareを管理できます(crsctl start | stop | enable | disable | config crs
)。 -
Oracle Enterprise Manager: Oracle Enterprise Managerには、単一インスタンス環境とOracle RACデータベース環境の両方を管理するために、Cloud ControlインタフェースとGrid Control GUIインタフェースの両方があります。また、Oracle Clusterware、およびOracle Grid Infrastructureのインストールで構成したすべてのコンポーネントを管理するGUIインタフェースもあります。Oracle Enterprise Managerを使用して管理タスクを実行することをお薦めします。
-
Oracle Interface Configurationツール(OIFCFG):OIFCFGシングル・インスタンスのOracle DatabaseとOracle RAC環境の両方のコマンドライン・ツールです。OIFCFGを使用して、ネットワーク・インタフェースのコンポーネントへの割当ておよび割当て解除を行います。また、OIFCFGを使用して、特定のネットワーク・インタフェースを使用するようにコンポーネントを設定したり、コンポーネントの構成情報を取得できます。
-
サーバー制御ユーティリティ(SRVCTL): SRVCTLは、クラスタ内のデータベース、サービス、リスナーなどのOracleリソースを管理するためのコマンドライン・インタフェースです。
注意:
接頭辞
ora.*
を持つ名前のサーバー・プールのみ、SRVCTLを使用して管理できます。
1.9 コマンドの評価の概要
Oracle Clusterware制御(CRSCTL)ユーティリティを使用すると、Oracle Clusterware環境内でサーバー、サーバー・プールおよびポリシーを管理するためにCRSCTLコマンドを使用した場合に、どのような理由で(妥当なコマンドの評価)何が発生するか(コマンドの評価)について、実際に変更することなく評価できます。
コマンド評価は、計画済または計画外のイベントの結果を示す以外に、ポリシー管理環境で、Oracle Clusterwareのポリシー決定に関する仮定を検証する機能が役立ちます。妥当なコマンド評価の機能は、様々なCRSCTLコマンドの冗長出力を介してOracle Clusterwareで特定のアクションが実行される理由を示すことによって拡張されます。
サーバー・プールからサーバーを削除した場合に発生することの例を次に示します。
$ crsctl eval delete server mjk-node2-3 -explain
Stage Group 1:
-----------------------------------------------------------------------------
Stage Required Action
-----------------------------------------------------------------------------
1 E Server 'mjk-node2-3' is removed from server pool 'sp1'.
E Server pool 'sp1' is below the MIN_SIZE value of 2 with 1
servers.
E Looking at other server pools to see whether MIN_SIZE value 2 of
server pool 'sp1' can be met.
E Scanning server pools with MIN_SIZE or fewer servers in
ascending order of IMPORTANCE.
E Considering server pools (IMPORTANCE): sp2(2) for suitable
servers.
E Considering server pool 'sp2' because its MIN_SIZE is 2 and it
has 0 servers above MIN_SIZE.
E Relocating server 'mjk-node2-0' to server pool 'sp1'.
Y Server 'mjk-node2-3' will be removed from pools 'sp1'.
Y Server 'mjk-node2-0' will be moved from pools 'sp2' to
pools 'sp1'
===============================================================================
注意:
CRSCTLはサード・パーティ・リソースのみを評価できます。ora.orcl.db
など、oraという接頭辞が付いたリソースは、SRVCTLコマンドを使用して評価する必要があります。
1.10 グリッド環境でのOracle Clusterwareのクローニングおよび拡張の概要
ノードのクローニングは、新しいクラスタを作成する1つの方法です。クローニングを使用して、同じ構成で複数のクラスタを迅速に作成します。
クローニング・プロセスでは、Oracle Clusterwareソフトウェアのイメージが同様のハードウェアおよびソフトウェアを持つ他のノードにコピーされます。クローニングを使用する前に、プラットフォーム固有のOracle Clusterwareのインストレーション・ガイドに記載された手順を使用して、1つ以上のノードにOracle Clusterwareホームを正常にインストールする必要があります。
新規インストールの場合またはインストールするクラスタが1つのみの場合は、Oracle Universal InstallerやOracle Enterprise ManagerのProvisioning Pack機能など、自動化された対話型のインストール方法を使用することをお薦めします。これらの方法ではインストールのチェックが実行されるため、正常にインストールできます。クラスタ内のノードに対してOracle Clusterwareを追加または削除するには、addnode.sh
スクリプトおよびrootcrs.pl
スクリプトを使用します。
1.11 Oracle Clusterwareの高可用性フレームワークおよびAPIの概要
Oracle Clusterwareでは、クラスタで実行されるアプリケーションまたはプロセスを管理できる、CLSCRS APIという多くの高可用性Application Program Interfaceが提供されます。このCLSCRS APIによって、すべてのアプリケーションで高可用性を実現できます。
アプリケーションが実行されているクラスタ内のノードとは関係なくユーザーがアプリケーションにアクセスできるように、アプリケーションのVIPアドレスを定義できます。これは、アプリケーションVIPとも呼ばれます。複数のアプリケーションVIPを定義できます。通常、実行中のアプリケーションごとに1つのアプリケーションVIPを定義します。アプリケーションVIPは、Oracle Clusterwareにより定義されたアプリケーション・リソースに依存することでアプリケーションに関連付けられます。
Oracle Clusterwareコンポーネントは、高可用性を維持するために、定義されている高可用性規則に従い、ステータスの変化に応じてアプリケーションおよびプロセスを再起動できます。アプリケーションをOracle Clusterwareに登録し、クラスタウェアがアプリケーション・プロセスを起動、停止または再配置できるように構成することによって、Oracle Clusterwareの高可用性フレームワークを使用できます。これを行うには、Oracle Clusterwareを使用して、アプリケーションを監視、再配置および再起動するプロファイルを作成し、カスタム・アプリケーションの高可用性を確保します。
1.12 クラスタの時間管理の概要
クラスタ時刻同期化サービス(CTSS)によって、クラスタ内のノード間の時刻同期に関する問題を検出できます。
CTSSはOracle Clusterwareの一部としてインストールされます。時刻同期化サービス(NTPやChronyなど)または時刻同期化サービス構成が、有効でも無効でもシステム上で検知されれば、これはオブザーバ・モードで実行されます。たとえば、etc/ntp.conf
ファイルがクラスタ内の任意のノードに存在する場合、時刻同期化ソフトウェアが実行されていないときでも、CTSSはオブザーバ・モードで実行されます。
時刻同期化サービスまたは時刻同期化サービス構成がクラスタ内のどのノードにもないことをCTSSが検出した場合、CTSSはアクティブ・モードになり、クラスタの時刻管理を引き継ぎます。
CTSSがアクティブ・モードで実行されていて、NTP以外の別の時刻同期化ソフトウェアが実行されている場合、etc/ntp.conf
というファイルを作成することで、CTSSがオブザーバ・モードで実行されるように変更することができます。CTSSは、オブザーバ・モードの変更に関するアラート・ログにエントリを記録します。
ノードがクラスタに追加されると、CTSSではアクティブ・モードの場合、これらのノードの時刻がクラスタ内の1つのノードにある参照クロックと比較されます。2つの時刻の間に不一致があり、かつ、特定のステップ制限内に不一致がある場合、CTSSは、ステップ時間の同期を実行します。これは、基準と同期させるために、クラスタを結合するノードの時刻を前または後に移動させることです。
クラスタ内のノードのクロックは、様々な理由のために定期的に参照クロック(時刻CTSSが基準として使用し、クラスタ内で最初に起動するノードのクロック)と非同期になります。この場合、CTSSは時刻の同期化(Slew)を実行し、参照システムの時刻と同期するまで、ノードのシステムの時刻を速めたり、遅くします。この時刻の同期方法では、CTSSによって時刻が戻されることがないため、システムの時刻における単調増加が保証されます。
Oracle Clusterwareを起動したときに、CTSSがアクティブ・モードで実行されており、時刻の不一致が段階制限(制限は24時間)を超えている場合、CTSSはアラート・ログにアラートを生成して終了し、Oracle Clusterwareの起動は失敗します。クラスタに追加したノードの時刻をクラスタと同期するように手動で調整する必要があり、その後、Oracle Clusterwareを起動してCTSSでノードの時刻を管理することができます。
時刻の同期化(Slew)を実行する場合、CTSSでは参照クロックと同期するために時刻が戻されることはありません。CTSSによって定期的にアラート・ログにアラートが書き込まれ、これには、ノードが参照クロックと同期し続けるようにCTSSによって時刻が調整される頻度に関する情報が含まれます。
CTSSは、次の場合にOracle Clusterwareアラート・ログおよびsyslog
にエントリを書き込みます。
-
時刻の変更を検出したとき
-
参照ノードとの大きな時間の違いを検出したとき
-
モードがオブザーバからアクティブに切り替わるとき、またはその逆のとき
クラスタ内の時刻を同期させるためにCTSSを実行すると、Oracle Clusterwareの問題のトラブルシューティングに役立ちます。これは、様々なノードでのイベントの順序の時間オフセットを考慮に入れる必要がないためです。
1.12.1 クラスタの時間管理のアクティブ化および非アクティブ化
クラスタのCTSSをアクティブ化するには、クラスタ内のすべてのノードでベンダーの時刻同期サービスを停止し、構成を解除する必要があります。CTSSは、この操作を検出し、クラスタの時間管理を引き受けます。
たとえば、NTPの構成を解除するには、etc/ntp.conf
ファイルを削除するか、名前を変更する必要があります。
同様に、クラスタのCTSSを非アクティブ化するには、次の手順を実行します。
- クラスタ内のすべてのノードでベンダーの時刻同期サービスを構成します。CTSSは、この変更を検出し、オブザーバ・モードに戻ります。
crsctl check ctss
コマンドを使用して、CTSSがオブザーバ・モードで動作していることを確認します。- クラスタ内のすべてのノードでベンダーの時刻同期サービスを起動します。
cluvfy comp clocksync -n all
コマンドを使用して、時刻同期サービスが動作していることを検証します。
脚注の凡例
脚注1:Oracle Clusterwareでは、Oracle Database 10g リリース2 (10.2)以上のリリースが稼働する構成において、クラスタ内で最大100のノードがサポートされます。