Sun Java System Messaging Server 6.3 管理ガイド

第 3 章高可用性の設定

この節では、Veritas Cluster Server または Sun Cluster の高可用性のクラスタリングソフトウェアを設定し、Messaging Server で使用するための準備に必要な情報について説明します。『Sun Java Communications Suite 5 配備計画ガイド』の第 6 章「サービスの可用性の設計」を読んでおくことを前提にしています。また、Veritas または Sun Cluster Server のマニュアルで、詳細な計画、インストール手順、必要なパッチなどの情報を必要に応じて参照してください。

この章には、次の節があります。

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

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

x86/SPARC 版の Solaris 9 および Solaris 10 の場合:

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


クラスタ	サポートされているバージョン
Sun Cluster Server	Sun Cluster 3.0 & 3.1
Veritas Cluster Server	Veritas Cluster Server 1.3、Veritas Cluster Server 2.0、および Veritas Cluster Server 3.5

3.2 高可用性モデル

Messaging Server で使用可能な高可用性モデルは各種あります。基本的なモデルは次の 3 つです。

非対称
対称
N+1 (N Over 1)

それぞれのモデルの詳細については、以降の項で説明します。また、次の内容について扱います。

HA 製品の違いによって、サポートされるモデルも異なるとは限りません。サポートされるモデルを判断するには、HA のマニュアルを参照してください。

3.2.1 非対称

基本的な非対称 (ホットスタンバイ) 高可用性モデルは、2 つのクラスタ化されたホストマシン (ノード) で構成されます。1 つの論理 IP アドレスおよび 1 つの関連付けられたホスト名が両方のノードに指定されます。

このモデルでは、常に 1 つのノードだけがアクティブであり、バックアップ (ホットスタンバイ) ノードは、ほとんどの時間がアイドル状態です。両方のノード間に単一の共有ディスクアレイが構成され、アクティブノードまたは第一のノードにより管理されます。メッセージストアのパーティションと Mail Transport Agent (MTA) キューは、この共有ボリュームにあります。

図 3–1 非同期高可用性モード

この図は 2 つの物理ノード、物理-A および物理-B を示しています。フェイルオーバー前のアクティブなノードは物理-A です。フェイルオーバーが発生すると、物理-B がアクティブなノードになり、共有ボリュームが物理-B によって管理されるように切り替えられます。物理-A ですべてのサービスが停止し、物理-B ですべてのサービスが起動します。

このモデルの利点は、バックアップノードが第一のノード専用に、完全に予約されていることです。また、フェイルオーバーが発生したときにバックアップノードでリソースの競合はありません。ただしこのモデルでは、ほとんどの時間、バックアップノードがアイドル状態であるため、このリソースは十分に活用されていません。

3.2.2 対称

基本的な対称 (「デュアルサービス」) 高可用性モデルは、2 つのホスティングマシンで構成され、それぞれのマシンには専用の論理 IP アドレスが割り当てられています。論理ノードにはそれぞれ 1 つの物理ノードが関連付けられ、各物理ノードは 2 つのストレージボリュームを持つ 1 つのディスクアレイを制御します。一方のボリュームは、ローカルのメッセージストアパーティションおよび MTA キューに使用され、もう一方のボリュームは、相手ノードのメッセージストアパーティションおよび MTA キューのミラーイメージに使用されます。

次の図は、対称高可用性モードを示しています。両方のノードは同時にアクティブであり、それぞれのノードは、お互いのバックアップノードとして機能します。通常の状態では、各ノードで Messaging Server のインスタンスを 1 つだけを実行しています。

図 3–2 同期高可用性モード

フェイルオーバーが発生すると、障害の発生したノード上のサービスがシャットダウンし、バックアップノード上のサービスが再起動します。この時点で、バックアップノードは両方のノードに対して Messaging Server を実行し、2 つの個別のボリュームを管理しています。

このモデルの利点は、両方のノードが同時にアクティブであるため、マシンのリソースを最大限に利用できる点にあります。ただし障害発生中は、バックアップノードが両方のノードに対して Messaging Server のサービスを実行するため、リソースの競合が起きやすくなります。そのため、障害の発生したノードをなるべく早く修復し、サーバーをデュアルサービス状態に戻すようにしてください。

このモデルでは、バックアップストレージアレイも提供されます。ディスクアレイで障害が発生した場合は、バックアップノードのサービスで冗長イメージを選択できます。

対称モデルを構成するには、共有ディスクに共有バイナリをインストールする必要があります。こうすることで、順次アップグレード (Messaging Server のパッチリリース中にシステムをアップグレードできる機能) が実行できなくなります。(この機能は将来のリリースで計画されています。)

3.2.3 N+1 (N Over 1)

N + 1 (または「N over 1」) モデルは、複数ノードの非対称構成で処理されます。N 個の論理ホスト名と N 個の共有ディスクアレイが必要です。1 つのバックアップノードが、ほかのすべてのノードのホットスタンバイとして予約されています。バックアップノードは、N 個のノードに対して Messaging Server を並列実行できます。

次の図は、基本的な N + 1 高可用性モデルを示しています。

図 3–3 N + 1 高可用性モード

1 つ以上のアクティブなノードでフェイルオーバーが発生すると、バックアップノードが障害の発生したノードの処理を引き受けます。

N + 1 モデルの利点は、サーバーの負荷を複数のノードに分散できること、および起こり得るノード障害のすべてに対処するために必要なバックアップノードが 1 つだけであることです。つまり、単体の非対称モデルの場合のマシンアイドル比が 1/1 であるのに対し、このモデルでは 1/N になります。

N+1 モデルを構成するには、バイナリをローカルディスクのみにインストールする必要があります (対称モデルのような共有ディスクではない)。現在の Messaging Server インストールおよび設定プロセスでは、対称、1+1/N+1 の非対称/対称 HA ソリューションの場合、共有ディスク上にバイナリが配置されます。

3.2.4 高可用性モデルの選択

それぞれの高可用性モデルの長所と短所について、次の表にまとめます。この情報は、配備にどのモデルが適切であるかを判断するのに役立ちます。

表 3–2 HA モデルの比較


モデル	長所	短所	推奨されるユーザー
非対称	シンプルな構成バックアップノードは 100% 予約されている	マシンリソースは最大限に使用されていない。	将来の拡張を計画している小規模なサービスプロバイダ
対称	システムリソースの使用が良好高い可用性	バックアップノードにおけるリソースの競合。 HA で完全に冗長なディスクが必要。	単一サーバーの障害時におけるパフォーマンスの低下を許容する、小企業での配備
N + 1	負荷分散容易な拡張	複雑な管理および構成。	リソースの競合なしで分散を必要とする、大規模なサービスプロバイダ

3.2.5 システムダウンタイムの計算

次の表は、ある日、システム障害によりメッセージングサービスが利用できなくなる可能性を示しています。この計算では、平均して、各サーバーはシステムのクラッシュやサーバーのハングアップが原因で 3 か月に 1 日ダウンし、各ストレージデバイスは 12 か月に 1 日ダウンすると仮定しています。また、両方のノードが同時にダウンするという小さい可能性は無視しています。

表 3–3 HA ダウンの可能性


