test

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

ソフトウェア構成

Sun Cluster には、次のソフトウェアコンポーネントが含まれています。

これらのソフトウェアコンポーネントに関係する論理コンポーネントは、次のとおりです。

以下の節では、これらのコンポーネントについて説明します。

クラスタフレームワーク

図 1-17 は、Sun Cluster で HA データサービスをサポートするために必要なフレームワークを構成するさまざまなコンポーネントの適切な階層構造を表しています。ただし、この図には、Sun Cluster のさまざまなコンポーネント間の関係は示されていません。最も内側のコアは、現在のクラスタメンバーシップの記録を取るクラスタメンバーシップモニター(CMM) で構成されます。ノードがクラスタから切り離されるか、再結合するたびに、そのクラスタノード上の CMM は、分散メンバーシッププロトコルを経由して、新しいクラスタメンバーシップの合意を図ります。新しいメンバーシップが確定すると、CMM は、Sun Cluster フレームワークを使用して別のクラスタコンポーネントの再構成を調整します。

図 1-17 Sun Cluster のソフトウェアコンポーネント

Graphic

Sun Cluster 構成では、ハードウェアやソフトウェアに問題が発生した場合に、メンバーシップモニター、障害モニター、関係するプログラムによって、障害が発生した Cluster サーバーから別の Cluster サーバーに、すべてのデータサービス処理を引き継ぐことを可能にします。これは、障害の発生した Cluster サーバーに関連付けられている論理ホストをマスターする権利を、クラスタサーバーに引き継ぐことによって実現されます。一部の種類の障害では、フェイルオーバーは発生しません。一般に、ディスクドライブ障害では、フェイルオーバーは行われず、ミラー化によって対処されます。同様に、障害モニターによってソフトウェア障害が検出された場合は、別のノードへのフェイルオーバーは行われずに、同じ物理ノード上でデータサービスが再開されます。

障害モニター層

障害モニター層は、障害デーモン 1 つと、データサービスのさまざまな部分を検証するためのプログラムで構成されます。サービスの障害を検出した場合、障害モニターは、データサービスがどのように構成されているかによって、同じノード上でのサービスの再開または論理ホストのフェイルオーバーを試みることができます。

いくつかの環境では、サービスの中断があっても、データサービス障害モニターは、フェイルオーバーを開始しません。これに対する例外は、次の場合です。

データサービス層

Sun Cluster には、サンによって高可用性が実現された一群のデータサービスが付属しています。Sun Cluster は、データサービス層で障害モニターを提供します。この障害モニターが提供する障害検出レベルは、個々のデータサービスによって異なります。障害検出レベルは、いくつかの要因に依存します。Sun Cluster データサービスに対する障害モニターの働きについての詳細は、『Sun Cluster 2.2 のシステム管理』を参照してください。

サーバーを検証するときに、障害モニターは local7 メッセージ機能を利用します。この機能が生成するメッセージは、サーバー上のメッセージの設定に従って、メッセージファイルに記録するか、コンソールに表示できます。メッセージの設定についての詳細は、syslog.conf(4) のマニュアルページを参照してください。

Sun Cluster がサポートするデータサービス

Sun Cluster は、リレーショナルデータベースや並列データベース、インターネットサービス、資源管理データサービスなどのいろいろなアプリケーションに HA サポートを提供します。今回の Sun Cluster のリリースでは、次のデータサービスがサポートされています (データサービスとサポートされているバージョンの最新の情報については、『Sun Cluster 2.2 ご使用にあたって』を参照するか、ご購入先にお問い合わせください)。

データサービス API

Sun Cluster ソフトウェアには、Sun Cluster HA フレームワーク下で、既存のデータサービスを高可用性にすることを可能にするアプリケーションプログラミングインタフェース (API) が付属しています。データサービスは、クラスタの再構成のいくつかの重要なポイントで HA フレームワークによってコールバックされるメソッド (プログラム) を登録します。Sun Cluster には、データサービスのメソッドが Sun Cluster 構成の状態を照会したり、テイクオーバーを開始したりすることを可能にするユーティリティも付属しています。そのほか、データサービスのメソッドによるファイルロック保持中のプログラムの実行や、タイムアウト値を設定したプログラムの実行、プログラムが終了した場合の自動再起動を簡単に行えるようにするユーティリティもあります。

データサービス API についての詳細は、『Sun Cluster 2.2 API 開発ガイド』を参照してください。

スイッチ管理エージェント

