Sun ロゴ      前へ      目次      索引      次へ     

Sun ONE Messaging Server 6.0 インストールガイド (Solaris 版)

第 3 章
High Availability 機能の設定

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

Messaging Server でサポートされている High Availability モデルの詳細については、以下の製品マニュアルを参照してください。

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

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

以下の各項で、この 3 つのモデルについて詳細に説明します。さらに、次の内容についても説明します。

HA 製品の種類によって、サポートされているモデルが異なる場合があります。サポートされているモデルについては、HA のマニュアルを参照してください。

非対称

基本的な非対称 (ホットスタンバイ) High Availability モデル (図 3-1) は、クラスタ化された 2 つのホストマシン、つまり、「ノード」で構成されます。どちらのノードにも、1 つの論理 IP アドレスと関連ホスト名が割り当てられています。

このモデルでは、一方のノードのみが常にアクティブになり、バックアップまたはホットスタンバイ用のノードは、ほとんどの時間アイドル状態のままです。両方のノードで共用される単一のディスクアレイは、アクティブなノード、つまり、「主要」ノードによって構成および制御されます。メッセージストアパーティションおよび MTA (Message Transfer Agent) キューは、この共用ボリュームに置かれます。

図 3-1 非対称 High Availability モデル

非対称 High Availability モデル

フェイルオーバーが実行される前は、アクティブノードは物理ホスト A です。フェイルオーバーの実行後は、物理ホスト B がアクティブノードになり、共用ボリュームは物理ホスト B に制御されるように切り替えられます。物理ホスト A のすべてのサービスが停止され、同じサービスが物理ホスト B で開始されます。

このモデルの利点は、バックアップノードが主要ノードのバックアップ専用に確保されていることです。したがって、フェイルオーバーの適用時に、バックアップノードでリソースの競合が発生することはありません。ただし、このモデルでは、バックアップノードはほとんどの時間アイドル状態にあるため、その間、このリソースを無駄に使用していることになります。

対称

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

対称 High Availability モデル (図 3-2) では、両方のノードが同時にアクティブ状態にあり、それぞれのノードが他方のバックアップノードの働きをします。通常の状況では、各ノードは、Messaging Server の 1 つのインスタンスだけを実行します。

図 3-2 対称 High Availability モデル

対称 High Availability モデル

フェイルオーバーの実行時には、障害のあるノードのサービスがシャットダウンされ、同じサービスがバックアップノードで再開されます。この時、バックアップノードは、両ノードの Messaging Server を実行し、個別の 2 つのボリュームを制御します。

このモデルの利点は、両方のノードが同時にアクティブ状態にあるので、マシンのリソースを十分に利用できることです。ただし、障害が発生している間、バックアップノードが両ノードの Messaging Server のサービスを実行するので、バックアップノードでのリソースの競合が増えます。したがって、障害のあるノードをできるだけ早く修復し、サーバーを本来の二重サービスの状態に戻す必要があります。

このモデルには、バックアップストレージアレイも備えられています。つまり、一方のディスクアレイに障害が生じた場合、バックアップノードのサービスが、そのミラーイメージを引き継ぐことができます。

対称モデルを設定するには、共用ディスク上に共用バイナリをインストールする必要があります。そのため、ローリングアップグレードが実行できない場合があることに注意してください。ローリングアップグレードは、Messaging Server のパッチリリース中にシステムをアップグレードすることができる機能です (これは将来のリリースで利用できるようになります)。

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

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

図 3-3 は、基本的な N + 1 High Availability モデルを示しています。

図 3-3 N + 1 High Availability モデル

N + 1 High Availability モデル

1 つ以上のアクティブノードにフェイルオーバーが適用されると、バックアップノードが、障害のあるノードのサービスを引き継ぎます。

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

N + 1 モデルを設定するには、対称モデルと同様に、共用ディスク上に共用バイナリをインストールする必要があります。そのため、ローリングアップグレードが実行できない場合があることに注意してください。ローリングアップグレードは、Messaging Server のパッチリリース中にシステムをアップグレードすることができる機能です (これは将来のリリースで利用できるようになります)。

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

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

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

