test

Sun Cluster の概念 (Solaris OS 版)

第 3 章 重要な概念 - システム管理者とアプリケーション開発者

この章では、Sun Cluster 環境のソフトウェアコンポーネントに関する重要な概念について説明します。この章の情報は、主に Sun Cluster API および SDK を使用するシステム管理者およびアプリケーション開発者向けです。クラスタの管理者にとっては、この情報は、クラスタソフトウェアのインストール、構成、管理についての予備知識となります。アプリケーション開発者は、この情報を使用して、作業を行うクラスタ環境を理解できます。

この章で説明する内容は次のとおりです。

管理インタフェース

複数のユーザーインタフェースから Sun Cluster ソフトウェアをインストール、構成、および管理する方法を選択できます。Sun Cluster Manager (旧 SunPlexTM Manager) のグラフィカルユーザーインタフェース (GUI) またはコマンドラインインタフェースのいずれかによって、システム管理作業を実行できます。コマンド行インタフェースでは、特定のインストール作業や構成作業を容易にする scinstall や clsetup などのユーティリティーが使用できます。Sun Cluster ソフトウェアには、Sun Management Center の一部として実行される、特定のクラスタ作業に GUI を提供するモジュールもあります。このモジュールを使用できるのは、SPARC ベースのクラスタに限られます。管理インタフェースの詳細については、『Sun Cluster のシステム管理 (Solaris OS 版)』の「管理ツール」を参照してください。

クラスタ内の時間

クラスタ内のすべてのノード間の時刻は同期をとる必要があります。クラスタノードの時刻と外部の時刻ソースの同期をとるかどうかは、クラスタの操作にとって重要ではありません。Sun Cluster ソフトウェアは、Network Time Protocol (NTP) を使用し、ノード間のクロックの同期をとっています。

通常、システムクロックが数分の 1 秒程度変更されても問題は起こりません。しかし、システムクロックと時刻の起点の同期をとるために、date、rdate、xntpdate を (対話形式または cron スクリプト内で) アクティブクラスタに対して実行すると、これよりも大幅な時刻変更を強制的に行うことが可能です。ただしこの強制的な変更を行った場合、ファイル修正時刻の表示に問題が生じたり、NTP サービスに混乱が生じる可能性があります。

Solaris オペレーティングシステムを各クラスタノードにインストールする場合は、ノードのデフォルトの時刻と日付の設定を変更できます。通常は、工場出荷時のデフォルト値を使用します。

scinstall コマンドを使用して Sun Cluster ソフトウェアをインストールする場合は、インストールプロセスの手順の 1 つとして、クラスタの NTP を構成します。Sun Cluster ソフトウェアは、ntp.cluster というテンプレートファイルを提供しています (インストールされたクラスタノードの /etc/inet/ntp.cluster を参照)。このテンプレートは、すべてのクラスタノード間で対等関係を確立します。1 つのノードは「優先ノード」になります。ノードはプライベートホスト名で識別され、時刻の同期化がクラスタインターコネクト全体で行われます。NTP 用のクラスタの構成方法については、『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』の第 2 章「クラスタへのソフトウェアのインストール」を参照してください。

また、クラスタの外部に 1 つまたは複数の NTP サーバーを設定し、ntp.conf ファイルを変更してその構成を反映させることもできます。

通常の操作では、クラスタの時刻を調整する必要はありません。ただし、Solaris オペレーティングシステムをインストールしたときに設定された誤った時刻を変更する場合の手順については、『Sun Cluster のシステム管理 (Solaris OS 版)』の第 8 章「クラスタの管理」を参照してください。

高可用性フレームワーク

Sun Cluster ソフトウェアでは、ユーザーとデータ間の「パス」にあるすべてのコンポーネント、つまり、ネットワークインタフェース、アプリケーション自体、ファイルシステム、および多重ホストデバイスを高可用性にします。一般に、システムで単一 (ソフトウェアまたはハードウェア) の障害が発生してもあるクラスタコンポーネントが稼働し続けられる場合、そのコンポーネントは高可用性であると考えられます。

次の表は Sun Cluster コンポーネント障害の種類 (ハードウェアとソフトウェアの両方) と高可用性フレームワークに組み込まれた回復の種類を示しています。

表 3–1 Sun Cluster の障害の検出と回復のレベル

障害が発生したクラスタリソース 

ソフトウェアの回復 

ハードウェアの回復 

データサービス 

HA API、HA フレームワーク 

適用不可 

パブリックネットワークアダプタ 

IP ネットワークマルチパス 

複数のパブリックネットワークアダプタカード 

クラスタファイルシステム 

一次複製と二次複製 

多重ホストデバイス 

ミラー化された多重ホストデバイス 

ボリューム管理 (Solaris ボリュームマネージャー および VERITAS Volume Manager) 

ハードウェア RAID-5 (Sun StorEdgeTM A3x00 など)

広域デバイス 

一次複製と二次複製 

デバイス、クラスタトランスポート接続点への多重パス 

プライベートネットワーク 

HA トランスポートソフトウェア 

ハードウェアから独立した多重プライベートネットワーク 

ノード 

CMM、フェイルファーストドライバ 

複数ノード 

ゾーン 

HA API、HA フレームワーク 

適用不可 

Sun Cluster ソフトウェアの高可用性フレームワークは、ノードまたはゾーンの障害をすばやく検出して、クラスタ内の残りのノードまたはゾーンにあるフレームワークリソース用に新しい同等のサーバーを作成します。どの時点でもすべてのフレームワークリソースが使用できなくなることはありません。障害が発生したノードまたはゾーンの影響を受けないフレームワークリソースは、回復中も完全に使用できます。さらに、障害が発生したノードまたはゾーンのフレームワークリソースは、回復されると同時に使用可能になります。回復されたフレームワークリソースは、他のすべてのフレームワークリソースが回復するまで待機する必要はありません。

最も可用性の高いフレームワークリソースは、そのリソースを使用するアプリケーション (データサービス) に対して透過的に回復されます。フレームワークリソースのアクセス方式は、ノードまたはゾーンの障害時にも完全に維持されます。アプリケーションは、フレームワークリソースサーバーが別のノードに移動したことを認識できないだけです。1 つのノードで障害が発生しても、残りのノード上にあるプログラムがそのノードに接続されているファイル、デバイス、およびディスクボリュームを使用できるので、その障害は完全に透過的と言えます。別のノードからそのディスクに代替ハードウェアパスが設定されている場合に、このような透過性が実現されます。この例としては、複数ノードへのポートを持つ多重ホストデバイスの使用があります。

ゾーンメンバーシップ

また、Sun Cluster ソフトウェアはゾーンがいつ起動または停止するかを検出することによって、ゾーンメンバーシップを追跡します。こうした変化も再構成の原因となります。再構成によって、クラスタ内のノードおよびゾーン間にクラスタリソースを再配置できます。

クラスタメンバーシップモニター

データが破壊から保護されるように保証するには、すべてのノードが、クラスタメンバーシップに対して一定の同意に達していなければなりません。必要であれば、CMM は、障害に応じてクラスタサービス (アプリケーション) のクラスタ再構成を調整します。

CMM は、クラスタのトランスポート層から、他のノードへの接続に関する情報を受け取ります。CMM は、クラスタインターコネクトを使用して、再構成中に状態情報を交換します。

CMM は、クラスタメンバーシップの変更を検出すると、それに合わせてクラスタを構成します。このような同期構成では、クラスタの新しいメンバーシップに基づいて、クラスタリソースが再配布されることがあります。

クラスタ自身が複数の異なるクラスタに分割されないようにする方法についての詳細は、「障害による影響の防止について」を参照してください。

フェイルファースト機構

「フェイルファースト」機構では、ノードの大域ゾーンまたは非大域ゾーンのいずれかにおける重大な問題が検出されます。フェイルファーストで問題が検出されたときに、Sun Cluster が取る措置は、問題が大域ゾーンで発生するか非大域ゾーンで発生するかによって異なります。

重大な問題が大域ゾーンで発生した場合、Sun Cluster は強制的にノードを停止させます。Sun Cluster は次にノードをクラスタメンバーシップから削除します。

重大な問題が非大域ゾーンで発生した場合、Sun Cluster は非大域ゾーンを再起動します。

ノードは、他のノードとの接続を失うと、通信が可能なノードとクラスタを形成しようとします。そのセットのノードが定足数に達しない場合、Sun Cluster ソフトウェアはノードを停止して、共有ストレージからノードをフェンス、つまり遮ります。この種類のフェイルファーストについての詳細は、「障害による影響の防止について」を参照してください。

1 つまたは複数のデーモンが停止すると、Sun Cluster ソフトウェアは重大な問題が発生したことを宣言します。Sun Cluster ソフトウェアは、大域ゾーンと非大域ゾーンの両方でクラスタ固有のデーモンを実行します。重大な問題が発生すると、Sun Cluster はノードを停止して削除するか、問題が発生した非大域ゾーンを再起動します。

非大域ゾーンで実行されるクラスタ固有のデーモンが失敗すると、次のようなメッセージがコンソールに表示されます。


cl_runtime: NOTICE: Failfast: Aborting because "pmfd" died in zone "zone4" (zone id 3)
35 seconds ago.

大域ゾーンで実行されるクラスタ固有のデーモンが失敗し、ノードでパニックが発生すると、次のようなメッセージがコンソールに表示されます。


panic[cpu1]/thread=2a10007fcc0: Failfast: Aborting because "pmfd" died in zone "global" (zone id 0)
35 seconds ago.
409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0)
%l0-7: 1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0

パニック後、このノードは再起動して、クラスタに再び参加しようとします。あるいは、SPARC ベースのシステムで構成されているクラスタの場合、そのノードは OpenBootTM PROM (OBP) プロンプトのままになることがあります。ノードがどちらのアクションをとるかは、auto-boot? パラメータの設定によって決定されます。OpenBoot PROM の ok プロンプトで、eeprom コマンドにより auto-boot? を設定できます。詳細は、eeprom(1M) のマニュアルページを参照してください。

クラスタ構成レポジトリ (CCR)

CCR は、更新に 2 フェーズのコミットアルゴリズムを使用します。更新はすべてのクラスタメンバーで正常に終了する必要があり、そうしないと、その更新はロールバックされます。CCR はクラスタインターコネクトを使用して、分散更新を適用します。

注意 – 注意 –

CCR はテキストファイルで構成されていますが、CCR ファイルは絶対に自分では編集しないでください。各ファイルには、ノード間の一貫性を保証するための検査合計レコードが含まれています。CCR ファイルを自分で更新すると、ノードまたはクラスタ全体の機能が停止する可能性があります。

CCR は、CMM に依存して、定足数 (quorum) が確立された場合にのみクラスタが実行されるように保証します。CCR は、クラスタ全体のデータの一貫性を確認し、必要に応じて回復を実行し、データへの更新を容易にします。

広域デバイス

Sun Cluster ソフトウェアは、「広域デバイス」を使用して、デバイスが物理的に接続されている場所に関係なく、任意のノードからクラスタ内のすべてのデバイスに対して、クラスタ全体の可用性の高いアクセスを可能にします。通常、広域デバイスへのアクセスを提供中のノードにエラーが発生すると、Sun Cluster ソフトウェアは自動的にこのデバイスへの別のパスを見つけます。Sun Cluster ソフトウェアは、アクセスをこのパスにリダイレクトさせます。Sun Cluster 広域デバイスには、ディスク、CD-ROM、テープが含まれます。しかし、Sun Cluster ソフトウェアがサポートする多重ポート広域デバイスはディスクだけです。つまり、CD-ROM とテープは現在、高可用性のデバイスではありません。各サーバーのローカルディスクも多重ポート化されていないため、可用性の高いデバイスではありません。

クラスタは自動的に、クラスタ内の各ディスク、CD-ROM、およびテープデバイスに一意の ID を割り当てます。この割り当てによって、クラスタ内の任意のノードから各デバイスに対して一貫したアクセスが可能になります。広域デバイス名前空間は、/dev/global ディレクトリにあります。詳細は、「広域名前空間」を参照してください。

多重ポート広域デバイスは、1 つのデバイスに対して複数のパスを提供します。多重ホストディスクは複数のノードがホストするデバイスグループの一部であるため、多重ホストディスクの可用性は高くなります。

デバイス ID と DID 疑似ドライバ

Sun Cluster ソフトウェアは、DID 疑似ドライバと呼ばれる構造によって広域デバイスを管理します。このドライバを使用して、多重ホストディスク、テープドライブ、CD-ROM を含め、クラスタ内のあらゆるデバイスに一意の ID を自動的に割り当てます。

DID 疑似ドライバは、クラスタの広域デバイスアクセス機能における重要な部分です。DID ドライバは、クラスタのすべてのノードを探索して、一意のデ バイスのリストを作成し、クラスタのすべてのノードで一貫している一意のメジャー番号およびマイナー番号を各デバイスに割り当てます。広域デバイスへのアクセスは、ディスクを示す c0t0d0 などの従来の Solaris デバイス ID ではなく、(DID ドライバが割り当てた) この一意のデバイス ID を利用して行われます。

