test

Sun Cluster 3.1 データサービスのインストールと構成

第 1 章 Sun Cluster データサービスの計画

この章では、Sun Cluster データサービスのインストールと構成を計画するにあたってのガイドラインを説明します。この章の内容は次のとおりです。

データサービス、リソースタイプ、リソースグループについての概念的な情報については、『Sun Cluster 3.1 の概念 』を参照してください。

Sun Cluster データサービスとして現在提供されていないアプリケーションについては、『Sun Cluster 3.1 データサービス開発ガイド』を参照してください。アプリケーションを高可用性データサービスとして構成する方法について説明されています。

Sun Cluster データサービスのインストールと構成作業

次の表に、Sun Cluster データサービスのインストールと構成について説明している章を示します。

表 1–1 作業マップ: Sun Cluster データサービスのインストールと構成

作業 

参照箇所 

Sun Cluster HA for Oracle のインストールと構成 

第 2 章「Sun Cluster HA for Oracle のインストールと構成」

Sun Cluster HA for Sun Open Net Environment (Sun ONE) Web Server のインストールと構成 

第 3 章「Sun Cluster HA for SunTM ONE Web Server のインストールと構成」

Sun Cluster HA for Sun ONE Directory Server のインストールと構成 

第 4 章「Sun Cluster HA for Sun ONE Directory Server のインストールと構成」

Sun Cluster HA for Apache のインストールと構成 

第 5 章「Sun Cluster HA for Apache のインストールと構成」

Sun Cluster HA for DNS のインストールと構成 

第 6 章「Sun Cluster HA for Domain Name Service (DNS) のインストールと構成」

Sun Cluster HA for NFS のインストールと構成 

第 7 章「Sun Cluster HA for Network File System (NFS) のインストールと構成」

Sun Cluster Support for Oracle Parallel Server/Real Application Clusters のインストールと構成 

第 8 章「Sun Cluster Support for Oracle Parallel Server/Real Application Clusters のインストールと構成」

Sun Cluster HA for SAP のインストールと構成 

第 9 章「Sun Cluster HA for SAP のインストールと構成」

Sun Cluster HA for Sybase ASE のインストールと構成 

第 10 章「Sun Cluster HA for Sybase ASE のインストールと構成」

Sun Cluster HA for BroadVision One-To-One Enterprise のインストールと構成 

第 11 章「Sun Cluster HA for BroadVision One-To-One Enterprise のインストールと構成」

Sun Cluster HA for NetBackup のインストールと構成 

第 12 章「 Sun Cluster HA for NetBackup のインストールと構成」

Sun Cluster HA for SAP liveCache のインストールと構成 

第 13 章「Sun Cluster HA for SAP liveCache のインストールと構成」

Sun Cluster HA for Siebel のインストールと構成 

第 14 章「Sun Cluster HA for Siebel のインストールと構成」

データサービスリソースの管理 

第 15 章「データサービスリソースの管理」

Sun Cluster データサービスの構成ガイドライン

この節では、Sun Cluster データサービスを構成するためのガイドラインを説明します。

データサービス固有の要件の識別

Solaris と Sun Cluster のインストールを開始する前に、すべてのデータサービスの要件を確認します。計画に不備があった場合、インストールエラーが発生し、Solaris や Sun Cluster ソフトウェアを完全にインストールし直す必要が生じる可能性もあります。

たとえば、Sun Cluster Support for Oracle Parallel Server/Real Application Clusters の Oracle Parallel Fail Safe/Real Application Clusters Guard オプションには、ユーザーがクラスタ内で使用するホスト名に関する特殊な要件があります。Sun Cluster HA for SAP にも特殊な要件があります。Sun Cluster ソフトウェアをインストールした後はホスト名を変更できないので、Sun Cluster ソフトウェアをインストールする前にこれらの条件を満たす必要があります。

アプリケーションバイナリの格納先の決定

アプリケーションソフトウェアおよびアプリケーション構成ファイルは、次のいずれかの場所にインストールできます。

nsswitch.conf ファイルの内容の確認

nsswitch.conf ファイルは、ネームサービスの検索用の構成ファイルです。このファイルは次の情報を指定します。

一部のデータサービスについては、「group」検索の対象をまず「files」に変更してください。これらのデータサービスは、nsswitch.confファイル内の「group」行を変更し、「files」エントリが最初にリストされるようにします。「group」行を変更するかどうかを判断するには、構成するデータサービスに関する章を参照してください。