モデル

長所

短所

推奨ユーザー

非対称

  • 構成が単純
  • バックアップノードが 100 パーセント確保される
  • マシンのリソースが十分に利用されない

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

対称

  • システムリソースを有効に利用できる
  • より可用性が高い
  • バックアップノード上でのリソース競合
  • ミラーディスクのためにディスク書き込みのパフォーマンスが低下する

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

N + 1

  • 負荷が分散される
  • 拡張が簡単
  • 構成が複雑

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

システム停止時間の計算

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

表 3-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 または Sun Cluster の High Availability のクラスタリングソフトウェアを構成し、Messaging Server で使用するための準備に必要な情報について説明します。(必要に応じて、Veritas または Sun Cluster Server のマニュアルで、詳細なインストール手順、必要なパッチ、および情報を参照してください。)

表 3-3 は、Messaging Server で現時点でサポートされている Sun Cluster Server および Veritas Cluster Server のバージョンのリストです。

表 3-3 Sun Cluster Server および Veritas Cluster Servers のサポートされているバージョン

クラスタ

サポートされているバージョン

Sun Cluster Server

Sun Cluster 3.0 Update 3 および Sun Cluster 3.1

Veritas Cluster Server

Veritas Cluster Server 1.3、Veritas Cluster Server 2.0、および Veritas Cluster Server 3.5

バージョンサポートの最新のアップデートについては、『Sun ONE Messaging Server 6.0 リリースノート』を参照してください。

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

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

クラスタエージェントは、クラスタフレームワークのもとで動作する Messaging Server プログラムです。

Sun Cluster Messaging Server エージェント (SUNWscims) は、Java Enterprise System インストーラから Sun Cluster 3.1 を選択したときにインストールされます。Veritas Cluster Messaging Server エージェント (SUNWmsgvc) は、Java Enterprise System CD の Messaging Server Product サブディレクトリにあります。(VCS クラスタエージェントをインストールするには、pkgadd(1M) コマンドを使用する必要があります。)

Messaging Server および High Availability (Veritas Cluster および Sun Cluster の両方に適用される) のインストールに関して次のことに注意してください。

useconfig ユーティリティの使用

useconfig ユーティリティを使用することで、HA 環境の複数のノード間で単一の設定を共有することができます。このユーティリティは、既存の設定をアップグレードまたはアップデートするものではありません。

たとえば、最初のノードをアップグレードする場合は、Java Enterprise System インストーラからインストールを行ってから、Messagng Server を設定します (第 2 章「Messaging Server のインストール」を参照)。そのあと、Java Enterprise System インストーラを使って Messaging Server パッケージをインストールする 2 番目のノードにフェイルオーバーします。ただし、初期実行時設定プログラム (configure) をもう一度実行する必要はありません。代わりに、useconfig ユーティリティを使用することができます。

このユーティリティを使用するには、useconfig ユーティリティを実行して、以前の Messaging Server 設定をポイントします。

msg_svr_base/sbin/useconfig install/configure_YYYYMMDDHHMMSS

ここで、configure_YYYYMMDDHHMMSS は前の構成設定ファイルです。

新しいノードには、共用ディスク上の msg_svr_base/data/setup ディレクトリに configure_YYYYMMDDHHMMSS があります。

注

Messenger Express の HTML ファイルは、useconfig コマンドでは更新されません。そのため、HTML ファイルをカスタマイズしている場合は、新しいテンプレートを使用して、それらのファイルを手作業で更新する必要があります。HTML ファイルをカスタマイズしていない場合は、新しいテンプレートを config ディレクトリにコピーするだけですみます。

# cp -rpf msg_svr_base/lib/config-templates/html msg_svr_base/config

「Veritas Cluster Server エージェントのインストール」および「Sun クラスタエージェントのインストール」の以下の節には、useconfig ユーティリティをいつ使用できるかが記載されています。

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