この方法により、ディスクにアクセスするすべてのアプリケーション (ボリュームマネージャーまたは raw デバイスを使用するアプリケーションなど) は、一貫したパスを使用してクラスタ全体にアクセスできます。各デバイスのローカルメジャー番号およびマイナー番号はノードによって異なり、Solaris デバイス命名規則も変更する可能性があるため、この一貫性は、多重ホストディスクにとって特に重要です。たとえば、Node1 は多重ホストディスクを c1t2d0 と識別し、Node2 は同じディスクをまったく異なるディスクとして、つまり、c3t2d0 と識別する場合があります。ノードはこのような名前の代わりに、DID ドライバが割り当てた広域名 (d10 など) を使用します。つまり、DID ドライバは多重ホストディスクへの一貫したマッピングを各ノードに提供します。

cldevice コマンドでデバイス ID を更新して管理します。詳細は、cldevice(1CL) のマニュアルページを参照してください。

デバイスグループ

Sun Cluster ソフトウェアでは、多重ホストデバイスをすべてSun Cluster ソフトウェアで管理する必要があります。最初に多重ホストディスク上にボリュームマネージャーのディスクグループ (Solaris ボリュームマネージャーのディスクセットまたは VERITAS Volume Manager ディスクグループのいずれか) を作成します。次に、ボリュームマネージャーのディスクグループを「デバイスグループ」として登録します。デバイスグループは、広域デバイスの一種です。さらに、Sun Cluster ソフトウェアは、個々のディスクデバイスやテープデバイスごとに raw デバイスグループを自動的に作成します。ただし、これらのクラスタデバイスグループは、広域デバイスとしてアクセスされるまではオフラインの状態になっています。

この登録によって、Sun Cluster ソフトウェアは、どのノードがどのボリュームマネージャーディスクグループへのパスをもっているかを知ることができます。この時点でそのボリュームマネージャーデバイスグループは、クラスタ内で広域アクセスが可能になります。あるデバイスグループが複数のノードから書き込み可能 (マスター) な場合は、そのデバイスグループに格納されるデータは、高度な可用性を有することになります。高度な可用性を備えたデバイスグループには、クラスタファイルシステムを格納できます。

注 –

デバイスグループは、リソースグループとは別のものです。あるノードまたはゾーンは、データサービスプロセスのグループを表すリソースグループをマスターすることができます。別のノードは、データサービスによりアクセスされているディスクグループをマスターすることができます。ただし、最も良い方法は、特定のアプリケーションのデータを保存するデバイスグループと、アプリケーションのリソース (アプリケーションデーモン) を同じノードに含むリソースグループを維持することです。デバイスグループとリソースグループの関係の詳細については、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の「リソースグループとデバイスグループの関係」を参照してください。

あるノードがディスクデバイスグループを使用するとき、ボリュームマネージャーのディスクグループは実際に使用するディスクに対してマルチパスサポートを提供するため、そのディスクグループは「広域」になります多重ホストディスクに物理的に接続された各クラスタノードは、デバイスグループへのパスを提供します。

デバイスグループのフェイルオーバー

ディスク格納装置は複数のノードに接続されるため、現在デバイスグループをマスターしているノードに障害が生じた場合でも、代替パスによってその格納装置にあるすべてのデバイスグループにアクセスできます。デバイスグループをマスターするノードの障害は、回復と一貫性の検査を実行するために要する時間を除けば、デバイスグループへのアクセスに影響しません。この時間の間は、デバイスグループが使用可能になるまで、すべての要求は (アプリケーションには透過的に) 阻止されます。

図 3–1 フェイルオーバー前後のデバイスグループ

図 : この図については、前の本文中で説明しています。

多重ポートデバイスグループ

この節では、多重ポートディスク構成において性能と可用性をバランスよく実現するディスクデバイスグループのプロパティーについて説明します。Sun Cluster ソフトウェアには、多重ポートディスク構成を設定するためのプロパティーが 2 つあります。つまり、preferenced と numsecondaries です。preferenced プロパティーは、フェイルオーバーの発生時に各ノードがどの順で制御を取得するかを制御します。numsecondaries プロパティーは、特定のデバイスグループに対する二次ノードの数を設定します。

高可用性サービスは、主ノードまたはゾーンが停止し、かつ、主ノードまたはゾーンになる資格のある二次ノードまたはゾーンが存在しないときに、完全に停止したと見なされます。preferenced プロパティーが true に設定されている場合、 サービスのフェイルオーバーが発生すると、ノードリストの順序に従って、二次ノードまたはゾーンが選択されます。ノードリストは、ノードまたはゾーンが、主制御を引き受ける順序、またはスペアから二次への移行を引き受ける順序を決めます。clsetup コマンドを使用して、デバイスサービスの優先順序を動的に変更できます。従属サービスプロバイダ (広域ファイルシステムなど) に関連する設定は、デバイスサービスの設定と同じになります。

主ノードは、正常な運用時に二次ノードのチェックポイントをとります。多重ポートディスク構成では、二次ノードのチェックポイントをとるたびに、クラスタの性能の低下やメモリーのオーハーヘッドの増加が発生します。スペアノードのサポートが実装されているのは、このようなチェックポイントによる性能の低下やメモリーのオーバーヘッドを最小限に抑えるためです。デフォルトでは、デバイスグループには 1 つの主ノードと 1 つの二次ノードがあります。残りのプロバイダノードはスペアノードです。フェイルオーバーが発生すると、二次ノードが主ノードになり、ノードリスト上で最も優先順位の高い (スペア) ノードが二次ノードになります。

二次ノードの望ましい数には、任意の整数 (1 から、デバイスグループ内の動作可能な主ノード以外のプロバイダノードの数まで) を設定できます。

注 –

Solaris ボリュームマネージャー を使用している場合、 numsecondariesプロパティーにデフォルト以外の数字を設定するには、まず、デバイスグループを作成する必要があります。

デバイスサービスのためのデフォルトの望ましい二次ノード数は 1 です。望ましい数とは、複製フレームワークによって維持される二次プロバイダノードの実際の数です。ただし、動作可能な主ノード以外のプロバイダノードの数が望ましい数よりも小さい場合を除きます。ノードを構成に追加したり、ノードを構成から切り離す場合は、numsecondaries プロパティーを変更したあと、ノードリストを十分に確認する必要があります。ノードリストと二次ノードの望ましい数を正しく保つことによって、構成されている二次ノードの数と、フレームワークによって与えられている実際の数の不一致を防げます。

広域名前空間

広域デバイスを有効にする Sun Cluster ソフトウェアの機構は、「広域名前空間」です。広域名前空間には、ボリューム管理ソフトウェアの名前空間とともに、/dev/global/ 階層が含まれます。広域名前空間は、多重ホストディスクとローカルディスクの両方 (および CD-ROM やテープなどの他のクラスタデバイスすべて) を反映して、多重ホストディスクへの複数のフェイルオーバーパスを提供します。多重ホストディスクに物理的に接続された各ノードは、クラスタ内のすべてのノードの記憶装置に対するパスを提供します。

Solaris Volume Manager の場合、ボリュームマネージャーの名前空間は、通常、 /dev/md/diskset/dsk (と rdsk) ディレクトリにあります。Veritas VxVM の場合、 ボリュームマネージャーの名前空間は /dev/vx/dsk/disk-group ディレクトリと /dev/vx/rdsk/disk-group ディレクトリにあります。これらの名前空間は、クラスタ全体でインポートされている Solaris ボリュームマネージャー の各ディスクセットと VxVM の各ディスクグループのディレクトリから構成されます。これらの各ディレクトリには、そのディスクセットまたはディスクグループ内の各メタデバイスまたはボリュームのデバイスノードが格納されています。

Sun Cluster ソフトウェアでは、ローカルボリュームマネージャーの名前空間内の各デバイスノードは /global/.devices/node@nodeID ファイルシステム内のデバイスノードへのシンボリックリンクに置き換えられます。nodeID は、クラスタ内のノードを表す整数です。Sun Cluster ソフトウェアは、その標準的な場所に引き続きシンボリックリンクとしてボリューム管理デバイスも表示します。広域名前空間と標準ボリュームマネージャー名前空間は、どちらも任意のクラスタノードから使用できます。

広域名前空間には、次の利点があります。

ローカル名前空間と広域名前空間の例

次の表は、多重ホストディスク c0t0d0s0 でのローカル名前空間と広域名前空間のマッピングを示したものです。

表 3–2 ローカル名前空間と広域名前空間のマッピング

コンポーネントまたはパス 

ローカルノード名前空間 

広域名前空間 

Solaris 論理名 

/dev/dsk/c0t0d0s0

/global/.devices/node@nodeID/dev/dsk/c0t0d0s0

DID 名 

/dev/did/dsk/d0s0

/global/.devices/node@nodeID/dev/did/dsk/d0s0

Solaris ボリュームマネージャー 

/dev/md/diskset/dsk/d0

/global/.devices/node@nodeID/dev/md/diskset/dsk/d0

VERITAS Volume Manager 

/dev/vx/dsk/disk-group/v0

/global/.devices/node@nodeID/dev/vx/dsk/disk-group/v0

広域名前空間はインストール時に自動的に生成されて、再構成再起動のたびに更新されます。広域名前空間は、cldevice コマンドを使用して生成することもできます。詳細は、cldevice(1CL) のマニュアルページを参照してください。

クラスタファイルシステム

クラスタファイルシステムには、次の機能があります。

広域デバイスにファイルシステムをマウントするとき、広域にマウントする場合は mount -g を使用し、ローカルにマウントする場合は mount を使用します。

プログラムは、同じファイル名 (たとえば、/global/foo) によって、クラスタ内のすべてのノードからクラスタファイルシステムのファイルにアクセスできます。

クラスタファイルシステムは、すべてのクラスタメンバーにマウントされます。クラスタファイルシステムをクラスタメンバーのサブセットにマウントすることはできません。

クラスタファイルシステムは、特定のファイルシステムタイプではありません。つまり、クライアントは、実際に使用するファイルシステム (UFS など) だけを認識します。

クラスタファイルシステムの使用法

Sun Cluster ソフトウェアでは、すべての多重ホストディスクがディスクデバイスグループとして構成されています。これは、Solaris ボリュームマネージャー のディスクセット、VxVM のディスクグループ、またはソフトウェアベースのボリューム管理ソフトウェアの制御下にない個々のディスクが該当します。

クラスタファイルシステムを高可用性にするには、使用するディスクストレージが複数のノードに接続されていなければなりません。したがって、ローカルファイルシステム (ノードのローカルディスクに格納されているファイルシステム) をクラスタファイルシステムにした場合は、高可用性にはなりません。

クラスタファイルシステムは、通常のファイルシステムと同様にマウントできます。

注 –

Sun Cluster ソフトウェアには、クラスタファイルシステムに対する特定の命名規則はありません。しかし、/global/disk-group などのように、同じディレクトリのもとにすべてのクラスタファイルシステムのマウントポイントを作成すると、管理が容易になります。詳細は、Sun Cluster 3.1 9/04 Software Collection for Solaris OS (SPARC Platform Edition) と『Sun Cluster のシステム管理 (Solaris OS 版)』を参照してください。

HAStoragePlus リソースタイプ

HAStoragePlus リソースタイプは、ローカルおよび広域ファイルシステム構成を高可用対応にするように設計されています。HAStoragePlus リソースタイプを使用して、ローカルまたは広域ファイルシステムを Sun Cluster 環境に統合し、このファイルシステムを高可用対応にすることができます。

HAStoragePlus リソースタイプを使用すると、ファイルシステムを非大域ゾーンで利用可能にすることができます。HAStoragePlus リソースタイプを使用してこのようにするには、大域ゾーンと非大域ゾーンにマウントポイントを作成してください。ファイルシステムを非大域ゾーンで利用可能にするために、HAStoragePlus リソースタイプは、まず大域ゾーンにあるファイルシステムをマウントします。このリソースタイプは、次に非大域ゾーンでループバックマウントを実行します。

注 –

ローカルファイルシステムには、UNIX File System (UFS)、Quick File System (QFS)、Veritas File System (VxFS)、Solaris ZFS (Zettabyte File System) などがあります。

HAStoragePlus リソースタイプは、確認、マウント、およびマウントの強制解除などの追加のファイルシステム機能を提供します。これらの機能により、Sun Cluster はローカルのファイルシステムをフェイルオーバーすることができます。 フェイルオーバーを行うには、アフィニティースイッチオーバーが有効になった広域ディスクグループ上にローカルファイルシステムが存在していなければなりません。

HAStoragePlus リソースタイプの使用法については、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の「高可用性ローカルファイルシステムの有効化」 を参照してください。

HAStoragePlus リソースタイプを使用して、リソースとリソースが依存するデバイスグループの起動を同期化することができます。詳細は、「リソース、リソースグループ、リソースタイプ」を参照してください。

syncdir マウントオプション

