9    ファイル・システムとデバイスの管理

この章では,TruCluster Server システムでのストレージ・デバイスの管理に特有な情報を記載しています。ここでは,次の項目について説明します。

その他のデバイス管理に関する情報は,表 9-1 に示す Tru64 UNIX バージョン 5.1B のマニュアルに記載されています。

表 9-1:  ストレージ・デバイス管理の参考マニュアル

内容 Tru64 UNIX マニュアル
デバイスの管理 ハードウェア管理ガイド
ファイル・システムの管理 システム管理ガイド
アーカイブ・サービスの管理 システム管理ガイド
AdvFS の管理 AdvFS 管理ガイド

LSM (Logical Storage Manager) とクラスタについては,第 10 章を参照してください。

9.1    CDSL の使用

コンテキスト依存シンボリック・リンク (CDSL) には,クラスタ・メンバを識別する変数があります。この変数は,実行時にターゲット内で解決されます。

CDSL は,次のように構造化されます。

/etc/rc.config -> ../cluster/members/{memb}/etc/rc.config

CDSL パス名を解決する場合は,カーネルにより,文字列 {memb} が文字列 membern に置き換えられます。ここで,n は現在のメンバ ID です。たとえば,メンバ ID が 2 のクラスタ・メンバでは,パス名 /cluster/members/{memb}/etc/rc.config は,/cluster/members/member2/etc/rc.config に解決されます。

CDSL を利用すれば,単一ファイル名で複数のファイルのうちの 1 つを示すことができます。クラスタでこの CDSL を利用すれば,メンバ固有のファイルをクラスタ単位で単一ファイル名によって指定できるようになります。システム・データと構成ファイルで CDSL が利用される傾向にあります。このようなファイルは,ルート (/),/usr,および /var のディレクトリにあります。

9.1.1    CDSL の作成

mkcdsl コマンドには,CDSL の作成や設定を行うための簡単なツールが用意されています。たとえば,/usr/accounts/usage-history ファイルの新規 CDSL を作成するには,次のコマンドを入力してください。

# mkcdsl /usr/accounts/usage-history
 

結果のリストを表示させると,次のように出力されます。

# ls -l /usr/accounts/usage-history
 
... /usr/accounts/usage-history -> cluster/members/{memb}/accounts/usage-history

CDSL usage-history は,/usr/accounts に作成されます。どのメンバの /usr/cluster/members/{memb} ディレクトリにもファイルは作成されません。

CDSL にファイルを移動するには,次のコマンドを使用してください。

# mkcdsl -c targetname
 

コピー (-c) オプションを使用して既存のファイルを置き換える場合は,強制 (-f) オプションも使用しなければなりません。

-c オプションを使用すれば,クラスタ・メンバのメンバ固有の領域にソース・ファイルがコピーされます。この領域で,mkcdsl コマンドが実行され,ソース・ファイルが CDSL で置き換えられます。ソース・ファイルをすべてのクラスタ・メンバのメンバ固有の領域にコピーしてから,ソース・ファイルを CDSL に置き換えるには,次のように,コマンドに -a オプションを使用してください。

# mkcdsl -a filename
 

CDSL の削除は,他のシンボリック・リンクを削除する場合と同様に,rm コマンドを使用します。

/var/adm/cdsl_admin.inv ファイルには,クラスタの CDSL の記録が格納されます。mkcdsl コマンドを使用して CDSL を追加すると,コマンドにより,/var/adm/cdsl_admin.inv が更新されます。ln -s コマンドを使用して CDSL を作成した場合には,/var/adm/cdsl_admin.inv は更新されません。

/var/adm/cdsl_admin.inv を更新するには,次のコマンドを入力します。

# mkcdsl -i targetname

CDSL を削除する場合,または ln -s を使用して CDSL を作成した場合は,インベントリを更新します。

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

9.1.2    CDSL の保守

次のツールは,CDSL の保守に役立ちます。

次の例は,clu_check_config で不正な CDSL や不明な CDSL が検出された場合の出力 (およびエラーが記述されたログ・ファイルへのポインタ) を示しています。

# clu_check_config -s check_cdsl_config
Starting Cluster Configuration Check...
check_cdsl_config : Checking installed CDSLs
check_cdsl_config : CDSLs configuration errors : See /var/adm/cdsl_check_list
clu_check_config : detected one or more configuration errors
 

通常,ファイルを移動する前に,コピー先が CDSL でないことを確認します。誤って該当するクラスタ・メンバの CDSL を上書きした場合は,mkcdsl -c filename コマンドを使用してファイルをコピーし,CDSL を再作成してください。

9.1.3    カーネル構築と CDSL

クラスタでカーネルを構築する場合は,コマンド cp を使って,新しいカーネルを /sys/HOSTNAME/vmunix から /vmunix へコピーします。カーネルを /vmunix へ移動させると,/vmunix CDSL を上書きします。そのため,次にクラスタ・メンバをブートすると,/sys/HOSTNAME/vmunix 内の古い vmunix を使うことになります。

9.1.4    CDSL のエクスポートとマウント

CDSL は,1 つのファイル名で異なるクラスタ・メンバのさまざまな内容を表す必要がある場合に使用されます。このようなことから,CDSL はエクスポート用には指定されていません。

クラスタ別名で CDSL をマウントすると,マウント要求を取得するクラスタ・システムによってファイルの内容が異なるため,問題が生じます。ただし,CDSL のエクスポートを防止することはできません。ディレクトリ全体が CDSL になっている場合は,マウント要求を受けるノードから,そのノードのディレクトリに対応するファイル・ハンドルが得られます。CDSL が,エクスポートされたクラスタ単位のディレクトリ内に含まれている場合は,要求を受けるネットワーク・ファイル・システム (NFS) サーバが拡張します。通常のシンボリック・リンクと同様に,クライアントがファイルまたはディレクトリを読み込むことはできません。ただし,該当する領域もクライアントでマウントされている場合は除きます。

9.2    デバイスの管理

クラスタでのデバイス管理は,次の例外を除けば,スタンドアロン・システムにおける管理と同様です。

以降の各項で,これらの違いについて説明します。

9.2.1    デバイス・スペシャル・ファイルの管理

クラスタ内で dsfmgr (デバイス・スペシャル・ファイル管理ユーティリティ) を使用する場合は,次のことに留意してください。

詳細は, dsfmgr(8) を参照してください。デバイス,デバイスの命名,およびデバイス管理については,Tru64 UNIX 『ハードウェア管理ガイド』を参照してください。

9.2.2    デバイス位置の確定

Tru64 UNIX の hwmgr コマンドを使用すれば,プライベート・バス上のハードウェア・デバイスをはじめとするクラスタ内のすべてのハードウェア・デバイス,バス-ターゲット-LUN の名前と /dev/disks/dsk* の名前との関連を示すことができます。たとえば,次のようになります。

# hwmgr -view devices -cluster
HWID: Device Name         Mfg     Model            Hostname   Location       
-------------------------------------------------------------------------------
  3: kevm                                         pepicelli
 28: /dev/disk/floppy0c          3.5in floppy     pepicelli  fdi0-unit-0
 40: /dev/disk/dsk0c     DEC     RZ28M    (C) DEC pepicelli  bus-0-targ-0-lun-0
 41: /dev/disk/dsk1c     DEC     RZ28L-AS (C) DEC pepicelli  bus-0-targ-1-lun-0
 42: /dev/disk/dsk2c     DEC     RZ28     (C) DEC pepicelli  bus-0-targ-2-lun-0
 43: /dev/disk/cdrom0c   DEC     RRD46    (C) DEC  pepicelli bus-0-targ-6-lun-0
 44: /dev/disk/dsk3c     DEC     RZ28M    (C) DEC pepicelli  bus-1-targ-1-lun-0
 44: /dev/disk/dsk3c     DEC     RZ28M    (C) DEC polishham  bus-1-targ-1-lun-0
 44: /dev/disk/dsk3c     DEC     RZ28M    (C) DEC provolone  bus-1-targ-1-lun-0
 45: /dev/disk/dsk4c     DEC     RZ28L-AS (C) DEC pepicelli  bus-1-targ-2-lun-0
 45: /dev/disk/dsk4c     DEC     RZ28L-AS (C) DEC polishham  bus-1-targ-2-lun-0
 45: /dev/disk/dsk4c     DEC     RZ28L-AS (C) DEC provolone  bus-1-targ-2-lun-0
 46: /dev/disk/dsk5c     DEC     RZ29B    (C) DEC pepicelli  bus-1-targ-3-lun-0
 46: /dev/disk/dsk5c     DEC     RZ29B    (C) DEC polishham  bus-1-targ-3-lun-0
 46: /dev/disk/dsk5c     DEC     RZ29B    (C) DEC provolone  bus-1-targ-3-lun-0
 47: /dev/disk/dsk6c     DEC     RZ28D    (C) DEC pepicelli  bus-1-targ-4-lun-0
 47: /dev/disk/dsk6c     DEC     RZ28D    (C) DEC polishham  bus-1-targ-4-lun-0
 47: /dev/disk/dsk6c     DEC     RZ28D    (C) DEC provolone  bus-1-targ-4-lun-0
 48: /dev/disk/dsk7c     DEC     RZ28L-AS (C) DEC pepicelli  bus-1-targ-5-lun-0
 48: /dev/disk/dsk7c     DEC     RZ28L-AS (C) DEC polishham  bus-1-targ-5-lun-0
 48: /dev/disk/dsk7c     DEC     RZ28L-AS (C) DEC provolone  bus-1-targ-5-lun-0
 49: /dev/disk/dsk8c     DEC     RZ1CF-CF (C) DEC pepicelli  bus-1-targ-8-lun-0
 49: /dev/disk/dsk8c     DEC     RZ1CF-CF (C) DEC polishham  bus-1-targ-8-lun-0
 49: /dev/disk/dsk8c     DEC     RZ1CF-CF (C) DEC provolone  bus-1-targ-8-lun-0
 50: /dev/disk/dsk9c     DEC     RZ1CB-CS (C) DEC pepicelli  bus-1-targ-9-lun-0
 50: /dev/disk/dsk9c     DEC     RZ1CB-CS (C) DEC polishham  bus-1-targ-9-lun-0
 50: /dev/disk/dsk9c     DEC     RZ1CB-CS (C) DEC provolone  bus-1-targ-9-lun-0
 51: /dev/disk/dsk10c    DEC     RZ1CF-CF (C) DEC pepicelli  bus-1-targ-10-lun-0
 51: /dev/disk/dsk10c    DEC     RZ1CF-CF (C) DEC polishham  bus-1-targ-10-lun-0
 51: /dev/disk/dsk10c    DEC     RZ1CF-CF (C) DEC provolone  bus-1-targ-10-lun-0
 52: /dev/disk/dsk11c    DEC     RZ1CF-CF (C) DEC pepicelli  bus-1-targ-11-lun-0
 52: /dev/disk/dsk11c    DEC     RZ1CF-CF (C) DEC polishham  bus-1-targ-11-lun-0
 52: /dev/disk/dsk11c    DEC     RZ1CF-CF (C) DEC provolone  bus-1-targ-11-lun-0
 53: /dev/disk/dsk12c    DEC     RZ1CF-CF (C) DEC pepicelli  bus-1-targ-12-lun-0
 53: /dev/disk/dsk12c    DEC     RZ1CF-CF (C) DEC polishham  bus-1-targ-12-lun-0
 53: /dev/disk/dsk12c    DEC     RZ1CF-CF (C) DEC provolone  bus-1-targ-12-lun-0
 54: /dev/disk/dsk13c    DEC     RZ1CF-CF (C) DEC pepicelli  bus-1-targ-13-lun-0
 54: /dev/disk/dsk13c    DEC     RZ1CF-CF (C) DEC polishham  bus-1-targ-13-lun-0
 54: /dev/disk/dsk13c    DEC     RZ1CF-CF (C) DEC provolone  bus-1-targ-13-lun-0
 59: kevm                                         polishham  
 88: /dev/disk/floppy1c          3.5in floppy     polishham  fdi0-unit-0
 94: /dev/disk/dsk14c    DEC     RZ26L    (C) DEC polishham  bus-0-targ-0-lun-0
 95: /dev/disk/cdrom1c   DEC     RRD46   (C) DEC  polishham  bus-0-targ-4-lun-0
 96: /dev/disk/dsk15c    DEC     RZ1DF-CB (C) DEC polishham  bus-0-targ-8-lun-0
 99: /dev/kevm                                    provolone    
127: /dev/disk/floppy2c          3.5in floppy     provolone  fdi0-unit-0
134: /dev/disk/dsk16c    DEC     RZ1DF-CB (C) DEC provolone  bus-0-targ-0-lun-0
135: /dev/disk/dsk17c    DEC     RZ1DF-CB (C) DEC provolone  bus-0-targ-1-lun-0
136: /dev/disk/cdrom2c   DEC     RRD47   (C) DEC  provolone  bus-0-targ-4-lun-0

drdmgr devicename コマンドでは,デバイスに対するサービスを提供するメンバが報告されます。複数のサーバに対応するディスクは共用 SCSI バス上にあります。数少ない例外を除けば,1 台のサーバのみに対応しているディスクは,そのサーバのプライベート・ディスクです。例外についての詳しい説明は,9.4.1 項を参照してください。