スイッチ管理エージェント (SMA) ソフトウェアコンポーネントは、SCI リンクおよびスイッチに対するセッションを管理します。同様に、Ethernet リンクおよびスイッチ上のセッションも管理します。また、SMA は個別リンク障害からアプリケーションを切り離し、すべてのアプリケーションに対して論理リンクの概念を提供します。

クラスタ SNMP エージェント

Sun Cluster には、クラスタ用に MIB (Management Information Base) とともに SNMP (Simple Network Management Protocol) エージェントが付属します。このエージェントファイルの名前は snmpd (SNMP デーモン)、MIB の名前は sun.mib です。

Sun Cluster の SNMP エージェントは、同時に複数のクラスタ (最高 32 個) を監視できます。通常の Sun Cluster 構成では、クラスタは、管理ワークステーションまたはシステムサービスプロセッサ (Sun Enterprise 10000 の場合) から管理できます。クラスタは、管理ワークステーション (またはシステムサービスプロセッサ) に Sun Cluster の SNMP エージェントをインストールすることによって、SNMP パケットの送信時に、ネットワークトラフィックが規制され、ノードの CPU パワーが浪費されなくなります。

クラスタ構成データベース

クラスタ構成データベース (CCD) は、Sun Cluster 構成に合わせて内部構成情報を格納するための、可用性の高い複製データベースです。CCD は、Sun Cluster が内部で利用するデータベースです。パブリックインタフェースではないため、直接、CCD を更新しないでください。

CCD は、クラスタメンバーシップモニター (CMM) サービスに基づいて、現在のクラスタメンバーシップと、整合性ドメイン、すなわち、整合性のとられたデータベースコピーを保持して、更新を伝達するノード群を特定します。CCD データベースは、初期データベースと動的データベースの 2 つに分かれます。

初期 CCD データベースの目的は、scinstall による CCD パッケージのインストール中に値が設定される、変更不可能な起動寺構成パラメータを格納することにあります。動的 CCD には、残りのデータベースエントリが含まれます。初期 CCD と異なり、動的 CCD 内のエントリは、CCD データベースが回復されていること (すなわち、クラスタが動作していること)、そして CCD が定足数を得ていることという制限付きで、いつでも更新できます (定足数の定義については、「CCD の動作」を参照)。

初期 CCD (/etc/opt/SUNWcluster/conf/ccd.database.init) はまた、CCD が動作する前に起動されるコンポーネントに関する情報の格納にも使用されます。このことは、CCD データベースが回復し、広域的な整合性が検査される前に初期 CCD への照会を行えることを意味します。

動的 CCD (/etc/opt/SUNWcluster/conf/ccd.database) には、そのほかのデータベースエントリが含まれます。CCD は、その整合性ドメインの全ノードにまたがって動的 CCD の整合性のとられた複製が作成されるようにします。

ノード障害が発生したときでも確実に利用できるよう、CCD データベースは、すべてのノード上に複製が作成されます。CCD デーモンは互いの間で通信を確立して、CCD 整合性ドメイン内でのデータベース処理の同期と直列化を図ります。データベースの更新および照会要求は、どのノードからでも発行できます。CCD には、シングルポイント制御はありません。

また、CCD は以下を提供します。

CCD の動作

CCD は、選出された整合性ドメインの全ノードで整合性のとれたデータベースの複製が存在するようにします。有効な CCD のコピーが検出されたノードだけが、クラスタへの結合を許可されます。整合性の検査は、局所的と広域的の 2 つのレベルで行われます。局所的には、それぞれのデータベースコピーは、データベースの検査合計と長さを保持した整合性レコードを内蔵しています。この整合性レコードは、データベースの更新または回復が行われたときのローカルのデータベースコピーの妥当性を検査します。整合性レコードは、データベースの最終更新日時を記録します。

CCD はまた、広域的な整合性検査を行なって、すべてのノードに存在するデータベースのコピーが同じであることを確認します。CCD デーモンは整合性レコードを交換して、その妥当性の検査をします。クラスタの再起動中、データベースの回復には定足数投票方式が使用されます。回復プロセスによって、CCD の有効なコピーが存在するノード数 (整合性レコードを使用して、局所的な整合性が検査される) と、同一内容 (検査合計と長さが同じ) のコピー数が求められます。

過半数のノードが動作しているときに、CCD コピーを最新にするには、デフォルトの整合性ドメイン内に定足数の過半数が検出される必要があります。

注 -

CCD を更新するには、定足数の過半数が必要です。

