管理の手引き


Sun Cluster 2.2

Sun Cluster 2.2 (SC2.2) は、 Sun Microsystems の高可用性クラスター化製品です。 SC2.2 は単一のクラスターで最大 4 台のマシンをサポートします。 4 台の Ultra Enterprise 10000 を使用すると、 クラスターは最大で 256 個の CPU と 256 GB の RAM を持つことができます。

サポートされるシステム


システム UltraSPARC メモリー容量 入出力
Ultra Enterprise 1 1 64MB 〜 1GB 3 SBus
Ultra Enterprise 2 1 〜 2 64MB 〜 2GB 4 SBus
Ultra Enterprise 450 1 〜 4 32MB 〜 4GB 10 PCI
Ultra Enterprise 3000 1 〜 6 64MB 〜 6GB 9 SBus
Ultra Enterprise 4000 1 〜 14 64MB 〜 14GB 21 SBus
Ultra Enterprise 5000 1 〜 14 64MB 〜 14GB 21 SBus
Ultra Enterprise 6000 1 〜 30 64MB 〜 30GB 45 SBus
Ultra Enterprise 10000 1 〜 64 512MB 〜 64GB 64 SBus

エージェント

Sun Cluster ソフトウェアには、 SC2.2 製品に付属してサポートされる、 多数の高可用性エージェントが含まれています。 他の HA エージェント (たとえば、DB2 のエージェント) は、Sun の外部で開発されており、 Sun Cluster ソフトウェアには付属していません。 DB2 の HA エージェントは DB2 に付属しており、 IBM によってサポートされています。

Sun Cluster ソフトウェアは、 Sun Cluster ソフトウェアの各種構成要素に対応するメソッド (スクリプトまたはプログラム) を登録する機会を提供することにより、 高可用性データ・サービスを処理します。 これらのメソッドを使用して、 SC2.2 ソフトウェアでは、詳しい知識がなくてもデータ・サービスを制御できます。 このメソッドには、以下のものがあります。

START
論理ネットワーク・インターフェースがオンラインになる前に、 データ・サービスの一部を開始します。

START_NET
論理ネットワーク・インターフェースがオンラインになった後に、 データ・サービスの一部を開始します。

STOP
論理ネットワーク・インターフェースがオフラインになった後に、 データ・サービスの一部を停止します。

STOP_NET
論理ネットワーク・インターフェースがオフラインになる前に、 データ・サービスの一部を停止します。

ABORT
STOP メソッドに似ていますが、 クラスター・ソフトウェアによりマシンがダウン状態になる直前に実行されるという点が異なります。 この場合、マシンの「健康」が重要であるため、 データ・サービスでは、 マシンがダウン状態になる前に「最後のお願い」要求を実行することができます。 このメソッドは、論理ネットワーク・インターフェースがオフラインになった後に実行されます。

ABORT_NET
ABORT メソッドに似ていますが、 論理ネットワーク・インターフェースがオフラインになる前に実行されるという点が異なります。

FM_INIT
障害モニターを初期化します。

FM_START
障害モニターを開始します。

FM_STOP
障害モニターを停止します。

FM_CHECK
hactl コマンドにより呼び出されます。 対応するデータ・サービスの現行の状態を戻します。

DB2 エージェントは、スクリプト START_NET、STOP_NET、FM_START、および FM_STOP で構成されています。 スクリプト ABORT、ABORT_NET、および FM_CHECK はクラスターの再構成時に実行されません。

高可用性エージェントは、 これらのメソッドの 1 つまたは複数で構成されます。 メソッドは、 hareg コマンドにより SC2.2 に登録されます。 メソッドが登録されると、 Sun Cluster は対応するメソッドを呼び出して、 データ・サービスを制御します。

サービスの ABORT および STOP メソッドは呼び出されない場合があることを覚えておくことは大切です。 これらのメソッドはデータ・サービスの制御シャットダウンを目的としており、 データ・サービスは、 これらのメソッドを呼び出さずにマシンに障害が起きても回復できなければなりません。

詳細については、 Sun Cluster の資料を参照してください。

論理ホスト

SC2.2 ソフトウェアは、論理ホストの概念を使用します。 論理ホスト は、 一連のディスクと 1 つ以上の論理公衆ネットワーク・インターフェースで構成されます。 高可用性データ・サービスは論理ホストと関連しており、 論理ホストのディスク・グループにあるディスクを必要とします。 論理ホストは、クラスター内のさまざまなマシンによってホスト可能で、 実行されているマシンの CPU およびメモリーを「借りる」ことができます。

