この章では,TruCluster Server システムでのストレージ・デバイスの管理に特有な情報を記載しています。ここでは,次の項目について説明します。
CDSL の使用 (9.1 節)
デバイスの管理 (9.2 節)
クラスタ・ファイル・システムの管理 (9.3 節)
デバイス要求ディスパッチャの管理 (9.4 節)
クラスタでの AdvFS の管理 (9.5 節)
新しいファイル・システムの作成 (9.6 節)
CDFS ファイル・システムの管理 (9.7 節)
ファイルのバックアップとリストア (9.8 節)
スワップ領域の管理 (9.9 節)
ブート・パラメータによる問題の修正 (9.10 節)
クラスタでの
verify
の使用 (9.11 節)
その他のデバイス管理に関する情報は,表 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}
が文字列
member
n
に置き換えられます。ここで,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
(8)
cdslinvchk
(8)
mkcdsl
(8)-i
オプションを指定)
次の例は,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) サーバが拡張します。通常のシンボリック・リンクと同様に,クライアントがファイルまたはディレクトリを読み込むことはできません。ただし,該当する領域もクライアントでマウントされている場合は除きます。
クラスタでのデバイス管理は,次の例外を除けば,スタンドアロン・システムにおける管理と同様です。
デバイス・スペシャル・ファイルの管理用の
dsfmgr
コマンドで,クラスタの特殊オプションが解釈される場合
クラスタ内で共用バスとプライベート・バスが混在するため,デバイス・トポロジがさらに複雑になる場合
クラスタ内でサーバとして機能するクラスタ・メンバ,およびアクセス・ノードとして機能するメンバを指定できる場合
以降の各項で,これらの違いについて説明します。
9.2.1 デバイス・スペシャル・ファイルの管理
クラスタ内で
dsfmgr
(デバイス・スペシャル・ファイル管理ユーティリティ) を使用する場合は,次のことに留意してください。
-a
オプションには,entry_type
として
c
(クラスタ) を使用する必要があります。
-o
と
-O
のオプションは,古い形式のデバイス・スペシャル・ファイルを作成するので,クラスタでは有効ではありません。
-s
オプションでの出力では,最初のテーブルの
class scope
の欄は,c
(クラスタ) を使用してデバイスの有効範囲を示します。
詳細は,
dsfmgr
(8)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 でのハードウェア構成の表示
SCSI ハードウェア・デバイスの物理的な設置については,TruCluster Server 『クラスタ・ハードウェア構成ガイド』を参照してください。新しいディスクを設置した後は,以下の手順に従ってください。
すべてのメンバが新しいディスクを認識するように,各メンバ上で次のコマンドを実行します。
# hwmgr -scan comp -cat scsi_bus
注意
ディスクにアクセスする必要のあるすべてのクラスタ・メンバ上で
hwmgr -scan comp -cat scsi_bus
コマンドを実行しなければなりません。
すべてのメンバに新しいディスクの情報が登録されるまでしばらく待ちます。
追加するディスクがモデル RZ26,RZ28,RZ29,または RZ1CB-CA の場合,各クラスタ・メンバ上で次のコマンドを実行します
# /usr/sbin/clu_disk_install
クラスタに多数のストレージ・デバイスがある場合は,このコマンドが完了するのに数分かかります。
新しいディスクの名前を確認するには,次のコマンドを入力します。
# hwmgr -view devices -cluster
SysMan Station コマンドを実行し,[Views] メニューから [Hardware] を選択して,新しいディスク名を確認することもできます。
ディスク上でのファイル・システムの作成については,9.6 節を参照してください。
9.2.4 他社製ストレージの管理
クラスタ・メンバがクォーラムを失うと,その入出力はすべて中断され,残りのメンバは,クラスタから削除されたノードに対して入出力バリアを形成します。この入出力バリアが働くと,非クラスタ・メンバは共用ストレージ・デバイスに対して入出力できなくなります。
入出力バリアを形成する方法は,クラスタ・メンバが共用しているストレージ・デバイスのタイプによって異なります。場合によっては,Target_Reset というタスク管理の機能を使って,今までメンバであったノードとの間で行うすべての入出力を停止します。このタスク管理の機能は,次のいずれかの状況で使用されます。
共用している SCSI デバイスが SCSI Persistent Reserve コマンド・セットをサポートしておらず,Fibre Channel インターコネクトを使用する場合
共用している SCSI デバイスが 4 つの条件,つまり,(1) SCSI Persistent Reserve コマンド・セットをサポートしていない,(2) SCSI Parallel インターコネクトを使用する,(3) マルチポートのデバイスである,および (4) SCSI
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
では,dsk9
と
dsk10
をテープ・ドライブへバックアップするにはクラスタ・インターコネクトを介して行います。セミ・プライベート・ディスク
dsk11
,dsk12
,dsk13
,dsk14
を含むその他のディスクをバックアップする場合,データ転送速度が速くなります。
図 9-2: セミ・プライベート・ストレージを持つクラスタ
テープ装置が共用バス上に配置されている場合,装置へアクセスするアプリケーションは,共用 SCSI バス上の特定のイベントに対して適切に対応するように記述しなければなりません (たとえば,バス,デバイスのリセット)。バスとデバイスのリセット (たとえば,クラスタ・メンバシップ遷移による) は,共用 SCSI バス上のすべてのテープ装置を巻き戻します。
テープ・サーバ・アプリケーションの
read()
または
write()
では,errno
が返されます。I/O 呼出しから戻されたエラー情報を使用するようにテープ・サーバ・アプリケーションを明示的に設定し,テープを再位置付けします。read()
または
write()
の操作が失敗したときは,ioctl()
を
MTIOCGET
コマンド・オプションと一緒に使用して,アプリケーションでテープを再位置付けするために必要なエラー情報を持つ構造体を取得します。構造体の説明は,/usr/include/sys/mtio.h
を参照してください。
通常使うユーティリティ
tar
,cpio
,dump
,vdump
はこのように設計されていません。そのため,クラスタ内の共用バスに存在するテープ装置上で使うときには,予告なく停止する可能性があります。
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
クラスタのブート時に,TruCluster Server ソフトウェアにより,各ファイル・システムは,それぞれに対するサービスを提供するメンバに直接接続されます。メンバのローカ ル・バスに接続されたデバイスのファイル・システムは,そのメンバがサービスを提供します。共用 SCSI バス上のデバイスのファイル・システムは,その SCSI バスに直接接続されたメンバのいずれかがサービスを提供します。
AdvFS の場合は,CFS サーバに割り当てられた最初のファイルセットによって,そのドメイン内の他のすべてのファイルセットに CFS サーバと同じクラスタ・メンバが設定されていると判断されます。
クラスタのブート時には,通常,共用 SCSI バスに接続されている最初に起動したメンバが,最初に共用バス上のデバイスを検出します。その後,このメンバが,共用バス上のすべてのデバイスに対するすべてのファイル・システムの CFS サーバになります。 このため,ほとんどのファイル・システムは 1 つのメンバで取り扱われるため,そのメンバは他のメンバよりも負荷が重くなります。したがって,そのメンバのリソース (CPU,メモリ,I/O,など) の使用量は大きくなります。このような場合には,ファイル・システムを他のクラスタ・メンバに再配置して,負荷の分散と性能の向上を図ることをお奨めします。
TruCluster Server バージョン 5.1B には,負荷モニタ・デーモン
/usr/sbin/cfsd
が用意されており,ファイル・システム関連のメンバとクラスタのアクティビティを監視したり,そのレポートを作成したり,応答したりします。cfsd
は,省略時の構成では無効なので,明示的に有効にする必要があります。有効にされた後,cfsd
は次の機能を実行します。
目的やストレージの接続性に基づいてファイル・システムを配置することにより,ファイル・システムの管理を支援します。cfsd
を構成して,ストレージの接続性が変化したり,CFS のメモリ使用量が大きくなった場合,メンバをクラスタに参加させたり切り離したりするときに,自動的にファイル・システムを再配置できます。
ファイル・システムの使用性やシステム負荷のさまざまな統計情報を収集します。このデータによって,クラスタのファイル・システムの使用方法を把握できます。
収集した統計情報を分析し,システム性能の改善やクラスタ単位でのファイル・システムの負荷分散を図るために,ファイル・システムの再配置を推奨します。
クラスタ・ノード上で CFS のメモリ使用量を監視し,メンバが CFS メモリの使用限度に近づいたときに警告します。
cfsd
デーモンのインスタンスはクラスタの各メンバ上で実行します。すなわち,cfsd
がクラスタで動作するときには,各メンバ上で実行する必要があり,適切に動作する各メンバ上のデーモンに依存します。cfsd
をクラスタで動作させたくない場合は,どのメンバにもその実行を許可しないでください。
デーモンの各インスタンスはそのメンバ上で統計情報を収集し,CFS メモリが少ないというようなメンバ固有のイベントを監視します。クラスタのデーモンは,自動的に
"マスタ"
デーモンとしてサービスされ,収集したすべての統計情報を分析し,推奨案を作成して,自動的な再配置を開始します。このデーモンは,クラスタ単位の
/etc/cfsd.conf
構成ファイルを介して構成されます。
cfsd
デーモンは,定期的にメンバをポーリングして情報を入手し,ファイル・システムの性能とリソースの使用量を監視します。このポーリングは,指定されたポリシに対応した
/etc/cfsd.conf
構成ファイルの
polling_schedule
属性に従って行われます。
cfsd
デーモンは,各メンバの各ファイル・システムの使用量,各ファイル・システムのメモリ要求,各メンバのシステム・メモリ要求,メンバの物理的なストレージ接続性などの情報を収集しています。各デーモンは,メンバ固有のバイナリ・ファイル
/var/cluster/cfs/stats.member
に統計情報を格納します。このファイルのデータは,cfsd
固有のフォーマットであり,直接のユーザ・アクセスを意図していません。cfsd
デーモンはこれらのファイルを更新して,保守します。定期的に削除したり,保存したりする必要はありません。
次のデータは,各クラスタ・メンバによって収集されます。
svrcfstok 構造体の限度値 (この構造体については,9.3.6.3 項を参照)
svrcfstok 構造体の使用数
総バイト数
ラインのバイト数
次のデータは,メンバごと,ファイル・システムごとに集められます。
読み取り回数
書き込み回数
検索回数
getattr 操作回数
readlink 操作回数
アクセス回数
その他の操作回数
読み取りバイト数
書き込みバイト数
svrcfstok
構造体の使用数 (9.3.6.3 項で説明)
また,cfsd
デーモンは EVM イベントを処理し,クラスタ・メンバシップ,マウントされたファイル・システムおよびデバイス接続性のような,一般的なクラスタとクラスタのファイル・システムの状態についての情報を監視します。
注意
cfsd
は AdvFS ドメインを必要なエンティティとみなします。AdvFS ファイル・システムの再配置は,対象のファイル・システムばかりでなく同一ドメインのすべてのファイル・システムに影響を及ぼします。ドメイン全体が再配置されます。NFS クライアントおよび MFS (メモリ・ファイル・システム) タイプのファイル・システムは再配置できません。さらに,メンバ・ブート・パーティション,サーバだけのファイル・システム (読み書きアクセス用にマウントされた UFS ファイルなど),HSM (hierarchical storage manager) で管理されるファイル・システムも,再配置できません。
共用バス上のダイレクト・アクセス入出力デバイスはバス上のすべてのクラスタ・メンバによって使用されます。共用バス上,またはクラスタ・メンバに直接接続された単一サーバ・デバイスは,単一メンバによって使用されます。2 つ以上のファイル・システムが同一の単一サーバ・デバイスを使用している場合,
cfsd
はファイル・システムが別のメンバによってサービスされるときに起こる性能上の理由から再配置しません。
/sbin/init.d/cfsd
ファイルは各クラスタ・メンバ上で
cfsd
デーモンのインスタンスを起動します。ただし,デーモンの起動では
cfsd
をアクティブにしません。cfsd
デーモンの動作は,スタンザ・フォーマット・ファイル
/etc/cfsd.conf
の
active
フィールドを介して制御されます。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
がファイル・システムを自動的に再配置するかどうかを決定します。
このファイルを変更する場合は,次の点に注意してください。
ファイル・システムに明示的にポリシを指定しない場合,省略時のポリシを引き継ぎます。
cfsd
デーモンは,たとえブート・パーティションが再配置を行う
active_placement
ポリシに属していたとしても,デーモンはクラスタ・メンバのブート・パーティションを決して再配置しません。cfsd
デーモンはブート・パーティション用の
active_placement
を無視します。
active_placement
キーワードは,自動的な再配置を発生させるイベントを定義します。hosting_members
オプションは,ファイル・システムを再配置するメンバを定義します。
hosting_members
オプションは,優先リストでなく制限するリストです。placement
属性は,hosting_members
属性で指定されたメンバが利用できないときに,ファイル・システムを配置する方法を制御します。
cfsd
デーモンは,1 つだけの
hosting_members
エントリで定義されたすべてのクラスタ・メンバを平等に扱います。リストの位置による優先順位はありません。
メンバの優先順位を指定するには,複数の
hosting_members
行を使用します。cfsd
デーモンは,一番最初の
hosting_members
行にリストされたメンバに優先権を与え,次の
hosting_members
行のメンバに次の優先権を与えます。以下,このように優先順位を付与します。
作成可能なポリシの数には制限がありません。
file systems
行には,ファイル・システムを任意の数だけリストできます。複数のポリシに同一のファイル・システムが出現すると,最後に使用されたファイル・システムの優先順位が採用されます。
/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
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
コマンドを使用して推奨されるサーバへファイル・システムを再配置することができます。
たとえば,swiss
が
test_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
cfsd
デーモは,独自の統計情報の分析だけに基づいて自動再配置を行いません。むしろ,レポートを生成し,ユーザ環境に応じて採用の判断が可能な推奨案を提供します。
ただし,条件を設定すると,cfsd
はファイル・システム・ポリシの
active_placement
オプションで指定されたキーワードに基づいて,自動的にファイル・システムを再配置できます。active_placement
キーワードでは,自動再配置を行うイベントを定義します。hosting_members
オプションは,ファイル・システムを再配置するメンバとその優先順位を定義します。
active_placement
オプションの動作と指定できる値については,
cfsd.conf
(4)
メモリ
CFS メモリ使用量は,9.3.6.3 項で説明されている
svrcfstok_max_percent
カーネル属性によって制限されます。クラスタ・メンバがこの制限に達すると,そのメンバによってサービスされているファイル・システム上でのファイル処理は,「file table overflow」エラーで失敗します。メンバが CFS メモリの使用限度に近づくと,カーネルが警告として EVM イベントをポストします。このようなイベントがポストされると,cfsd
はサービスしているファイル・システムのいくつかを再配置して,そのメンバ上のメモリを開放しようとします。
優先順位
メンバがクラスタに参加したり切り離されたりするとき,cfsd
は希望するメンバにファイル・システムを再配置することができます。クラスタ・メンバのサブセットでの基本的なファイル・システムを望む場合もあります。
フェイルオーバ
メンバがクラスタに参加したり切り離されたりすると,cfsd
は希望するメンバにファイル・システムを再配置することができます。特定のファイル・システムのサービスを,主にクラスタ・メンバのサブセットで行いたい場合もあります。
接続性
メンバがサービスしているファイル・システムによって要求されたデバイスへの直接的な物理接続がない場合,サーバの性能は低下します。cfsd
デーモンは,現行のサーバがファイル・システム下のデバイスへの接続を失ったというイベントで自動的にファイル・システムを再配置します。
cfsd
デーモンは,CAA リソースの情報を持ちません。CAA では,hosting_members
,placement_policy
,required_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
のストレージが物理的に接続されているかどうかを次のようにして判断してください。
/accounts
がマウントされている場所を調べてください。/etc/fstab
を調べるか,または
mount
コマンドを使用できます。マウントされているファイル・システムが多数ある場合は,次のように
grep
を使用することをお勧めします。
# mount | grep accounts accounts_dmn#accounts on /accounts type advfs (rw)
AdvFS ドメイン
accounts_dmn
がマウントされているデバイスを確認するために,次のようにして
/etc/fdmns/accounts_dmn
ディレクトリを調べます。
# ls /etc/fdmns/accounts_dmn dsk6c
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 つになっているので,物理的に接続されています。
次のように
/accounts
の CFS サーバを
systemd
に再配置します。
# cfsmgr -a server=systemd /accounts
CFS 統計情報の示す負荷がそれほど不均衡になっていない場合でも,共用バスに接続されている利用可能なメンバ間で CFS サーバを分散するようお勧めします。そうすれば,クラスタの性能を全体的に向上できます。
9.3.3.8
cfsmgr
による CFS サーバの負荷分散
特定のクラスタ・メンバを自動的にファイル・システムまたはドメインの CFS サーバとして機能させるには,cfsmgr
コマンドを呼び出すスクリプトを
/sbin/init.d
に設定すれば,ファイル・システムまたはドメインのサーバを目的のクラスタ・メンバに再配置できます。この方法は CFS の負荷を分散させますが,平衡はとりません。
たとえば,クラスタ・メンバ
alpha
で
accounting
ドメインに対するサービスを提供したい場合は,起動スクリプトに次のように
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
の機能の仕方に幾分違いがありますが,両方とも,フリーズされたドメイン上でのメタデータの変更は許されません。クラスタでのコマンドの動作で,最も注目される単一システムとの違いは,次のとおりです。
クラスタ・メンバをシャットダウンすると,クラスタのすべてのフリーズされたファイル・システムが解凍される。
クラスタ・メンバに障害が発生した場合,クラスタのすべてのフリーズされたファイル・システムが解凍される。
省略時の設定では,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
CFS 性能を次に示す事項で調整できます。
先読みおよび後書きスレッド数の変更 (9.3.6.1 項)
直接入出力の利用 (9.3.6.2 項)
CFS メモリ使用量の調整 (9.3.6.3 項)
メモリ・マップ・ファイルの使用 (9.3.6.4 項)
フル・ファイル・システムの回避 (9.3.6.5 項)
その他の方法 (9.3.6.6 項)
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 非同期入出力 (クラスタでもサポート) と合わせて頻繁に直接入出力を行って,入出力性能を向上させます。
直接入出力用にオープンされたファイル上で最高の性能を引き出すには,次のような条件があります。
ファイルの既存位置から読み取る
ファイルの既存位置へ書き込む
読み取られる,または書き込まれるデータのサイズがディスク・セクタ・サイズ (512 バイト) の倍数
次の条件により,直接入出力性能が低くなります。
メタデータがファイルに変更される操作。ファイル・システムの CFS サーバ以外のメンバで直接入出力を行うアプリケーションが実行されるとき,この操作は,ファイル・システムの CFS サーバへクラスタ・インターコネクトを介して行われます。このような操作には次のものがあります。
ファイル内の散在する位置への変更
ファイルに追加する変更
ファイルを切り捨てる変更
8K 未満のフラグメントだけで構成されるファイルでの読み取りまたは書き込み,または大きいファイルの末尾のフラグメント部分に対する読み書き
ファイルの既存位置以外への非ブロック境界の読み取りまたは書き込み。要求がブロック境界で開始または終了しない場合は,複数の入出力が実行されます。
直接入出力用にファイルがオープンされたときには,ドメイン上の AdvFS 移行操作 (たとえば,migrate
,rmvol
,defragment
,balance
) は,全メンバ上で実行中の入出力が完了するまでブロックされます。逆に,直接入出力は AdvFS 移行操作が完了するまでブロックされます。
直接入出力を使用するアプリケーションは,それ自身のキャッシングを管理する責任があります。1 つのクラスタ・メンバまたは複数のメンバ上でマルチスレッドの直接入出力を実行する場合は,アプリケーションで,どの場合もセクタの読み取りまたは書き込みが確実に単一のスレッドのみで行われるように同期をとる必要があります。
直接入出力プログラミングについては,Tru64 UNIX 『プログラミング・ガイド』 の最適化技術の章を参照してください。
9.3.6.2.1 クラスタとスタンドアロン AdvFS 直接入出力の違い
スタンドアロン・システムと異なるクラスタ上の直接入出力の動作を次に示します。
直接入出力ブロック用に既にオープン済みのファイルでの移行操作は,実行中の入出力がすべてのメンバ上で完了するまで実行される。続く入出力は,移行操作が完了するまでブロックされる。
スタンドアロン・システムの 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
個々の統計情報には次の意味があります。
direct i/o reads
通常の直接入出力読み取り要求回数。要求を発行したメンバ上で処理された読み取り要求で,CFS サーバ上の AdvFS 層へ送信されなかった要求です。
direct i/o writes
通常の直接入出力書き込み要求実行回数。要求を発行したメンバ上で処理された書き込み要求で,CFS サーバ上の AdvFS 層へ送信されなかった要求です。
aio raw reads
通常の直接入出力非同期読み取り要求回数。要求を発行したメンバ上で処理された読み取り要求で,CFS サーバ上の AdvFS 層へ送信されなかった要求です。
aio raw writes
通常の直接入出力非同期書き込み要求回数。要求を発行したメンバ上で処理された書き込み要求で,CFS サーバ上の AdvFS 層へ送信されなかった要求です。
unaligned block reads
ディスク・セクタのサイズ (現在は 512 バイト) の倍数でない読み取り回数。セクタ境界から開始しない要求またはセクタ境界で終了しない要求を加えた回数です。非ブロック境界の読み取り操作は,セクタの読み取りと,セクタの適切な位置からのユーザ・データのコピーから構成されます。
入出力要求がファイルの既存位置を対象とするものであり,フラグメントを含まない場合,この操作は CFS サーバへ送られません。
fragment reads
要求がフラグメントを含むファイルの一部に対してなされたため,CFS サーバへ送信する必要のある読み取り要求回数。
140K 未満のファイルには,8K の倍数でないフラグメントを最後に含むことがあります。また,サイズが 8K 未満の小さいファイルは,フラグメントだけのことがあります。
8K 未満のファイルにフラグメントを含まないようにするには,常に直接入出力用にのみファイルをオープンします。そうしなければ,通常にオープンされたファイルをクローズする場合,フラグメントがファイルに作成されます。
zero-fill (hole) reads
直接入出力でオープンされたファイルの散在する部分に発生する読み取り回数。この要求は CFS サーバへ送られません。
file-extending writes
データをファイルに追加するため,CFS サーバへ送信する書き込み要求回数。
unaligned block writes
ディスク・セクタのサイズ (現在は 512 バイト) の倍数でない書き込み回数。セクタ境界から開始しない要求またはセクタ境界で終了しない要求を加えた回数です。非ブロック境界の書き込み操作は,セクタの読み取り,ブロックの適切な位置へのユーザ・データのコピー,およびその後のデータの書き込みから構成されます。
入出力要求がファイルの既存位置を対象にするものであり,フラグメントを含まない場合,この操作は CFS サーバへ送られません。
hole writes
CFS サーバで AdvFS に送る必要のあるファイル内の散在する位置への書き込み要求回数。
fragment writes
要求がフラグメントを含むファイルの一部に対してなされたため,CFS サーバへ送信する必要のある書き込み要求回数。
140K 未満のファイルには,8K の倍数でないフラグメントを最後に含むことがあります。また,サイズが 8K 未満の小さいファイルは,フラグメントだけのことがあります。
8K 未満のファイルにフラグメントを含まないようにするには,常に直接入出力用にのみファイルをオープンします。そうしなければ,通常にオープンされたファイルをクローズする場合,フラグメントがファイルに作成されます。
truncates
直接入出力でオープンされたファイルの切り捨て要求回数。この要求は 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
エラーの取得を開始する場合は,以下の手順に従ってください。
CFS クライアントが vnode の範囲外かどうかを次のように判断します。
max_vnodes
カーネル属性の現在の値を取得します。
# sysconfig -q vfs max_vnodes
dbx
を使用して
total_vnodes
と
free_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_vnodes
が
max_vnodes
と等しく,free_vnodes
が 0 の場合,そのメンバは vnode の範囲外です。このような場合には,max_vnodes
カーネル属性の値を増やすことができます。sysconfig
を使用すれば,動作中のメンバの
max_vnodes
を変更できます。たとえば,vnode の最大数を 20000 に設定するには,次のように入力します。
# sysconfig -r vfs max_vnodes=20000
CFS クライアントが vnode の範囲外でない場合は,CFS サーバでトークン構造体 (svrcfstok_max_percent
) に利用可能なメモリすべてが使用されたかどうかを次のように調べてください。
CFS サーバにログインします。
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
cfs_max_svrcfstok
の値を取得します。
(dbx)pd cfs_max_svrcfstok max_svrcfstok_value
svrtok_active_svrcfstok
が
cfs_max_svrcfstok
以上になっている場合は,CFS サーバでトークン構造体に利用可能なメモリすべてが使用されています。
このような場合に,ファイル・システムを再び使用できるようにする理想的な解決策は,ファイル・システムの一部を他のクラスタ・メンバに再配置することです。それが無理な場合は,以下のような解決策が適しています。
cfs_max_svrcfstok
の値を増やす。
sysconfig
コマンドで
cfs_max_svrcfstok
を変更することはできません。ただし,dbx assign
コマンドを使用すれば,カーネルの動作中に
cfs_max_svrcfstok
の値を変更できます。たとえば,CFS サーバ・トークン構造体の最大数を 80000 に設定するには,次のコマンドを入力します。
(dbx)assign cfs_max_svrcfstok=80000
dbx assign
コマンドで設定する値は,システムがリブートされると失われます。
CFS サーバ上のトークン構造体に利用可能なメモリ容量を増やす。
このオプションは,メモリ容量の少ないシステムには好ましくありません。
svrcfstok_max_percent
を増やすには,サーバにログインして,dxkerneltuner
コマンドを実行します。メイン・ウィンドウで,cfs
カーネル・サブシステムを選択します。cfs
ウィンドウで,svrcfstok_max_percent
に適切な値を入力します。この変更は,クラスタ・メンバがリブートされるまで有効になりません。
一般に,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 の性能を改善できます。
クラスタ・メンバでシステム・メモリが不足しないように確認します。
一般に,クラスタ・メンバの間でファイルを共用して読み書きすると,キャッシュがすべて無効になるため,性能が低下するおそれがあります。CFS を使うファイルの入出力は,複数のメンバが同時にデータを変更する場合は正しく動作しません。この状況では,キャッシュが頻繁にフラッシュされるため,すべてのノードに対して,どの時点でもデータが同じように見えるようにすることは困難です。
個々のメンバ上の分散型アプリケーションで読み取りと書き込みを行う場合は,書き込みを行うメンバ上にアプリケーションの CFS サーバを配置します。書き込みは,リモート入出力に対して読み取りよりも慎重に処理する必要があります。
複数のアプリケーションが単一の AdvFS ドメイン内のさまざまなデータ・セットにアクセスする場合は,そのデータを複数のドメインに分割することを検討します。このようにすれば,単一の CFS サーバより多くのサーバに負荷を分散できます。単一のメンバにすべてをロードせずに,各アプリケーションを,そのアプリケーションのデータ用の 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 ファイル・システムのみに適用できます。
パーティショニングされたファイル・システムには次のような制限があります。
Tru64 UNIX バージョン 5.1B からは,マウントされるファイル・システムもまたパーティショニングされたファイル・システムであり,同じクラスタのメンバでサービスされる場合には,ファイル・システムはパーティショニングされたファイル・システムにマウントできます。
CFS を介したフェイルオーバ機能を持たない
パーティショニングされたファイル・システムをサービスするクラスタ・メンバに障害が発生した場合,ファイル・システムはアンマウントされます。
パーティショニングされたファイル・システムを使用するアプリケーションが CAA の制御下にあることでこれを回避できます。パーティショニングされたファイル・システムがマウントされているメンバ上でアプリケーションを実行する必要があるため,メンバに障害が発生すると,ファイル・システムとアプリケーションの両方に障害が発生します。CAA の制御下のアプリケーションは,実行中のクラスタ・メンバにフェイルオーバします。アプリケーションの CAA 処理スクリプトにパーティショニングされたファイル・システムを新規メンバでマウントするように記述できます。
NFS エクスポート
パーティショニングされたファイル・システムをエクスポートする最適な方法は,パーティショニングしたそのファイル・システムを提供するノードに対して単一のノード・クラスタ別名を作成し,その別名を
/etc/exports.aliases
ファイルに入れることです。/etc/exports.aliases
ファイルの利用方法についての詳細は,3.15 節を参照してください。
クラスタの提供する NFS マウント・ファイル・システムへアクセスするときに省略時のクラスタ別名を使用すると,NFS 要求がファイル・システムへアクセスできないメンバに送られて失敗することがあります。
パーティショニングされたファイル・システムをエクスポートするもうひとつの方法は,パーティショニングされたファイル・システムを提供するメンバにクラスタ内の一番高いクラスタ別名選択優先順位 (selp
) を付けることです。これを行うと,メンバはすべての NFS 接続要求に対してサービスします。ただし,メンバはクラスタに指示された全種類のネットワーク・トラフィックも処理する必要があります。これは,ほとのどの環境では容認できません。
接続要求の分散についての詳細は,3.10 節を参照してください。
同じドメイン内にパーティショニングされたファイルセットと通常のファイルセットが混在しない
オプション
server_only
は,ドメイン内のすべてのファイル・システムに適応されます。マウントされた最初のファイルセットのタイプが,ドメイン内の全ファイルセットのタイプを決定します。
ファイルセットがオプション
server_only
なしでマウントされた場合,ドメイン
server_only
内の別のファイルセットのマウントは失敗します。
ドメイン内のファイルセットが
server_only
でマウントされた場合,ドメイン内でマウントされたそれ以降のファイルセットは
server_only
になる必要があります。
手動の再配置機能を持たない
パーティショニングされたファイル・システムを別の CFS サーバへ移動するには,ファイル・システムをアンマウントし,対象とするメンバ上で再度マウントする必要があります。同時に,ファイル・システムを使うアプリケーションを移動させる必要があります。
オプション
server_only
を使ったマウント更新機能を持たない
ファイル・システムの通常のマウントの後,ファイル・システム上でオプション
server_only
でコマンド
mount -u
を使用することはできません。たとえば,file_system
がフラグ
server_only
なしで既にマウント済みの場合,次のコマンドは失敗します。
# mount -u -o server_only file_system
単一のブロック・デバイスには,複数の別名を設定できます。この場合には,ファイル・システムのネームスペースにおける複数のブロック・デバイス・スペシャル・ファイルに同じ
dev_t
が含まれます。このような別名は,ネームスペース内の複数のドメインまたはファイル・システムの至るところで見つかる可能性があります。
スタンドアロン・システムでは,キャッシュの整合性は,もとになる共通のブロック・デバイスの
open()
呼び出しに使用された別名にかかわらず,オープンしたブロック・デバイスすべての間で保証されます。ただし,クラスタでキャッシュの整合性が得られるのは,すべてのブロック・デバイス・ファイルの別名が同じドメインまたはファイル・システム上に存在する場合に限られます。
たとえば,クラスタ・メンバ
mutt
がブロック・デバイスを備えたドメインを提供し,メンバ
jeff
が同じ
dev_t
で別のブロック・デバイス・ファイルを備えたドメインを提供する場合,この 2 つの別名で同時に入出力が実行されれば,キャッシュの整合性は得られません。
9.3.10 CFS の制限
クラスタ・ファイル・システム (CFS) は,ネットワーク・ファイル・システム (NFS) クライアントを読み取り/書き込みアクセスでサポートします。
ファイル・システムをクラスタで NFS マウントした場合,CFS はすべてのクラスタ・メンバで読み取り/書き込みアクセスを可能にします。実際にマウントしたメンバが,他のクラスタ・メンバにファイル・システムを提供します。
NFS ファイル・システムをマウントしたメンバが,シャットダウンするか,または障害が発生すると,ファイル・システムは自動的にアンマウントされ,CFS はマウント・ポイントのクリーンアップを開始します。クリーンアップ処理の間,これらのマウント・ポイントにアクセスするメンバはクリーンアップの進展の度合いに応じてさまざまな状態になります。
メンバがそのファイル・システム上でまだファイルをオープンしている場合は,書き込みデータは実際の NFS マウント・ファイル・システムの代わりに,ローカル・キャッシュに送られます。
そのファイル・システム上ですべてのファイルがクローズされている場合は,ファイル・システムが再びマウントされるまで,EIO
エラーで失敗します。アプリケーションには,「Stale NFS handle」メッセージが送信されます。これは,スタンドアロン・システムでも,クラスタと同様に,通常の動作です。
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
が,systemd
と
dsk3
の間のあらゆるデバイス要求ディスパッチャの処理を引き受けるようになります。
# drdmgr -h systemd -a accessnode=systemc dsk3
9.4.1.1 ダイレクト・アクセス入出力をサポートするデバイス
RAID 対応のディスクはダイレクト・アクセス入出力機能を備えています。RAID (Redundant Array of Independent Disks) コントローラの一部を,以下に示します。
HSZ80
HSG60
HSG80
RA3000 (HSZ22)
Enterprise Virtual Array (HSV110)
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 に交換) する場合は,次の手順を実行して,新しいディスクをダイレクト・アクセス入出力ディスクにしてください。
ディスクをバスに物理的に接続します。
次のように
hwmgr
コマンドを使用して新しいディスクを走査します。
# hwmgr -scan comp -cat scsi_bus
走査が完了するまで 1,2 分かかります。
交換した旧ディスクと同じデバイス名を新規ディスクに付ける場合は,hwmgr -redirect scsi
コマンドを実行します。詳細は,
hwmgr
(8)
各クラスタ・メンバで,次のように
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) は,大部分がスタンドアロン・システムと同様の特徴を示します。ただし,この節で次のようなクラスタ固有のいくつかの注意事項を説明します。
新たに追加されたメンバからの AdvFS ファイルの統合 (9.5.1 項)
クラスタ・ルート・ドメインにファイルセットを 1 つだけ作成する (9.5.2 項)
メンバのブート・パーティションへファイルセットを追加する (9.5.3 項)
メンバのルート・ドメインへボリュームを追加しない (9.5.4 項)
addvol
および
rmvol
コマンドの使用 (9.5.5 項)
ユーザとグループのファイル・システムに対するクォータの使用 (9.5.6 項)
ストレージの接続性と AdvFS ボリュームの理解 (9.5.7 項)
9.5.1 新たに追加されたメンバからの AdvFS ファイルの統合
新規メンバをクラスタに追加しますが,その新規メンバには,スタンドアロン・システムとして稼働していたときから AdvFS ボリュームとファイルセットが用意されているとします。このようなボリュームとファイルセットをクラスタに統合するには,次の操作を行う必要があります。
クラスタに統合したい
domains#filesets
を列挙している
/etc/fstab
ファイルを変更します。
新規ドメインをクラスタに登録するために,ドメイン情報を手動で
/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 サーバになっているメンバ上でリモートに実行されます。これにより,次のような結果になります。
ドメインのサーバでないメンバから
addvol
または
rmvol
が入力され,ドメインに対するサービスを提供するメンバに障害が発生した場合,コマンドは,実行されたシステム上で TCP のタイムアウトまで,場合によっては 1 時間もの間ハングするおそれがあります。
このような状況になった場合は,コマンドとコマンドに関連する
rsh
プロセスを強制終了させて,次のようにしてコマンドを繰り返すことができます。
ps
コマンドでプロセス ID (PID) を取得して,more
によって出力をパイプ処理し,addvol
または
rmvol
を (どちらが適切であっても) 検索します。たとえば,次のようになります。
# ps -el | more +/addvol 80808001 I + 0 16253977 16253835 0.0 44 0 451700 424K wait pts/0 0:00.09 addvol 80808001 I + 0 16253980 16253977 0.0 44 0 1e6200 224K event pts/0 0:00.02 rsh 808001 I + 0 16253981 16253980 0.0 44 0 a82200 56K tty pts/0 0:00.00 rsh
プロセス ID (この例では,16253977
,16253980
,および
16253981
の PID) と親プロセス ID (16253977
と
16253980
の PPID) を使用して,addvol
または
rmvol
と
rsh
プロセスとの関連を確認します。2 つの
rsh
プロセスは
addvol
プロセスに関連付けられています。3 つのプロセスすべてを強制終了しなければなりません。
該当するプロセスを強制終了します。この例では,次のようになります。
# kill -9 16253977 16253980 16253981
addvol
コマンドまたは
rmvol
コマンドを再入力します。addvol
の場合は,-F
オプションを入力しなければなりません。-F
オプションを使用する必要があるのは,ハングした
addvol
コマンドでディスク・ラベルがすでに AdvFS に変更されている可能性があるためです。
もう 1 つの方法として,ドメインで
addvol
または
rmvol
コマンドを使用する前に,次の操作が実行できます。
次のように
cfsmgr
コマンドを使用して,ドメインの CFS サーバの名前を確認します。
# cfsmgr -d domain_name
あらゆる CFS ドメインのサーバのリストを取得するには,cfsmgr
コマンドのみを入力します。
サービスを提供しているメンバにログインします。
addvol
または
rmvol
のコマンドを使用します。
ボリュームの CFS サーバが,addvol
または
rmvol
の操作の途中で別のメンバにフェイルオーバした場合は,新しいサーバが部分的な操作をすべて取り消すため,コマンドの再入力が必要になる可能性があります。このコマンドでは,サーバに障害が発生したことを示すメッセージは返されないので,操作を繰り返す必要があります。
コマンドが戻った後に
addvol
または
rmvol
コマンドのターゲット・ドメインに対する
showfdmn
コマンドを入力することをお勧めします。
コマンドが実行されたメンバがドメインのサーバでない場合,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 システムでサポートしているクォータと似ていますが,次の点が異なります。
CFS (クラスタ・ファイル・システム) はキャッシュされているデータを独自の基準 (タイミングと方法) に基づいて書き込みます。そのため,ハード限界値は絶対ではありません。
ソフト限界値と猶予期間はサポートされていますが,ユーザがソフト限界値を超過したクライアント・ノードからメッセージを受け取れない場合があり,そのようなメッセージがタイムリーに到達しない場合もあります。
quota コマンドは,クラスタ単位で有効です。ただし,各クラスタ・メンバで
/sys/conf/NAME
システム構成ファイルを編集して,システムにクォータ・サブシステムを組み入れる必要があります。クラスタ・メンバでこの手順を実行しなくても,クォータはそのメンバで有効になりますが,そのメンバから quota コマンドを入力することはできません。
TruCluster Server がサポートしているファイル・システムは,AdvFS ファイル・システムだけです。
ユーザとグループはクラスタ単位で管理されます。つまり,ユーザおよびグループのクォータも,クラスタ単位で管理されます。
ここでは,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 ドメイン内のすべてのボリュームが同じ接続性を備えていなければなりません。次の条件のどちらかに当てはまる場合は,ボリュームの接続性が同じです。
AdvFS ドメイン内のすべてのボリュームが同じ共用 SCSI バス上にある。
AdvFS ドメイン内のボリュームは別々の共用 SCSI バス上にあるが,それぞれのバスすべてが同じクラスタ・メンバに接続されている。
drdmgr
および
hwmgr
コマンドを使用すれば,システムとディスクのサービスの関係がわかります。動作中のメンバ,バス,ストレージ・デバイス,およびそれらの接続をはじめとするクラスタ・ハードウェアの構成をグラフィカルに表示するには,sms
コマンドを使用して SysMan Station のグラフィック・インタフェースを起動し,次に [Views] メニューから [Hardware] を選択してください。
9.6 新しいファイル・システムを作成するときの注意事項
新しいファイル・システムの作成は,そのほとんどがクラスタとスタンドアロンの環境で同じです。Tru64 UNIX 『AdvFS 管理ガイド』では,スタンドアロン環境での AdvFS ファイル・システムの作成方法を幅広く説明しています。
クラスタへのディスクの追加については,9.2.3 項を参照してください。
以下に示すのは,新しいファイル・システムを作成する場合の重要なクラスタ固有の注意事項です。
最高の可用性が得られるように,AdvFS ドメインでボリュームに使用されるすべてのディスクが同じ接続性を持つことを確実にしてください。
できるだけ,AdvFS ドメイン内のすべて LSM ボリュームの接続性を同じにしてください。LSM ボリュームと接続性の詳細については,Tru64 UNIX 『Logical Storage Manager』 を参照してください。
ディスクが使用中かどうかを調べるときは,そのディスクが以下のいずれかとして使用されていないかどうかを確認してください。
クラスタ・クォーラム・ディスク
データ用にはクォーラム・ディスク上のどのパーティションも使用しないでください。
クラスタ単位のルート・ファイル・システム,クラスタ単位の
/var
ファイル・システム,またはクラスタ単位の
/usr
ファイル・システム
メンバのブート・ディスク
メンバ・ブート・ディスクの説明とその構成方法については,11.1.5 項を参照してください。
1 つの
/etc/fstab
ファイルがクラスタのすべてのメンバに適用されます。
最高の可用性が得られるように,AdvFS ドメインでボリュームに使用されるすべてのディスクの接続性が同じであることを確認する必要があります。
ディスクは,次のどちらかの条件を満たす場合は接続性が同じです。
AdvFS ドメイン内のボリュームに使用されるすべてのディスクが同じ共用 SCSI バス上にある。
AdvFS ドメイン内のボリュームに使用されるディスクが異なる共用 SCSI バス上にあっても,それぞれのバスがすべて同じクラスタ・メンバに接続されている。
ディスクの接続性を確認する最も簡単な方法は,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 . . .
この出力では,dsk0
,dsk1
,および
dsk2
が
pepicelli
のローカル・バスに接続されているプライベート・ディスクです。これらのディスクはどれもフェイルオーバ機能を必要とするファイル・システムに適切ではないので,LSM (Logical Storage Manager) ボリュームとして選択しない方が賢明です。
ディスク
dsk13
(HWID 44),dsk14
(HWID 45),および
dsk15
(HWID 46) は,pepicelli
,polishham
,および
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
コマンドからの出力で,以下のことがわかります。
ディスク
dsk3
は,クラスタ単位のルート・ファイル・システム (/
) で使用されます。このディスクは使用できません。
ディスク
dsk5
は,クラスタ単位の
/usr
ファイル・システムで使用されます。このディスクは使用できません。
ディスク
dsk6
は,クラスタ単位の
/var
ファイル・システムで使用されます。このディスクは使用できません。
ディスク
dsk4
,dsk8
,および
dsk2
は,メンバ・ブート・ディスクです。これらのディスクは使用できません。
disklabel
コマンドを使用してメンバ・ブート・ディスクを識別することもできます。それぞれのディスクにはパーティションが 3 つあり,a
パーティションには
fstype
AdvFS
,b
パーティションには
fstype
swap
,h
パーティションには
fstype
cnx
が設定されています。
ディスク
dsk9
,dsk11
,および
dsk12
は,データおよびツールに使用されていると思われます。
ディスク
dsk0
は 非クラスタの Tru64 UNIX ベース・オペレーティング・システム用のブート・ディスクです。
非クラスタ・カーネルをブートして修復しなければならない場合に備えて,このディスクは変更しないでください。
メンバの 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)
SysMan Station GUI (グラフィカル・ユーザ・インタフェース) を利用して AdvFS ボリュームの作成や構成を行うことができます。ただし,/etc/fstab
の編集にコマンド行を使用することにした場合,そのファイルは一度だけ編集すればよく,任意のクラスタ・メンバから編集できます。/etc/fstab
ファイルは,CDSLではありません。1 つのファイルがすべてのクラスタ・メンバで使用されます。
9.7 CDFS ファイル・システムの管理
クラスタでは,CD-ROM は必ずサービスされるデバイスです。ドライブはローカル・バスに接続されていなければならず,共用バスに接続することはできません。次に,クラスタで CDFS (CD-ROM ファイル・システム) を管理する場合の制約を示します。
cddevsuppl
コマンドは,クラスタではサポートされていません。
次のコマンドは,CDFS ファイル・システムの CFS サーバになっているクラスタ・メンバから実行された場合にのみ機能します。
cddrec
(1)
cdptrec
(1)
cdsuf
(1)
cdvd
(1)
cdxar
(1)
cdmntsuppl
(8)
CD-ROM をマウントするメンバにかかわらず,ドライブに接続されたメンバは CDFS ファイル・システムの CFS サーバです。
CDFS ファイル・システムを管理するには,次の手順を実行します。
cfsmgr
コマンドを入力して,現在 CDFS に対するサービスを提供しているメンバを確認します。
# cfsmgr
サービスを提供しているメンバにログインします。
適切なコマンドを使用して管理タスクを実行します。
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 バックアップするファイルに対する推奨事項
データ・ファイルと以下のファイル・システムを定期的にバックアップします。
クラスタ単位のルート・ファイル・システム
ユーザ・データに使用するのと同じバックアップとリストア方式を採用してください。
クラスタ単位の
/usr
ファイル・システム
ユーザ・データに使用するのと同じバックアップとリストア方式を採用してください。
クラスタ単位の
/var
ファイル・システム
ユーザ・データに使用するのと同じバックアップとリストア方式を採用してください。
TruCluster Server をインストールする前に,AdvFS を使用しており,/usr
(usr_domain#var
) に
/var
が配置されている場合は,インストール処理により,/var
は自身のドメイン (cluster_var#var
) に移動されます。
メンバ・ブート・ディスク
メンバ・ブート・ディスクのバックアップとリストアの特別な注意事項は,11.1.5 項を参照してください。
スワップ・エントリを
/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
共用バス上のデバイスにメンバのスワップ領域を設定すると,バスの入出力トラフィックがさらに増加します。これを回避するために,メンバのローカル・バス上のディスクにスワップを設定できます。
メンバに対してローカルのスワップを設定した際の唯一のマイナス面は,アダプタの障害時に稀に発生するおそれのある,スワップ・ディスクへのメンバのパスが失われるという問題です。パスが失われた場合は,メンバに障害が発生したことになります。スワップ・ディスクが共用バス上にある場合は,少なくとも 1 つのメンバにそのディスクへのパスが設定されている限り,メンバはそのスワップ・パーティションを使用できます。
9.10 ブート・パラメータによる問題の修正
クラスタ・メンバが,メンバのルート・ドメイン (root
N_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
内のファイルセットが
fset1
,fset2
,および
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
フェイルオーバされたマウントをクリーンアップするには,次の手順を実行します。
次のようにして
/etc/fdmns
内のファイルセットをすべてアンマウントします。
# umount /etc/fdmns/*/*_verify_*
次のコマンドで,フェイルオーバされたマウントをすべて削除します。
# rm -rf /etc/fdmns/*/*_verify_*
verify
ユーティリティが正常に完了した後に,ファイルセットを再マウントします。
verify
についての詳しい説明は,
verify
(8)9.11.1 クラスタ・ルートでの verify ユーティリティの使用
verify
ユーティリティは,稼働状態のドメインで実行できるように変更されています。-a
オプションを使用して,クラスタ・ルート・ファイル・システム
cluster_root
を検査してください。
検査対象のドメインに対するサービスを提供しているメンバ上で
verify -a
ユーティリティを実行しなければなりません。cfsmgr
コマンドを使用して,ドメインに対するサービスを提供しているメンバを確定してください。
-a
オプションを指定して
verify
を実行すると,ドメインの検査のみが実行されます。稼働状態のドメインに対して修正を行うことはできません。-f
と
-d
のオプションを
-a
オプションとともに使用することできません。