Sun Cluster 環境の nsswitch.conf ファイルの構成方法については、『Sun Cluster 3.1 ソフトウェアのインストール』の計画に関する章を参照してください。　

クラスタファイルシステムの構成の計画

データサービスによっては、Sun Cluster の要件を満たす必要があります。特別な検討事項が必要かどうかを判断するには、そのデータサービスに関する章を参照してください。

リソースタイプ HAStoragePlus を使用すると、フェイルオーバー用に構成された Sun Cluster 環境で高可用性ローカルファイルシステムを使用できます。HAStoragePlusリソースタイプを設定する方法については、高可用性ローカルファイルシステムの有効化 を参照してください。

クラスタファイルシステムの作成については、『Sun Cluster 3.1 ソフトウェアのインストール』の計画に関する章を参照してください。

リソースグループとディスクデバイスグループの関係

Sun Cluster には、ディスクデバイスグループとリソースグループに関連した、ノードリストという概念を持っています。ノードリストには、ディスクデバイスグループまたはリソースグループの潜在マスターである主ノードが順にリストされています。ダウンしていたノードがクラスタに再結合し、そのノードがノードリストで現在の主ノードより前にきたときにどうなるかは、フェイルバックポリシーの設定によって異なります。フェイルバックが True に設定されていると、デバイスグループまたはリソースグループが現在の主ノードから、再結合したノードに切り替えられ、このノードが新しい主ノードになります。

フェイルオーバーリソースグループの高可用性を保証するには、そのグループのノードリストと関連するディスクデバイスグループのノードリストとを一致させます。スケーラブルリソースグループの場合、そのリソースグループのノードリストは必ずしもデバイスグループのノードリストと一致するとは限りません。これは、現段階では、デバイスグループのノードリストには 2 つのノードしか含むことができないためです。2 ノードを超えるクラスタの場合は、スケーラブルリソースグループのノードリストに、3 ノード以上を含むことができます。

たとえば、ノード phys-schost-1 と phys-schost-2 が含まれるノードリストを持つディスクデバイスグループ disk-group-1 があり、フェイルバックポリシーが Enabled に設定されているとします。さらに、 アプリケーションデータの保持に disk-group-1 を使用する resource-group-1 というフェイルオーバーリソースグループも持っているとします。このような場合は、resource-group-1 を設定するときに、リソースグループのノードリストに phys-schost-1 と phys-schost-2 も指定し、フェイルバックポリシーを True に設定します。

スケーラブルリソースグループの高可用性を保証するためには、そのスケーラブルサービスグループのノードリストをディスクデバイスグループのノードリストのスーパーセットにします。スーパーセットにすることで、ディスクに直接接続されるノードは、スケーラブルリソースグループを実行するノードになります。この利点は、データに接続されている少なくとも 1 つのクラスタノードがクラスタで起動されているときに、スケーラブルリソースグループがこれらと同じノード上で実行されても、スケーラブルサービスは利用できることです。

ディスクデバイスグループの設定については、『Sun Cluster 3.1 ソフトウェアのインストール』を参照してください。ディスクデバイスグループとリソースグループの関連性については、『Sun Cluster 3.1 の概念』を参照してください。

HAStorage および HAStoragePlus リソースタイプ

HAStorage および HAStoragePlus リソースタイプは、次のオプションの構成に使用されます。

さらに、 HAStoragePlus はマウント解除状態であると判明した任意の広域ファイルシステムもマウントできます。詳細については、クラスタファイルシステムの構成の計画を参照してください。

注 –

HAStorage または HAStoragePlus リソースがオンラインの間にデバイスグループが別のノードに切り替えられた場合、AffinityOn の設定は無視され、リソースグループはデバイスグループと共に別のノードに移行することはありません。一方、リソースグループが別のノードに切り替わった場合、AffinityOn が True に設定されていると、デバイスグループはリソースグループと一緒に新しいノードに移動します。

ディスクデバイスグループとリソースグループの関連性については、リソースグループとディスクデバイスグループ間での起動の同期を参照してください。詳細については、SUNW.HAStorage(5) および SUNW.HAStoragePlus(5) のマニュアルページを参照してください。

VxFS などのファイルシステムをローカルモードでマウントする方法については、高可用性ローカルファイルシステムの有効化を参照してください。詳細については、SUNW.HAStoragePlus(5) のマニュアルページを参照してください。

データサービスに HAStorage または HAStoragePlus が必要かどうかの判断

HAStorage または HAStoragePlusの選択

HAStorage または HAStoragePlus のどちらのリソースをデータサービスリソースグループに作成するかを決める場合には、次の事項を考慮します。

