iPlanet Messaging Server 5.2 UNIX 用インストールガイド: 第 4 章高可用性 (High Availability、HA)

前へ目次索引 DocHome 次へ

iPlanet Messaging Server 5.2 UNIX 用インストールガイド

第 4 章 高可用性 (High Availability、HA)

この章では、どの高可用性 (High Availability、HA) モデルが適しているかを判別し、Messaging Server で High Availability を利用できるようにシステムを設定する方法について説明します。この章には、以下の節があります。

「高可用性 (High Availability、HA) モデル」

「High Availability のインストール」

「追加の構成に関する注意事項」

「High Availability のアンインストール」

注
現在、High Availability は Solaris プラットフォームでのみ使用できます。

高可用性 (High Availability、HA) モデル

Messaging Server で使用できる High Availability モデルには、さまざまな種類があります。その中でも基本的な 3 つのモデルを次に示します。

「非対称」 (ホットスタンバイ)

「対称」

「N + 1 (N より 1 大きい)」
以下の各項で、この 3 つのモデルについて詳細に説明します。さらに、次の内容についても説明します。

「どの High Availability モデルが適しているか」

「システム停止時間の計算」
HA 製品の種類によって、サポートされているモデルが異なる場合があります。サポートされているモデルについては、HA のマニュアルを参照してください。

非対称

基本的な非対称 (ホットスタンバイ) High Availability モデル (図 4-1) は、クラスタ化された 2 つのホストマシン、つまり、「ノード」で構成されます。どちらのノードにも、1 つの論理 IP アドレスと関連ホスト名が割り当てられています。
このモデルでは、一方のノードのみが常にアクティブになり、バックアップまたはホットスタンバイ用のノードは、ほとんどの時間アイドル状態のままです。両方のノードで共用される単一のディスクアレイは、アクティブなノード、つまり、「主要」ノードによって構成および制御されます。メッセージストアパーティションおよび MTA (Message Transport Agent) キューは、この共用ボリュームに置かれます。
図 4-1    非対称 High Availability モデル

フェイルオーバーが実行される前は、アクティブノードは物理ホスト A です。フェイルオーバーの実行後は、物理ホスト B がアクティブノードになり、共用ボリュームは物理ホスト B に制御されるように切り替えられます。物理ホスト A のすべてのサービスが停止され、同じサービスが物理ホスト B で開始されます。
このモデルの利点は、バックアップノードが主要ノードのバックアップ専用に確保されていることです。したがって、フェイルオーバーの適用時に、バックアップノードでリソースの競合が発生することはありません。ただし、このモデルでは、バックアップノードはほとんどの時間アイドル状態にあるため、その間、このリソースを無駄に使用していることになります。

対称

基本的な対称 (二重サービス) High Availability モデルは、2 つのホストマシンで構成されており、それぞれのホストマシンには固有の論理 IP アドレスが割り当てられています。各論理ノードには 1 つの物理ノードが対応しており、各物理ノードは、2 つのストレージボリュームからなる 1 つのディスクアレイを制御します。ディスクアレイのストレージボリュームの一方は、ローカルのメッセージストアパーティションと MTA キューのために使用され、もう一方は、相手ノードのメッセージストアパーティションと MTA キューのミラーイメージの役割を果たします。
対称 High Availability モデル (図 4-2) では、両方のノードが同時にアクティブ状態にあり、それぞれのノードが他方のバックアップノードの働きをします。通常の状況では、各ノードは、Messaging Server のインスタンスだけを実行します。
図 4-2    対称 High Availability モデル

フェイルオーバーの実行時には、障害のあるノードのサービスがシャットダウンされ、同じサービスがバックアップノードで再開されます。この時、バックアップノードは、両ノードのすべての Messaging Server インスタンスを実行し、個別の 2 つのボリュームを制御します。
このモデルの利点は、両方のノードが同時にアクティブ状態にあるので、マシンのリソースを十分に利用できることです。ただし、障害が発生している間、バックアップノードが両ノードのすべての Messaging Server インスタンスのサービスを実行するので、バックアップノードでのリソースの競合が増えます。したがって、障害のあるノードをできるだけ早く修復し、サーバを本来の二重サービスの状態に戻す必要があります。
このモデルには、バックアップストレージアレイも備えられています。つまり、一方のディスクアレイに障害が生じた場合、バックアップノードのサービスが、そのミラーイメージを引き継ぐことができます。

N + 1 (N より 1 大きい)

N + 1 モデル、つまり「N より 1 大きい」モデルは、複数ノードによる非対称構成で動作します。このモデルでは、N 個の論理ホスト名と N 個の共有ディスクアレイを必要とします。1 つのバックアップノードが、残りの全ノードのホットスタンバイ用に確保されています。このバックアップノードには、N 個のノードのすべての Messaging Server インスタンスを同時に実行する能力があります。
図 4-3 は、基本的な N + 1 High Availability モデルを示しています。
図 4-3    N + 1 High Availability モデル

1 つ以上のアクティブノードにフェイルオーバーが適用されると、バックアップノードが、障害のあるノードのサービスを引き継ぎます。
N + 1 モデルの利点は、サーバの負荷が複数のノードに分散されること、さらに、1 つのバックアップノードのみですべてのノードの障害に対処できることです。そのため、マシンのアイドル比率は、単一非対称モデルの場合が 1/1 であるのに対して、N + 1 モデルでは 1/N になります。

どの High Availability モデルが適しているか

表 4-1 に、各 High Availability モデルの長所と短所を示します。これを参考にして、どのモデルが適しているかを判断してください。

表 4-1    High Availability モデルの長所と短所

モデル

長所

短所

推奨ユーザ

非対称

構成が単純

バックアップノードが 100 パーセント確保される

マシンのリソースが十分に利用されない

将来に拡張予定のある小規模なサービスプロバイダ

対称

システムリソースを有効に利用できる

より可用性が高い

バックアップノード上でのリソース競合

ミラーディスクのためにディスク書き込みのパフォーマンスが低下する

近い将来にバックアップシステムの拡張予定のない中規模のサービスプロバイダ

N + 1

負荷が分散される

拡張が簡単

構成が複雑

リソースの制約なしで分散を必要とする大規模なサービスプロバイダ

 システム停止時間の計算

表 4-2 に、任意の 1 日にシステム障害のためにメールサービスが使用できなくなる確率を示します。これらの計算では、各サーバは、システムのクラッシュまたはサーバのハングにより、平均で 3 か月に 1 日の割合で停止し、各ストレージデバイスは、12 か月に 1 日の割合で停止すると仮定しています。また、両方のノードが同時に停止する確率は低いので無視しています。

表 4-2    システム停止時間の計算

モデル

サーバ停止時間の確率