syncdir マウントオプションは、実際に使用するファイルシステムとして UFS を使用するクラスタファイルシステムに使用できます。ただし、syncdir を指定しない場合、パフォーマンスは大幅に向上します。syncdir を指定した場合、POSIX 準拠の書き込みが保証されます。syncdir を指定しない場合、NFS ファイルシステムの場合と同じ動作となります。たとえば、syncdir を指定しないと、場合によっては、ファイルを閉じるまでスペース不足条件を検出できません。syncdir (および POSIX 動作) を指定すると、スペース不足条件は書き込み動作中に検出されます。syncdir を指定しない場合に問題が生じることはほとんどありません。

SPARC ベースのクラスタを使用している場合、VxFS には、UFS の syncdir マウントオプションと同等なマウントオプションはありません。VxFS の動作は syncdir マウントオプションを指定しない場合の UFS と同じです。

広域デバイスとクラスタファイルシステムの FAQ については、「ファイルシステムに関する FAQ」を参照してください。

ディスクパスの監視

現在のリリースの Sun Cluster ソフトウェアは、ディスクパス監視機能 (DPM) をサポートします。この節では、DPM、DPM デーモン、およびディスクパスを監視するときに使用する管理ツールについての概念的な情報を説明します。ディスクパスの状態を監視、監視解除、および表示する手順については、『Sun Cluster のシステム管理 (Solaris OS 版)』 を参照してください。

DPM の概要

DPM は、二次ディスクパスの可用性を監視することによって、フェイルオーバーおよびスイッチオーバーの全体的な信頼性を向上させます。リソースを切り替える前には、cldevice コマンドを使用して、そのリソースが使用しているディスクパスの可用性を確認します。cldevice コマンドのオプションを使用すると、単一ノードまたはクラスタ内のすべてのノードへのディスクパスを監視できます。コマンド行オプションの詳細は、cldevice(1CL) のマニュアルページを参照してください。

次の表に、DPM コンポーネントのデフォルトのインストール場所を示します。

保存場所 

コンポーネント 

デーモン 

/usr/cluster/lib/sc/scdpmd

コマンド行インタフェース 

/usr/cluster/bin/cldevice

デーモン状態ファイル (実行時に作成される) 

/var/run/cluster/scdpm.status

マルチスレッド化された DPM デーモンは各ノード上で動作します。DPM デーモン (scdpmd) はノードの起動時に rc.d スクリプトによって起動されます。問題が発生した場合、DPM デーモンは pmfd によって管理され、自動的に再起動されます。以下で、最初の起動時に scdpmd がどのように動作するかについて説明します。

注 –

起動時、各ディスクパスの状態は UNKNOWN に初期化されます。

  1. DPM デーモンは、以前の状態ファイルまたは CCR データベースから、ディスクパスとノード名の情報を収集します。CCR についての詳細は、「クラスタ構成レポジトリ (CCR)」を参照してください。DPM デーモンの起動後、指定したファイルから監視すべきディスクのリストを読み取るように DPM デーモンに指示できます。

  2. DPM デーモンは通信インタフェースを初期化して、デーモンの外部にあるコンポーネント (コマンド行インタフェースなど) からの要求に応えます。

  3. DPM デーモンは scsi_inquiry コマンドを使用して、監視リストにある各ディスクパスに 10 分ごとに ping を送信します。各エントリはロックされるため、通信インタフェースは監視中のエントリの内容にアクセスできなくなります。

  4. DPM デーモンは 、UNIX の syslogd コマンドを使用して Sun Cluster イベントフレームワークにパスの新しい状態を通知して、ログに記録します。詳細は、syslogd(1M) のマニュアルページを参照してください。

注 –

このデーモンに関連するすべてのエラーはpmfd で報告されます。API のすべての関数は、成功時に 0 を戻し、失敗時に -1 を戻します。

DPM デーモンは、Sun StorEdge Traffic Manager、HDLM、EMC PowerPath などのマルチパスドライバを通じて、論理パスの可用性を監視します。このようなマルチパスドライバは物理パスの障害を DPM デーモンから隠すため、DPM デーモンはマルチパスドライバが管理する物理パスを監視できません。

ディスクパスの監視

この節では、クラスタ内のディスクパスを監視するための 2 つの方法について説明します。1 つめの方法は cldeviceコマンドを使用する方法です。scdpm コマンドを使用すると、クラスタ内のディスクパスの状態を監視、監視解除、または表示できます。このコマンドを使用して故障したディスクのリストを印刷し、ファイルからディスクパスを監視することもできます。詳細は、cldevice(1CL) のマニュアルページを参照してください。

2 つめの方法は、Sun Cluster Manager (従来の SunPlex Manager) の GUI (Graphical User Interface) を使用してクラスタ内のディスクパスを監視する方法です。Sun Cluster Manager は、クラスタ内の監視しているディスクをトポロジビューで表示します。このトポロジビューは 10 分ごとに更新され、失敗した ping の数が表示されます。Sun Cluster Manager の GUI が報告する情報と cldevice コマンドを組み合わせて使用すると、ディスクパスを管理できます。Sun Cluster Manager については、『Sun Cluster のシステム管理 (Solaris OS 版)』の第 12 章「グラフィカルユーザーインタフェースによる Sun Cluster の管理」 を参照してください。

cldevice コマンドを使用してディスクパスを監視および管理する

cldevice コマンドを使用して、次の作業を実行できます。

任意のアクティブなノードから、ディスクパス引数を付けて cldevice コマンドを発行することによって、そのクラスタ上で DPM 管理作業を実行できます。ディスクパス引数はノード名とディスク名からなります。ノード名は不要です。ノード名を指定しない場合、デフォルトですべてのノードが影響を受けます。次の表に、ディスクパスの命名規約を示します。

注 –

必ず、UNIX のディスクパス名ではなく、広域ディスクパス名を指定してください。これは、広域ディスクのパス名がクラスタ全体で一貫しているためです。UNIX のディスクパス名にはこの性質はありません。たとえば、あるノードでディスクパス名を c1t0d0 にして、別のノードで c2t0d0 にすることができます。ノードに接続されたデバイスの広域ディスクパス名を調べるには、DPM コマンドを発行する前に cldevice list コマンドを使用します。詳細は、cldevice(1CL) のマニュアルページを参照してください。

表 3–3 ディスクパス名の例

名前型 

ディスクパス名の例 

説明 

広域ディスクパス 

schost-1:/dev/did/dsk/d1

schost-1 ノード上のディスクパス d1

 

all:d1

クラスタのすべてのノードでのディスクパス d1

UNIX ディスクパス 

schost-1:/dev/rdsk/c0t0d0s0

schost-1 ノード上のディスクパス c0t0d0s0

 

schost-1:all

schost-1 ノードでのすべてのディスクパス

すべてのディスクパス 

all:all

クラスタのすべてのノードでのすべてのディスクパス 

Sun Cluster Manager によるディスクパスの監視

Sun Cluster Manager を使用すると、次のような DPM の基本的な管理作業を実行できます。

Sun Cluster Manager のオンラインヘルプでは、ディスクパスの管理方法の手順について説明しています。

clnode set コマンドを使用して、ディスクパスエラーを管理する

すべての監視対象ディスクパスでエラーが発生した際のノードの自動再起動を有効化または無効化するには、clnode set コマンドを使用します。Sun Cluster Manager を使用してこれらの作業を実行することもできます。

定足数と定足数デバイス

ここでは、次の内容について説明します。

注 –

Sun Cluster ソフトウェアが定足数デバイスとしてサポートする特定のデバイスの一覧については、Sun のサービスプロバイダにお問い合わせください。

クラスタノードはデータとリソースを共有しており、複数のアクティブなパーティションがあるとデータが壊れる恐れがあるのでクラスタは決して複数のアクティブなパーティションに一度に分割しないでください。クラスタメンバーシップモニター (CMM) および定足数アルゴリズムにより、たとえクラスタ接続がパーティション分割されている場合でも、いつでも同じクラスタのインスタンスが 1 つだけは動作していることが保証されます。

定足数と CMM の概要については、『Sun Cluster の概要 (Solaris OS 版)』の「クラスタメンバーシップ」を参照してください。

クラスタのパーティション分割からは、次の 2 種類の問題が発生します。

Split brain は、ノード間のクラスタ接続が失われ、クラスタがサブクラスタにパーティション分割されるときに起きます。あるパーティションのノードはほかのパーティションのノードと通信できないため、各パーティションは自分が唯一のパーティションであると認識します。

amnesia は、停止したクラスタが、停止時よりも古いクラスタ構成データに基づいて再起動されたときに発生します。この問題は、最後に機能していたクラスタパーティションにないノード上のクラスタを起動するときに起きる可能性があります。

Sun Cluster ソフトウェアは、split brain と amnesia を次の操作により回避します。

過半数の投票数を持つパーティションは、定足数を獲得し、動作可能になります。この過半数の投票メカニズムにより、クラスタ内に 3 つ以上のノードが構成されているときに split brain と amnesia を防ぐことができます。ただし、クラスタ内に 3 つ以上のノードが構成されている場合、ノードの投票数を数えるだけでは十分ではありません。しかし、2 ノードクラスタでは過半数が 2 であるため、このような 2 ノードクラスタがパーティション分割された場合、いずれかのパーティションが定足数を獲得するために外部投票が必要です。この外部からの投票は「定足数デバイス」によって行われます。

定足数投票数について

clquorum show コマンドを使って、以下の情報を調べます。

詳細は、cluster(1CL) のマニュアルページを参照してください。

ノードおよび定足数デバイスの両方がクラスタへの投票に数えられ、定足数を満たすことができます。

ノードは、ノードの状態に応じて投票に数えられます。

定足数デバイスは、デバイスに伴う投票数に基づいて、投票に数えられます。定足数デバイスを構成するとき、Sun Cluster ソフトウェアは定足数デバイスに N-1 の投票数を割り当てます (N は定足数デバイスに伴う投票数)。たとえば、2 つのノードに接続された、投票数がゼロ以外のクォーラムデバイスの投票数は 1 (2-1) になります。

定足数デバイスは、次の 2 つの条件のうちの 1 つを満たす場合に投票に数えられます。

定足数デバイスの構成は、クラスタをインストールするときに行うか、あるいはあとで、『Sun Cluster のシステム管理 (Solaris OS 版)』の第 6 章「定足数の管理」で説明されている手順に従って行います。

障害による影響の防止について

クラスタの主要な問題は、クラスタがパーティション分割される (sprit-brain と呼ばれる) 原因となる障害です。split brain が発生すると、一部のノードが通信できなくなるため、個々のノードまたは一部のノードが個々のクラスタまたは一部のクラスタを形成しようとします。各部分 (つまりパーティション) は、誤って、多重ホストデバイスに対して単独のアクセスと所有権を持つものと認識します。そのため、複数のノードがディスクに書き込もうとすると、データが破壊される可能性があります。

障害による影響の防止機能では、多重ホストデバイスへのノードのアクセスを、ディスクへのアクセスを物理的に防止することによって制限します。障害による影響の防止はノードにのみ適用され、ゾーンには適用されません。障害が発生するかパーティション分割され、ノードがクラスタから切り離されると、障害による影響の防止機能によって、ノードがディスクにアクセスできなくなります。現在のメンバーノードだけが、ディスクへのアクセス権を持つため、データの完全性が保たれます。

デバイスサービスは、多重ホストデバイスを使用するサービスに対して、フェイルオーバー機能を提供します。現在、デバイスグループの主ノード (所有者) として機能しているクラスタメンバーに障害が発生するか、またはこのメンバーに到達できなくなると、新しい主ノードが選択されます。この新しい主ノードによって、デバイスグループはほんのわずかの中断だけで機能し続けることができます。このプロセス中、新しい主ノードが起動される前に、古い主ノードはデバイスへのアクセスを放棄する必要があります。ただし、あるメンバーがクラスタから切り離されて到達不能になると、クラスタはそのノードに対して、主ノードであったデバイスを解放するように通知できません。したがって、存続するメンバーが、障害の発生したメンバーから広域デバイスを制御してアクセスできるようにする手段が必要です。

Sun Cluster ソフトウェアは、SCSI ディスクリザベーションを使用して、二重障害の防止機能を実装します。SCSI リザベーションを使用すると、障害が発生したノードは多重ホストデバイスから阻止され、これらのディスクにアクセスできなくなります。

SCSI-2 ディスクリザベーションがサポートするリザベーションの形式には、ディスクに接続されているすべてのノードにアクセスを付与するものと (リザベーションが設定されていない場合)、単一ノード (リザベーションを保持するノード) だけにアクセスを制限するものがあります。

クラスタメンバーは、別のノードがクラスタインターコネクトを介して通信していないことを検出すると、障害による影響の防止手順を開始して、そのノードが共有ディスクへアクセスするのを防止します。この二重障害の防止機能が動作すると、アクセスを阻止されたノードはパニック状態になり、そのコンソールに「reservation conflict」メッセージが表示されます。