モデル	サーバーダウンタイムの可能性
単体のサーバー (高可用性なし)	可能性 (ダウン) = (システムダウン 4 日 + ストレージダウン 1 日)/365 = 1.37%
非対称	可能性 (ダウン) = (システムダウン 0 日 + ストレージダウン 1 日)/365 = 0.27%
対称	可能性 (ダウン) = (システムダウン 0 日 + ストレージダウン 0 日)/365 = (ほぼ 0)
N + 1 非対称	可能性 (ダウン) = (システムダウン 5 日 + ストレージダウン 1 日)/(365 × N) = 0.27%/N

3.3 Messaging Server 高可用性のインストール — 概要

配備に適切な HA モデルを選択したら、Sun Cluster HA または Veritas HA を選択します。この節では、簡単に HA 配備情報を説明します。その後の節では、Sun Cluster および Veritas の高可用性ソリューションについて、固有の情報を説明します。

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

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

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

3.3.2 Messaging Server および高可用性の注意

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

Messaging Server の高可用性は、デフォルトでインストールされません。Sun Cluster 2.2 または Veritas Cluster Server 1.1 以降をインストールする場合は、「カスタムインストール」メニューから「高可用性コンポーネント」を選択してください。

注 –
Sun Cluster 3.0 U1 または U2 をインストールする場合は、インストールの種類で「カスタムインストール」を選択するようにしてください。ただし、Messaging Server のインストール時に Sun Cluster 2.2/Veritas HA コンポーネントは選択しないでください。
インストールの実行時に、Messaging Server の HA 論理ホスト名および関連 IP アドレスが機能している (たとえばアクティブである) ことを確認してください。これは、インストールの一部でこれらの情報を使用し、TCP 接続を行うためです。Messaging Server の HA 論理ホスト名が現在指定しているクラスタノードで、インストールを実行してください。
msg_svr_base が共有ファイルシステム上にあることを確認します。共有ファイルシステム上にない場合、高可用性が正常に機能しません。たとえば、別のノードに処理が継続されると、サーバーは障害の発生したノード上に蓄積したデータを参照しなくなります。
初期実行時設定の際に Messaging Server ホストの完全修飾のドメイン名を求められたときは、Messaging Server の完全修飾 HA 論理ホスト名を指定してください。インストール中に、この論理ホスト名を使用した TCP 接続が試行されます。
ha_ip_config の実行時に Messaging Server の IP アドレスを要求されたときは、Messaging Server の論理ホスト名に関連付けられた IP アドレスを指定してください。物理ホストの IP アドレスを使用しないでください。
クラスタリングソフトウェアは、Messaging Server の現在のバージョンのインストールと設定を行う前にインストールする必要があります。その場合は、Messaging Server の HA 論理ホスト名が現在指定しているクラスタノードで、インストールを実行してください。ノード名の入力を要求されたら、クラスタエイリアスを入力してください。
Messaging Server の初期実行時設定 (「1.3 Messaging Server の初期実行時設定を作成する」を参照) を実行する際に、Messaging Server のクラスタの完全修飾 HA 論理ホスト名を指定してください。
Messaging Server を設定するには、クラスタホスト名を使用してください。それ以外の方法で設定した場合、クラスタホスト名を使用して再設定する必要があります。

3.3.3 useconfig ユーティリティーの使用

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

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

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

msg-svr-base/sbin/useconfig install/configure_YYYYMMDDHHMMSS

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

新しいノードでは、共有ディスク上の msg-svr-base/data/setup ディレクトリに configure_YYYYMMDDHHMMSS があります。

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

3.4 Sun Cluster のインストール

ここでは、Messaging Server をインストールし、Sun Cluster Highly Available (HA) Data Service として設定する方法について説明します。この節には、次の項目があります。

Sun Cluster 3.x のマニュアル (Sun Cluster 3.1 Documentation) も参照してください。

Veritas File System (VxFS) は Sun Cluster 3.1 でサポートされています。

3.4.1 Sun Cluster の要件

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

Sun Cluster 3.0 および 3.1 が、必要なパッチを適用した Solaris 9 または 10 オペレーティングシステム上にインストールされ、設定されていること。
Sun Cluster エージェント SUNWscims がシステムにインストールされていること。
論理ボリュームを作成している場合、Solstice DiskSuite または Veritas Volume Manager のどちらかを使用していること。

3.4.2 HAStoragePlus について

Sun Cluster 環境の内部で、ローカルマウントされるファイルシステムを高可用性にする場合、HAStoragePlus リソースタイプを使用することを強くお勧めします。ローカルファイルシステム (フェイルオーバーファイルシステム (FFS) とも呼ばれる) では、クラスタファイルシステム (CFS、グローバルファイルシステムとも呼ばれる) よりも入出力パフォーマンスが向上します。HAStoragePlus では、FFS と CFS の両方をサポートしています。一方、HAStorage では、CFS のみをサポートしています。

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

HAStoragePlus はグローバルファイルサービス層を完全に回避します。このことは、ディスク入出力が集中するデータサービスでパフォーマンスの大幅な向上につながります。
HAStoragePlus は、グローバルファイルサービス層と連携しない可能性があるファイルシステムも含めて、UFS、VxFS などの任意のファイルシステムと連携できます。Solaris オペレーティングシステムでサポートされるファイルシステムは HAStoragePlus と連携します。

データサービスリソースグループ内で HAStorage リソースと HAStoragePlus リソースのどちらを作成すべきかを決定するには、次の基準を考慮してください。

Sun Cluster 3.0 Release May 2002 または Sun Cluster 3.1 を使用している場合は、HAStoragePlus を使用する
Sun Cluster 3.0 December 2001 以前を使用している場合は、HAStorage を使用する

HAStoragePlus の詳細については、適切な Sun Cluster マニュアルを参照してください。たとえば http://docs.sun.com/app/docs/coll/573.10 などがあります。

3.4.3 Sun Cluster HAStorage または HAStoragePlus を使用した Messaging Server の設定

ここでは、Sun Cluster 用の Messaging Server に対して HAStorage および HAStoragePlus を設定する方法について説明します。まず、一般的な手順を説明します。その後の節で、対称および非対称の配備に対する具体的な例を示します。

HA を設定したあとは必ず、HA サポートに関連する追加の手順について「3.4.4 サーバーへの IP アドレスのバインド」を確認してください。

次の説明では、HA 論理ホスト名と IP アドレスを指定して Messaging Server が設定済みであることを前提としています。物理ホスト名を mars および venus、HA 論理ホスト名を meadow と仮定します。図 3–4 は、Messaging Server の HA サポートの設定時に作成する各種の HA リソースについて、入れ子構造の依存関係を示したものです。

注 –

HAStorage と HAStoragePlus の設定方法について説明しますが、入出力パフォーマンスの高い HAStoragePlus を使用することを強くお勧めします。「3.4.2 HAStoragePlus について」を参照してください。

図 3–4 単純な Messaging Server HA 設定

この図は、単純な Messaging Server HA 設定を示したものです。

Sun Cluster HAStorage または HAStoragePlus を使用して Messaging Server を設定する — 一般的な例

ここでは、HA 用に Messaging Server を設定する一般的な手順について説明します。ここでの手順を確認したら、次の節で特定の非対称または対称の例について参照してください。これらの手順では、物理ホスト名を mars および venus とします。論理ホスト名は meadow です。

スーパーユーザーになってコンソールを開きます。

以降の Sun Cluster コマンドはすべて、スーパーユーザーとしてログインしてから実行する必要があります。/dev/console へのメッセージ出力を確認するためにコンソールまたはウィンドウを開きます。

