11    クラスタのトラブルシューティング

この章では次の項目について説明します。

11.1    問題の解決

ここでは,クラスタの日常の運用時に生じるおそれのある問題の解決策について説明します。

11.1.1    ライセンスなしのシステムのブート

TruCluster Server ライセンスのないシステムをブートできます。このシステムはクラスタに参加し,マルチユーザ・モードでブートしますが,root のみ (最大 2 ユーザ) がログインできます。CAA (Cluster Application Availability) デーモン caad は起動されません。システムから,ライセンスの登録を通知するライセンス・エラー・メッセージが表示されます。このような方法でライセンス・チェックが実施され,緊急時のシステムに対するブート,ライセンス設定,および修復を行うことができるようになります。

11.1.2    メンバが動作したままになるシャットダウン

クラスタ・シャットダウン (shutdown -c) で 1 つ以上のメンバが動作したままになる場合があります。このような場合は,すべてのメンバをシャットダウンしてクラスタ・シャットダウンを完了しなければなりません。

各メンバに対するボートが 1 でクォーラム・ディスクなしの 3 メンバ・クラスタが構成されているとします。クラスタ・シャットダウンの間に,最後から 2 番目のメンバが停止すると,クォーラムを喪失します。クォーラム・チェックが有効になっている場合は,動作中の最後のメンバは処理がすべて中断され,クラスタ・シャットダウンが完了しません。

このような状況での手詰まりを回避するために,クラスタ・シャットダウン・プロセスの起動時にクォーラム・チェックが無効にされます。クラスタ・シャットダウンの間にメンバがシャットダウンできなかった場合,そのメンバは正常に機能しているクラスタ・メンバのように見えますが,そうではありません。この理由は,クォーラム・チェックが無効になっているためです。したがって,手動でシャットダウン・プロセスを完了しなければなりません。

このシャットダウン手順は,引き続き稼働しているシステムの状態によって次のように異なります。

11.1.3    環境のモニタリングとクラスタのシャットダウン

envconfig コマンド ( envconfig(8) を参照) には,ENVMON_SHUTDOWN_SCRIPT 変数が含まれています。この変数には,シャットダウンする状況になったとき,envmond デーモンを実行するユーザ定義スクリプトへのパスを指定します。クラスタでこのスクリプトを使う場合,スクリプトを実行した後,クラスタがクォーラムを失わないようにする必要があります。作成する ENVMON_SHUTDOWN_SCRIPT スクリプトでは,シャットダウンするとメンバがクォーラムを失うことになるかどうかを確実に調べる必要があります。クォーラムを失う場合には,残りのクラスタ・メンバをシャットダウンします。

たとえば,5 つのメンバで構成されるクラスタがあるとします。また,すべてのクラスタ・メンバが同じコンピュータ室に配置されていて,空調設備が故障したとします。気温がシステムの許容限度を超えた場合,クラスタ・メンバはそれぞれで気温が高すぎることを感知し,ENVMON_SHUTDOWN_SCRIPT スクリプトを呼び出します。3 番目のメンバがクラスタを離脱したときに,クラスタはクォーラムを失い (クォーラム・ボート = (クラスタ期待ボート + 2) / 2 (小数点以下切捨て)),2 つの残りのメンバがすべての処理を停止します。その結果として,これらの残りのメンバが過熱した研究室の中で稼働し続けます。

クラスタ・メンバの喪失がクォーラムの喪失の原因になる場合,残りのクラスタ・メンバをシャットダウンします。

ENVMON_SHUTDOWN_SCRIPT スクリプトはすべてのケースで shutdown -c を使用してシャットダウンを実行できますが,この方法は推奨できません。

次のサンプル・スクリプトは,現在のメンバをシャットダウンすると,クォーラムを失うことになるかどうかを判定します。

#!/usr/bin/ksh -p
#
  typeset currentVotes=0
  typeset quorumVotes=0
  typeset nodeVotes=0
 
  clu_get_info -q
  is_cluster=$?
 
        if [ "$is_cluster" = 0 ]  
        then
 
              # The following code checks whether it is safe to shut down
              # another member. It is considered safe if
              # the cluster would not lose quorum if a member shuts down.
              # If it's not safe, shut down the entire cluster.
 
              currentVotes=$(sysconfig -q cnx current_votes | \
               sed -n 's/current_votes.* //p')
 
              quorumVotes=$(sysconfig -q cnx quorum_votes | \
               sed -n 's/quorum_votes.* //p') 
 
              nodeVotes=$(sysconfig -q cnx node_votes | \
               sed -n 's/node_votes.* //p')  
 
           # Determine if this node is a voting member
 
           if  [ "$nodeVotes" -gt 0 ] 
           then              
 
               # It's a voting member, see if we'll lose quorum.
 
               if  [[ $((currentVotes-1)) -ge  ${quorumVotes} ]]
               then
                    echo "shutdown -h now..."
                    else 
                    echo "shutdown -c now..."  
               fi
           else
               echo "This member has no vote...shutdown -h now..."
           fi
 
        else
                # not in a cluster...nothing to do
                exit 0
        fi 
 

11.1.4    ブート時の CFS エラーの処理