論理ネットワーク・インターフェース

他の UNIX ベースのオペレーティング・システムと同様、 Solaris にも、ネットワーク・インターフェースの 1 次 IP アドレスに加えて、 追加 IP アドレスを持つ機能があります。 追加 IP アドレスは、 1 次 IP アドレスが物理ネットワーク・インターフェースに常駐するのと同じ方法で、 論理インターフェースに常駐します。 以下は、 クラスター内の 2 つのマシン上にある論理インターフェースの例です。 2 つのホストがあり、 両方とも現在、マシン「thrash」上にあります。

   scadmin@crackle(202)# netstat -in
   Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
   lo0 8232 127.0.0.0 127.0.0.1 289966 0 289966 0 0 0
   hme0 1500 9.21.55.0 9.21.55.98 121657 6098 764122 0 0 0
   scid0 16321 204.152.65.0 204.152.65.1 489307 0 476479 0 0 0
   scid0:1 16321 204.152.65.32 204.152.65.33 0 0 0 0 0 0
   scid1 16321 204.152.65.16 204.152.65.17 347317 0 348073 0 0 0
 
     1. lo0 は loopback インターフェースです。
     2. hme0 は公衆ネットワーク・インターフェース (イーサネット) です。
     3. scid0 は最初の私設ネットワーク・インターフェース (SCI
        (スケーラブル・コヒーレント・インターフェース)) です。
     4. scid0:1 は Sun Cluster ソフトウェアが内部で使用する
        論理ネットワーク・インターフェースです。
     5. scid1 は 2 番目の私設ネットワーク・インターフェースです。
 
   scadmin@thrash(203)# netstat -in
   Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
   lo0 8232 127.0.0.0 127.0.0.1 1128780 0 118780 0 0 0
   hme0 1500 9.21.55.0 9.21.55.92 1741422 5692 757127 0 0 0
   hme0:1 1500 9.21.55.0 9.21.55.109 0 0 0 0 0 0
   hme0:2 1500 9.21.55.0 9.21.55.110 0 0 0 0 0 0
   scid0 16321 204.152.65.0 204.152.65.2 476641 0 489476 0 0 0
   scid0:1 16321 204.152.65.32 204.152.65.34 0 0 0 0 0 0
   scid1 16321 204.152.65.16 204.152.65.18 348199 0 347444 0 0 0
 
     1. hme0:1 は論理ホストの論理ネットワーク・インターフェースです。
     2. hme0:2 は別の論理ホストの論理ネットワーク・インターフェースです。

論理ホストには、 1 つまたは複数の論理インターフェースが関連付けられています。 これらの論理インターフェースは、 論理ホストとともにマシン間を移動し、 論理ホストと関連したデータ・サービスにアクセスするために使用されます。 これらの論理インターフェースは論理ホストとともに移動するので、 クライアントは、 データ・サービスが常駐するマシンとは無関係に、 そのデータ・サービスにアクセスすることができます。

高可用性データ・サービスは、 TCP/IP アドレス INADDR_ANY にバインドされます。 これにより、 システム上の各 IP アドレスは、 データ・サービスのための接続を確実に受け取ることができます。 代わりに、データ・サービスが特定の IP アドレスにバインドされる場合、 データ・サービスをホストしている論理ホストに関連した論理インターフェースをバインドしなければなりません。 INADDR_ANY にバインドしておけば、 データ・サービスの必要とする新規 IP アドレスがシステムに到着した場合に、 その IP アドレスに再バインドする必要がありません。
注:HA インスタンスのクライアントは、 論理ホストの論理 IP アドレスのホスト名を使用して、 データベースをカタログ化します。 ここではマシンの 1 次ホスト名は使用すべきではありません。 DB2 がそのマシン上で実行されているという保証はないからです。

ディスク・グループとファイル・システム

