Sun Cluster 3.0 ご使用にあたって

既知の問題

次に説明する既知の問題は、Sun Cluster 3.0 リリースの動作に影響するものです。最新の情報については、http://docs.sun.com で提供されるリリースノートを参照するか、ご購入先にお問い合わせください。

バグ ID 4314698

問題の概要: Solstice Disksuite ソフトウェアをインストールした後、Solstice Disksuite のデバイスリンクを広域名前空間に表示させるには scgdevs(1M) コマンドを実行する必要がある。

回避方法: scgdevs コマンドを手作業で実行して Solstice Disksuite デバイスのノードが作成されたことを確認します。

バグ ID 4346123

問題の概要: 複数の障害が起こった後でクラスタノードを起動すると、クラスタのファイルシステムが /etc/vfstab エントリの自動マウントに失敗し、起動プロセスがノードを管理シェルに置いてしまう。デバイスに fsck コマンドを実行すると、このエラーが起きることがある。

# fsck -y /dev/global/rdsk/d1s7
** /dev/global/rdsk/d1s7
Can't roll the log for /dev/global/rdsk/d1s7

回避方法: この問題は広域デバイスが無効なクラスタファイルシステムのマウントと関連付けられている時に発生することがあります。次のコマンドを実行し、ファイルシステムが無効マウントを示すエラー状態を表示するかどうかを確認してください。

# /usr/bin/df -k

広域デバイスが無効なクラスタファイルシステムのマウントと関連付けられている場合は、その広域デバイスをマウント解除します。いずれかのクラスタノードにファイルシステムのユーザーがアクセスしている場合は、マウント解除できないので注意してください。各ノードで次のコマンドを実行し、現在ファイルシステムにユーザーがアクセスしているかどうかを確認します。

# /usr/sbin/fuser -c mountpoint

また、share(1M) コマンドを実行し、クラスタノードでファイルシステムが NFS 共有されていないことを確認します。

バグ ID 4358349

問題の概要: SharedAddress リソースを含むリソースグループに Sun Cluster HA for NFS のリソースを作成できない。Sun Cluster ソフトウェアでは、このデータサービスで SharedAddress リソースの使用をサポートされない。

回避方法: フェイルオーバーリソースグループに必要な論理ホスト名リソースを追加します。

この手順を行うには LogicalHostname リソースを設定する必要があります。Sun Cluster HA for NFS と一緒に使用するホスト名には SharedAddress リソースは使えません。

# scrgadm -a -L -g resource-group-name -l hostname,...

-a -L -g resource-group-name: 論理ホスト名リソースを置くフェイルオーバーリソースグループを指定します。
-l hostname,...: 追加するネットワークリソース (論理ホスト名) を指定します。

バグ ID 4358629

問題の概要: Sun Cluster 2.2 ソフトウェアのために作成した論理ホストがホスト名ではなく IP アドレス番号を使用している場合に、Sun Cluster 2.2 から Sun Cluster 3.0 へのソフトウェアのアップグレードが失敗する可能性がある。

回避方法: この問題の解決方法は 2 つあります。

クラスタで Sun Cluster 2.2 ソフトウェアが動作中の場合は、scconf(1M) コマンドを再実行して LOGIP フィールドを IP アドレスから実際の名前にリセットします。
# scconf clustername -L logical_host -n host_list -g diskgroup_list -i adapter_list,logical_hostname
次に、LOGIP フィールドを IP アドレスから実際の名前にリセットする例を示します。
# scconf schost -L schost-1 -n phys-schost-1,phys-schost-2 -g schost-1 -i hme0,hme0,schost-1
クラスタがすでに Sun Cluster 3.0 ソフトウェアにアップグレードされている場合は、アップグレードしたノードの ccd ファイルの、保存済みのコピーを編集します。/var/cluster/logs/install/preserve/2.2/SUNWcluster/conf ディレクトリの ccd ファイルを編集し、LOGIP フィールドを実際の名前に置き換えます。

たとえば、次の行で指定されている IP アドレスは、その IP アドレスに対応する論理ホスト名に変更する必要があります。
LOGIP:phys-schost-1,phys-schost-2:hme0,hme0:192.29.72.238:1
ccd ファイルの IP アドレスを対応する論理ホスト名に置き換えます。
LOGIP:phys-schost-1,phys-schost-2:hme0,hme0:schost-1:1

バグ ID 4359321

問題の概要: scinstall ユーティリティを使用すると /global ディレクトリを広域デバイスファイルシステムに指定できる。しかし、広域デバイスファイルシステムのマウントポイントが /global/.devices/node@nodeid のために、この仕様は実際には使用できない。

回避方法: 広域デバイスファイルシステムの正しい名前を使用してノードを再インストールします。

推奨はできませんが、/etc/vfstab ファイルのエントリを修正してクラスタを再起動し、scgdevs コマンドを実行して回避することも可能です。各 /etc/vfstab ファイルの /global/.devices/node@nodeid の各エントリに、広域マウントのオプションセットがあるかどうかを確認してください。

バグ ID 4362435

問題の概要: Sun Cluster 3.0 のモジュールを Sun Management Center 2.1 のコンソールに読み込み、「Resource Type Definition」->「Properties Table」にアクセスしようとすると、テーブルが 1 ページを超える長さの場合に読み込まれない。

回避方法: すべてのリソースタイプのプロパティを表示するには scrgadm -pvv コマンドを実行します。

バグ ID 4362925

問題の概要:

nodeA# scshutdown -g0 -y
scshutdown: Unmount of /dev/md/sc/dsk/d30 failed: Device busy.
scshutdown: Could not unmount all PxFS filesystems.