Messaging Server は、Veritas Cluster Server 1.3、2.0、および 3.5 とともに設定することができます。この節で示す手順では、Veritas Cluster 3.5 のみを取り上げています。Veritas 1.3 および 2.0 については、『Messaging Server 5.2 インストールガイド』を参照してください。

次の手順を実行する前に、Veritas Cluster Server マニュアルを再度お読みください。

注

  • Veritas Volume Manager (VxVM) には、別のライセンスを必要とするクラスタ機能があります。この機能では、Sun Cluster 3.0 グローバルファイルシステム同様、共有ストレージ上のファイルシステムを概観できます。詳細は、Veritas Cluster Server のマニュアルを参照してください。
  • FsckOpt は、3.5 より以前の Veritas リリースではオプションでしたが、Mount リソースの設定には必須です。FsckOpt には -y または -n を付ける必要があります。そうしないと、リソースがオンラインになりません。
  • Veritas Cluster Server 2.0 Explorer は、Veritas Cluster Server 3.5 の管理には使用できません。

Java Enterprise System インストーラからの Messaging Server のインストールと HA の設定が完了したあと、HA サポートに関連するその他の手順を「サーバー上での IP アドレスのバインド」で確認してください。

Veritas Cluster Server 要件

VCS 3.5 インストールおよび設定上の注意

次の手順では、Veritas Cluster Server 3.5 を使用して Messaging Server を HA サービスとして設定する方法を説明します。

デフォルトの main.cf 設定ファイルは、VCSweb アプリケーションを起動する ClusterService と呼ばれるリソースグループを設定します。このグループには、csgnic や webip などの、ネットワーク論理ホスト IP リソースが含まれます。また、ntfr リソースは、イベント通知用に作成されます。

  1. ノードの 1 つから Cluster Explorer を起動します。

    2. この Veritas Cluster Server の手順では、Messaging Server を HA サービスとして設定する際にグラフィカルユーザーインタフェースを使用すると仮定しています。

    Cluster Explorer を起動するには、以下のコマンドを実行します。

    # /opt/VRTSvcs/bin/hagui

    GUI を使用するために、VRTScscm パッケージをインストールする必要があります。

  2. タイプ DiskGroup の s1ms_dg ディスクグループリソースを追加して、有効にします。
  3. タイプ Mount の s1ms_mt マウントリソースを追加します。
    1. Veritas Cluster Server 2.0 とは異なり、-y (または -n) を FsckOpt に追加する必要があります。NULL オプションは、Mount をハングさせます。fsck_vxfs の詳細については、Solaris のマニュアルページを参照してください。
    2. リンクしているリソースがまだ有効になっていない場合は、「リンク」ボタンを使って、必ずそのリソースを有効にしてください。
  4. s1ms_mt と s1ms_dg の間のリンクを作成します。リソース s1ms_mt を有効にします。

    5. 次の依存関係ツリーを見てください。
    VCS 依存関係ツリー。s1ms_dg と slms_dg の間に作成されたリンク。

  5. Messaging Server を選択して、Java Enterprise System インストーラを実行します。
    1. 主要ノード (たとえば、Node_A) から Messaging Server 初期実行時設定を実行して (第 2 章「Messaging Server のインストール」 を参照)、Messaging Server をインストールします。
    2. pkgadd(1M) コマンドを使用して、Veritas Cluster Server エージェントパッケージ、SUNWmsgvc (Java Enterprise System CD の Messaging Server Product サブディレクトリ内) をインストールします。
    3. インストール中にホスト名または IP アドレスが要求されるときは常に、論理ホスト名と論理 IP アドレスが指定されていることを確認します。

      4. これで、Messaging Server と Veritas エージェントが Node_A にインストールされます。

  6. バックアップノード (たとえば、Node_B) に切り替えます。
  7. Java Enterprise System インストーラを実行して、バックアップノード (Node_B) に Messaging Server をインストールします。
  8. Messaging Server をインストールしたあと、useconfig ユーティリティを使用することにより、バックアップノード (Node_B) に追加の初期実行時設定を作成する必要がなくなります。useconfig ユーティリティを使用することで、HA 環境の複数のノード間で単一の設定を共有することができます。このユーティリティは、既存の設定をアップグレードまたはアップデートするものではありません。「useconfig ユーティリティの使用」を参照。

    9. これで、Veritas エージェントが Node_B にインストールされます。

  9. Cluster Explorer で、「ファイル」メニューから「Import Types...」を選択し、ファイル選択ボックスを表示します。
  10. /etc/VRTSvcs/conf/config ディレクトリから MsgSrvTypes.cf タイプをインポートします。このタイプファイルをインポートします。このファイルを検索するときは、クラスタノード上にいる必要があります。
  11. ここで、タイプ MsgSrv のリソース (たとえば、Mail) を作成します。このリソースは、論理ホスト名プロパティの設定に必要です。
  12. Mail リソースは、s1ms_mt および webip によって決まります。以下の依存関係ツリーに示されているように、リソース間のリンクを作成します。
    VCS 依存関係ツリー:リンクは Mail と webip および s1ms_mt 間に作成されています。
    1. すべてのリソースを有効にし、Mail をオンラインにします。
    2. すべてのサーバーが起動されます。
  13. Node_A に切り替えて、High Availability の設定が機能しているかどうかをチェックします。
  14. グループ属性 OnlineRetryLimit を 3 から 0 に変更します。変更しないと、フェイルオーバーしたサービスが同じノード上で再起動することがあります。