データ・サービス用のディスクは、 グループ単位 (またはセット単位) で論理ホストと関連付けられます。 クラスターが Sun StorEdge Volume Manager (Veritas) を実行中の場合、 Sun Cluster ソフトウェアは、 Veritas の「vxdg」ユーティリティーを使用して、 各論理ホストのディスク・グループをインポートおよびデポート (追放) します。 以下に示すのは、2 つの論理ホスト「log0」および「log1」のディスク・グループの例です。 これらの論理ホストは「thrash」というマシンによってホストされています。 「crackle」というマシンは、 現在どの論理ホストのホストにもなっていません。

   scadmin@crackle(206)# vxdg list
   NAME STATE ID
   rootdg enabled 899825206.1025.crackle
 
   scadmin@thrash(205)# vxdg list
   NAME STATE ID
   rootdg enabled 924176206.1025.thrash
   data0 enabled 925142028.1157.crackle=
   data1 enabled 899826248.1108.crackle

ディスク・グループ「data0」および「data1」はそれぞれ、 論理ホスト「log0」および「log1」と対応します。 ディスク・グループ「data0」は、 以下のコマンドを実行することによって「thrash」からデポートすることができます。

   vxdg deport data0

また、以下のコマンドを実行して「crackle」にインポートできます。

   vxdg import data1

これは Sun Cluster ソフトウェアによって自動的に行われるもので、 活動状態のクラスター上で手作業で行ってはなりません。

それぞれのディスク・グループには、 クラスター内の 2 つ以上のマシン間で共有可能な多数のディスクが含まれています。 論理ホストは、自身が属するディスク・グループ内のディスクに物理アクセス可能なマシンにのみ移動できます。

各論理ホストのファイル・システムを制御する 2 つのファイルがあります。

   /etc/opt/SUNWcluster/conf/hanfs/vfstab.<logical_host>
   /etc/opt/SUNWcluster/conf/hanfs/dfstab.<logical_host>

logical_host は、 関連する論理ホスト名です。

vfstab ファイルは /etc/vfstab ファイルと類似していますが、 ディスク・グループが論理ホスト用にインポートされた後でマウントされるファイル・システムの項目を含むという点が異なります。 dfstab ファイルは /etc/dfs/dfstab ファイルと類似していますが、 HA-NFS を介して論理ホスト用にエクスポートされるファイル・システムの項目を含むという点が異なります。 各マシンにはこれらのファイルの独自コピーがあるため、 クラスター内の各マシンで同じ内容になるように注意を払う必要があります。
注:論理ホストの vfstab ファイルおよび dfstab ファイルのパスは、 hanfs ディレクトリーが含まれているため、間違いやすくなっています。 論理ホストの dfstab ファイルだけが HA-NFS で使用されます。 vfstab ファイルは、 HA-NFS が構成されていなくても使用されます。

以下に示すのは、 相互引き受け構成の DB2 ユニバーサル・データベース エンタープライズ拡張エディション (EEE) を実行しているクラスターの例です。

   scadmin@thrash(217)# ls -l /etc/opt/SUNWcluster/conf/hanfs
   total 8
   -rw-r--r-- 1 root build 173 Apr 14 15:01 dfstab.log0
   -rw-r--r-- 1 root build 316 Apr 26 12:07 vfstab.log0
   -rw-r--r-- 1 root build 389 Apr 13 21:04 vfstab.log1
 
   scadmin@thrash(218)# cat dfstab.log0
   share -F nfs -o root=crackle:thrash:\
   jolt:bump:crackle.torolab.ibm.com:thrash.torolab.ibm.com:\
   jolt.torolab.ibm.com:bump.torolab.ibm.com /log0/home

ファイル・システム /log0/home をマウントする許可が与えられているホストは、 クラスター内の各マシン上のすべてのネットワーク・インターフェース (論理および物理) から来ています。 ファイル・システムはルート許可とともにエクスポートされます。

scadmin@thrash(220)# cat vfstab.log0
#device to mount             device  to fsck               mount       FS   fsck mount   options
#                                                          point       type pass at boot
/dev/vx/dsk/data0/data1-stat /dev/vx/rdsk/data0/data1-stat /log0       ufs  2    no      -
/dev/vx/dsk/data0/vol01      /dev/vx/rdsk/data0/vol01      /log0/home  ufs  2    no      -
/dev/vx/dsk/data0/vol02      /dev/vx/rdsk/data0/vol02      /log0/data  ufs  2    no      -
 
scadmin@thrash(221)# cat vfstab.log1
#device to mount             device  to fsck               mount       FS   fsck mount   options
#                                                          point       type pass at boot
 