すべてのノードで、必要な Messaging Server Sun Cluster Data Service Agents (SUNWscims) パッケージをインストールします。

クラスタの各ノードで、Messaging Server を実行するための Messaging Server 実行時ユーザーおよびグループを作成します。

ユーザー ID およびグループ ID 番号は、クラスタ内のすべてのノードで同じでなければなりません。実行時ユーザー ID は、Messaging Server を実行するユーザー名です。この名前に root を指定することはできません。デフォルトは mailsrv です。実行時グループ ID は、Messaging Server を実行するグループです。デフォルトは mail です。

configure ユーティリティーでもこれらの名前を作成できますが、configure を実行する前に、この章で説明する各ノードの準備の一環としてこれらの名前を作成できます。実行時ユーザーおよびグループ ID 名は、次のファイルに存在する必要があります。
- クラスタ内の全ノードの /etc/passwd: mailsrv または選択した名前が存在する必要がある
- クラスタ内の全ノードの /etc/group: mail または選択した名前が存在する必要がある
「1.1 UNIX システムのユーザーとグループを作成する」を参照してください。

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

使用する予定のリソースタイプを認識するように Sun Cluster を設定します。Messaging Server をリソースとして登録するには、次のコマンドを使用します。
# scrgadm -a -t SUNW.ims
HAStoragePlus をリソースタイプとして登録するには、次のコマンドを使用します。
# scrgadm -a -t SUNW.HAStoragePlus
HAStorage をリソースタイプとして同じ操作を行うには、次のコマンドを使用します。
# scrgadm -a -t SUNW.HAStorage

Messaging Server 用のフェイルオーバーリソースグループを作成します。

リソースグループをまだ作成していない場合は作成し、Messaging Server を実行するクラスタノード上でそのグループが見えるようにします。次のコマンドは、MAIL-RG という名前のリソースグループを作成し、クラスタノード mars および venus 上でそのグループが見えるようにします。

# scrgadm -a -g MAIL-RG -h mars,venus

もちろん、リソースグループに対しては任意の名前を使用できます。

HA 論理ホスト名リソースを作成し、オンラインにします。

HA 論理ホスト名のリソースを作成して有効にし、リソースグループに配置します (まだこの作業を行なっていない場合のみ)。次のコマンドは、論理ホスト名 meadow を使用してその処理を行います。-j スイッチを省略しているため、作成されるリソースの名前も meadow になります。meadow は、クライアントがリソースグループ内のサービスと通信するときに使用する論理ホスト名です。
# scrgadm -a -L -g MAIL-RG -l meadow # scswitch -Z -g MAIL-RG

HAStorage リソースまたは HAStoragePlus リソースを作成します。

次に、Messaging Server が依存するファイルシステムに対して HA Storage または HAStoragePlus リソースタイプを作成する必要があります。次のコマンドは、disk-rs という名前の HAStoragePlus リソースを作成し、ファイルシステム disk_sys_mount_point をその制御下に置きます。
# scrgadm -a -j disk-rs -g MAIL-RG \ -t SUNW.HAStoragePlus \ -x FilesystemMountPoints=disk_sys_mount_point-1, disk_sys_mount_point-2 -x AffinityOn=True
SUNW.HAStoragePlus は、1 個以上のデータサービスリソースによって使用されるデバイスグループ、クラスタおよびローカルファイルシステムを表します。これらは、リソースグループに SUNW.HAStoragePlus 型のリソースを追加し、その他のリソースと SUNW.HAStoragePlus リソース間の依存関係を設定します。この依存関係により、データサービスリソースは、次の条件が揃った時点でオンラインになります。
- 指定のすべてのデバイスサービスが使用可能な状態になっており、必要に応じて連結されている
- 指定のすべてのファイルシステムのチェックとマウントが完了している
FilesystemMountPoints 拡張プロパティーにより、グローバルとローカルのどちらのファイルシステムでも指定できます。つまり、クラスタのすべてのノードからも、単一クラスタノードからも、アクセス可能なファイルシステムです。ローカルファイルシステムは、SUNW.HAStoragePlus リソースによって管理され、単一のクラスタノードにマウントされます。配下のデバイスは Sun Cluster グローバルデバイスである必要があります。ローカルファイルシステムを指定する SUNW.HAStoragePlus リソースは、アフィニティースイッチオーバーが有効になっているフェイルオーバーリソースグループ以外には所属できません。このため、これらのローカルファイルシステムはフェイルオーバーファイルシステムと呼ばれます。ローカルとグローバルの両方のファイルシステムのマウントポイントを同時に指定できます。

ファイルシステムのマウントポイントが FilesystemMountPoints 拡張プロパティーに指定され、/etc/vfstab エントリが次の条件を両方とも満たしている場合、このファイルシステムはローカルです。
- 非グローバルマウントオプション
- ブート時マウントフラグが no に設定されている
注 –
SUNW.HAStoragePlus リソースタイプのインスタンスは、大域ファイルシステムのブート時マウントフラグを無視します。

HAStoragePlus リソースの場合、FilesystemMountPoints のコンマ区切りのリストが、Messaging Server が依存するクラスタファイルシステム (CFS) またはフェイルオーバーファイルシステム (FFS) のマウントポイントです。この例では、disk_sys_mount_point-1 および disk_sys_mount_point-2 の 2 つのマウントポイントのみを指定しています。いずれかのサーバーが依存するファイルシステムがほかにもある場合、追加の HA ストレージリソースを作成し、手順 15 でその追加の依存関係を指定することができます。

HAStorage の場合は、次のコマンドを使用します。
# scrgadm -a -j disk-rs -g MAIL-RG \ -t SUNW.HAStorage -x ServicePaths=disk_sys_mount_point-1, disk_sys_mount_point-2 -x AffinityOn=True
HAStorage リソースの ServicePaths のコンマ区切りのリストは、Messaging Server が依存するクラスタファイルシステムのマウントポイントです。この例では、disk_sys_mount_point-1 および disk_sys_mount_point-2 の 2 つのマウントポイントのみを指定しています。いずれかのサーバーが依存するファイルシステムがほかにもある場合、追加の HA ストレージリソースを作成し、手順 15 でその追加の依存関係を指定することができます。

必要な Messaging Server パッケージを第一のノードにインストールします。「あとで設定」オプションを選択します。

Messaging Server パッケージのインストールには、Communications Suite のインストーラを使用します。

対称配備の場合: Messaging Server バイナリおよび構成データを、Sun Cluster の共有ディスクにマウントされたファイルシステム上にインストールします。たとえば、Messaging Server バイナリの場合は /disk_sys_mount_point-1/SUNWmsgsr に、構成データの場合は /disk_sys_mount_point-2/config にインストールします。

非対称配備の場合: Messaging Server バイナリを、Sun Cluster の各ノードのローカルファイルシステム上にインストールします。構成データを共有ディスク上にインストールします。たとえば構成データの場合は /disk_sys_mount_point-2/config にインストールします。

Messaging Server を構成します。「1.3 Messaging Server の初期実行時設定を作成する」を参照してください。

初期実行時設定で、完全修飾ホスト名が要求されます。HA の物理ホスト名ではなく、論理ホスト名を使用する必要があります。

「1.3 Messaging Server の初期実行時設定を作成する」に示すように、初期実行時設定では設定ディレクトリを指定するよう求められます。必ず、対象の HAStorage または HAStoragePlus リソースの共有ディスクディレクトリパスを使用してください。