MsgSrv 属性

この節では、mail リソースの動作を管理する MsgSrv のその他の属性について説明します。Veritas Cluster Server で Messaging Server を設定するには、表 3-4 を参照してください。

表 3-4 Veritas Cluster Server 属性 

属性

説明

FaultOnMonitorTimeouts

設定解除 (=0) の場合、監視 (プローブ) タイムアウトはリソースの障害としては扱われません。推奨される設定は 2 です。監視のタイムアウトが 2 回になると、リソースが再起動またはフェイルオーバーします。

ConfInterval

障害や再起動がカウントされる時間間隔。サービスがこの時間の間オンラインになっていると、以前の履歴は消去されます。600 ミリ秒を推奨。

ToleranceLimit

リソース FAULTED を宣言するために監視が OFFLINE を返す回数。この値は 0 (デフォルト) のままにしてください。

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

この節では、Sun Cluster の Highly Available (HA) Data Service のインストールおよび設定方法を説明します。このインストール手順は、Sun Cluster 3.0 Update 3 および Sun Cluster 3.1 の両方に適用されます。この節には、以下の項目があります。

Sun Cluster 3.0 Update 3 および Sun Cluster 3.1 のマニュアルは、次の場所で参照できます。

http://docs.sun.com/db/prod/cluster#hic

Veritas File System (VxFS) は、Sun Cluster 3.0 Update 3 および Sun Cluster 3.1 でサポートされています。

Sun Cluster の要件

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

Sun Cluster の Messaging Server HA サポートの設定

この節では、Sun Cluster 3.0 Update 3 および 3.1 の Sun ONE Messaging Server の HA サポートを設定する方法を、単純な例を使って説明します。

HA を設定したら、「サーバー上での IP アドレスのバインド」で、HA サポートに関連する追加の手順を確認してください。

以下の例では、メッセージングサーバーが HA 論理ホスト名および IP アドレスによって設定されていると仮定しています。物理ホスト名は mail-1 と mail-2 で、HA 論理ホスト名は budgie とします。図 3-4 に、Messaging Server HA サポートの構成時に作成する各種の HA リソースの依存関係を入れ子構造で示します。

図 3-4 単純な Sun ONE Messaging Server HA 構成