あるノードがすでにクラスタメンバーでないことが検出されると、そのノードとほかのノード間で共有されていたすべてのディスクに対して SCSI リザベーションが行われます。阻止されているノードは自分が阻止されていることを認識しない場合があるため、共有ディスクのどれかにアクセスしようとしてリザベーションを検出すると、そのノードはパニックします。

障害の影響を防止するフェイルファースト機構

異常のあるノードが再起動され、共有ストレージに書き込むのを防ぐクラスタフレームワークの機構をフェイルファーストといいます。

クラスタのメンバーである各ノードでは、定足数ディスクを含むアクセス可能な個々のディスクに対し ioctl (MHIOCENFAILFAST) が連続的に有効にされます。この ioctl はディスクドライバに対する命令です。あるノードがほかのノードによってリザベーションされているディスクにアクセスできない場合、この ioctl を使用すると、このノードは自らをパニックする (強制的に停止する) ことができます。

MHIOCENFAILFAST ioctl が有効になっていると、ドライバは、ノードからそのディスクに対して出されるすべての読み取りや書き込みからのエラーに、 Reservation_Conflict エラーコードが含まれていないか検査します。ioctl はバックグラウンドでディスクに対して周期的にテスト操作を行い、Reservation_Conflict がないか検査します。Reservation_Conflict が返されると、フォアグラウンドとバックグラウンドのコントロールフローパスが両方ともパニックを発生します。

SCSI-2 ディスクの場合、リザベーションは永続的ではありません。リザベーションはノードが再起動されると無効になります。Persistent Group Reservation (PGR) の SCSI-3 ディスクでは、リザベーション情報はそのディスクに格納されるため、ノードが再起動されても有効です。SCSI-2 ディスクでも SCSI-3 ディスクでも、フェイルファースト機構の機能は同じです。

定足数を獲得できるパーティションに属していないノードが、クラスタ内の他のノードとの接続を失うと、そのノードは別のノードによってクラスタから強制的に切り離されます。定足数を達成可能なパーティションに参加している別のノードが、共有ディスクにリザベーションを発行します。定足数を持たないノードが共有ディスクにアクセスしようとすると、そのノードはリザベーション衝突のエラーを受け取り、フェイルファースト機構に基づいてパニックします。

パニック後、ノードは再起動してクラスタに再度加わろうとするか、またはクラスタが SPARC ベースのシステムで構成されている場合は、OpenBoot PROM (OBP) プロンプトのままになります。ノードがどちらのアクションをとるかは、auto-boot パラメータの設定によって決定されます。auto-boot を設定するには、SPARC ベースのクラスタにおいて、OpenBoot PROM の ok プロンプトで eeprom を使用します。詳細は、eeprom(1M) のマニュアルページを参照してください。X86 ベースのクラスタでは、BIOS のブート後に SCSI ユーティリティーを起動することで設定できます。

定足数の構成について

次に、定足数の構成について示します。

回避すべき定足数の構成例については、「望ましくない定足数の構成」を参照してください。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。

定足数デバイス要件の順守

Sun Cluster ソフトウェアがご使用のデバイスを定足数デバイスとしてサポートしていることを確認します。この要件を無視すると、クラスタの可用性が損なわれる場合があります。

注 –

Sun Cluster ソフトウェアが定足数デバイスとしてサポートする特定のデバイスの一覧については、Sun のサービスプロバイダにお問い合わせください。

Sun Cluster ソフトウェアは、次の種類の定足数デバイスをサポートしています。

注 –

レプリケートされたデバイスは定足数デバイスとしてはサポートされません。

2 ノード構成では、1 つのノードに障害が起きてももう 1 つのノードが動作を継続できるように、少なくとも 1 つの定足数デバイスを構成する必要があります。詳細は、図 3–2を参照してください。

回避すべき定足数の構成例については、「望ましくない定足数の構成」を参照してください。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。

定足数デバイスのベストプラクティスの順守

以下の情報を使用して、ご使用のトポロジに最適な定足数の構成を評価してください。

回避すべき定足数の構成例については、「望ましくない定足数の構成」を参照してください。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。

推奨される定足数の構成

この節では、推奨される定足数の構成例を示します。回避すべき定足数の構成例については、「望ましくない定足数の構成」を参照してください。

2 ノード構成の定足数

2 ノードのクラスタを形成するには、2 つの定足投票数が必要です。これらの 2 つの投票数は、2 つのクラスタノード、または 1 つのノードと 1 つの定足数デバイスのどちらかによるものです。

図 3–2 2 ノード構成

図 : 2 つのノードに接続された 1 つの定足数デバイスを持つノード A およびノード B を示しています。

2 ノードより大きな構成での定足数

定足数デバイスを持たない、2 ノードよりも大きなクラスタも構成できます。ただし、このようなクラスタを構成した場合、そのクラスタはクラスタ内の過半数のノードなしには開始できません。

図 : 構成1: NodeA-D。A/B が (->) QD1 に接続。C/D -> QD2。構成2: NodeA-C。A/C -> QD1。B/C -> QD2。構成3: NodeA-C -> 1 つの QD。

変則的な定足数の構成

図 3–3 では、Node A と Node B でミッションクリティカルなアプリケーション (Oracle データベースなど) を実行していると仮定します。ノード A とノード B を使用できず、共有データにアクセスできない場合、クラスタ全体を停止させる必要がある場合があります。停止させない場合、この構成は高可用性を提供できないため、最適な構成とはなりません。

この例外に関するベストプラクティスについては、「定足数デバイスのベストプラクティスの順守」を参照してください。

図 3–3 変則的な構成

図 : NodeA-D。Node A/B は QD1-4 に接続。NodeC は QD4 に接続。NodeD は QD4 に接続。合計投票 = 10。定足数に必要な投票 = 6。

望ましくない定足数の構成

この節では、回避すべき定足数の構成例を示します。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。

図 : 構成1: NodeA-B。A/B は -> QD1/2 に接続。構成2: NodeA-D。A/B -> QD1/2。構成3: NodeA-C. A/B-> QD1/2 & C -> QD2.

データサービス

「データサービス」という用語は、Oracle や Sun Java System Web Server など、単一のサーバーではなく、クラスタで動作するように構成されたアプリケーションを意味します。データサービスは、アプリケーション、専用の Sun Cluster 構成ファイル、および、アプリケーションの次のアクションを制御する Sun Cluster 管理メソッドからなります。

データサービスタイプについては、『Sun Cluster の概要 (Solaris OS 版)』の「データサービス」を参照してください。

図 3–4に、単一のアプリケーションサーバーで動作するアプリケーション (単一サーバーモデル) と、クラスタで動作する同じアプリケーション (クラスタサーバーモデル) との比較を示します。これら 2 つの構成の唯一の違いは、クラスタ化されたアプリケーションの動作がより速くなり、その可用性もより高くなることです。

図 3–4 標準的なクライアントサーバー構成とクラスタ化されたクライアントサーバー構成

図 : この図については次に説明します。

単一サーバーモデルでは、特定のパブリックネットワークインタフェース (ホスト名) を介してサーバーにアクセスするようにアプリケーションを構成します。ホスト名はその物理サーバーに関連付けられています。

クラスタサーバーモデルでは、パブリックネットワークインタフェースは、論理ホスト名または共有アドレスです。「ネットワークリソース」は、論理ホスト名と共有アドレスの両方を表します。

一部のデータサービスでは、ネットワークインタフェースとして論理ホスト名か共有アドレスのいずれかを指定する必要があります。論理ホスト名と共有アドレスは相互に交換できません。しかし、別のデータサービスでは、論理ホスト名や共有アドレスをどちらでも指定することができます。どのようなタイプのインタフェースを指定する必要があるかどうかについては、各データサービスのインストールや構成の資料を参照してください。

ネットワークリソースは、特定の物理サーバーと関連付けられているわけではありません。ネットワークリソースは、ある物理サーバーから別の物理サーバーに移すことができます。

ネットワークリソースは、当初、1 つのノード (一次ノード) に関連付けられています。主ノードで障害が発生すると、ネットワークリソースとアプリケーションリソースは別のクラスタノード (二次ノード) にフェイルオーバーされます。ネットワークリソースがフェイルオーバーされても、アプリケーションリソースは、短時間の遅れの後に二次ノードで動作を続けます。

図 3–5に、単一サーバーモデルとクラスタサーバーモデルとの比較を示します。クラスタサーバーモデルのネットワークリソース (この例では論理ホスト名) は、 複数のクラスタノード間を移動できます。アプリケーションは、特定のサーバーに関連付けられたホスト名として、この論理ホスト名を使用するように設定されます。

図 3–5 固定ホスト名と論理ホスト名

図 : この図については、前の本文中で説明しています。

共有アドレスも最初は 1 つのノードに対応付けられます。このノードのことを「広域インタフェースノード」といいます。共有アドレスは「広域インタフェース」といい、クラスタへの単一ネットワークインタフェースとして使用されます。

論理ホスト名モデルとスケーラブルサービスモデルの違いは、スケーラブルサービスモデルでは、各ノードのループバックインタフェースにも共有アドレスがアクティブに構成される点です。この構成では、データサービスの複数のインスタンスをいくつかのノードで同時にアクティブにすることができます。「スケーラブルサービス」という用語は、クラスタノードを追加してアプリケーションの CPU パワーを強化すれば、性能が向上することを意味します。

広域インタフェースノードに障害が発生した場合、共有アドレスは同じアプリケーションのインスタンスが動作している別のノードで起動できます。これによって、このノードが新しい広域インタフェースノードになります。または、共有アドレスを、このアプリケーションを実行していない別のクラスタノードにフェイルオーバーすることができます。

図 3–6 に、単一サーバー構成とクラスタ化されたスケーラブルサービス構成との比較を示します。スケーラブルサービス構成では、共有アドレスがすべてのノードに設定されています。アプリケーションは、特定のサーバーに関連付けられたホスト名として、この共有アドレスを使用するように設定されます。この方式は、フェイルオーバーデータサービスに論理ホスト名を使用する方法と似ています。

図 3–6 固定ホスト名と共有アドレス

図 : この図については、前の本文中で説明しています。

データサービスメソッド

Sun Cluster ソフトウェアでは、一連のサービス管理メソッドを提供しています。これらのメソッドは、Resource Group Manager (RGM) の制御下で実行されます。RGM はこれらのメソッドを使用して、クラスタノード上またはゾーン内のアプリケーションを開始、停止、および監視します。これらのメソッドとクラスタフレームワークソフトウェアおよび多重ホストデバイスにより、アプリケーションは、フェイルオーバーデータサービスやスケーラブルデータサービスとして機能します。

さらに、RGM は、アプリケーションのインスタンスやネットワークリソース (論理ホスト名と共有アドレス) といったクラスタのリソースを管理します。

Sun Cluster ソフトウェアが提供するメソッドのほかにも、Sun Cluster ソフトウェアは API やいくつかのデータサービス開発ツールを提供します。これらのツールを使用すれば、アプリケーション開発者は、独自のデータサービスメソッドを開発することによって、ほかのアプリケーションを Sun Cluster ソフトウェアの下で高可用性データサービスとして実行できます。

フェイルオーバーデータサービス

データサービスが実行されているノードまたはゾーン (主ノード) に障害が発生すると、サービスは、ユーザーによる介入なしで別の作業ノードまたはゾーンに移行します。フェイルオーバーサービスは、アプリケーションインスタンスリソースとネットワークリソース (「論理ホスト名」) のコンテナである「フェイルオーバーリソースグループ」を使用します。論理ホスト名は、1 つのノードまたはゾーンで構成でき、あとで自動的に元のノードやゾーンに構成したり、別のノードやゾーンに構成することができる IP アドレスです。

フェイルオーバーデータサービスでは、アプリケーションインスタンスは単一のノードまたはゾーンでのみ実行されます。フォルトモニターは、エラーを検出すると、そのインスタンスを同じノードまたはゾーンで再起動しようとするか、別のノードまたはゾーンで起動 (フェイルオーバー) しようとします。出力は、データサービスの構成方法によって異なります。

スケーラブルデータサービス

スケーラブルデータサービスは、複数のノードまたはゾーンのアクティブインスタンスに対して効果があります。

スケーラブルサービスは、2 つのリソースグループを使用します。

スケーラブルリソースグループは、同時に複数のノードまたはゾーンでオンラインにできます。その結果、サービスの複数のインスタンスを一度に実行できます。ただし、共有アドレスを使用してノード間のサービス負荷のバランスを取るスケーラブルなリソースグループは、1 つの物理ノード当たり 1 つのゾーンでのみオンラインにできます。スケーラブルなリソースグループはすべて負荷分散を使用します。スケーラブルサービスのホストとなるすべてのノードまたはゾーンは、サービスをホストするための同じ共有アドレスを使用します。共有アドレスのホストとなるフェイルオーバーリソースグループは、一度に 1 つのノードまたはゾーンでしかオンラインにできません。