ha_ip_config スクリプトを実行して、service.listenaddr および service.http.smtphost パラメータと、dispatcher.cnf および job_controller.cnf ファイルを高可用性のために設定します。

このスクリプトは、これらのパラメータおよびファイルに対して、物理 IP アドレスではなく論理 IP アドレスが設定されることを確認します。また、watcher プロセス (local.watcher.enable) と自動再起動プロセス (local.autorestart) を有効 (それぞれ 1 に設定) にします。

スクリプトの実行方法については、「3.4.4 サーバーへの IP アドレスのバインド」を参照してください。

ha_ip_config スクリプトは、第一のノードで 1 回だけ実行されなければなりません。

imta.cnf ファイルを修正します。すべての物理ホスト名をクラスタの論理ホスト名に置換します。

リソースグループを一次クラスタノードから二次クラスタノードへフェイルオーバーして、フェイルオーバーが適切に機能することを確認します。

リソースグループを別のクラスタノードに手動でフェイルオーバーします (フェイルオーバー先のクラスタノードに対するスーパーユーザー権限が必要)。

scstat コマンドを使用して、リソースグループが現在どのノード上で動作しているか (「オンライン」であるか) を確認します。たとえば、リソースグループが mars 上でオンラインである場合、次のコマンドを実行して venus へフェイルオーバーします。

# scswitch -z -g MAIL-RG -h venus

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

必要な Messaging Server パッケージを第ニのノードにインストールします。「あとで設定」オプションを選択します。

二次ノードにフェイルオーバーしたら、Communications Suite のインストーラを使用して Messaging Server パッケージをインストールします。

対称配備の場合: Messaging Server をインストールしないでください。

非対称配備の場合: Messaging Server バイナリを、ローカルファイルシステム上にインストールします。

クラスタの二次ノードで useconfig を実行します。

useconfig ユーティリティーを使用すると、HA 環境内の複数のノード間で単一の設定を共有できます。初期実行時設定プログラム (configure) を実行する必要はありません。代わりに useconfig ユーティリティーを使用してください (「3.3.3 useconfig ユーティリティーの使用」を参照)。

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

ここで、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,meadow
このコマンドは、msg-svr-base ディレクトリ内の IMS_serverroot にインストールされた Messaging Server に対して、mail-rs という名前の HA Messaging Server リソースを作成します。HA Messaging Server リソースは、HA 論理ホスト名 meadow に加えて、HA ディスクリソース disk-rs に依存します。

ファイルシステムに対する Messaging Server の依存関係がほかにもある場合、それらのファイルシステムに対する追加の HA ストレージリソースを作成できます。必ず、追加の HA ストレージリソースの名前を、このコマンドの Resource_dependencies オプションに含めるようにしてください。

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

HA Messaging Server リソースをアクティブにし、それによってメッセージングサーバーをオンラインにする準備ができました。これを行うには、次のコマンドを使用します。

# scswitch -e -j mail-rs

このコマンドは、MAIL-RG リソースグループの mail-rs リソースを有効にします。MAIL-RG リソースはあらかじめオンラインにされていたため、このコマンドによって mail-rs もオンラインになります。

問題がないことを確認します。

scstat -pw コマンドを使って、MAIL-RG リソースグループがオンラインかどうかを確認します。

必要であれば、コンソールデバイスへの出力を参照して診断情報を確認します。また、syslog ファイル /var/adm/messages も確認します。詳細なデバッグのオプションと情報については、「3.4.3.1 Sun Cluster でデバッグを有効にする方法」を参照してください。

Sun Cluster 3.x 用の Messaging Server HA サポートを設定解除する — 一般的な例

この節では、Sun Cluster 用の HA 設定を解除する方法について説明します。ここでは、「3.4 Sun Cluster のインストール」で説明した単純な設定例を想定します。手順 3 などの一部の手順が異なる場合がありますが、それ以外の手順の論理順は同じです。

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

以降の Sun Cluster コマンドはすべて、スーパーユーザーとして実行する必要があります。

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

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

# scswitch -F -g MAIL-RG

このコマンドは、Messaging Server や HA 論理ホスト名など、リソースグループ内部のすべてのリソースをシャットダウンします。

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

続いて、次のコマンドを実行して、リソースグループから 1 つずつリソースを削除します。
# scswitch -n -j mail-rs # scswitch -n -j disk-rs # scswitch -n -j budgie

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

リソースが無効になったら、次のコマンドによって、リソースグループからリソースを 1 つずつ削除できます。
# scrgadm -r -j mail-rs # scrgadm -r -j disk-rs # scrgadm -r -j budgie

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

リソースグループからすべてのリソースが削除されたら、次のコマンドによってリソースグループ自体を削除できます。

# scrgadm -r -g MAIL-RG

リソースタイプを削除します (必要な場合)。

リソースタイプをクラスタから削除する必要がある場合、次のコマンドを実行します。
# scrgadm -r -t SUNW.ims # scrgadm -r -t SUNW.HAStoragePlus

2 ノード対称 Messaging Server を設定する — 例

この例では、物理ホスト名が mars.red.siroe.com および venus.red.siroe.com である 2 つのクラスタノードを仮定します。インストールディレクトリの位置および設定ディレクトリの位置は一意である必要があります。/opt/SUNWmsgsr と /var/opt/SUNWmsgsr のように、各ノードのインストールディレクトリや設定ディレクトリが同じディレクトリ名である場合は、競合の問題が発生します。競合の問題は、venus が mars にフェイルオーバーし、Messaging Server の 2 つのインスタンスでインストールディレクトリおよび設定ディレクトリが競合することで発生します。

インストールディレクトリおよび設定ディレクトリに一意の名前を作成するには、インストールディレクトリに形式 /opt/NodeMember /SUNWmsgsr、設定ディレクトリに形式 /var/opt/NodeMember/SUNWmsgsr を使用するとよいでしょう。一意であるかぎり、どのようなディレクトリであっても、バイナリや設定データのインストールに使用できます。

この例では、物理ホスト名が mars.red.siroe.com および venus.red.siroe.com である 2 つのクラスタノードを仮定します。

mars.red.siroe.com では、バイナリが /opt/mars/SUNWmsgsr に、設定データが /var/opt/mars/SUNWmsgsr にインストールされています。

venus.red.siroe.com では、バイナリが /opt/venus/SUNWmsgsr に、設定データが /var/opt/venus/SUNWmsgsr にインストールされています。

個別の論理 IP アドレスが設定されている、2 つの論理ホスト名 meadow と pasture があります。たとえば、両方のノードの /etc/hosts ファイルは、次のようになっています。

192.18.75.155 meadow.red.siroe.com meadow 
192.18.75.157 pasture.red.siroe.com pasture

Messaging Server Sun Cluster エージェントパッケージ (SUNWscims) を両方のノードにインストールします。

4 つのファイルシステムを作成します。

これらのファイルシステムは、クラスタファイルシステムでもローカルファイルシステム (フェイルオーバーファイルシステム) でもかまいません。

/var/opt/mars/SUNWmsgsr
/var/opt/venus/SUNWmsgsr
/opt/mars/SUNWmsgsr
/opt/venus/SUNWmsgsr

これらのファイルシステムは、共有ディスクにマウントするようにしてください。たとえば、次のような 4 つのクラスタファイルシステムにします。次の /etc/vfstab の内容は、クラスタのすべてのノードで同じようになっているはずです。