単一サーバ (High Availability なし)

Pr(down) = (システム停止 4 日 + ストレージ停止 1 日)/365 = 1.37%

非対称

Pr(down) = (システム停止 0 日 + ストレージ停止 1 日)/365 = 0.27%

対称

Pr(down) = (システム停止 0 日 + ストレージ停止 0 日)/365 = (ほぼ 0)

N + 1

Pr(down) = (システム停止 0 日 + ストレージ停止 1 日)/(365xN) = 0.27%/N

High Availability のインストール

この節では、Veritas Cluster Server 1.1 以降、Sun Cluster 2.2、Sun Cluster 3.0 Update 1、または Sun Cluster 3.0 Update 2 用の High Availability クラスタリングソフトウェアをインストールし、Messaging Server で使用できるように準備するために必要な情報を提供します必要に応じて、Veritas Cluster Server または Sun Cluster のマニュアルで、詳細なインストール手順や情報を参照してください。この節には、以下の項目があります。

「クラスタエージェントのインストール」

「Veritas Cluster Server エージェントのインストール」

「Sun Cluster 2.2 エージェントのインストール」

「Sun Cluster 3.0 U1 および U2 エージェントのインストール」

注
iPlanet Directory Server 用の HA エージェントは存在しないので、iPlanet Directory Server 5.1 とともに High Availability を構成することはできません。代わりに、ディレクトリ複製など、別のソリューションを使用する必要があります。代わりの可用性ソリューションについては、『iPlanet Directory Server 導入ガイド』を参照してください。

クラスタエージェントのインストール

クラスタエージェントは、クラスタフレームワークのもとで動作する Messaging Server プログラムです。Messaging Server 5.2 のインストールプロセスで High Availability コンポーネントのインストールを選択すると、setup プログラムは、サーバにインストールされているクラスタリングソフトウェアを自動的に検出し、適切なエージェントプログラムセットを適切な場所にインストールします。

注
Veritas Cluster Server または Sun Cluster 2.2 をインストールする場合、setup プログラムは、VCS 1.1 または SC 2.2 のどちらか一方のエージェントセットのみをコピーします。したがって、どちらか一方のクラスタリングソフトウェアのみがサーバにインストールされ、構成されていることを確認してください。

Veritas Clustering Software では、エージェントタイプファイルは /etc/VRTSvcs/conf/config ディレクトリに、エージェントプログラムは /opt/VRTSvcs/bin/MsgSrv ディレクトリにあります。Sun Cluster 2.2 では、エージェントは /opt/SUNWcluster/ha/msg ディレクトリにインストールされます。
Messaging Server のインストールと High Availability (Veritas Sun Cluster、Sun Cluster 2.2、Sun Cluster 3.0 U1 および U2) に関する留意点は以下のとおりです。

Messaging Server 用 High Availability はデフォルトではインストールされません。そのため、Sun Cluster 2.2 または Veritas Cluster Server 1.1 以降をインストールする場合は、「Custom Installation」メニューから「High Availability Components」を選択するようにしてください。

注
Sun Cluster 3.0 U1 または U2 をインストールする場合は、インストールタイプとして「Custom Installation」を選択する必要があります。ただし、Messaging Server のインストール中には、Sun Cluster 2.2/Veritas HA コンポーネントを選択しないようにしてください。

インストールの実行時には、Messaging Server およびディレクトリサーバの HA 論理ホスト名と関連 IP アドレスが機能している (たとえば、アクティブ状態になっている) ことを確認してください。これは、インストール処理の各所で (たとえば、ディレクトリサーバに構成情報を提供する時などに)、これらのホスト名と IP アドレスを使用して TCP 接続を行うためです。Messaging Server とディレクトリサーバを同じホストで実行する場合は、同じ論理ホスト名と IP アドレスが使用されることもあります。その場合は、Messaging Server の HA 論理ホスト名が現在指定しているクラスタノードで、インストールを実行してください。

server-root (第 3 章「インストールに関する質問」の手順 5 を参照) の指定を求められたら、その server-root が共用ファイルシステムにあることを確認してください。共用ファイルシステムにないと、High Availability は正常に動作しません。たとえば、障害によって別のノードに処理が引き継がれた場合、そのノードのサーバは、障害のあるノード上のサーバによって蓄積されたデータを見ることができなくなります。

Messaging Server ホストの完全指定ドメイン名 (第 3 章「インストールに関する質問」の手順 11 を参照) の指定を求められた場合は、Messaging Server の完全指定 HA 論理ホスト名を指定します。インストール処理中に、この論理ホスト名を使用した TCP 接続が試みられます。

Messaging Server の IP アドレス (第 3 章「インストールに関する質問」の手順 35 を参照) の指定を求められたら、Messaging Server の論理ホスト名に関連付けられた IP アドレスを指定します。物理ホストの IP アドレスは使用しないでください。
Veritas Cluster Server 1.1 以降の High Availability ソフトウェアを使用している場合は、「Veritas Cluster Server エージェントのインストール」に進んでください。Sun Cluster 2.2 の High Availability ソフトウェアを使用している場合は、「Sun Cluster 2.2 エージェントのインストール」に進んでください。Sun Cluster 3.0 U1 または U2 の High Availability ソフトウェアを使用している場合は、「Sun Cluster 3.0 U1 および U2 エージェントのインストール」に進んでください。

Veritas Cluster Server エージェントのインストール

実装する High Availability モデルが決まったら、次に、Veritas Cluster Server ソフトウェアをインストールし、Messaging Server で使用できるように準備します。この節で説明する手順は、Messaging Server をインストールする前に実行する必要があります。

注
ここでは、Veritas Cluster Server の概念やコマンドについて十分に理解していることを前提としています。

この節には、以下の項目があります。

「インストール前の手順」

「High Availability のインストール」

「インストール後の手順」

「Veritas Cluster Server 用の High Availability の構成」
この節で使用する例は、単純な、2 つのノードを使用したクラスタサーバ (非対称モデル) をベースにしています。
基本的な非対称モデルでは、1 つの公共ネットワークインタフェースと 2 つの専用ネットワークインタフェース、および 1 つの共用ディスクを必要とします。専用ネットワークインタフェースは、クラスタ通信に使用されます。共用ディスクは、両方のノードに接続されている必要があります。

インストール前の手順

ここでは、Veritas Cluster Server をインストールし、Messaging Server で使用できるように準備する手順を説明します。
Veritas Cluster Server をインストールして Messaging Server で使用できるように設定するには、次の手順に従います。

Veritas Cluster Server 1.1 以降を両方のノードにインストールします。

Veritas Cluster Server を構成して起動します。

注
この最初の 2 つの段階の詳細な情報および手順については、Veritas Cluster Server のマニュアルを参照してください。