システムのブート時にクラスタ単位のルート (/) が初めてマウントされると,CFS で次の警告メッセージが生成される場合があります。

"WARNING:cfs_read_advfs_quorum_data: cnx_disk_read failed with error-number
 

通常は,error-numberEIO の値です。

このメッセージには,次のメッセージが伴います。

"WARNING: Magic number on ADVFS portion of CNX partition on quorum disk \
is not valid"
 

これらのメッセージは,ブート・メンバによる,クォーラム・ディスクの CNX パーティションのデータへのアクセスで問題が生じていることを示しています。メッセージには,cluster_root ドメインのデバイス情報も含まれています。メッセージが表示されるのは,ブート・メンバがクォーラム・ディスクにアクセスできない場合で,その理由はクラスタが意図的にこのように構成されているか,またはパスの障害のどちらかです。前者の理由の場合,メッセージを情報とみなすことができます。後者の理由の場合は,パスの障害の原因に対して処置を講ずる必要があります。

メッセージは,クォーラム・ディスク自体に問題があることを示す場合があります。クォーラム・ディスクのハードウェア・エラーもレポートされている場合は,そのディスクを交換してください。クォーラム・ディスクの交換については,4.5.1 項を参照してください。

エラー番号については, errno(5) を参照してください。 EIO については, errno(2) を参照してください。

11.1.5    メンバのブート・ディスクのバックアップと修復

メンバのブート・ディスクには,3 つのパーティションがあります。 表 11-1 は,このパーティションの詳細を示しています。

注意

メンバのブート・パーティションにファイルセットを追加することは禁止しませんが,推奨しません。メンバがクラスタを離脱する場合,メンバのブート・パーティションからマウントされたすべてのファイルセットは,強制的にアンマウントされ,再配置することはできません。

表 11-1:  メンバ・ブート・ディスク・パーティション

パーティション 内容
a AdvFS (Advanced File System) ブート・パーティション,メンバ・ルート・ファイル・システム
b スワップ・パーティション (ah のパーティションの間の全領域)
h

CNX バイナリ・パーティション

AdvFS と LSM (Logical Storage Manager) では,それぞれが機能するために重要な情報が h パーティションに格納される。この情報には,ディスクがメンバかクォーラム・ディスクかを表す情報,およびクラスタのルート・ファイル・システムが配置されているデバイスの名前が含まれている。

メンバのブート・ディスクが破損している場合や利用できなくなった場合は,クラスタにメンバをリストアするために h パーティションの情報が必要です。clu_bdmgr コマンドを使用すれば,メンバ・ブート・ディスクを構成して,メンバ・ブート・ディスクに関するデータの保存やリストアを行うことができます。

clu_bdmgr コマンドを使用して,次の作業を行うことができます。

このコマンドの詳細は, clu_bdmgr(8) を参照してください。

メンバがブートするときは必ず,clu_bdmgr により,そのメンバのブート・ディスクの h パーティションのコピーが自動的に保存されます。データは,/cluster/members/memberID/boot_partition/etc/clu_bdmgr.conf に保存されます。

一般に,すべてのメンバ・ブート・ディスクの h パーティションには,同じデータが格納されます。ただし,次の 2 つの場合は除きます。

メンバのブート・ディスクが破損している場合は,clu_bdmgr を使用すれば,そのディスクの修復や交換が可能です。クラスタが稼働していない場合でも,少なくとも 1 つのクラスタ・メンバ上のクラスタ化されたカーネルをブートできる間は,clu_bdmgr コマンドを使用できます。

クラスタに新しいディスクを追加する方法については,9.2.3 項を参照してください。

メンバのブート・ディスクを修復するには,最初にブート・パーティションをバックアップしなければなりません。その 1 つの方法は,各メンバのブート・パーティションのダンプ・イメージ用のディスク・スペースを,共用 /var ファイル・システムに割り当てることです。

member3 のブート・パーティションのダンプ・イメージをメンバ固有のファイル /var/cluster/members/member3/boot_part_vdump に保存するには,次のコマンドを入力します。

# vdump -0Df /var/cluster/members/member3/boot_part_vdump \
/cluster/members/member3/boot_partition

11.1.5.1    メンバのブート・ディスクの修復例

次の手順は,vdump で保存されたファイルを使用してブート・ディスクを交換する方法を示しています。この手順では,次のような仮定をします。

注意