# cat /etc/vfstab
#device  device  mount  FS  fsck  mount  mount  to  mount  to  fsck  point  type 
pass at_boot_options
/dev/md/penguin/dsk/d500 /dev/md/penguin/rdsk/d500 /opt/mars/SUNWmsgsr ufs 2 yes 
logging,global
/dev/md/penguin/dsk/d400 /dev/md/penguin/rdsk/d400 /var/opt/mars/SUNWmsgsr ufs 2 
yes logging,global
/dev/md/polarbear/dsk/d200 /dev/md/polarbear/rdsk/d200 /opt/venus/SUNWmsgsr ufs 2 
yes  logging,global
/dev/md/polarbear/dsk/d300 /dev/md/polarbear/rdsk/d300 /var/opt/venus/SUNWmsgsr 
ufs 2 yes logging,global

前述の 4 つのファイルシステムをローカルファイルシステム (フェイルオーバーファイルシステム) にする場合は、ブートオプションの mount を no に設定し、マウントオプションの global キーワードを削除します。

第一のノードを設定します。
1. 第一のノードに必要なリソースタイプを追加します。
  
  使用する予定のリソースタイプを認識するように Sun Cluster を設定します。Messaging Server および HAStoragePlus リソースを登録するには、次のコマンドを使用します。
  # scrgadm -a -t SUNW.HAStoragePlus # scrgadm -a -t SUNW.ims
2. MS_RG_MARS という名前の Messaging Server 用フェイルオーバーリソースグループを作成します。
  # scrgadm -a -g MS_RG_MARS -h mars,venus
3. meadow という名前の論理ホスト名リソース 1 つを作成してリソースグループに追加し、オンラインにします。
  # scrgadm -a -L -g MS_RG_MARS -l meadow # scrgadm -c -j meadow -y R_description="LogicalHostname resource for meadow" # scswitch -Z -g MS_RG_MARS
4. 先に作成したファイルシステムで ms-hasp-mars という名前の HAStoragePlus リソースを作成します。
  # scrgadm -a -j ms-hasp-mars -g MS_RG_MARS -t SUNW.HAStoragePlus -x FileSystemMountPoints ="/opt/mars/SUNWmsgsr, /var/opt/mars/SUNWmsgsr" -x AffinityOn=TRUE
5. HAStoragePlus リソースを有効にします。
  # scswitch -e -j ms-hasp-mars

第一のノードに Messaging Server をインストールします。

Communications Suite インストーラを使用して Messaging Server パッケージをインストールします。共有ファイルシステムに Messaging Server バイナリおよび設定データをインストールしたことを確認してください (手順 2 を参照)。たとえば Messaging Server のこのインスタンスの場合、Messaging Server バイナリは /opt/mars/SUNWmsgsr に、設定データは /var/opt/mars/SUNWmsgsr にあります。

第一のノードに Messaging Server をインストールし、設定します (「1.3 Messaging Server の初期実行時設定を作成する」を参照)。

初期実行時設定プログラムで、完全修飾ホスト名が要求されます。論理ホスト名 meadow.red.siroe.com を入力します。設定ディレクトリの指定も要求されます。/var/opt/mars/SUNWmsgsr と入力します。

第一のノードで ha_ip_config スクリプトを実行し、論理 IP アドレスを指定します。

第一のノードのみで実行し、第ニのノードでは実行しません。ha_ip_config スクリプトは、sbin ディレクトリの下のインストールディレクトリにあります。次に例を示します。

# /opt/mars/SUNWmsgsr/sbin/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: 192.18.75.155 
# This value is the logical IP address of the logical hostname. Refer 
# to the /etc/hosts file.
Please specify the path to the top level directory in which iMS is
installed.

iMS server root: /opt/mars/SUNWmsgsr

. . . 

Updating the file /opt/mars/SUNWmsgsr/config/dispatcher.cnf
Updating the file /opt/mars/SUNWmsgsr/config/job_controller.cnf
Setting the service.listenaddr configutil parameter
Setting the local.snmp.listenaddr configutil parameter
Setting the service.http.smtphost configutil parameter
Setting the local.watcher.enable configutil parameter
Setting the local.autorestart configutil parameter
Setting the metermaid.config.bindaddr configutil parameters
Setting the metermaid.config.serveraddr configutil parameters
Setting the local.ens.port parameter
Configuration successfully updated

imta.cnf ファイルを修正して、物理ホスト名 (mars) の出現箇所すべてを HA 論理ホスト名 (meadow) に置き換えます。

リソースグループを第ニのノード (venus) にフェイルオーバーします。

フェイルオーバー後、第ニのノード (venus) を設定します。
# scswitch -z -g MS_RG_VENUS -h mars

第ニのノード (venus) で useconfig ユーティリティーを実行します。「3.3.3 useconfig ユーティリティーの使用」を参照してください。

初期実行時設定プログラム ( configure) を実行したり、Messaging Server パッケージをインストールしたりする必要はありません。

次の例で、/var/opt/mars/SUNWmsgsr は共有設定ディレクトリです。

# useconfig /var/opt/mars/SUNWmsgsr/setup/configure_20061201124116
cp /var/opt/mars/SUNWmsgsr/setup/configure_20061201124116/Devsetup.properties
/opt/mars/SUNWmsgsr/lib/config-templates/Devsetup.properties
/usr/sbin/groupadd mail
/usr/sbin/useradd -g mail -d / mailsrv
/usr/sbin/usermod -G mail mailsrv
sed -e "s/local.serveruid/mailsrv/" -e "s/local.serveruid/mail/" -e "s:<msg·RootPath>:/opt/mars/SUNWmsgsr:" 
/opt/mars/SUNWmsgsr/lib/config-templates/devtypes.txt.template > 
/opt/mars/SUNWmsgsr/lib/config-templates/devtypes.txt
sed -e "s/local.serveruid/mailsrv/" -e "s/local.serveruid/mail/" -e 
"s:<msg·RootPath>:/opt/mars/SUNWmsgsr:" 
/opt/mars/SUNWmsgsr/lib/config-templates/config.ins.template > 
/opt/mars/SUNWmsgsr/lib/config-templates/config.ins
/opt/mars/SUNWmsgsr/lib/devinstall -l sepadmsvr:pkgcfg:config -v -m -i 
/opt/mars/SUNWmsgsr/lib/config-templates/config.ins 
/opt/mars/SUNWmsgsr/lib/config-templates 
/opt/mars/SUNWmsgsr/lib/jars /opt/mars/SUNWmsgsr/lib
devinstall returned 0
crle -c /var/ld/ld.config -s
 /usr/lib/secure:/opt/SUNWmsgsr/lib:/opt/venus/SUNWmsgsr/lib:/opt/mars/SUNWmsgsr/lib 
-s /opt/mars/SUNWmsgsr/lib
See /opt/mars/SUNWmsgsr/install/useconfiglog_20061211155037 for more details

HA Messaging Server リソースを作成し、有効にします。
# scrgadm -a -j ms-rs-mars -t SUNW.ims -g MS_RG_MARS -x IMS_serverroot =/opt/mars/SUNWmsgsr -y Resource_dependencies=meadow,ms-hasp-mars # scswitch -e -j mail-rs-mars
このコマンドでは、/opt/mars/SUNWmsgsr にインストールされた Messaging Server 用に ms-rs-mars という名前の HA Messaging Server リソースを作成します。この HA Messaging Server リソースは、HA ディスクリソース、つまり先に作成したファイルシステムと、HA 論理ホスト名 meadow に依存します。