クラスタ・メンバのハードウェア構成を確認するには,次のコマンドを入力してください。

# hwmgr -view hierarchy -member membername
 

メンバが共用バス上にある場合は,このコマンドで,共用バス上のデバイスが報告されます。このコマンドでは,他のメンバのプライベート・デバイスは報告されません。

動作中のメンバ,バス,共用ストレージ・デバイスとプライベート・ストレージ・デバイス,およびそれらの接続をはじめとするクラスタ・ハードウェア構成をグラフィック表示するには,sms コマンドを使用して SysMan Station のグラフィック・インタフェースを起動し,次に [View] メニューから [Hardware] を選択してください。

図 9-1 は,SysMan Station で表示した 2 メンバ・クラスタを示しています。

図 9-1:  SysMan Station でのハードウェア構成の表示

9.2.3    クラスタへのディスクの追加

SCSI ハードウェア・デバイスの物理的な設置については,TruCluster Server 『クラスタ・ハードウェア構成ガイド』を参照してください。新しいディスクを設置した後は,以下の手順に従ってください。

  1. すべてのメンバが新しいディスクを認識するように,各メンバ上で次のコマンドを実行します。

    # hwmgr -scan comp -cat scsi_bus
    

    注意

    ディスクにアクセスする必要のあるすべてのクラスタ・メンバ上で hwmgr -scan comp -cat scsi_bus コマンドを実行しなければなりません。

    すべてのメンバに新しいディスクの情報が登録されるまでしばらく待ちます。

  2. 追加するディスクがモデル RZ26,RZ28,RZ29,または RZ1CB-CA の場合,各クラスタ・メンバ上で次のコマンドを実行します

    # /usr/sbin/clu_disk_install
    

    クラスタに多数のストレージ・デバイスがある場合は,このコマンドが完了するのに数分かかります。

  3. 新しいディスクの名前を確認するには,次のコマンドを入力します。

    # hwmgr -view devices -cluster
    

    SysMan Station コマンドを実行し,[Views] メニューから [Hardware] を選択して,新しいディスク名を確認することもできます。

ディスク上でのファイル・システムの作成については,9.6 節を参照してください。

9.2.4    他社製ストレージの管理

クラスタ・メンバがクォーラムを失うと,その入出力はすべて中断され,残りのメンバは,クラスタから削除されたノードに対して入出力バリアを形成します。この入出力バリアが働くと,非クラスタ・メンバは共用ストレージ・デバイスに対して入出力できなくなります。

入出力バリアを形成する方法は,クラスタ・メンバが共用しているストレージ・デバイスのタイプによって異なります。場合によっては,Target_Reset というタスク管理の機能を使って,今までメンバであったノードとの間で行うすべての入出力を停止します。このタスク管理の機能は,次のいずれかの状況で使用されます。

どちらの状況でも,Target_Reset を送ってから,デバイスと前メンバとの間で保留されていたすべての入出力がクリアされるまでに,遅延が生じます。この遅延の長さは,デバイスとクラスタの構成によって異なります。遅延が発生している間に,前メンバから入出力が発生することもあります。Target_Reset の後で送られたこの入出力は,他のノードから影響を受けることなく,通常どおり行われます。

この遅延待ち時間は,drd_target_reset_wait カーネル属性で構成可能です。デバイス要求ディスパッチャは,この時間が経過するまで,共用デバイスに対する新しい入出力をすべて中断します。Target_Reset を受信した後に前メンバから入出力要求を受け取ったデバイスでも,この間にクリアできます。この時間が経過すると,入出力バリアが働き始めます。

drd_target_reset_wait の省略時の値は 30 秒です。通常は,この値で十分です。それでも,クラスタ内に他社製デバイスがあって不安のある場合は,そのデバイスの製造元に仕様を問い合わせて,Target_Reset を受信してから入出力をクリアするまでにどの程度時間がかかるかを確認してください。

drd_target_reset_wait はブート時と実行時に設定することもできます。

クォーラムの喪失とシステムの分断についての詳細は,TruCluster Server 『クラスタ概要』 の接続マネージャに関する章を参照してください。

9.2.5    テープ装置

テープ装置がメンバのプライベート・バス上,共用バス上,または別メンバのプライベート・バス上にあっても,クラスタ上のそのテープ装置にはどのメンバからでもアクセスできます。

複数のメンバが装置へ直接アクセスする共用バス上に,テープ装置を配置します。共用バス上のテープ装置の性能も考慮します。テープ装置のある共用バス上のシステムへ接続されたストレージのバックアップは,クラスタ・インターコネクトを介すより高速です。たとえば,図 9-2 では,dsk9dsk10 をテープ・ドライブへバックアップするにはクラスタ・インターコネクトを介して行います。セミ・プライベート・ディスク dsk11dsk12dsk13dsk14 を含むその他のディスクをバックアップする場合,データ転送速度が速くなります。

図 9-2:  セミ・プライベート・ストレージを持つクラスタ

テープ装置が共用バス上に配置されている場合,装置へアクセスするアプリケーションは,共用 SCSI バス上の特定のイベントに対して適切に対応するように記述しなければなりません (たとえば,バス,デバイスのリセット)。バスとデバイスのリセット (たとえば,クラスタ・メンバシップ遷移による) は,共用 SCSI バス上のすべてのテープ装置を巻き戻します。

テープ・サーバ・アプリケーションの read() または write() では,errno が返されます。I/O 呼出しから戻されたエラー情報を使用するようにテープ・サーバ・アプリケーションを明示的に設定し,テープを再位置付けします。read() または write() の操作が失敗したときは,ioctl()MTIOCGET コマンド・オプションと一緒に使用して,アプリケーションでテープを再位置付けするために必要なエラー情報を持つ構造体を取得します。構造体の説明は,/usr/include/sys/mtio.h を参照してください。

通常使うユーティリティ tarcpiodumpvdump はこのように設計されていません。そのため,クラスタ内の共用バスに存在するテープ装置上で使うときには,予告なく停止する可能性があります。

9.2.6    クラスタでのディスケットのフォーマット

9.3.7 項で説明するように,TruCluster Server には UFS (UNIX ファイル・システム) ファイル・システムの読み取り/書き込み機能があるので,TruCluster Server を用いてディスケットをフォーマットできます。

バージョン 5.1A より前の TruCluster Server では,UFS ファイル・システムの読み取り/書き込みはできません。旧バージョンの TruCluster Server は UFS ファイル・システムの読み取り/書き込みをサポートしておらず,また,AdvFS メタデータがディスケットの容量を超えるので,クラスタ内では一般的な方法でディスケットをフォーマットできません。

バージョン 5.1A より前のバージョンの TruCluster Server でクラスタ内のディスケットをフォーマットしなければならない場合は,mtools または dxmtools のツール・セットを使用してください。詳細は, mtools(1) および dxmtools(1) を参照してください。

9.2.7    CD-ROM と DVD-ROM

CD-ROM 装置と DVD-ROM 装置は常時サービスされる装置です。この種の装置はローカル・バスへ接続する必要があります。つまり,共用バスへ接続できません。

クラスタ上で CD-ROM ファイル・システム (CDFS) を管理する方法については,9.7 節を参照してください。

9.3    クラスタ・ファイル・システムの管理

クラスタ・ファイル・システム (CFS) を利用すれば,クラスタ内のどこに格納されたファイルでも透過的にアクセスできます。ユーザやアプリケーションは,1 つのシステム・イメージでファイルにアクセスできます。アクセス方法は,アクセス要求元のクラスタ・メンバがどこにあるかや,ファイルを格納しているディスクがクラスタ内のどこに接続されているかにかかわらず,同じです。CFS では,サーバ/クライアント・モデルに従って,クラスタ・メンバが各ファイル・システムに対するサービスを提供します。クラスタ・メンバは,クラスタ内のどのデバイス上のファイル・システムに対するサービスも提供できます。ファイル・システムを提供しているメンバが利用できなくなった場合は,CFS サーバにより利用可能なクラスタ・メンバに自動的にフェイルオーバされます。

クラスタ・ファイル・システム管理用の基本ツールは cfsmgr コマンドです。このコマンドの使用例についてはこの節で説明します。cfsmgr コマンドについての詳しい説明は, cfsmgr(8) を参照してください。

TruCluster Server バージョン 5.1B では,mount コマンドの -o オプションが用意され,起動時に特定のクラスタ・メンバでファイル・システムがサービスされます。このオプションについては 9.3.4 項で説明します。

TruCluster Server バージョン 5.1B では,負荷モニタ・デーモン /usr/sbin/cfsd が提供されており,ファイル・システム関連のメンバやクラスタのアクティビティを監視したり,そのレポートを作成したり,応答したりします。cfsd デーモンについては,9.3.3 項で説明します。

CFS についての統計情報を収集するには,コマンド cfsstat またはコマンド cfsmgr -statistics を使います。cfsstat を使って直接入出力についての情報を取得する例が 9.3.6.2 項 に示されています。このコマンドについての詳細は, cfsstat(8) を参照してください。

共用バス上のデバイスのファイル・システムでは,入出力性能は,バスの負荷とファイル・システムを提供しているメンバの負荷によって異なります。負荷分散を単純化するために,CFS では,サーバを別のメンバに容易に再配置できます。メンバがプライベート・デバイスのファイル・システムに対するサービスを提供している場合,そのメンバは,ファイル・システムに高速にアクセスできます。

9.3.1    ファイル・システムがフェイルオーバできない場合

ほとんどの場合,CFS を利用すれば,クラスタ内のファイル・システムを問題なくフェイルオーバできます。ファイル・システムに対するサービスを提供しているクラスタ・メンバが利用できなくなった場合,CFS では,利用可能なメンバにサーバがフェイルオーバされます。ただし,次のような場合には,ファイル・システムへのパスが存在しないので,ファイル・システムがフェイルオーバできません。

どちらの場合も,cfsmgr コマンドは,ファイル・システム (またはドメイン) について次の状態を返します。

Server Status : Not Served

ファイル・システムにアクセスしようとすると,次のメッセージが返されます。

filename I/O error
 

ストレージに接続されたクラスタ・メンバが利用可能になると,ファイル・システムに対するサービスが再び提供されて,ファイル・システムにアクセスできるようになります。メンバを利用可能にする以外には,処置の必要はありません。

9.3.2    ダイレクト・アクセス・キャッシュド・リード

TruCluster Server には ダイレクト・アクセス・キャッシュド・リード が実装されており,AdvFS ファイル・システムの性能が向上しています。CFS はダイレクト・アクセス・キャッシュド・リードを使用することで,同時に複数のクラスタ・メンバに代わってストレージから読み取ることができます。

読み取りを発行したクラスタ・メンバがファイル・システムのあるストレージに直接接続されていると,ダイレクト・アクセス・キャッシュド・リードはそのストレージに直接アクセスし,CFS サーバとの間にあるクラスタ・インターコネクトを経由しません。

CFS クライアントは,自分がファイル・システムのあるストレージに直接接続されていない場合 (たとえば,ストレージがクラスタ・メンバに対してプライベートである場合) でも,読み取り要求をそのデバイスに直接発行します。ただし,この場合,デバイス要求ディスパッチャの階層はクラスタ・インターコネクトを通して読み取り要求をデバイスに送ります。

ダイレクト・アクセス・キャッシュド・リードと CFS がサービスを行う既存のファイル・システム・モデルとの間には整合性があり,CFS サーバは,読み取り操作に関するメタデータとログの更新を今までどおり行います。

ダイレクト・アクセス・キャッシュド・リードは AdvFS ファイルにのみ実装されています。また,ダイレクト・アクセス・キャッシュド・リードは,サイズが 64K 以上のファイルに対してのみ実行されます。小さなファイルを処理する場合は,通常の入出力方法の方が効率的です。

ダイレクト・アクセス・キャッシュド・リードは特に指定しなくても有効になっており,ユーザが設定したり調節したりすることはできません。ただし,アプリケーションが 9.3.6.2 項で述べるように直接入出力を使用する場合は,そちらの方が優先され,そのアプリケーションに対してダイレクト・アクセス・キャッシュド・リードは実行されません。

cfsstat directio コマンドを使用して直接入出力の統計情報を表示させることができます。ダイレクト・アクセス・キャッシュド・リードの統計情報は direct i/o reads フィールドに表示されます。これらのフィールドについての詳細は,9.3.6.2.3 項を参照してください。

# cfsstat directio
Concurrent Directio Stats:
     941 direct i/o reads
       0 direct i/o writes
       0 aio raw reads
       0 aio raw writes
       0 unaligned block reads
      29 fragment reads
      73 zero-fill (hole) reads
       0 file-extending writes
       0 unaligned block  writes
       0 hole writes
       0 fragment writes
       0 truncates
 

9.3.3    CFS の負荷分散

クラスタのブート時に,TruCluster Server ソフトウェアにより,各ファイル・システムは,それぞれに対するサービスを提供するメンバに直接接続されます。メンバのローカ ル・バスに接続されたデバイスのファイル・システムは,そのメンバがサービスを提供します。共用 SCSI バス上のデバイスのファイル・システムは,その SCSI バスに直接接続されたメンバのいずれかがサービスを提供します。