/etc/VRTSvcs/conf/config/main.cf ファイルを作成します。

iMS5 というサービスグループを作成します。

このサービスグループ内で、次の作業を実行します。

network リソースを作成します (リソースタイプとして NIC を指定)。

Device 属性には公共ネットワークインタフェース名を使用します (たとえば hme0)。

logical_IP リソースを作成します (リソースタイプとして IP を指定)。

Address 属性には論理 IP を、Device 属性には公共ネットワークインタフェースを使用します。

sharedg リソースを作成します (リソースタイプとして DiskGroup を指定)。

DiskGroup 属性には、ディスクグループ名を使用します。

mountshared リソースを作成します (リソースタイプとして Mount を指定)。

共用デバイス名 BlockDevice を使用し、マウントポイントとして MountPoint を指定し、適切なファイルシステムタイプとして FSType を設定します。

主要 (アクティブ) ノードで、上記のリソースをすべてオンラインにします。

logical_IP リソースが network リソースに依存し、mountshared リソースが sharedg リソースに依存するように依存関係ツリーを設定します。依存関係ツリーは次のようになります。

High Availability のインストール

この時点で、Veritas Cluster Server がインストールされ、Messaging Server をインストールするための準備が完了しています。
主要ノードに Messaging Server と High Availability をインストールします。これは次の手順に従います。

主要ノードで setup プログラムを起動して、Messaging Server のインストールを開始します。

./setup

インストールタイプのリストから「Custom installation」を選択します。

Messaging Server コンポーネントに加えて、主要ノードにインストールする Sun Cluster 2.2 または Veritas の HA コンポーネントを選択します。
二次ノードには、High Availability のみをインストールする必要があります。これは次の手順に従います。

二次ノードに対してフェイルオーバーを実行します。

二次ノードで setup プログラムを起動して、Messaging Server のインストールを開始します。

./setup

インストールタイプのリストから「Custom Installation」を選択し、次に、「iPlanet Messaging Applications」からSun Cluster 2.2/Veritas HA コンポーネントのみを選択します。
Messaging Server のインストール時に、setup プログラムは、Veritas Cluster Server がインストールされ、正しく設定されているかどうかをチェックします。インストールと設定が正しく行われていれば、適切な High Availability ファイルがインストールされます。

インストール後の手順

High Availability のインストールが完了したら、両方のノードに対して次に示すインストール後の手順を実行します。

Veritas Cluster Server を停止します。

main.cf に、次の行を追加します。

include "MsgSrvTypes.cf"

Veritas Cluster Server を起動します。

mail という名前のリソースを作成し (リソースタイプとして MsgSrv を指定)、インスタンス名 (InstanceName) と、論理ホスト名 (LogHostName) を入力します。

logical_IP リソースと mountshared リソースを、mail リソースの子として設定します。

これにより、mail リソースの、logical_IP リソースと mountshared リソースへの依存関係が設定されます。

この場合の依存関係ツリーは次のようになります。

これで準備ができました。任意のノードで、mail リソースをオンラインにします。これにより、そのノードでメールサーバが自動的に起動します。

Veritas Cluster Server 用の High Availability の構成

Veritas Cluster Server 用の High Availability を構成するには、MsgSvrType 設定ファイルのパラメータを変更します。関連するエントリを次に示します。
type MsgSrv (
   static int MonitorInterval = 180
   statis int MonitorTimeout = 180
   static int OnlineRetryLimit = 1
   static int OnlineWaitLimit = 1
   static int RestartLimit = 2
   static str ArgList[] = { State, InstanceName, LogHostName, PrtStatus, DebugMode }
   NameRule = resource.InstanceName
   str InstanceName
   str LogHostName
   str PrtStatus
   str DebugMode
)
表 4-3 に、各パラメータの説明を示します。

表 4-3    MsgSrv のパラメータ

パラメータ

説明

MonitorInterval

プローブ実行の時間間隔 (秒単位)

MonitorTimeout

プローブがタイムアウトするまでの時間 (秒単位)

OnlineRetryLimit

オンライン再試行の回数

OnlineWaitLimit

オンライン手順の完了後、そのリソースがオンラインになるまで待機する MonitorInterval の数

RestartLimit

リソースにフェイルオーバーが適用されるまでの再起動回数

表 4-4 に、各引数の説明を示します。

表 4-4    MsgSrv の引数

パラメータ

説明

State

サービスがオンライン状態にある (このシステムに存在する) かどうかを示す。ユーザがこの値を変更することはできない

InstanceName

Messaging Server のインスタンス名 (msg- 接頭辞なし)

LogHostName

このインスタンスに関連付ける論理ホスト名

PrtStatus

TRUE に設定すると、オンラインの状態が Veritas Cluster Server のログファイルに記録される

DebugMode

TRUE に設定すると、デバッグ情報が Veritas Cluster Server のログファイルに記録される

 Sun Cluster 2.2 エージェントのインストール

実装する High Availability モデルが決まったら、次に、Sun Cluster 用の High Availability ソフトウェアをインストールし、Messaging Server で使用できるように準備します。この節には、以下の項目があります。

「インストール前の手順」

「High Availability のインストール」

「インストール後の手順」

「ディレクトリサーバの構成」
この節で説明する手順は、Messaging Server をインストールする前に実行する必要があります。

注
ここでは、Sun Cluster の概念やコマンドについて十分に理解していることを前提としています。

この節で使用する例は、単純な、2 つのノードを使用したクラスタサーバ (非対称モデル) をベースにしています。
基本的な非対称モデルでは、1 つの公共ネットワークインタフェースと 2 つの専用ネットワークインタフェース、および 1 つの共用ディスクを必要とします。専用ネットワークインタフェースは、クラスタ通信に使用されます。共用ディスクは、両方のノードに接続されている必要があります。

インストール前の手順

ここでは、Sun Cluster ソフトウェアをインストールして、Messaging Server で使用できるように準備する手順を説明します。
Sun Cluster をインストールして Messaging Server で使用できるように設定するには、次の手順に従います。

Sun Cluster 2.2 を両方のノードにインストールします。

注
HA 障害監視エージェントは、Sun Cluster 2.2 SUNWscpro パッケージの tcpclnt バイナリファイルを必要とします。このプローブ機能は必ずインストールしてください。インストールしないと、反応しない Messaging Server が検出されません。

Sun Cluster を構成して起動し、論理 IP と共用ボリュームにアクセスできるようにします。

注
この最初の 2 つの段階の詳細な情報および手順については、Sun Cluster のマニュアルを参照してください。

High Availability のインストール

この時点で、Sun Cluster ソフトウェアがインストールされ、Messaging Server をインストールするための準備は完了しています。
主要ノードに Messaging Server と High Availability をインストールします。これは次の手順に従います。