メンバのブート・ディスクは,常にクラスタ・メンバすべてによって共用されるバスに接続する必要があります。このように配置すれば,少なくとも 1 つのクラスタ・メンバをブートできる間は,どのメンバのブート・ディスクでも修復できます。

  1. clu_get_info を使用して,member3 が停止しているかどうかを判断します。

    # clu_get_info -m 3
     
    Cluster memberid = 3
    Hostname = member3.zk3.dec.com
    Cluster interconnect IP name = member3-mc0
    Member state = DOWN
    

  2. 新しいディスク (この例では dsk5) を member3 の交換ブート・ディスクとして選択します。member3 のブート・ディスクは dsk3 なので,dsk5member3 の新しいディスクとして使用されるように,member3/etc/sysconfigtab を編集する必要があります。

    dsk5member3 のブート・ディスクとして構成するには,次のコマンドを入力します。

    # /usr/sbin/clu_bdmgr  -c  dsk5 3
     
    The new member's disk, dsk5, is not the same name as the original disk
    configured for domain root3_domain.  If you continue the following
    changes will be required in member3's/etc/sysconfigtab file:
            vm:
            swapdevice=/dev/disk/dsk5b
            clubase:
            cluster_seqdisk_major=19
            cluster_seqdisk_minor=175
     
    

  3. member3 のルート・ドメイン (新しい dsk5 上) をマウントし,member3/etc/sysconfigtab を編集して,ブート・パーティションをリストアします。

    # mount root3_domain#root /mnt
     
    

  4. ブート・パーティションをリストアします。

    # vrestore -xf /var/cluster/members/member3/boot_part_vdump -D /mnt
    

  5. member3/etc/sysconfigtab を編集します。

    # cd /mnt/etc
    # cp sysconfigtab sysconfigtab-bu
     
    

    clu_bdmgr コマンドからの出力に指示されているとおりに,vm スタンザの swapdevice 属性ならびに clubase スタンザの cluster_seqdisk_major 属性と cluster_seqdisk_minor 属性の値を変更します。

            swapdevice=/dev/disk/dsk5b
            clubase:
            cluster_seqdisk_major=19
            cluster_seqdisk_minor=175
     
    

  6. h パーティションの CNX 情報をリストアします。

    # /usr/sbin/clu_bdmgr -h  dsk5
    

    h パーティション情報は,clu_bdmgr コマンドを実行するクラスタ・メンバから dsk5h パーティションにコピーされます。

    クラスタ全体が停止している場合は,クラスタ化されたカーネルからいずれかのメンバをブートする必要があります。単一メンバのクラスタが稼働した後は,h パーティションの CNX 情報を /mnt/etc/clu_bdmgr.conf から member3 の新規ブート・ディスク dsk5 にリストアできます。次のコマンドを入力します。

    # /usr/sbin/clu_bdmgr -h  dsk5 /mnt/etc/clu_bdmgr.conf
    

  7. member3 のルート・ドメインをアンマウントします。

    # umount root3_domain#root /mnt
    

  8. member3 をクラスタ内にブートします。

  9. 必要であれば,member3consvar -s bootdef_dev disk_name コマンドを使用して,bootdef_dev 変数を新しいディスクに設定します。

11.1.6    ブート時の cluster_root の指定

ブート時に,cluster_root (クラスタ・ルート・ファイル・システム) のマウントにクラスタが使用するデバイスを指定することができます。この機能を使用するのは,障害回復のために新しいクラスタ・ルートでブートする必要があるときだけです。

CFS (クラスタ・ファイル・システム) カーネル・サブシステムでは,3 つまでの cluster_root デバイスに対する主番号と副番号を指定するために,6 つの属性をサポートしています。障害回復のために使用している cluster_root ドメインは複数のボリュームで構成されている可能性があるため,次のように cluster_root デバイスを 3 つまで指定することができます。

これらの属性を使用するには,クラスタをシャットダウンし,あるメンバを対話的にブートして適切な cluster_root_dev の主番号と副番号を指定します。メンバをブートすると,メンバのブート・ディスクの CNX パーティション (h パーティション) は,cluster_root デバイスのロケーションで更新されます。クラスタにクォーラム・ディスクがある場合は,その CNX パーティションも更新されます。その他のノードがクラスタの中にブートされるときに,それらのメンバのブート・ディスク情報も更新されます。

たとえば,dsk6bdsk8g を構成する 2 つのボリュームのファイル・システムの cluster_root を使用するとします。dsk6b の主番号は 19,副番号は 227 とします。dsk8g の主番号は 19,副番号は 221 とします。次のようにクラスタをブートします。

  1. あるメンバを対話的にブートします。

    >>> boot -fl "ia"
     (boot dkb200.2.0.7.0 -flags ia)
     block 0 of dkb200.2.0.7.0 is a valid boot block
     reading 18 blocks from dkb200.2.0.7.0
     bootstrap code read in
     base = 200000, image_start = 0, image_bytes = 2400
     initializing HWRPB at 2000
     initializing page table at fff0000
     initializing machine state
     setting affinity to the primary CPU
     jumping to bootstrap code
     
     
    .
    .
    .
    Enter kernel_name [option_1 ... option_n] Press Return to boot default kernel 'vmunix':vmunix cfs:cluster_root_dev1_maj=19 \ cfs:cluster_root_dev1_min=227 cfs:cluster_root_dev2_maj=19 \ cfs:cluster_root_dev2_min=221[Return]  

  2. その他のクラスタ・メンバをブートします。

これらの属性を使用してクラスタのルート・ファイル・システムを回復させる方法についての詳細は,11.1.7 項および 11.1.8 項を参照してください。

11.1.7    クラスタの既存のディスクへのクラスタ・ルート・ファイル・システムの回復

次のすべてにあてはまる場合に,ここで記述する回復手順を使用してください。

この手順は次のことを想定しています。