式 Q= [Na/2]+1 は、CCD を更新するために必要なノード数を規定します。Na は、クラスタ内に物理的に存在するノード数です。ノードは物理的に存在しますが、クラスタソフトウェアを実行していないこともあります。

VERITAS Volume Manager を使用した 2 ノードのクラスタの場合、定足数は、共有 CCD ボリュームを使用し、ノード数が 1 つだけ上回ることによって維持されることがあります。共有 CCD 構成では、CCD のコピーが各ノードのローカルディスクに保持され、別のコピーが、ノード間で共有可能な特殊なディスクグループに保持されます。通常の運用では、ローカルディスク上のコピーだけが利用されますが、ノードの 1 つで問題が発生した場合は、共有 CCD が使用されて、クラスタ内にノード 1 つだけで CCD 定足数が維持されます。障害ノードがクラスタに再結合した場合、そのノードは、共有 CCD の現在のコピーを使用して更新されます。2 ノードのクラスタにおける共有 CCD ボリュームの設定についての詳細は、第 3 章「Sun Cluster ソフトウェアのインストールと構成」を参照してください。

ノードの 1 つが動作し続けている場合は、そのノードの有効な CCD を新たに結合するノードに伝達できます。CCD 回復アルゴリズムは、有効なコピーが検出され、すべてのノード上に正しくその複製が作成されている場合にだけ CCD データベースが動作するようにします。回復に失敗した場合は、ユーザーが介入して、どの CCD コピーが有効であるかを決定する必要があります。こうして選出されたコピーを使用して、データベースを復元できます。このデータベースの復元には、ccdadm -r コマンドを使用します。CCD を管理する手順については、『Sun Cluster 2.2 のシステム管理』を参照してください。

注 -

CCD には、データベースの現在の内容を記憶するバックアップ機能 (ccdadm(1M) を使用) があります。データベースの現在の内容を記憶することにより、バックアップコピーを使用して、データベースを復元することができます。詳細は、ccdadm(1M) のマニュアルページを参照してください。

ボリュームマネージャ

Sun Cluster は、Solstice DiskSuite および VERITAS Volume Manager (VxVM) のボリュームマネージャをサポートしています。これらのボリュームマネージャは、Sun Cluster にミラー化、連結、ストライプ化機能を提供します。 ボリュームマネージャは、複数のディスクを、1 つの単位として管理できるディスクグループ (VxVM) またはディスクセット (Solstice DiskSuite) に編成します。

Sun StorEdge A3000 ディスク拡張装置には、Sun StorEdge A3000 ハードウェア内のディスクすべてをミラー化、結合、ストライプ化する機能もあります。詳細は、Sun StorEdge A3x00 のマニュアルを参照してください。

Solstice DiskSuite と VERITAS Volume Manager を同時に使用できるのは、Solstice DiskSuite でローカルディスクを管理し、VERITAS Volume Manager で多重ホストディスクを制御する場合に限ります。このような構成では、物理ディスクの必要量を構成に応じて増加する必要があります。たとえば、VERITAS Volume Manager の場合、ルートディスクグループ用に追加のディスクが必要になることがあります。詳細は、ボリュームマネージャのマニュアルを参照してください。

ボリュームマネージャについての詳細は、使用しているボリュームマネージャのマニュアルおよび 「ボリューム管理」 を参照してください。

ディスクグループおよびディスクセット

ディスクグループ (VxVM の用語) やディスクセット (Solstice DiskSuite の用語) は、ボリュームマネージャの制御下にある一連のディスクを意味する用語です。ボリュームマネージャでは、RAID-0、RAID-1、または RAID-5 構成の共用ディスクがサポートされます。あらゆるデータサービスおよび並列データベースデータは、共有ディスク上のディスクグループまたはディスクセットに格納されます。一般に、ディスクグループ内のミラーは、物理的にミラーの半分がそれぞれ異なるディスク拡張装置内に置かれ、異なるコントローラまたはホストアダプタに接続されるように編成されます。こうすることによって、1 つのディスクまたはディスク拡張装置の障害をシングルポイント障害として排除します。

ディスクグループまたはディスクセットは、raw データ記憶装置かファイルシステム、またはその両方に使用できます。

論理ホスト

Sun Cluster の論理ホストは、1 つの単位として Sun Cluster サーバー間を移動可能な資源の集まりです。Sun Cluster では、資源は、ネットワークホスト名とそのホストに関連付けられた IP アドレスのコレクションに 1 つ以上のディスクグループを加えたものです。OPS 構成などの HA 以外のクラスタ環境では、IP アドレスは特定のホストシステムに固定的に対応付けられます。クライアントアプリケーションは、サーバーアプリケーションを実行するホストの IP アドレスを指定することによって、サーバー上のデータにアクセスします。