サービス要求は、単一ネットワークインタフェース (広域インタフェース) を通じてクラスタに入ります。これらの要求は、事前に定義されたいくつかのアルゴリズムの 1 つに基づいてノードまたはゾーンに分配されます。これらのアルゴリズムは「負荷分散ポリシー」によって設定されます。クラスタは、負荷分散ポリシーを使用し、いくつかのノードまたはサービス間でサービス負荷分散をとることができます。ほかの共有アドレスをホストしている異なるノードまたはゾーン上には、複数の広域インタフェースが存在する可能性があります。

スケーラブルサービスの場合、アプリケーションインスタンスはいくつかのノードまたはゾーンで同時に実行されます。広域インタフェースのホストとなるノードまたはゾーンに障害が発生すると、広域インタフェースは別のノードまたはゾーンで処理を続行します。動作していたアプリケーションインスタンスが停止した場合、そのインスタンスは同じノードまたはゾーン上で再起動しようとします。

アプリケーションインスタンスを同じノードまたはゾーンで再起動できず、別の未使用のノードまたはゾーンがサービスを実行するように構成されている場合、サービスはその未使用ノードまたはゾーンで処理を続行します。そうしないと、サービスは残りのノードまたはゾーン上で動作し続け、サービスのスループットが低下することがあります。

注 –

各アプリケーションインスタンスの TCP 状態は、広域インタフェースノードではなく、インスタンスを持つノードで維持されます。したがって、広域インタフェースノードに障害が発生しても接続には影響しません。

図 3–7 に、フェイルオーバーリソースグループとスケーラブルリソースグループの例と、スケーラブルサービスにとってそれらの間にどのような依存関係があるのかを示します。この例は、3 つのリソースグループを示しています。フェイルオーバーリソースグループには、可用性の高い DNS のアプリケーションリソースと、可用性の高い DNS および可用性の高い Apache Web Server (SPARC ベースのクラスタに限って使用可能) の両方から使用されるネットワークリソースが含まれます。スケーラブルリソースグループには、Apache Web Server のアプリケーションインスタンスだけが含まれます。リソースグループの依存関係は、スケーラブルリソースグループとフェイルオーバーリソースグループの間に存在します (実線)。また、Apache アプリケーションリソースはすべて、共有アドレスであるネットワークリソース schost-2 に依存します (破線)。

図 3–7 SPARC: フェイルオーバーリソースグループとスケーラブルリソースグループの例

図 : この図については、前の本文中で説明しています。

負荷均衡ポリシー

負荷均衡は、スケーラブルサービスのパフォーマンスを応答時間とスループットの両方の点で向上させます。スケーラブルデータサービスには 2 つのクラスがあります。

pure サービスでは、任意のインスタンスがクライアント要求に応答できます。sticky サービスでは、クライアントは同じインスタンスに応答を送信できます。これらの要求は、別のインスタンスには変更されません。

pure サービスは、ウェイト設定した (weighted) 負荷均衡ポリシーを使用します。この負荷均衡ポリシーのもとでは、クライアント要求は、デフォルトで、クラスタ内のサーバーインスタンスに一律に分配されます。負荷は指定されたウェイト値に従って各種のノードに分配されます。たとえば、3 ノードクラスタにおいて、各ノードのウェイトが 1 だとします。各ノードは、そのサービスに対する任意のクライアントからの要求を 1/3 ずつを負担します。クラスタ管理者は、管理コマンドまたは Sun Cluster Manager によって、いつでもウェイト値を変更できます。

ウェイト設定した負荷分散ポリシーは、Load_balancing_weights プロパティーに設定された LB_WEIGHTED 値を使用して設定されます。ウェイトがノードについて明示的に設定されていない場合は、デフォルトで 1 が設定されます。

ウェイト設定したポリシーは、一定の割合のクライアントトラフィックを特定ノードに送るためのものです。たとえば、X=「ウエイト」、A=「すべてのアクティブノードの合計ウエイト」であるとします。アクティブノードは、新しい接続数の合計の約 X/A がこのアクティブノード宛てに送られると予測できます。ただし、接続数の合計は十分に大きな数である必要があります。このポリシーは、個々の要求には対応しません。

このウェイト設定したポリシーは、ラウンドロビンではないことに注意してください。ラウンドロビンポリシーでは、常に、同じクライアントからの要求はそれぞれ異なるノードに送られます。たとえば、1 番目の要求はノード 1 に、2 番目の要求はノード 2 に送られます。

sticky サービスには「ordinary sticky」と「wildcard sticky」の 2 種類があります。

sticky サービスを使用すると、内部状態メモリーを共有でき (アプリケーションセッション状態)、複数の TCP 接続でアプリケーションレベルの同時セッションが可能です。

ordinary sticky サービスを使用すると、クライアントは、複数の同時 TCP 接続で状態を共有できます。このクライアントを、単一ポートで待機するサーバーインスタンスに対して 「sticky」であるといいます。

次の条件を満たす場合、このクライアントはすべての要求が同じサーバーインスタンスに送られることが保証されます。

たとえば、クライアント上の Web ブラウザは、3 つの異なるTCP 接続を使用して、ポート 80 にある共有 IP アドレスに接続します。そして、これらの接続はサービスでキャッシュされたセッション情報をお互いに交換します。

sticky ポリシーを一般化すると、そのポリシーは同じインスタンスの背後でセッション情報を交換する複数のスケーラブルサービスにまで及びます。これらのサービスが同じインスタンスの背後でセッション情報を交換するとき、同じノードで異なるポートと通信する複数のサーバーインスタンスに対して、そのクライアントは「sticky」であるといいます

たとえば、電子商取引 Web サイトの顧客はポート 80 の HTTP を使用して買い物をします。そして、購入した製品をクレジットカードで支払うときには、ポート 443 の SSL に切り替えて機密データを送ります。

通常の sticky ポリシーでは、ポートの集合が、アプリケーションリソースの構成時に認識されます。このポリシーは、Load_balancing_policy リソースプロパティーの LB_STICKY の値を使用して設定されます。

Wildcard sticky サービスは、動的に割り当てられたポート番号を使用しますが、クライアント要求が同じノードに送りかえされると想定します。クライアントは、同じ IPアドレスを持っているポートに対して「sticky wildcard」であるといいます。

このポリシーの例としては、受動モード FTP があります。たとえば、クライアントはポート 21 の FTP サーバーに接続します。次に、サーバーは、動的ポート範囲のリスナーポートサーバーに接続し直すようにクライアントに指示します。この IP アドレスに対する要求はすべて、サーバーが制御情報によってクライアントに通知した、同じノードに転送されます。

sticky-wildcard ポリシーは、通常の「sticky」ポリシーの上位セットです。IP アドレスによって識別されるスケーラブルサービスでは、ポートはサーバーによって割り当てられます。したがって、事前に認識できません。ポートは変更されることがあります。このポリシーは、Load_balancing_policy リソースプロパティーの LB_STICKY_WILD の値を使用して設定されます。

このような各 sticky ポリシーでは、ウェイト設定した負荷均衡ポリシーがデフォルトで有効です。したがって、クライアントの最初の要求は、負荷均衡によって指定されたインスタンス宛てに送られます。インスタンスが動作しているノードとのアフィニティーをクライアントが確立すると、今後の要求はそのインスタンス宛てに送られます。ただし、そのノードはアクセス可能であり、負荷均衡ポリシーが変更されていない必要があります。

フェイルバック設定

リソースグループは、ノードまたはゾーンから別のノードまたはゾーンへ処理を継続します。このようなフェイルオーバーが発生すると、二次ノードが新しい主ノードになります。フェイルバック設定は、本来の主ノードがオンラインに戻ったときの動作を指定します。つまり、本来の主ノードを再び主ノードにする (フェイルバックする) か、現在の主ノードをそのままにするかです。これを指定するには、Failback リソースグループプロパティー設定を使用します。

リソースグループをホストしていた本来の主ノードまたはゾーンに障害が発生し、繰り返し再起動する場合は、フェイルバックを設定することよって、リソースグループの可用性が低くなる可能性もあります。

データサービス障害モニター

Sun Cluster の各データサービスには、データサービスを定期的に検査してその状態を判断するフォルトモニターがあります。障害モニターは、1 つまたは複数のアプリケーションデーモンが実行しているか、クライアントがサービスを受けているかどうかを検証します。探索によって得られた情報をもとに、デーモンの再起動やフェイルオーバーの実行などの事前に定義された処置が開始されます。

新しいデータサービスの開発

Sun が提供する構成ファイルや管理メソッドのテンプレートを使用することで、さまざまなアプリケーションをクラスタ内でフェイルオーバーサービスやスケーラブルサービスとして実行できます。フェイルオーバーサービスやスケーラブルサービスとして実行するアプリケーションが Sun から提供されていない場合は、代わりの方法があります。つまり、Sun Cluster API や DSET API を使用して、フェイルオーバーサービスやスケーラブルサービスとして動作するようにアプリケーションを構成します。しかし、必ずしもすべてのアプリケーションがスケーラブルサービスになるわけではありません。

スケーラブルサービスの特徴

アプリケーションがスケーラブルサービスになれるかどうかを判断するには、いくつかの基準があります。アプリケーションがスケーラブルサービスになれるかどうかを判断する方法については、『Sun Cluster データサービス開発ガイド (Solaris OS 版)』の「アプリケーションの適合性の分析」を参照してください。

次に、これらの基準の要約を示します。

データサービス API と DSDL API

Sun Cluster ソフトウェアには、アプリケーションの可用性を高めるものとして次の機能があります。

Sun Cluster ソフトウェアが提供するデータサービスをインストールおよび構成する方法については、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』を参照してください。Sun Cluster フレームワークでアプリケーションの可用性を高める方法については、Sun Cluster 3.1 9/04 Software Collection for Solaris OS (SPARC Platform Edition)を参照してください。

アプリケーション開発者は、Sun Cluster API を使用することによって、データサービスインスタンスの起動や停止を行なう障害モニターやスクリプトを開発できます。これらのツールを使用すると、アプリケーションをフェイルオーバーまたはスケーラブルデータサービスとして実装できます。Sun Cluster ソフトウェアは「汎用」のデータサービスを提供します。この汎用のデータサービスを使用すれば、簡単に、アプリケーションに必要な起動メソッドと停止メソッドを生成して、データサービスをフェイルオーバーサービスまたはスケーラブルサービスとして実装できます。

クラスタインターコネクトによるデータサービストラフィックの送受信

クラスタには、ノード間を結ぶ複数のネットワーク接続が必要です。クラスタインターコネクトは、これらの接続から構成されています。

Sun Cluster ソフトウェアは、複数のインターコネクトを使用して、次の目標を達成します。

内部と外部の両方のトラフィック (ファイルシステムのデータやスケーラブルサービスのデータなど) の場合、メッセージはすべての利用できるインターコネクト間で転送されます。クラスタインターコネクトは、ノード間の通信の可用性を高めるためにアプリケーションから使用することもできます。たとえば、分散アプリケーションでは、個々のコンポーネントが異なるノードで動作することがあり、その場合には、ノード間の通信が必要になります。パブリック伝送の代わりにクラスタインターコネクトを使用することで、個別のリンクに障害が発生しても、接続を持続することができます。

ノードまたはゾーン間の通信にクラスタインターコネクトを使用するには、Sun Cluster のインストール時に設定したプライベートホスト名をアプリケーションで使用する必要があります。たとえば、node1 のプライベートホスト名が clusternode1-priv である場合、クラスタインターコネクトを経由して node1 と通信するときにこの名前を使用する必要があります。この名前を使用してオープンされた TCP ソケットは、クラスタインターコネクトを経由するように経路指定され、プライベートネットワークアダプタに障害が発生した場合でも、この TCP ソケットは透過的に再経路指定されます。任意の 2 つのノード間のアプリケーション通信はすべてのインターコネクト経由で転送されます。ある特定の TCP 接続のトラフィックは、ある特定の時点では、1 つのインターコネクト上を流れます。異なる TCP 接続はすべてのインターコネクト間で転送されます。さらに、UDP トラフィックは常に、すべてのインターコネクト間で利用されます。

アプリケーションでは、ゾーンのプライベートホスト名を使用し、ゾーン間でクラスタインターコネクトを経由して通信することもできます。ただし、各ゾーンのプライベートホスト名をまず設定しないと、アプリケーションは通信を開始することができません。各ゾーンに、通信するための独自のプライベートホスト名があります。あるゾーンで動作中のアプリケーションは、同じゾーン内のプライベートホスト名を使用して、他ゾーン内のプライベートホスト名と通信します。1 つのゾーン内の各アプリケーションは、別のゾーン内のプライベートホスト名を使って通信することはできません。

Sun Cluster のインストール時に複数のプライベートホスト名が設定されているため、クラスタインターコネクトでは、そのときに選択した任意の名前を使用できます。実際の名前を判別するために scha_cluster_get コマンドを scha_privatelink_hostname_node 引数と組み合わせて使用します。詳細は、scha_cluster_get(1HA) のマニュアルページを参照してください。