Oracle をインストールすると、Networker パッケージがバンドルされてインストールされる。そのため、nsrmmd デーモンが起動して /global/oracle ディレクトリにマウントを行い、すべてのクラスタファイルシステムをマウント解除できなくなる。

nodeA# umount /global/oracle
umount: global/oracle busy
nodeA# fuser -c /global/oracle
/global/oracle: nodeA# umount /global/oracle
umount: global/oracle busy
nodeA# fuser -c /global/oracle
/global/oracle: 335co 317co 302co 273co 272co
nodeA# ps -ef|grep 335
 root 335 273 0 17:17:41 ?       0:00 /usr/sbin/nsrmmd -n 1
 root 448 397 0 17:19:37 console 0:00 grep 335

この問題は Sun Cluster を停止するときに、nsrmmd プロセスがまだ参照しているクラスタファイルシステムをマウント解除しようとする際に発生する。

回避方法: 各ノードで fuser(1M) コマンドを実行し、マウント解除できないクラスタファイルシステムを使用しているすべてのプロセスのリストを作成します。scshutdown(1M) コマンドが最初に起動して失敗したことにより、Resource Group Manager のリソースが再起動されていないことを確認します。プロセスをすべて kill -9 コマンドで終了します。この削除リストには、Resource Group Manager の管理下にあるプロセスを含めてはなりません。これらのプロセスをすべて終了させてから scshutdown コマンドを再実行すると、停止動作は正常に実行されて終了します。

バグ ID 4365310

問題の概要: リソースの状態が STOP_FAILED になると、手作業でリソースの STOP_FAILED フラグをクリアしなければならなくなる。複数のリソースのフラグのクリアを指定した場合に、その中に STOP_FAILED 状態ではないフラグがあると、他のリソースの STOP_FAILED フラグをクリアせずに関数が早く戻ってしまう。

この場合にはエラーメッセージは表示されないが、他のリソースのフラグはクリアされていない。エラーメッセージが表示されないため、コマンドで指定したリソースの STOP_FAILED フラッグがクリアされていないにもかかわらず、何もエラーが発生しなかったかのように見える。

回避方法: この問題を回避するには、STOP_FAILED 状態になった各リソースの STOP_FAILED フラグを個別にクリアしてください。

# scswitch -c -f STOP_FAILED -j stopfailres -h phys-schost-1

バグ ID 4365700

問題の概要: 次の例では、同一グループの複数のリソースが単一のコマンドで無効にされている。

# scswitch -n -j r1,r2,r3

最初のリソースが STOP_FAILED 状態に移行すると、残りのリソースは無効になってもオンラインのまま残ってしまう。このようなオンライン状態は Resource Group Manager デーモンにとって無効な内部状態なので、Resource Group Manager デーモンがパニックを起こすことがある。

回避方法: リソースを無効にする際には、常に 1 つのリソースだけを scswitch(1M) コマンドで無効にするようにします。

バグ ID 4365729

問題の概要: デバイスグループを次のコマンドを使用して保守モードにしようとすると、ファイルシステムが特定のデバイスグループにマウントされている場合に失敗する。

# scswitch -m -D device-group

回避方法: 保守モードにするデバイスグループ上のすべてのファイルシステムをマウント解除します。デバイスグループを保守モードにできるのは、そのデバイスグループのデバイスが利用されていない場合だけです。そのデバイスグループのデバイスにアクティブなユーザーが存在してはならないため、依存するファイルシステムはすべてマウント解除します。

バグ ID 4366840

問題の概要: クラスタ内にダウンしているノードがあるときに、そのクラスタからケーブルや関連するアダプタまたは接続点を取り外すと、ノードを再起動してクラスタに再結合しようとする場合にパニックを起こす。

回避方法: このバグが修正されるまでは、ノードがダウンしているときにクラスタからケーブルやアダプタ、接続点を取り外さないでください。パニックが発生した場合は、もう 1 度ノードを再起動してください。ノードはパニックを起こさずにクラスタに結合できます。

バグ ID 4366886

問題の概要: システムの負荷が高いと、デバイスグループをオンラインにする際に問題が発生することがある。この問題は、VERITAS Volume Manager (VxVM) がディスクグループのインポートのために、ミラーの同期などいくつかのタスクを実行する必要があるために起こる。負荷が高くなるとこれらのタスクは、他のシステムタスクが重要なシステムリソースを利用しているために時間内で完了することができなくなる。デバイスグループはノードの起動時に (たとえば、ファイルシステムが自動マウントに設定されている場合など) 自動的に一緒にオンラインになるので、このようなオンラインのハングは起動時のハングとして発生することがある。

回避方法: システムの負荷を低減するか、vxconfigd デーモンの優先度を上げてください。

バグ ID 4368034

問題の概要: Resource Group Manager デーモンが停止した場合や、遠隔手続き呼び出しの途中でノードが停止した場合に、次のようなエラーメッセージがシステムコンソールに表示されることがある。

COMM_FAILURE SystemException: COMM_FAILURE major 3 minor 0 Error 0 completed NO

INV_OBJREF SystemException: INV_OBJREF major 4 minor 9 Bad file number completed NO

これらのメッセージは一般ユーザーが利用することを意図したものではなく、デバッグのための利用を前提としたものです。Resource Group Manager デーモンによって、この例外に関するより詳細な syslog メッセージがすでに書かれているため、printf のデバッグは不要です。

回避方法: これらのコンソールメッセージは無視してください。ノードの停止に関しては syslog メッセージを参照してください。通常、Resource Group Manager デーモンにより、自動的に復旧します。

バグ ID 4369228

問題の概要: Oracle から提供される dbassist ユーティリティが、ハードウェア RAID デバイスへの Oracle Parallel Server データベースの直接作成を有効にできない。