主要ノードで setup プログラムを起動して、Messaging Server のインストールを開始します。

./setup

インストールタイプのリストから「Custom installation」を選択します。

Messaging Server コンポーネントに加えて、主要ノードにインストールする Sun Cluster 2.2 または Veritas の HA コンポーネントを選択します。
二次ノードには、High Availability のみをインストールする必要があります。これは次の手順に従います。

logical_IP と共用ディスクを二次ノードに切り替えます。

二次ノードで setup プログラムを起動して、Messaging Server のインストールを開始します。

./setup

インストールタイプのリストから「Custom Installation」を選択し、次に、「iPlanet Messaging Applications」からSun Cluster 2.2/Veritas HA コンポーネントのみを選択します。
Messaging Server のインストール時に、setup プログラムは、Sun Cluster ソフトウェアがインストールされ、正しく設定されているかどうかをチェックします。インストールと設定が正しく行われていれば、適切な High Availability ファイルがインストールされます。

インストール後の手順

二次ノードで、次の作業を実行する必要があります。

二次ノードに対してフェイルオーバーを実行します。

server-root/bin/msg/ha/sc/config/ims_ha.cnf ファイルを、この論理ホスト (たとえば /$LOGICAL_HOSTNAME) の管理ファイルシステムディスクのマウントポイントディレクトリにコピーします。

さらに、hareg -Y コマンドを実行してデータサービスを使用する前に、Messaging Server のデータサービスを登録する必要があります。

論理ホストのタイムアウト値を変更する必要がある場合は、次のコマンドを使用します。

scconf cluster_name -l seconds

cluster_name はクラスタ名、seconds はタイムアウト値として設定する秒数を示します。この秒数は、起動の完了に必要な秒数の 2 倍にする必要があります。詳細については、Sun Cluster のマニュアルを参照してください。

ディレクトリサーバの構成

Messaging Server と同じ server-root の下にディレクトリサーバをインストールして構成する場合は、Sun Cluster エージェントファイルを追加する必要はありません。それ以外の場合は、Sun が供給する既存のエージェントパッケージを使用できます。パッケージ名は、SUNWscnsl です。これは、Sun の Sun Cluster チームによりサポートされています。

Sun Cluster 3.0 U1 および U2 エージェントのインストール

この節では、Sun Cluster 3.0 U1 または U2 (Update 1 または 2) Highly Available (HA) Data Service のインストールおよび構成方法を説明します。この節には、以下の項目があります。

「Sun Cluster 3.0 U1 および U2 の前提条件」

「Sun Cluster 3.0 U1 および U2 の Messaging Server HA サポートのインストール」

「Sun Cluster 3.0 U1 および U2 の Messaging Server HA サポートの構成」
Sun Cluster 3.0 U1 および U2 のマニュアルは、次の場所で参照できます。
http://docs.sun.com/ab2/coll.572.8/

Sun Cluster 3.0 U1 および U2 の前提条件

ここでは、次の条件を前提としています。

必要なパッチが適用された Solaris 8 オペレーティング環境に Sun Cluster 3.0 U1 または U2 がインストールされている

Netscape Directory Server の HA エージェント (Sun Cluster 3.0 U1 または U2 エージェントの CD-ROM に収録) がインストールされている。Netscape Directory Server の HA エージェントを使用する必要のない場合でも、このインストールを強く推奨します。このマニュアルでは、インストールしてあることを前提に説明を行います。

共用ディスクを使用するシステムの場合、Solstice DiskSuite または Veritas Volume Manager が使用されている

Veritas File System (VxFS) は、Sun Cluster 3.0 U1 ではサポートされていない

注
Veritas File System (VxFS) は、Sun Cluster 3.0 U2 でサポートされるようになりました。

Sun Cluster 3.0 U1 および U2 の Messaging Server HA サポートのインストール

Messaging Server を実行するには、各クラスタノードにパッケージが 1 つインストールされている必要があります。

iPlanet Messaging Server CD の solaris/iMS_sc30 ディレクトリ内の SUNWscims
各クラスタノードで、pkgadd コマンドを使用して、パッケージをインストールします。たとえば、以下のように記述します。
# pkgadd -d . SUNWscims
パッケージをインストールすると、Messaging Server を HA 用に構成できるようになります。

Sun Cluster 3.0 U1 および U2 の Messaging Server HA サポートの構成

この節では、さまざまな構成例を示して、iPlanet Messaging Server の HA サポートを構成する方法を説明します。

「単純な例」

「複雑な例」

注
Messaging Server は、ローカルシステムではなく、グローバルファイルシステムのディレクトリにインストールされている必要があります。

Messaging Server のインストールが完了したら、「サーバにある 1 つまたは複数の Messaging Server インスタンスの IP アドレスのバインド」で、HA サポートの構成に関連する追加の構成手順を確認してください。

単純な例
この例では、Messaging Server とディレクトリサーバが同じクラスタノードで実行され、同じ HA 論理ホスト名と IP アドレスを使用するものとします。物理ホスト名は mail-1 と mail-2 で、HA 論理ホスト名は mail とします。図 4-4 に、Messaging Server HA サポートの構成時に作成する各種の HA リソースの依存関係を入れ子構造で示します。
図 4-4    単純な iPlanet Messaging Server HA 構成

作業を進める前に、すべてのクラスタノードの Messaging Server がシャットダウンされていることを確認します。これをもっとも簡単な方法で確認するには、各クラスタノードで次のコマンドを実行します。
# ps -ef | grep server-root
server-root は、Messaging Server の最上位ディレクトリ (たとえば /global/ims/server5/) を表します。Messaging Server が実行されていなければ、入力した grep 行以外には何も表示されません。

スーパーユーザ (root) になり、コンソールを開きます。

以下の Sun Cluster コマンドを実行するには、スーパーユーザとしてログインする必要があります。また、メッセージ出力を表示するコンソールまたはウィンドウを /dev/console に設定する必要があります。

必要なリソースタイプを追加します。

使用するリソースタイプを Sun Cluster が認識できるように設定します。これを行うには、次のように、scrgadm -a -t コマンドを使用します。

# scrgadm -a -t SUNW.HAStorage
# scrgadm -a -t SUNW.nsldap
# scrgadm -a -t SUNW.ims

Messaging Server インスタンスのリソースグループを作成します。

この作業をまだ実行していない場合は、リソースグループを作成し、Messaging Server インスタンスを実行するクラスタノードにそのグループが表示されるようにします。次のコマンドは、IMS-RG というリソースグループを作成し、クラスタノードの mail-1 および mail-2 にこのグループが表示されるようにするためのものです。

