この章では、Sun Cluster サーバー上で次の並列データベースシステムを構成し、管理する方法について説明します。
Oracle Parallel Server (OPS)
Informix-Online XPS
OPS は、Sun Cluster の共有ディスク構成を使用します。共有ディスク構成では、1 つのデータベースが複数の OPS インスタンス間で共有され、それら OPS インスタンスは同時にデータベースにアクセスします。同じデータへのアクセスの衝突は、分散ロックマネージャ (Oracle UNIX Distributed Lock Manager (DLM)) によって制御されます。プロセスまたはノードがクラッシュすると、DLM は再構成され、障害からの回復が図られます。
Informix-Online XPS は、Sun Cluster の非共有ディスク構成を使用します。各ノード上のデータベースサーバーインスタンスは、その専用のデータベースパーティションに対する独占的なアクセス権を持ちます。
クライアントからデータベース照会があると、そのテーブルパーティションがサーバーによって解析され、プライベートネットワーク経由で適切なサーバーに転送されます。結果はプライベートネットワーク経由でマージされ、クライアントに返されます。
OPS などの一部アプリケーションでは、/etc/system ファイルを編集して、要求される共有メモリーの最小サイズを非常に大きくしなければならないことがあります。しかし、たとえば、/etc/system ファイル内の shmsys:shminfo_shmmin フィールドに 200 バイトより大きな値を設定した場合、sm_config(1M) コマンドは共有メモリーを取得できません。これは、システムが割り当て可能な最小サイズより少ないバイト数が最終的に要求されることになるためです。この結果、sm_config(1M) による shmget(2) システムコールで問題が発生し、sm_config(1M) は異常終了します。
この問題を回避するには、/etc/system をエディタで開いて、shmsys:shminfo_shmmin に 200 を設定し、shmsys:shminfo_shmmax に 200 より大きな値を設定してください。新しい値を有効にするには、マシンを再起動します。
semsys 警告メッセージが表示され、コアダンプが発生した場合は、/etc/system ファイル内の semsys:seminfo_* フィールドに含まれているセマフォ値がマシンの実際の物理的な制限に一致していないことを意味します。
Oracle SQL*Net は、OPS 環境でノード障害が発生した場合に、IP フェイルオーバー機能を使用することなく正常に動作している残りのサーバーに再接続するように構成できます。
OPS 環境では、複数の Oracle インスタンスが協力して、同じ共有データベースへのアクセスを可能にします。Oracle クライアントは、インスタンスのどれを使用しても、データベースにアクセスできます。つまり、インスタンスに問題が発生しても、クライアントは、残りのインスタンスに接続することによって、引き続きデータベースにアクセスできます。
残りのインスタンスに再接続する作業を行う方法は多数あります。
Oracle インスタンスへの接続が失われた場合に、Oracle クライアントが代替インスタンスへの接続を再確立するようにアプリケーションを設計する。このことは、クライアントが複数インスタンス (OPS) 環境で動作していることを認識することを意味します。
ただし、こうした解決策はほとんど使用されません。ほとんどの実装では、Tuxedo トランザクションモニター (TM) などのミドルウェアを使用して、再接続ロジックを実現します。Oracle クライアントが TM に接続し、接続された TM が多数あるデータベースインスタンスの 1 つに接続します。TM は、代替インスタンスに再接続することによってクライアントから特定のインスタンスの障害を隠します。TM を使用することの利点は、OPS 環境で複数インスタンスを利用するために、既存の Oracle クライアントアプリケーションを書き直す必要がないことです。欠点は、TM との統合コストです。
Oracle インスタンスへの接続が失われた場合に、Oracle クライアントが同じサーバーへの接続を再度試みるようにアプリケーション (Oracle クライアント) を設計する。つまり、非並列環境用に設計された Oracle クライアントアプリケーションを再設計することなく OPS 環境に移すことができます。接続が残りのサーバーに向けられるように構成します。
このことを実現する方法の 1 つとして、OPS データサービスと Sun Cluster の IP フェイルオーバー機能を組み合わせる方法があります。この章の後半部分では、Oracle SQL*Net の高可用性機能を使用したより簡単な代替解決方法について説明します。この機能を実現するために、IP フェイルオーバー機能は必要ありません。
Oracle クライアントから見ると、モデルは単純です。サーバーがクラッシュしたとき、クライアントは接続が切断されたことを検出します。クライアントはサーバーに再接続し、トランザクションを再実行するように依頼します。Oracle SQL*Net には、同じサービスの下で複数のホストにまたがって動作する複数インスタンスを組み込む機能が用意されています。この機能により、再接続したとき、クライアントは自動的に残りのインスタンスを利用できます。この再接続は自動的ではありません。一般に、クライアントには、前回と同じサービスに再接続するコードを組み込みます。
ノードまたはインスタンス障害あると、残りのサーバーは障害が発生したインスタンスを最初に回復する必要があります。この回復中、クライアントは、インスタンスからの応答がないことを検出します。この回復処理は、Sun Cluster フレームワークとは何の関係もありません。この回復は、Oracle、トランザクションボリューム、OPS に対する回復機能に完全に依存します。
ここでは、TNSNAMES.ORA を使用して、クライアント上に Oracle SQL*Net を構成する 2 つの方法を示します。クライアントが生き残りインスタンスに接続する時間が、Oracle SQL*Net を構成するために使用する方法の影響を受けることはありません。
複数のインスタンスに同じ「接続文字列」を設定して、同じ ORACLE SID を使用し、異なるホスト上で動作するようにする方法を次に示します。
ora = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = erlan) (PORT = 1526) <- instance 1 ) (CONNECT_DATA= (SID=ora)) ) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = weibull) (PORT = 1526) <- instance 2 ) (CONNECT_DATA= (SID=ora)) ) ) |
複数のインスタンスに同じ「接続文字列」を設定して、異なる ORACLE SID を使用し、異なるホスト上で動作するようにする方法を次に示します。
ora = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = erlang) (PORT = 1526)) (CONNECT_DATA = (SID = ora)(GLOBAL_NAME = ora)) ) (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = weibull) (PORT = 1526)) (CONNECT_DATA = (SID = ora1)(GLOBAL_NAME = ora)) ) ) |
この構成では、インスタンスごとにリスナーが動作します。
Oracle7 Parallel Server をインストールする場合は、『Oracle7 for Sun SPARC Solaris 2.x Installation and Configuration Guide, Release 7.x』を参照してください。Oracle8 Parallel Server をインストールする場合は、『Oracle8 Parallel Server Concepts and Administration, Release 8.0』を参照してください。
Sun Cluster 構成に OPS をインストールするには、全ノード上で次の手順を実行します。
vi などのエディタを使用して、/etc/system ファイルを編集します。たとえば、次のようにします。
# vi /etc/system |
/etc/system ファイルから次のような行を探します。
set shmsys:shminfo_shmmax=10000000 |
Oracle のマニュアルにこの行の説明がある場合は、この後の手順 4 と 手順 5 を省略します。Oracle のマニュアルにこの行の説明がない場合は、この後の手順 4 と 手順 5 を行います。
Oracle7 または Oracle8 のマニュアルの説明は、常にこの節の情報よりも優先します。
上記の行の数字が 1000 万より小さい場合は、1000 万 (10000000) に変更します。1000 万以上の場合は、そのまま残します。
データベースのサイズによっては、OPS のインストールの一環として、後でこの数字の変更が必要になることがあります。
すべてのノードを再起動します。
Informix-Online XPS のインストールについては、『Installation Notes INFORMIX-OnLine XPS』を参照してください。Informix-Online XPS をサポートするための /etc/system ファイルに対する変更は、Informix のマニュアルに含まれている情報に基づいて行う必要があります。
Informix-Online XPS のマニュアルの説明は、常にこの節の情報よりも優先します。
Sun Cluster 構成では、次の手順で Informix-Online XPS をインストールします。
vi などのエディタを使用して、/etc/hosts ファイルを編集します。たとえば、次のようにします。
# vi /etc/hosts |
/etc/hosts ファイルに次のような行を追加します。
204.152.65.1 ssa28-scid0 204.152.65.17 ssa28-scid1 204.152.65.2 ssa28a-scid0 204.152.65.18 ssa28a-scid1 |
この例の 204.152.65.1 と 204.152.65.17 は、Sun Cluster システムによって主ノード上の SCI カードに割り当てられた IP アドレスです。204.152.65.2 と 204.152.65.18 は、二次ノード上の SCI カードに割り当てられた IP アドレスです。
ノード 1 の場合は、ssa28a-scid0 または ssa28a-scid1 を使用して、クラスタ内のノード 2 と通信できます。2 つの SCI があることにより、メッセージの伝達に使用する接続 (SCI 0 または 1) を選択できます。
Informix の onconfig 構成ファイルは、これらの名前を使用して 2 つのノード間の通信設定をします。
ネットワークセキュリティ - Informix では、インストール中にクラスタノードのプライベートインターコネクト IP アドレスが /etc/hosts ファイル内に存在する必要があります。クラスタのノードのいずれかを NIS または DNS ネームサーバーとして動作するように構成した場合は、ネームサーバーによって、そのプライベートアドレスが権限のないホストからも利用できるようになるため、セキュリティ上、問題になることがあります。クラスタに Informix をインストールした場合は、セキュリティの観点から、ノードを NIS や DNS ネームサーバーとして構成しないことを推奨します。