回避方法: Oracle Parallel Server のデータベースを Sun Cluster 3.0 ソフトウェアで作成するには、Oracle Server Manager のコマンドラインモードである svrgmrl を使用します。

バグ ID 4369565

問題の概要: nfs_upgrade スクリプトが呼び出し回数に依存する。スクリプトを 2 回実行することができない。

回避方法: スクリプトを 2 回実行する場合は、スクリプトの 2 回目の実行前に、最初の試行で作成された NFS リソースと NFS リソースタイプを削除してください。

バグ ID 4369668

問題の概要: 管理しているリソースグループの Nodelist プロパティをシステム管理者が編集する際に、ノードリストに追加されたすべてのノードで、Resource Group Manager はリソースグループに属する Init_nodes=RG_PRIMARIES プロパティを持つすべてのリソースに INIT メソッドを実行する必要がある。ノードリストから削除されたすべてのノードでは、Resource Group Manager は同様にリソースに FINI メソッドを実行する必要がある。また同様に、リソースタイプの Installed_nodes プロパティを編集する際には、管理しているリソースグループに属し、Init_nodes=RT_installed_nodes プロパティを持つこのタイプのすべてのリソースに対して、INIT または FINI のメソッドを実行する必要がある。

現在のところ、Resource Group Manager は、これらの更新を行う際に INIT や FINI のメソッドを実行しない。その結果、これらノードのリソースが正常に初期化またはクリーンアップされない可能性がある。

回避方法: 対象となるリソースグループに scswitch コマンドを使用していったん管理を解除してから、再管理を行います。この処理では、管理者はリソースグループをオフラインにしなければなりません。この代わりに、グループ内で起こるリソースタイプに関する INIT や FINI の操作がマニュアルに記載されている場合は、管理者はその操作を手作業で実行することもできます (リソースグループの管理を解除する必要はありません)。

グループ内のリソースに INIT メソッドや FINI メソッドを持つものがない場合は、この回避策は不要です。Sun が提供するリソースタイプで INIT メソッドと FINI メソッドを使用するのは以下に限られます。

SUNW.SharedAddress (共有アドレスリソースタイプ)
SUNW.apache (Apache Web Server) がスケーラブルモードで構成されている場合
SUNW.iws (iPlanet/Netscape Web Server) がスケーラブルモードで構成されている場合

他社が提供する上記以外のリソースタイプが、INIT メソッドや FINI メソッドを利用する場合もあります。リソースグループにその種のリソースタイプが含まれている場合は、この回避策が必要となります。

注 -

すべてのスケーラブルなサービスは、明示的に宣言していなくても、暗黙的に INIT メソッドと FINI メソッドを利用しています。

バグ ID 4370760

問題の概要: 最初にデバイスグループをオフラインにしないと、メタセットから最後のホストを削除できない。

回避方法: メタセットから最後のホストを削除するには、まずデバイスグループをオフラインにします。最後のホストを削除するには、削除するホストから、次の 2 つのコマンドをスーパーユーザーで実行します。

# /usr/cluster/bin/scswitch -m -D disksetname
# metaset -s disksetname -d -h hostname

バグ ID 4371236

問題の概要: ge スイッチの中には、ge デバイスのパラメータをデフォルト値以外の値に設定しておかなければならないものがる。『Sun GigabitEthernet/P 2.0 Adapter Installation and User's Guide』の第 3 章に ge デバイスのパラメータを変更する方法が説明されてるが、この手順を Sun Cluster 3.0 ソフトウェアを実行中のノードに使用する場合、マニュアルの説明と異なる部分がある。具体的には、/etc/path_to_inst ファイルのデバイスパス名を ge.conf ファイルで使用する親の名前に転用する方法が異なる。

回避方法: 『Sun GigabitEthernet/P 2.0 Adapter Installation and User's Guide』の第 3 章では、/kernel/drv/ge.conf ファイルのエントリを使用して ge デバイスのパラメータ値を変更する手順が説明してあります。/etc/path_to_inst のリスト (ge.conf のエントリで使用) から親の名前を決定する手順は、「Setting Driver Parameters Using a ge.conf File」で説明しています。たとえば、次のような行が /etc/path_to_inst 行にある場合ば、ge2 の親の名前は /pci@4,4000 となります。

"/pci@4,4000/network@4" 2 "ge"

クラスタノードでは、/etc/path_to_inst のデバイスパスから /node@nodeid の部分を取り除く必要があります。たとえば、クラスタノードでは、これに対応する /etc/path_to_inst のエントリは次のようなエントリになっています。

"/node@1/pci@4,4000/network@4" 2 "ge"

ge.conf で ge2 の親の名前として使用するのも、同様に /pci@4,4000 です。

バグ ID 4372369

問題の概要: Sun Cluster 2.2 で複数の論理ホストが構成されていると nfs_upgrade スクリプトが使用できない。

回避方法: 現在のところ回避方法はありません。この問題に遭遇した場合は、適切なパッチがあるかどうかをご購入先にお問い合わせください。

バグ ID 4373498

問題の概要: LDAP 管理サーバーがホスト名の大文字と小文字を区別する。そのため、LDAP 管理サーバーで作業する場合には、LDAP 構成で設定してあるすべてのホスト名が、クラスタノードで使用しているネームサービスの LDAP 仕様と大文字と小文字が一致しなければならない。この大文字と小文字の一致は、特に DNS をネームサービスとして利用している場合には、DNS ドメイン名も同様に LDAP 構成のホスト名の仕様と厳密に一致しなければならないため重要となる。

回避方法: LDAP に与えたマシンの正しいドメイン名とリゾルバから返されるドメイン名の大文字と小文字が一致するかどうかを確認してください。

バグ ID 4373911