# scrgadm -a -g IMS-RG -h mail-1,mail-2

リソースグループには、任意の名前を使用できます。

HA 論理ホスト名リソースを作成します。

この作業をまだ実行していない場合は、HA 論理ホスト名リソースを作成して有効にし、これを Messaging Server インスタンスのリソースグループ内に配置します。次のコマンドは、論理ホスト名 mail を使用して、これを実行します。-j オプションが省略されているので、作成したリソースの名前も mail になります。

# scrgadm -a -L -g IMS-RG -l mail
# scswitch -Z -g IMS-RG

Messaging Server をインストールします。

手順 4 で作成して有効にした HA 論理ホスト名を使用して、Messaging Server をインストールします。二次ノードに /etc/msgregistry.inf を複製する必要があります。

Messaging Server のインストール手順については、第 2 章「インストール手順」を参照してください。

注
Sun Cluster 3.0 U1 または U2 をインストールする場合は、インストールタイプとして「Custom Installation」を選択する必要があります。ただし、Messaging Server のインストール中には、High Availability コンポーネントを選択しないようにしてください。

msgserver-root ディレクトリの start-msg コマンドを使用して Messaging Server を起動します。

ha_ip_config スクリプトを実行して、サーバ上の msg-instance の IP アドレスをバインドします。スクリプトの実行手順については、「サーバにある 1 つまたは複数の Messaging Server インスタンスの IP アドレスのバインド」を参照してください。

msgserver-root ディレクトリの stop-msg ha を実行して、Messaging Server を停止します。

以下のコマンドを使用して、ディレクトリと Administration Server プロセスを停止します。

msgserver-root/slapd-instance/stop-slapd
msgserver-root/stop-admin

HA ストレージリソースを作成します。

Messaging Server とディレクトリサーバが依存するファイルシステムの HA ストレージリソースタイプを作成する必要があります。次のコマンドは、ha-storage という HA ストレージリソースを作成し、ファイルシステム /global/ims/server5 を、その制御下に置くためのものです。

# scrgadm -a -j ha-storage -g IMS-RG \
-t SUNW.HAStorage \
-x ServicePaths=/global/ims/server5

ServicePaths= の後ろに、Messaging Server とディレクトリサーバの両方が依存するクラスタファイルシステムのマウントポイントをカンマで区切って列挙します。この例では、/global/ims/server5 という 1 つのマウントポイントのみが指定されています。一方のサーバが別のファイルシステムに依存する場合は、追加の HA ストレージリソースを作成し、手順 6 または 8 で、その依存関係を指定します。

HA LDAP リソースを作成します。

作業対象のリソースグループに、ディレクトリサーバを監視するために、SUNW.nsldap タイプのリソースを追加します。SUNW.nsldap の Confdir_list 拡張プロパティは、グローバルファイルシステムにあるディレクトリサーバの最上位ディレクトリのパスを示すために使用されます。また、このリソースは、手順 4 および 5 で設定した HA 論理ホスト名と HA ストレージリソースの両方に依存します。ただし、SUNW.nsldap リソースタイプはリソースタイプ登録ファイルの Network_resources_used を指定するので、Resource_dependencies オプションで HA 論理ホスト名リソースを明示的に指定する必要はありません。このオプションで指定する必要があるのは、HA ストレージリソースのみです。次のコマンドは、この全作業を実行し、HA LDAP リソースに ha-ldap という名前を付けるためのものです。

# scrgadm -a -j ha-ldap -t SUNW.nsldap -g IMS-RG \
     -x Confdir_list=/global/ims/server5/slapd-mail \
     -y Resource_dependencies=ha-storage

HA LDAP リソースを有効にします。

HA Messaging Server リソースの作成作業を進める前に、HA LDAP リソースをオンラインにする必要があります。HA Messaging Server リソースの作成時には、Messaging Server リソース定義の妥当性検査が行われます。そのために、LDAP サーバに保存された Messaging Server 構成情報へのアクセスが必要になります。

すでに実行していたために手順 3 ～ 5 を省略した場合は、IMS-RG リソースグループの一部はすでにオンラインになっています。その場合は、次のコマンドを実行して HA ストレージリソースと LDAP リソースを有効にしてください。

# scswitch -e -j ha-storage

# scswitch -e -j ha-ldap

手順 3 ～ 5 を実行した場合は、代わりに次のコマンドを使用します。

# scswitch -Z -g IMS-RG

HA Messaging Server リソースを作成します。

HA Messaging Server リソースを作成し、これをリソースグループに追加します。このリソースは、HA 論理ホスト名リソース、HA ストレージリソース、および HA LDAP リソースに依存します。HA LDAP リソースと同様に、HA 論理ホスト名リソースを指定する必要はありません。さらに、HA LDAP リソースは自動的に HA ストレージリソースに依存するので、ほとんどの場合、HA LDAP リソースとの依存関係を指定する必要はありません。

HA Messaging Server リソースを作成する時は、Messaging Server の最上位ディレクトリ (server-root) のパスと、HA を作成する Messaging Server インスタンスの名前を指定する必要があります。これには、次に示すように、IMS_serverroot および IMS_instance の各拡張プロパティを使用します。

# scrgadm -a -j ha-ims -t SUNW.ims -g IMS-RG \
          -x IMS_serverroot=/global/ims/server5 \
          -x IMS_instance=stork \
          -y Resource_dependencies=ha-ldap

このコマンドは、グローバルファイルシステムの /global/ims/server5 にインストールされている stork という Messaging Server インスタンス用に、ha-ims という名前の HA Messaging Server リソースを作成します。この HA Messaging Server リソースは、手順 6 で作成した ldap という HA LDAP リソースに依存します。

Messaging Server インスタンスがディレクトリサーバとは別のファイルシステムとの依存関係を持つ場合は、そのファイルシステム用に追加の HA ストレージリソースを作成できます。その場合は、上記のコマンドの Resource_dependencies オプションに、追加する HA ストレージリソースの名前を含めます。

Messaging Server リソースを有効にします。

HA Messaging Server リソースを有効にし、その Messaging Server をオンラインにします。これを実行するには、次のコマンドを使用します。

# scswitch -e -j ha-ims

このコマンドは、IMS-RG リソースグループの ha-ims リソースを有効にします。IMS-RG リソースはすでにオンラインになっているので、このコマンドで、ha-ims リソースもオンラインにします。

リソースの動作を確認します。

scstat コマンドを使用して、IMS-RG リソースグループがオンラインになっているかどうかを確認します。診断情報があれば、コンソールデバイスに出力されるので、画面で確認できます。また、syslog ファイル /var/adm/messages で参照することもできます。

もう 1 つのクラスタノードにリソースグループの処理を継続させます。