単純な Messaging Server HA 構成

  1. スーパーユーザーになり、コンソールを開きます。

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

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

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

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

  3. Messaging Server のリソースグループを作成します。

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

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

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

  4. HA 論理ホスト名リソースを作成し、リソースグループを起動します。

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

    # scrgadm -a -L -g MAIL-RG -l budgie
    # scswitch -Z -g MAIL-RG

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

    6. Messaging Server が依存するファイルシステムの HA ストレージリソースタイプを作成する必要があります。次のコマンドは、disk-rs という HA ストレージリソースを作成し、ファイルシステム disk_sys_mount_point を、その制御下に配置します。

    # scrgadm -a -j disk-rs -g MAIL-RG ¥
    -t SUNW.HAStorage ¥
    -x ServicePaths=disk_sys_mount_point-1, disk_sys_mount_point-2

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

  6. Messaging Server をインストールして設定します (第 2 章「Messaging Server のインストール」)。必ず、手順 4 で作成した HA 論理ホスト名を使用してください。
    1. 初期実行時設定で、「Messaging Server の初期実行時設定の作成」の手順 3 で設定ディレクトリを指定するよう求められます。必ず、HA ストレージリソース (または、「HAStoragePlus を有効にする」で説明されている HAStoragePlus リソース) の共用ディスクのディレクトリパスを使用してください。
    2. 次のコマンドを実行して、Sun Cluster の下で watcher プロセスを有効にしてください。

      configutil -o local.autorestart -v 1

      3. watcher プロセスの詳細は、『Sun ONE Messaging Server 6.0 管理者ガイド』を参照してください。

  7. ha_ip_config スクリプトを実行して、service.listenaddr と service.http.smtphost を設定し、High Availability 用に dispatcher.cnf および job_controller.cnf ファイルを設定します。このスクリプトでは、物理 IP アドレスではなく論理 IP アドレスがこれらのパラメータやファイルに設定されます。

    8. スクリプトの実行手順については、「サーバー上での IP アドレスのバインド」を参照してください。

    ha_ip_config スクリプトは、(設定とデータ用の) 共用ディスクがあるマシン上で、1 回だけ実行する必要があります。

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

    9. HA Messaging Server リソースを作成し、これをリソースグループに追加します。このリソースは、HA 論理ホスト名リソースと HA ディスクリソースに依存します。

    HA Messaging Server リソースを作成するときは、Messaging Server のトップレベルディレクトリへのパス (msg_svr_base パス) を指定する必要があります。これには、次に示すように、IMS_serverroot 拡張プロパティを使用します。

    # scrgadm -a -j mail-rs -t SUNW.ims -g MAIL-RG ¥
              -x IMS_serverroot=msg_svr_base ¥
              -y Resource_dependencies=disk-rs,budgie

    上記のコマンドは、msg_svr_base ディレクトリ内の IMS_serverroot にインストールされている Messaging Server に、mail-rs という HA Messaging Server リソースを作成します。この HA Messaging Server リソースは、HA ディスクリソース disk-rs、および HA 論理ホスト名 budgie に依存します。

    Messaging Server が追加のファイルシステムとの依存関係を持つ場合は、そのファイルシステム用に追加の HA ストレージリソースを作成できます。上記のコマンドの Resource_dependencies オプションに、追加する HA ストレージリソースの名前が含まれていることを確認してください。

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

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

    # scswitch -e -j mail-rs

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

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

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

  11. フェイルオーバーを適切に動作させるため、もう 1 つのクラスタノードにリソースグループの処理を継続させます。

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

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

HAStoragePlus を有効にする

SUNW.HAStoragePlus は、Sun Cluster 環境内でローカルにマウントされたファイルシステムの High Available を利用可能にするために使用できるリソースタイプです。Sun Cluster グローバルデバイスグループに常駐するファイルシステムは、HAStoragePlus で使用できます。HAStorage のようなグローバルにマウントされたファイルシステムとは異なり、HAStoragePlus は一定期間に 1 つのクラスタノードでのみ利用できます。これらのローカルにマウントされたファイルシステムは、フェイルオーバーモードとフェイルオーバーリソースグループのみで使用できます。HAStoragePlus は、HAStorage の GFS (グローバルファイルシステム) とは異なり、FFS (フェイルオーバーファイルシステム) を提供します。