/dev/vx/dsk/data1/data1-stat /dev/vx/rdsk/data1/data1-stat /log1       ufs  2    no      -
/dev/vx/dsk/data1/vol01      /dev/vx/rdsk/data1/vol01      /log1/home  ufs  2    no      -
/dev/vx/dsk/data1/vol02      /dev/vx/rdsk/data1/vol02      /log1/data  ufs  2    no      -
/dev/vx/dsk/data1/vol03      /dev/vx/rdsk/data1/vol03      /log1/data1 ufs  2    no      -

vfstab.log0 ファイルには、 /log0 ディレクトリーの下にあるファイル・システム用に、 3 つの有効な項目が含まれます。 論理ホスト log0 のファイル・システムが 論理ボリューム装置を使用していることに注意してください。 これは、 論理ホストに関連したディスク・グループ data0 の一部です。

vfstab ファイル内のファイル・システムは上から下の順にマウントされるので、 ファイル・システムが正しい順序でリストされているか確認することは重要です。 特定のファイル・システムの下にマウントされるファイル・システムは、 上位のファイル・システムより下にリストしなければなりません。 論理ホストで必要な実際のファイル・システムは、 データ・サービスの必要に依存しており、 これらの例とは大きく異なります。

フェールオーバー時に、SC2.2 ソフトウェアは、 論理ホストに関連するディスク・グループおよび論理インターフェースが、 クラスター内のマシンの間で論理ホストとともに移動することを保証します。 高可用性データ・サービスは、 フェールオーバーの後に、 少なくともこれらのリソースが新規システム上で使用可能にされることを予期します。 実際には、多くのデータ・サービスはそれらが高可用性であることに気付いてさえおらず、 これらのリソースをフェールオーバー後もまったく同じように「認識する」でしょう。

制御メソッド

制御メソッドは以下を使用して登録されます。

   hareg(1m)

HA サービスが登録されると、 SC 2.2 はクラスターの再構成またはフェールオーバー中の適切な時刻に、 HA サービスに登録されたメソッドを呼び出します。

クラスターの再構成 (制御フェールオーバー) 時には、 以下の処理が (指定された順序で) 行われます。 マシンがクラッシュした場合、 ステップ 5c より前のアクションは行われません。 (クラスターの再構成についての詳細は、 SC2.2 の資料を参照してください。)

  1. FM_STOP メソッドが実行されます。
  2. STOP_NET メソッドが実行されます。
  3. 論理ホストの論理インターフェースがオフラインになります。
       - ifconfig hme0:1 0.0.0.0 down
  4. STOP メソッドが実行されます。
  5. ディスク・グループとファイル・システムが移動されます。
       a. 論理ホストのファイル・システムをアンマウントします。
       b. vxdg は 1 つのマシン上にディスク・グループをデポートします。
 
     - - 以下のステップはマシンがクラッシュした場合にのみ実行されます - -
 
       c. vxdg は 別のマシン上にディスク・グループをインポートします。
       d. 論理ホスト・ファイル・システムに対して fsck を実行します。
       e. 論理ホスト・ファイル・システムをマウントします。
  6. START メソッドが実行されます。
  7. 論理ホストの論理インターフェースがオンラインになります。
       - ifconfig hme0:1 <ip address> up
  8. START_NET メソッドが実行されます。
  9. FM_INIT メソッドが実行されます。
 10. FM_START メソッドが実行されます。

制御メソッドは、 以下のコマンド行引き数を使用して実行されます。

   METHOD <logical hosts being hosted> <logical hosts not being hosted> <time-out>

最初の引き数は、 現在ホストされている論理ホストのコンマ区切りリストで、 2 番目は、 現在ホストされていない論理ホストのコンマ区切りリストです。 最後の引き数は、メソッドのタイムアウト、 つまり、SC2.2 ソフトウェアが打ちきるまでにメソッドを実行できる時間の合計です。

ディスクとファイル・システムの構成

SC2.2 は 2 つのボリューム・マネージャー Sun StorEdge Volume Manager (Veritas) および Solstice Disk Suite をサポートしています。 両方とも正常に機能しますが、 StorEdge Volume Manager は、クラスター環境でいくらか有利です。 クラスター構成によっては、 ディスク格納装置のコントローラー番号が、 クラスター内のマシンごとに異なる場合があります。 コントローラー番号が違うと、 コントローラーのディスク装置へのパスも異なります。 Disk Suite はディスク装置へのパスを直接使用するので、 この状況では十分機能しません。 StorEdge Volume Manager は、 コントローラー番号に関係なく、 ディスクそのものを使用するので、 コントローラー番号が違っても影響を受けません。