問題の概要: 次の操作を行った場合、次の警告メッセージが HA-NFS 障害モニターに表示されることがある。

複数の Sun Cluster HA for NFS リソースをクラスタに構成する。
ある HA-NFS リソースの有効/無効を切り替えて、同一ノードの他のリソースをオンラインのままにしておく。

clnt_tp_create_timed of program statd failed:RPC:Program not registered

回避方法: この警告メッセージは無視して構いません。

バグ ID 4374194

問題の概要: Ultra 2 ワークステーションを Sun StorEdge A5000 と共に使用している場合に、Sun Management Center エージェントが突然終了することがある。この問題は、Sun Management Center エージェントが Config Reader で設定されており、Config-Reader4udt モジュールが /var/opt/SunWsymon/cfg/base-modules-d.dat ファイルに追加されている時に発生する。Sun Management Center エージェントは、このファイルを起動時に読み取り、リストされているモジュールをすべて読み込もうとする。エージェントが Config-Reader4udt モジュールを読み込むときにセグメント例外を起こすことがある。

回避方法: この問題を回避するには、次のいずれかを実行します。

Config-Reader4udt を base-modules-d.dat ファイルから削除する。

Config-Reader4udt を、Ultra 2 マシンに同じ情報を提供する Config-Reader4u に置きかえる。

Sun Management Center エージェントの設定時に、Config Reader モジュールを設定しない。これにより Config-Reader4udt モジュールが base-modules-d.dat ファイルに追加されるのを防止します。

バグ ID 4374648

問題の概要: scinstall のマニュアルページには、-s oracle を使用して自動的に Sun Cluster HA for Oracle のデータサービスを Sun Cluster 2.2 から Sun Cluster 3.0 にアップグレードする例が示されている。このオプションは現在サポートされていない。

回避方法: Oracle データサービスを Sun Cluster 2.2 から Sun Cluster 3.0 にアップグレードするときに、-s oracle オプションを使用しないでください。その代わりに、「Sun Cluster HA for Oracle の Sun Cluster 2.2 から Sun Cluster 3.0 へのアップグレード」にある手作業によるアップグレード手順を使用してください。

バグ ID 4376171

問題の概要: FC-AL SBus Card (FC100/S) と Sun Quad FastEthernet 2.0 (SQFE/S) を同じ SBus に設置すると QFE カードが突然リセットする。

回避方法: クラスタノードの構成で、FC-AL SBus Card (FC100/S) と Sun Quad FastEthernet 2.0 (SQFE/S) を同じ SBus 上に設置しないでください。

バグ ID 4377303

問題の概要: 新規に作成した Sun StorEdge A3500 の LUN がノードで表示されない。

回避方法: 新しい LUN が表示されないノードで /etc/raid/hot_add コマンドを実行します。

バグ ID 4378553

問題の概要: リソースグループの Nodelist プロパティはリソースグループをマスターできるノードのリストで、もっとも優先されるノードが最初に表示される順序になっている。Resource Group Manager は、常に利用可能な中でもっとも優先されるノードのリソースグループのホストになるようになっている。しかし、管理者がクラスタを (すべてのノードを 1 回で再起動することで) 再起動すると、管理されているリソースグループのマスターがもっとも優先されるノード以外のノードになることがある。この問題はクラスタ全体を 1 回で再起動する場合にのみ起こる。

回避方法: クラスタを再起動した後で、scswitch コマンドを使用してリソースグループを目的のノードに切り替えます。クラスタが稼働している限り、Nodelist の優先順位は自動的に切り替わります。

スケーラブルサービスのスティッキー負荷均衡ポリシー

現在、スティッキー負荷均衡ポリシーを使用したスケーラブルデータサービスを実行すると問題が発生する可能性があります。あるノードに関連して確立されたスティッキー状態を使用してサービスが実行されていて、後で別のノードで同じサービスの別のインスタンスを起動すると、この問題が発生することがあります。同じサービスの別のインスタンスを起動すると、最初のインスタンスのスティッキー状態が失われる可能性があります。

2番目のインスタンスを起動した時にスティッキーアルゴリズムが返す結果により、最初のインスタンスがスティッキー状態を失うかどうかが決まります。この場合にはアルゴリズムはスティッキーとの関連を変更することはありませんが、必要に応じてアルゴリズムがスティッキーとの関連を変更することもあります。

スティッキー負荷均衡ポリシーについての詳細は、『Sun Cluster 3.0 の概念』を参照してください。

Sun Cluster HA for Oracle の Sun Cluster 2.2 から Sun Cluster 3.0 へのアップグレード

Sun Cluster フレームワークを scinstall アップグレード手順を使用してアップグレードする場合は、次の手順に従ってください。

条件と制限

Sun Cluster HA for Oracle を Sun Cluster 2.2 から Sun Cluster 3.0 にソフトウェアアップグレードする場合には、次の条件と制限が適用されます。

Sun Cluster HA for Oracle をアップグレードする前に、『Sun Cluster 3.0 ソフトウェアのインストール』に記載されている、Sun Cluster フレームワークを Sun Cluster 2.2 からアップグレードする際に関連するすべての条件に適合していることを確認する必要があります。
アップグレードする前に、Sun Cluster HA for Oracle が Sun Cluster 2.2 で正常に機能している必要があります。

Sun Cluster HA for Oracle の構成ファイルを保存する

次の手順で、Sun Cluster 2.2 で設定した構成ファイルを保存します。

各ノードで、アップグレード開始手順 (scinstall -F begin) が完了するまで、scinstall フレームワークアップグレード手順に従います。

各ノードで、次のコマンドをスーパーユーザーで実行します。このコマンドにより、/var/opt/oracle ディレクトリのすべてのファイルを保存します。