手動でリソースグループの処理を別のクラスタノードに継続させます。scstat コマンドを使用して、現在リソースグループの処理を実行している (オンラインになっている) ノードを確認します。たとえば、オンラインノードが mail-1 の場合は、次のコマンドを使用して、mail-2 に処理を継続させます。

# scswitch -z -g IMS-RG -h mail-2

複雑な例
今度はもっと複雑な例として、iPlanet Messaging Server が次のものに依存している場合について考えます。

同じノードで実行され、構成情報が含まれている LDAP サーバ

別のノードで実行され、ユーザ情報が含まれている LDAP サーバ

メッセージストアパーティションと MTA メッセージキューが含まれている別のファイルシステム
図 4-5 は、Sun Cluster のリソースグループを使用してこれらの依存関係を実現する方法を示しています。この図には、各リソースのキーパラメータが示されています。この構成を実現するために必要なコマンドを図のあとに示します。
図 4-5    複雑な iPlanet Messaging Server HA 構成

# scrgadm -a -t SUNW.nsldap

# scrgadm -a -t SUNW.ims

# scrgadm -a -g LDAP-USER-RG -h ldap-1,ldap-2 LDAP-USER-RG リソースグループを作成

# scrgadm -a -L -g LDAP-USER-RG -l ldap HA 論理ホスト名を作成

# scswitch -Z -g LDAP-USER-RG LDAP-USER-RG をオンラインにする

     .../global/ids に Directory Server をインストールして構成する

# scrgadm -a -j ha-ids-disk -g LDAP-USER-RG \ HA ストレージリソースを作成

          -t SUNW.HAStorage \

          -x ServicePaths=/global/ids

# scrgadm -a -j ha-ldap-user -g LDAP-USER-RG \ HA LDAP リソースを作成

          -t SUNW.nsldap \

          -x Confdir_list=/global/ids/slapd-ldap \

          -y Resource_dependencies=ha-ids-disk

# scswitch -e -j ha-ids-disk 残りのLDAP-USER-RG をオンラインにする

# scswitch -e -j ha-ldap-user

# scrgadm -a -g IMS-RG -h mail-1,mail-2 IMS-RG リソースグループを作成

# scrgadm -a -L -g IMS-RG -l mail HA 論理ホスト名を作成

# scswitch -Z -g IMS-RG IMS-RG をオンラインにする

    .../global/ims/server5 に Messaging Server と 2 つ目の Directory Server をインストールして構成する

# scrgadm -a -j ha-ims-serverroot -g IMS-RG \ HA ストレージリソースを作成

          -t SUNW.HAStorage \

          -x ServicePaths=/global/ims/server5

# scrgadm -a -j ha-ldap-config -g IMS-RG \ HA LDAP リソースを作成

          -t SUNW.nsldap \

          -x Confdir_list=/global/ims/server5/slapd-mail \

          -y Resource_dependencies=ha-ims-serverroot

# scrgadm -a -j ha-ims-data -g IMS-RG \ もう 1 つの HA ストレージリソースを作成

          -t SUNW.HAStorage \

          -x ServicePaths=/global/ims/store,/global/ims/queues

# scswitch -e -j ha-ims-serverroot LDAP をオンラインにする
# scswitch -e -j ha-ldap-config

# scrgadm -a -j ha-ims -g IMS-RG \ HA Messaging Server リソースを作成

          -t SUNW.ims \

          -x IMS_serverroot=/global/ims/server5 \

          -x IMS_instance=stork \

          -y Resource_dependencies=ha-ldap-config,ha-ims-data \

          -y RG_dependencies=LDAP-USER-RG

# scswitch -e -j ha-ims-data                  Messaging Server をオンラインにする
# scswitch -e -j ha-ims

追加の構成に関する注意事項

「対称」High Availability モデルまたは「N + 1」High Availability モデルを使用する場合は、Cluster Server を Messaging Server に対応させるために、インストールと構成で注意すべき事項がいくつかあります。
この節では、Veritas Cluster Server 1.1 以降、Sun Cluster 2.2、Sun Cluster 3.0 U1 および Sun Cluster 3.0 U2 について、それらの問題と対処方法を説明します。

「サーバにある 1 つまたは複数の Messaging Server インスタンスの IP アドレスのバインド」

「追加の Messaging Server インスタンスの可用性の高度化」

注
Messaging Server のインストールでは、インストール処理中はメールサービスをオフラインにする必要があります。メールサービスが動作していると、Messaging Server のインストールの妨げになることがあります。

サーバにある 1 つまたは複数の Messaging Server インスタンスの IP アドレスのバインド

サーバで 1 つまたは複数の Messaging Server インスタンスを実行する場合は、正しい IP アドレスを各インスタンスにバインドする必要があります。

注この節の内容は、Sun Cluster 2.2、Sun Cluster 3.0 U1 および U2、Veritas Cluster Server バージョン 1.1 以降に適用されます。

以下の節で、各インスタンスの IP アドレスをバインドする方法を説明します。これを正しく行わないと、インスタンスが互いに悪影響を及ぼす可能性があります。
Messaging Server を HA 対応に構成する過程で、Messaging Server がバインドされて接続を待機するインタフェースアドレスを設定します。デフォルトでは、各サーバは使用可能なすべてのインタフェースアドレスにバインドされます。ただし、HA 環境では、HA 論理ホスト名に関連付けられたインタフェースアドレスに限定して各サーバをバインドする必要があります。使用可能なすべてのインタフェースにバインドすると、2 つの異なる Messaging Server インスタンスを同じ物理ホスト上で実行する場合に問題が発生するためです。
上記のようなバインドが簡単に行えるように、特定の Messaging Server インスタンスに属するサーバが使用するインタフェースアドレスの構成を行うためのスクリプトが用意されています。このスクリプトにより、同じ Messaging Server ルートにある LDAP サーバインスタンスが同じインタフェースアドレスを使用するように構成することも可能です。このスクリプトでは、ユーザが所有する IP アドレス、またはサーバが使用する HA 論理ホスト名に関連付ける IP アドレスから、適切なインタフェースアドレスを特定します。
使用する LDAP サーバが別のホストに置かれている場合、ha_ip_config スクリプトは、それらの LDAP サーバを構成できません。通常は、Messaging Server を HA 用に構成していれば、別のホストにある LDAP サーバの構成を追加する必要はありません。
このスクリプトは、以下の設定ファイルを修正または作成することによって、構成を変更します。
server-root/msg-instance/imta/config/dispatcher.cnf
このファイルでは、SMTP サーバおよび SMTP 送信サーバの INTERFACE_ADDRESS オプションを追加または変更します。
server-root/msg-instance/imta/config/job_controller.cnf
このファイルでは、ジョブコントローラの INTERFACE_ADDRESS オプションを追加または変更します。
server-root/slapd-instance/config/slapd.conf
このファイルでは、LDAP サーバの listenhost オプションを追加または変更し (省略可)、最後に、POP サーバ、IMAP サーバ、および Messenger Express HTTP サーバが使用する configutil service.listenaddr パラメータを設定します。
元の設定ファイルがある場合、それらのファイルは *.pre-ha という名前に変更されます。
このスクリプトを実行するには、次の手順に従います。

