2    推奨事項,注意事項,および既知の問題

以降の各節では,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」というエラーが表示されることがあります。

システムのファームウェアをアップデートするには,次の手順に従います。

  1. ファームウェア CD-ROM をドライブに挿入して,その CD-ROM から次のようにブートします。

    >>> boot cdrom_console_device_name
     
    

    ファームウェア・アップデート・ユーティリティは自動的にシステムのタイプとモデルを識別して,システムに必要な正しいファームウェア・リビジョンを判断します。

  2. 画面の指示に従ってください。READ-ME-FIRST ファイルが自動的に表示されます。このファイルでは,アップデートで行われるファームウェアの変更について説明しています。

  3. ファームウェアのアップデートが完了したら,新しいファームウェアを初期化するために,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 サービスがクラスタ別名で利用可能なフェイルオーバ機構を使用できるようにします。マップを再作成するには,次の手順に従います。

  1. ディレクトリを /var/yp/src に変更します。

    cd /var/yp/src
     
    

  2. touch コマンドを実行して,ファイルの日付を更新します。

    touch *
     
    

  3. ディレクトリを /var/yp に変更します。

    cd ..
     
    

  4. make コマンドを実行して,データベースを再作成します。

    make
     
    

2.3.3    異なるディスクでクラスタを再作成した場合のドメインの問題

クラスタを作成する場合,clu_create は,cluster_rootcluster_usrcluster_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    ローリング・アップグレード

この節では,ローリング・アップグレードに関する問題について説明します。

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,リモート・ユーティリティの保護,および完全に修飾されたドメイン名

この項の注意事項は,次のすべてが当てはまる場合にのみ関係します。

クラスタをバージョン 5.1B にアップグレードする場合,Secure Shell サブセットは必須のサブセットであり,EnforceSecureRutilsyes に設定されているときには,クラスタについて完全に修飾されたドメイン名によるホスト・ベースの認証の使用を必要とします。クラスタで完全に修飾されたドメイン名を使用しない場合,従来のリモート・ユーティリティ (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]:
 

このような状況になった場合には,次の手順に従ってください。

  1. プロンプトに対して no と応答します。

  2. clu_upgrade undo setup コマンドを実行して,タグ付きファイルを削除し,setup 段階を取り消します。

  3. ファイル・システムの空き容量を 『クラスタ・インストレーション・ガイド』 に示されている値まで増やします。

  4. 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 コマンドは,従属のあるリソースとともに使用すると,失敗します。この問題を回避するには,次の手順に従います。

  1. caa_stat -p コマンドを使用して,従属のあるアプリケーションを識別します。REQUIRED_RESOURCES というエントリが表示されるアプリケーションが従属のあるアプリケーションです。

  2. caa_relocate -f コマンドを使用して,従属のあるアプリケーションを再配置します。

  3. 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/bootptabsa エントリを更新しません。 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 コマンドでクラスタを再作成しなければならなくなります。

次のいずれかの操作を実行する場合には,クラスタ・ルート・ファイル・システムおよびメンバ・ブート・パーティションのバックアップをとってください。

メンバのブート・ディスクのバックアップをとったり,その修復を行ったりする方法の詳細については,『クラスタ管理ガイド』を参照してください。

2.10.6    クラスタ・メンバの IP ルータとしての構成

この項では,『クラスタ管理ガイド』の「IP ルータの実行」の節の情報を補足します。

クラスタ・メンバを IP ルータとして構成する場合には,gated を使用します。ただし,gated デーモンは aliasd の制御下に置くことはできません。aliasd の制御下に置いた場合,aliasdgated をオン/オフして,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 より大きな転送を使用しない

この注意事項は,次のすべてがあてはまる場合にだけ関係します。

この状況では,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);
}
 

2.12    SysMan Menu

この節では,クラスタ内で 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 はシステム状態を正しく反映しないことがあります。

2.13.2    SysMan Station で新規ハードウェア・オブジェクトが間違って表示されることがある

新規ディスク・デバイスを増設した場合,あるいは稼働中のクラスタ内で既存のデバイスを交換した場合,SysMan Station の Hardware View に新規ディスク・オブジェクトまたは変更後のディスク・オブジェクトが間違って表示されることがあります。ディスク・オブジェクトがハードウェア階層内の間違った位置に,たとえば SCSI バスの子オブジェクトとしてではなく,ホスト・オブジェクトの子オブジェクトとして,表示されることがあります。

表示を修正するには,影響を受けるすべてのメンバ上で次の手順を実行し,各クラスタ・メンバ上で SysMan Station デーモン (smsd) を再起動します。

  1. オープンしているすべての SysMan Station セッションをクローズします。

  2. 次のコマンドを実行します。

    # /sbin/init.d/smsd restart
     
    

2.13.3    選択したオブジェクトのプロパティが表示されない

選択したオブジェクトのプロパティが表示されないことがあります。Properties ダイアログ・ボックスが画面上に短時間だけ表示されたり,あるいはまったく表示されないことがあります。

この問題に対処するには,現在の SysMan Station クライアントにプロパティを繰り返し表示するか,SysMan Station クライアントを終了して新規セッションを開始します。

2.13.4    一部の SysMan Station アプリケーションで間違ったターゲット・メンバ名が表示される

SysMan Station から次の各アプリケーションを起動した場合,そのタイトル・バーにはアプリケーションのアクションのターゲットであるクラスタ・メンバではなく,間違って SysMan Station クライアントを実行しているクラスタ・メンバのメンバ名が表示されます。

タイトル・バー上の名前が間違っているだけで,アプリケーションは正しいクラスタ・メンバ上で実行されます。

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 のクラスタ・ドキュメント・セットの残りのマニュアルに分散されています。