この情報が失われないようにするために、/var/opt/oracle ディレクトリにある構造を外部装置にバックアップします。
# cp -r /var/opt/oracle /var/cluster/logs/install/preserve/2.2/SUNWscor

フレームワークアップグレードの終了部分 (scinstall -u finish) を完了します。

注 -
scinstall -u finish コマンドで -s oracle オプションを使用しないでください。このオプションは Sun Cluster HA for Oracle の自動アップグレードを試みますが、自動アップグレードは失敗します。自動アップグレードがサポートされるのは NFS だけです。

フレームワークのアップグレードが終了したら、Sun Cluster 3.0 の環境を設定します。「Sun Cluster 3.0 環境の設定」を参照してください。

Sun Cluster 3.0 環境の設定

次の手順で Sun Cluster 3.0 環境を設定します。

任意のノードで次のコマンドを実行し、次のことを確認します。
- フレームワークのアップグレードで、Sun Cluster 2.2 の論理ホストに対応する Sun Cluster 3.0 のリソースグループが正しく設定されている。
- リソースグループ内にホスト名のネットワークリソースがあり、オンラインになっている。
# scstat -g

任意のノードで次のコマンドを実行し、Oracle データベース (必要に応じて Oracle バイナリも) を含む、Sun Cluster 2.2 の VERITAS ディスクグループまたは Solstice DiskSuite のディスクセットが、正しく Sun Cluster 3.0 のディスクデバイスグループにマッピングされているかどうかを確認します。
# scstat -D

各ノードで次のコマンドを実行し、各 Oracle インスタンスに必要なファイルシステムがマウントされているかどうかを確認します。
# mount

各ノードで次のコマンドを実行し、保存しておいた Oracle 構成ファイルを /var/opt ディレクトリに復元します。

すでに /var/opt/oracle ディレクトリにファイルを復元しており、内容を変更していない場合は、この手順を省略できます。
# cp -r /var/cluster/logs/install/preserve/2.2/SUNWscor/oracle /var/opt # chown -R oracle:dba /var/opt/oracle

Sun Cluster 3.0 での Sun Cluster HA for Oracle の構成

次の手順で、Sun Cluster 3.0 HA for Oracle を構成します。

注 -

手順 1 は 1 回だけ実行してください。

任意のノードで次のコマンドを実行、Oracle サーバーとリスナーリソースタイプを登録します。
# scrgadm -a -t SUNW.oracle_server # scrgadm -a -t SUNW.oracle_listener
手順 2 から手順 5 までを、/var/opt/oracle/oratab ファイルにある各 Sun Cluster 2.2 HA for Oracle のインスタンスで実行します。

ORACLE_HOME 変数の値を oratab ファイルで確認します。

たとえば、oratab ファイルに次の情報があるとします。
ora32:/oracle/816_32:N
この情報は、ORACLE_SID ora32 インスタンスの ORACLE_HOME 変数の値が /oracle/816_32 であることを意味しています。

ccd.database ファイルから各 Oracle インスタンスのパラメータ値を取り出します。

これらのパラメータは scrgadm で Sun Cluster 3.0 のパラメータにマッピングされます。Sun Cluster HA for Oracle を Sun Cluster 3.0 で構成するときにはこのパラメータを使用します。
# grep ^HAORACLE: /var/cluster/logs/install/preserve/2.2/SUNWcluster/conf/ccd.database
ccd.database ファイルにある各 Oracle インスタンスは、次の書式を使用します。
HAORACLE:on:ora32:boots-1:60:10:120:300:scott/tiger:/oracle/816_32/dbs/initora32.ora:ORA_LIST
.

これらのパラメータは、次の Sun Cluster 3.0 の書式にマッピングされます。
HAORACLE:STATE:ORACLE_SID:LOGICAL_HOSTNAME_IP_Resource:THOROUGH_PROBE_INTERVAL: CONNECT_CYCLE:PROBE_TIMEOUT:RETRY_INTERVAL:CONNECT_STRING:PARAMETER_FILE:LISTENER_NAME
リソースグループ名 RG_NAME は、${LOGICAL_HOSTNAME_IP_Resource}-lh となります。-lh は、自動的に Sun Cluster 3.0 のリソースグループ名に追加されます。

$PARAMETER_FILE 変数に background_dump_dest 値を設定し、ALERT_LOG_FILE 変数に次の値を設定します。
$background_dump_dest/alert_$ORACLE_SID.log
たとえば、ORACLE_SID=ora32 で、$PARAMETER_FILE ファイルの background_dump_dest を次の値と仮定します。
/oracle/816_32/admin/ora32/bdump
この例では、ALERT_LOG_FILE は次の値に更新されます。
/oracle/816_32/admin/ora32/bdump/alert_ora32.log

任意のノードで次のコマンドを実行し、Oracle リソースを作成してオンラインにします。

# scrgadm -a -t SUNW.oracle_server -g $RG_NAME -j $ORACLE_SID-serv ¥ 
-x Oracle_sid=$ORACLE_SID -x Oracle_home=$ORACLE_HOME ¥ 
-y Thorough_probe_interval=$THOROUGH_PROBE_INTERVAL ¥ 
-x Connect_cycle=$CONNECT_CYCLE -x Probe_timeout=$PROBE_TIMEOUT ¥ 
-y Retry_interval=$RETRY_INTERVAL -x Connect_string=$CONNECT_STRING ¥ 
-x Parameter_file=$PARAMETER_FILE -x Alert_log_file=$ALERT_LOG_FILE
# scrgadm -a -j $ORACLE_SID-list -t SUNW.oracle_listener -g $RG_name ¥ 
-x Oracle_home=$ORACLE_HOME -x Listener_name=$LISTENER_NAME
# scswitch -e -j $ORACLE_SID-serv
# scswitch -e -j $ORACLE_SID-list
# scswitch -e -M -j $ORACLE_SID-serv
# scswitch -e -M -j $ORACLE_SID-list