クラスタ・ルートをリストアするには,次のように行います。

  1. Tru64 UNIX ディスクでシステムをブートします。

    この手順では,このシステムを member 1 と想定します。

  2. このシステムの,新しいクラスタ・ルートになるデバイスの名前が,クラスタのそのデバイスの名前と異なる場合は,コマンド dsfmgr -m を使用してデバイス名を変更し,クラスタのデバイスの名前が一致するようにします。

    たとえば,クラスタの新しいクラスタ・ルートになるデバイスの名前が dsk6b で,システムのそのデバイスの名前が dsk4b の場合,デバイスの名前を次のコマンドで変更します。

    # dsfmgr -m dsk4 dsk6
    

  3. 必要に応じて,ディスクにパーティションを設定し,ディスクがクラスタ・ルートとして,パーティション・サイズとファイル・システム・タイプが適切になるようにします。

  4. 新しいクラスタ・ルート用の新規ドメインを作成します。

    # mkfdmn /dev/disk/dsk6d cluster_root
     
    

  5. そのドメインのルート・ファイルセットを作成します。

    # mkfset cluster_root root
     
    

  6. この復旧手順では,cluster_root に 3 つまでのボリュームを使用できます。復旧が完了したら,新しいボリュームをクラスタ・ルートに追加することができます。この例の場合,1 つのボリューム (dsk6b) のみを追加します。

    # addvol /dev/disk/dsk6b cluster_root
     
    

  7. 新しいクラスタ・ルートになるドメインをマウントします。

    # mount cluster_root#root /mnt
    

  8. バックアップ・メディアからクラスタ・ルートをリストアします (vdump 以外のバックアップ・ツールを使用した場合は,vrestore の代りに適切なリストア・ツールを使用します)。

    # vrestore -xf /dev/tape/tape0 -D /mnt
     
    

  9. 新しくリストアされたファイル・システムの /etc/fdmns/cluster_root を変更し,新しいデバイスを参照するようにします。

    # cd /mnt/etc/fdmns/cluster_root
    # rm *
    # ln -s /dev/disk/dsk6b
     
    

  10. コマンド file を使用して,新しい cluster_root デバイスの主番号と副番号を書き出しておきます (cluster_root デバイスの主番号と副番号の使用についての詳細は,11.1.6 項を参照してください)。

    たとえば,次のように行います。

    # file /dev/disk/dsk6b
    /dev/disk/dsk6b:        block special (19/221)
     
    

  11. システムをシャットダウンし,新しいクラスタ・ルートの主番号と副番号を指定して対話的にリブートします。11.1.6 項では,ブート時のクラスタ・ルートの指定方法について説明しています。

    注意

    4.10.2 項で説明されているように,メンバをブートするには,おそらく,期待ボードを調整する必要があります。

    >>> boot -fl "ia"
     (boot dkb200.2.0.7.0 -flags ia)
     block 0 of dkb200.2.0.7.0 is a valid boot block
     reading 18 blocks from dkb200.2.0.7.0
     bootstrap code read in
     base = 200000, image_start = 0, image_bytes = 2400
     initializing HWRPB at 2000
     initializing page table at fff0000
     initializing machine state
     setting affinity to the primary CPU
     jumping to bootstrap code
     
     
    .
    .
    .
    Enter kernel_name [option_1 ... option_n] Press Return to boot default kernel 'vmunix':vmunix cfs:cluster_root_dev1_maj=19 \ cfs:cluster_root_dev1_min=221[Return]  

    メンバをブートすると,メンバのブート・ディスクの CNX パーティション (h パーティション) は,cluster_root デバイスの位置で更新されます。クラスタにクォーラム・ディスクがある場合,その CNX パーティションも更新されます。クラスタに他のノードをブートするときには,メンバのブート・ディスク情報も更新されます。

  12. その他のクラスタ・メンバをブートします。

11.1.8    新しいディスクへのクラスタ・ルート・ファイル・システムの回復

クラスタの既存のディスク以外を使用して cluster_root を回復する手順は複雑です。回復させる前に,新しいクラスタ・ルート・ディスクとして使用できる,クラスタに既にインストールされているディスクを探してみてください。見つかったら,11.1.7 項の手順を実行してください。

次のような場合に,ここで記述する回復手順を使用します。

この手順は次のことを想定しています。

