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 ソフトウェアでは、詳しい知識がなくてもデータ・サービスを制御できます。 このメソッドには、以下のものがあります。
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 構成になっていることを確認することが重要です。 これにより、ディスクの障害のために起きるフェールオーバーは防止され、 クラスターの安定度が増します。
DB2 UDB EEE では、 1 つのインスタンスが複数のマシンにわたって構成されるときに、 ファイル共用システムが必要です。 一般的な DB2 UDB EEE 構成では、 ホーム・ディレクトリーが NFS を介して 1 つのマシンからエクスポートされ、 EEE インスタンスに関与しているすべてのマシン上でマウントされています。 相互引き受け構成では、 DB2 UDB EEE は HA-NFS を使用して、 高可用性ファイル共用システムを提供します。 論理ホストの 1 つが HA-NFS を介してファイル・システムをエクスポートしたら、 クラスター内の各マシンは、そのファイル・システムを、 EEE インスタンスのホーム・ディレクトリーとしてマウントします。 HA-NFS についての詳細は、 Sun Cluster の資料を参照してください。
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 を使用して開始できます。