AdvFS の場合は,CFS サーバに割り当てられた最初のファイルセットによって,そのドメイン内の他のすべてのファイルセットに CFS サーバと同じクラスタ・メンバが設定されていると判断されます。

クラスタのブート時には,通常,共用 SCSI バスに接続されている最初に起動したメンバが,最初に共用バス上のデバイスを検出します。その後,このメンバが,共用バス上のすべてのデバイスに対するすべてのファイル・システムの CFS サーバになります。 このため,ほとんどのファイル・システムは 1 つのメンバで取り扱われるため,そのメンバは他のメンバよりも負荷が重くなります。したがって,そのメンバのリソース (CPU,メモリ,I/O,など) の使用量は大きくなります。このような場合には,ファイル・システムを他のクラスタ・メンバに再配置して,負荷の分散と性能の向上を図ることをお奨めします。

TruCluster Server バージョン 5.1B には,負荷モニタ・デーモン /usr/sbin/cfsd が用意されており,ファイル・システム関連のメンバとクラスタのアクティビティを監視したり,そのレポートを作成したり,応答したりします。cfsd は,省略時の構成では無効なので,明示的に有効にする必要があります。有効にされた後,cfsd は次の機能を実行します。

cfsd デーモンのインスタンスはクラスタの各メンバ上で実行します。すなわち,cfsd がクラスタで動作するときには,各メンバ上で実行する必要があり,適切に動作する各メンバ上のデーモンに依存します。cfsd をクラスタで動作させたくない場合は,どのメンバにもその実行を許可しないでください。

デーモンの各インスタンスはそのメンバ上で統計情報を収集し,CFS メモリが少ないというようなメンバ固有のイベントを監視します。クラスタのデーモンは,自動的に "マスタ" デーモンとしてサービスされ,収集したすべての統計情報を分析し,推奨案を作成して,自動的な再配置を開始します。このデーモンは,クラスタ単位の /etc/cfsd.conf 構成ファイルを介して構成されます。

cfsd デーモンは,定期的にメンバをポーリングして情報を入手し,ファイル・システムの性能とリソースの使用量を監視します。このポーリングは,指定されたポリシに対応した /etc/cfsd.conf 構成ファイルの polling_schedule 属性に従って行われます。

cfsd デーモンは,各メンバの各ファイル・システムの使用量,各ファイル・システムのメモリ要求,各メンバのシステム・メモリ要求,メンバの物理的なストレージ接続性などの情報を収集しています。各デーモンは,メンバ固有のバイナリ・ファイル /var/cluster/cfs/stats.member に統計情報を格納します。このファイルのデータは,cfsd 固有のフォーマットであり,直接のユーザ・アクセスを意図していません。cfsd デーモンはこれらのファイルを更新して,保守します。定期的に削除したり,保存したりする必要はありません。

次のデータは,各クラスタ・メンバによって収集されます。

次のデータは,メンバごと,ファイル・システムごとに集められます。

また,cfsd デーモンは EVM イベントを処理し,クラスタ・メンバシップ,マウントされたファイル・システムおよびデバイス接続性のような,一般的なクラスタとクラスタのファイル・システムの状態についての情報を監視します。

注意

cfsd は AdvFS ドメインを必要なエンティティとみなします。AdvFS ファイル・システムの再配置は,対象のファイル・システムばかりでなく同一ドメインのすべてのファイル・システムに影響を及ぼします。ドメイン全体が再配置されます。

NFS クライアントおよび MFS (メモリ・ファイル・システム) タイプのファイル・システムは再配置できません。さらに,メンバ・ブート・パーティション,サーバだけのファイル・システム (読み書きアクセス用にマウントされた UFS ファイルなど),HSM (hierarchical storage manager) で管理されるファイル・システムも,再配置できません。

共用バス上のダイレクト・アクセス入出力デバイスはバス上のすべてのクラスタ・メンバによって使用されます。共用バス上,またはクラスタ・メンバに直接接続された単一サーバ・デバイスは,単一メンバによって使用されます。2 つ以上のファイル・システムが同一の単一サーバ・デバイスを使用している場合,cfsd はファイル・システムが別のメンバによってサービスされるときに起こる性能上の理由から再配置しません。

9.3.3.1    cfsd の起動と停止

/sbin/init.d/cfsd ファイルは各クラスタ・メンバ上で cfsd デーモンのインスタンスを起動します。ただし,デーモンの起動では cfsd をアクティブにしません。cfsd デーモンの動作は,スタンザ・フォーマット・ファイル /etc/cfsd.confactive フィールドを介して制御されます。active フィールドに 1 が設定されると,cfsd をアクティブにします。

省略時の設定では cfsd デーモンは無効 (0 を設定) です。使用したい場合は,明示的に有効にする必要があります。

cfsd デーモンは,起動時にクラスタ単位の /etc/cfsd.conf ファイルを読み取ります。次のように,cfsd に SIGHUP シグナルを送って構成ファイルの再読み取りを強制的に行うことができます。

#  kill -HUP `cat /var/run/cfsd.pid`

/etc/cfsd.conf を変更する場合は,cfsd に SIGHUP シグナルを送って変更したファイルを再度読み取ります。クラスタ内の 1 つの cfsd デーモン・プロセスに SIGHUP を送信した場合,クラスタ内のすべての cfsd デーモンがこのファイルを再度読み取ります。複数の SIGHUP シグナルを送る必要はありません。

9.3.3.2    EVM イベント

cfsd デーモンは,最新の分析結果に有益な情報が含まれていることを警告するため,EVM の sys.unix.clu.cfsd.anlys.relocsuggested イベントをポストします。evmwatch コマンドと evmshow コマンドを使って,これらのイベントを監視します。

# evmget | evmshow -t "@name [@priority]" | grep cfsd
sys.unix.clu.cfsd.anlys.relocsuggested [200]
 

次のコマンドは,cfsd EVM イベントの追加情報を提供します。

# evmwatch  -i -f "[name sys.unix.clu.cfsd.*]" | evmshow -d | more
 

9.3.3.3    /etc/cfsd.conf 構成ファイルの変更

/etc/cfsd.conf 構成ファイルは ( cfsd.conf(4) で説明),cfsd の一般的なパラメータを指定し,cfsd がクラスタのファイル・システムを管理して分析する場合に従うファイル・システム配置ポリシのセットを定義します。クラスタ内のすべてのファイル・システムには,それらに関連付けられた配置ポリシがあります。このポリシでは,各ファイル・システムをメンバに割り当てる方法を指定し,必要であれば cfsd がファイル・システムを自動的に再配置するかどうかを決定します。

このファイルを変更する場合は,次の点に注意してください。

/etc/cfsd.conf ファイルの例を例 9-1 に示します。詳細については, cfsd.conf(4) を参照してください。

例 9-1:  /etc/cfsd.conf ファイル

# Use this file to configure the CFS load monitoring daemon (cfsd)
# for the cluster. cfsd will read this file at startup and on receipt
# of a SIGHUP. After modifying this file, you can apply your changes
# cluster-wide by issuing the following command from any cluster
# member: "kill -HUP `cat /var/run/cfsd.pid`". This will force the
# daemon on each cluster member to reconfigure itself. You only need
# to send one SIGHUP.
# 
# Any line whose first non-whitespace character is a '#' is ignored
# by cfsd.
# 
# If cfsd encounters syntax errors while processing this file, it will
# log the error and any associated diagnostic information to syslog.
#
# See cfsd(8) for more information.
 
# This block is used to configure certain daemon-wide features.
# 
# To enable cfsd, set the "active" attribute to "1".
# To disable cfsd, set the "active" attribute to "0".
# 
# Before enabling the daemon, you should review and understand the
# configuration in order to make sure that it is compatible with how
# you want cfsd to manage the cluster's file systems.
# 
# cfsd will analyze load every 12 hours, using the past 24 hours worth
# of statistical data.
# 
cfsd:
	active = 1
	reloc_on_memory_warning = 1
	reloc_stagger = 0
	analyze_samplesize = 24:00:00
	analyze_interval = 12:00:00
 
 
# This block is used to define the default policy for file systems that
# are not explicitly included in another policy. Furthermore, other
# policies that do not have a particular attribute explicitly defined
# inherit the corresponding value from this default policy.
# 
# Collect stats every 2 hours all day monday-friday.
# cfsd will perform auto relocations to maintain server preferences,
# connectivity, and acceptable memory usage, and will provide relocation
# hints to the kernel for preferred placement on failover.
# No node is preferred over another.
# 
defaultpolicy:
	polling_schedule = 1-5, 0-23, 02:00:00
	placement = favored
	hosting_members = *
	active_placement = connectivity, preference, memory, failover
 
# This policy is used for file systems that you do NOT want cfsd to
# ever relocate. It is recommended that cfsd not be allowed to relocate
# the /, /usr, or /var file systems.
# 
# It is also recommended that file systems whose placements are
# managed by other software, such as CAA, also be assigned to
# this policy.
# 
policy:
	name = PRECIOUS
	filesystems = cluster_root#, cluster_usr#, cluster_var#
	active_placement = 0 
 
 
# This policy is used for file systems that cfsd should, for the most
# part, ignore. File systems in this policy will not have statistics
# collected for them and will not be relocated.
# 
# Initially, this policy contains all NFS and MFS file systems that
# are not explicitly listed in other policies. File systems of these
# types tend to be temporary, so collecting stats for them is usually
# not beneficial. Also, CFS currently does not support the relocation
# of NFS and MFS file systems.
# 
policy:
	name = IGNORE
	filesystems = %nfs, %mfs
	polling_schedule = 0
	active_placement = 0
 
 
# Policy for boot file systems.
# 
# No stats collection for boot file systems.  Boot partitions are never
# relocated.
#
policy:
	name = BOOTFS
	filesystems = root1_domain#, root2_domain#, root3_domain#
	polling_schedule = 0
 
 
# You can define as many policies as necessary, using this policy block
# as a template. Any attributes that you leave commented out will be
# inherited from the default policy defined above.
# 
policy:
	name = POLICY01
	#filesystems =
	#polling_schedule = 0-6, 0-23, 00:15:00
        #placement = favored
	#hosting_members = *
	#active_placement = preference, connectivity, memory, failover
 

9.3.3.4    cfsd 分析の理解と実装に関する推奨事項

cfsd デーモンは,メンバ固有のファイル /var/cluster/cfs/stats.member に統計情報を収集します。これらのデータ・ファイルは,cfsd 固有のフォーマットであり,直接のユーザ・アクセスを意図していません。cfsd デーモンはこれらのファイルを更新し,維持します。定期的に削除したり,保存したりする必要はありません。

cfsd は,収集された統計情報を分析した後に,分析結果を /var/cluster/cfs/analysis.log ファイルに格納します。/var/cluster/cfs/analysis.log ファイルは,最新の /var/cluster/cfs/analysis.log.dated ファイルへのシンボリック・リンクです。/var/cluster/cfs/analysis.log.dated ファイルは 24 時間後に,新しいバージョンが作られてシンボリック・リンクが更新されます。古いバージョンの /var/cluster/cfs/analysis.log.dated ファイルは,削除されます。cfsd デーモンは,最新の分析結果に有益な情報が含まれていることを警告するため,EVM イベントをポストします。

/var/cluster/cfs/analysis.log ファイルは,通常のテキスト文で,次のような形式です。