クラスタ・ルートをリストアするには,次のように行います。

  1. Tru64 UNIX ディスクでシステムをブートします。

    この手順では,このシステムを member 1 と想定します。

  2. 必要に応じて,ディスクにパーティションを設定し,ディスクがクラスタ・ルートとして,パーティション・サイズとファイル・システム・タイプが適切になるようにします。

  3. 新しいクラスタ・ルート用の新規ドメインを作成します。

    # mkfdmn /dev/disk/dsk5b new_root
    

    TruCluster Server 『クラスタ・インストレーション・ガイド』で説明されているように,cluster_root ファイル・システムは b パーティションによく置かれます。この場合,例として /dev/disk/dsk5b が使用されます。

  4. そのドメインのルート・ファイルセットを作成します。

    # mkfset new_root root
     
    

  5. この復旧手順では,new_root に 3 つまでのボリュームを使用できます。復旧が完了したら,新しいボリュームをクラスタ・ルートに追加することができます。この例の場合,1 つのボリューム (dsk8e) を追加します。

    # addvol /dev/disk/dsk8e new_root
    

  6. 新しいクラスタ・ルートになるドメインをマウントします。

    # mount new_root#root /mnt
    

  7. バックアップ・メディアからクラスタ・ルートをリストアします (vdump 以外のバックアップ・ツールを使用した場合は,vrestore の代わりに適切なリストア・ツールを使用します)。

    # vrestore -xf /dev/tape/tape0 -D /mnt
     
    

  8. リストアされたデータベースを,Tru64 UNIX システムの /etc ディレクトリにコピーします。

    # cd /mnt/etc
    # cp dec_unid_db dec_hwc_cdb dfsc.dat /etc
     
    

  9. リストアされたデータベースの現在のメンバのメンバ固有データを Tru64 UNIX システムの /etc ディレクトリにコピーします。

    # cd /mnt/cluster/members/member1/etc
    # cp dfsl.dat /etc
     
    

  10. メンバのブート・ディスクのドメインが存在しない場合には,ドメインを作成します。

    # cd /etc/fdmns
    # ls
    # mkdir root1_domain
    # cd root1_domain
    # ln -s /dev/disk/dsk2a
    

  11. メンバのブート・パーティションをマウントします。

    # cd /
    # umount /mnt
    # mount root1_domain#root /mnt
     
    

  12. メンバのブート・パーティションから Tru64 UNIX システムの /etc ディレクトリにデータベースをコピーします。

    # cd /mnt/etc
    # cp dec_devsw_db dec_hw_db dec_hwc_ldb dec_scsi_db /etc
     
    

  13. メンバのブート・ディスクをアンマウントします。

    # cd /
    # umount /mnt
     
    

  14. データベースの .bak バックアップ・ファイルを更新します。

    # cd /etc
    # for f in dec_*db ; do cp $f $f.bak ; done
     
    

  15. 同じ Tru64 UNIX ディスクを使ってシステムをシングルユーザ・モードにリブートし,/etc にコピーされたデータベースを使うようにします。

    クラスタ・ルート・ファイル・システムのバックアップが現在のディスク・ストレージ環境を反映していない場合,このプロシージャはこの時点でパニックを引き起こします。パニックが起こると,クラスタ・ファイル・システムを回復できなくなり,clu_create コマンドを使用してクラスタを再作成しなければならなくなります。

  16. シングルユーザ・モードにブートした後,バス上にあるデバイスをスキャンします。

    # hwmgr -scan scsi
    

  17. 書き込み可能としてルートを再マウントします。

    # /sbin/mountroot
     
    

  18. デバイス・データベースを検証し,更新します。

    # dsfmgr -v -F
     
    

  19. hwmgr を使用して現在のデバイス命名規則を確認します。

    # hwmgr -view devices
    

  20. 必要に応じて,ローカル・ドメインを更新し,デバイス命名規則を反映させます (特に,usr_domainnew_rootroot1_domain)。

    この更新作業は,適切な /etc/fdmns ディレクトリへ移り,既存リンクを削除してから新たに現在のデバイス名へのリンクを作成して行います (現在のデバイス名は前の手順で調べました)。たとえば,次のように行います。

    # cd /etc/fdmns/root_domain
    # rm *
    # ln -s /dev/disk/dsk1a
    # cd /etc/fdmns/usr_domain
    # rm *
    # ln -s /dev/disk/dsk1g
    # cd /etc/fdmns/root1_domain
    # rm *
    # ln -s /dev/disk/dsk2a
    # cd /etc/fdmns/new_root
    # rm *
    # ln -s /dev/disk/dsk5b
    # ln -s /dev/disk/dsk8e
     
    

  21. コマンド bcheckrc を実行し,ローカル・ファイル・システムをマウントします。特に /usr のマウントが必要です。

    #  bcheckrc
     
    

  22. 更新されたクラスタ・データベース・ファイルをクラスタ・ルート上にコピーします。

    # mount new_root#root /mnt
    # cd /etc
    # cp dec_unid_db* dec_hwc_cdb* dfsc.dat /mnt/etc
    # cp dfsl.dat /mnt/cluster/members/member1/etc
     
    

  23. 新しいクラスタ・ルートで,cluster_root ドメインを使用します。

    # rm /mnt/etc/fdmns/cluster_root/*
    # cd /etc/fdmns/new_root
    # tar cf - * | (cd /mnt/etc/fdmns/cluster_root && tar xf -)
     
    

  24. 更新されたクラスタ・データベース・ファイルをメンバのブート・ディスクにコピーします。

    # umount /mnt
    # mount root1_domain#root /mnt
    # cd /etc
    # cp dec_devsw_db* dec_hw_db* dec_hwc_ldb* dec_scsi_db* /mnt/etc
     
    

  25. コマンド file を使用して,新しい cluster_root デバイスの主番号と副番号を調べます (cluster_root デバイスの主番号と副番号の使用についての詳しい情報は,11.1.6 項を参照してください)。この番号は次の手順で使用するので書き出しておきます。

    たとえば,次のように行います。

    # file /dev/disk/dsk5b
    /dev/disk/dsk5b:        block special (19/227)
    # file /dev/disk/dsk8e
    /dev/disk/dsk8e:        block special (19/221)
    

  26. システムを停止させ,新しいクラスタ・ルートの主番号と副番号を指定して対話形式でリブートします。ブート時のクラスタ・ルートの指定方法については,11.1.6 項で説明しています。

    注意

    4.10.2 項で説明しているように,メンバをブートするには,おそらく,期待ボートを調整する必要があります。

    >>> boot -fl "ia"
     (boot dkb200.2.0.7.0 -flags ia)
     block 0 of dkb200.2.0.7.0 is a valid boot block
     reading 18 blocks from dkb200.2.0.7.0
     bootstrap code read in
     base = 200000, image_start = 0, image_bytes = 2400
     initializing HWRPB at 2000
     initializing page table at fff0000
     initializing machine state
     setting affinity to the primary CPU
     jumping to bootstrap code
     
     
    .
    .
    .
    Enter kernel_name [option_1 ... option_n] Press Return to boot default kernel 'vmunix':vmunix cfs:cluster_root_dev1_maj=19 \ cfs:cluster_root_dev1_min=227 cfs:cluster_root_dev2_maj=19 \ cfs:cluster_root_dev1_min=221[Return]  

  27. その他のクラスタ・メンバをブートします。

    ブート時にデバイス・ファイルでエラーが発生した場合は,コマンド dsfmgr -v -F を実行します。