たとえば、手順 2、手順 3、手順 4 で説明した Oracle インスタンスを使用すると、実行するコマンドは次のようになります。

# scrgadm -a -t SUNW.oracle_server -g boots-1-lh -j ora32-serv ¥ 
-x Oracle_sid=ora32 -x Oracle_home=/oracle/816_32 ¥ 
-y Thorough_probe_interval=60 ¥ 
-x Connect_cycle=10 -x Probe_timeout=120 ¥ 
-y Retry_interval=300 -x Connect_string=scott/tiger ¥ 
-x Parameter_file=/oracle/816_32/dbs/initora32.ora ¥ 
-x Alert_log_file=/oracle/816_32/admin/ora32/bdump/alert_ora32.log
# scrgadm -a -j ora32-list -t SUNW.oracle_listener -g boots-1-lh ¥
-x Oracle_home=/oracle/816_32 -x Listener_name=ORA_LIST
# scswitch -e -j ora32-serv
# scswitch -e -j ora32-list
# scswitch -e -M -j ora32-serv
# scswitch -e -M -j ora32-list

アップグレードの確認

次の手順で、アップグレードが正しく完了したことを確認します。

Oracle リソースがオンラインであることを確認するには次のコマンドを使用します。
# scstat -g
.

リソースグループの切り替えが次のコマンドで実行できることを確認します。
# scswitch -z -g resource-group -h node

マニュアルの訂正

この節では、マニュアル内で誤って記載されている情報を示します。

『Sun Cluster 3.0 Hardware Guide』

『Sun Cluster 3.0 Hardware Guide』では次の手順が誤っているか、または記載されていません。

第 7 章の「Configuring StorEdge A3500 Disk Drives」には誤りがあります。「Increase the drive capacity of a LUN」というタイトルは誤りです。LUN のドライブ容量を増やすことはできません。ただし、ドライブグループのサイズを増やすことはできます。従って、ディスクセットやディスクグループから LUN を取り外す必要はありません。この作業は「Increase the size of the drive group. Follow the same procedure used in a non-cluster environment (ドライブグループのサイズを増やします。非クラスタ環境と同様の手順に従ってください)」と読み替えてください。
Sun Cluster 3.0 AnswerBook には、Cluster Configuration Repository (CCR) に冗長ディスクパスを導入せずにディスクを再配線する手順が記載されていません。

クラスタ内部でデバイスを再配線する場合には、クラスタが新しいデバイス構成を認識するようにしなければなりません。クラスタが新しい構成を認識し、デバイスを確実に使用できるようにするには、次の手順に従います。

ディスクケーブルを新しいアダプタに移動する

次の手順で、ディスクケーブルをノード内の新しいアダプタに移動します。

関係するディスクの I/O をすべて休止します。

古いアダプタからケーブルを取り外します。

ローカルノードで cfgadm(1M) コマンドを実行し、移動に関連するすべてのドライブの構成を解除します。

または、次のコマンドでノードを再起動します。
# reboot -- -r

ローカルノードで devfsadm -C コマンドを実行し、Solaris のデバイスリンクをクリーンアップします。

ローカルノードで scdidadm -C コマンドを実行し、DID デバイスパスをクリーンアップします。

新しいアダプタにケーブルを接続します。

ローカルノードで cfgadm コマンドを実行し、ドライブを新しい場所に構成します。

または、次のコマンドでノードを再起動します。
# reboot -- -r

scgdevs コマンドを実行し、新しい DID デバイスパスを追加します。

別のノードにディスクケーブルを移動する

ディスクケーブルを、あるノードから別のノードに移動するには次の手順を使用します。

すべてのボリュームマネージャーとデータサービスの構成から、削除するパスへの参照をすべて削除します。

関連するディスクへの I/O をすべて休止します。

古いノードからケーブルを取り外します。

古いノードで cfgadm コマンドを実行し、移動に関連するすべてのドライブの構成を解除します。

または、次のコマンドでノードを再起動します。
# reboot -- -r

ローカルノードで devfsadm -C コマンドを実行し、Solaris のデバイスリンクをクリーンアップします。

ローカルノードで scdidadm -C コマンドを実行し、DID デバイスパスをクリーンアップします。

新しいノードにケーブルを接続します。

新しいノードで cfgadm コマンドを実行し、ドライブを新しい場所に構成します。

または、次のコマンドでノードを再起動します。
# reboot -- -r

新しいノードで devfsadm コマンドを実行し、新しい Solaris デバイスリンクを作成します。

新しいノードで scgdevs コマンドを実行し、新しい DID デバイスパスを追加します。

新しいノードで必要なボリューム管理ソフトウェアとデータサービスの構成に必要なパスを追加します。

データサービスを構成するときには、ノードのフェイルオーバーの設定が新しい構成を反映するように設定されていることを確認してください。

クラスタソフトウェアが正しいデバイス構成を反映するよう更新する

この手順が正しく行われていないと、次回に scdidadm -r コマンドや scgdevs コマンドを実行した時にエラーが記録されることがあります。正しいデバイス構成を反映するように、次の手順でクラスタソフトウェアを更新してください。

ケーブル構成が意図した通りであることを確認します。ケーブルが古いノードから取り外してあるかどうかを確認します。

古いノードが必要なボリューム管理ソフトウェアやデータサービスの構成から削除されていることを確認します。

古いノードで cfgadm コマンドを実行し、移動に関連するすべてのドライブの構成を解除します。

または、次のコマンドでノードを再起動します。
# reboot -- -r