HAStoragePlus には、多くの利点があります。

HAStoragePlus の詳細は、『Sun Cluster 3.1 データサービスの計画 / 管理者ガイド』を参照してください。

クラスタ上で HAStoragePlus を有効にするには、次の手順を行います。

  1. 次のようにして、メッセージングとストレージのリソースを無効にします。

    2. # scwitch -n -j mail-rs
    # scwitch -n -j disk-rs

  2. 次のようにして、メッセージングとストレージのリソースを削除します。

    3. # scrgadm -r -j mail-rs
    # scrgadm -r -j disk-rs

  3. ディスクタイプ SUNW.HAStoragePlus を作成します。

    4. # scrgadm -a -t SUNW.HAStoragePlus

  4. ディスクリソースと、HAStoragePlus とのリソースの依存関係を作成します。

    5. HA ストレージリソース
    # scrgadm -a -j disk-rs -g MAIL-RG ¥
              -t SUNW.HAStoragePlus ¥
             -x FileSystemMountPoints=file_sys_mount_point-1

    Messaging Server リソース
    # scrgadm -a -j mail-rs -g MAIL-RG ¥
              -x IMS_serverroot=msg_svr_base
             -y Resource_dependencies=disk-rs,budgie

  5. /etc/vfstab ファイルから global という語を削除します。ブートアップでは、/etc/vbstab が「no」に設定されている必要があります。詳細については、Sun Cluster 3.1 のマニュアルを参照してください。

    6. HAStoragePlus で vfstab ファイルが有効になる前に、最初に、現在のグローバルファイルシステムであるファイルシステムを umount する場合があります。そのあと、HAStoragePlus で vfstab ファイルを有効にし、ファイルシステムを再マウントすることができます。

  6. クラスタサーバーを起動します。

    7. # scswitch -Z -g MAIL-RG

サーバー上での IP アドレスのバインド

「対称」High Availability モデルまたは「N + 1」High Availability モデルを使用する場合は、Sun Cluster Server を Messaging Server に対応させるために、構成で注意すべき事項がいくつかあります。

サーバー上で動作する Messaging Server は、正しい IP アドレスによってバインドされる必要があります。これは HA 環境で Messaging を正しく設定するために必要です。

Messaging Server を HA 対応に構成する過程で、Messaging Server がバインドされて接続を待機するインタフェースアドレスを設定します。デフォルトでは、各サーバーは使用可能なすべてのインタフェースアドレスにバインドされます。ただし、HA 環境では、HA 論理ホスト名に関連付けられたインタフェースアドレスに限定して各サーバーをバインドする必要があります。

上記のようなバインドが簡単に行えるように、特定の Messaging Server インスタンスに属するサーバーが使用するインタフェースアドレスの構成を行うためのスクリプトが用意されています。このスクリプトでは、ユーザーが所有する IP アドレス、またはサーバーが使用する HA 論理ホスト名に関連付ける IP アドレスから、適切なインタフェースアドレスを特定します。

このスクリプトは、以下の設定ファイルを修正または作成することによって、構成を変更します。

msg_svr_base/config/dispatcher.cnf

このファイルでは、SMTP サーバーおよび SMTP 送信サーバーの INTERFACE_ADDRESS オプションを追加または変更します。

msg_svr_base/config/job_controller.cnf

この操作によって、ジョブコントローラの INTERFACE_ADDRESS オプションが追加または変更されます。

最後に、POP、IMAP、および Messenger Express HTTP サーバーが使用する configutil service.listenaddr および service.http.smtphost パラメータを設定します。

元の設定ファイルがある場合、それらのファイルは *.pre-ha という名前に変更されます。