11.1.9    AdvFS の問題の処理

ここでは,AdvFS を利用した場合に生じるおそれのある問題について説明します。

11.1.9.1    addvol または rmvol からの警告メッセージに対する応答

ある条件下では,cluster_root ドメインで addvol または rmvol を使用すると,次の警告メッセージが出力される場合があります。

"WARNING:cfs_write_advfs_root_data: cnx_disk_write failed for quorum disk with error-number."
 

通常は,error-numberEIO の値です。

このメッセージは,addvol または rmvol が実行されたメンバが,クォーラム・ディスクの CNX パーティションに書き込みができないことを示しています。CNX パーティションには,cluster_root ドメインのデバイス情報が含まれています。

この警告が生じるのは,ブート・メンバがクォーラム・ディスクにアクセスできない場合で,その理由はクラスタが意図的にこのように構成されているか,またはパスの障害のどちらかです。前者の理由の場合,メッセージを情報とみなすことができます。後者の理由の場合は,パスの障害の原因に対して処置を講ずる必要があります。

メッセージは,クォーラム・ディスク自体に問題があることを示す場合があります。クォーラム・ディスクのハードウェア・エラーもレポートされている場合は,そのディスクを交換する必要があります。クォーラム・ディスクの交換については,4.5.1 項を参照してください。

エラー番号については, errno(5) を参照してください。 EIO については, errno(2) を参照してください。

11.1.9.2    デバイスの接続障害による AdvFS ドメイン・パニックの解消

ドメインまたはファイルセットの置かれているストレージが 1 つでも使用できなくなると,AdvFS でドメイン・パニックが発生するおそれがあります。この問題がもっともよく発生するケースは,AdvFS ドメインで使用されているプライベート・ストレージに接続しているクラスタ・メンバがクラスタを離れた場合です。次によくあるケースは,ストレージ・デバイスにハードウェア・トラブルが発生して使用できなくなった場合です。どちらの場合も,クラスタ・メンバからそのストレージへアクセスするパスがすべてなくなって,そのストレージが使用できなくなるため,ドメイン・パニックが発生します。

通常は,ドメイン・パニックが発生して最初に現れる症状として,デバイスから入出力エラーが返ったり,システム・コンソールにパニック・メッセージが出力されたりします。ドメインでは,まだ動作しているクラスタ・メンバによってサービスが行われていると,cfsmgr -e のような CFS コマンドに対して OK のステータスが返ることがあり,問題がただちに反映されるとは限りません。

# ls -l /mnt/mytst
/mnt/mytst: I/O error
 
# cfsmgr -e
Domain or filesystem name = mytest_dmn#mytst
Mounted On = /mnt/mytst
Server Name = deli
Server Status : OK
 

デバイスの接続を回復してサービスに使用できる場合は,cfsmgr コマンドを使用して,影響を受けたドメイン内のファイルセットを,パニックが生じる前にそのドメインへサービスを提供していたメンバに (または別のメンバに) 再配置することで,継続してドメインを使用することができます。

# cfsmgr -a SERVER=provolone -d mytest_dmn
 
# cfsmgr -e
Domain or filesystem name = mytest_dmn#mytests
Mounted On = /mnt/mytst
Server Name = provolone
Server Status : OK
 

11.1.9.3    AdvFS ファイル・システムまたはドメインの強制アンマウント

デバイスの接続性を回復してサービスに戻せない場合,TruCluster Server バージョン 5.1B の cfsmgr -ucfsmgr -U コマンドを使用します。

クラスタ・メンバがサービスしていない AdvFS ファイル・システムやドメインは,cfsmgr -u を使用して,強制的にアンマウントできます。ファイル・システムまたはドメインがサービス中の場合は,アンマウントできません。

cfsmgr -U コマンドを使用して,クラスタ・メンバによってサービスされている AdvFS のドメイン全体を強制的にアンマウントできます。