ケーブルを取り外したノードで devfsadm -C コマンドを実行します。

ケーブルを取り外したノードで scdidadm -C コマンドを実行します。

新しいノードで cfgadm コマンドを実行し、ドライブを新しい場所に構成します。

または、次のコマンドでノードを再起動します。
# reboot -- -r

新しいノードで scgdevs コマンドを実行し、新しい DID デバイスパスを追加します。

新しいノードで scdidadm -R デバイス名コマンドを実行し、SCSI の予約が正しい状態にあるかどうかを確認します。

『Sun Cluster 3.0 データサービス開発ガイド』

『Sun Cluster 3.0 データサービス開発ガイド』の付録 B のサンプルコードには、次の問題があります。

コードリストの改行の多くが誤っており、特に長いコメントで顕著です。正しい改行で見るためには PDF 版のマニュアルを表示してください。
この付録のメソッドスクリプトのリストでは、ほとんどの変数の宣言が抜けています。各メソッドでは main() で次の変数が宣言されていなければなりません。
SYSLOG_TAG=$RESOURCETYPE_NAME,$RESOURCEGROUP_NAME,$RESOURCE_NAME
この変数は、logger() コマンドのコード例の全体で使用されています。

『Sun Cluster 3.0 の概念』

『Sun Cluster 3.0 の概念』では次の点に注意する必要があります。

『Sun Cluster 3.0 の概念』には、データサービスの開発者やシステム管理者が、アプリケーショントラフィックにクラスタインターコネクトを利用する方法が説明されていません。以下を参照してください。

アプリケーショントラフィックのためのクラスタインターコネクトの利用

クラスタでは、ノード間に複数のネットワーク接続が存在してクラスタインターコネクトを形成しなければなりません。クラスタリングソフトウェアは、複数のインターコネクトを高可用性とパフォーマンスの向上のために利用します。内部のトラフィックでは (たとえばファイルシステムのデータやスケーラブルサービスのデータ)、メッセージは利用可能なすべてのインターコネクトの間でラウンドロビンによりストライプ化されます。

クラスタインターコネクトは、アプリケーションからもノード間の可用性の高い通信のために利用できます。たとえば、分散アプリケーションでは、構成要素が異なるノードで実行されていて通信が必要なことがあります。パブリックインターコネクトの代わりにクラスタインターコネクトを使用することで、これらの接続は個別リンクのエラーを回避できます。

ノード間の通信にクラスタインターコネクトを使用するには、アプリケーションは、クラスタをインストールした際に構成されたプライベートホスト名を使用する必要があります。たとえば、ノード 1 のプライベートホスト名が clusternode1-priv である場合には、ノード 1 とクラスタインターコネクトで通信する際にこの名前を使用します。この名前で開いた TCP ソケットは、クラスタインターコネクトを経由して転送され、ネットワークエラーが発生した際には透過的に再転送できます。

プライベートホスト名はインストール時に構成できるため、その時にはクラスタインターコネクトに任意の名前を使用できます。実際の名前は、scha_cluster_get(3HA) に scha_privatelink_hostname_node 引数を指定することで取得できます。

アプリケーションレベルでクラスタインターコネクトを使用する場合は、各ノードのペアの間で単一のインターコネクトを使用しますが、異なるノードのペアに対しては、可能であれば独立したインターコネクトを使用します。たとえば、3 ノードで実行中のアプリケーションがあり、クラスタインターコネクトで通信しているとします。この場合、ノード 1 と 2 の間の通信には hme0 インタフェースが使用され、ノード 1 と 3 の通信には qfe1 インタフェースが使用されることになります。つまり、アプリケーションが任意の 2 ノード間で通信する場合は、単一のインターコネクトに限られますが、内部クラスタリングの通信は、すべてのインターコネクトでストライプ化されます。

アプリケーションは、インターコネクトを内部クラスタリングのトラフィックと共有しており、従って、アプリケーションが利用可能な帯域幅は、他のクラスタリングトラフィックが使用している帯域幅に依存していることに注意してください。エラーが発生した場合、内部トラフィックは残っているインターコネクトにラウンドロビンできますが、アプリケーションの接続でインターコネクトにエラーが出た場合は、稼動中のインターコネクトに切り替わります。

2 種類のアドレスがクラスタインターコネクトをサポートしており、プライベートホスト名に gethostbyname(3N) を実行すると、通常 2 つの IP アドレスを返します。最初のアドレスは論理 pairwise アドレスと呼ばれ、2 番目のアドレスは論理 pernode アドレスと呼ばれます。

各ノードのペアには、独立した論理 pairwise アドレスが割り当てられています。この小規模な論理ネットワークが、接続のフェイルオーバーをサポートしています。各ノードには固定 pernode アドレスも割り当てられています。つまり、clusternode1-priv の論理 pairwise アドレスはノードごとに異なっていますが、clusternode1-priv の論理 pernode アドレスは各ノードで同じです。しかし、ノードは pairwise アドレスを自分で持っているわけではないため、ノード 1 に gethostbyname(clusternode1-priv) を実行しても、戻るのは論理 pernode アドレスだけです。

アプリケーションが、クラスタインターコネクトによる接続を受け入れてから IP アドレスを確認する際には、セキュリティ上の理由から、gethostbyname で返される最初の IP アドレスだけではなく、すべての IP アドレスを検査する必要があることに注意してください。

アプリケーション全体にわたって一貫した IP アドレスが必要な場合は、クライアントとサーバーの両側で pernode アドレスをバインドするようにアプリケーションを構成し、すべての接続が pernode アドレスで行き来するようにしてください。

『Sun Cluster 3.0 データサービスのインストールと構成』