各ノードまたはゾーンには、固定した per-node アドレスが割り当てられます。この per-node アドレスは、clprivnet ドライブで探索されます。IP アドレスは、ノードまたはゾーンのプライベートホスト名にマッピングされます。つまり、clusternode1-priv です。詳細は、clprivnet(7) のマニュアルページを参照してください。

アプリケーション全体で一貫した IP アドレスが必要な場合、クライアント側とサーバー側の両方でこの per-node アドレスにバインドするようにアプリケーションを設定します。これによって、すべての接続はこの per-node アドレスから始まり、そして戻されるように見えます。

リソース、リソースグループ、リソースタイプ

データサービスは、複数の「リソース」タイプを利用します。Sun Java System Web Server や Apache Web Server などのアプリケーションは、それらのアプリケーションが依存するネットワークアドレス (論理ホスト名と共有アドレス) を使用します。アプリケーションとネットワークリソースは RGM が管理する基本単位です。

データサービスはリソースタイプです。たとえば、Sun Cluster HA for Oracle のリソースタイプは SUNW.oracle-server、Sun Cluster HA for Apache のリソースタイプ SUNW.apache です。

リソースはリソースタイプをインスタンス化したもので、クラスタ規模で定義されます。いくつかのリソースタイプはすでに定義されています。

ネットワークリソースは、SUNW.LogicalHostname リソースタイプまたは SUNW.SharedAddress リソースタイプのどちらかです。これら 2 つのリソースタイプは、Sun Cluster ソフトウェアにより事前に登録されています。

HAStoragePlus リソースタイプは、リソースとそのリソースが依存するディスクデバイスグループの起動を同期させるのにも使用できます。このリソースタイプによって、クラスタファイルシステムのマウントポイント、広域デバイス、およびデバイスグループ名のパスがデータサービスの起動前に利用可能になることが保証されます。詳細については、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の「リソースグループとデバイスグループ間での起動の同期」を参照してください。HAStoragePlus リソースタイプはまた、ローカルのファイルシステムを高可用対応にすることができます。この機能についての詳細は、「HAStoragePlus リソースタイプ」を参照してください。

RGM が管理するリソースは、1 つのユニットとして管理できるように、「リソースグループ」と呼ばれるグループに配置されます。リソースグループ上でフェイルオーバーまたはスイッチオーバーが開始されると、リソースグループは 1 つのユニットとして移行されます。

注 –

アプリケーションリソースが含まれるリソースグループをオンラインにすると、そのアプリケーションが起動します。データサービスの起動メソッドは、アプリケーションが起動され、実行されるのを待ってから、正常に終了します。アプリケーションの起動と実行のタイミングの確認は、データサービスがクライアントにサービスを提供しているかどうかをデータサービスの障害モニターが確認する方法と同じです。このプロセスについての詳細は、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』を参照してください。

リソースグループマネージャー (RGM)

RGM は、データサービス (アプリケーション) を、リソースタイプの実装によって管理されるリソースとして制御します。これらの実装は、Sun が行う場合もあれば、開発者が汎用データサービステンプレート、データサービス開発ライブラリ API (DSDL API)、またはリソース管理 API (RMAPI) を使用して作成することもあります。クラスタ管理者は、「リソースグループ」と呼ばれる入れ物 (コンテナ) の中でリソースの作成や管理を行います。RGM は、クラスタメンバーシップの変更に応じて、指定ノードまたは指定ゾーンのリソースグループを停止および開始します。

RGM は「リソース」と「リソースグループ」に作用します。RGM のアクションによって、リソースやリソースグループの状態はオンラインまたはオフラインに切り替えれらます。リソースとリソースグループに適用できる状態と設定値についての詳細は、「リソースおよびリソースグループの状態と設定値」を参照してください。

RGM 制御下で Solaris プロジェクトを起動する方法については、「データサービスプロジェクトの構成」を参照してください。

リソースおよびリソースグループの状態と設定値

リソースやリソースグループの値はシステム管理者によって静的に設定されるため、これらの設定は管理操作によってのみ変更できます。RGM は、動的な「状態」の間でリソースグループを移動させます。

これらの設定および状態は次のとおりです。

リソースとリソースグループプロパティー

Sun Cluster データサービスのリソースやリソースグループのプロパティー値は構成できます。標準的なプロパティーはすべてのデータサービスに共通です。拡張プロパティーは各データサービスに特定のものです。標準プロパティーおよび拡張プロパティーのいくつかは、デフォルト設定によって構成されているため、これらを修正する必要はありません。それ以外のプロパティーは、リソースを作成して構成するプロセスの一部として設定する必要があります。各データサービスのマニュアルでは、設定できるリソースプロパティーの種類とその設定方法を指定しています。

標準プロパティーは、通常特定のデータサービスに依存しないリソースおよびリソースグループプロパティーを構成するために使用されます。標準プロパティーのセットについては、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の付録 B「標準プロパティー」 を参照してください。

RGM 拡張プロパティーは、アプリケーションバイナリの場所や構成ファイルなどの情報を提供するものです。拡張プロパティーは、データサービスの構成に従って 修正する必要があります。拡張プロパティーについては、データサービスの個別のガイドで説明されています。

Sun Cluster ノードでの Solaris ゾーンのサポート

Solaris ゾーンは、Solaris 10 OS のインスタンス内で仮想化されたオペレーティングシステム環境を作成する手段を提供します。Solaris ゾーンを使用すると、1 つまたは複数のアプリケーションをシステム上の他の活動から分離して実行できます。Solaris ゾーンの機能については、『Solaris のシステム管理 (Solaris コンテナ : 資源管理と Solaris ゾーン)』のパート II「ゾーン」を参照してください。

Solaris 10 OS 上で Sun Cluster ソフトウェアを実行する場合は、1 つの物理ノード上で任意の数のゾーンを作成できます。

Sun Cluster ソフトウェアを使用して、クラスタノードの Solaris 非大域ゾーンで動作するアプリケーションの可用性とスケーラビリティーを管理できます。Sun Cluster ソフトウェアは、次の方法により非大域ゾーンで動作するアプリケーションのサポートを提供します。

Sun Cluster ノード上の Solaris ゾーンを RGM を使用して直接サポート

Solaris 10 OS が動作するクラスタでは、リソースグループを大域ゾーンまたは非大域ゾーンで動作するように設定できます。RGM は、各ゾーンをスイッチオーバーターゲットとして管理します。リソースグループのノードリストで非大域ゾーンが指定されている場合、RGM はノードの指定されたゾーンでリソースグループをオンラインにします。

図 3–8 は、2 つのノードクラスタの Sun Cluster ノード上のゾーン間のリソースグループのフェイルオーバーを示しています。この例では、クラスタの管理を簡単にするために各ノードで同一のゾーンが構成されています。

図 3–8 Sun Cluster ノード上のゾーン間のリソースグループのフェイルオーバー

ゾーン間のリソースグループのフェイルオーバーを示す図

フェイルオーバーリソースグループは、別のノード上または同じノード上のゾーンへのフェイルオーバーを実行できます。ただし、ノードで障害が発生すると、同一ノード上のゾーンに対するこのリソースグループのフェイルオーバーから高可用性は得られません。とはいえ、同一ノード上のゾーンに対するリソースグループのフェイルオーバーは、テストまたはプロトタイプ化の際に便利な場合もあります。

スケーラブルなリソースグループ (ネットワーク負荷分散を使用) を、非大域ゾーンでも動作するよう構成することができます。ただし、スケーラブルなリソースグループを同一ノード上の複数のゾーンで実行するように構成しないでください。

Sun Cluster コマンドで、次の例に示すように、ゾーンの名前を物理ノードの名前に追加し、それらをコロンで区切ることによって、ゾーンを指定します。

phys-schost-1:zoneA

次の例のような複数の Sun Cluster コマンドでゾーンを指定できます。

RGM によるSolaris ゾーンの直接サポートを使用するための基準

次のいずれかの基準を満たす場合、RGM による Solaris ゾーンの直接サポートを使用します。

RGM によるSolaris ゾーンの直接サポートを使用するための要件

アプリケーションで RGM による Solaris ゾーンの直接サポートの使用を計画している場合は、次の要件を満たしていることを確認してください。

RGM による Solaris ゾーンの直接サポートを使用する場合、リソースおよびリソースグループを次のように構成します。

RGM によるSolaris ゾーンの直接サポートに関するその他の情報

RGM によるSolaris ゾーンの直接サポートの構成方法の詳細については、次のドキュメントを参照してください。

Sun Cluster ノード上の Solaris ゾーンを Sun Cluster HA for Solaris Containers を通してサポート

Sun Cluster HA for Solaris Containers データサービスは、各ゾーンを RGM によって制御されるリソースとして管理します。

Sun Cluster HA for Solaris Containers を使用するための基準

次のいずれかの基準を満たす場合、Sun Cluster HA for Solaris Containers データサービスを使用します。

Sun Cluster HA for Solaris Containers を使用するための要件

アプリケーションで Sun Cluster HA for Solaris Containers データサービスの利用を計画している場合、次の要件を満たすことを確認してください。

Sun Cluster HA for Solaris Containers についてのその他の情報

Sun Cluster HA for Solaris Containers データサービスの使い方の詳細については、『Sun Cluster Data Service for Solaris Containers Guide』 を参照してください。

サービス管理機能

Solaris サービス管理機能 (SMF) によって、アプリケーションを可用性が高く、スケーラブルなリソースとして実行して管理することができます。リソースグループマネージャー (RGM) と同じように、SMF は高可用性とスケーラビリティーを提供しますが、Solaris オペレーティングシステム用です。

Sun Cluster は、クラスタで SMF サービスを有効にするために使用する 3 種類のプロキシリソースタイプを提供します。これらのリソースタイプ、 SUNW.Proxy_SMF_failover、 SUNW.Proxy_SMF_loadbalanced、および SUNW.Proxy_SMF_multimaster により、フェイルオーバー、スケーラブル、およびマルチマスターのそれぞれの構成で、SMF サービスを実行できます。SMF は単一ノード上で SMF サービスの可用性を管理します。SMF はコールバックメソッド実行モデルを使用して、サービスを実行します。

さらに、SMF はサービスの監視と制御のための管理インタフェースのセットも提供します。これらのインタフェースにより、ユーザー独自の SMF 制御サービスを Sun Cluster に組み込むことができます。この機能により新たなコールバックメソッドを作成したり、既存のコールバックメソッドを書き直したり、あるいは SMF サービスマニフェストを更新する必要がなくなります。複数の SMF リソースを 1 つのリソースグループに含め、それらのリソース間に依存性とアフィニティーを構成することができます。

SMF はこれらのサービスを開始、停止、および再開する権限を持ち、サービス間の依存性を管理します。Sun Cluster は、クラスタ内でこれらのサービスを管理し、これらのサービスを開始するノードを決める権限を持ちます。

SMF は、各クラスタノード上でデーモン svc.startd として動作します。SMF デーモンは、あらかじめ設定されたポリシーに基づいて、選択したノード上で自動的にリソースを開始および停止します。

SMF プロキシリソースに指定されたサービスは、大域ゾーンおよび非大域ゾーンに常駐できます。ただし、同じSMF プロキシリソースに指定したサービスは、同じゾーンに置く必要があります。SMF プロキシリソースはどのゾーンでも動作します。

システムリソースの使用率

システムリソースには、CPU 使用率、メモリ使用率、スワップ使用率、ディスクおよびネットワークのスループットが含まれます。Sun Cluster では、オブジェクトタイプ別にシステムリソースの使用率を監視できます。オブジェクトタイプには、ノード、ゾーン、ディスク、ネットワークインタフェース、またはリソースグループがあります。Sun Cluster ではまた、リソースグループで使用できる CPU を制御することもできます。

システムリソース使用量の監視と制御をリソース管理ポリシーの一部にすることができます。多数のマシンの管理は複雑でコストがかかるため、より大規模なサーバーにアプリケーションを統合することが望まれます。個々の作業負荷を別々のシステムで実行して、そのシステムのリソースへのフルアクセスを与える代わりに、リソース管理ソフトウェアを使用すれば、システム内の作業負荷を分離できます。リソース管理機能を使用すると、1 つの Solaris システムで複数の異なるアプリケーションを実行して制御することにより、システムの総保有コスト (TCO) を低減することができます。

リソース管理機能を使用して、アプリケーションが必要な応答時間を確保できるようにします。また、リソース管理機能により、リソースの使用率を向上させることができます。使用状況を分類して優先付けすることにより、オフピーク時に余ったリソースを効率よく使用でき、処理能力を追加する必要がなくなります。また、負荷の変動が原因で資源を無駄にすることもなくなります。

Sun Cluster がシステムリソースの使用率について収集するデータを活用するには、次の手順を実行する必要があります。

Sun Cluster のインストール時にデフォルトでは、システムリソースの監視と制御は構成されていません。これらのサービスの構成の詳細については、『Sun Cluster のシステム管理 (Solaris OS 版)』の第 9 章「CPU 使用率の制御の構成」を参照してください。

システムリソース監視

システムリソースの使用率を監視することにより、次のことができます。