上記のコマンドのどちらを使用するのかは,その時点で CFS (クラスタ・ファイル・システム) がドメインをどう認識しているかによって異なります。

cfsmgr コマンドについての詳細は, cfsmgr(8) を参照してください。

11.1.9.4    ドメイン・パニックの回避

AdvFS GUI (グラフィカル・ユーザ・インタフェース) エージェント advfsd は,定期的にシステム・ディスクを走査します。メタデータの書き込みエラーが発生した場合,または単一の AdvFS ファイル・ドメインで破損が検出された場合,advfsd デーモンは,システム・パニックではなく,ファイル・ドメイン上でドメイン・パニックを発生させます。この措置により,障害の発生したドメインが分離されるので,システムが引き続き他のすべてのドメインに対するサービスを提供できます。

クラスタのメンバ上で実行中の advfsd デーモンから見ると,AdvFS ドメインが含まれているディスクにアクセスできなくなったためにドメイン・パニックが生じる場合があります。正常な場合には,これは予定された動作です。このようなパニックを診断するには,Tru64 UNIX 『AdvFS 管理ガイド』のトラブルシューティングに関する章の手順に従ってください。ただし,クラスタ・メンバが,別のメンバのプライベート・ディスクが利用できなくなった (メンバの停止など) ためにドメイン・パニックを検出した場合は,ドメイン・パニックによって無用な混乱が生じます。

このようなメイン・パニックを回避するには,メンバの /usr/var/advfs/daemon/disks.ignore ファイルを編集して,AdvFS ドメインが含まれている他のメンバのプライベート・ストレージのディスク名を指定してください。これにより,ローカル・メンバ上の advfsd デーモンが,指定されたデバイスを走査しなくなります。

プライベート・デバイスを識別するには,sms コマンドを使用して SysMan Station のグラフィック・インタフェースを起動し,次に [Views] メニューから [Hardware] を選択してください。

11.1.10    停止したシステム上のブート・パーティションへのアクセス

正常なシャットダウンによって,またはパニックなどの予定外の方法で,メンバがクラスタから外れる場合は,そのメンバのブート・パーティションはアンマウントされます。ブート・パーティションが共用バス上にある場合は,そのパーティションをマウントすれば,他のどのメンバでもブート・パーティションにアクセスできます。

システム provolone の停止中に provolone/etc/sysconfigtab を編集するとします。その場合は,次のように入力できます。

# mkdir /mnt
# mount root2_domain#root /mnt
 

provolone をリブートする前に,root2_domain#root をアンマウントしなければなりません。たとえば,次のように指定します。

# umount root2_domain#root
 

11.1.11    ブート・ディスクがすでにマウントされているメンバのブート

期待されるクォーラム・ボートまたはクォーラム・ディスク・デバイスが変更されると,各メンバの /etc/sysconfigtab ファイルが更新されます。クラスタ・メンバがダウンしている場合は,クォーラムに影響するクラスタ・ユーティリティ (clu_add_memberclu_quorumclu_delete_member など) が,ダウンしているメンバのブート・ディスクをマウントして更新します。ダウンしたメンバをブート・ディスクのマウント中にブートしようとすると,次のようなパニック・メッセージが出力されます。

cfs_ mountroot: CFS server already exists for this nodes boot partition

クラスタ・ユーティリティは,正常にダウンしているメンバのブート・ディスクをアンマウントします。

一般に,他のメンバがあるメンバのブート・ディスクをマウントしているときにそのメンバをブートしようとすると,パニックが発生します。たとえば,ダウンしているメンバのブート・ディスクをマウントして修復する場合,修復できたメンバをブートする前にそのブート・ディスクをアンマウントしなければ,パニックが発生します。

11.1.12    クラッシュ・ダンプの生成

クラスタに重大な問題が生じた場合は,すべてのクラスタ・メンバからのクラッシュ・ダンプが必要になる可能性があります。動作中のメンバからクラッシュ・ダンプを取得するには,dumpsys コマンドを使用して,システム・メモリのスナップショットをダンプ・ファイルに保存してください。

クラッシュ・ダンプを生成するには,動作中の各クラスタ・メンバにログインして dumpsys を実行してください。省略時には,dumpsys を実行すると,メンバ固有のディレクトリ /var/adm/crash にダンプが書き込まれます。

詳細は, dumpsys(8) を参照してください。

SysMan Menu Configure Dump および Create Dump Snapshot を使用しても,クラッシュ・ダンプを構成できます。Configure Dump 機能は,savecore コマンドに関連する一般的なシステム構成変数に設定します。Create Dump Snapshot 機能は,dumpsys コマンドを使用します。このコマンドは,通常のクラッシュ・ダンプを生成するためにそのシステムを停止することができないときに,メモリのスナップショットを手動でファイルにダンプするために使用します。

11.1.12.1    メンバがハングしたときのクラッシュ・ダンプの生成

