iPlanet Messaging Server UNIX 用インストールガイド: 付録 A 高可用性 (High Availability、HA)

前へ目次索引 DocHome 次へ

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

付録 A 高可用性 (High Availability、HA)

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

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

 Veritas Cluster Server 1.1 以降または Sun Cluster 2.2 用の High Availability のインストール

 Sun Cluster 3.0 用の High Availability のインストール

 複数の Messaging Server インスタンスに関する注意事項

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

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

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

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

対称

N + 1 (N より 1 大きい)
以下の各項で、この 3 つのモデルについて詳細に説明します。HA 製品の種類によって、サポートされているモデルが異なる場合があります。どのモデルがサポートされているかについては、HA のマニュアルを参照してください。

非対称

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

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

対称

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

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

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

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

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

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

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

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

モデル

長所

短所

推奨ユーザ

非対称

構成が単純

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

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

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

対称

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

より可用性が高い

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

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

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

N + 1

負荷が分散される

拡張が簡単

構成が複雑

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

 システム停止時間の計算

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

表 A-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

Veritas Cluster Server 1.1 以降または Sun Cluster 2.2 用の High Availability のインストール

この節では、Veritas Cluster Server 1.1 以降または Sun Cluster 2.2 用の High Availability クラスタリングソフトウェアをインストールし、Messaging Server で使用できるように準備するために必要な情報を提供します (必要に応じて、Veritas Cluster Server または Sun Cluster のマニュアルで、詳細なインストール手順や情報を参照してください)。この節で使用する例は、単純な、2 つのノードを使用したクラスタサーバ (非対称モデル) をベースにしています。
基本的な非対称モデルでは、1 つの公共ネットワークインタフェースと 2 つの専用ネットワークインタフェース、および 1 つの共用ディスクを必要とします。専用ネットワークインタフェースは、クラスタ通信に使用されます。共用ディスクは、両方のノードに接続されている必要があります。

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

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

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

Veritas Clustering Software 1.1 以降では、エージェントタイプファイルは /etc/VRTSvcs/conf/config ディレクトリに、エージェントプログラムは
/opt/VRTSvcs/bin/MsgSrv ディレクトリにあります。Sun Cluster 2.2 では、エージェントは /opt/SUNWcluster/ha/msg ディレクトリにインストールされます。
Messaging Server のインストールおよび High Availability に関するいくつかの注意点を次に示します。

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

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

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

ディレクトリサーバ ID (第 3 章「インストールに関する質問」の手順 22 を参照) の指定を求められた場合は、ディレクトリサーバの完全指定 HA 論理ホスト名を指定します。この論理ホスト名を使用した接続が試みられるので、この論理ホスト名もアクティブである必要があります。

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

Veritas Cluster Server Agent のインストール

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

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

インストール前の手順

ここでは、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 をインストールし、2 番目のノードには High Availability コンポーネントのみをインストールする必要があります。High Availability コンポーネントのみをインストールするには、[iPlanet Server Products] メニューから iPlanet Messaging Suite コンポーネントのみを選択し、次に、[iPlanet Messaging Applications] メニューから High Availability コンポーネントのみを選択します。
Messaging Server のインストールの実行時に、setup プログラムは、Veritas Cluster Server がインストールされ、正しく設定されているかどうかを検査します。インストールと設定が正しく行われていれば、適切な High Availability ファイルがインストールされます。

インストール後の手順

ここまでの手順が完了したら、二次ノードで次の手順を実行する必要があります。

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

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

./setup

インストールタイプのリストから [Custom installation] を選択し、次に、[iPlanet Messaging Applications] コンポーネントの High Availability パッケージのみを選択します。
Veritas Cluster Server ソフトウェアをインストールしたマシンで、次の作業を実行します。

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
)
表 A-3 に、各パラメータの説明を示します。

表 A-3 MsgSrv のパラメータ

パラメータ

説明

MonitorInterval

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

MonitorTimeout

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

OnlineRetryLimit

オンライン再試行の回数

OnlineWaitLimit

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

RestartLimit

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

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

表 A-4 MsgSrv の引数

パラメータ

説明

State

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

InstanceName

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

LogHostName

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

PrtStatus

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