『Sun Cluster 3.0 データサービスのインストールと構成』の第 5 章「Sun Cluster HA for Apache のインストールと構成」では、Apache Web Server を Apache の Web サイト (http://www.apache.org) からインストールする方法について説明していますが、Apache Web Server は Solaris 8 オペレーティング環境の CD-ROM からインストールすることもできます。

Apache のバイナリは SUNWapchr、SUNWapchu、SUNWapchd という 3 つのパッケージに含まれており、SUNWCapache パッケージのメタクラスタを構成しています。SUNWapchr は、SUNWapchu より先にインストールする必要があります。

Web サーバーのバイナリは、各クラスタノードのローカルファイルシステムか、クラスタファイルシステムに置きます。

Solaris 8 CD-ROM から Apache をインストールする

この手順では、Sun Cluster HA for Apache データサービスを Solaris 8 オペレーティング環境 CD-ROM に含まれている Apathe Web Server で使用する場合に必要な手順について説明します。

Apache パッケージの SUNWapchr、SUNWapchu、SUNWapchd をインストールしていない場合は、インストールします。

パッケージがすでにインストールされているかどうかを確認するには pkginfo(1) コマンドを実行します。

# pkgadd -d Solaris_8_Product_directory SUNWapchr SUNWapchu SUNWapchd
...
Installing Apache Web Server (root) as SUNWapchr
...
[ verifying class initd ]
/etc/rc0.d/K16apache linked pathname
/etc/rc1.d/K16apache linked pathname
/etc/rc2.d/K16apache linked pathname
/etc/rc3.d/S50apache linked pathname
/etc/rcS.d/K16apache linked pathname
...

SUNWapchr パッケージの一部としてインストールした、実行開始/停止制御スクリプトを無効にします。

データサービスを構成した後は、Sun Cluster HA for Apache データサービスが Apache アプリケーションの起動と停止を行うため、このスクリプトを無効にする必要があります。次の手順を実行してください。

Apache 開始制御スクリプトのリストを表示します。

Apache 開始制御スクリプトの名前を変更します。

すべての Apache 関連のスクリプトの名前が変更されたことを確認します。

注 -

次の例では、開始制御スクリプトの名前の最初の文字を大文字から小文字に変更しています。このスクリプトの名前は、通常のシステム管理の方針に合わせて、任意の名前に変更しても構いません。

# ls -1 /etc/rc?.d/*apache
/etc/rc0.d/K16apache
/etc/rc1.d/K16apache
/etc/rc2.d/K16apache
/etc/rc3.d/S50apache
/etc/rcS.d/K16apache
# mv /etc/rc0.d/K16apache  /etc/rc0.d/k16apache
# mv /etc/rc1.d/K16apache  /etc/rc1.d/k16apache
 
# mv /etc/rc2.d/K16apache  /etc/rc2.d/k16apache
 
# mv /etc/rc3.d/S50apache  /etc/rc3.d/s50apache
 
# mv /etc/rcS.d/K16apache  /etc/rcS.d/k16apache
 
 
 
# ls -1 /etc/rc?.d/*apache
/etc/rc0.d/k16apache/etc/rc1.d/k16apache/etc/rc2.d/k16apache/etc
/rc3.d/s50apache/etc/rcS.d/k16apache

マニュアルページ

Sun Cluster 3.0 ソフトウェアと共に提供される各データサービスには、新しいマニュアルページ (英語) が含まれています。データサービスのマニュアルページには、SUNW.apache(5)、SUNW.dns(5)、SUNW.iws(5)、SUNW.nfs(5)、SUNW.nsldap(5)、SUNW.oracle_listener(5)、SUNW.oracle_server(5)、SUNW.HAStorage(5)、scalable_service(5) があります。これらのマニュアルページには、各データサービスが使用する標準および拡張プロパティが説明してあります。

Sun Management Center GUI の既知の問題

この節では、Sun Management Center GUI の Sun Cluster 3.0 モジュールの既知の問題を説明します。

特定の種類の Ultra サーバーが Sun Management Center に認識されない

現象

Sun Management Center のウィンドウに、マシンのアイコンの代わりにドメイン内のクラスタノードを示す、青または黄色のフォルダアイコンが表示される。
ノードを「Details」ウィンドウに表示したときに、「Load Modules」のメニュー項目が選択不可になる

問題点の確認

「Details」ウィンドウを閉じます

「Sun Management Center」ウィンドウで、「File」->「Console Messages」を選択します。

認識されないクラスタノードを表すフォルダアイコンをダブルクリックします。

コンソールメッセージウィンドウで「...family definition file missing for...」という行を探します。

回避方法

Sun Management Center サーバーで、ファミリファイルのあるディレクトリに移動します。
# cd /opt/SUNWsymon/classes/base/console/cfg

利用できる一番近い family-j.x ファイルへのシンボリックリンクを作成します。

たとえば、見つからないファイルの行が「...missing for sun4u-Sun-Ultra-450-family-j.x...」である場合は、sun4u-Sun-Enterprise-450-family-j.x から sun4u-Sun-Ultra-450-family-j.x へのリンクを作成します。
# ln -s sun4u-Sun-Enterprise-450-family-j.x sun4u-Sun-Ultra-450-family-j.x

コンソールを終了し、再起動します。

シンボリックリンクの名前を決定する別の方法

認識されないクラスタノードをダブルクリックして「Details」ウィンドウを表示します。

「Info」タブをクリックします。

「Properties」テーブルの「Entity Family」の項目を検索します。

値が画面からはみ出している場合は、マウスポインタをしばらく値フィールドの上に置きます。完全な名前 (たとえば sun4u-Sun-Ultra-450) が表示されます。

-family-j.x を追加することで、リンクの名前を決定できます。