推奨事項

データサービスのインストールと構成を計画するときは、この節で説明する情報を使用してください。この節の情報は、任意のデータサービスのインストールと構成における決定が与える影響について検討するのに役立ちます。データサービスに固有の推奨事項については、『Sun Cluster 3.1 データサービスのインストールと構成』の該当するデータサービスについて説明されている章を参照してください。

ノードリストプロパティ

データサービスを構成するときに、次の 3 つのノードリストを指定できます。

  1. installed_nodes — リソースタイプのプロパティ。このプロパティには、リソースタイプがインストールされ、そこで実行が可能になるクラスタノード名の一覧が含まれます。

  2. nodelist — リソースグループのプロパティ。優先順位に基づいて、グループをオンラインにできるクラスタノード名の一覧が含まれます。これらのノードは、リソースグループの潜在的な主ノードまたはマスターノードになります。フェイルオーバーサービスについては、リソースグループノードリストを 1 つだけ設定します。スケーラブルサービスの場合は、2 つのリソースグループを設定するため、ノードリストも 2 つ必要になります。一方のリソースグループとノードリストには、共有アドレスをホストするノードが含まれます。このリソースグループとノードリストは、スケーラブルリソースが依存するフェイルオーバーリソースグループになります。もう一方のリソースグループとノードリストには、アプリケーションリソースをホストするノードの一覧が含まれます。アプリケーションリソースは、共有アドレスに依存します。共有アドレスを含むリソースグループ用のノードリストは、アプリケーションリソース用のノードリストのスーパーセットになる必要があるためです。

  3. auxnodelist — 共有アドレスリソースのプロパティ。このプロパティには、クラスタノードを識別する物理ノード ID の一覧が含まれます。このクラスタノードは共有アドレスをホストできますが、フェイルオーバー時に主ノードになることはありません。これらのノードは、リソースグループのノードリストで識別されるノードとは、相互に排他的な関係になります。このノードリストは、スケーラブルサービスにのみ適用されます。詳細は、scrgadm(1M) のマニュアルページを参照してください。

インストールと構成プロセスの概要

データサービスをインストールして構成するには、次の手順を使用します。

データサービスのインストールと構成を開始する前に、『Sun Cluster 3.1 ソフトウェアのインストール』を参照してください。このマニュアルには、データサービスソフトウェアパッケージのインストール方法、ネットワークリソースが使用する Internet Protocol Network Multipathing (IP Networking Multipathing) (NAFO) グループの構成方法についての説明があります。

注 –

SunPlex Manager を使用して、Sun Cluster HA for Oracle、Sun Cluster HA for Sun ONE Web Server、Sun Cluster HA for Sun ONE Directory Server、Sun Cluster HA for Apache、Sun Cluster HA for DNS、Sun Cluster HA for NFS の各データサービスのインストールと構成を行うことができます。詳細については、SunPlex Manager のオンラインヘルプを参照してください。

インストールと構成の作業の流れ

次の表に、Sun Cluster フェイルオーバーデータサービスのインストールおよび構成作業と、その手順が説明されている参照先を示します。

表 1–2 作業マップ: Sun Cluster データサービスのインストールと構成

作業 

参照箇所 

Solaris と Sun Cluster ソフトウェアのインストール  

『Sun Cluster 3.1 ソフトウェアのインストール』

IP Networking Multipathing グループの設定 

『Sun Cluster 3.1 ソフトウェアのインストール』

多重ホストディスクの設定 

『Sun Cluster 3.1 ソフトウェアのインストール』

リソースとリソースグループの計画 

『Sun Cluster 3.1 ご使用にあたって』

アプリケーションバイナリの格納先の決定と nsswitch.conf の構成

第 1 章「Sun Cluster データサービスの計画」

アプリケーションソフトウェアのインストールと構成 

データサービスに関する各章 

データサービスソフトウェアパッケージのインストール 

『Sun Cluster 3.1 ソフトウェアのインストール』、データサービスに関する各章

データサービスの登録と構成 

データサービスに関する各章 

例

この節では、高可用性フェイルオーバーデータサービスとして設定されている Oracle アプリケーション用に、リソースタイプ、リソース、リソースグループを設定する方法を紹介します。

この例とスケーラブルデータサービスの例では、ネットワークリソースを含むフェイルオーバーリソースグループが異なります。さらに、スケーラブルデータサービスには、アプリケーションリソースごとに別のリソースグループ (スケーラブルリソースグループ) が必要です。