HA の目標はデータ・サービスの可用性を上げることなので、 すべてのファイル・システムおよびディスク装置がミラーリングされているか、 または RAID 構成になっていることを確認することが重要です。 これにより、ディスクの障害のために起きるフェールオーバーは防止され、 クラスターの安定度が増します。

HA-NFS

DB2 UDB EEE では、 1 つのインスタンスが複数のマシンにわたって構成されるときに、 ファイル共用システムが必要です。 一般的な DB2 UDB EEE 構成では、 ホーム・ディレクトリーが NFS を介して 1 つのマシンからエクスポートされ、 EEE インスタンスに関与しているすべてのマシン上でマウントされています。 相互引き受け構成では、 DB2 UDB EEE は HA-NFS を使用して、 高可用性ファイル共用システムを提供します。 論理ホストの 1 つが HA-NFS を介してファイル・システムをエクスポートしたら、 クラスター内の各マシンは、そのファイル・システムを、 EEE インスタンスのホーム・ディレクトリーとしてマウントします。 HA-NFS についての詳細は、 Sun Cluster の資料を参照してください。

cconsole および ctelnet ユーティリティー

SC2.2 には、2 つの役立つユーティリティー cconsole および ctelnet が付属しています。 これらのユーティリティーを使用すれば、 単一のコマンドをクラスター内の複数のマシンに同時に発行することができます。 これらのユーティリティーを使用して構成ファイルを編集すれば、 確実にクラスター内の全マシンで構成ファイルを等しい状態に保つことができます。 また、これらのユーティリティーを使用すれば、 各マシンでまったく同じ方法によりソフトウェアをインストールすることもできます。 これらのユーティリティーについての詳細は、 Sun Cluster の資料を参照してください。

キャンパス・クラスタリングとコンチネンタル・クラスタリング

クラスター内のマシンが同じ建物にない場合、 そのクラスターはキャンパス・クラスター と呼ばれます。 キャンパス・クラスターは、 単一の障害ポイントとして建物自体を除去する場合に役に立ちます。 たとえば、クラスター内のマシンがすべて同じ建物にあり、 それが焼け落ちた場合、 クラスター全体に影響が及びます。 しかし、マシンが複数の建物にあれば、 建物の 1 つが燃えても、クラスターは存続します。

コンチネンタル・クラスター は、 マシンが別々の都市に分散しているクラスターです。 このクラスターの目標は、単一の障害ポイントとして地域を除去することです。 このタイプのクラスターは、 地震や津波のような災害からの保護を提供します。

現在、Sun Cluster は、10 km (約 6 マイル) の範囲内にあるマシンをサポートできます。 このため、 2 つの異なるサイトの間での高速接続を必要とする人にとって、 キャンパス・クラスタリングは実際的なオプションとなります。 クラスターには、2 つの私用内部接続と、 共用ディスクのための多数の光ファイバー・ケーブルが必要です。 2 つのサイトの間の高速接続にかかるコストは、 その利点によって相殺されます。

一般的な問題

SC2.2 ソフトウェアは Cluster Configuration Database (CCD(4)) を使用して、 クラスター構成用にクラスター全体の単一リポジトリーを提供します。 CCD には専用 API があり、 /etc/opt/SUNWcluster/conf ディレクトリーの下に保管されます。 まれに、CCD の同期がとれなくなり、 修正が必要となる場合があります。 この状況で CCD を修正する最善の方法は、 バックアップ・コピーから復元することです。

CCD をバックアップするには、 クラスター内の全マシンでクラスター・ソフトウェアをシャットダウンし、 /etc/opt/SUNWcluster/conf ディレクトリーを tar 圧縮して、 tar ファイルを安全な場所に保管します。 バックアップを作成したときにクラスター・ソフトウェアがシャットダウンされていないと、 CCD を復元するときに問題が起きる可能性があります。 クラスター構成が変更されたときに新規バックアップをとることにより、 バックアップ・コピーが最新の状態に保たれるようにしてください。 CCD を復元するには、 クラスター内の全マシン上でクラスター・ソフトウェアをシャットダウンし、 conf ディレクトリーを conf.old に移動して、 バックアップ・コピーを tar 解凍します。 クラスターは、 新規の CCD を使用して開始できます。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]