クラスタ・メンバがハングした場合,クラッシュ・ダンプを生成するために dumpsys コマンドを使用することができません。この場合,クラッシュ・ダンプを生成するには次の手順を使用します。

  1. dumpsys コマンドを使用して,動作中のメンバのメモリ・スナップショットをダンプ・ファイルにコピーします。省略時には,dumpsys コマンドは /var/adm/crash にダンプを書き込みます。このパスは,CDSL であり,実際のパスは /cluster/members/{memb}/adm/crash となります。

  2. 5.5 節に説明されているように,clu_quorum コマンドを使用して,ハングしたメンバを停止したときにクォーラムを失っていないことを確認します。

  3. ハングしたメンバをクラッシュさせます。これを行うには,メンバを手動で停止し,コンソールのプロンプトで crash を実行します。

  4. メンバをブートします。ブートで savecore ( savecore(8)) を実行し,/var/adm/crash にダンプします。

11.1.13    ネットワーク問題の修正

ここでは,クラスタ内の潜在的なネットワークの問題とその解決策について説明します。

症状

確認事項

/etc/rc.config/etc/hosts 内のエントリが正しく,他の問題がすべて修正されたことを確認した後は,gatewayinet のデーモンを停止してから再起動してください。この操作を行うには,各クラスタ・メンバ上で次のコマンドを入力します。

# /sbin/init.d/gateway stop
# /sbin/init.d/gateway start
 

11.1.14    クラスタでの routed の実行

TruCluster Server バージョン 5.1B より前のリリースでは,ルーティング・デーモンとして gated をクラスタで実行する必要がありました。routedogated,または静的ルーティングのセットアップを使用できず,また,ルーティング・デーモンも使用できませんでした。バージョン 5.1B からは,gatedrouted,または静的ルーティングが使用可能になりました。ogated は使用できません。省略時の構成では,gated となります。3.14 節でルーティング・オプションについて説明しています。

11.2    クラスタ管理のヒント

ここでは,クラスタの構成と管理のヒントおよび提案について説明します。

11.2.1    /tmp の移動

省略時には,メンバ固有の /tmp 領域は同じファイル・システム内にありますが,その領域は個々のファイル・システムに移動できます。場合によっては,共用 SCSI バスのトラフィックを軽減するために,各メンバの /tmp 領域をメンバのローカル・ディスクに移動してもかまいません。

クラスタ・メンバに対してプライベート・バス上の固有の /tmp ディレクトリを設定したい場合は,そのクラスタ・メンバのローカル・バス上のディスクに AdvFS ドメインを作成して,そのドメインの /etc/fstab/tmp のマウント・ポイントを持つエントリを追加できます。

たとえば,次の /etc/fstab のエントリは,メンバ ID がそれぞれ 5859 の 2 つのクラスタ・メンバ tcr58tcr59/tmp ディレクトリに対応しています。

    tcr58_tmp#tmp   /cluster/members/member58/tmp   advfs rw 0 0
    tcr59_tmp#tmp   /cluster/members/member59/tmp   advfs rw 0 0

tcr58_tmp ドメインは,tcr58 メンバのみが接続できるバス上にあります。tcr59_tmp ドメインは,tcr59 メンバのみが接続できるディスク上にあります。

各メンバは,ブート時に /etc/fstab 内のすべてのファイル・システムをマウントしようとしますが,マウントできるのは,まだマウントされていない,デバイスへのパスが存在するドメインのみです。この例では,tcr58tcr58_tmp#tmp のみをマウントできます。また,tcr59tcr59_tmp#tmp のみをマウントできます。

/etc/fstab に次のように設定できます。

    tcr58_tmp#tmp   /tmp    advfs rw 0 0
    tcr59_tmp#tmp   /tmp    advfs rw 0 0

/tmp は CDSL (コンテキスト依存シンボリック・リンク) なので,/cluster/members/membern/tmp に解決されます。ただし,/etc/fstab に完全パス名を設定すれば,より明らかになるので混乱が生じる確率は低くなります。

11.2.2    MC_CABLE コンソール・コマンドの実行

任意のメンバ上で MC_CABLE Memory Channel 診断コマンドを実行する前に,すべてのメンバをコンソール・プロンプトに応じてシャットダウンしなければなりません。これは正常な操作です。

停止しているクラスタ・メンバのコンソールから,他のメンバの起動時に MC_CABLE コマンドを実行すると,クラスタがクラッシュします。

11.2.3    Korn シェルにおけるメンバ固有のディレクトリへの実パスの非表示

Korn シェル (ksh) では,ディレクトリまでのパスが記憶され,pwd コマンドを入力すると,そのパス名が表示されます。これは,パス内のシンボリック・リンクのために別のディレクトリに移動している場合でも同じです。TruCluster Server では,CDSL を利用してメンバ固有のディレクトリがクラスタ単位のネームスペースに保持されるので,作業ディレクトリが CDSL になっている場合は,Korn シェルでは実パスは返されません。

パス名の表示時にシェルでシンボリック・リンクを解釈させたい場合は,Korn シェル以外のシェルを使用してください。たとえば,次のようになります。

# ksh
# ls -l /var/adm/syslog
lrwxrwxrwx   1 root system  36 Nov 11 16:17 /var/adm/syslog
->../cluster/members/{memb}/adm/syslog
# cd /var/adm/syslog
# pwd
/var/adm/syslog
# sh
# pwd
/var/cluster/members/member1/adm/syslog