以降の各節では,TruCluster Server バージョン 5.1B に関する推奨事項,注意事項,および既知の問題について説明します。
2.1 ハードウェア構成
この節では,クラスタにするハードウェアの構成に関する注意事項について説明します。
2.1.1 Memory Channel 構成は対称的でなければならない
クラスタ・インターコネクトに Memory Channel を使用するクラスタでは,クラスタの各メンバは,同じ数の Memory Channel カードを持っていなければなりません。たとえば,あるメンバを 2 つの Memory Channel カードで構成し,別のメンバを 1 つの Memory Channel カードだけで構成することはできません。Memory Channel ソフトウェアは,対称的な Memory Channel 構成を持つクラスタで動作します。Memory Channel およびサポートされる構成についての詳細は,『クラスタ概要』および『クラスタ・ハードウェア構成ガイド』を参照してください。
2.2 インストレーション
この節では,インストレーションに関する注意事項について説明します。
2.2.1 バージョン 5.1B をインストールする前に最新のファームウェアにアップデートする
Tru64 UNIX および TruCluster Server バージョン 5.1B をインストールする前に,クラスタ・メンバにするすべてのシステムを最新のファームウェアにアップデートします。古いファームウェアを実行しているクラスタ・メンバは,クラスタに接続されているハードウェアのいくつかを使用できないことがあります。たとえば,古いファームウェアでは,HSZ80 または HSG80 コントローラの後ろにブート・ディスクのあるメンバは,ブートに失敗して,「Reservation Conflict」というエラーが表示されることがあります。
システムのファームウェアをアップデートするには,次の手順に従います。
ファームウェア CD-ROM をドライブに挿入して,その CD-ROM から次のようにブートします。
>>> boot cdrom_console_device_name
ファームウェア・アップデート・ユーティリティは自動的にシステムのタイプとモデルを識別して,システムに必要な正しいファームウェア・リビジョンを判断します。
画面の指示に従ってください。READ-ME-FIRST ファイルが自動的に表示されます。このファイルでは,アップデートで行われるファームウェアの変更について説明しています。
ファームウェアのアップデートが完了したら,新しいファームウェアを初期化するために,10 秒間以上プロセッサの電源をオフにします。
ファームウェア CD-ROM にアクセスできない場合には,次の URL から最新のファームウェアを入手することができます。
ftp.digital.com/pub/DEC/Alpha/firmware/readme.html
ファームウェアおよび関連ドキュメントを anonymous FTP (File Transfer Protocol) でダウンロードすることができます。
2.3 クラスタの作成とメンバの追加
この節では,クラスタの作成とクラスタ・メンバの追加に関する注意事項について説明します。
2.3.1 クラスタ・カーネルの構築のためベースの /usr に空き容量が必要
clu_create
コマンドは,最初のクラスタ・メンバ用のカーネルをベース・システムの
/usr
に構築します。/usr
に十分な空き容量がない場合,doconfig
コマンドは失敗します。これは致命的なエラーではありません。ディスク容量に空きを作ってから
clu_create
を再実行するか,または最初のメンバのクラスタ・ブート・ディスクからクラスタ対応
genvmunix
をブートした後,そのメンバのカスタマイズ済みカーネルを構築することができます。
この問題を回避するための対処方法は,clu_create
を実行する前に,/usr
にカーネル構築のための十分な容量があることを確認することです。
2.3.2 NIS マスタおよびクラスタの作成
クラスタ作成の前に Tru64 UNIX システムが NIS マスタとして構成されている場合,clu_create
コマンドは,クラスタを NIS マスタとして構成すべきです。しかし,シングル・メンバ・クラスタがブートされると,すべての
yp
マップは,ypservers
マップが,省略時のクラスタ別名からではなく,依然としてベース・メンバのホスト名からサービスされていると期待します。この問題を修正するには,make
コマンドを実行してマップを再作成し,NIS サービスがクラスタ別名で利用可能なフェイルオーバ機構を使用できるようにします。マップを再作成するには,次の手順に従います。
ディレクトリを
/var/yp/src
に変更します。
# cd /var/yp/src
touch
コマンドを実行して,ファイルの日付を更新します。
# touch *
ディレクトリを
/var/yp
に変更します。
# cd ..
make
コマンドを実行して,データベースを再作成します。
# make
2.3.3 異なるディスクでクラスタを再作成した場合のドメインの問題
クラスタを作成する場合,clu_create
は,cluster_root
,cluster_usr
,cluster_var
,および最初のメンバのブート・ドメイン (通常は
root1_domain
) について,/etc/fdmns
内に AdvFS ドメインを作成します。これらのドメインは,元の Tru64 UNIX オペレーティング・システム上の
/etc/fdmns
ディレクトリに置かれます。
クラスタを再作成するには,Tru64 UNIX オペレーティング・システムをマルチ・ユーザ・モードにブートして,clu_create
を再実行します。これは,最初にクラスタを作成したときと同じディスクを同じクラスタ・ドメインについて使用する場合に限り,うまくいきます。しかし,異なるディスクを指定すると,clu_create
では
/etc/fdmns
から既存のドメインが削除されることが示されますが,これは行われません。たとえば,次の例を参照してください。
The following AdvFS boot domain is already configured: root1_domain dsk6a Do you want to reuse the disk associated with this AdvFS domain as the boot disk? [yes]: no The installation must remove this AdvFS domain in order to continue. Do you want to remove this domain? [yes]: yes Each member has its own boot disk, which has an associated device name; for example, 'dsk5'. Enter the device name of the member boot disk []:dsk17 Checking the member boot disk: dsk17.
.
.
.
Creating AdvFS domains: Creating AdvFS domain 'root1_domain#root' on partition '/dev/disk/dsk17a'. mkfdmn: domain '/etc/fdmns/root1_domain' already exists mkfdmn: can't create new domain 'root1_domain' *** Error *** Cannot create AdvFS domain '/dev/disk/dsk17a' on disk 'root1_domain'. *** Error *** clu_create: Failed creating AdvFS domains. *** Error *** clu_create: Failed to create a cluster.
この問題を回避するには,clu_create
コマンドを実行してクラスタを再作成する前に,同じディスクを使用しないドメインを
/etc/fdmns
から削除しておきます。たとえば,次のコマンドを使用します。
# rm -rf /etc/fdmns/root1_domain
この節では,ローリング・アップグレードに関する問題について説明します。
2.4.1 ロールされていないメンバ上での vfast ブート・エラー・メッセージ
バージョン 5.1B へのローリング・アップグレードを実行している場合に,先行メンバがロールされた後,ロールされていないメンバをブートすると,次のような文字列を含む
vfast
エラー・メッセージが表示されることがあります。
usr/sbin/vfast: /sbin/loader: Fatal Error: call to unresolved symbol \ from /usr/sbin/vfast
この問題が生じるのは,vfast
起動スクリプトが
/sbin/init.d
にインストールされているが,バージョン 5.1A で
vfast
がサポートされていないのに,リブートされたメンバが
vfast
を起動しようとするからです。起動は失敗し,エラー・メッセージは通知のためです。この問題は,バージョン 5.1B にロールされたメンバでは起こりません。
2.4.2 ローリング・アップグレード,Secure Shell,リモート・ユーティリティの保護,および完全に修飾されたドメイン名
この項の注意事項は,次のすべてが当てはまる場合にのみ関係します。
クラスタでバージョン 1.0 の Secure Shell (SSH) を実行している。
/etc/ssh2/ssh_config
構成ファイルで
EnforceSecureRutils
変数を
yes
に設定している。
クラスタについて完全に修飾されたドメイン名を使用していない。
Secure Shell のドキュメントおよび
clu_create
ではともに,完全に修飾されたドメイン名を使用するように推奨しています。このガイドラインに従っている場合,この注意事項はそのクラスタには当てはまりません。
クラスタをバージョン 5.1B にアップグレードする場合,Secure Shell サブセットは必須のサブセットであり,EnforceSecureRutils
が
yes
に設定されているときには,クラスタについて完全に修飾されたドメイン名によるホスト・ベースの認証の使用を必要とします。クラスタで完全に修飾されたドメイン名を使用しない場合,従来のリモート・ユーティリティ (rcp
および
rsh
など) は認証チェックに失敗します。
対処方法は,完全に修飾されたクラスタ・ホスト名を
/etc/hosts
,/.rhosts
(使用している場合),および
/.shosts
に追加することです。その後,完全に修飾された名前を使用して
/etc/ssh2/knownhosts
にシンボリック・リンクを作成します。たとえば,次の例では,deli
というクラスタ名を使用して,完全に修飾されたクラスタ名を使用する前後の各ファイルを表示するとともに,リンクを作成するために使用したコマンドを示します。
使用前:
/etc/hosts: 16.140.160.124 deli /.rhosts: deli /.shosts: deli
使用後:
/etc/hosts: 16.140.160.124 deli.zk3.dec.com deli /.rhosts: deli.zk3.dec.com /.shosts: deli.zk3.dec.com # ln -sf /etc/ssh2/hostkey.pub \ /etc/ssh2/knownhosts/deli.zk3.dec.com.ssh-dss.pub
2.4.3 i18n が /usr にある場合 clu_upgrade は必要なディスク容量を正しく算出しない
ワールドワイド言語サポート (WLS) サブセットは
/usr/i18n
にインストールされます。このサブセットは,/usr
の一部にすることも,別個のファイル・システムにすることもできます。WLS サブセットが別個のファイル・システムにインストールされない場合,clu_upgrade
コマンドは,setup
段階で必要なディスク容量を正しく算出しません。この計算間違いにより,setup
段階で
clu_upgrade
がタグ付きファイルを作成する際に,WLS サブセットが格納されているファイル・システムで容量不足になります。たとえば,次の例を参照してください。
# clu_upgrade setup 1 . . . Checking inventory and available disk space. Copying cluster kit 'xxx' to 'yyy' Creating tagged files. .......................................................... .......................NOTE: CFS: File system full: /usr NOTE: CFS: File system full: /usr NOTE: CFS: File system full: /usr NOTE: CFS: File system full: /usr . . . [followed by a multitude of similar error messages] *** Warning *** The above errors were detected during the cluster upgrade. If you believe that the errors are not critical to system operation, you can choose to continue. If you are unsure, you should check the cluster upgrade log and refer to clu_upgrade(8) before continuing with the upgrade. Do you want to continue the cluster upgrade? [no]:
このような状況になった場合には,次の手順に従ってください。
プロンプトに対して
no
と応答します。
clu_upgrade undo setup
コマンドを実行して,タグ付きファイルを削除し,setup
段階を取り消します。
ファイル・システムの空き容量を 『クラスタ・インストレーション・ガイド』 に示されている値まで増やします。
clu_upgrade setup
コマンドを再度実行します。
これを防止するための対応策は,clu_upgrade setup
コマンドを実行する前に,ファイル・システムに必要な量の空き領域があることを確認することです。
2.4.4 clu_upgrade undo install: /usr/.smdb./.wwinstall に関するエラー・メッセージ
ワールドワイド言語サポート (WLS) サブセットがクラスタにインストールされているときに,ローリング・アップグレードで問題が起こって
install
段階を取り消す必要がある場合には,次のメッセージが表示されます。
Restoring tagged files. .........Cannot rename /usr/.smdb./.RollTemp...wwinstall \ to /usr/.smdb./.wwinstall /usr/.smdb./.RollTemp...wwinstall is not a tagged file
.wwinstall
ディレクトリはインベントリ項目ではないため,この警告メッセージは無視してかまいません。
2.4.5 clu_upgrade undo install: /etc/.Old..ifaccess.conf に関するエラー・メッセージ
バージョン 5.1B にローリングしているとき,ローリング・アップグレードでロール段階を終えたのちに,インストール段階の取り消しに戻った場合に限り,次のようなエラー・メッセージが表示されます。
clu_rollprop: /etc/.Old..ifaccess.conf does not exist
インストール段階を取り消している場合にこのエラー・メッセージが表示された場合には,メッセージを無視してかまいません。/etc/.Old..ifaccess.conf
ファイルは存在しませんが,実際のメンバごとの/etc/ifaccess.conf
ファイルは存在しています。
2.4.6 clu_upgrade undo install で /etc/motd から WLS エントリが削除されない
ワールドワイド言語サポート (WLS) サブセットがインストールされているクラスタで,ローリング・アップグレードを取り消しているとき,Tru64 UNIX バージョン 5.1A およびバージョン 5.1B の両方について WLS エントリが
/etc/motd
ファイル内に残されます。たとえば,次のようになります。
Tru64 UNIX Catalan Support V5.1B (rev. 231) Tru64 UNIX Catalan Support V5.1A (rev. 168)
/etc/motd
ファイルを手動で編集して,Tru64 UNIX バージョン 5.1B の WLS エントリを削除してください。
2.4.7 ローリング・アップグレードおよびサポート対象外のハードウェア
バージョン 5.1B にローリング・アップグレードを行う前に,Tru64 UNIX バージョン 5.1B 『リリース・ノート』の「本リリースからサポートされないハードウェア」の項を読んで,使用しているクラスタのハードウェアが バージョン 5.1B でサポートされていることを確認してください。
2.5 ブートとシャットダウン
この節では,クラスタでのメンバのブートとクラスタ・メンバのシャットダウンを行う際の要件と制限事項について説明します。
2.5.1 KZPBA-CB SCSI バス・アダプタを使用したクラスタ内でのブート時にメンバがハングすることがある
KZPBA-CB SCSI バス・アダプタのあるクラスタのメンバをブートする場合,ブート中にメンバがハングすることがあります。そのメンバのコンソール・ログには,次のようなメッセージが表示されます。
cam_logger: SCSI event packet cam_logger: bus 10 target 15 lun 0 ss_perform_timeout timeout on disconnected request Active CCB at time of error cam_logger: SCSI event packet cam_logger: bus 10 target 15 lun 0 isp_process_abort_queue IO abort failure (mailbox status 0x0), chip reinit scheduled Active CCB at time of error cam_logger: SCSI event packet cam_logger: bus 10 isp_reinit Beginning Adapter/Chip reinitialization (0x3) cam_logger: SCSI event packet cam_logger: bus 10 isp_reinit Fatal reinit error 1: Unable to bring Qlogic chip back online
このようなメッセージが表示された場合は,システムをリセットして再度ブートする必要があります。
AlphaServer GS80,GS160,または GS320 では,SCM (システム制御マネージャ) の
halt
および
reset
を実行することができます。他のシステムでは,再度ブートする前に,ハードウェアのリセットを行う必要があります。
リセットしても問題が解決されない場合は,電源を一旦オフにしてからオンにする必要があります。AlphaServer GS80,GS160,または GS320 では,SCM の
power off
および
power on
コマンドでこれを行うことができます。
2.5.2 ブート中の CNX パニック
大規模なストレージ構成のあるクラスタ内でメンバをブートすると,そのメンバはパニック状態になって,次のようなメッセージが表示されることがあります。
CNX MGR: Invalid configuration for cluster seq disk
このような状況が起こった場合は,メンバをリブートします。
2.5.3 パニック: clubase_cfg: no cluster name in /etc/sysconfigtab
このパニックは,負荷状態でリブート中のクラスタで時々起こることがあります。これは,コンソール・ファームウェアの問題です。対処方法はありませんので,再ブートしてください。
2.5.4 パニック: cb_open: failed SCSI
このパニック ('cb_open: failed SCSI' の後にデバイス情報が続く) は,負荷状態でリブート中のクラスタで時々起こることがあります。これは,コンソール・ファームウェアの問題です。対処方法はありませんので,再度ブートしてください。
2.5.5 非投票クラスタ・メンバの対話形式でのブート
設計により,非投票メンバはクラスタを形成できません。ここでは,非投票メンバがクラスタ内で唯一の稼働可能なメンバであるときに,そのメンバをブートしてクラスタを形成する方法について説明します。次の例では,cluster_expected_votes=1
および
cluster_node_votes=1
の両方を設定して,現在のメンバシップやクォーラム・ボート構成に関わらず,メンバをブートしてクラスタを形成できるようにします。
>>> boot -fl "ia"
.
.
.
Enter kernel_name [option_1 ... option_n] Press Return to boot default kernel 'vmunix': vmunix clubase:cluster_node_votes=1 \ clubase:cluster_expected_votes=1 [Return]
ブートを再開すると,メンバはクラスタを形成できます。メンバがマルチユーザ・レベルになると,ログインし,clu_quorum
コマンドを使用して,メンバに 1 ボート与えます (対話形式のブートに使用されたボートは,メンバの
sysconfigtab
ファイルに書き込まれません)。その後,clu_quorum
を使用して,すべてのクラスタ・クォーラムの設定を調べ,必要に応じて調整します。クォーラム・ボート構成については,『クラスタ管理ガイド』を参照してください。また,『クラスタ管理ガイド』には,「メンバがブートとクラスタ形成に必要な数のボートを持っていない場合のクラスタ形成」の節があり,クラスタ・メンバをブートするときに,対話形式でクォーラム値を調整する方法について詳細に説明しています。
2.6 ファイル・システム
この節では,クラスタでの CFS,AdvFS,および NFS ファイル・システムに関する問題について説明します。
2.6.1 newfs コマンドでクォーラム・ディスクに誤って UFS ファイル・システムが作成できる
クォーラム・ディスクはユーザ・データ用に使用してはなりません。mkfdmn
コマンドは,クォーラム・ディスクに AdvFS ドメインが作成されるのを防ぎます。しかし,newfs
では,クォーラム・ディスクに誤ってファイル・システムを作成できます。newfs
を使用してクォーラム・ディスクにファイル・システムを作成しないでください。
2.6.2 メモリをロックするアプリケーションに関わる CFS 再配置の失敗
手動で再配置を行っている際に,plock()
または
mlock()
システム・コールを使用して物理メモリのページをロックするアプリケーションを実行した場合,cfsmgr
コマンドが異常終了することがあります。
アプリケーションが
plock()
を使用している場合,そのアプリケーションの実行可能ファイルを含むドメインまたはファイル・システムを再配置することはできません。mlock()
の場合は,ロックされたページがファイルに関連付けられていると,そのファイルが存在するファイル・システムを再配置することはできません。
異常終了した場合,cfsmgr
コマンドは次のメッセージを返します。
Server Relocation Failed Failure Reason: Invalid Relocation
その実行可能ファイルが存在するドメインまたはファイル・システムの再配置を完了できるようにするには,plock()
および
mlock()
システム・コールを使用している実行可能ファイルを実行しているプロセスを強制終了させます。collect
が実行されているかどうかを調べます。実行されている場合は,collect
を強制終了し,-l
(ページをメモリ内にロックしない) オプションを指定して再起動します。
2.6.3 cfsstat directio コマンドでサーバ上に表示される Fragment Writes の値が間違っている
cfsstat
コマンドでは,そのコマンドが,ファイル・システムのサービスを行っているクラスタ・メンバで実行されたか,またはファイル・システムのクライアントであるクラスタ・メンバで実行されたかにより,fragment writes
について異なる値が返されます。
fragment writes
の値は,クライアント上では正しく増えていきますが,サーバ上では間違っています。たとえば,次のようになります。
サーバでは次のようになります。
# /usr/bin/cfsstat directio Concurrent Directio Stats: 0 direct i/o reads 280 direct i/o writes 0 aio raw reads 0 aio raw writes 0 unaligned block reads 0 fragment reads 0 zero-fill (hole) reads 280 file-extending writes 0 unaligned block writes 0 hole writes 0 fragment writes 0 truncates
クライアントでは次のようになります。
# /usr/bin/cfsstat directio Concurrent Directio Stats: 1569 direct i/o reads 240 direct i/o writes 0 aio raw reads 0 aio raw writes 0 unaligned block reads 37 fragment reads 3 zero-fill (hole) reads 230 file-extending writes 0 unaligned block writes 0 hole writes 10 fragment writes 0 truncates
2.6.4 freezefs -q コマンドで AdvFS でないファイル・システムについて間違った結果が返される
AdvFS は,freezefs
コマンド操作で有効な唯一のファイル・システムのタイプです。NFS,UFS,または
/proc
など,他のタイプのファイル・システムをフリーズしようとすると,次のようなエラーになります。
ENOTSUP : Function not implemented
ユーザは,freezefs
コマンドの
-q
オプション,または
freezefs
システム・コールの
FS_QUERY
フラグを使用することにより,ファイル・システムが現在フリーズされているかどうかを知ることができます。-q
オプションは,AdvFS ファイル・システムに対して正しく作用します。しかし,freezefs -q
コマンドを使用して,AdvFS でないファイル・システムがフリーズされているかどうかを問い合わせると,エラー・メッセージが表示される代わりに,ファイル・システムがフリーズされていることを示すメッセージが誤って表示されます。
2.6.5 chfile -L on コマンドまたは mount -o adl コマンドを使用しない
クラスタでは,chfile -L on
filename
コマンドおよび
mount -o adl
file-system
コマンドを使用してはなりません。ファイルが
mmap()
システム・コールでマッピングされている場合,クラスタ環境では,ある種のデータ・ロギングの強制排他を正しく行うことができないため,システムがクラッシュすると一貫性のないデータがディスクに書き込まれることがあります。
2.7 LSM
この節では,TruCluster Server クラスタ内の LSM (Logical Storage Manager) の使用に関わる問題について説明します。
2.7.1 長いホスト名を持つクラスタでのスワップのカプセル化の問題
LSM には,ベース・ホスト名が 24 文字より長いメンバの,クラスタでのスワップのカプセル化に関する問題があります。たとえば,reallyreallyreallyverylonghostname.foo.bar.com
のような名前の場合です。
この問題を回避するには,ベース・ホスト名を 24 文字以下にします。
2.7.2 volmigrate または volunmigrate コマンドを cluster_usr ドメインについて使用する場合の注意
AdvFS の
cluster_usr
ドメインについて LSM の
volmigrate
または
volunmigrate
操作の進行中には,クラスタのどのメンバもリブートしてはなりません。
volmigrate
または
volunmigrate
操作が完了する前にノードをリブートすると,クラスタ全体がハングすることがあります。この問題は,cluster_usr
ドメインでのみ起こります。
ドメインを LSM ボリュームとの間で移行した後,クラスタもどのクラスタ・メンバもリブートする必要はありません。
2.8 CAA
この節では,CAA (Cluster Application Availability) サブシステムの問題について説明します。
2.8.1 複数の相互に依存するアプリケーションを指定した場合の caa_relocate の問題
caa_relocate -s
コマンドは,従属のあるリソースとともに使用すると,失敗します。この問題を回避するには,次の手順に従います。
caa_stat -p
コマンドを使用して,従属のあるアプリケーションを識別します。REQUIRED_RESOURCES
というエントリが表示されるアプリケーションが従属のあるアプリケーションです。
caa_relocate -f
コマンドを使用して,従属のあるアプリケーションを再配置します。
caa_relocate -s member1 -c member2
を使用して,他のアプリケーションを再配置します。
2.8.2 端末上の SysMan Menu CAA Management でナビゲーション・ボタンが表示されない
端末画面上で SysMan Menu の CAA Management ブランチを実行しているとき,画面が 24 行しかない場合には,OK,CANCEL,および HELP の選択が詳細ウィンドウに表示されないことがあります。この画面から移動するには,Ctrl/c を押します。
2.8.3 Balance データを指定しないでアプリケーション・リソースの登録をアップデートするとエラーが生じる
アプリケーション・プロファイルの Balance フィールドにデータを指定しないでアプリケーション・リソースの登録をアップデートすると (caa_register -u
resource
),次のようなエラー・メッセージが表示されます。
REBALANCE entry(ies) will be removed from clustercron Error when calling system (/var/cluster/caa/bin/caa_schedule \ UNREGISTER <application>)
このメッセージは無視してかまいません。
2.8.4 イベント・マネージャのビューアで見た場合 CAA イベントの表示が不正である
イベント・マネージャのビューアで表示される CAA イベント・メッセージが正しく表示されません。あるいは,情報が欠落しているメッセージが表示されます。
CAA named is transitioning from state ONLINE to state OFFLINE on skiing
たとえば,上記のメッセージが次のように表示されます。
CAA named is transitioning from state to state skiing
この問題の対処方法は,daemon.log
ファイル内で各メッセージを調べて,もっと完全な情報があるかどうかを確認するようにします。daemon
ログ・ファイル内のメッセージは,イベント・マネージャのビューアで表示されるものとは形式が少し異なっています。
2.8.5 SysMan Station による UNKNOWN 状態の CAA アプリケーション・リソースのエラー表示
SysMan Station は,UNKNOWN
状態にあるアプリケーション・リソースをエラーとして表示し,そのアプリケーションがどのメンバ上で
UNKNOWN
であるかは表示しません。たとえば,UNKNOWN
状態の
xyz
という名前のアプリケーション・リソースは,クラスタ・アイコンの下に
xyz (error)
と表示されます。
2.9 クラスタ別名
この節では,クラスタ別名サブシステムの問題について説明します。
2.9.1 クラスタ別名では SSH 要求を均等に分散しないように見える
クラスタ別名にアドレス指定した着信接続要求は,別名の各メンバに割り当てられた選択の重み (selw
) に従って,その別名のメンバ間で分散されます。省略時のクラスタ別名は,selw
として 3 を持ちます。ただし,Secure Shell (SSH) は,1 つの接続を確立するために 2 つの接続を使用するため,SSH を使用する省略時のクラスタ別名への接続要求は,いくつかのシステムでは 2 つの接続を取得し,別のシステムでは 1 つの接続を取得するように分散されます。実際の分散の不均衡はありません。接続要求は,クラスタ・メンバに割り当てられた選択の重みに従って分散されています。
『クラスタ概要』のクラスタ別名に関する章では,着信 TCP 接続要求と UDP パケットが,クラスタ別名のメンバ間で分散される方法について説明しています。
2.10 管理についてのその他の注意事項
この節では,クラスタ内で使用する各種の管理ツールに関わる問題点について説明します。
2.10.1 クラスタが RIS サーバの場合の RIS のブートの失敗
clu_create
コマンドを実行する前に,最初のクラスタ・メンバになったシステムを RIS サーバとして構成すると,クラスタ作成プロセスは,/etc/bootptab
の
sa
エントリを更新しません。
sa
エントリはスタンドアロン・システムの IP アドレスのままです。このため,クラスタ作成後に RIS をブートしようとすると,ルート・ファイル・システムのマウントに失敗します。
/etc/bootptab
を手動で編集して,sa
エントリを省略時のクラスタ別名の IP アドレスに更新する必要があります。
2.10.2 SCSI デバイスに対するクラスタ単位の名前の作成時に hwmgr -show comp コマンドで矛盾するエラーが報告される
hwmgr -edit scsi
コマンドを使用し,SCSI デバイスに対してクラスタ単位の一意な名前を作成したのち,続いて
hwmgr -show comp
コマンドを実行すると,SCSI デバイスについて矛盾するエラーが報告されることがあります。2 番目のメンバで
hwmgr -edit scsi
コマンドを実行し,同じデバイスに対して次のメンバで実行する場合,その矛盾が現れます。この状況では,矛盾するエラーを無視してかまいません。
たとえば,次のようになります。
root> hwmgr -show comp -id 373 -full HWID: HOSTNAME FLAGS SERVICE COMPONENT NAME -------------------------------------------------------------------- 373: rovel-qa1 rcd-i iomap SCSI-WWID:ff10000b:"media_chngr" DSF GROUP INSTANCE GRPFLAGS GROUPID SUBSYSTEM BASENAME L1 L2 -------------------------------------------------------------------- 0 40 81 cam_changer mc2 media_changer generic DEVICE NODE ID LBdevT LCdevT CBdevT CCdevT BFlags CFlags Class Suffix L3B L3 ----------------------------------------------------------------------------- 0 0 56008c0 0 13003b3 0x0 0x861 0x0 (null) (null) (null) COMPONENT INCONSISTENCY ----------------------- Component should not have an entry in the cluster database but it does.
2.10.3 大規模クラスタ上でのプロセス課金機能によるメンバ・プロセス・クォータの消費
大規模クラスタ (6〜8 メンバ) でプロセス課金機能が有効である場合,クラスタ・メンバが過度のスワッピングを開始し,最終的にそのプロセス・クォータを消費し尽くすことがあります。
このようなメンバ上で
ps
コマンドを実行すると,何万もの
icssvr_daemon_from_pool
プロセスが存在することが示されます。
プロセス課金機能を現在実行しているクラスタでこの状況が進行していることがわかった場合は,accton
コマンドをパラメータなしで使用して課金機能を無効にします。
2.10.4 ファイルを手動で編集した場合はファイルを改行文字で終了する
いくつかのクラスタ・コマンドでは,1 エントリにつき 1 行を使用する形式の既存のシステム管理ファイルに対して,情報を追加します。このタイプのファイルの最後に手動でエントリを追加したときに,改行文字を追加しなかった場合,コマンドによる追加では,新しい行の新しいエントリとして追加されるのではなく,現在のエントリに連結されます。
たとえば,/.rhosts
ファイルの最後にエントリsomehostname root
を追加しましたが,改行文字を入力しなかったとします。その後,clu_create
を実行すると,新しいクラスタの名前 (この例では,deli.zk3.dec.com
) が,ファイルに追加されます。この結果,エントリは次のようになります。
somehostname rootdeli.zk3.dec.com
このため,1 行につき 1 エントリの形式のファイルを手動で編集する場合には,ファイルの最後の文字が改行文字であることを確認してください。
2.10.5 バックアップを必要とするクラスタ・ハードウェア操作
TruCluster Server システムでは,クラスタ単位およびメンバ固有のハードウェア・データベースを保守しています。データベースは,クラスタ・ルート・ファイル・システムとメンバ・ブート・ディスクとの間で同期がとられ,不一致が生じた場合には,最新のソースとして,クラスタ・ルート上で保守されているデータベースと同期がとられます。
特定のハードウェア操作でハードウェア・データベースにエントリが生成されます。これらの操作を 1 つ以上実行した後には,クラスタ・ルート・ファイル・システムおよびメンバ・ブート・パーティションのバックアップをとって,クラスタのハードウェア状態が正しく反映されるようにする必要があります。
クラスタ・ルート・ファイル・システムがのちに破損したり,ハードウェア障害のために利用不能になったりして,それをバックアップからリストアしなければならない場合,これは特に重要になります。バックアップは,障害が発生したときに,クラスタ・ルート・ファイル・システムで認識されていたディスク・ストレージ環境を反映していなければなりません。クラスタ・ルート・ファイル・システムのバックアップが現在のディスク・ストレージ環境を反映していない場合,『クラスタ管理ガイド』で説明されているクラスタ・リカバリ・プロシージャを実行するとパニックが起こり,clu_create
コマンドでクラスタを再作成しなければならなくなります。
次のいずれかの操作を実行する場合には,クラスタ・ルート・ファイル・システムおよびメンバ・ブート・パーティションのバックアップをとってください。
hwmgr -delete
コマンドで構成要素を削除する。
hwmgr -refresh comp
コマンドで構成要素データベースを復元する。
hwmgr -redirect scsi
コマンドで SCSI デバイスをリダイレクトする。
メンバのブート・ディスクのバックアップをとったり,その修復を行ったりする方法の詳細については,『クラスタ管理ガイド』を参照してください。
2.10.6 クラスタ・メンバの IP ルータとしての構成
この項では,『クラスタ管理ガイド』の「IP ルータの実行」の節の情報を補足します。
クラスタ・メンバを IP ルータとして構成する場合には,gated
を使用します。ただし,gated
デーモンは
aliasd
の制御下に置くことはできません。aliasd
の制御下に置いた場合,aliasd
は
gated
をオン/オフして,gated
が,ユーザのカスタマイズした
/etc/gated
ファイルではなく,aliasd
によって生成された
/etc/gated.conf.membern
構成ファイルをポイントするようにします。cluamgr
コマンドの
nogated
オプションを使用する方法と,CLUAMGR_ROUTE_ARGS=nogated
をそのメンバの
/etc/rc.config
ファイルに設定する方法については,『クラスタ管理ガイド』に説明があります。
経験を積んだネットワーク管理者でなければ,クラスタ・メンバを汎用 IP ルータとして構成しないことをお奨めします。
IP ルータとなるクラスタ・メンバ上では
routed
や静的ルーティングを使用しないことをお奨めします。
2.11 プログラミング
この節では,クラスタ対応アプリケーション・プログラミング・インタフェース (API) の問題について説明します。
2.11.1 MC API アプリケーションは仮想ハブを使用するクラスタでループバック・モードを有効にして 8 KB より大きな転送を使用しない
この注意事項は,次のすべてがあてはまる場合にだけ関係します。
クラスタで Memory Channel クラスタ・インターコネクトを使用している。
クラスタに仮想ハブがある。
アプリケーションで Memory Channel アプリケーション・プログラミング・インタフェース (MC API) を使用して,ループバック・モードが (IMC_LOOPBACK
フラグを指定して MC API
imc_asattach()
関数を呼び出して) 有効にされている。
この状況では,MC API を使用するアプリケーションが Memory Channel 転送のサイズを最大 8 KB ブロックに制限していることを確認してください。これより大きなブロック・サイズが指定されている場合は,クラスタ・メンバがハングすることがあるので,回復するには,電源を落としてリブートしなければなりません。
次の関数
imc_bcopy_safe()
では, Memory Channel を経由して 8 KB 以下のブロックでデータをコピーし,メンバ間で一種のフロー制御を実現することにより,この問題を回避しています。アプリケーションは,MC API の
imc_bcopy()
関数を呼び出す代わりに,imc_bcopy_safe()
関数を呼び出すことができます。次の例をそのまま使用することも,あるいは,コーディングのガイドラインとして使用することもできます。
/* * This function is a workaround to a HW problem when MC VHUBs * are used on certain platforms. * * Problem: If too much data is sent over MC on a page that * is set up for LOOPBACK, the remote node may * get stuck on the PCI bus, because of an * MC adapter buffer overflow problem combined * with a PCI interface chip problem. * * Solution: Only copy 8KB of data at a time over MC. In * between these calls, use the function imc_ckerrcnt_mr() * to provide a sort of flow control to the other node. * * Usage: Use this function instead of direct calls to * imc_bcopy(). * * Note: The use of this function has some * performance implications for large amounts of data. */ #include <stdio.h> #include <unistd.h> #include <sys/imc.h> long imc_bcopy_safe( void *, void *, long , long , long ); #define MCCOPY_SIZE (8*1024) /* Max copy size to avoid system hangs! */ #define LOGICAL_RAIL 0 long imc_bcopy_safe( void *src, void *dest, long length, long dest_write_only, long first_dest_quad) { char *source; char *tx_addr; long size, sz, last_quad; int prev_err, status; for(source = src, tx_addr = dest, size = length; size > 0; ) { /* Set sized in one call copied to <= 8KB */ sz = MIN(MCCOPY_SIZE,size); /* * Use the error check routine imc_ckerrcnt_mr() to provide * some flow control to the remote adapter through HW ACKs. * Handle MC errors. */ do { prev_err = imc_rderrcnt_mr(LOGICAL_RAIL); last_quad = imc_bcopy(source,tx_addr, sz, dest_write_only, first_dest_quad); } while ((status = imc_ckerrcnt_mr(&prev_err,0)) != IMC_SUCCESS); source += sz; tx_addr += sz; size -= sz; } while (size); return(last_quad); }
Memory Channel API およびループバック・モードについての詳細は,『クラスタ高可用性アプリケーション・ガイド』 および
imc_asattach
(3)imc_bcopy()
関数についての詳細は,
imc_bcopy
(3)2.11.2 clu_get_info() の失敗時の小規模なメモリ・リーク
clu_get_info()
関数は
clu_info_resp
構造体のためにメモリを割り当てます。ほとんどのエラーの場合,関数は,戻る前に構造体を解放します。ただし,クラスタ・メンバでないシステムで呼ばれた場合,clu_get_info()
は,clu_info_resp
構造体を解放する前に戻ります。clu_get_info()
の呼び出しをループするプログラムがなければ,この問題に気づくことはありません。
対処方法は,clu_get_info()
を使用して,システムがクラスタ・メンバかどうかをテストするのを避けることです。次の例は,1 つの方法を示しています。
# include <sys/param.h> # include <sys/sysconfig.h> # include <stdio.h> int get_cluInfo () { cfg_attr_t one_attribute[1]; strcpy (one_attribute[0].name, "clu_configured"); if (cfg_subsys_query (NULL, "generic", one_attribute, 1) == CFG_SUCCESS) if ((one_attribute[0].status == CFG_ATTR_SUCCESS) && (one_attribute[0].attr.num.val != 0)) return (TRUE); return (FALSE); } main () { int i = 0; char host[MAXHOSTNAMELEN]; if (!(gethostname (host, MAXHOSTNAMELEN))) { if (get_cluInfo ()) { printf ("System %s is a cluster member\n", host); } else { printf ("System %s is a _not_ a cluster member\n", host); } } else { printf ("Cannot determine host name\n"); exit (1); } exit (0); }
この節では,クラスタ内で SysMan Menu を使用するときに発生する可能性のある問題について説明します。
2.12.1 ホーム・ディレクトリのない非 root ユーザはシステム管理アプリケーションを実行できない
構成変更を行う場合,システム管理アプリケーションは通常
root
特権を必要とします。現在の構成を参照する場合にかぎり,非 root ユーザはシステム管理アプリケーションを実行することができますが,構成を変更することはできません。
クラスタ内では,システム管理アプリケーションは,リモート・シェル・コマンド (rsh
) を使用して,リモート・ホストのコマンドを実行します。rsh
コマンド処理の一部には,ホーム・ディレクトリにあるリモート・ユーザの
$HOME/.rhosts
ファイルによるアクセスを確認する機能が含まれています。このため,ホーム・ディレクトリを持たない非 root ユーザがシステム管理アプリケーションを実行中に,コア・ダンプが発生することがあります。これらの問題を回避するには,システム管理アプリケーションを使用する前に,ホーム・ディレクトリを必ず設定しておくようにします。
2.13 SysMan Station
この節では,クラスタ内で SysMan Station を使用しているときに発生する可能性のある問題について説明します。
2.13.1 SysMan Station で間違ったクラスタ状態が表示されることがある
SysMan Station は,イベント・マネージャ・サブシステムがクラスタ状態の監視と表示のために生成するイベントに依存しています。次の場合,SysMan Station はシステム状態を正しく反映しないことがあります。
クラスタ・メンバのブート後,ネットワーク・エラーが存在しない場合でも Monitor ウィンドウ上の Network ライトが警告状態 (黄色) を示すことがあります。この状態は,ブート・シーケンス中に生成されるネットワーク・イベントによって発生します。この警告を解除するには,次の手順に従います。
Monitor ウィンドウの Network ライトをクリックして Network Event ウィンドウを表示します。
Clear Events ボタンをクリックします。
CAA (Cluster Application Availability) デーモン (caad
) がクラスタ・メンバ上での起動に失敗した場合,SysMan Station は CAA オブジェクトの状態を正しく表示しません。たとえば,すべてのクラスタ・メンバ上に TruCluster Server のライセンスが登録されていないときに,この状況が発生することがあります。SysMan Station から CAA アプリケーションに関して正確な情報を得るには,次の手順に従います。
次のコマンドを使用して,影響を受けるクラスタ・メンバ上で
caad
デーモンを起動します。
# /usr/sbin/caad
次のコマンドを使用して,smsd
デーモンを再起動します。
# /sbin/init.d/smsd restart
2.13.2 SysMan Station で新規ハードウェア・オブジェクトが間違って表示されることがある
新規ディスク・デバイスを増設した場合,あるいは稼働中のクラスタ内で既存のデバイスを交換した場合,SysMan Station の Hardware View に新規ディスク・オブジェクトまたは変更後のディスク・オブジェクトが間違って表示されることがあります。ディスク・オブジェクトがハードウェア階層内の間違った位置に,たとえば SCSI バスの子オブジェクトとしてではなく,ホスト・オブジェクトの子オブジェクトとして,表示されることがあります。
表示を修正するには,影響を受けるすべてのメンバ上で次の手順を実行し,各クラスタ・メンバ上で SysMan Station デーモン (smsd
) を再起動します。
オープンしているすべての SysMan Station セッションをクローズします。
次のコマンドを実行します。
# /sbin/init.d/smsd restart
2.13.3 選択したオブジェクトのプロパティが表示されない
選択したオブジェクトのプロパティが表示されないことがあります。Properties
ダイアログ・ボックスが画面上に短時間だけ表示されたり,あるいはまったく表示されないことがあります。
この問題に対処するには,現在の SysMan Station クライアントにプロパティを繰り返し表示するか,SysMan Station クライアントを終了して新規セッションを開始します。
2.13.4 一部の SysMan Station アプリケーションで間違ったターゲット・メンバ名が表示される
SysMan Station から次の各アプリケーションを起動した場合,そのタイトル・バーにはアプリケーションのアクションのターゲットであるクラスタ・メンバではなく,間違って SysMan Station クライアントを実行しているクラスタ・メンバのメンバ名が表示されます。
Security Auditing Configuration
Network Configuration Applications
NFS Configuration Applications
NTP Configuration Applications
PPP Configuration Applications
タイトル・バー上の名前が間違っているだけで,アプリケーションは正しいクラスタ・メンバ上で実行されます。
2.13.5 クラスタ・メンバがパニックになった場合は全クラスタ・メンバ上で smsd の再起動が必要
クラスタ上のいずれかのノードでシステム・パニックが起こった場合には,そのクラスタ内のすべての SysMan Station デーモン
smsd
を再起動し,SysMan Station Filesystem の表示が一貫性があって正しいものであることを確認してください。
クラスタで SysMan Station
デーモンを停止して再起動する方法についての詳細は,
smsd
(8)2.14 マニュアル
この節では,TruCluster Server バージョン 5.1B のマニュアルについて説明します。
2.14.1 バージョン 5.1B では『クラスタ LAN インターコネクト』は提供されない
バージョン 5.1A で提供されていた『クラスタ LAN インターコネクト』は,バージョン 5.1B では提供されません。このマニュアルの情報は,更新されて,バージョン 5.1B のクラスタ・ドキュメント・セットの残りのマニュアルに分散されています。