システムリソースの使用率に関するデータにより、あまり使用されていないハードウェアリソースや多くのリソースを使用するアプリケーションを判別することができます。このデータに基づいて、アプリケーションを必要なリソースがあるノードやゾーンに割り当て、フェイルオーバーするノードやゾーンを選択することができます。この統合により、ハードウェアリソースとソフトウェアリソースの使用方法を最適化できます。

すべてのシステムリソースを同時に監視することは、CPU の負担になる場合があります。システムに最も重要なリソースに優先順位を付けて、監視するシステムリソースを選択してください。

監視を有効にするときに、監視するテレメトリ属性を選択します。テレメトリ属性はシステムリソースの一面です。テレメトリ属性の例としては、CPU の量またはデバイスで使用されているブロックの使用率などがあります。あるオブジェクトタイプについてテレメトリ属性を監視する場合、Sun Cluster はクラスタ内のそのタイプのすべてのオブジェクトでこのテレメトリ属性を監視します。Sun Cluster は収集されるシステムリソースデータを 7 日間保存します。

特定のデータ値がシステムリソースに重要だと考えられる場合、この値にしきい値を設定できます。しきい値を設定するときに、重要度レベルを割り当てることによって、このしきい値がどれくらい重要かを選択することもできます。このしきい値を超えると、Sun Cluster はこのしきい値の重要度レベルをユーザーが選択する重要度レベルに変更します。

CPU の制御

クラスタ上で動作するアプリケーションおよびサービスウィンドウごとに特定の CPU ニーズがあります。表 3–4 は、Solaris OS の各バージョンで使用できる CPU 制御動作を示しています。

表 3–4 CPU 制御

Solaris のバージョン 

ゾーン 

制御 

Solaris 9 OS 

使用不可 

CPU シェアの割り当て 

Solaris 10 OS 

大域ゾーン 

CPU シェアの割り当て 

Solaris 10 OS 

非大域ゾーン 

CPU シェアの割り当て 

CPU 数の割り当て 

専用のプロセッサセットの作成 

注 –

CPU シェアを提供する場合、クラスタ内でフェアシェアスケジューラ (FFS) をデフォルトのスケジューラとして指定する必要があります。

非大域ゾーンで専用プロセッサセットのリソースグループに割り当てられている CPU を制御することにより、もっとも厳格なレベルの制御が実現されます。あるリソースグループに CPU を予約すると、この CPU は他のリソースグループでは使用できません。

システムリソース使用率の表示

コマンドラインまたは Sun Cluster Manager を使用して、システムリソースデータおよび CPU 割り当てを表示できます。監視を選択するシステムリソースによって、表示できる表とグラフが決まります。

システムリソース使用率と CPU 制御の出力を表示することにより、次を実現することができます。

Sun Cluster では、収集したデータに基づいて取るべき措置をアドバイスしたり、ユーザーの代わりに措置を実行することはありません。表示されるデータがサービスに期待する条件を満たしているかどうかを判断する必要があります。そのあとで、確認されたパフォーマンスの救済措置を取る必要があります。

データサービスプロジェクトの構成

データサービスは、RGM でオンラインにしたときに Solaris プロジェクト名のもとで起動するように構成できます。そのためには、データサービスを構成するときに、RGM によって管理されるリソースまたはリソースグループと Solaris プロジェクト ID を対応付ける必要があります。リソースまたはリソースグループにプロジェクト ID を対応付けることによって、Solaris オペレーティングシステムの洗練されたコントロールを使用して、クラスタ内の負荷や使用量を管理できます。

注 –

Solaris 9 OS または Solaris 10 OS 上で Sun Cluster を使用する場合、この構成を実行できます。

Sun Cluster 環境の Solaris 管理機能を使用すると、ほかのアプリケーションとノードまたはゾーンを共有している場合に、最も重要なアプリケーションに高い優先順位を与えることができます。ノードまたはゾーンを複数のアプリケーションで共有する例としては、サービスを統合した場合や、アプリケーションのフェイルオーバーが起った場合があります。ここで述べる管理機能を使用すれば、優先順位の低いアプリケーションが CPU 時間などのシステムサプライを過度に使用するのを防止し、重要なアプリケーションの可用性を向上させることができます。

注 –

この機能に関連する Solaris のマニュアルでは、CPU 時間、プロセス、タスクなどのコンポーネントを「リソース」と呼んでいます。一方、Sun Cluster のマニュアルでは、RGM の制御下にあるエンティティーを「リソース」と呼んでいます。次の節では、「リソース」という用語をRGM で制御される Sun Cluster エンティティーを指す用語として使用します。また、CPU 時間、プロセス、およびタスクを「サプライ」と呼びます。

この節では、指定した Solaris OS の project(4) でプロセスを起動するように、データサービスを構成する方法の概念について説明します。また、Solaris オペレーティングシステムの管理機能を使用するための、フェイルオーバーのシナリオやヒントについても説明します。

管理機能の概念や手順についての詳細は、『Solaris のシステム管理 (ネットワークサービス)』の第 1 章「ネットワークサービス (概要)」を参照してください。

    クラスタ内で Solaris 管理機能を使用できるようにリソースやリソースグループを構成するための手順は次のようになります。

  1. アプリケーションをリソースの一部として構成します。

  2. リソースをリソースグループの一部として構成します。

  3. リソースグループのリソースを有効にします。

  4. リソースグループを管理状態にします。

  5. リソースグループに対する Solaris プロジェクトを作成します。

  6. 手順 5 で作成したプロジェクトにリソースグループ名を対応付けるための標準プロパティーを構成します。

  7. リソースグループをオンラインにします。

Solaris プロジェクト ID をリソースやリソースグループに関連付けるように標準の Resource_project_name または RG_project_name プロパティーを構成するには、clresource set および clresourcegroup set コマンドとともに -p オプションを使用します。続いて、プロパティーの値にリソースまたはリソースグループを設定します。プロパティーの定義については、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』の付録 B「標準プロパティー」 を参照してください。プロパティーの説明については、r_properties(5) および rg_properties(5) のマニュアルページを参照してください。

指定するプロジェクト名はプロジェクトデータベース (/etc/project) に存在するものでなければなりません。さらに、指定するプロジェクトのメンバーとして root ユーザーが設定されていなければなりません。プロジェクト名データベースの概念については、『Solaris のシステム管理 (Solaris コンテナ : 資源管理と Solaris ゾーン)』の第 2 章「プロジェクトとタスク (概要)」 を参照してください。プロジェクトファイルの構文については、project(4) を参照してください。

RGM は、リソースまたはリソースグループをオンラインにする際に、関連するプロセスをこのプロジェクト名の下で起動します。

注 –

リソースまたはリソースグループとプロジェクトを対応付けることはいつでもできます。ただし、RGM を使ってプロジェクトのリソースやリソースグループをオフラインにしてから再びオンラインに戻すまで、新しいプロジェクト名は有効になりません。

リソースやリソースグループをプロジェクト名の下で起動すれば、次の機能を構成することによってクラスタ全体のシステムサプライを管理できます。

プロジェクト構成に応じた要件の決定

Sun Cluster 環境で Solaris が提供する制御を使用するようにデータサービスを構成するには、まず、スイッチオーバーやフェイルオーバー時にリソースをどのように制御および管理するかを決めておく必要があります。新しいプロジェクトを構成する前に、まず、クラスタ内の依存関係を明確にします。たとえば、リソースやリソースグループはデバイスグループに依存しています。

リソースグループのノードリストの優先順位を識別するには、clresourcegroup set コマンドで構成する nodelist、failback、maximum_primaries および desired_primaries リソースグループのプロパティーを使用します。

デバイスグループのノードリストの優先順位を決めるには、cldevicegroup および clsetup コマンドで構成する preferenced プロパティーおよび failback プロパティーを使用します。詳細は、clresourcegroup(1CL)、cldevicegroup(1CL)、および clsetup(1CL) のマニュアルページを参照してください。

すべてのクラスタノードまたはゾーンを同じように構成すると、主ノードと二次ノードに対して同じ使用限度が割り当てられます。各プロジェクトの構成パラメータは、すべてのノードの構成ファイルに定義されているすべてのアプリケーションに対して同じである必要はありません。特定のアプリケーションに対応するすべてのプロジェクトは、少な くとも、そのアプリケーションのすべての潜在的マスターにあるプロジェクトデータベースからアクセス可能である必要があります。アプリケーション 1 が phys-schost-1 または phys-schost-1 上のゾーンによってマスターされているが、phys-schost-2、phys-schost-3 またはこれらいずれかのノード上のゾーンに切り替えられるか、フェイルオーバーされる可能性があると仮定します。アプリケーション 1 に対応付けられたプロジェクトは、これら 3 つのノード (phys-schost-1、phys-schost-2、phys-schost-3) またはこれらのノード上のゾーンでアクセス可能でなければなりません。

注 –

プロジェクトデータベース情報は、ローカルの /etc/project データベースファイルに格納することも、NIS マップや LDAP ディレクトリサーバー に格納することもできます。

Solaris オペレーティングシステムでは、使用パラメータは柔軟に構成でき、Sun Cluster によって課せられる制約はほとんどありません。どのような構成を選択するかはサイトの必要性によって異なります。システムの構成を始める前に、次の各項の一般的な指針を参考にしてください。

プロセス当たりの仮想メモリー制限の設定

仮想メモリーの制限をプロセス単位で制御する場合は、process.max-address-space コントロールを使用します。process.max-address-space 値の設定方法についての詳細は、rctladm(1M) のマニュアルページを参照してください。

Sun Cluster ソフトウェアで管理コントロールを使用する場合は、アプリケーションの不要なフェイルオーバーが発生したり、アプリケーションの「ピンポン」現象が発生したりするのを防止するために、メモリー制限を適切に設定する必要があります。そのためには、一般に次の点に注意する必要があります。

フェイルオーバーシナリオ

管理パラメータを適切に構成すれば、プロジェクト構成 (/etc/project) 内の割り当ては、通常のクラスタ操作でも、スイッチオーバーやフェイルオーバーの状況でも正常に機能します。

以下の各項ではシナリオ例を説明します。

Sun Cluster 環境では、アプリケーションはリソースの一部として構成します。そして、リソースをリソースグループ (RG) の一部として構成します。障害が発生すると、リソースグループは、対応付けられたアプリケーションとともに、別のノードまたはゾーンにフェイルオーバーされます。次の例では、リソースは明示的に示されていません。各リソースには、1 つのアプリケーションが構成されているものとします。

注 –

フェイルオーバーは、ノードまたはゾーンがノードリストで指定され、RGM で設定された順序で行なわれます。

以下の例は次のように構成されています。

フェイルオーバーが起こると、各アプリケーションに割り当てられる CPU 時間の割合が変化します。ただし、割り当てられているシェアの数はそのままです。この割合は、そのノードまたはゾーンで動作しているアプリケーションの数と、アクティブな各アプリケーションに割り当てられているシェアの数によって異なります。

これらのシナリオでは、次のように構成が行われているものとします。

2 つのアプリケーションを供う 2 ノードクラスタ

2 ノードクラスタに 2 つのアプリケーションを構成することによって、それぞれの物理ホスト (phys-schost-1、 phys-schost-2) を 1 つのアプリケーションのデフォルトマスターにすることができます。一方の物理ホストは、他方の物理ホストの二次ノードになります。アプリケーション 1 とアプリケーション 2 に関連付けられているすべてのプロジェクトは、両ノードのプロジェクトデータベースファイルに存在している必要があります。クラスタが正常に動作している間、各アプリケーションはそれぞれのデフォルトマスターで動作し、管理機能によってすべての CPU 時間を割り当てられます。

フェイルオーバーかスイッチオーバーが起ると、これらのアプリケーションは同じノードで動作し、構成ファイルの設定に従ってシェアを割り当てられます。たとえば、/etc/project ファイルに次のエントリが指定されていると、アプリケーション 1 に 4 シェアが、アプリケーション 2 に 1 シェアがそれぞれ割り当てられます。

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

次の図は、この構成の正常時の動作とフェイルオーバー時の動作を表しています。割り当てられているシェアの数は変わりません。ただし、各アプリケーションが利用できる CPU 時間の割合は変わる場合があります。この割合は、CPU 時間を要求する各プロセスに割り当てられているシェア数によって異なります。

図 : この図については、前の本文中で説明しています。

3 つのアプリケーションを供う 2 ノードクラスタ

3 つのアプリケーションが動作する 2 ノードクラスタでは、1 つの物理ホスト (phys-schost-1) を 1 つのアプリケーションのデフォルトマスターとして構成できます。そして、もう 1 つの物理ホスト (phys-schost-2) をほかの 2 つのアプリケーションのデフォルトマスターとして構成できます。各ノードには、次のサンプルプロジェクトデータベースファイルがあるものとします。フェイルオーバーやスイッチオーバーが起っても、プロジェクトデータベースファイルが変更されることはありません。

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none)
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)