Cluster Filesystem (CFS) Analysis Report
(generated by cfsd[525485]
 
Recommended
relocations:
 
none
 
Filesystem usage summary:
cluster         reads           writes          req'd svr mem
                24 KB/s         0 KB/s          4190 KB
 
 
node            reads           writes          req'd svr mem
 
rye             4 KB/s          0 KB/s          14 KB
swiss           19 KB/s         0 KB/s          4176 KB
 
filesystem    
    node        reads           writes          req'd svr mem
 
test_one#       2 KB/s          0 KB/s          622 KB
rye             0 KB/s          0 KB/s
@swiss          2 KB/s          0 KB/s
 
test_two#       4 KB/s          0 KB/s          2424 KB
rye             1 KB/s          0 KB/s
@swiss          3 KB/s          0 KB/s
:
:
Filesystem placement evaluation results:
 
filesystem    
node            conclusion      observations
test_one#
    rye         considered      (hi conn, hi pref, lo use) 
    @swiss      recommended     (hi conn, hi pref, hi use)
test_two#
    rye         considered      (hi conn, hi pref, lo use)
    @swiss      recommended     (hi conn, hi pref, hi use)
:
:
 

各ファイル・システムの現行の CFS サーバは,"at" シンボル (@)で示されます。前にも説明していますが,cfsd は,AdvFS ドメインを必要なエンティティとみなしており,分析は AdvFS ドメイン・レベルで報告されます。AdvFS タイプのファイル・システムの再配置は,同一ドメインのすべてのファイル・システムに影響を及ぼします。

この分析結果を使用して,ファイル・システムの CFS サーバを別のクラスタ・メンバにするのかどうかを判断できます。現行の CFS サーバが,cfsd の分析に基づき,このファイル・システムにとって推奨されるサーバでない場合,cfsmgr コマンドを使用して推奨されるサーバへファイル・システムを再配置することができます。

たとえば,swisstest_two ドメインの現行の CF サーバであり,rye が推奨される CFS サーバであると仮定します。この分析結果を受け入れて実装する場合は,次の cfsmgr コマンドを実行して,CFS サーバを rye に変更します。

# cfsmgr -a server=rye -d test_two
# cfsmgr -d test_two
 Domain or filesystem name = test_two
 Server Name = rye
 Server Status : OK

9.3.3.5    自動再配置

cfsd デーモは,独自の統計情報の分析だけに基づいて自動再配置を行いません。むしろ,レポートを生成し,ユーザ環境に応じて採用の判断が可能な推奨案を提供します。

ただし,条件を設定すると,cfsd はファイル・システム・ポリシの active_placement オプションで指定されたキーワードに基づいて,自動的にファイル・システムを再配置できます。active_placement キーワードでは,自動再配置を行うイベントを定義します。hosting_members オプションは,ファイル・システムを再配置するメンバとその優先順位を定義します。

active_placement オプションの動作と指定できる値については, cfsd.conf(4) に説明されています。 次にその概要を示します。

9.3.3.6    CAA リソースとの関連性

cfsd デーモンは,CAA リソースの情報を持ちません。CAA では,hosting_membersplacement_policyrequired_resources オプションを使って,特定の CAA リソースを実行できるメンバを優先的に指定したり,制限したりすることができます。

CAA リソースがアプリケーション固有のファイル・システムやリソース固有のファイル・システムを使う場合,関連する CAA 処理スクリプトを使って,ファイル・システムを配置したり再配置します。リソースが再配置された場合,処理スクリプトでも cfsmgr を使って,同様にファイル・システムを移動すべきです。処理スクリプトを通して cfsmgr コマンドを使うと,CAA リソースとファイル・システムを直接,容易に同期させられるようになります。

9.3.3.7    cfsd 以外での CFS の負荷分散

cfsd デーモンは,クラスタ上で CFS の負荷を分析し,分散させる推奨方法です。cfsd デーモンは,メンバとクラスタ・アクティビティを監視したり,そのレポートを作成したり,ファイル・システムに関連するメンバに応答したりします。ただし,既にファイル・システムの負荷を分散させる手段がある場合,または単に自分で負荷分散の分析を実行する場合には,当然そうすることもできます。

cfsmgr コマンドを使用して,CFS サーバの再配置に最適な候補を確定してください。cfsmgr コマンドでは,メンバ単位にファイル・システムの使用状況に関する統計情報が表示されます。たとえば,性能を改善するために /accounts のサーバを再配置した方がよいかどうかを判断したいとします。最初に,次のようにして /accounts の現在の CFS サーバを確認します。

# cfsmgr /accounts
 
 Domain or filesystem name = /accounts
 Server Name = systemb
 Server Status : OK
 

次に,現在のサーバと候補サーバの CFS 統計情報を得るために,次のコマンドを入力します。

# cfsmgr -h systemb -a statistics /accounts
 
 Counters for the filesystem /accounts:
        read_ops = 4149
        write_ops = 7572
        lookup_ops = 82563
        getattr_ops = 408165
        readlink_ops = 18221
        access_ops = 62178
        other_ops = 123112
 
 Server Status : OK
# cfsmgr -h systema -a statistics /accounts
 
 Counters for the filesystem /accounts:
        read_ops = 26836
        write_ops = 3773
        lookup_ops = 701764
        getattr_ops = 561806
        readlink_ops = 28712
        access_ops = 81173
        other_ops = 146263
 
 Server Status : OK
# cfsmgr -h systemc -a statistics /accounts
 
 Counters for the filesystem /accounts:
        read_ops = 18746
        write_ops = 13553
        lookup_ops = 475015
        getattr_ops = 280905
        readlink_ops = 24306
        access_ops = 84283
        other_ops =  103671
 
 Server Status : OK
# cfsmgr -h systemd -a statistics /accounts
 
 Counters for the filesystem /accounts:
        read_ops = 98468
        write_ops = 63773
        lookup_ops = 994437
        getattr_ops = 785618
        readlink_ops = 44324
        access_ops = 101821
        other_ops = 212331
 
 Server Status : OK
 

この例では,/accounts の読み取りと書き込みの動作の大半は systemd メンバからで,現在このファイル・システムに対するサービスを提供している systemb メンバからではありません。systemd/accounts のストレージに物理的に接続されているとすると,systemd/accounts の CFS サーバとして最適な選択肢となります。

systemd/accounts のストレージが物理的に接続されているかどうかを次のようにして判断してください。

  1. /accounts がマウントされている場所を調べてください。/etc/fstab を調べるか,または mount コマンドを使用できます。マウントされているファイル・システムが多数ある場合は,次のように grep を使用することをお勧めします。

    # mount | grep accounts
    accounts_dmn#accounts on /accounts type advfs (rw)
     
    

  2. AdvFS ドメイン accounts_dmn がマウントされているデバイスを確認するために,次のようにして /etc/fdmns/accounts_dmn ディレクトリを調べます。

    # ls /etc/fdmns/accounts_dmn
    dsk6c
     
    

  3. dsk6 のサーバを確認するために,次のように drdmgr コマンドを入力します。

    # drdmgr -a server dsk6
                       Device Name: dsk6
                       Device Type: Direct Access IO Disk
                     Device Status: OK
                 Number of Servers: 4
                       Server Name: membera
                      Server State: Server
                       Server Name: memberb
                      Server State: Server
                       Server Name: memberc
                      Server State: Server
                       Server Name: memberd
                      Server State: Server
     
    

    dsk6 に複数のサーバが存在するので,そのデバイスは共用バス上にあります。systemd がサーバの 1 つになっているので,物理的に接続されています。

  4. 次のように /accounts の CFS サーバを systemd に再配置します。

    # cfsmgr -a server=systemd /accounts
    

CFS 統計情報の示す負荷がそれほど不均衡になっていない場合でも,共用バスに接続されている利用可能なメンバ間で CFS サーバを分散するようお勧めします。そうすれば,クラスタの性能を全体的に向上できます。

9.3.3.8    cfsmgr による CFS サーバの負荷分散

特定のクラスタ・メンバを自動的にファイル・システムまたはドメインの CFS サーバとして機能させるには,cfsmgr コマンドを呼び出すスクリプトを /sbin/init.d に設定すれば,ファイル・システムまたはドメインのサーバを目的のクラスタ・メンバに再配置できます。この方法は CFS の負荷を分散させますが,平衡はとりません。

たとえば,クラスタ・メンバ alphaaccounting ドメインに対するサービスを提供したい場合は,起動スクリプトに次のように cfsmgr コマンドを設定してください。

# cfsmgr -a server=alpha -d accounting
 

そしてスクリプトを編集し,再配置が正常に終了したかどうかを確認して,再配置が失敗した場合は,処理を再試行させる必要があります。cfsmgr コマンドは,失敗した場合にゼロ以外の値を返しますが,この値では,不正な終了値でスクリプトを再試行するのに不十分です。フェイルオーバまたは再配置がすでに進行しているために,再配置に失敗したとも考えられます。

そのため,スクリプトでは,再配置に失敗した場合に,次の 2 つのメッセージを検索するようにします。

	Server Status : Failover/Relocation in Progress
 
	Server Status : Cluster is busy, try later
 

このどちらのメッセージが見つかっても再配置を再試行するようなスクリプトにします。その他のエラーの場合には,スクリプトが適切なメッセージを出力して終了するようにします。

9.3.4    mount -o コマンドによるファイル・システムの分散

共用 SCSI バス上のデバイスのファイル・システムは,その SCSI バスに直接接続されているメンバの 1 つによってサービスされます。クラスタのブート時,通常は,共用 SCSI バスに接続されている最初にアクティブにされるメンバが共用バス上のデバイスを最初に使うメンバとなります。このメンバが,その共用バス上のすべてのデバイスのすべてのファイル・システムの CFS サーバとなります。CFS では,ファイル・システムの負荷をよりよく分散するために,9.3.3 項で説明されているように,ファイル・システムの再配置を行うことができます。

もう 1 つの方法は,mount -o server=name コマンドを使用して,起動時にファイル・システムをどのクラスタ・メンバがサービスするかを指定することです。-o server=name オプションは,再配置ができない NFS,MFS,および読み取り/書き込み用 UFS ファイル・システムのようなファイル・システムには,特に有効です。

# mount -t nfs -o server=rye smooch:/usr /tmp/mytmp
# cfsmgr -e
Domain or filesystem name = smooch:/usr
Mounted On = /cluster/members/member1/tmp/mytmp
Server Name = ernest
Server Status : OK
 

mount -o server=name コマンドによってマウントが成功すると,指定したクラスタ・メンバがそのファイル・システムの CFS サーバになります。ただし,指定されたメンバがそのクラスタのメンバでないかファイル・システムをサービスできない場合,そのマウントの試みは失敗します。

mount -o server=name コマンドは,ファイル・システムを最初にどこにマウントするかを決定します。ファイル・システムを後で再配置したりフェイルオーバしたりするクラスタ・メンバの制限や定義は行いません。

-o server_only オプションと -o server=name を組み合わせると,ファイル・システムは指定されたクラスタ・メンバのみにマウントされ,パーティショニングされたファイル・システムとして扱われます。つまり,そのファイル・システムは,それをマウントしたメンバだけからは,読み取り専用アクセスも,読み取り書き込みアクセスも,どちらも可能です。他のクラスタ・メンバは,ファイル・システムからの読み取りも,ファイル・システムへの書き込みもできません。リモート・アクセスは許可されず,フェイルオーバは発生しません。-o server_only オプションは,AdvFS,MFS, および UFS ファイル・システムにだけ適用できます。

注意

-o server=name オプションは,通常のサーバ選択プロセスを介さないため,ファイル・システムのデバイスへの接続性が低いメンバになる可能性があります。さらに,指定したメンバが使用可能でない場合,ファイル・システムは他のクラスタ・メンバでもマウントできません。

-o server=name と -o server_only オプションの組み合わせでは,CFS ファイル・システムの多くの高可用性機能が使えません。ファイル・システムは,指定されたクラスタ・メンバにだけマウントでき,そのメンバだけがアクセスでき,また他のメンバにフェイルオーバすることはできません。したがって,この組み合わせを使用する際には,注意が必要です。

-o server=name オプションは,1 つのクラスタ内でだけ,かつ AdvFS,UFS,MFS,NFS,CDFS および DVDFS ファイル・システムだけで有効です。MFS ファイル・システムの場合,-o server=name オプションは,限定された方法でサポートされています。このファイル・システムは,指定されたサーバがローカル・ノードの場合だけマウントできます。

-o server=name オプションで /etc/fstab ファイルがあるメンバを指定すると,クラスタ・メンバ固有の fstab エントリを作成できます。

その他の使い方については, mount(8) を参照してください。

9.3.5    クローン作成前のデーモンのフリーズ

マルチボリューム・ドメイン構成で一貫性のあるハードウェアのスナップショットを可能にするため,ファイル・システムのメタデータは,それぞれのボリュームのクローンが作成されるとき,すべてのボリュームにわたって整合性がとれていなければなりません。メタデータの整合性を保つために,Tru64 UNIX バージョン 5.1B では freezefs コマンドが用意されました。このコマンドについては, freezefs(8) で説明されています。freezefs コマンドは AdvFS ドメインをメタデータの整合性がとれたフリーズ状態にし,指定されたフリーズ期限が切れるか,thawfs コマンドで明示的に解凍されるまで,その状態を継続することを保証します。複数ボリュームまたは論理単位 (LUN) に渡るすべてのメタデータは,ディスクにフラッシュされて,フリーズ期間中は変更されません。

freezefs によって,AdvFS ファイル・システムをマウントしたディレクトリをいくつか指定することが要求されますが,AdvFS ドメインのすべてのファイルセットに影響があります。freezefs コマンドは,AdvFS ドメインを必要不可欠なエンティティとみなしています。ドメインのファイル・システムをフリーズすることは,ドメイン全体をフリーズすることになります。

クラスタ構成でファイル・システムをフリーズする場合,その時実行中のすべてのファイル・システム操作は完了するまで実行を継続できます。メタデータの更新を必要としないいくつかのファイル・システム操作は,たとえ,ターゲット・ファイル・システムがフリーズされていても,通常通り動作します。たとえば,read および stat が該当します。

単一システムかクラスタかによって freezefs の機能の仕方に幾分違いがありますが,両方とも,フリーズされたドメイン上でのメタデータの変更は許されません。クラスタでのコマンドの動作で,最も注目される単一システムとの違いは,次のとおりです。

9.3.5.1    ドメインがフリーズされているかどうかの判断

省略時の設定では,freezefs はファイル・システムを 60 秒間フリーズします。ただし,-t オプションを使用して,さらに短い,またはより長いタイムアウト値を秒単位で指定したり,thawfs によって解凍されるまでドメインがフリーズ状態のままであることを指定したりすることができます。

freezefs コマンドの -q オプションを使って,ファイル・システムにフリーズ状態かどうかを問い合わせることができます。

# freezefs -q /mnt
/mnt is frozen
 

また,freezefs コマンドは,ファイル・システムがフリーズされるか解凍されるときに EVM イベントをポストします。evmwatch および evmshow コマンドを使用して,クラスタのドメインがフリーズさているか解凍されているかを判断します。次に例を示します。

# /usr/sbin/freezefs -t -1 /freezetest 
freezefs: Successful
 
# evmget -f "[name sys.unix.fs.vfs.freeze]" | evmshow -t "@timestamp @@"
14-Aug-2002 14:16:51 VFS: filesystem test2_domain#freeze  mounted on
/freezetest was frozen
 
# /usr/sbin/thawfs /freezetest
thawfs: Successful
 
# evmget -f "[name sys.unix.fs.vfs.thaw]" | evmshow -t "@timestamp @@"
14-Aug-2002 14:17:32 VFS: filesystem test2_domain#freeze mounted on
/freezetest was thawed
 

9.3.6    CFS 性能の最適化

CFS 性能を次に示す事項で調整できます。

9.3.6.1    先読みおよび後書きスレッド数の変更

CFS は,ファイルの順次アクセスを検出すると,先読みスレッドを使用して,データの次の入出力ブロック・サイズ分を読み取ります。また,CFS は後書きスレッドを使用して,ディスクの書き込みが予想される次のデータ・ブロックをバッファに入れます。cfs_async_biod_threads カーネル属性を使用して,非同期先読みと後書きを実行する入出力スレッド数を設定してください。先読みおよび後書きスレッドは,CFS クライアントから行われる読み取りと書き込みのみに適用されます。

cfs_async_biod_threads の省略時のサイズは 32 です。一度に 32 を超える数の大規模なファイルを順次にアクセスするような環境では,cfs_async_biod_threads を大きくすると,特にそれらのファイルを使用するアプリケーションで待ち時間が短縮される可能性がある場合は,CFS の性能を改善できます。

先読みスレッドおよび後書きスレッドの数は,0 〜 128 の範囲で調整できます。使用中以外は,スレッドはシステム・リソースをほとんど消費しません。

9.3.6.2    直接入出力の利用

アプリケーションで open システム・コールにフラグ O_DIRECTIO を指定して AdvFS ファイルをオープンした場合,データ入出力はストレージを対象とします。システム・ソフトウェアは,ファイル・システム・レベルでファイルのデータ・キャッシングを行いません。クラスタでは,クラスタのメンバからのファイルへの同時直接入出力が可能です。つまり,どのメンバの要求でもファイルへの入出力は CFS サーバへのクラスタ・インターコネクトを介して行われません。データベース・アプリケーションでは,raw 非同期入出力 (クラスタでもサポート) と合わせて頻繁に直接入出力を行って,入出力性能を向上させます。

直接入出力用にオープンされたファイル上で最高の性能を引き出すには,次のような条件があります。

次の条件により,直接入出力性能が低くなります。

直接入出力を使用するアプリケーションは,それ自身のキャッシングを管理する責任があります。1 つのクラスタ・メンバまたは複数のメンバ上でマルチスレッドの直接入出力を実行する場合は,アプリケーションで,どの場合もセクタの読み取りまたは書き込みが確実に単一のスレッドのみで行われるように同期をとる必要があります。

直接入出力プログラミングについては,Tru64 UNIX 『プログラミング・ガイド』 の最適化技術の章を参照してください。

9.3.6.2.1    クラスタとスタンドアロン AdvFS 直接入出力の違い

スタンドアロン・システムと異なるクラスタ上の直接入出力の動作を次に示します。

9.3.6.2.2    直接入出力モードでオープンしたファイルを持つファイルセットのクローンを作成する

9.3.6.2 項で説明したように,アプリケーションが open システム・コールで O_DIRECTIO フラグを立ててファイルをオープンした場合,そのファイルの入出力は,CFS サーバとの間にあるクラスタ・インターコネクトを経由しません。ただし,直接入出力モードでオープンしたファイルを持つファイルセットのクローンを作成すると,入出力がこのモデルに従わないので,性能がかなり低下するおそれがあります (読み取り性能は,このクローン作成から影響を受けません)。

clonefset(8) で説明されている clonefset ユーティリティは,クローン・ファイルセットという AdvFS ファイルセットの読み取り専用コピーを作成します。クローン・ファイルセットは,ファイルセット・データ構造 (メタデータ) の読み取り専用のスナップショットです。つまり,ファイルセットのクローンを作成すると,このユーティリティは元になるファイルセットの構造のみをコピーし,データはコピーしません。元になっているファイルセットのファイルを変更すると,その書き込みのたびに,元になるデータがまだコピーされていないかどうかがチェックされ,コピーされていなければ,データの書き込みに同期してクローンにもコピーされます。このようにして,クローン・ファイルセットの内容は,最初に作成したときのように元データと同じ内容になるよう維持されます。

直接入出力モードでオープンしたファイルがそのファイルセットにある場合にファイルを変更すると,AdvFS は元データをクローンのストレージにコピーします。AdvFS はこのコピー操作をクラスタ・インターコネクトを経由して送りません。しかし,CFS は,直接入出力モードを使用するアプリケーションが自分と同じノードで動作している場合を除き,ファイルセット内のデータの変更に伴う書き込み操作を,クラスタ・インターコネクトを経由して CFS サーバへ送ります。書き込み操作をクラスタ・インターコネクトを経由して送ると,直接入出力モードでファイルをオープンする利点がなくなってしまいます。

直接入出力モードの利点を活かすためには,バックアップが完了した時点ですぐにクローンを削除し,次の書き込みもストレージに直接書き込まれるようにします。そうすれば,書き込みはクラスタ・インターコネクトを経由して送られません。

9.3.6.2.3    直接入出力に関する統計情報の収集

直接入出力を使うアプリケーションの性能向上が期待より低い場合は,コマンド cfsstat を使ってノードごとにグローバルな直接入出力の統計情報を調べます。

最初に cfsstat を使用して,アプリケーションを実行せずにグローバルな直接入出力の統計情報を調べます。次に,アプリケーションを実行して統計情報を再度確認し,直接入出力の動作を最適化しないパスがあるかどうかを調べます。

次の例は,コマンド cfsstat を使って直接入出力の統計情報を取得する方法を示します。

# cfsstat directio
Concurrent Directio Stats:
     160 direct i/o reads
     160 direct i/o writes
       0 aio raw reads
       0 aio raw writes
       0 unaligned block reads
       0 fragment reads
       0 zero-fill (hole) reads
     160 file-extending writes
       0 unaligned block  writes
       0 hole writes
       0 fragment writes
       0 truncates
 

個々の統計情報には次の意味があります。

9.3.6.3    CFS メモリ使用量の調整

1 つのクラスタ・メンバが多数のファイル・システムに対する CFS サーバになっている場合には,そのクライアント・メンバでは,サービスが提供されるファイル・システムから莫大な数の vnode がキャッシュに書き込まれる可能性があります。vnode が積極的に使用されなくても,クライアントのキャッシュに書き込まれた vnode ごとに,CFS サーバでは,CFS 層でのファイルの記録に必要な CFS トークン構造体用に 800 バイトのシステム・メモリを割り当てなければなりません。このほかに,一般に CFS トークン構造体には,対応する AdvFS アクセス構造体と vnode が必要なため,ほぼ 2 倍のメモリ容量が使用されます。

省略時には,各クライアントでは,メモリの最大 4 パーセントを vnode のキャッシュに使用できます。複数のクライアントのキャッシュが CFS サーバからの vnode で限界に達すると,サーバ上のシステム・メモリが不足して,システムがハングするおそれがあります。

svrcfstok_max_percent カーネル属性は,そのようなシステム・ハングを防止するように設計されています。この属性を使用して,CFS サーバに割り当てられるメモリ容量の上限を設定し,クライアント上の vnode キャッシングを管理します。省略時の値は 25 パーセントです。メモリが使用されるのは,サーバの負荷のためにメモリが必要になった場合に限ります。事前にメモリが割り当てられることはありません。

サーバ上の svrcfstok_max_percent の制限に達した後,メンバによって管理されるファイルにアクセスするアプリケーションは,EMFILE エラーになります。perror() を使用して 現在の errno 設定を確認するアプリケーションは,アプリケーションで使用される標準エラー・ストリーム stderr,制御 TTY またはログ・ファイルに対して too many open files というメッセージを返します。EMFILE エラー・メッセージを調べても,キャッシュに書き込まれたデータは失われません。

アプリケーションで EMFILE エラーの取得を開始する場合は,以下の手順に従ってください。

  1. CFS クライアントが vnode の範囲外かどうかを次のように判断します。

    1. max_vnodes カーネル属性の現在の値を取得します。

      # sysconfig -q vfs max_vnodes
      

    2. dbx を使用して total_vnodesfree_vnodes の値を取得します。

      # dbx -k /vmunix /dev/mem
      dbx version 5.0
      Type 'help' for help.
      (dbx) pd total_vnodes
      total_vnodes_value
       
      

      max_vnodes の値を取得します。

      (dbx) pd max_vnodes
      max_vnodes_value
       
      

      total_vnodesmax_vnodes と等しく,free_vnodes が 0 の場合,そのメンバは vnode の範囲外です。このような場合には,max_vnodes カーネル属性の値を増やすことができます。sysconfig を使用すれば,動作中のメンバの max_vnodes を変更できます。たとえば,vnode の最大数を 20000 に設定するには,次のように入力します。

      # sysconfig -r vfs max_vnodes=20000
      

  2. CFS クライアントが vnode の範囲外でない場合は,CFS サーバでトークン構造体 (svrcfstok_max_percent) に利用可能なメモリすべてが使用されたかどうかを次のように調べてください。

    1. CFS サーバにログインします。

    2. dbx を使用して,svrtok_active_svrcfstok の現在の値を取得します。

      # dbx -k /vmunix /dev/mem
      dbx version 5.0
      Type 'help' for help.
      (dbx)pd svrtok_active_svrcfstok
      active_svrcfstok_value
       
      

    3. cfs_max_svrcfstok の値を取得します。

      (dbx)pd cfs_max_svrcfstok
      max_svrcfstok_value
       
      

    svrtok_active_svrcfstokcfs_max_svrcfstok 以上になっている場合は,CFS サーバでトークン構造体に利用可能なメモリすべてが使用されています。

    このような場合に,ファイル・システムを再び使用できるようにする理想的な解決策は,ファイル・システムの一部を他のクラスタ・メンバに再配置することです。それが無理な場合は,以下のような解決策が適しています。

一般に,CFS サーバが svrcfstok_max_percent の制限に達した場合は,ファイル・システムのサービス提供の負荷がクラスタ・メンバに分散されるように,CFS ファイル・システムの一部を再配置します。起動スクリプトを使用すれば,cfsmgr を実行して,メンバの起動時にファイル・システムをクラスタのあちこちに自動的に再配置できます。

svrcfstok_max_percent を省略時の値より小さく設定する方法を推奨できるのは,省略時の値の 25 パーセントでも大きすぎてメモリ不足になるような小容量のメモリのシステムに限ります。

9.3.6.4    メモリ・マップ・ファイルの使用

クラスタ単位で読み取り専用アクセス以外にメモリを共用するためにメモリ・マッピングを行うと,性能が低下する可能性があります。複数のメンバが同時にデータを変更しているときには,ファイルへの CFS I/O はうまく動作しません。この状況では,全ノードでいつでも同じデータをアクセスするように,早期キャッシュ・フラッシュが必要となります。

9.3.6.5    フル・ファイル・システムの回避

ファイル・システムの空きスペースが 50 MB 未満の場合,または空きスペースがファイル・システムのサイズの 10 パーセント未満の場合 (どちらが少ない場合であっても),CFS クライアントからのファイル・システムへの書き込み性能に問題が生じます。これは,フル・ファイル・システムに近い状態でのすべての書き込みが,正常な ENOSPC ("not enough space: 十分な容量がない") の処理を行えるように即座にサーバへ送信されるためです。

9.3.6.6    その他の方法

次のような方法で CFS の性能を改善できます。

9.3.7    MFS および UFS ファイル・システムのサポート

TruCluster Server では,MFS (メモリ・ファイル・システム) と UFS (UNIX ファイル・システム) に対する読み取り/書き込みをサポートしています。

クラスタ内で UFS ファイル・システムを読み取り/書き込みアクセスでマウントする場合と,クラスタ内で MFS ファイル・システムを読み取り専用または読み取り/書き込みアクセスでマウントする場合は,特に指定しなくても mount コマンドで server_only 引数が使用されます。これらのファイル・システムは,9.3.8 項で説明するように,パーティショニングされたファイル・システムとして扱われます。つまり,これらのファイル・システムは,それをマウントしたメンバであれば,読み取り専用または読み取り/書き込みアクセスのいずれでもアクセスすることができます。他のクラスタ・メンバは,MFS または UFS ファイル・システムのいずれに対しても書き込みだけでなく読み取りもできません。リモート・アクセスは許可されず,フェイルオーバはできません。

すべてのクラスタ・メンバに対して読み取り専用で UFS ファイル・システムをマウントするには,明示的に読み取り専用でマウントしなければなりません。

9.3.8    ファイル・システムのパーティショニング

CFS はすべてのファイルをすべてのクラスタ・メンバに対してアクセス可能にします。全クラスタ・メンバに接続された装置または単一メンバにプライベートな装置にファイルが格納されているかどうかにかかわらず,各クラスタ・メンバはファイルを同様にアクセスできます。ただし,CFS は AdvFS ファイル・システムのマウントを可能にして,単一クラスタ・メンバのみがアクセスできるようにします。このことをファイル・システムのパーティショニングといいます。

TruCluster Server 製品の初期のバージョンである ASE (Available Server Environment) では,ファイル・システムのパーティショニングのような機能を提供していました。TruCluster Server バージョン 5.1 ではファイルのパーティショニング機能が用意され,ASE から簡単に移植できます。TruCluster Server のファイル・システムのパーティショニングは,ファイル・システムのアクセスを単一メンバに制限するための汎用的な手段としては提供されていません。

パーティショニングされたファイル・システムをマウントするには,ファイル・システムへの排他的アクセスを持つメンバにログオンします。コマンド mount をオプション server_only を使って実行します。これで,コマンド mount を実行するメンバ上でファイル・システムがマウントされ,そのメンバにファイル・システムへの排他的アクセスが与えられます。マウントしたメンバのみがファイル・システムへのアクセス権を持っていても,すべてのメンバがクラスタ単位でファイル・システムをマウントすることができます。

オプション server_only は AdvFS,MFS,および UFS ファイル・システムのみに適用できます。

パーティショニングされたファイル・システムには次のような制限があります。

9.3.9    ブロック・デバイスとキャッシュの整合性

単一のブロック・デバイスには,複数の別名を設定できます。この場合には,ファイル・システムのネームスペースにおける複数のブロック・デバイス・スペシャル・ファイルに同じ dev_t が含まれます。このような別名は,ネームスペース内の複数のドメインまたはファイル・システムの至るところで見つかる可能性があります。

スタンドアロン・システムでは,キャッシュの整合性は,もとになる共通のブロック・デバイスの open() 呼び出しに使用された別名にかかわらず,オープンしたブロック・デバイスすべての間で保証されます。ただし,クラスタでキャッシュの整合性が得られるのは,すべてのブロック・デバイス・ファイルの別名が同じドメインまたはファイル・システム上に存在する場合に限られます。

たとえば,クラスタ・メンバ mutt がブロック・デバイスを備えたドメインを提供し,メンバ jeff が同じ dev_t で別のブロック・デバイス・ファイルを備えたドメインを提供する場合,この 2 つの別名で同時に入出力が実行されれば,キャッシュの整合性は得られません。

9.3.10    CFS の制限

クラスタ・ファイル・システム (CFS) は,ネットワーク・ファイル・システム (NFS) クライアントを読み取り/書き込みアクセスでサポートします。

ファイル・システムをクラスタで NFS マウントした場合,CFS はすべてのクラスタ・メンバで読み取り/書き込みアクセスを可能にします。実際にマウントしたメンバが,他のクラスタ・メンバにファイル・システムを提供します。

NFS ファイル・システムをマウントしたメンバが,シャットダウンするか,または障害が発生すると,ファイル・システムは自動的にアンマウントされ,CFS はマウント・ポイントのクリーンアップを開始します。クリーンアップ処理の間,これらのマウント・ポイントにアクセスするメンバはクリーンアップの進展の度合いに応じてさまざまな状態になります。

CFS クリーンアップが完了するまでの間,メンバは NFS ファイル・システムのローカル・マウント・ポイント(または,マウント・ポイントの下にローカルに作られたディレクトリ)で,新しいファイルを作成することができます。

NFS ファイル・システムは自動的に別のメンバにフェイルオーバしません。手動でファイル・システムをマウントして -- 同じマウント・ポイントまたは別のマウント・ポイント -- 他のクラスタのメンバから再びアクセスできるようにする必要があります。もう 1 つの方法は,クラスタ・メンバをブートして /etc/fstab ファイルにリストされたファイル・システムをマウントすることです。そのリスト上のファイル・システムは,現在マウントされていなく,クラスタ内でサービスされていないファイル・システムです (AutoFS または automount を使用している場合,マウントは自動的に行われます)。

9.4    デバイス要求ディスパッチャの管理

デバイス要求ディスパッチャ・サブシステムは,クラスタ内の物理的なストレージの位置に関係なく,すべてのクラスタ・メンバが物理的なディスク・ストレージとテープ・ストレージを透過的に利用できるようにします。アプリケーションがファイルへのアクセスを要求すると,CFS から AdvFS に要求が渡され,そこからデバイス要求ディスパッチャに渡されます。ファイル・システム階層においては,デバイス要求ディスパッチャは,デバイス・ドライバの真上になります。

デバイス要求ディスパッチャの管理用の基本ツールは drdmgr コマンドです。このコマンドの使用例については,この節で説明しています。詳細は, drdmgr(8) を参照してください。

9.4.1    ダイレクト・アクセス入出力と単一サーバ・デバイス

デバイス要求ディスパッチャはクライアント/サーバ・モデルに従います。つまり,メンバがディスク,テープ,CD-ROM ドライブなどのデバイスに対するサービスを提供します。

クラスタ内のデバイスは,ダイレクト・アクセス入出力デバイスまたは単一サーバ・デバイスのどちらかです。ダイレクト・アクセス入出力デバイスには,複数のクラスタ・メンバから同時にアクセスできます。単一サーバ・デバイスには,単一メンバのみからアクセスできます。

共用バス上のダイレクト・アクセス入出力デバイスは,そのバスのすべてのクラスタ・メンバによってサービスが提供されます。共用バス上か,クラスタ・メンバに直接接続されているかにかかわらず,単一サーバ・デバイスは単一のメンバによってサービスが提供されます。他のすべてのメンバは,サービスを提供しているメンバを介してサービス対象のデバイスにアクセスします。ダイレクト・アクセス入出力デバイスは,デバイス要求ディスパッチャ・サブシステムの一部であり,CFS で処理される直接入出力 (open システム・コールに O_DIRECTIO フラグを指定したファイルのオープン) とは関係がありません。直接入出力と CFS についての詳しい説明は,9.3.6.2 項を参照してください。

通常,共用バス上のディスクはダイレクト・アクセス入出力デバイスですが,場合によっては,共用バス上の一部のディスクが単一サーバ・デバイスになることがあります。このような例外が発生するのは,設定済みのクラスタに RZ26,RZ28,RZ29,RZ1CB-CA のディスクのうちいずれか 1 つを追加する場合です。最初は,こうしたデバイスは単一サーバ・デバイスです。詳細は,9.4.1.1 項を参照してください。テープ・デバイスは,常に単一サーバ・デバイスです。

共用バス上の単一サーバ・ディスクはサポートされますが,メンバのブート・ディスクまたはスワップ・ファイルとして,あるいはコア・ダンプの取得に使用するにはきわめて低速です。したがって,このような場合にはダイレクト・アクセス入出力ディスクを使用することをお勧めします。

図 9-3 は,共用バス上に 5 台のディスクと 1 台のテープ・ドライブを備えた 4 ノード・クラスタを示しています。systemd は共用バスに接続されていないことに注意してください。このノードからクラスタ・ストレージへのアクセスは,クラスタ・インターコネクトを介して行われます。

図 9-3:  4 ノード・クラスタ

共用バス上のディスクは,バスのすべてのクラスタ・メンバによってサービスが提供されます。これを確認するには,次のようにして dsk3 のデバイス要求ディスパッチャ・サーバを検索してください。

# drdmgr -a server dsk3
                   Device Name: dsk3
                   Device Type: Direct Access IO Disk
                 Device Status: OK
             Number of Servers: 3
                   Server Name: systema
                  Server State: Server
                   Server Name: systemb
                  Server State: Server
                   Server Name: systemc
                  Server State: Server
 

dsk3 は共用バス上のダイレクト・アクセス入出力デバイスなので,バス上の 3 つのシステムすべてがそのディスクに対するサービスを提供します。共用バス上の任意のメンバがディスクにアクセスする場合は,そのメンバから直接デバイスにアクセスします。

プライベート・バス上のディスクは,接続元のローカル・システムによってサービスが提供されます。たとえば,次に示すように,dsk7 のサーバは systemb です。

# drdmgr -a server dsk7
                   Device Name: dsk7
                   Device Type: Direct Access IO Disk
                 Device Status: OK
             Number of Servers: 1
                   Server Name: systemb
                  Server State: Server
 

テープ・ドライブは,常に単一サーバ・デバイスです。tape0 は共用バス上にあるので,そのバス上のどのメンバもテープ・ドライブのサーバとして機能できます。クラスタの起動時には,テープ・ドライブにアクセスする最初のアクティブ・メンバが,テープ・ドライブのサーバになります。

ディスクに付けられた番号は,クラスタのブート時に systema が最初に起動したことを示します。このサーバでは,最初にプライベート・ディスクを検出してそのディスクにラベルが設定され,次に,共用バスのディスクを検出してそのディスクにラベルが設定されます。systema は最初に起動したので,tape0 のサーバにもなります。これを確認するには,次のコマンドを入力してください。

# drdmgr -a server tape0
                   Device Name: tape0
                   Device Type: Served Tape
                 Device Status: OK
             Number of Servers: 1
                   Server Name: systema
                  Server State: Server
 

tape0 のサーバを systemc に変更するには,drdmgr コマンドを次のように入力してください。

# drdmgr -a server=systemc /dev/tape/tape0
 

単一サーバ・デバイスの場合は,サービスを提供しているメンバがアクセス・ノードにもなります。次のコマンドでこれを確認してください。

# drdmgr -a accessnode tape0
                   Device Name: tape0
              Access Node Name: systemc
 

指定したデバイスに対する,デバイス要求ディスパッチャの SERVER 属性はすべてのクラスタ・メンバで同じですが,ACCESSNODE 属性の値はクラスタ・メンバに固有です。

共用バス上のシステムは,常に同じ共用バス上のダイレクト・アクセス入出力デバイスに対する固有のアクセス・ノードになります。

systemd には共用バスが接続されていないので,共用バス上のダイレクト・アクセス入出力デバイスごとに,デバイスへのアクセス時に systemd が利用するアクセス・ノードを指定できます。アクセス・ノードは,共用バス上のいずれかのメンバでなければなりません。

次のコマンドを実行すると,systemc が,systemddsk3 の間のあらゆるデバイス要求ディスパッチャの処理を引き受けるようになります。

# drdmgr -h systemd -a accessnode=systemc dsk3
 

9.4.1.1    ダイレクト・アクセス入出力をサポートするデバイス

RAID 対応のディスクはダイレクト・アクセス入出力機能を備えています。RAID (Redundant Array of Independent Disks) コントローラの一部を,以下に示します。

clu_create または clu_add_member のコマンドによってシステムがクラスタ・メンバになる時点ですでに設置されている RZ26,RZ28,RZ29,および RZ1CB-CA のディスクは,ダイレクト・アクセス入出力ディスクとして自動的に使用可能になります。これらのディスクのうちいずれか 1 つを後からダイレクト・アクセス入出力ディスクとして追加するには,9.2.3 項の手順を使用しなければなりません。

9.4.1.2    ダイレクト・アクセス入出力ディスクとしての RZ26,RZ28,RZ29,RZ1CB-CA のうちいずれか 1 つの交換

RZ26,RZ28,RZ29,RZ1CB-CA のうちいずれか 1 つのダイレクト・アクセス入出力ディスクを同じタイプのディスクと交換 (たとえば,RZ28-VA を別の RZ28-VA に交換) する場合は,次の手順を実行して,新しいディスクをダイレクト・アクセス入出力ディスクにしてください。

  1. ディスクをバスに物理的に接続します。

  2. 次のように hwmgr コマンドを使用して新しいディスクを走査します。

    # hwmgr -scan comp -cat scsi_bus
    

    走査が完了するまで 1,2 分かかります。

  3. 交換した旧ディスクと同じデバイス名を新規ディスクに付ける場合は,hwmgr -redirect scsi コマンドを実行します。詳細は, hwmgr(8) および Tru64 UNIX 『ハードウェア管理ガイド』 の「障害の発生した SCSI デバイスの交換」の項を参照してください。

  4. 各クラスタ・メンバで,次のように clu_disk_install コマンドを入力します。

    # clu_disk_install
    

注意

クラスタに多数のストレージ・デバイスが存在する場合は,コマンド clu_disk_install の完了まで数分かかる場合があります。

9.4.1.3    共用バス上の HSZ ハードウェアのサポート

共用バス上でサポートされているハードウェアの一覧については,TruCluster Server バージョン 5.1B『QuickSpecs』を参照してください。

共用バス上で適切なファームウェア・リビジョンを持たない HSZ を使用した場合は,HSZ に対して同時に複数のアクセスが発生すると,クラスタがハングするおそれがあります。

9.5    クラスタでの AdvFS の管理

クラスタでの AdvFS (Advanced file system) は,大部分がスタンドアロン・システムと同様の特徴を示します。ただし,この節で次のようなクラスタ固有のいくつかの注意事項を説明します。

9.5.1    新たに追加されたメンバからの AdvFS ファイルの統合

新規メンバをクラスタに追加しますが,その新規メンバには,スタンドアロン・システムとして稼働していたときから AdvFS ボリュームとファイルセットが用意されているとします。このようなボリュームとファイルセットをクラスタに統合するには,次の操作を行う必要があります。

  1. クラスタに統合したい domains#filesets を列挙している /etc/fstab ファイルを変更します。

  2. 新規ドメインをクラスタに登録するために,ドメイン情報を手動で /etc/fdmns に入力するか,または advscan コマンドを実行します。

advscan コマンドについては, advscan(8) を参照してください。/etc/fdmns の再構築の例は,Tru64 UNIX 『AdvFS 管理ガイド』の AdvFS ファイル・システムのリストアに関する節を参照してください。

9.5.2    クラスタ・ルート・ドメインにファイルセットを 1 つだけ作成する

ルート・ドメインである cluster_root には,ファイルセットが 1 つだけ必要です。cluster_root にファイルセットを 2 つ以上作成すると (作成自体は可能),cluster_root ドメインにフェイルオーバが必要となった場合にパニックが発生することがあります。

このような状況が発生する例として,クローン・ファイルセットをとりあげます。 advfs(4) で説明されているように,クローン・ファイルセットは既存のファイルセットを読み取り専用でコピーしたものであり,他のファイルセットと同じようにマウントできます。クラスタ単位のルート (/) のクローンを作成してマウントすると,そのクローン・ファイルセットが cluster_root ドメインに追加されます。クローン・ファイルセットがマウントされている間に cluster_root ドメインにフェイルオーバの必要が生じると,クラスタはパニックに陥ります。

注意

クローン・ファイルセットからクラスタ単位のルートのバックアップを作成する場合は,クローンのマウント時間をできるだけ短くしてください。できるだけ速く,クローン・ファイルセットをマウントし,バックアップを実行して,クローンをアンマウントしてください。

9.5.3    メンバのブート・パーティションへファイルセットを追加する (非推奨)

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

9.5.4    メンバのルート・ドメインへボリュームを追加しない

addvol コマンドを使用してメンバのルート・ドメイン (rootmemberID_domain#root) にボリュームを追加することはできません。追加したい場合は,まずクラスタからメンバを削除し,次に diskconfig または SysMan を用いて適切にディスクを構成したのちに,そのメンバをクラスタに追加するかたちで戻さなければなりません。メンバのブート・ディスクを構成する場合の要件については,『クラスタ・インストレーション・ガイド』 を参照してください。

9.5.5    クラスタでの addvol コマンドと rmvol コマンドの使用

AdvFS ドメインがローカル・メンバ上またはリモート・メンバ上にマウントされているかどうかにかかわらず,任意のクラスタ・メンバからそのドメインを管理できます。ただし,管理対象ドメインの CFS サーバでないメンバから addvol コマンドまたは rmvol コマンドを使用する場合,コマンドは,rsh を利用してドメインの CFS サーバになっているメンバ上でリモートに実行されます。これにより,次のような結果になります。

コマンドが実行されたメンバがドメインのサーバでない場合,rmvol および addvol コマンドは rsh を使用します。rsh が機能するためには,省略時のクラスタ別名が /.rhosts ファイルに登録されていなければなりません。/.rhosts のクラスタ別名のエントリは,完全に修飾されたホスト名または修飾されていないホスト名の形式をとります。ホスト名の代わりに,すべてのホストのアクセスを許可する正符合 (+) を指定することもできますが,セキュリティ上の理由からお勧めしません。

clu_create コマンドは,クラスタ別名を自動的に /.rhosts に登録して,ユーザが介入しなくても rsh が動作するようにします。rsh が失敗したために,rmvol または addvol コマンドが失敗した場合には,次のメッセージが返されます。

rsh failure, check that the /.rhosts file allows cluster alias access.

9.5.6    ユーザとグループのファイル・システムに対するクォータのサポート

TruCluster Server では,クォータをサポートしています。この機能を使用することにより,ユーザやグループに代わって,AdvFS ファイル・システムに置けるファイルの数と使用できるディスク・スペースの総量の両方を制限できます。

TruCluster Server 環境でサポートしているクォータは,Tru64 UNIX システムでサポートしているクォータと似ていますが,次の点が異なります。

ここでは,TruCluster Server 環境で行うディスク・クォータ管理に特有な事項を説明します。クォータ管理についての一般的な説明は,Tru64 UNIX 『システム管理ガイド』 を参照してください。

9.5.6.1    クォータのハード限界値

Tru64 UNIX システムでは,それぞれのユーザまたはグループがファイル・システムに置けるファイルの数や使用できるディスクのスペースは,ハード限界値によってその絶対的な上限が制限されます。ハード限界値に達すると,ディスク・スペースの割り当てやファイルの作成ができなくなります。ハード限界値を超えるようなシステム・コールは,クォータ違反となって失敗します。

TruCluster Server 環境でも,スタンドアロンの Tru64 UNIX システムと同じように,ファイル数のハード限界値が強制されます。

ただし,ディスク・スペース全体に対するハード限界値は,それほど厳密には適用されません。CFS では,性能上の理由から,クライアント・ノードでユーザまたはグループのデータをそのデータを提供するメンバと連絡することなく,ある程度キャッシュに置けるようになっています。その量は構成できます。そのため,あるクライアント・ノードで書き込み操作を行ったときに,そのデータがキャッシュに書き込まれるだけでサーバのディスクに書き込まれない状況が発生しますが,CFS は,そのノードに障害が発生した場合を除いて,そのデータが最終的にサーバのディスクに書き込まれることを保証します。

キャッシュされているデータの書き込みは,ディスク・クォータの強制より優先します。つまり,クォータ違反が発生しても,キャッシュ内のデータは違反を無視してディスクに書き込まれます。その後にこのグループまたはユーザが書き込みを行っても,クォータ違反が修正されるまでキャッシュされません。

クォータ違反が発生している間はデータがキャッシュに追加されないので,全クラスタ・メンバの quota_excess_blocks を総計した値以上にハード限界値を超えることはありません。したがって,ユーザまたはグループに対する実際のディスク・スペース・クォータは,ハード限界値に全クラスタ・メンバの quota_excess_blocks を足した値になります。

ユーザまたはグループごとにキャッシュできるデータ量は,各メンバの etc/sysconfigtab ファイルにある quota_excess_blocks の値で決まります。quota_excess_blocks の値は 1024 バイトのブロックを 1 単位として表します。省略時の値は 1024 で,1 MB のディスク・スペースです。quota_excess_blocks の値は,クラスタ・メンバごとに異なっていてもかまいません。データのほとんどが置かれるクラスタ・メンバでは quota_excess_blocks の値を大きくし,その他のクラスタ・メンバには省略時の quota_excess_blocks の値を使用することもできます。

9.5.6.2    quota_excess_blocks の値の設定

quota_excess_blocks の値は,/etc/sysconfigtab ファイルの cfs スタンザに記述されています。

このファイルは,手動で変更しないでください。変更は,sysconfigdb コマンドで行ってください。このユーティリティは,自動的にすべての変更をカーネルが使用できるようにするとともに,ファイルの構造を保存して,将来アップグレードしたときに正しく組み込めるようにします。

ユーザまたはグループによっては,性能が quota_excess_blocks の影響を受けることがあります。この値を低くしすぎると,CFS はキャッシュを有効に使えません。quota_excess_blocks の値を 64K より小さくすると,性能に大きく影響します。逆に,quota_excess_blocks を高く設定しすぎると,ユーザまたはグループが消費するディスク・スペースの割合が増加します。

quota_excess_blocks の値としては,省略時の 1 MB を使用するか,潜在的な上限値がディスク・ブロックの利用に与える影響を考慮して,妥当と思われる分だけ増やすことをお勧めします。設定する値を決める際は,最悪の上限値を考慮してください。最悪の上限値は次の式で求まります。

(admin の指定するハード上限値) + 
  (各クライアント・ノードの quota_excess_blocks の合計)  
 

CFS はできる限りの処理を行って,ハード・クォータ限界値を超えないようにしています。したがって,最悪の上限に到達することはほとんどありません。

9.5.7    ストレージの接続性と AdvFS ボリューム

フェイルオーバ機能が要求される場合は,AdvFS ドメイン内のすべてのボリュームが同じ接続性を備えていなければなりません。次の条件のどちらかに当てはまる場合は,ボリュームの接続性が同じです。

drdmgr および hwmgr コマンドを使用すれば,システムとディスクのサービスの関係がわかります。動作中のメンバ,バス,ストレージ・デバイス,およびそれらの接続をはじめとするクラスタ・ハードウェアの構成をグラフィカルに表示するには,sms コマンドを使用して SysMan Station のグラフィック・インタフェースを起動し,次に [Views] メニューから [Hardware] を選択してください。

9.6    新しいファイル・システムを作成するときの注意事項

新しいファイル・システムの作成は,そのほとんどがクラスタとスタンドアロンの環境で同じです。Tru64 UNIX 『AdvFS 管理ガイド』では,スタンドアロン環境での AdvFS ファイル・システムの作成方法を幅広く説明しています。

クラスタへのディスクの追加については,9.2.3 項を参照してください。

以下に示すのは,新しいファイル・システムを作成する場合の重要なクラスタ固有の注意事項です。

9.6.1    ディスクの接続性の確認

最高の可用性が得られるように,AdvFS ドメインでボリュームに使用されるすべてのディスクの接続性が同じであることを確認する必要があります。

ディスクは,次のどちらかの条件を満たす場合は接続性が同じです。

ディスクの接続性を確認する最も簡単な方法は,sms コマンドを使用して SysMan Station のグラフィック・インタフェースを起動し,[Views] メニューから [Hardware] を選択することです。

たとえば,図 9-1 では,pza0 に接続されている SCSI バスは,3 つのクラスタ・メンバすべてによって共用されています。そのバス上のディスクはすべて接続性が同じになります。

hwmgr コマンドを使用してクラスタ上のすべてのデバイスを表示してから,さまざまなメンバに接続されているために複数回表示されるディスクを選別することもできます。たとえば,次のようになります。

# hwmgr -view devices -cluster
 
HWID: Device Name         Mfg     Model            Hostname   Location
-------------------------------------------------------------------------------
  3: kevm                                         pepicelli
 28: /dev/disk/floppy0c          3.5in floppy     pepicelli  fdi0-unit-0
 40: /dev/disk/dsk0c     DEC     RZ28M    (C) DEC pepicelli  bus-0-targ-0-lun-0
 41: /dev/disk/dsk1c     DEC     RZ28L-AS (C) DEC pepicelli  bus-0-targ-1-lun-0
 42: /dev/disk/dsk2c     DEC     RZ28     (C) DEC pepicelli  bus-0-targ-2-lun-0
 43: /dev/disk/cdrom0c   DEC     RRD46    (C) DEC  pepicelli bus-0-targ-6-lun-0
 44: /dev/disk/dsk13c    DEC     RZ28M    (C) DEC pepicelli  bus-1-targ-1-lun-0
 44: /dev/disk/dsk13c    DEC     RZ28M    (C) DEC polishham  bus-1-targ-1-lun-0
 44: /dev/disk/dsk13c    DEC     RZ28M    (C) DEC provolone  bus-1-targ-1-lun-0
 45: /dev/disk/dsk14c    DEC     RZ28L-AS (C) DEC pepicelli  bus-1-targ-2-lun-0
 45: /dev/disk/dsk14c    DEC     RZ28L-AS (C) DEC polishham  bus-1-targ-2-lun-0
 45: /dev/disk/dsk14c    DEC     RZ28L-AS (C) DEC provolone  bus-1-targ-2-lun-0
 46: /dev/disk/dsk15c    DEC     RZ29B    (C) DEC pepicelli  bus-1-targ-3-lun-0
 46: /dev/disk/dsk15c    DEC     RZ29B    (C) DEC polishham  bus-1-targ-3-lun-0
 46: /dev/disk/dsk15c    DEC     RZ29B    (C) DEC provolone  bus-1-targ-3-lun-0
        .
        .
        .

この出力では,dsk0dsk1,および dsk2pepicelli のローカル・バスに接続されているプライベート・ディスクです。これらのディスクはどれもフェイルオーバ機能を必要とするファイル・システムに適切ではないので,LSM (Logical Storage Manager) ボリュームとして選択しない方が賢明です。

ディスク dsk13 (HWID 44),dsk14 (HWID 45),および dsk15 (HWID 46) は,pepicellipolishham,および provolone に接続されています。この 3 つのディスクは,接続性がまったく同じです。

9.6.2    利用可能なディスクの調査

ディスクがすでに使用中かどうかを判断したいときは,クォーラム・ディスク,クラスタ単位のファイル・システムが含まれているディスク,およびメンバ・ブート・ディスクとスワップ領域を調べてください。

9.6.2.1    クォーラム・ディスクの場所の調査

クォーラム・ディスクの場所を調べるには,clu_quorum コマンドを使用します。次の例では,コマンドからの出力の一部は,dsk10 がクラスタ・クォーラム・ディスクであることを示しています。

# clu_quorum
 Cluster Quorum Data for: deli as of Wed Apr 25 09:27:36 EDT 2001
 
Cluster Common Quorum Data
Quorum disk:   dsk10h
        .
        .
        .

disklabel コマンドを使用して,クォーラム・ディスクを調べることもできます。クォーラム・ディスク内のすべてのパーティションは未使用です。ただし,fstype cnx が設定されている h パーティションは除きます。

9.6.2.2    メンバ・ブート・ディスクとクラスタ単位の AdvFS ファイル・システムの場所の調査

メンバ・ブート・ディスクとクラスタ単位の AdvFS ファイル・システムの場所を確認するには,/etc/fdmns ディレクトリ内のファイル・ドメイン・エントリを調べてください。この作業に ls コマンドを使用できます。たとえば,次のようになります。

# ls /etc/fdmns/*
 
/etc/fdmns/cluster_root:
dsk3c
 
/etc/fdmns/cluster_usr:
dsk5c
 
/etc/fdmns/cluster_var:
dsk6c
 
/etc/fdmns/projects1_data:
dsk9c
 
/etc/fdmns/projects2_data:
dsk11c
 
/etc/fdmns/projects_tools:
dsk12c
 
/etc/fdmns/root1_domain:
dsk4a
 
/etc/fdmns/root2_domain:
dsk8a
 
/etc/fdmns/root3_domain:
dsk2a
 
/etc/fdmns/root_domain:
dsk0a
 
/etc/fdmns/usr_domain:
dsk0g

このような ls コマンドからの出力で,以下のことがわかります。

9.6.2.3    メンバ・スワップ領域の調査

メンバの 1 次スワップ領域は,常にメンバ・ブート・ディスクの b パーティションです。メンバ・ブート・ディスクの詳細は,11.1.5 項を参照してください。ただし,メンバにさらにスワップ領域を設定する可能性があります。メンバが停止している場合は,メンバのスワップ領域を使用しないように注意してください。ディスクにスワップ領域が設定されているかどうかを確認するには,disklabel -r コマンドを使用します。fstype swap のパーティションに関する出力で 「fstype」の列を調べてください。

次の例では,dsk11 のパーティション b がスワップ・パーティションです。

# disklabel -r dsk11
        .
        .
        .
8 partitions:
#         size     offset    fstype   [fsize bsize cpg] # NOTE: values not exact
 a:     262144          0     AdvFS                     # (Cyl.    0 - 165*)
 b:     401408     262144      swap                     # (Cyl.  165*- 418*)
 c:    4110480          0    unused        0     0      # (Cyl.    0 - 2594)
 d:    1148976     663552    unused        0     0      # (Cyl.  418*- 1144*)
 e:    1148976    1812528    unused        0     0      # (Cyl. 1144*- 1869*)
 f:    1148976    2961504    unused        0     0      # (Cyl. 1869*- 2594)
 g:    1433600     663552     AdvFS                     # (Cyl.  418*- 1323*)
 h:    2013328    2097152     AdvFS                     # (Cyl. 1323*- 2594)
 

9.6.3    /etc/fstab の編集

SysMan Station GUI (グラフィカル・ユーザ・インタフェース) を利用して AdvFS ボリュームの作成や構成を行うことができます。ただし,/etc/fstab の編集にコマンド行を使用することにした場合,そのファイルは一度だけ編集すればよく,任意のクラスタ・メンバから編集できます。/etc/fstab ファイルは,CDSLではありません。1 つのファイルがすべてのクラスタ・メンバで使用されます。

9.7    CDFS ファイル・システムの管理

クラスタでは,CD-ROM は必ずサービスされるデバイスです。ドライブはローカル・バスに接続されていなければならず,共用バスに接続することはできません。次に,クラスタで CDFS (CD-ROM ファイル・システム) を管理する場合の制約を示します。

CDFS ファイル・システムを管理するには,次の手順を実行します。

  1. cfsmgr コマンドを入力して,現在 CDFS に対するサービスを提供しているメンバを確認します。

    # cfsmgr
     
    

  2. サービスを提供しているメンバにログインします。

  3. 適切なコマンドを使用して管理タスクを実行します。

CDFS を操作するライブラリ関数の使用方法については,TruCluster Server 『クラスタ高可用性アプリケーション・ガイド』を参照してください。

9.8    ファイルのバックアップとリストア

クラスタ内のユーザ・データのバックアップとリストアは,スタンドアロン・システムの場合と同様です。他のシンボリック・リンクと同様に CDSL のバックアップとリストアを行います。CDSL のすべてのターゲットをバックアップするには,/cluster/members 領域をバックアップしてください。

使用する予定のすべてのリストア・ソフトウェアが,最初にクラスタ・メンバになったシステムの Tru64 UNIX ディスク上で利用できることを確認してください。このディスクをクラスタの緊急修復ディスクとして扱ってください。クラスタからルート・ドメイン cluster_root が失われた場合は,Tru64 UNIX ディスクから最初のクラスタ・メンバをブートすれば,cluster_root をリストアできます。

bttape ユーティリティは,クラスタではサポートされていません。

clonefset ユーティリティは ( clonefset(8) を参照),アクティブなファイルセットの読み取り専用のコピー (クローン) を作ることで,アクティブなファイルのオンライン・バックアップを行えるようにします。クローン・ファイルセットを作成しマウントした後,vdump コマンドや他のサポートされているバックアップ・ユーティリティを使って,クローンをバックアップできます (dump コマンドは,AdvFS でサポートされていません)。clonefset は,クラスタ・ファイル・システムのバックアップに適しています。クローン・ファイルセットからのクラスタ単位のルートのバックアップは,クローンがマウントされている時間を短縮します。クローン・ファイルセットをマウントし,バックアップを実行して,クローンをアンマウントする時間を可能な限り短くしてください。詳細は,9.5.2 項を参照してください。

9.8.1    バックアップするファイルに対する推奨事項

データ・ファイルと以下のファイル・システムを定期的にバックアップします。

9.9    スワップ領域の管理

スワップ・エントリを /etc/fstab に設定しないでください。Tru64 UNIX バージョン 5.0 では,スワップ・デバイスのリストが /etc/fstab ファイルから/etc/sysconfigtab ファイルに移動されました。また,スワップ割り当てを示すために /sbin/swapdefault ファイルを使用できなくなりました。したがって,このような用途にも /etc/sysconfigtab ファイルを使用してください。スワップ・デバイスとスワップ割り当てモードは,ベース・オペレーティング・システムのインストール中に自動的に /etc/sysconfigtab ファイルに設定されます。詳細は,Tru64 UNIX 『システム管理ガイド』および swapon(8) を参照してください。

各メンバのスワップ情報は,該当するメンバの sysconfigtab ファイルに設定してください。スワップ情報はクラスタ単位の /etc/fstab ファイルには設定しないでください。

sysconfigtab におけるスワップ情報は,swapdevice 属性で識別されます。スワップ情報の形式は,次のとおりです。

swapdevice=disk_partition,disk_partition,...

たとえば,次のようになります。

swapdevice=/dev/disk/dsk1b,/dev/disk/dsk3b

/etc/fstab でスワップ・エントリを指定しても,/etc/fstab がメンバ固有のファイルではなく,クラスタ単位のファイルなので,そのエントリはクラスタでは機能しません。スワップが /etc/fstab で指定されている場合は,ブートしてクラスタを形成する最初のメンバが,/etc/fstab 内のすべてのファイル・システムを読み取り,マウントします。他のメンバには,そのスワップ領域はまったくわかりません。

/etc/sysconfigtab ファイルはコンテキスト依存シンボリック・リンク (CDSL) なので,各メンバはそれぞれ固有のスワップ・パーティションを見つけてマウントできます。インストレーション・スクリプトでは,メンバごとに 1 つのスワップ・デバイスを自動的に構成して,swapdevice= エントリが,該当するメンバの sysconfigtab ファイル内に設定されます。

さらにスワップ領域を追加したい場合は,swapon で新規パーティションを指定してから,リブート後にパーティションが利用可能になるように,エントリを sysconfigtab 内に設定してください。たとえば,スワップ用に dsk1b をすでに使用しているメンバの 2 次スワップ・デバイスとして使用できるように dsk3b を構成するには,次のコマンドを入力してください。

swapon -s /dev/disk/dsk3b

次に,該当するメンバの /etc/sysconfigtab を編集し,/dev/disk/dsk3b を追加してください。/etc/sysconfigtab 内の最後のエントリは,次のようになります。

	swapdevice=/dev/disk/dsk1b,/dev/disk/dsk3b

9.9.1    性能向上のためのスワップ・デバイスの設定

共用バス上のデバイスにメンバのスワップ領域を設定すると,バスの入出力トラフィックがさらに増加します。これを回避するために,メンバのローカル・バス上のディスクにスワップを設定できます。

メンバに対してローカルのスワップを設定した際の唯一のマイナス面は,アダプタの障害時に稀に発生するおそれのある,スワップ・ディスクへのメンバのパスが失われるという問題です。パスが失われた場合は,メンバに障害が発生したことになります。スワップ・ディスクが共用バス上にある場合は,少なくとも 1 つのメンバにそのディスクへのパスが設定されている限り,メンバはそのスワップ・パーティションを使用できます。

9.10    ブート・パラメータによる問題の修正

クラスタ・メンバが,メンバのルート・ドメイン (rootN_domain) におけるパラメータの問題のためにブートに失敗する場合は,そのドメインを動作中のメンバ上にマウントして,パラメータに必要な変更を加えることができます。ただし,その起動していないメンバをブートする前に,動作中のクラスタ・メンバから新たに更新されたメンバのルート・ドメインをアンマウントしなければなりません。

アンマウントしなければ,クラッシュして,次のメッセージが表示される場合があります。

cfs_mountroot: CFS server already exists for node boot partition.

詳細は,11.1.10 項を参照してください。

9.11    クラスタでの verify ユーティリティの使用

verify ユーティリティでは,AdvFS ファイル・システムのオンディスク・メタデータ構造が検査されます。このユーティリティを使用する前に,検査対象のファイル・ドメイン内のファイルセットすべてをアンマウントしなければなりません。

verify ユーティリティを実行し,実行先のクラスタ・メンバに障害が発生した場合は,外部マウントが残るおそれがあります。このようになるのは,verify ユーティリティにより,検査対象ドメイン内のファイルセットの一時的なマウントが作成されるためです。単一システムでは,この一時的なマウントは,ユーティリティの実行中にシステムに障害が発生すれば削除されますが,クラスタでは一時的なマウントは,別のクラスタ・メンバにフェイルオーバされます。このように一時的なマウントがフェイルオーバされるため,そのマウントを削除するまでは,ファイルセットもマウントできなくなります。

verify を実行すると,ドメイン内のファイルセットごとにディレクトリが作成され,対応するディレクトリで各ファイルセットがマウントされます。ディレクトリは,/etc/fdmns/domain/set_verify_XXXXXX のように名前が付けられます。 ここで,XXXXXX は固有の ID です。

たとえば,ドメイン名が dom2 で,dom2 内のファイルセットが fset1fset2,および fset3 の場合は,次のようにコマンドを入力してください。

# ls -l /etc/fdmns/dom2
total 24
lrwxr-xr-x   1 root     system        15 Dec 31 13:55 dsk3a -> /dev/disk/dsk3a
lrwxr-x---   1 root     system        15 Dec 31 13:55 dsk3d -> /dev/disk/dsk3d
drwxr-xr-x   3 root     system      8192 Jan  7 10:36 fset1_verify_aacTxa
drwxr-xr-x   4 root     system      8192 Jan  7 10:36 fset2_verify_aacTxa
drwxr-xr-x   3 root     system      8192 Jan  7 10:36 fset3_verify_aacTxa
 

フェイルオーバされたマウントをクリーンアップするには,次の手順を実行します。

  1. 次のようにして /etc/fdmns 内のファイルセットをすべてアンマウントします。

    # umount /etc/fdmns/*/*_verify_*
     
    

  2. 次のコマンドで,フェイルオーバされたマウントをすべて削除します。

    # rm -rf /etc/fdmns/*/*_verify_*
     
    

  3. verify ユーティリティが正常に完了した後に,ファイルセットを再マウントします。

verify についての詳しい説明は, verify(8) を参照してください。

9.11.1    クラスタ・ルートでの verify ユーティリティの使用

verify ユーティリティは,稼働状態のドメインで実行できるように変更されています。-a オプションを使用して,クラスタ・ルート・ファイル・システム cluster_root を検査してください。

検査対象のドメインに対するサービスを提供しているメンバ上で verify -a ユーティリティを実行しなければなりません。cfsmgr コマンドを使用して,ドメインに対するサービスを提供しているメンバを確定してください。

-a オプションを指定して verify を実行すると,ドメインの検査のみが実行されます。稼働状態のドメインに対して修正を行うことはできません。-f-d のオプションを -a オプションとともに使用することできません。