スーパーユーザ (root) になります。

server-root/bin/msg/install/bin/ha_ip_config を実行します。

スクリプトによって、以下の質問が表示されます。Control キーを押しながら d キーを押すと、どの質問の段階でもスクリプトを中止できます。デフォルトの設定は、各括弧 ([ ]) 内に表示されています。デフォルトの設定を選択する場合は、Return キーを押します。

Logical IP address : 論理 IP アドレス。Messaging Server インスタンスが使用する論理ホスト名に割り当てられた IP アドレスを指定します。この IP アドレスは、「10.0.100.10」のように、ドット付きの 10 進形式で指定する必要があります。

Messaging Server root : Messaging Server ルート。Messaging Server をインストールする最上位ディレクトリの絶対パスを指定します。このディレクトリ内の msg-* サブディレクトリに、各 Messaging Server インスタンスが置かれます。

Messaging Server instance name : Messaging Server インスタンス名。構成する Messaging Server インスタンスの名前を指定します。このインスタンス名には、先頭の msg- を含めないでください。

Also configure an LDAP server instance in the same Messaging Serverroot : 同じ Messaging Server ルートに LDAP サーバも構成するかどうか。同じ Messaging Server ルートにある LDAP サーバインスタンスも構成する場合は、「yes」と答えます。これにより、その LDAP サーバは、Messaging Server インスタンスと同じ IP アドレスに設定されます。LDAP サーバインスタンスの構成を行わない場合は、「no」と答えます。

Messaging Server ルートに slapd- で始まる名前を持つサブディレクトリが含まれていない場合、この質問は表示されません。

LDAP instance name : LDAP インスタンス名。構成する LDAP インスタンスの名前を指定します。このインスタンス名には、先頭の slapd- を含めないでください。

LDAP サーバインスタンスの構成に関する前の質問 (d) で「no」と答えた場合、この質問は表示されません。

Do you wish to change any of the above choices : 選択した項目を変更するかどうか。これまでに回答した内容でよい場合は、「no」と答えて、構成の変更を確定します。回答を変更する場合は、「yes」と答えます。

2 つ以上の Messaging Server インスタンスを同じノードで実行する場合、または実行する可能性がある場合は、server-root/msg-instance/imta/config/ ディレクトリにある job_controller.cnf ファイルを編集します。ジョブコントローラで、各インスタンスが異なるポート番号を使用するようにしてください。この設定は、job_controller.cnf ファイルの TCP_PORT オプションで行います。

注
物理ホスト名の IP アドレスを論理ホスト名の IP アドレスに変更しない場合は、Messaging Server のインストール中に指定した物理ホスト上の Administration Server のみにアクセスできます。
論理ホスト名の IP アドレスを設定する場合は、クラスタに Messaging Server をインストールするときに、「Custom installation」オプションを選択する必要があります。質問 35. で、Administration Server を特定の IP アドレスに指定することができます。
「Typical installation」オプションを選択した場合でも、Administration Server の物理ホストの IP アドレスを論理ホストの IP アドレスに変更できます。これには admin_ip.pl ユーティリティを使用します。このユーティリティについては、http://docs.iplanet.com/docs/manuals/console.html にある iPlanet Console のマニュアルを参照してください。

ノードのテスト

テストを始める前に、そのクラスタの各ノードで、iPlanet Messaging Server を開始および停止できることを確認してください。Messaging Server をインストールしたノードからテストを始めます。その後、次のコマンドを使用して、その論理ホスト名から別のクラスタノードに処理を継続させます (Sun Cluster 3.0 の場合)。
# scswitch -z -g IMS-RG -h name-of-physical-host-to-failover-to
テストが完了したら、HA の構成を行う前に Messaging Server をシャットダウンしてください。別のホストで実行される Directory Server、または別の方法で Messaging Server から分離されている Directory Server についても同様です。

追加の Messaging Server インスタンスの可用性の高度化

Veritas Cluster Server 1.1 以降を使用する場合、前に作成した iMS5 に加えて、2 番目のサービスグループを作成する必要があります。このグループには、iMS5 グループと同じリソースセットおよび同じ依存関係ツリーを持たせる必要があります。
Sun Cluster 2.2 を使用する場合は、別の論理 IP と共用ボリュームで構成されるもう 1 つの論理ホストを作成します。その後、このボリュームに新規インスタンスをインストールできます。

注
hareg -Y コマンドを使用して Sun Cluster 2.2 を実行する場合は、各ノードにインスタンスが 1 つしかないことを確認します。Sun Cluster 2.2 では、このコマンドを使用して、1 つのノードで複数の論理 IP を呼び出すことはできません。

Sun Cluster 3.0 では、もう 1 つのリソースグループを作成するかどうかは、追加の Messaging Server インスタンスの使用方法によって決まります。追加インスタンスのフェイルオーバーを既存のインスタンスとは別のものにする場合は、追加インスタンス用の新しいリソースグループを作成します。ただし、既存インスタンスのフェイルオーバーに伴って追加インスタンスがフェイルオーバーするような場合は、両方のインスタンスが同じリソースグループを使用させる方がよいでしょう。

High Availability のアンインストール

この節では、High Availability をアンインストールする方法を説明します。以下の項目があります。

「Veritas Cluster Server および Sun Cluster 2.2 のアンインストール」

「Sun Cluster 3.0 U1 および U2 の Messaging Server HA サポートのアンインストール」

Veritas Cluster Server および Sun Cluster 2.2 のアンインストール

High Availability のアンインストール手順は、Veritas Cluster Server か Sun Cluster のどちらを削除するかによって異なります。Veritas Cluster Server の High Availability ソフトウェアを使用している場合は、「Veritas Cluster Server 用の High Availability のアンインストール」に進んでください。Sun Cluster 2.2 の High Availability ソフトウェアを使用している場合は、「Sun Cluster の High Availability のアンインストール」に進んでください。

Veritas Cluster Server 用の High Availability のアンインストール

Veritas Cluster Server の High Availability コンポーネントをアンインストールするには、次の手順に従います。

iMS5 サービスグループをオフラインにし、そのリソースを無効にします。

mail リソース、logical_IP リソース、および mountshared リソースの間の依存関係を解除します。