Oracle アプリケーションには、サーバーとリスナーの 2 つのコンポーネントがあります。Sun Cluster HA for Oracle データサービスは、Sun が提供しているので、これらのコンポーネントは、すでに Sun Cluster リソースタイプにマップされています。これら両方のリソースタイプが、リソースとリソースグループに関連付けられます。

この例は、フェイルオーバーデータサービスの例なので、論理ホスト名ネットワークリソースを使用し、主ノードから二次ノードにフェイルオーバーする IP アドレスを使用します。フェイルオーバーリソースグループに論理ホスト名リソースを入れ、Oracle サーバーリソースとリスナーリソースを同じリソースグループに入れます。この順に入れることで、フェイルオーバーを行うすべてのリソースが 1 つのグループになります。

Sun Cluster HA for Oracle をクラスタ上で実行するには、次のオブジェクトを定義する必要があります。

データサービスリソースを管理するためのツール

この節では、インストールや構成の作業に使用するツールについて説明します。

SunPlex Manager のグラフィカルユーザーインタフェース (GUI)

SunPlex Manager は Web ベースのツールです。このツールでは、次の作業を行うことができます。

SunPlex Manager を使ってクラスタソフトウェアをインストールする手順については、『Sun Cluster 3.1 ソフトウェアのインストール』を参照してください。SunPlex Manager のオンラインヘルプには、ほとんどの管理作業の説明が載っています。

Sun Management Center GUI 向けの Sun Cluster モジュール

Sun Cluster モジュールを使用することにより、Sun Management Center GUI からクラスタの監視を行ったり、リソースおよびリソースグループに対して操作を実行することができます。Sun Cluster モジュールのインストール要件やインストール手順については、『Sun Cluster 3.1 ソフトウェアのインストール』を参照してください。Sun Management Center の詳細は、 http://docs.sun.com にある Sun Management Center のソフトウェアマニュアルを参照してください。

scsetup ユーティリティー

scsetup(1M) ユーティリティーは、Sun Cluster の一般的な管理に使用するメニュー方式のインタフェースです。このユーティリティーは、さらに、データサービスのリソースやリソースグループの構成にも使用できます。この場合には、scsetup のメインメニューからオプション 2 を選択して、「リソースグループマネージャ」というサブメニューを起動してください。

scrgadm コマンド

scrgadm コマンドにより、データサービスリソースの登録や構成を行うことができます。この手順については、このマニュアルの該当する各章に記載されているデータサービスの登録と構成の項を参照してください。たとえば Sun Cluster HA for Oracle を使用している場合は、Sun Cluster HA for Oracle の登録と構成を参照してください。第 15 章「データサービスリソースの管理」にも、scrgadm コマンドを使ってデータサービスリソースを管理する方法が記載されています。さらに、scrgadm(1M) のマニュアルページも参照してください。

データサービスリソースの管理作業

次の表に、データサービスリソースの管理作業に使用できるツール (コマンド行以外の) を示します。これらの作業の詳細や、関連する手順をコマンド行から行う方法については、第 15 章「データサービスリソースの管理」を参照してください。

表 1–3 データサービスリソースの管理作業に使用できるツール

作業 

SunPlex Manager 

Sun Management Center 

scsetup ユーティリティー

リソースタイプの登録 

可 

不可 

可 

リソースグループの作成 

可 

不可 

可 

リソースのリソースグループへの追加 

可 

不可 

可 

リソースグループのオンライン化 

可 

可 

不可 

リソースグループの削除 

可 

可 

不可 

リソースの削除 

可 

可 

不可 

リソースグループの現在の主ノードの切り替え 

可 

不可 

不可 

リソースの無効化 

可 

可 

不可 

無効なリソースのリソースグループを非管理状態に変更 

可 

不可 

不可 

リソースタイプ、リソースグループ、リソース構成情報の表示 

可 

可 

不可 

リソースプロパティの変更 

可 

不可 

不可 

リソースの STOP_FAILED エラーフラグの消去

可 

不可 

不可 

ノードのリソースグループへの追加 

可 

不可 

不可 

Sun Cluster データサービスの障害モニター

この節では、データサービス障害モニターの一般的な事項について説明します。Sun が提供するデータサービスには、パッケージに組み込まれている障害モニターがあります。障害モニター (または障害検証機能) は、データサービスの状態を検証するプロセスです。

障害モニターの呼び出し