クラスタが正常に動作している間、アプリケーション 1 には、そのデフォルトマスター phys-schost-1 で 5 シェアが割り当てられます。このノードで CPU 時間を要求するアプリケーションはこのアプリケーションだけであるため、この数は 100 パーセントの CPU 時間と同じことです。アプリケーション 2 と 3 には、それぞれのデフォルトマスターである phys-schost-2 で 3 シェアと 2 シェアが割り当てられます。したがって、正常な動作では、アプリケーション 2 に CPU 時間の 60 パーセントが、アプリケーション 3 に CPU 時間の 40 パーセントがそれぞれ割り当てられます。

フェイルオーバーかスイッチオーバーが発生し、アプリケーション 1 が phys-schost-2 に切り替えられても、3 つのアプリケーションの各シェアは変わりません。ただし、割り当てられる CPU リソースの割合はプロジェクトデータベースファイルに従って変更されます。

次の図は、この構成の正常な動作とフェイルオーバー動作を示しています。

図 : この図については、前の本文中で説明しています。

リソースグループだけのフェイルオーバー

複数のリソースグループが同じデフォルトマスターに属している構成では、1 つのリソースグループ (および、それに関連付けられたアプリケーション) が 二次ノードまたはゾーンにフェイルオーバーされたり、スイッチオーバーされることがあります。その間、クラスタのデフォルトマスターは動作を続けます。

注 –

フェイルオーバーの際、フェイルオーバーされるアプリケーションには、二次ノードまたはゾーン上の構成ファイルの指定に従ってリソースが割り当てられます。この例の場合、主ノードと二次ノードのプロジェクトデータベースファイルの構成は同じです。

次のサンプル構成ファイルでは、アプリケーション 1 に 1 シェア、アプリケーション 2 に 2 シェア、アプリケーション 3 に 2 シェアがそれぞれ割り当てられています。

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)

次の図は、この構成の正常時の動作とフェイルオーバー時の動作を表しています。ここでは、アプリケーション 2 が動作する RG-2 が phys-schost-2 にフェイルオーバーされます。割り当てられているシェアの数は変わりません。ただし、各アプリケーションが利用できる CPU 時間の割合は、CPU 時間を要求する各アプリケーションに割り当てられているシェア数によって異なります。

図 : この図については、前の本文中で説明しています。

パブリックネットワークアダプタと IP ネットワークマルチパス

クライアントは、パブリックネットワークを介してクラスタにデータ要求を行います。各クラスタノードは、1 対のパブリックネットワークアダプタを介して少なくとも 1 つのパブリックネットワークに接続されています。

Sun Cluster で動作する Solaris インターネットプロトコル (IP) ソフトウェアは、パブリックネットワークアダプタを監視したり、障害を検出したときに IP アドレスをあるアダプタから別のアダプタにフェイルオーバーしたりする基本的な機構を提供します。各クラスタノードは独自の IP ネットワークマルチパス 構成を持っており、この構成がほかのクラスタノードの構成と異なる場合があります。

パブリックネットワークアダプタは、IP マルチパスグループ (「マルチパスグループ」) として編成されます。各マルチパスグループには、1 つまたは複数のパブリックネットワークアダプタがあります。マルチパスグループの各アダプタはアクティブにしておいてもかまいません。あるいは、スタンバイインタフェースを構成し、フェイルオーバーが起こるまでそれらを非アクティブにしておいてもかまいません。

in.mpathd マルチパスデーモンは、テスト IP アドレスを使って障害や修復を検出します。マルチパスデーモンによってアダプタの 1 つに障害が発生したことが検出されると、フェイルオーバーが行われます。すべてのネットワークアクセスは、障害が発生したアダプタから、マルチパスグループ内の別の動作中のアダプタにフェイルオーバーされます。したがって、デーモンがそのノードのパブリックネットワーク接続を維持します。スタンバイインタフェースを構成していた場合、このデーモンはスタンバイインタフェースを選択します。そうでない場合、このデーモンは最も小さい IP アドレス番号を持つインタフェースを選択します。フェイルオーバーはアダプタインタフェースレベルで発生するため、これよりも高いレベルの接続 (TCP など) は影響を受けません。ただし、フェイルオーバー中には一時的にわずかな遅延が発生します。IP アドレスのフェイルオーバーが正常に終了すると、ARP ブロードキャストが送信されます。したがって、デーモンがリモートクライアントへの接続を維持します。

注 –

TCP の輻輳回復特性のために、正常なフェイルオーバーのあと、TCP エンドポイントではさらに遅延が生じる可能性があります。これは、フェイルオーバー中にいくつかのセグメントが失われて、TCP の輻輳制御機構がアクティブになるためです。

マルチパスグループには、論理ホスト名と共有アドレスリソースの構築ブロックがあります。論理ホスト名と共有アドレスリソースとは別にマルチパスグループを作成して、クラスタノードのパブリックネットワーク接続を監視する必要もあります。つまり、ノード上の同じマルチパスグループは、任意の数の論理ホスト名または共有アドレスリソースをホストできます。論理ホスト名と共有アドレスリソースについての詳細は、『Sun Cluster データサービスの計画と管理 (Solaris OS 版)』を参照してください。

注 –

IP ネットワークマルチパス 機構の設計は、アダプタの障害を検出してマスクすることを目的としています。この設計は、管理者が ifconfig を使用して論理 (または共有) IP アドレスのどれかを削除した状態から回復することを目的としているわけではありません。Sun Cluster ソフトウェアから見ると、論理アドレスや共有 IP アドレスは RGM によって管理されるリソースです。管理者が IP アドレスを追加または削除する場合、正しくは、clresource および clresourcegroup を使用してリソースを含むリソースグループを修正します。

IP ネットワークマルチパスの Solaris の実装についての詳細は、クラスタにインストールされている Solaris オペレーティングシステムのマニュアルを参照してください。

オペレーティングシステム 

参照先 

Solaris 9 オペレーティングシステム 

『IP ネットワークマルチパスの管理』の第 1 章「IP ネットワークマルチパス (概要)」

Solaris 10 オペレーティングシステム 

『Solaris のシステム管理 (IP サービス)』のパート VI「IPMP」

SPARC: 動的再構成のサポート

Sun Cluster 3.2 による動的再構成 (DR: Dynamic Reconfiguration) ソフトウェア機能のサポートは段階的に開発されています。この節では、Sun Cluster 3.2 による DR 機能のサポートの概念と考慮事項について説明します。

Solaris の DR 機能の説明で述べられているすべての必要条件、手順、制限は Sun Cluster の DR サポートにも適用されます (オペレーティング環境での休止状態中を除く)。したがって、Sun Cluster ソフトウェアで DR 機能を使用する前には、必ず、Solaris の DR 機能についての説明を参照してください。特に、DR の切り離し 操作中に、ネットワークに接続されていない入出力デバイスに影響する問題について確認してください。

『Sun Enterprise 10000 Dynamic Reconfiguration ユーザーマニュアル』と『Sun Enterprise 10000 Dynamic Reconfiguration リファレンスマニュアル』が、http://docs.sun.com で参照できます。

SPARC: 動的再構成の概要

DR 機能を使用すると、システムハードウェアの切り離しなどの操作をシステムの稼動中に行うことができます。DR プロセスの目的は、システムを停止したり、クラスタの可用性を中断したりせずにシステム操作を継続できるようにすることです。

DR はボードレベルで機能します。したがって、DR 操作はボード上のすべてのコンポーネントに影響します。ボードには、CPU やメモリー、ディスクドライブやテープドライブ、ネットワーク接続の周辺機器インタフェースなど、複数のコンポーネントが取り付けられています。

アクティブなコンポーネントを含むボードを切り離すと、システムエラーになります。DR サブシステムは、ボードを切り離す前に、他のサブシステム (Sun Cluster など) に問い合わせてボード上のコンポーネントが使用されているかを判別します。ボードが使用中であることがわかると、DR のボード切り離し操作は行われません。つまり、アクティブなコンポーネントを含むボードに DR のボード切り離し操作を発行しても、DR サブシステムがその操作を拒否するため、DR のボード切り離し操作はいつ発行しても安全です。

同様に、DR のボード追加操作も常に安全です。新たに追加されたボードの CPU とメモリーは、システムによって自動的にサービス状態になります。ただし、そのボードのほかのコンポーネントを意図的に使用するには、管理者がそのクラスタを手動で構成する必要があります。

注 –

DR サブシステムにはいくつかのレベルがあります。下位のレベルがエラーを報告すると、上位のレベルもエラーを報告します。ただし、下位のレベルが具体的なエラーを報告しても、上位のレベルは「Unknown error」を報告します。このエラーは無視してもかまいません。

次の各項では、デバイスタイプごとに DR の注意事項を説明します。

SPARC: CPU デバイスに対する DR クラスタリング

CPU デバイスが存在していても、Sun Cluster ソフトウェアは DR のボード切り離し操作を拒否しません。

DR のボード追加操作が正常に終わると、追加されたボードの CPU デバイスは自動的にシステム操作に組み込まれます。

SPARC: メモリーに対する DR クラスタリング

DR では、次の 2 種類のメモリーを考慮してください。

これらの違いはその使用方法だけであり、実際のハードウェアは同じものです。カーネルメモリーケージとは、Solaris オペレーティングシステムが使用するメモリーのことです。Sun Cluster ソフトウェアは、カーネルメモリーケージを含むボードに対するボード切り離し操作をサポートしていないため、このような操作を拒否します。DR のボード切り離し操作がカーネルメモリーケージ以外のメモリーに関連するものである場合、Sun Cluster ソフトウェア はこの操作を拒否しません。メモリーに関連する DR のボード追加操作が正常に終わると、追加されたボードのメモリーは自動的にシステム操作に組み込まれます。

SPARC: ディスクドライブとテープドライブに対する DR クラスタリング

Sun Cluster は、主ノードのアクティブなドライブに対する DR のボード切り離し操作を拒否します。DR のボード切り離し操作を実行できるのは、主ノードのアクティブでないドライブと、二次ノードの任意のドライブだけです。DR 操作が終了すると、クラスタのデータアクセスが前と同じように続けられます。

注 –

Sun Cluster は、定足数デバイスの使用に影響を与える DR 操作を拒否します。定足数デバイスの考慮事項と、定足数デバイスに対する DR 操作の実行手順については、「SPARC: 定足数デバイスに対する DR クラスタリング」を参照してください。

これらの操作の詳細な実行手順については、『Sun Cluster のシステム管理 (Solaris OS 版)』の「定足数デバイスへの動的再構成」を参照してください。

SPARC: 定足数デバイスに対する DR クラスタリング

DR のボード切り離し操作が、定足数デバイスとして構成されているデバイスへのインタフェースを含むボードに関連する場合Sun Cluster ソフトウェアはこの操作を拒否します。Sun Cluster ソフトウェアはまた、この操作によって影響を受ける定足数デバイスを特定します。定足数デバイスとしてのデバイスに対して DR のボード切り離し操作を行う場合は、まずそのデバイスを無効にする必要があります。

定足数の詳細な管理手順については、『Sun Cluster のシステム管理 (Solaris OS 版)』の第 6 章「定足数の管理」を参照してください。

SPARC: クラスタインターコネクトインタフェースに対する DR クラスタリング

DR のボード切り離し操作が、アクティブなクラスタインターコネクトインタフェースを含むボードに関連する場合、Sun Cluster ソフトウェアはこの操作を拒否します。Sun Cluster ソフトウェアはまた、この操作によって影響を受けるインタフェースを特定します。DR 操作を成功させるためには、Sun Cluster 管理ツールを使用して、アクティブなインタフェースを無効にしておく必要があります。

注意 – 注意 –

Sun Cluster ソフトウェアでは、各クラスタノードは、ほかのすべてのクラスタノードへの有効なパスを、少なくとも1 つ、持っておく必要があります。したがって、個々のクラスタノードへの最後のパスをサポートするプライベートインターコネクトインタフェースを無効にしないでください。

これらの操作の詳細な実行方法については、 『Sun Cluster のシステム管理 (Solaris OS 版)』の「クラスタインターコネクトの管理」を参照してください。

SPARC: パブリックネットワークインタフェースに対する DR クラスタリング

DR のボード切り離し操作が、アクティブなパブリックネットワークインタフェースを含むボードに関連する場合、Sun Cluster ソフトウェアはこの操作を拒否します。Sun Cluster ソフトウェアはまた、この操作によって影響を受けるインタフェースを特定します。アクティブなネットワークインタフェースが存在するボードを切り離す前に、まず、if_mpadm コマンドを使って、そのインタフェース上のすべてのトラフィックを、同じマルチパスグループの正常なほかのインタフェースに切り替える必要があります。

注意 – 注意 –

無効にしたネットワークアダプタに対する DR 切り離し操作中に、残りのネットワークアダプタで障害が発生すると、可用性が影響を受けます。これは、DR 操作の間は、残りのネットワークアダプタのフェイルオーバー先が存在しないためです。

パブリックネットワークインタフェースに対する DR 切り離し操作の詳細な実行手順については、『Sun Cluster のシステム管理 (Solaris OS 版)』の「パブリックネットワークの管理」を参照してください。