Sun Cluster では、IP アドレスは論理ホストに割り当てられ、どのようなホストシステムでも、アプリケーションサーバーが現在動作しているホストシステムに一時的に関連付けられます。こうした IP アドレスは再配置可能なため、ノード間を移動できます。Sun Cluster 環境では、クライアントは、物理ホストシステムの IP アドレスではなく、論理ホストの再配置可能 IP アドレスを指定して、アプリケーションに接続します。

次の図 1-18 の論理ホスト hahost1 は、ネットワークホスト名 hahost1、再配置可能 IP アドレス 192.9.200.1、ディスクグループ diskgroup1 と定義されます。論理ホスト名とディスクグループ名が同じである必要はないことに注意してください。

図 1-18 論理ホスト

Graphic

論理ホストは、パブリックネットワークごとに 1 つの論理ホスト名と 1 つの再配置可能 IP アドレスを持ちます。主論理ホスト名は、主パブリックネットワーク上で論理ホストが認識される名前です。二次論理ホスト名は、二次パブリックネットワーク上で論理ホストが認識される名前です。図 1-19 は、hahost1 と hahost2 という主論理ホスト名を持つ 2 つの論理ホストのホスト名と再配置可能 IP アドレスを表しています。この図の二次論理ホスト名の接尾辞には、ネットワーク番号の最後の要素 (201) が使用されています。たとえば、hahost1-201 は、論理ホスト hahost1 の二次論理ホスト名です。

図 1-19 複数のパブリックネットワーク上の論理ホスト

Graphic

論理ホストは、物理ホストによってマスターされます。論理ホストを現在マスターしている物理ホストだけが、その論理ホストのディスクグループにアクセスできます。物理ホストは複数の論理ホストをマスターできますが、各論理ホストは、一度に 1 つの物理ホストだけしかマスターできません。特定の論理ホストをマスターする能力をもつ物理ホストを、その論理ホストの潜在的マスターといいます。

データサービスは、物理ホストに関連付けられている既知の論理ホスト名を知らせることによって、ネットワーク上のクライアントがそのサービスを利用できるようにします。論理ホスト名はサイトの IP 名前空間の一部ですが、特定の物理ホスト名が割り当てられているわけではありません。クライアントは論理ホスト名を使用して、データサービスが提供するサービスを利用します。

図 1-20 は、複数のデータサービスが 1 つの論理ホストのディスクグループに置かれている構成を表しています。この例では、論理ホスト hahost2 が現在 phys-hahost2 によってマスターされていると仮定します。この構成で phys-hahost2 に問題が発生すると、両方の Sun Cluster HA for Netscape データサービス (dg2-http と dg2-news) が phys-hahost1 にフェイルオーバーされます。

図 1-20 論理ホストとデータサービスとデータサービスファイル

Graphic

論理ホスト上にデータサービスを構成する方法を決定するにあたっての考慮事項については、第 2 章「構成の計画」を参照してください。

パブリックネットワーク管理 (PNM)

発生した障害の種類によっては、障害の発生したノード上に置かれていたすべての論理ホストが別のノードに転送されます。ノードとパブリックネットワーク間のネットワークアダプタカード、コネクタ、ケーブルの障害では、結果的にノードのフェイルオーバーは必要ありません。Sun Cluster フレームワークのパブリックネットワーク管理 (PNM) ソフトウェアは、ネットワークアダプタの 1 つで問題が発生した場合に、同じグループの別のアダプタがネットワーク要求の処理サービスを引き継げるようネットワークアダプタをグループに編成することを可能にします。エラー検出とフェイルオーバー機能が動作している間の遅延はごくわずかなものです。

PNM を使用した構成では、同じサブネット上に複数のネットワークインタフェースが存在します。これらインタフェースによって、バックアップグループが構成されます。常に、1 つのネットワークアダプタは 1 つのバックアップグループにだけ所属でき、バックアップグループ内の 1 つのアダプタだけがアクティブになります。アクティブなアダプタで問題が発生すると、PNM ソフトウェアは、同じバックアップグループ内の別のアダプタを使用するようにネットワークサービスを切り替えます。パブリックネットワーク用に使用するすべてのアダプタは、1 つのバックアップグループにまとめてください。

注 -