障害モニターは、リソースグループとそのリソースをオンラインにしたときに、RGM によって呼び出されます。この呼び出しによって、RGM はそのデータサービスの MONITOR_START メソッドの呼び出しを内部で行います。

障害モニターは、次の 2 つの機能を実行します。

サーバープロセスの異常終了の監視

プロセスモニター (PMF : Process Monitor Facility) は、データサービスプロセスを監視します。

データサービスの障害検証は、無限ループで実行され、 Thorough_probe_interval リソースプロパティによって設定された調整可能な期間に休止状態 (スリープ) になります。休止している間に、検証機能は プロセスが終了したかどうかについて PMF により検査します。サーバープロセスが終了した場合は、その後、検証機能はデータサービスの状態を「Service daemon not running」で更新し、操作を実行します。実行する操作には、データサービスのローカルでの再起動、または二次クラスタノードへのデータサービスのフェイルオーバーなどが含まれます。検証機能は、そのデータサービスアプリケーションリソースの Retry_count および Retry_interval リソースプロパティで設定されている値を調べ、データサービスを再起動するか、またはフェイルオーバーするかを決定します。

データサービスの状態の検査

通常、検証機能とデータサービスとの間の通信は、専用のコマンドまたは指定したデータサービスポートとの正常な接続によって行われます。

検証機能は主に以下の操作を行います。

  1. 休止します (Thorough_probe_interval)。

  2. タイムアウトプロパティ Probe_timeout で状態検査を実行します。Probe_timeoutは、ユーザーが設定可能な各データサービスのリソース拡張プロパティです。

  3. 手順 2 を実行し、サービスの状態に異常がなければ、正常/異常の履歴を更新します。Retry_interval リソースプロパティに設定されている値よりも古い履歴を消去 (パージ) することで、正常/異常の履歴を更新します。検証機能は、リソースの状態メッセージを「Service is online」に設定し、手順 1 に戻ります。

    手順 2 の結果、サービスの状態に異常があれば、検証機能は異常履歴を更新します。その後、状態検査に失敗した総数を計算します。

    状態検査の結果は、致命的な異常から正常までの範囲があります。結果の判断は、個々のデータサービスに依存します。たとえば、検証機能が正常にサーバーに接続でき、ハンドシェイクメッセージをサーバーに送信できるにも関わらず、この検証機能がタイムアウト前に一部の応答しか受け取ることができない場合を考えてみます。このケースは、システムの過負荷の結果として、最も発生する可能性があります。サービスの再起動など、操作を何か実行すると、クライアントはそのサービスに接続するため、さらにシステムの負荷が増大します。このような場合に、データサービスの障害モニターは、この「一部」の異常を致命的なものとして扱わないようにします。代わりに、モニターは、この異常をサービスの致命的ではない検証として追跡します。これらの一部の異常は、Retry_interval プロパティによって指定された期間、累積されます。

    ただし、検証機能がまったくサーバーに接続できない場合は、致命的な異常であると認識されます。一部の異常が、断片的な量によって異常カウントの増加につながります。致命的な異常、または一部の異常の累積のいずれかによって、異常カウントが 合計カウントに到達するたびに、検証機能はデータサービスの再起動またはフェイルオーバーによってこの状況を修正しようとします。

  4. 手順 3 (履歴期間内での異常の数)での計算の結果、Retry_count リソースプロパティの値よりも少ない場合は、検証機能は、状況をローカルで修正しようとします (たとえば、サービスの再起動)。検証機能は、リソースの状態メッセージを「Service is degraded」に設定し、手順 1 に戻ります。

  5. Retry_interval で指定した期間内で発生した異常の数が Retry_count の値を超える場合、検証機能は、scha_control を「giveover」オプション付きで呼び出します。このオプションは、サービスのフェイルオーバーを要求します。この要求によって異常が修正されると、このノードでの障害モニターが停止されます。検証機能は、リソースの状態メッセージを「Service has failed」に設定します。

  6. さまざまな理由により、前の手順で発行された scha_control 要求が Sun Cluster フレームワークによって拒否されることがあります。この理由は、scha_control のリターンコードで識別できます。検証機能は、リターンコードを調べます。scha_control が拒否される場合、検証機能は異常/正常履歴をリセットし、新たに開始します。検証機能が履歴をリセットするのは、異常の数がすでに Retry_count を超えているため、障害モニターが各後続の繰り返しで scha_control を発行しようとするためです (ただし、再び拒否されます)。この要求は、システムの負荷をさらに高め、サービス障害がさらに生じる可能性が増大します。

    その後、検証機能は、手順 1 に戻ります。