すべてが動作していることを確認します。

Messaging Server リソースを第一のノードにフェイルオーバーします。
# scswitch -z -g MAIL-RG -h mars

同様にして、Messaging Server の 2 番目のインスタンスに対し、第一のノードが venus、第ニのノード (スタンバイノード) が mars である別のフェイルオーバーリソースグループを作成します。

手順 3 〜 10 を繰り返します。このリソースグループの第一のノードとして venus、リソースグループとして MS_RG_VENUS、論理ホスト名として pasture、HAStoragePlus リソースとして ms-hasp-venus を使用します。つまり、コマンドは次のようになります。

リソースグループ MS_RG_VENUS を作成するには、次のコマンドを実行します。
# scrgadm -a -g MS_RG_VENUS -h venus,mars
pasture という名前の論理ホスト名リソースを作成してリソースグループに追加し、オンラインにするには、次のコマンドを実行します。
# scrgadm -a -L -g MS_RG_VENUS -l pasture # scrgadm -c -j pasture -y R_description="LogicalHostname resource for pasture" # scswitch -Z -g MS_RG_VENUS
先に作成したファイルシステムで ms-hasp-venus という名前の HAStoragePlus リソースを作成するには、次のコマンドを実行します。
# scrgadm -a -j ms-hasp-venus -g MS_RG_VENUS -t SUNW.HAStoragePlus -x FileSystemMountPoints ="/opt/venus/SUNWmsgsr, /var/opt/venus/SUNWmsgsr" -x AffinityOn=TRUE
HAStoragePlus リソースを有効にするには、次のコマンドを実行します。
# scswitch -e -j ms-hasp-venus
第一のノードで ha_ip_config スクリプトを実行し、論理 IP アドレスを指定するには、次のコマンドを実行します。
# /opt/venus/SUNWmsgsr/sbin/ha_ip_config
HA Messaging Server リソースを作成し、有効にするには、次のコマンドを実行します。
# scrgadm -a -j ms-rs-venus -t SUNW.ims -g MS_RG_VENUS -x IMS_serverroot =/opt/venus/SUNWmsgsr -y Resource_dependencies=pasture,ms-hasp-venus # scswitch -e -j mail-rs-venus
リソースグループを第ニのノード (venus) にフェイルオーバーするには、次のコマンドを実行します。
# scswitch -z -g MS_RG_MARS -h venus
第ニのノード (mars) で useconfig を実行するには、次のように useconfig ユーティリティーを実行します。
# useconfig /var/opt/venus/SUNWmsgsr/setup/configure_20061201124116
Messaging Server リソースを第一のノードにフェイルオーバーすることで、すべてが動作していることを確認するには、次のコマンドを実行します。
# scswitch -z -g MAIL-RG -h venus

HA 対称配備を設定解除する

設定解除は、Messaging Server または Sun Cluster をアップグレードする必要がある場合や、Messaging Server をアンインストールする必要がある場合に行われます。ここでは、システムが前の例を使用して設定されていると仮定します。

最初の手順では、クラスタ内の各リソースグループを削除します。この例では、2 つのリソースグループ MS_RG_MARS および MS_RG_VENUS があります。どちらも削除する必要があります。

クラスタからリソースグループ MS_RG_MARS を削除します。

1 つのノードだけで次のコマンドを使用します。各ノードで実行する必要はありません。
1. クラスタ内のすべてのノードでリソースグループをオフラインにします。
  # scswitch -F -g MS_RG_MARS
2. 固有の Messaging Server リソースすべてを無効にします。
  # scswitch -n -j ms-rs-mars # scswitch -n -j meadow # scswitch -n -j ms-hasp-mars
3. 固有の Messaging Server リソースすべてを削除します。
  # scrgadm -r -j ms-rs-mars # scrgadm -r -j meadow # scrgadm -r -j ms-hasp-mars
4. リソースグループを削除します。
  scrgadm -r -g MS_RG_MARS

クラスタからリソースグループ MS_RG_VENUS を削除します。

1 つのノードだけで次のコマンドを使用します。各ノードで実行する必要はありません。
1. クラスタ内のすべてのノードでリソースグループをオフラインにします。
  # scswitch -F -g MS_RG_VENUS
2. 固有の Messaging Server リソースすべてを無効にします。
  # scswitch -n -j ms-rs-venus # scswitch -n -j pasture # scswitch -n -j ms-hasp-venus
3. 固有の Messaging Server リソースすべてを削除します。
  # scrgadm -r -j ms-rs-venus # scrgadm -r -j pasture # scrgadm -r -j ms-hasp-venus
4. リソースグループを削除します。
  scrgadm -r -g MS_RG_VENUS

使用していないリソースタイプを登録解除します。
# scrgadm -r -t SUNW.HAStoragePlus # scrgadm -r -t SUNW.ims

2 ノード HA 非対称 Messaging Server を設定する — 例

この例では、物理ホスト名 daisy.red.siroe.com および lavender.red.siroe.com と論理ホスト名 budgie が設定された 2 ノードクラスタを仮定します。

daisy.red.siroe.com では、バイナリが /opt/SUNWmsgsr に、設定データが /var/opt/SUNWmsgsr にインストールされています。

論理ホスト名 budgie には、論理 IP アドレスが割り当てられています。たとえば、/etc/hosts ファイルは、次のようになっています。

192.18.75.157 budgie.red.siroe.com budgie

Messaging Server Sun Cluster エージェント (SUNWscims) を両方のノードにインストールします。

ファイルシステムを作成します。

この例のファイルシステム /var/opt/SUNWmsgsr は、共有ディスクにマウントされています。このファイルシステムは、クラスタファイルシステムでもローカルファイルシステム (フェイルオーバーファイルシステム) でもかまいません。

第一のノード (daisy) を設定します。
1. 第一のノードに必要なリソースタイプを追加します。
  
  使用する予定のリソースタイプを認識するように Sun Cluster を設定します。Messaging Server および HAStoragePlus リソースを登録するには、次のコマンドを使用します。
  # scrgadm -a -t SUNW.HAStoragePlus # scrgadm -a -t SUNW.ims
2. Messaging Server インスタンスに対して MS_RG_DAISY という名前のリソースグループを作成します。
  # scrgadm -a -g MS_RG_daisy -h daisy,lavender
3. meadow という名前の論理ホスト名リソースを作成してリソースグループに追加し、オンラインにします。
  # scrgadm -a -L -g MS_RG_DAISY -l meadow # scrgadm -c -j meadow -y R_description="LogicalHostname resource for meadow" # scswitch -Z -g MS_RG_DAISY
4. 先に作成したファイルシステムで ms-hasp-daisy という名前の HAStoragePlus リソースを作成します。
  # scrgadm -a -j ms-hasp-daisy -g MS_RG_DAISY -t SUNW.HAStoragePlus -x FileSystemMountPoints ="/var/opt/SUNWmsgsr" -x AffinityOn=TRUE
5. HAStoragePlus リソースを有効にします。
  # scswitch -e -j ms-hasp-daisy

第一のノードに Messaging Server をインストールし、設定します (「1.3 Messaging Server の初期実行時設定を作成する」を参照)。

初期実行時設定で、完全修飾ホスト名が要求されます。論理ホスト名 meadow.red.siroe.com を入力します。設定ディレクトリの指定も要求されます。/var/opt/SUNWmsgsr と入力します。