DebugMode

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

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

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

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

インストール前の手順

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

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

注 HA 障害監視エージェントは、Sun Cluster 2.2 SUNWscpro パッケージの tcpclnt バイナリファイルを必要とします。そのため、プローブ機能を十分に活用するには、このパッケージもインストールする必要があります。

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

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

High Availability のインストール

この時点で、Sun Cluster ソフトウェアがインストールされ、Messaging Server をインストールするための準備は完了しています。最初のノードに Messaging Server をインストールし、2 番目のノードには High Availability コンポーネントのみをインストールする必要があります (このとき、High Availability コンポーネントをインストールする前に、logical_IP と共用ディスクを二次ノードに切り替える必要があります)。High Availability コンポーネントのみをインストールするには、[iPlanet Server Products] メニューから iPlanet Messaging Suite コンポーネントのみを選択し、次に、[iPlanet Messaging Applications] メニューから High Availability コンポーネントのみを選択します。
Messaging Server のインストールの実行時に、setup プログラムは、Sun Cluster ソフトウェアがインストールされ、正しく設定されているかどうかを検査します。インストールと設定が正しく行われていれば、適切な High Availability ファイルがインストールされます。

インストール後の手順

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

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

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

./setup

インストールタイプのリストから [Custom Installation] を選択し、次に、iPlanet Messaging Applications コンポーネントの High Availability パッケージのみを選択します。
これらの手順が完了したら、server-root/bin/msg/ha/sc/config/ims_ha.cnf を、共用ディスクのマウントポイントディレクトリにコピーする必要があります。たとえば、共用ディスクが /mnt ディレクトリの下にマウントされている場合は、/mnt ディレクトリにコピーします。
さらに、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 チームによりサポートされています。

Veritas Cluster Server 1.1 以降または Sun Cluster 2.2 のアンインストール

Veritas Cluster Server および Sun Cluster 2.2 をアンインストールするには、次の手順に従います。

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

複数のインスタンスがインストールされている場合は、/etc/msgregistry.inf ファイルから、目的のインスタンスのエントリを削除します。インストールされているインスタンスが 1 つの場合は、両方のノードで、/etc/msgregistry.inf ファイルを削除します。
ここからは、Veritas Cluster Server か Sun Cluster のどちらを削除するかによって、アンインストールの手順が異なります。Veritas Cluster Server 1.1 以降の 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 コンポーネントをアンインストールするには、次の手順に従います。

両方のノードで、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 ファイルから削除します。

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

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

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

hareg -u ims50

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

/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

共用ディスクのマウントポイントディレクトリ (共用ディスクが /mnt ディレクトリの下にマウントされている場合は /mnt) から、ims_ha.cnf ファイルを削除します。

Sun Cluster 3.0 用の High Availability のインストール

この節では、Sun Cluster 3.0 Highly Available (HA) Data Service のインストールと構成の方法を説明します。Sun Cluster 3.0 のマニュアルは、次の場所で参照できます。
http://docs.sun.com/ab2/coll.572.7/

Sun Cluster 3.0 の制限事項とパフォーマンス

Veritas File System (VxFS) は、このリリースではサポートされていません。(Sun Cluster 3.1 ではサポートを予定しています。)

ローリングアップグレードのサポートはありません。

Sun Cluster 3.0 の前提条件

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

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

Netscape Directory Server の HA エージェント (Sun Cluster 3.0 Agents CDROM にある) がインストールされている。

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

Sun Cluster 3.0 の Messaging Server HA サポートのインストール

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

Sun Cluster 3.0 CDROM (704-7524-10) の SUNWscdev

iPlanet Messaging Server CD の solaris/sc30 ディレクトリ内の SUNWscsdk。これは、Sun Cluster 3.0 Cool Stuff CDROM (704-7494-10) の SUNWscsdk パッケージのアップデート版です。Sun Cluster 3.0 Cool Stuff CDROM のこのバージョンには、メモリーリーク (バグ ID : 4398767) が含まれています

iPlanet Messaging Server CD の solaris/iMS_sc30 ディレクトリ内の SUNWscims
各クラスタノードで、pkgadd コマンドを使用して、これらのパッケージをインストールします。たとえば、パッケージが現在の作業用ディレクトリにある場合は、次のコマンドを使用してインストールします。
# pkgadd -d . SUNWscsdk SUNWscdev SUNWscims
3 つのパッケージをインストールすると、Messaging Server を HA 用に構成できるようになります。