iMS5 サービスグループをオンラインに戻します。sharedg リソースが有効になります。

dirsync オプションを使用している場合は、両方のノードの cron ジョブテーブルから dirsync エントリを削除します。

インストール時に作成した Veritas Cluster Server リソースをすべて削除します。

Veritas Cluster Server を停止し、ほかにインスタンスが存在しない場合は、両方のノードで次のファイルを削除します。

/etc/VRTSvcs/conf/config/MsgSrvTypes.cf
/opt/VRTSvcs/bin/MsgSrv/online
/opt/VRTSvcs/bin/MsgSrv/offline
/opt/VRTSvcs/bin/MsgSrv/clean
/opt/VRTSvcs/bin/MsgSrv/monitor
/opt/VRTSvcs/bin/MsgSrv/sub.pl

Messaging Server のエントリを両方のノードの/etc/VRTSvcs/conf/config/main.cf ファイルから削除します。

両方のノードから /opt/VRTSvcs/bin/MsgSrv/ ディレクトリを削除します。

Messaging Server と同じ server-root ディレクトリに Directory Server がインストールされている場合は、その Directory Server が稼動していることを確認します。

付録 B 「uninstall プログラムの実行」に示されている通常のアンインストール手順を実行します。

複数のインスタンスがインストールされている場合は、両方のノードの /etc/msgregistry.inf ファイルから、目的のインスタンスのエントリを削除します。インストールされているインスタンスが 1 つの場合は、両方のノードで、/etc/msgregistry.inf ファイルを削除します。

Sun Cluster の High Availability のアンインストール

Sun Cluster の High Availability コンポーネントをアンインストールするには、次の手順に従います。

次のコマンドを実行して、すべてのプロセスを停止します。

hareg -n

Messaging Server と同じ server-root ディレクトリに Directory Server がインストールされている場合は、その Directory Server が稼動していることを確認します。

付録 B 「uninstall プログラムの実行」に示されている通常のアンインストール手順を実行します。

複数のインスタンスがインストールされている場合は、両方のノードの /etc/msgregistry.inf ファイルから、目的のインスタンスのエントリを削除します。インストールされているインスタンスが 1 つの場合は、両方のノードで、/etc/msgregistry.inf ファイルを削除します。

次のコマンドを実行します。

hareg -u ims50

この手順を実行する前に、手順 1 を実行する必要があります。

次のファイルを削除します。

/opt/SUNWcluster/ha/msg/ims_common
/opt/SUNWcluster/ha/msg/ims_fm_probe
/opt/SUNWcluster/ha/msg/ims_start_net
/opt/SUNWcluster/ha/msg/ims_stop_net

論理ホスト (たとえば/$LOGICAL_HOST) のシステムディスクのマウントポイントディレクトリから ims_ha.cnf ファイルを削除します。

Sun Cluster 3.0 U1 および U2 の Messaging Server HA サポートのアンインストール

この節では、Sun Cluster 3.0 U1 および U2 の HA 構成を取り消す方法を説明します。ここでは、「単純な例」で説明した単純な例の構成を前提としています。ほかの構成では、特定のコマンド (たとえば、手順 3) が異なる場合がありますが、それ以外の手順は同じです。

スーパーユーザ (root) になります。

以下の Sun Cluster コマンドを実行するには、スーパーユーザになる必要があります。

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

リソースグループのすべてのリソースをシャットダウンするには、次のコマンドを実行します。

# scswitch -F -g IMS-RG

これで、リソースグループ内のすべてのリソース (Messaging Server、LDAP、HA 論理ホスト名など) がシャットダウンされます。

個々のリソースを無効にします。

次のコマンドで、リソースグループからリソースを 1 つずつ無効にします。

# scswitch -n -j ha-ims
# scswitch -n -j ha-ldap
# scswitch -n -j ha-storage
# scswitch -n -j mail

リソースグループから個々のソースを削除します。

リソースを無効にしたら、次のコマンドで、リソースグループからリソースを 1 つずつ削除できます。

# scrgadm -r -j ha-ims
# scrgadm -r -j ha-ldap
# scrgadm -r -j ha-storage
# scrgadm -r -j mail

リソースグループを削除します。

リソースグループからすべてのリソースを削除したら、次のコマンドで、リソースグループそのものを削除できます。

# scrgadm -r -g IMS-RG

リソースタイプを削除します (省略可)。

クラスタからリソースタイプを削除する必要がある場合は、次のコマンドを実行します。

# scrgadm -r -t SUNW.ims
# scrgadm -r -t SUNW.nsldap
# scrgadm -r -t SUNW.HAStorage

モデル	長所	短所	推奨ユーザ
非対称	構成が単純バックアップノードが 100 パーセント確保される	マシンのリソースが十分に利用されない	将来に拡張予定のある小規模なサービスプロバイダ
対称	システムリソースを有効に利用できるより可用性が高い	バックアップノード上でのリソース競合ミラーディスクのためにディスク書き込みのパフォーマンスが低下する	近い将来にバックアップシステムの拡張予定のない中規模のサービスプロバイダ
N + 1	負荷が分散される拡張が簡単	構成が複雑	リソースの制約なしで分散を必要とする大規模なサービスプロバイダ

モデル	サーバ停止時間の確率
単一サーバ (High Availability なし)	Pr(down) = (システム停止 4 日 + ストレージ停止 1 日)/365 = 1.37%
非対称	Pr(down) = (システム停止 0 日 + ストレージ停止 1 日)/365 = 0.27%
対称	Pr(down) = (システム停止 0 日 + ストレージ停止 0 日)/365 = (ほぼ 0)
N + 1	Pr(down) = (システム停止 0 日 + ストレージ停止 1 日)/(365xN) = 0.27%/N

パラメータ	説明
MonitorInterval	プローブ実行の時間間隔 (秒単位)
MonitorTimeout	プローブがタイムアウトするまでの時間 (秒単位)
OnlineRetryLimit	オンライン再試行の回数
OnlineWaitLimit	オンライン手順の完了後、そのリソースがオンラインになるまで待機する MonitorInterval の数
RestartLimit	リソースにフェイルオーバーが適用されるまでの再起動回数

パラメータ	説明
State	サービスがオンライン状態にある (このシステムに存在する) かどうかを示す。ユーザがこの値を変更することはできない
InstanceName	Messaging Server のインスタンス名 (msg- 接頭辞なし)
LogHostName	このインスタンスに関連付ける論理ホスト名
PrtStatus	TRUE に設定すると、オンラインの状態が Veritas Cluster Server のログファイルに記録される
DebugMode	TRUE に設定すると、デバッグ情報が Veritas Cluster Server のログファイルに記録される

前へ目次索引 DocHome 次へ
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 2 月 26 日