バックアップグループはまた、同一ノードのフェイルオーバーアダプタが存在しないときでもパブリックネットの監視に使用されます。

図 1-21 ネットワークアダプタのフェイルオーバー構成

Graphic

PNM の構成と管理については、『Sun Cluster 2.2 のシステム管理』を参照してください。

システムフェイルオーバーとスイッチオーバー

Sun Cluster HA 構成でノードに問題が発生すると、そのノード上で動作していたデータサービスは、同じサーバーセット内の正常なノードに自動的に移動されます。フェイルオーバーソフトウェアは、論理ホストの IP アドレスを障害ホストから正常なノードに移動します。障害ホストによってマスターされていた論理ホスト上で動作していたすべてのデータサービスも移動されます。

システム管理者は、手動で論理ホストのスイッチオーバーを行うことができます。フェイルオーバーとスイッチオーバーの違いは、前者が、ノードに問題が発生したとき Sun Cluster ソフトウェアによって自動的に処理されるのに対し、後者はシステム管理者が手動で行うという点です。スイッチオーバーは、クラスタノードの定期的な保守またはソフトウェアのアップグレードを行うときに行います。

図 1-22 は、正常に稼働している 2 ノードの構成を表しています。それぞれの物理ホストが 1 つの論理ホストをマスターしていることに注意してください (実線で示しています)。2 つのクライアントが、この 2 つの論理ホスト上の異なるデータサービスを利用しています。

図 1-22 フェイルオーバーまたはスイッチオーバー前の対称構成

Graphic

phys-hahost1 で問題が発生した場合、論理ホスト hahost1 は、phys-hahost2 に移動されます。hahost1 の再配置可能 IP アドレスは phys-hahost2 に移動し、データサービス要求は phys-hahost2 に送信されます。クラスタの再構成が行われている間、hahost1 上のデータを利用するクライアントでは短時間の遅延が発生します。図 1-23 は、上図の、フェイルオーバーまたはスイッチオーバー後の新しい構成です。

(物理ホスト phys-hahost2 になった) phys-hahost1 上の論理ホスト hahost1 にアクセスしていたクライアントシステムが、引き続き物理ホスト phys-hahost2 上の同じ論理ホストにアクセスすることに注意してください。フェイルオーバーの場合、この引き継ぎは、クラスタの再構成によって自動的に行われます。フェイルオーバーの結果、phys-hahost2 は、hahost1 と hahost2 の両方の論理ホストをマスターするようになっています。関連付けられているディスクセットは、phys-hahost2 経由でのみアクセスできます。

図 1-23 フェイルオーバーまたはスイッチオーバー後の対称構成

Graphic

部分的フェイルオーバー

1 つの物理ホストが複数の論理ホストをマスターできるということは、データサービスの部分的フェイルオーバーが可能であるということです。図 1-24 は、物理ホスト 3 つと論理ホスト 5 つの星型構成を表しています。この図では、物理ホストと論理ホストを結ぶ線によって、どの物理ホストがどの論理ホスト (およびディスクグループ) を現在マスターしているかを示しています。

phys-hahost1 によってマスターされている 4 つの論理ホスト (実線で示されています) は、個別にホットスタンバイサーバーにフェイルオーバーできます。図 1-24 のホストスタンバイサーバーは、全多重ホストディスクに物理接続されていますが、どの論理ホストもマスターしていないことに注意してください。

図 1-24 複数論理ホスト構成の部分的フェイルオーバー以前

Graphic

図 1-25 は、hahost5 だけがホットスタンバイサーバーにフェイルオーバー (部分的フェイルオーバー) した後の構成を表しています。

部分的フェイルオーバーでは、phys-hahost1 が論理ホスト hahost5 をマスターする権利を放棄し、phys-hahost3 (ホットスタンバイサーバー) がその権利を引き継ぎます。

図 1-25 複数論理ホスト構成の部分的フェイルオーバー後

Graphic

同じ論理ホスト上にデータサービスを配置することによって、どのデータサービスを一緒にフェイルオーバーさせるかを制御できます。論理ホスト上のデータサービスの結合または分離に関係する問題については、第 2 章「構成の計画」を参照してください。

並列データベースに対するフェイルオーバー

並列データベース環境には、論理ホストの概念はありません。しかし、ノードで障害が発生した場合にノード間を移動できる再配置可能 IP アドレスの概念はあります。再配置可能 IP アドレスとフェイルオーバーについては 「論理ホスト」および 「システムフェイルオーバーとスイッチオーバー」を参照してください。