Sun Cluster 3.0 の Messaging Server HA サポートの構成

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

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

単純な例

この例では、Messaging Server とディレクトリサーバが同じクラスタノードで実行され、同じ HA 論理ホスト名と IP アドレスを使用するものとします。物理ホスト名は mail-1 と mail-2 で、HA 論理ホスト名は mail とします。図 A-4 は、Messaging Server HA サポートの構成時に作成する各種の HA リソースの依存関係を入れ子構造で示しています。
図 A-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 をインストールします。2 番目のノードに /etc/msgregistry.inf を複製する必要があります。

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

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

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

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

複雑な例

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

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

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

メッセージストアパーティションと MTA メッセージキューが含まれている別のファイルシステム
図 A-5 は、Sun Cluster のリソースグループを使用してこれらの依存関係を実現する方法を示します。この図には、各リソースのキーパラメータが示されています。この構成を実現するために必要なコマンドを、図の後に示します。
図 A-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-2LDAP-USER-RG リソースグループを作成

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

# 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-serverrootLDAP をオンラインにする
# 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

Sun Cluster 3.0 の Messaging Server HA サポートの構成解除

この節では、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

複数の Messaging Server インスタンスに関する注意事項

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

注 Messaging Server のインストールでは、インストール処理中はメールサービスをオフラインにする必要があります。メールサービスが動作していると、Messaging 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 インスタンスの使用方法によって決まります。追加インスタンスのフェイルオーバーを既存のインスタンスとは別のものにする場合は、追加インスタンス用の新しいリソースグループを作成します。ただし、既存インスタンスのフェイルオーバーに伴って追加インスタンスがフェイルオーバーするような場合は、両方のインスタンスに同じリソースグループを使用させるほうがよいでしょう。

同じサーバ上にある各 Messaging Server の IP アドレスのバインド

同じサーバで複数の Messaging Server インスタンスを実行する場合、各インスタンスに正しい IP アドレスをバインドする必要があります。以下の項で、各インスタンスの IP アドレスをバインドする方法を説明します。これを正しく行わないと、複数のインスタンスが互いに悪影響を及ぼす可能性があります。ここに示す手順は、Sun Cluster 2.2、Sun Cluster 3.0、および Veritas Cluster Server に該当します。
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」と答えます。

このスクリプトの実行例を次に示します。

# su root
# <server-root>/bin/msg/install/bin/ha_ip_config

Please specify the IP address assigned to the HA logical host name.Use dotted decimal form, a.b.c.d

Logical IP address: 10.0.37.10

Please specify the path to the top level directory in which iMS is installed.This is the server root directory which contains the instance directories.

iMS server root: /opt/iplanet/server5

Next, please specify the name of the iMS instance for which to effect the configuration changes.Omit the leading "msg-" from the name.Possible instances include:

mail-1
mail-2

iMS instance name [mail-1]: mail-1

Also configure an LDAP server instance in the same iMS server root [yes]? yes

Please specify the name of the LDAP server instance for which to effect the configuration changes.This LDAP server instance must live in a subdirectory of the iMS server root previously specified.Omit the leading "slapd-" from the LDAP server instance name. Possible instances include:

elenchus

LDAP instance name [elenchus]: elenchus

Logical IP address: 10.0.37.10
iMS server root: /opt/iplanet/server5
iMS instance name: mail-1
LDAP instance name: elenchus

Do you wish to change any of the above choices (yes/no) [no]? no

Updating the file /opt/iplanet/server5/msg-mail-1/imta/config/dispatcher.cnf
Updating the file /opt/iplanet/server5/msg-mail-1/imta/config/job_controller.cnf
Updating the file /opt/iplanet/server5/slapd-elenchus/config/slapd.conf
Setting the service.listenaddr configutil parameter
Configuration successfully changed

#

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

ノードのテスト

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

モデル	長所	短所	推奨ユーザ
非対称	構成が単純バックアップノードが 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 © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.

Last Updated July 19, 2001