第一のノードで ha_ip_config スクリプトを実行し、論理 IP アドレスを指定します。

# /opt/SUNWmsgsr/sbin/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: 192.18.75.155 
# This value is the logical IP address of the logical hostname. Refer 
# to the /etc/hosts file.
Please specify the path to the top level directory in which iMS is
installed.

iMS server root: /opt/SUNWmsgsr

. . . 

Updating the file /opt/SUNWmsgsr/config/dispatcher.cnf
Updating the file /opt/SUNWmsgsr/config/job_controller.cnf
Setting the service.listenaddr configutil parameter
Setting the local.snmp.listenaddr configutil parameter
Setting the service.http.smtphost configutil parameter
Setting the local.watcher.enable configutil parameter
Setting the local.autorestart configutil parameter
Setting the metermaid.config.bindaddr configutil parameters
Setting the metermaid.config.serveraddr configutil parameters
Setting the local.ens.port parameter
Configuration successfully updated

imta.cnf ファイルを修正して、物理ホスト名 (daisy) の出現箇所すべてを HA 論理ホスト名 (meadow) に置き換えます。

リソースグループを第ニのノード (lavender) にフェイルオーバーします。

フェイルオーバー後、第ニのノード (lavender) を設定します。
# scswitch -z -g MS_RG_LAVENDER -h daisy

第ニのノード (lavender) で、Messaging Server をインストールし、useconfig ユーティリティーを実行します。「3.3.3 useconfig ユーティリティーの使用」を参照してください。

初期実行時設定プログラム (configure) を実行する必要はありません。

次の例で、/var/opt/SUNWmsgsr は共有設定ディレクトリです。

# useconfig /var/opt/SUNWmsgsr/setup/configure_20061201124116
cp /var/opt/SUNWmsgsr/setup/configure_20061201124116/Devsetup.properties
/opt/SUNWmsgsr/lib/config-templates/Devsetup.properties
/usr/sbin/groupadd mail
/usr/sbin/useradd -g mail -d / mailsrv
/usr/sbin/usermod -G mail mailsrv
sed -e "s/local.serveruid/mailsrv/" -e "s/local.serveruid/mail/" -e "s:<msg·RootPath>:/opt/SUNWmsgsr:" 
/opt/SUNWmsgsr/lib/config-templates/devtypes.txt.template > 
/opt/SUNWmsgsr/lib/config-templates/devtypes.txt
sed -e "s/local.serveruid/mailsrv/" -e "s/local.serveruid/mail/" -e 
"s:<msg·RootPath>:/opt/SUNWmsgsr:" 
/opt//SUNWmsgsr/lib/config-templates/config.ins.template > 
/opt/SUNWmsgsr/lib/config-templates/config.ins
/opt/SUNWmsgsr/lib/devinstall -l sepadmsvr:pkgcfg:config -v -m -i 
/opt/SUNWmsgsr/lib/config-templates/config.ins 
/opt/SUNWmsgsr/lib/config-templates 
/opt/SUNWmsgsr/lib/jars /opt/SUNWmsgsr/lib
devinstall returned 0
crle -c /var/ld/ld.config -s
 /usr/lib/secure:/opt/SUNWmsgsr/lib:/opt/SUNWmsgsr/lib:/opt/SUNWmsgsr/lib 
-s /opt/SUNWmsgsr/lib
See /opt/SUNWmsgsr/install/useconfiglog_20061211155037 for more details

HA Messaging Server リソースを作成し、有効にします。
# scrgadm -a -j ms-rs-daisy -t SUNW.ims -g MS_RG_DAISY -x IMS_serverroot =/opt/SUNWmsgsr -y Resource_dependencies=meadow,ms-hasp-daisy # scswitch -e -j mail-rs-daisy
このコマンドでは、/opt/SUNWmsgsr にインストールされた Messaging Server 用に ms-rs-daisy という名前の HA Messaging Server リソースを作成します。この HA Messaging Server リソースは、HA ディスクリソース、つまり先に作成したファイルシステムと、HA 論理ホスト名 meadow に依存します。

すべてが動作していることを確認します。

Messaging Server リソースを第一のノードにフェイルオーバーします。
# scswitch -z -g MAIL-RG -h daisy

3.4.3.1 Sun Cluster でデバッグを有効にする方法

Messaging Server Data Service Sun Cluster エージェントでは、2 つの API を使用してデバッグメッセージをログに記録します。

scds_syslog_debug() は、デバッグ用メッセージを 1 レベルでシステムログに書き込みます。

scds_syslog() は、メッセージを daemon.notice、daemon.info、および daemon.error の各レベルでシステムログに書き込みます。

すべての syslog メッセージには、次のプレフィックスが付きます。

SC[resourceTypeName, resourceGroupName, resourceName,methodName]

次に例を示します。

Dec 11 18:24:46 mars SC[SUNW.ims,MS-RG,mail-rs,ims_svc_start]: [ID 831728daemon.debug]
Groupname mail exists. 
Dec 11 18:24:46 mars SC[SUNW.ims,MS-RG,mail-rs,ims_svc_start]: [ID 383726daemon.debug] 
Username mailsrv exists.
Dec 11 18:24:46 mars SC[SUNW.ims,MS-RG,mail-rs,ims_svc_start]: [ID 244341daemon.debug] 
IMS_serverroot = /opt/mars/SUNWmsgsr
Dec 11 15:55:52 mars SC[SUNW.ims,MS_RG,MessagingResource,ims_svc_validate]: 
[ID 855581daemon.error] Failed to get the configuration info
Dec 11 18:24:46 mars SC[SUNW.ims,MS-RG,mail-rs,ims_svc_start]: [ID 833212daemon.info]
Attempting to start the data service under process monitor facility.

Messaging Server リソースタイプ SUNW.ims からのメッセージをログに記録するには、次のようにして /var/cluster の下にリソースタイプディレクトリを作成します。

mkdir -p /var/cluster/rgm/rt/SUNW.ims

リソースタイプ SUNW.ims のデバッグメッセージをすべて表示するには、全クラスタノード上で次のコマンドを発行します。

echo 9 > /var/cluster/rgm/rt/SUNW.ims/loglevel

リソースタイプ SUNW.ims のデバッグメッセージを抑制するには、全クラスタノード上で次のコマンドを発行します。

echo 0 > /var/cluster/rgm/rt/SUNW.ims/loglevel

Sun Cluster Data サービスからのデバッグメッセージと、Messaging Server エージェントからの一般的なデバッグ情報をログに記録するには、syslog.conf ファイルを編集します。たとえばすべての syslog メッセージをファイル /var/adm/clusterlog に記録するには、次の行を syslog.conf ファイルに追加します。

daemon.debug /var/adm/clusterlog

これは、レベル emerg、alert、critical、error、 warning、notice、information、debug のすべてのメッセージを書き込みます。詳細については、syslog.conf マニュアルページを参照してください。

syslogd デーモンを再起動します。

pkill -HUP syslogd

3.4.4 サーバーへの IP アドレスのバインド

Symmetric または N + 1 高可用性モデルを使用している場合、Messaging Server 用に Sun Cluster Server を準備するための設定作業について追加の留意事項があります。

Messaging Server が動作するサーバーに正しい IP アドレスをバインドする必要があります。このことは、HA 環境でメッセージングを適切に設定するために必要です。

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 オプションを追加または変更します。