このスクリプトを実行するには、次の手順に従います。

  1. スーパーユーザーになります。
  2. msg_svr_base/sbin/ha_ip_config を実行します。
  3. スクリプトによって、以下の質問が表示されます。Control キーを押しながら d キーを押すと、どの質問の段階でもスクリプトを中止できます。デフォルトの設定は、各括弧 ([ ]) 内に表示されています。デフォルトの設定を選択する場合は、Return キーを押します。
    1. Logical IP address : 論理 IP アドレス。Messaging Server が使用する論理ホスト名に割り当てられた IP アドレスを指定します。この IP アドレスは、「123.456.78.90」のように、ドット付きの 10 進形式で指定する必要があります。

      2. 論理 IP アドレスは、configutil パラメータ service.http.smtphost に自動的に設定されます。このパラメータにより、クラスタ内でメッセージングシステムが実行されているマシンを参照することができます。たとえば Messenger Express を使用している場合、サーバーは、送信メールの送り先メールホストを判断できます。

    2. Messaging Server Base (msg_svr_base) : Messaging Server ルート。Messaging Server をインストールする最上位ディレクトリの絶対パスを指定します。
    3. Do you wish to change any of the above choices : 選択した項目を変更するかどうか。これまでに回答した内容でよい場合は、「no」と答えて、設定の変更を確定します。回答を変更する場合は、「yes」と答えます。

      注

      また、ha_ip_config スクリプトでは、パラメータ local.autorestart および local.watcher.enable を使用して、2 つの新しいプロセス watcher および msprobe を自動的に有効にします。これらの新しいパラメータは、メッセージングサーバーの状況を監視する際に役立ちます。プロセスの障害や反応しないサービスによって、特定の障害を示すログメッセージが生成されます。現在、クラスタエージェントは watcher プロセスを監視し、それが存在するときは必ずフェイルオーバーします。Sun Cluster を正しく機能させるために、パラメータを有効にしておく必要があります。

      watcher プロセスと msprobe プロセスの詳細については、『Sun ONE Messaging Server 6.0 リリースノート』を参照してください。

High Availability の構成の解除

この節では、High Availability の構成を解除する方法を説明します。High Availability をアンインストールするには、Veritas または Sun Cluster のマニュアルに記載されている手順に従ってください。

High Availability の構成の解除手順は、Veritas Cluster Server か Sun Cluster のどちらを削除するかによって異なります。

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

Veritas Cluster Server の構成の解除

Veritas Cluster Server の High Availability コンポーネントの構成を解除するには、次の手順に従います。

  1. iMS5 サービスグループをオフラインにし、そのリソースを無効にします。
  2. mail リソース、logical_IP リソース、および mountshared リソースの間の依存関係を解除します。
  3. iMS5 サービスグループをオンラインに戻します。sharedg リソースが有効になります。
  4. インストール時に作成した Veritas Cluster Server リソースをすべて削除します。
  5. Veritas Cluster Server を停止し、両方のノードで次のファイルを削除します。

    6. /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

  6. Messaging Server のエントリを両方のノードの/etc/VRTSvcs/conf/config/main.cf ファイルから削除します。
  7. 両方のノードから /opt/VRTSvcs/bin/MsgSrv/ ディレクトリを削除します。

Sun Cluster 3.ｘ の Messaging Server HA サポートの構成の解除

この節では、Sun Cluster の HA 構成を取り消す方法を説明します。ここでは、「Sun クラスタエージェントのインストール」で説明した単純な例の構成を前提としています。ほかの構成では、特定のコマンド (たとえば、手順 3) が異なる場合がありますが、それ以外の手順は同じです。

  1. スーパーユーザーになります。

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

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

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

    # scswitch -F -g MAIL-RG

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

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

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

    # scswitch -n -j mail-rs
    # scswitch -n -j disk-rs
    # scswitch -n -j budgie

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

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

    # scrgadm -r -j mail-rs
    # scrgadm -r -j disk-rs
    # scrgadm -r -j budgie

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

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

    # scrgadm -r -g MAIL-RG

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

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

    # scrgadm -r -t SUNW.ims
    # scrgadm -r -t SUNW.HAStoragePlus



前へ      目次      索引      次へ     

Copyright 2003 Sun Microsystems, Inc. All rights reserved.