スクリプトは最後に、configutil の service.listenaddr および service.http.smtphost パラメータを設定します。これらは POP サーバー、IMAP サーバー、および Messenger Express HTTP サーバーによって使用されるパラメータです。

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

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

IP アドレスをサーバーにバインドする

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

msg-svr-base/sbin/ha_ip_config を実行します。

スクリプトによって、次に示す質問が表示されます。質問に対して control-d を入力すると、スクリプトを中止できます。質問へのデフォルトの回答は角括弧 [ ] で囲んで示されます。デフォルトの回答を変更しない場合は、RETURN キーだけを押します。
1. 論理 IP アドレス: Messaging Server が使用する予定の論理ホスト名に割り当てられる IP アドレスを指定します。IP アドレスは 123.456.78.90 のように、ドット区切りの 10 進形式で指定する必要があります。
  
  論理 IP アドレスは configutil のパラメータ service.http.smtphost に自動的に設定されます。このパラメータにより、クラスタ内のどのマシンがメッセージングシステムを実行しているかを確認できます。たとえば、Messenger Express を使用している場合、送信メールの送信元メールホストをサーバーが判別できます。
2. Messaging Server ベース (msg-svr-base): Messaging Server がインストールされる最上位ディレクトリの絶対パスを指定します。
3. 上の選択のいずれかを変更しますか。それまでの回答を変更せずに設定変更を有効にするには「no」と回答します。回答を変更する場合は「yes」と回答します。
  
  注 –
  ha_ip_config スクリプトはこれらの処理に加えて、2 つの新しいプロセス watcher および msprobe を自動的に有効にします。その際、local.autorestart パラメータと local.watcher.enable パラメータが使用されます。これらの新しいパラメータは、メッセージングサーバーの健全性を監視するために役立ちます。プロセスの障害や応答しないサービスがある場合、特定の障害を示すログメッセージが出力されます。クラスタエージェントは watcher プロセスを監視し、このプロセスが終了するたびにフェイルオーバーするようになりました。Sun Cluster を正しく機能させるためにはこれらのパラメータを有効にする必要がある点に注意してください。
  
  watcher プロセスと msprobe プロセスの詳細については、「4.5 障害が発生したサービスや応答がないサービスの自動再起動」を参照してください。

3.4.5 Messaging Server HA を管理するのに便利な Sun Cluster コマンド

Messaging Server リソースを有効にするには、次のコマンドを実行します。

# scswitch -e -j messaging-resource

Messaging Server リソースを無効にするには、次のコマンドを実行します。

# scswitch -n -j cal-resource

すべてのリソースおよびリソースグループを一覧表示するには、次のコマンドを実行します。

# scstat -pvv

プロセス監視機能 (PMF) タグ、つまり PMF で監視されるプロセスを判断するには、次のコマンドを実行します。

# pmfadm -L

すべてのリソースおよびリソースグループと、それらの状態を一覧表示するには、次のコマンドを実行します。

# scstat -g

Sun Cluster を管理するには、次のコマンドを実行します。

scsetup

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

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

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

注 –

Veritas インストールの関連事項は次のとおりです。

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 サポートに関連するその他の手順を「3.4.4 サーバーへの IP アドレスのバインド」で確認してください。

3.5.1 Veritas Cluster Server 要件

次の手順 (「3.5.2 VCS 3.5 のインストールと設定上の注意」) で説明するように、Veritas Cluster Software が Messaging Server ソフトウェアとともに両方のノードにあらかじめインストールされ、設定されていること。

3.5.2 VCS 3.5 のインストールと設定上の注意

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

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

Veritas Cluster Server 3.5 を使用して Messaging Server を HA サービスとして設定する

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

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

Cluster Explorer を起動するには、次のコマンドを実行します。
# /opt/VRTSvcs/bin/hagui
GUI を使用するため、VRTScscm パッケージがインストールされている必要があります。

タイプ DiskGroup のディスクグループリソース s1ms_dg を追加して、有効にします。

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

s1ms_mt と s1ms_dg の間にリンクを作成します。リソース s1ms_mt を有効にします。

次の図は依存関係ツリーを示したものです。

図 3–5 Veritas Cluster Server 依存関係ツリー 1

Java Enterprise System インストーラを実行し、管理サーバーと Messaging Server を選択します。
1. 管理サーバーの設定中、ホスト名の入力を求められたときは必ず論理ホスト名を指定します。
2. 第一のノード (たとえば、Node_A) から Messaging Server 設定プログラムを実行して Messaging Server をインストールします。
3. pkgadd(1M) コマンドを使用して、Veritas Cluster Server エージェントパッケージ SUNWmsgvc (Java Enterprise System CD の Messaging Server Product サブディレクトリ内) をインストールします。
  
  これで、Messaging Server と Veritas エージェントが Node_A にインストールされます。

バックアップノード (たとえば、Node_B) に切り替えます。

Java Enterprise System インストーラを実行して、バックアップノード (Node_B) に Messaging Server をインストールします。

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

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

Cluster Explorer の「File」メニューから「Import Types」を選択し、ファイル選択ダイアログボックスを表示します。

/etc/VRTSvcs/conf/config ディレクトリから MsgSrvTypes.cf タイプをインポートします。このタイプファイルをインポートします。このファイルを検索するには、クラスタノード上で作業している必要があります。

ここで、タイプ MsgSrv のリソース (たとえば、Mail) を作成します。このリソースに対して論理ホスト名プロパティーを設定する必要があります。

Mail リソースは s1ms_mt および webip に依存します。次の依存関係ツリーに示すようにリソース間のリンクを作成します。

図 3–6 Veritas Cluster の依存関係ツリー
1. すべてのリソースを有効にし、Mail をオンラインにします。
2. すべてのサーバーが起動したことを確認します。

Node_A に切り替え、高可用性設定が機能しているかどうかをチェックします。

グループ属性 OnlineRetryLimit を 3 から 0 に変更します。変更しないと、フェイルオーバーしたサービスが同じノード上で再起動する可能性があります。

3.5.3 MsgSrv の属性

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

表 3–4 Veritas Cluster Server の属性


属性	説明
`FaultOnMonitorTimeouts`	未設定 (0) の場合、監視 (プローブ) のタイムアウトはリソースの障害としては扱われません。推奨される設定は 2 です。その場合、監視のタイムアウトが 2 回になると、リソースが再起動またはフェイルオーバーします。
`ConfInterval`	障害や再起動がカウントされる時間間隔。サービスのオンライン継続時間がこの設定値に達すると、以前の履歴が消去されます。推奨値は 600 秒です。
`ToleranceLimit`	監視がこの回数だけ OFFLINE を返すと、リソースが FAULTED を宣言します。推奨値はデフォルトのままの「0」です。

3.6 高可用性の設定解除

ここでは、高可用性の設定を解除する方法について説明します。高可用性をアンインストールするには、Veritas または Sun Cluster のマニュアルに記載された手順に従います。

高可用性の設定解除手順は、Veritas Cluster Server と Sun Cluster のどちらを削除するかによって異なります。

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

「Veritas Cluster Server を設定解除する」

Veritas Cluster Server を設定解除する

ここでは、Veritas Cluster Server 用の高可用性コンポーネントを設定解除する方法について説明します。

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

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

iMS5 サービスグループをオンラインに戻し、sharedg リソースを使用可能にします。

インストールの間に作成されたすべての 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

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

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

第 3 章 高可用性の設定