Jump to content 日本-日本語
≫ お問い合わせ

HP OpenVMS: Volume Shadowing for OpenVMS におけるホストベース・ミニマージ

第1章 Volume Shadowing for OpenVMS におけるホスト・ベース・ミニマージ (HBMM)

≫ 

OpenVMSドキュメント・ライブラリ

目次
第1章:Volume Shadowingにおけるホストベース・ミニマージ
PDF
OpenVMS ホーム
ここから本文が始まります

目次

1.1 HBMM の構成要件
1.2 HBMM の制限事項
1.2.1 クラスタ構成の制限
1.2.2 シャドウ・セット・メンバの制限事項
1.2.3 システム・パラメータの制限事項
1.3 複合バージョンまたは複合アーキテクチャの OpenVMS Cluster システムでの HBMM
1.4 フル・マージ操作とミニマージ操作の概要
1.4.1 システム障害によるマージ
1.4.2 マウント・チェックのタイムアウトによるマージ
1.4.3 SET SHADOW/DEMAND_MERGE の使用によるマージ
1.4.4 マージ操作とミニマージ操作の比較
1.5 HBMM の概要
1.5.1 マスタ・ビットマップとローカル・ビットマップ
1.5.2 HBMM ポリシー
1.6 HBMM ポリシー指定の構文
1.7 HBMM ポリシーに適用される規則
1.8 HBMM ポリシーを確立するためのガイドライン
1.8.1 マスタ・ビットマップを保有するシステムの選択
1.8.2 ビットマップの RESET_THRESHOLD 値の設定
1.8.3 複数ポリシーの使用
1.9 HBMM の構成と管理
1.9.1 HBMM ポリシーの定義方法
1.9.2 シャドウ・セットへの HBMM ポリシーの割り当て方法
1.9.3 シャドウ・セットで HBMM を有効にする方法
1.9.4 シャドウ・セットで HBMM を無効にする方法
1.9.5 シャドウ・セットに関連付けられたポリシーの削除方法
1.9.6 シャドウ・セットに割り当てられたポリシーの変更方法
1.9.7 システムで HBMM を無効にする方法
1.9.8 名前付きポリシーをクラスタから削除する方法
1.9.9 変更した DEFAULT ポリシーの適用方法
1.9.10 ポリシーの表示方法
1.9.11 シャドウ・セットのマージ状態の表示方法
1.9.12 複数サイト OpenVMS Cluster システムでの留意事項
1.10 HBMM に影響を与える新しいシステム・パラメータ
1.10.1 SHADOW_REC_DLY パラメータ
1.10.2 SHADOW_HBMM_RTC パラメータ
1.11 HBMM が有効な場合の /DEMAND_MERGE の使用
1.12 マージ操作とコピー操作の優先順位付け
1.12.1 マージ操作とコピー操作のデフォルトの管理
1.12.2 一時状態の操作の階層
1.12.3 優先順位の割り当て
1.12.4 優先順位値の表示
1.12.5 どのシステムがマージ操作やコピー操作を行うかを制御する
1.12.6 マージ操作の管理
1.12.7 コピー操作の管理
1.12.8 実行中の一時状態の管理
1.13 一時状態イベントの目に見える影響

ここでは,以下の内容について説明します。

  • HBMM の構成要件

  • HBMM の制限事項

  • 複合バージョンまたは複合アーキテクチャの OpenVMS Cluster システムでの HBMM

  • フル・マージ操作とミニマージ操作の概要

  • ホスト・ベース・ミニマージ (HBMM) の概要

  • HBMM ポリシー指定の構文

  • HBMM ポリシーに適用される規則

  • HBMM ポリシーを確立するためのガイドライン

  • HBMM の構成と管理

  • HBMM に影響を与える新しいシステム・パラメータ

  • HBMM が有効な場合の /DEMAND_MERGE の使用

  • マージ操作とコピー操作の優先順位付け

  • 一時状態イベントの目に見える影響

HBMM 機能に加え,マージ操作とコピー操作に優先順位を付ける新しい機能を,1.12 項 「マージ操作とコピー操作の優先順位付け」で説明します。

1.1 HBMM の構成要件

OpenVMS Cluster システムで HBMM を有効にするための構成要件は,以下のとおりです。

  • Alpha および HP Integrity サーバ・システムで構成されるクラスタでは,すべての HP Integrity サーバ・システムで OpenVMS I64 バージョン 8.2 が動作し,またすべての OpenVMS Alpha システムで OpenVMS Alpha バージョン 7.3-2 またはバージョン 8.2 が動作している必要があります。

  • Alpha システムと VAX システムで構成されるクラスタでは,すべての Alpha システムで OpenVMS Alpha バージョン 7.3-2 以降が動作し,またすべての VAX システムで OpenVMS VAX バージョン 7.3 が動作している必要があります。

    Alpha システムと HP Integrity サーバ・システムでサポートされる OpenVMS Cluster 構成については, 『新機能説明書』を参照してください。

  • 1.5.1 項 「マスタ・ビットマップとローカル・ビットマップ」で説明しているように,ビットマップをサポートするために十分なメモリが利用できる必要があります。

1.2 HBMM の制限事項

OpenVMS Cluster システムでの HBMM の構成と運用に関しては,以下の制限があります。

1.2.1 クラスタ構成の制限

HBMM が有効になったシャドウ・セットは,HBMM 機能を持つシステムだけにマウントできます。 書き込みビットマップをサポートしているバージョンの OpenVMS が動作するシステムは,HBMM をサポートしているシステムと同じクラスタ内に混在できますが,HBMM が有効になっているシャドウ・セットをこれらのシステムにマウントすることはできません。 以下のバージョンの OpenVMS は書き込みビットマップをサポートしていますが,HBMM はサポートしていません。

  • OpenVMS VAX バージョン 7.3 システム

  • OpenVMS Alpha バージョン 7.2-2 からバージョン 7.3-2 (バージョン 7.3-2 では,Volume Shadowing HBMM kit をインストールすることで,HBMM がサポートされます。 この機能は現在フィールド・テスト中です)。

OpenVMS バージョン 8.2 では,移行構成または保証構成でサポートされる最も古い OpenVMS Alpha のバージョンは,OpenVMS Alpha バージョン 7.3-2 です。

注意:

書き込みビットマップをサポートしていないシステムをクラスタに参加させると,HBMM が無効となり,既存の HBMM およびミニコピーのビットマップがすべて削除されます。

1.2.2 シャドウ・セット・メンバの制限事項

HBMM は,Volume Shadowing for OpenVMS がサポートするすべてのディスクで使用できますが,HSJ,HSC,HSD コントローラでは使用できません。

1.2.3 システム・パラメータの制限事項

ホスト・ベース・ミニマージ操作は,そのシャドウ・セットに対する HBMM マスタ・ビットマップを持っているシステムでのみ実行できます。 シャドウ・セットに対するマスタ・ビットマップを持つすべてのシステムで,システム・パラメータ SHADOW_MAX_COPY にゼロを設定すると,HBMM はどのシステムでも実行されません。

さらに,たとえ SHADOW_MAX_COPY に 1 以上を設定しても,シャドウ・セットがマウントされているほかのシステム (マスタ・ビットマップを持たないシステム) では,フル・マージは実行されません。

HBMM マスタ・ビットマップを持つシステムと持たないシステムの両方にマウントされるシャドウ・セットでマージが必要な場合,そのシャドウ・セットが HBMM マスタ・ビットマップを持つシステムにマウントされている限り,HBMM マスタ・ビットマップを持たないシステムではマージは実行されません。 このような状況から回復させる方法については,1.12.8 項 「実行中の一時状態の管理」を参照してください。

1.3 複合バージョンまたは複合アーキテクチャの OpenVMS Cluster システムでの HBMM

HBMM は,OpenVMS Alpha バージョン 8.2 および OpenVMS I64 バージョン 8.2 でサポートされます。 また,HBMM Kit をインストールした OpenVMS Alpha バージョン 7.3-2 でもサポートされます。

HBMM では,すべてのクラスタ・メンバが HBMM をサポートしている必要はありませんが,すべてのクラスタ・メンバが書き込みビットマップをサポートしている必要があります。

書き込みビットマップをサポートしている以前のバージョンの OpenVMS には以下のものがあります。

  • OpenVMS Alpha バージョン 7.2-2 以降

  • OpenVMS VAX バージョン 7.3

クラスタ内のシステムが書き込みビットマップをサポートしていない場合,そのクラスタでは,HBMM とミニコピー機能のどちらも利用できません。 さらに,書き込みビットマップをサポートしているメンバで構成されるクラスタに,書き込みビットマップをサポートしていないシステムが参加すると,既存のすべての HBMM およびミニコピーのビットマップが削除されます。

いったん HBMM 機能を持ったシステムがシャドウ・セットをマウントすると,HBMM の利用が有効になり,HBMM 機能を持ったクラスタ・メンバだけがそのシャドウ・セットをマウントできるようになります。

ミニコピーでは,すべてのクラスタメンバがミニコピーをサポートしている必要があるのに対し,HBMM では,すべてのメンバが書き込みビットマップをサポートしていればよく,全メンバが HBMM をサポートしている必要はありません。

拡張シャドウイング機能

この制限を強制するため (および将来の拡張に備えるため),HBMM 機能を使用しているシャドウ・セットには,拡張シャドウイング機能を持っていることがマークされます。 このマークは,以下の例に示すように,使用中の特殊機能としてSHOW SHADOW DSAn の表示に含まれます。

$ SHOW SHADOW DSA0 
_DSA0:    Volume Label: TST0
  Virtual Unit State:   Steady State
  Enhanced Shadowing Features in use:
    Host-Based Minimerge (HBMM) 

  VU Timeout Value      3600    VU Site Value          0
  Copy/Merge Priority   5000    Mini Merge       Enabled
  Served Path Delay     30

  HBMM Policy
    HBMM Reset Threshold: 50000
    HBMM Master lists:
      Any 1 of the nodes: CSGF1,CSGF2
    HBMM bitmaps are active on CSGF1
    Modified blocks since bitmap creation: 254

  Device $252$DKA0
    Read Cost             2     Site 0
    Member Timeout        10

 Device $252$DKA100            Master Member
   Read Cost             501   Site 0
   Member Timeout        10
$

いったんシャドウ・セットが拡張シャドウイング機能を使用しているとマークされると,クラスタ内の全システムでディスマウントされるまではそのままになります。 シャドウ・セットをマウントし直したときに,要求されている機能が再評価されます。 シャドウ・セットで拡張機能がもはや使用されていない場合は,その旨表示され,このシャドウ・セットは拡張機能をサポートしていないノードでもマウントできるようになります。

HBMM 機能を持っていないシステムは,HBMM シャドウ・セットのマウントに失敗します。 ただし,指定されたシャドウ・セットで HBMM が使用されていない場合は,HBMM 機能を持っていない以前のバージョンの OpenVMS でも,そのシャドウ・セットをマウントできます。

マウント・ユーティリティのメッセージ

ビットマップをサポートしているものの HBMM 機能を持っていないシステムで,HBMM シャドウ・セットに対して MOUNT コマンドを実行すると,エラー・メッセージが表示されます。 (1.2 項 「HBMM の制限事項」に示すように,ビットマップをサポートしているバージョンの Volume Shadowing for OpenVMS が動作し,HBMM 機能を持っていないシステムは,HBMM をサポートしているシステムのクラスタのメンバになることは可能ですが,HBMM シャドウ・セットをマウントすることはできません。)

メッセージは,シャドウ・セット内のメンバの数と,マウント方法によって異なります。 Mount ユーティリティがコマンドをリトライしている間 (30 秒程度) ハングしているように見えますが,その後でエラーとなります。

HBMM シャドウ・セットをマウントできなかった Mount ユーティリティが生成するエラーには,以下のものがあります。

 
%MOUNT-F-DEVBUSY, mount or dismount in progress on device 
%MOUNT-F-XSMBRS, maximum number of shadow members exceeded

遅延をなくしてより有用なメッセージを表示してくれる,Mount ユーティリティの修正キットが,ビットマップをサポートする以前のバージョンの OpenVMS 用に,将来リリースされます。

いったんシャドウ・セットが HBMM シャドウ・セットとしてマークされると,クラスタ内の全システムでディスマウントされるまでマークされたままになります。 シャドウ・セットをマウントし直す際,そのシャドウ・セットがもはや HBMM を使用していなければ,HBMM 機能を持たない以前のバージョンの OpenVMS にマウントできます。

1.4 フル・マージ操作とミニマージ操作の概要

フル・マージやミニマージの回復操作の目的は,シャドウ・セット・メンバのデータを比較して,すべてのメンバの全論理ブロックのデータを一致させることです。 各ブロックは,論理ブロック番号 (LBN) で識別されます。 回復操作の際,アプリケーションの入出力は継続されますが,速度は遅くなります。 フル・マージ操作やミニマージ操作は,シャドウ・セットがマウントされている OpenVMS システムのいずれかで管理されます。 本書では,ミニマージ操作マージ操作は,それぞれミニマージ回復操作とマージ回復操作を指します。

フル・マージ操作やミニマージ操作は,以下の場合に開始されます。

  • システムで障害が発生したため,アプリケーションの書き込みが不完全になった可能性がある場合。

  • シャドウ・セットでマウント・チェックが開始され,特定の条件下でマウント・チェックがタイムアウトになるか異常終了した場合 (1.4.2 項 「マウント・チェックのタイムアウトによるマージ」を参照)。

  • システム管理者が SET SHADOW/DEMAND_MERGE コマンドを実行した場合。

1.4.1 システム障害によるマージ

シャドウ・セットをマウントしているシステムで障害が発生した際に,シャドウ・セットに対して書き込み要求を出し,完了状態がアプリケーションに返される前にシステムが障害となったとすると,シャドウ・セットのメンバ間でデータの不整合が起こる可能性があります

  • すべてのメンバが新しいデータを持っている。

  • すべてのメンバが古いデータを持っている。

  • いくつかのメンバは新しいデータを持っており,残りのメンバは古い データを持っている。

どの状態になるかは,オリジナルの書き込み要求の処理中に障害が発生したタイミングによって決まります。 システムの回復動作の際に,Volume Shadowing for OpenVMS は,各シャドウ・セット・メンバ上の対応する LBN に同じデータ (古いデータまたは新しいデータ) が格納された状態にします。

注意:

Volume Shadowing for OpenVMS は,シャドウ・セットの全メンバでデータが同じであることを保証しますが,システム障害が発生したときに実行中だった書き込み要求がシャドウ・セットに記録されることは保証しません。 障害が発生したタイミングによっては,最後の書き込み要求のデータがボリュームに格納されている可能性もあります。 この点に関しては,シャドウ・セットもシャドウ化されていないストレージ・デバイスと違いはありません。 アプリケーションは,どちらの場合にも正しく機能するように設計する必要があります。

1.4.2 マウント・チェックのタイムアウトによるマージ

マウント・チェックが開始され,マウント・チェックがタイムアウトになるか異常終了した場合は,以下の条件が真であればマージ状態になります。

  • タイムアウトになったシステムのシャドウ・ドライバの内部キューに,未完了の書き込み入出力要求がある場合。

  • そのシャドウ・セットがクラスタ内のほかのシステムにマウントされている場合。

マウント・チェックがタイムアウトになった (またはマウント・チェックが異常終了した) システムは,そのシャドウ・セットをマウントしているほかのシステムにマージ操作が必要であることを通知し,シャドウ・セットをディスマウントします。

たとえば,シャドウ・セットが 8 台のシステムにマウントされていて,そのうち 2 台のシステムでマウント・チェックのタイムアウトが発生した場合,これら 2 台のシステムは,内部キューに書き込み入出力がないか確認します。 書き込み入出力が見つかると,そのシャドウ・セットはマージが必要となります。

1.4.3 SET SHADOW/DEMAND_MERGE の使用によるマージ

SET SHADOW/DEMAND_MERGE コマンドは,指定されたシャドウ・セットまたは全シャドウ・セットのマージを開始します。 この修飾子は,INITIALIZE/SHADOW コマンドで /ERASE 修飾子を指定せずにシャドウ・セットを作成した場合に便利です。

SET SHADOW コマンドは OpenVMS Alpha バージョン 7.3-2 で導入されました。 SET SHADOW/DEMAND_MERGE の使用方法の詳細は, 『DCL ディクショナリ』および『Volume Shadowing for OpenVMS 説明書』 を参照してください。

1.4.4 マージ操作とミニマージ操作の比較

フル・マージ操作では,シャドウ・セットのメンバが互いに比較され,同じデータが格納されていることが保証されます。 これは,ボリューム全体にわたってブロックごとの比較を行うことで実現されます。 しかし,この操作は長時間を要する可能性があります。

これに対し,ミニマージ操作は非常に高速です。 揮発性のコントローラ・ストレージまたは OpenVMS システム上の書き込みビットマップに記録されている書き込み操作の情報を使用して,ボリューム・シャドウイングでは,書き込み操作が行われたと分かっているシャドウ・セットの領域だけをマージします。 これにより,フル・マージ操作で必要となるボリューム全体の走査が不要となり,システム I/O リソースの消費を減らすことができます。

HBMM が導入される前は,ミニマージはコントローラ・ベースで実行されるため,HSJ,HSC,および HSD コントローラでしか利用できませんでした。

1.5 HBMM の概要

HBMM は,ミニマージ操作に必要な情報を提供してくれるビットマップとポリシーに依存します。 ユーザのシステム環境によっては,HBMM の DEFAULT ポリシーを 1 つ指定するだけで十分な場合もあります。

HBMM を使用してシャドウ・セットを回復させるためには,以下の条件を満たしている必要があります。

  • HBMM ポリシーが存在すること。

  • HBMM ポリシーがシャドウ・セットに関連付けられていること。

  • HBMM ポリシーで指定された 1 台以上のシステムにシャドウ・セットがマウントされていること。

シャドウ・セットにポリシーが関連付けられ,シャドウ・セットが複数のシステムにマウントされていれば,そのシャドウ・セット専用のビットマップが作成されます。

HBMM ポリシー定義で指定されたマスタ・リストから選ばれたシステムは,マスタ・ビットマップを保有しているため,ミニマージ操作を実行することができます。 シャドウ・セットがマウントされているその他のシステムは,各マスタ・ビットマップに対するローカル・ビットマップを保有しています。

1.5.1 マスタ・ビットマップとローカル・ビットマップ

各ビットマップにつき,マスタ・バージョンがクラスタ内のいずれかのシステムに 1 つだけ存在し,関連付けられたシャドウ・セットをマウントしているほかのシステムは,すべてローカル・バージョンを持ちます。 ミニマージ操作は,マスタ・ビットマップを持っているシステムだけが実行できます。 1 つのシャドウ・セットは,最大 6 つまでの HBMM マスタ・ビットマップを持つことができます。 同じシャドウ・セットに対して複数のマスタ・ビットマップがある場合,内容は同じですが,ビットマップ ID は違っています。

以下の例は,DSA12 に対する 2 つのマスタ・ビットマップです。 1 つは BLZZRD 上,もう 1 つは SCSI5 上にあり,固有のビットマップ ID を持っています。

$ SHOW DEVICE/BITMAP DSA12 

Device         BitMap    Size     Percent      Type of   Master  Active
Name            ID     (Bytes)   Populated     Bitmap     Node
DSA12:        00020007     8364        0%     Minimerge  RAIN      Yes
              00010008     8364        0%     Minimerge  SNOW     Yes

シャドウ・セットにマスタ・ビットマップが 1 つしかなく,マスタ・ビットマップを持ったシステムが障害になるかシャットダウンすると,ビットマップが失われてしまい,ほかのローカル・バージョンも自動的に削除されます。 ローカル・ビットマップは回復操作では使用できません。

シャドウ・セットに対して複数のマスタ・ビットマップが作成されており,少なくとも 1 つが残っていれば,そのマスタ・ビットマップを使用して回復させることができます。 特に複数サイト・クラスタ・システムでは,複数のマスタ・ビットマップを使用することをお勧めします。 マスタ・ビットマップが複数あれば,システム障害が発生した際に,フル・マージではなく HBMM 操作ですむ可能性が高くなります。

ビットマップには追加のメモリが必要です。 必要な量は,シャドウ・セットのボリューム・サイズに基づいて計算します。 システムにマウントされているシャドウ・セットのストレージ 1 GB ごとに,各ビットマップに対して,ビットマップ・メモリ 2KB がシステムで必要になります。 たとえば,ボリューム・サイズが 200 GB でビットマップが 2 つのシャドウ・セットでは,このシャドウ・セットをマウントしている各システムで,800 KB のメモリが使用されます。

1.5.2 HBMM ポリシー

ポリシーは,1 つ以上のシャドウ・セットについて以下の属性を指定します。

  • マスタ・ビットマップを保有する権利を持つシステムの名前。

  • マスタ・ビットマップを保有するシステムの数 (6 以下)。 この数を省略すると,指定したシステムの最初の 6 システムが選択されます。

  • ビットマップがリセットされるしきい値(512 バイト・ブロック単位)。 省略すると,デフォルトで 50,000 ブロックになります。

ポリシーには名前を付けることができます。 特定の属性を持つ予約名 DEFAULT および NODEFAULT を指定することもできます(1.7 項 「HBMM ポリシーに適用される規則」を参照)。 名前のないポリシーを作成して特定のシャドウ・セットに割り当てることもできます。 名前付きポリシーの利点は,名前を指定するだけで再利用できることです。

複数のポリシーを作成し,クラスタでのミニマージ操作をカスタマイズすることができます。

ポリシーの定義,割り当て,割り当て解除,削除を行い,シャドウ・セット上で HBMM を有効にしたり無効にするには,SET SHADOW/POLICY コマンドに HBMM 固有の修飾子を指定して実行します。 SET SHADOW/POLICY は,HBMM ポリシーを指定するための唯一のユーザ・インタフェースです。 MOUNT コマンドを使用してポリシーを定義することはできません。 ポリシーは,シャドウ・セットをマウントする前に定義することができます。(1.7 項 「HBMM ポリシーに適用される規則」で説明しているように,ほかの方法を使用してポリシーをシャドウ・セットに関連付けることもできます。)

1.6 HBMM ポリシー指定の構文

HBMM ポリシー指定は,HBMM ポリシー・キーワードのリストを括弧で囲んだ形式で指定します。 HBMM ポリシー・キーワードは,MASTER_LIST,COUNT,および RESET_THRESHOLD です。 3 つのキーワードのうち,MASTER_LIST だけが必須です。 COUNT や RESET_THRESHOLD を省略すると,デフォルト値が使用されます。

ここでは,これらのキーワードの使用方法と指定する際の規則を説明します。

MASTER_LIST=system-list

MASTER_LIST キーワードは,マスタ・ビットマップを保有する候補とするシステム (複数可) を指定するために使用します。system-list の値は,単一のシステム名,コンマで区切ったシステム名のリストを括弧で囲んだもの,またはワイルドカード文字のアスタリスク (*) です。 例:

  • MASTER_LIST=node1

  • MASTER_LIST=(node1,node2,node3)

  • MASTER_LIST=*

システム・リストが単一のシステムまたはワイルドカード文字である場合は,括弧は省略できます。

HBMM ポリシーには,少なくとも 1 つの MASTER_LIST が含まれている必要があります。 マスタ・リストを複数指定するかどうかは任意です。 1 つのポリシーにマスタ・リストが複数ある場合は,次の例のように,ポリシー全体を括弧で囲み,それぞれのマスタ・リストをコンマで区切る必要があります。

(MASTER_LIST=(node1,node2), MASTER_LIST=(node3,node4))

マスタ・リスト内のシステム名の順番には意味はありません。

COUNT=n

COUNT キーワードは,マスタ・システム・リストに記述したシステムのうち,何台のシステムをマスタ・ビットマップ・システムとして選ぶかを指定します。 したがって COUNT キーワードは,特定のマスタ・リストとともに括弧で囲み,マスタ・リストに関連付ける必要があります。

COUNT に値 n を指定すると,関連付けられたマスタ・リスト内の任意の n 台のシステムでマスタ・ビットマップを保有することを意味します。 必ずしもリスト内の最初の n 台のシステムが選択ばれるわけではありません。

COUNT キーワードは省略可能です。 省略すると,マスタ・リスト内のシステムの数と 6 のうち小さい方がデフォルトで使用されます。 1 つのマスタ・リストに対して 2 つ以上の COUNT キーワードを指定することはできません。

以下の 2 つは正しいポリシーの例です。

(MASTER_LIST=(node1,node2,node3), COUNT=2)
((MASTER_LIST=(node1,node2,node3),COUNT=2),(COUNT=2, MASTER_LIST=(system4,system5,system6))) 

一方,次の例では COUNT キーワードを特定のマスタ・リストとグループ化していないため,正しくありません。

(MASTER_LIST=(node1,node2), MASTER_LIST=(node4,node5), COUNT=1) 

RESET_THRESHOLD=n

RESET_THRESHOLD キーワードは,ビットマップがクリア対象になる前に設定することができるブロックの数を指定します。 マスタ・ビットマップに設定される各ビットは,マージが必要なブロックに対応しています。 したがって,マージ時間はこの値の影響を受けます。

RESET_THRESHOLD を超えると,ビットマップはクリア対象となります。 ただし,しきい値を超えてもすぐにリセットされるとは限りません。 この属性の値をいくつに設定すればよいかについては,1.8.2 項 「ビットマップの RESET_THRESHOLD 値の設定」および1.10.2 項 「SHADOW_HBMM_RTC パラメータ」を参照してください。

HBMM ポリシーに対してはリセットしきい値を 1 つだけ関連付けます。 このため,1 つのポリシーに対して RESET_THRESHOLD キーワードを複数指定することはできません。 RESET_THRESHOLD キーワードの範囲がポリシー全体であるため,ポリシーに複数のマスタ・リストを指定するときに,このキーワードをマスタ・リストに対応付けて指定することはできません。

RESET_THRESHOLD キーワードを省略すると,デフォルト値として 50000 が使用されます。

次のポリシーの例では,明示的にリセットしきい値を指定しています。

(MASTER_LIST=*, COUNT=4, RESET_THRESHOLD=100000)

1.7 HBMM ポリシーに適用される規則

HBMM ポリシーの作成と管理には,以下の規則が適用されます。 各規則では,HBMM をサポートしているシステムにシャドウ・セットがマウントされることを前提にしています。

ポリシーとその属性

  • ポリシーは属性を指定するだけで,シャドウ・セットに割り当てることができます。 このようにして割り当てることができるポリシーの数は,システムでサポートされるシャドウ・セットの数によってのみ制限されます。

  • シャドウ・セットには,同時に 1 つしか HBMM ポリシーを割り当てることができません。

  • ポリシーはクラスタ・ワイドに有効になります。

  • ポリシー名は,以下の規則に従っている必要があります。

    • ポリシー名は長さが 1 ~ 64 文字で,大文字と小文字は区別されません。

    • 英字,数字,ドル記号 ($),アンダスコア (_) だけが使用できます。

  • ポリシー名は完全な名前で指定する必要があり,省略形は許されません。

  • 名前付きポリシーは,SET SHADOW/POLICY=HBMM=policy-name コマンドでのみシャドウ・セットに割り当てることができます。

  • ユーザ定義の名前付きポリシーは,最大 128 個まで定義できます。

DEFAULT ポリシーと NODEFAULT ポリシー

名前付きポリシー DEFAULT および NODEFAULT には特殊なプロパティがあります。 これについて以降の項で概要を説明します。

  • DEFAULT

    • DEFAULT ポリシーは,クラスタ内の大多数のシャドウ・セットで同じポリシーを使用する場合に便利です。

    • DEFAULT ポリシーは,予約名 DEFAULT を使用して名前付きポリシーを定義することで作成できます。 あらかじめ定義された DEFAULT ポリシーはありません。

    • 予約名 DEFAULT を持つポリシーを定義すると,このポリシーは,以下のいずれかの操作でシャドウ・セットに関連付けられます。

      • ポリシーが関連付けられていないシャドウ・セットのマウント

        DEFAULT ポリシーが定義されていると,ポリシーが割り当てられていない (NODEFAULT ポリシーも含む) シャドウ・セットに割り当てられます。 たとえば,HBMM 機能を持つシステムにシャドウ・セット DSA1 をマウントする際,DSA1 に固有の HBMM ポリシーがあれば,それを適用しようとします。(デバイス固有のポリシーが存在するか確認したり,特定のポリシーを表示する方法については,1.9.10 項 「ポリシーの表示方法」を参照してください。)

        DSA1 用のポリシーが定義されていない場合は,DEFAULT ポリシーの適用が試みられます。 DEFAULT ポリシーが存在すれば,そのポリシーの属性が DSA1 に適用されます。

      • ポリシーが関連付けられていないシャドウ・セットのマージ完了時

      • SET SHADOW/ENABLE=HBMM コマンドを実行した場合

    • シャドウ・セットにポリシーが関連付けられており,そのポリシーの関連付けが削除されると,クラスタに対して DEFAULT ポリシーが定義されていれば,DEFAULT ポリシーの適用対象となります。

  • NODEFAULT ポリシー

    • NODEFAULT ポリシーは,このポリシーを適用するシャドウ・セットでは HBMM を使用しないことを指定します。 したがって,このシャドウ・セットに対しては,クラスタのどこにも HBMM ビットマップが作成されません。

    • DEFAULT ポリシーが定義されているクラスタでは,NODEFAULT ポリシーを使用して,特定のシャドウ・セットにデフォルト・ポリシーを適用しないようにすることができます。

    • NODEFAULT ポリシーは,削除したり再定義することはできません。

ポリシーの割り当てと有効化

  • ポリシーは,クラスタ内の任意のシステムがシャドウ・セットをマウントする前に,シャドウ・セットに割り当てることができます。

  • ポリシーが割り当てられている場合,ビットマップ・マスタ・システムにシャドウ・セットが最初にマウントされたときに,ポリシーが有効になります。

  • ポリシーを割り当てることで,マスタ・ビットマップ・システムになることができるシステム上にシャドウ・セットがマウントされた時に,マウントされたシャドウ・セット上で HBMM が暗黙で有効になります。 DSA1 がシステム MAPLE にマウントされている場合を考えてみます。 DSA1 をマウントしたとき,DSA1 に対して HBMM ポリシーは設定されておらず,適用する DEFAULT ポリシーもなかったとします。 その後,次のコマンドを実行します。

    $ SET SHADOW DSA1:/POLICY=HBMM=(MASTER=(MAPLE), COUNT=1)
    

    DSA1 はシステム MAPLE にすでにマウントされているため,HBMM ポリシーを割り当てた結果 HBMM が有効になります (1.9.2 項 「シャドウ・セットへの HBMM ポリシーの割り当て方法」を参照)。

  • マスタ・ビットマップを持つシステムでシャドウ・セットがマウントされていないか,ポリシーが定義されていない場合,SET SHADOW DSAn /ENABLE=HBMM コマンドで HBMM を有効にしようとしても,失敗します。

  • 新しいシステムがクラスタに参加したときには,そのクラスタに現在あるポリシーが継承されます。

ポリシーの変更

  • 名前付きのポリシーは,自由に作成,変更,削除できます。 名前付きポリシーを変更しても,その名前付きポリシーの以前のバージョンを使用してマウントしたシャドウ・セットには,その変更は引き継がれません

  • シャドウ・セットで HBMM が有効になっている場合は,ポリシーとマウント済みシャドウ・セットの関係は変更できません。 そのシャドウ・セットで HBMM を無効にした後でないと,そのシャドウ・セットに別のポリシーを割り当てることはできません。

  • ポリシーの変更はクラスタ・ワイドに有効です。

ポリシーの有効期間

  • どのポリシーも,少なくとも 1 台のシステムが動作中であれば,そのクラスタで有効です。 しかし,すべてのシステムがシャットダウンすると,すべてのポリシー定義と関連付けは消えます。 システムでクラスタを形成する時に,再度ポリシーを定義して割り当てる必要があります。 そのため,システム・スタートアップ・プロシージャの中で,必要な HBMM ポリシーを定義することをお勧めします。

  • ポリシーの割り当ては,HBMM を無効にしたり,シャドウ・セットをディスマウントしても,クラスタ内で 1 台以上のシステムが動作している限り持続します。

1.8 HBMM ポリシーを確立するためのガイドライン

HBMM ポリシーを確立するプロセスは継続的であり,構成が変わり,HBMM の動作とそれがシステムのさまざまな運用に与える影響についての理解が深まるにつれて変化します。 ここで説明するいくつかの留意点は,さまざまな構成でどのようなポリシーが適しているかを判断するのに役立ちます。

設定はハードウェア構成やソフトウェア構成,システムの負荷,運用上の要件によって変わります。 これらのガイドラインは,お使いの構成に対する初期設定を選択するのに役立ちます。 お使いの構成で結果を観察して,システム環境に合わせてさらに調整を加えることができます。

1.8.1 マスタ・ビットマップを保有するシステムの選択

ポリシーで指定するマスタ・ビットマップの数と,マスタ・ビットマップを保有するホストを選ぶ際には,いくつかの検討要素があります。 最初の問題は,構成でマスタ・ビットマップをいくつ使用するかという点です。 シャドウ・セットごとの最大は 6 つです。 マスタ・ビットマップを追加するたびに,書き込み性能に若干の影響があり,各システムでメモリを消費します(1.5.1 項 「マスタ・ビットマップとローカル・ビットマップ」で説明したとおりです)。

マスタ・ビットマップを 1 つしか使用しないと,単一点障害ができることになり,マスタ・ビットマップを保有しているシステムが障害になると,シャドウ・セットでフル・マージが実行されることになります。 したがって,メモリ消費とフル・マージの悪影響を比較検討する必要があります。 マスタ・ビットマップを 6 つ使用すればフル・マージが必要になる可能性を最小限にすることができます。

マスタ・ビットマップを保有するシステムを選ぶ際のもう 1 つの問題は,さまざまなシステムの入出力の帯域幅です。 ミニマージは,必ずマスタ・ビットマップを持っているシステムで実行されることを心に留めておいてください。 したがって,サテライト・クラスタ・メンバのように帯域幅が狭いシステムは向いていません。

構成のディザスタ・トレランスも決定する際の重要な要素です。 複数のサイトの複数のシステムでマスタ・ビットマップを保有するように指定すれば,サイト全体の接続が失われた場合でもミニマージが実行されるようになります。 2 サイト構成ではマスタ・ビットマップ・システムの半分を各サイトに置くようにし,3 サイト構成ではマスタ・ビットマップの 1/3 ずつを 3 つのサイトに置くようにします。

1.8.2 ビットマップの RESET_THRESHOLD 値の設定

HBMM ビットマップでは,シャドウ・セットへの書き込みが常時記録されます。 ビットマップ中の設定されているビットの数が増えるほど,ミニマージの際に必要なマージ量も増えます。 HBMM では,ある条件 (1.10.2 項 「SHADOW_HBMM_RTC パラメータ」を参照) が満たされた場合にビットマップをクリアします (各メンバの整合をとるため,処理中の書き込みがすべて完了したことを確認した後)。 クリアされたばかりで設定されたビットが少ないビットマップでは,ミニマージがより速く実行できます。

ただし,ビットマップのリセットは,入出力性能面で負担がかかります。 ビットマップをリセットする前に,シャドウ・セットに対するすべての書き込み入出力を休止し,実行中の書き込み入出力の完了を待つ必要があります。 その後ビットマップがクリアされます。 この操作は,シャドウ・セットごとに全システムで実行されます。 そのため,頻繁にリセットが起きるようなしきい値の設定は避けてください。

実行されたリセットの回数は,次の例のように,SHOW SHADOW コマンドを使って確認することができます。

$ SHOW SHADOW DSA1031 
_DSA1031: Volume Label: HBMM1031 
  Virtual Unit State:   Steady State
  Enhanced Shadowing Features in use:
        Host-Based Minimerge (HBMM)

  VU Timeout Value      3600    VU Site Value          0
  Copy/Merge Priority   5000    Mini Merge       Enabled
  Served Path Delay     30

  HBMM Policy
    HBMM Reset Threshold: 50000
    HBMM Master lists:
      Up to any 2 of the systems: LEMON, ORANGE 
      Any 1 of the systems: MELON, PEACH 
    HBMM bitmaps are active on LEMON, MELON, ORANGE 
  HBMM Reset Count      76    Last Reset    29-JAN-2004 10:13:53.90
    Modified blocks since last bitmap reset: 40132

 .
 .
 .
$ 

ビットマップにビットを設定する必要があるような書き込みは,すでに書き込み済みとしてマークされている領域への書き込みよりも,若干遅くなります。 このため,あるシャドウ・セットへの書き込みの多くが「ホットな」ファイルに集中している場合は,リセットしきい値を大きくして,同じビットのセットとクリアが繰り返されないようにすることをお勧めします。

逆に,リセットしきい値が大きすぎると,HBMM の効果が薄れてしまいます。 たとえば,ビットマップの 50 % が設定されていると (つまり,最後にリセットされてから,シャドウ・セットの 50 % が書き込まれた),HBMM マージではフル・マージの約 50 % の時間がかかることになります。

リセットしきい値を選ぶ際には,ビットマップ・リセットによる入出力性能への影響と,HBMM ミニマージの実行にかかる時間の釣り合いをとる必要があります。 目標は,アプリケーションの入出力性能に影響を与えずに,リセット値をできるだけ小さくすることです(これによりマージ時間が短くなります)。 値が小さすぎると,入出力性能が低化します。 値が大きすぎると,マージに要する時間が長くなります。

1.8.3 複数ポリシーの使用

HBMM ポリシーは,マスタ・ビットマップ・システムに関する意思決定を実現するために定義します。 サイトによっては,単一のポリシーでも意思決定を効果的に実現できます。 ほかのサイトでは,より細かな指定が必要となり,複数のポリシーを作成することになります。

複数のポリシーが必要になるケースとして可能性が高いのは,クラスタに広帯域なシステムが十分あり,マージの負荷を分散させたい場合です。 ミニマージは,マスタ・ビットマップを保有しているシステム上でしか実行されないことを思い出してください。 そのため,広い帯域幅を持つ 12 台のシステムでミニマージ操作またはマージ操作を行うように設定する場合には (すべてのシステムでシステム・パラメータ SHADOW_MAX_COPY が 1 以上の場合),マスタ・ビットマップをこれらの広帯域幅システムに分散させるようにしてください。

複数の HBMM ポリシーは,各シャドウ・セットで異なるビットマップ・リセットしきい値が必要になる場合にも便利です。 各ポリシーでは,マスタ・ビットマップ・システムのリストはそのままに,しきい値を異なる値にすることができます。

1.9 HBMM の構成と管理

ここでは,HBMM を設定し管理するための主な作業を説明します。

1.9.1 HBMM ポリシーの定義方法

HBMM ポリシーを定義するには,SET SHADOW/POLICY=HBMM コマンドを使用します。 お使いの環境に対して,複数のポリシーを定義することができます。 以下の例で,2 つの名前付きポリシー,DEFAULT ポリシーと POLICY_1 ポリシーを定義する方法を示します。

DEFAULT という名前のポリシーを定義するには,次のようにします。

$ SET SHADOW/POLICY=HBMM=(MASTER_LIST=*)/NAME=DEFAULT

この例では,クラスタに対して DEFAULT ポリシーを作成します。 アスタリスク・ワイルドカード (*) は,任意のシステムがマスタ・ビットマップを保有できることを意味します。 キーワード COUNT=n を省略しているため,最大 6 台のシステムがマスタ・ビットマップを保有できることになります。 DEFAULT ポリシーは,シャドウ・セットに名前付きポリシーが割り当てられていない場合に,マウント時に継承されます。

以下の例では,名前付きポリシー (POLICY_1) を定義し,マスタ・ビットマップを保有する権利を持つシステムを指定し,マスタ・ビットマップを保有するシステムの数を 2 台に限定し,ビットマップをクリアするしきい値としてより大きな値を指定しています (デフォルトは 50,000 ブロック)。

$ SET SHADOW /POLICY=HBMM=( -
_$ (MASTER_LIST=(NODE1,NODE2,NODE3), COUNT=2), -
_$ RESET_THRESHOLD=100000) -
_$ /NAME=POLICY_1

SET SHADOW/POLICY=HBMM コマンドの完全な DCL 構文については,TBS を参照してください。

1.9.2 シャドウ・セットへの HBMM ポリシーの割り当て方法

名前付きポリシーまたは名前なしポリシーをシャドウ・セットに割り当てることができます。 既存の名前付きポリシーを割り当てるには,次のコマンドを使用します。

$ SET SHADOW DSAn:/POLICY=HBMM=policy-name

名前なしポリシーをシャドウ・セットに割り当てるのにも同じコマンドを使用しますが,ポリシー名の代わりに,使用したいポリシー属性を指定します。 たとえば次のようにします。

$ SET SHADOW DSA1:/POLICY=HBMM=(MASTER_LIST=(NODE1, NODE2, NODE3), COUNT=2)

この例では,RESET_THRESHOLD キーワードが省略されているため,ビットマップ・リセットしきい値は,デフォルトの 50,000 ブロックになります。

1.9.3 シャドウ・セットで HBMM を有効にする方法

HBMM は,以下の条件でシャドウ・セット上で自動的に有効になります。

  • シャドウ・セットをマウントする際に HBMM ポリシーが存在し,シャドウ・セットがマウントされているシステムの少なくとも 1 台が,ビットマップ・マスタ・システムである。

  • シャドウ・セットをマウントした後に HBMM ポリシーが作成され,シャドウ・セットがマウントされているシステムの少なくとも 1 台が,ビットマップ・マスタ・システムである。

また,ポリシーが存在し,シャドウ・セットがビットマップ・マスタ・システムにマウントされていれば,SET SHADOW/ENABLE=HBMM コマンドでも HBMM を有効にできます。

1.9.4 シャドウ・セットで HBMM を無効にする方法

シャドウ・セットで HBMM を無効にするには,次のコマンドを使用します。

$ SET SHADOW DSAn:/DISABLE=HBMM 

シャドウ・セットで HBMM を無効にする理由としては,以下のものが考えられます。

  • シャドウ・セットに関連付けられたポリシーを変更するため。

  • シャドウ・セットに関連付けられたポリシーを削除するため。

  • HBMM をサポートしていないシステムにそのシャドウ・セットをマウントするため。 HBMM をサポートしていないシステムにマウントするためには,まず HBMM を無効にし,次にそれをマウントしている HBMM 機能を持ったすべてのシステムからディスマウントする必要があります。

HBMM は,再度有効にするか,そのシャドウ・セットに対して新しいポリシーを定義するまで,無効のままになります。

1.9.5 シャドウ・セットに関連付けられたポリシーの削除方法

シャドウ・セットに関連付けられたポリシーを削除する前に,HBMM が有効な場合には無効にする必要があります。 その後,次のコマンドを入力して,シャドウ・セットからポリシーの関連付けを削除することができます。

$ SET SHADOW DSAn:/POLICY=HBMM/DELETE

このコマンドは,このシャドウ・セットに設定された任意のポリシーを削除し,シャドウ・セットを初期 HBMM 状態に戻します。 それと同時に,シャドウ・セットは DEFAULT ポリシーの対象となります。

1.9.6 シャドウ・セットに割り当てられたポリシーの変更方法

シャドウ・セットに割り当てられたポリシーを変更するには,1.9.4 項 「シャドウ・セットで HBMM を無効にする方法」に従い,まず HBMM を無効にしてから,シャドウ・セットに別のポリシーを割り当てます。 別のポリシーを割り当てるには,1.9.2 項 「シャドウ・セットへの HBMM ポリシーの割り当て方法」で説明しているように,名前付きポリシーを指定するか,ポリシー属性を指定します (これにより「名前なし」ポリシーを作成)。 シャドウ・セットに対して新しいポリシー (またはポリシー属性) を指定することで,以前のポリシーが置き換えられます。 ポリシーの割り当てを変更する際には,1.9.5 項 「シャドウ・セットに関連付けられたポリシーの削除方法」に示すコマンドを使用する必要はありません。

1.9.7 システムで HBMM を無効にする方法

システムで HBMM を無効にする方法には次の 2 つがあります。

  • SHADOW_MAX_COPY に 0 を設定

  • システムにマウントされている各システムで SET SHADOW/PRIORITY=0 DSAn コマンドを実行し,各シャドウ・セットでのマージ操作とコピー操作の優先順位にゼロを設定する。

1.9.8 名前付きポリシーをクラスタから削除する方法

名前付きポリシーを削除するには,次の例に示すように,/DELETE 修飾子を使用します。

$ SET SHADOW /POLICY=HBMM/NAME=policy-name/DELETE

このコマンドを実行すると,指定した名前のポリシーが削除され,クラスタ全体に影響が現れます。 割り当て済みのポリシーがシャドウ・セットから削除されることはありません。

注意:

NODEFAULT ポリシーを削除することはできません。

1.9.9 変更した DEFAULT ポリシーの適用方法

DEFAULT ポリシーは,いつでも変更することができます。 ただし,以前の DEFAULT の定義がシャドウ・セットに割り当てられていると,それ以降 DEFAULT ポリシーを変更しても,そのシャドウ・セットまでさかのぼって変更されることはありません。 この点で,DEFAULT ポリシーは他の名前付きポリシーと同じように振る舞います。

ここでは,変更した DEFAULT ポリシーを適用する方法を説明します。

まず,DSA20 をマウントしたときに次のように DEFAULT ポリシーが関連付けられたとします。

$ SET SHADOW/POLICY=HBMM=(MASTER=(NODE1,NODE2,NODE3),COUNT=2)/NAME=DEFAULT
$ MOUNT/SYSTEM DSA20:/SHADOW=($1$DGA20,$1$DGA21) VOL_20

その後,次のコマンドにより DEFAULT ポリシーが再定義されました。 この再定義されたポリシーでは,クラスタ内のどのノードも HBMM マスタ・ビットマップを保有する権利があります。

$ SET SHADOW/POLICY=HBMM=(MASTER=*,COUNT=2)/NAME=DEFAULT

この場合,以下のコマンドを使用して,再定義された DEFAULT ポリシーを DSA20 に適用することができます。

$ SET SHADOW DSA20:/DISABLE=HBMM
$ SET SHADOW DSA20:/POLICY=HBMM/DELETE
$ SET SHADOW DSA20:/ENABLE=HBMM

DSA20 を最新の DEFAULT ポリシーの対象にするためには,DSA20 に関連付けられた HBMM ポリシーを明示的に削除しなくてはならない点に注意してください。 この手順が必要になるのは,DSA20 上で HBMM を無効にしても,ポリシー (MASTER=(NODE1,NODE2,NODE3),COUNT=2) は DSA20 に関連付けられたままになるためです。

更新後の DEFAULT ポリシーを DSA20 に適用するもう 1 つの方法は,DEFAULT ポリシーが名前付きポリシーであることを利用する方法です。 この方法では,次に示すように 2 つのコマンドだけで済みます。

$ SET SHADOW DSA20:/DISABLE=HBMM
$ SET SHADOW DSA20:/POLICY=HBMM=DEFAULT

1.9.10 ポリシーの表示方法

ポリシーは,SHOW SHADOW コマンドで表示することができます。 以下の内容を表示できます。

  • 指定したシャドウ・セットに関連付けられているポリシー

  • 名前付きポリシーの定義

  • クラスタ内でポリシーが割り当てられている全シャドウ・セットと,各ポリシーの定義

  • クラスタに存在するすべての名前付きポリシーとその定義

特定のシャドウ・セットのポリシーの表示

特定のシャドウ・セットに関連付けられたポリシーを表示するには,次のコマンドを実行します。

$ SHOW SHADOW DSAn:/POLICY=HBMM 

出力結果の例を以下に示します。

$ SHOW SHADOW DSA999:/POLICY=HBMM
HBMM Policy for device _DSA999:
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2,NODE3
  Any 1 of the nodes: NODE4,NODE5
  Up to any 2 of the nodes: NODE6,NODE7,NODE8

名前付きポリシーの定義の表示

名前付きポリシーの定義を表示するには,次のコマンドを実行します。

$ SHOW SHADOW/POLICY=HBMM/NAME=policy-name 

以下の表示では,PEAKS_ISLAND ポリシーの定義が表示されています。

$ SHOW SHADOW/POLICY=HBMM/NAME=PEAKS_ISLAND
HBMM Policy PEAKS_ISLAND  
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2,NODE3
  Any 1 of the nodes: NODE4,NODE5
  Up to any 2 of the nodes: NODE6,NODE7,NODE8

ポリシーが割り当てられているすべてのシャドウ・セットの表示

クラスタ内でポリシーが割り当てれれている全シャドウ・セットと,各ポリシーの定義を表示するには,次のコマンドを実行します。

$ SHOW SHADOW/POLICY=HBMM 

このコマンドを実行すると,以下のように表示されます。

$ SHOW SHADOW/POLICY=HBMM 
HBMM Policy for device _DSA12:
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2
 HBMM bitmaps are active on NODE1,NODE2
 Modified blocks since bitmap creation: 254

HBMM Policy for device _DSA30:
 HBMM Reset Threshold: 50000
 HBMM Master lists:                                         
  Up to any 2 of the nodes: FLURRY,FREEZE,HOTTUB

HBMM Policy for device _DSA99:
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2,NODE3
  Any 1 of the nodes: NODE4,NODE5
  Up to any 2 of the nodes: NODE6,NODE7,NODE8

HBMM Policy for device _DSA999:
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2,NODE3
  Any 1 of the nodes: NODE4,NODE5
  Up to any 2 of the nodes: NODE6,NODE7,NODE8

クラスタ内のすべての名前付きポリシーの表示

クラスタに存在する名前付きポリシーとその定義を表示するには,次のコマンドを実行します。

$ SHOW SHADOW/POLICY=HBMM/NAME

名前付きポリシーが,作成された順に表示されます。 このコマンドを実行すると,以下のように表示されます。

$ SHOW SHADOW/POLICY=HBMM/NAME
HBMM Policy DEFAULT
    HBMM Reset Threshold: 50000
    HBMM Master lists:
      Up to any 6 nodes in the cluster

HBMM Policy PEAKS_ISLAND
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2,NODE3
  Any 1 of the nodes: NODE4,NODE5
  Up to any 2 of the nodes: NODE6,NODE7,NODE8

HBMM Policy POLICY_1
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: NODE1,NODE2,NODE3
  Any 1 of the nodes: NODE4,NODE5

HBMM Policy ICE_HOTELS
 HBMM Reset Threshold: 50000
 HBMM Master lists:
  Up to any 2 of the nodes: QUEBEC,ICELND,SWEDEN
  Any 1 of the nodes: ALASKA,GRNLND

1.9.11 シャドウ・セットのマージ状態の表示方法

SHOW SHADOW/MERGE DSAn コマンドを実行することで,各シャドウ・セット・メンバのマージ状態を確認することができます。 /MERGE 修飾子は,以下のメッセージのいずれかを返します。

  • Merge is not reguired (マージは不要)

  • Merge is pending (マージは保留中)

  • Merge is in progress on node file-name (ノード file-name でマージを実行中)

SHOW SHADOW/MERGE DSAn コマンドにより生成される表示の例を以下に示します。

$ SHOW SHADOW/MERGE
  Device      Volume Name   Status
  _DSA1010      FOOBAR        Merging (10%)

現在コピー操作 (マージ操作ではなく) が実行中の場合は,完了したマージの割合 (%) と,完了したコピーの割合 (%) が,以下のように “Copy Active,” とともに表示されます。

$ SHOW SHADOW/MERGE
  Device      Volume Name   Status
  _DSA1010    FOOBAR        Merging (23%), Copy Active  (77%) on CSGF1

1.9.12 複数サイト OpenVMS Cluster システムでの留意事項

あるシャドウ・セットの HBMM マスタ・ビットマップを持つシステムだけが,そのシャドウ・セットに対して HBMM 回復を行うことができます。 シャドウ・セットでマージ回復が必要で,クラスタ内のどのシステムもそのシャドウ・セットに対する HBMM マスタ・ビットマップを持っていない場合は,フル・マージが実行されます。

したがって,複数サイト OpenVMS Cluster システムでフル・マージが必要になる可能性を最小限にするためには,各サイトに HBMM マスタ・ビットマップを 1 つ以上持つようなポリシーを使用することをお勧めします。 HBMM ポリシーで複数のマスタ・リストを指定する機能は,特にこの目的で設計されたものです。 各サイトでは別々の MASTER_LIST を指定する必要があります。

たとえば,12 台のクラスタ・メンバからなる,3 サイトの OpenVMS Cluster システムを考えます。

  • サイト 1: メンバ・システム NYN1,NYN2,NYN3,および NYN4

  • サイト 2: メンバ・システム CTN1,CTN2,CTN3,および CTN4

  • サイト 3: メンバ・システム NJN1,NJN2,NJN3,および NJN4

以下の DEFAULT ポリシーの定義では,各サイトで最大 2 つの HBMM マスタ・ビットマップを持つことができます。

$ SET SHADOW/NAME=DEFAULT/POLICY=HBMM=( -
_$ (MASTER_LIST=(NYN1,NYN2,NYN3,NYN4), COUNT=2), -
_$ (MASTER_LIST=(CTN1,CTN2,CTN3,CTN4), COUNT=2), -
_$ (MASTER_LIST=(NJN1,NJN2,NJN3,NJN4), COUNT=2))

特にこのポリシーでは,最初のマスタ・リストのうちの 2 台のシステム,2 番目のマスタ・リストのうちの 2 台のシステム,3 番目のマスタ・リストのうちの 2 台のシステムがマスタ・ビットマップを持つように指示されています。

この種の分散は,1 つの MASTER_LIST の中でシステムを特定の順序で並べただけでは実現できない点に注意してください。 これは,マスタ・リスト中でシステムを指定する順序は,HBMM マスタ・ビットマップを作成する際にその対象となるシステムの順序には影響しないためです。 HBMM マスタ・ビットマップが作成されるような事象が起きると,シャドウ・セットがマウントされているシステムにより,ランダムな順序でビットマップが作成されます。 以下の例では,システム NYN1 がマスタ・ビットマップを取得する可能性は,POLICY_A と POLICY_B のどちらでも同じです。

$ SET SHADOW/NAME=POLICY_A/POLICY=HBMM=( -
_$ (MASTER_LIST=(NYN1,CTN1,NJN1,NYN2,CTN2,NJN2),COUNT=3))

$ SET SHADOW/NAME=POLICY_B/POLICY=HBMM=( -
_$ (MASTER_LIST=(NJN2,CTN2,NYN2,NJN1,CTN1,NYN1),COUNT=3))

1.10 HBMM に影響を与える新しいシステム・パラメータ

本バージョンで,2 つの新しいシステム・パラメータ SHADOW_REC_DLY と SHADOW_HBMM_RTC が追加されました。

1.10.1 SHADOW_REC_DLY パラメータ

SHADOW_REC_DLY は,システム障害の後やシャドウ・セットが強制終了された後のシステムの動作を左右します。 SHADOW_REC_DLY パラメータの値は RECNXINTERVAL パラメータの値に加えられ,システムがマウントしていたシャドウ・セット上でマージ操作またはコピー操作を始めるまでに,システムがどれだけ待つかを決定します。

SHADOW_REC_DLY は,OpenVMS Cluster のどのシステムが回復操作を行うかを,より正確に予測するために使用することができます。 そのためには,回復操作を行わせたいシステムでは SHADOW_REC_DLY に小さい値を設定し,残りのシステムでは SHADOW_REC_DLY に大きい値を設定します。

SHADOW_REC_DLY は動的パラメータであり,その範囲は 0 ~ 65535 秒です。 デフォルト値は 20 秒です。

マージ操作やコピー操作を行うシステムを制御する方法についての詳細は,1.12.5 項 「どのシステムがマージ操作やコピー操作を行うかを制御する」を参照してください。

1.10.2 SHADOW_HBMM_RTC パラメータ

SHADOW_HBMM_RTC は,HBMM ビットマップの変更ブロック数を,どの程度の頻度でリセットしきい値と比較するかを,秒単位で指定するために使用します。 変更ブロック数がリセットしきい値を超えると,ビットマップはゼロ・クリアされます。

リセットしきい値は,SET SHADOW コマンドの /POLICY 修飾子のキーワード RESET_THRESHOLD で指定します。 この比較は,HBMM ビットマップを持つシステムにマウントされているすべてのシャドウ・セットに対して行われます。

比較を行う際,変更ブロック数がリセットしきい値を少しだけ超えていることもあれば,大幅に超えている場合もあります。 この違いは,ボリュームに対する書き込み動作と SHADOW_HBMM_RTC の設定値によって左右されます。

SHADOW_HBMM_RTC は動的パラメータであり,その範囲は 60 ~ 65535 秒です。 デフォルト値は 150 秒です。

リセットしきい値の設定内容と,最後にリセットされてからの変更ブロック数を,SHOW SHADOW の表示で確認することができます。 リセットしきい値の設定ガイドラインと,サンプルの SHOW SHADOW の表示については,1.8.2 項 「ビットマップの RESET_THRESHOLD 値の設定」を参照してください。 リセットしきい値より大きな変更ブロック数を含んだ SHOW SHADOW の表示については,『DCL ディクショナリ』の SHOW SHADOW の例 9 を参照してください。

1.11 HBMM が有効な場合の /DEMAND_MERGE の使用

シャドウ・セットの HBMM が有効になっており,積極的に HBMM を使用している場合,SET SHADOW/DEMAND_MERGE DSAn: コマンドを実行するとミニマージ操作が開始されます。 ミニマージ操作の代わりにフル・マージを強制的に実行するには,SET SHADOW/DEMAND_MERGE DSAn: コマンドを実行する前に,そのシャドウ・セットで HBMM を無効にする必要があります。 HBMM を無効にする方法については,1.9.4 項 「シャドウ・セットで HBMM を無効にする方法」 を参照してください。

SET SHADOW コマンドの /DEMAND_MERGE 修飾子は,主に INITIALIZE/SHADOW コマンドで /ERASE 修飾子を指定せずに作成したシャドウ・セット上で,強制的にマージ操作を実行するために使用します。 /DEMAND_MERGE 修飾子を指定すると,シャドウ・セットのすべてのブロックが同じであることが保証されます (現在ファイルに割り当てられていないブロックも含む)。 システム管理者は,システム環境がピークでない都合のよい時に,このコマンドを使用することができます。

INITIALIZE/SHADOW コマンドでシャドウ・セットを作成する際に /ERASE 修飾子を指定せず,SET SHADOW/DEMAND_MERGE DSAn: コマンドを実行していない場合,このシャドウ・セットでのフル・マージ操作のオーバヘッドは,システム障害時に通常発生するオーバヘッドよりも大きくなります。

システム管理者は,以下の理由で SET SHADOW/DEMAND_MERGE DSAn: コマンドを使用することもできます。

  • ANALYZE/DISK/SHADOW コマンドで,シャドウ・セットのメンバ間に違いが見つかった場合。 詳細は,TBS の ANALYZE/DISK/SHADOW コマンドの説明を参照してください。

  • ミニマージやフル・マージが入出力のスループットに与える影響を測定したい場合。

1.12 マージ操作とコピー操作の優先順位付け

システム管理者はマージ操作とコピー操作を細かく制御できます。 詳細な制御は,SET SHADOW コマンドに対する新しい 2 つの修飾子 /PRIORITY=n および /EVALUATE=RESOURCES と,新しいシステム・パラメータ SHADOW_REC_DLY で可能となります。 これらのパラメータを使用して,システム管理者は以下のことができます。

  • シャドウ・セットのマージ操作とコピー操作に対して,システムごとに優先順位を付ける。

  • どのシステムが特定のシャドウ・セットのマージ操作やコピー操作を行うかを制御する。

  • システム・パラメータ SHADOW_MAX_COPY を変更する (すぐに有効になります)。

1.12.1 マージ操作とコピー操作のデフォルトの管理

システムで障害が発生したり,マウント・チェックなどによりシステムがシャドウ・セットを強制終了させた場合,このような動作は重大イベントと呼ばれます。 重大イベントのいずれかが発生すると,クラスタ内のすべてのシステムに自動的に通知されます。 この通知により,すべてのシャドウ・サーバ・プロセスはフル・マージやフル・コピー操作を停止し,これらの操作で使用していたすべてのリソースを解放します。 その後,各システムは新しいより高い優先順位の作業を行うためにリソースを再割り当てします。

あらかじめ決められた遅延の後,SHADOW_MAX_COPY にゼロ以外の値が設定されているシステムは,一時状態にあるシャドウ・セットを,その優先順位に基づいて処理し始めます。 あらかじめ決められた遅延は,新しいシステム・パラメータ SHADOW_REC_DLY によって決まります(SHADOW_REC_DLY の詳細は,1.12.5 項 「どのシステムがマージ操作やコピー操作を行うかを制御する」を参照してください)。 各システムは,シャドウ・セットの優先順位に基づいて,利用可能な SHADOW_MAX_COPY リソースを割り当てます。

シャドウ・セットは,以下の操作のいずれも保留しておらず実行中でもないときに,安定状態と呼ばれます。

  • ミニマージ

  • ミニコピー

  • フル・コピー

  • フル・マージ

シャドウ・セットでこれらの操作が 1 つ以上保留されていたり,いずれかの操作が実行中の場合は,一時状態にあると呼ばれます。 これら一時状態の組み合わせは有効ですが,同時には 1 つの操作しか実行できません。

たとえば,HBMM が有効でないとします。 デバイスがシャドウ・セットに追加されると,フル・コピー一時状態としてマークされます。 このシャドウ・セットがマウントされているシステムで障害が発生すると,シャドウ・セットはさらにフル・マージ状態としてマークされます。 この例では,フル・マージが開始される前にフル・コピー操作が実行されます。

注意:

シャドウ・セットに割り当てられた優先順位は,一時状態の操作の階層には影響を与えません。

1.12.2 一時状態の操作の階層

特定のシャドウ・セットに対する操作は,以下の順序で実行されます。

  1. ミニマージ

  2. コピー (ミニコピーまたはフル・コピー)

  3. フル・マージ

1.12.3 優先順位の割り当て

シャドウ・セットが最初にシステムにマウントされるときに,各シャドウ・セットには優先順位としてデフォルトの 5000 が割り当てられます。 SET SHADOW/PRIORITY=n DSAn コマンドを使用して,マウントされた各シャドウ・セットに対し,システムごとに固有の優先順位を割り当てることができます。 各シャドウ・セットにシステムごとに異なる優先順位を割り当てることも,各シャドウ・セットに同じ優先順位を割り当てることもできます。 同じ優先順位のシャドウ・セットは,リリースによらず一貫した方法で管理されます。 ただし,優先順位が同じシャドウ・セットを管理する順序は,アルゴリズムの変更により,リリースごと異なる可能性があります。 したがって,順序が重要な場合には,異なる優先順位を割り当ててください。

優先順位の値の正しい範囲は,0 ~ 10,000 です。 割り当てられた値が大きいほど優先順位は高くなります。 優先順位の高いボリュームが,あまり重要でないボリュームよりも先にマージ (またはコピー) されるように,このコマンドを使用してシステムでデフォルトで割り当てられる優先順位から変更します。

優先順位レベル 0 には特別な意味があります。 優先順位が 0 の場合,そのシャドウ・セットは,このシステム上でのマージ操作やコピー操作の対象になりません。

注意:

重大イベントが通知されシステムのリソースが割り当てられた後は,シャドウ・セットに異なる優先順位レベルを割り当てても,システム上での現在のマージ操作やコピー操作に直接影響を与えることはできません。 シャドウ・セットの優先順位を設定し直す必要がある場合は,1.12.8 項 「実行中の一時状態の管理」 で説明する別の手法を使用しなければなりません。

1.12.4 優先順位値の表示

次のコマンドを実行することで,個々のシステムのシャドウ・セットの優先順位を表示することができます。

$ SHOW SHADOW/BY_PRIORITY DSAn:   

このコマンドは,現在の優先順位と,指定されたシャドウ・セットの状態を表示します。 コピー操作やマージ操作が実行中の場合は,その操作を実行しているノードと進行状況が表示されます。 以下に例を示します。

$ SHOW SHADOW DSA1104/BY_PRIORITY 
Device    Mbr                                                        Active
 Name     Cnt  Priority     Virtual Unit State                      on Node
_DSA1104:  2     5000       Merge Active (29%)                         MAX 

下記のコマンドを使用して,システムに存在するすべてのシャドウ・セットの優先順位レベルと状態を表示することができます。 状態は,シャドウ・セットで現在コピー操作やマージ操作が実行されているかどうか,またはどちらかの操作が必要かどうかを示します。 どちらかまたは両方の操作が実行中の場合は,以下の例に示すように操作を行っているシステムが表示されます。

$ SHOW SHADOW/BY_PRIORITY 
Device    Mbr                                                        Active
 Name     Cnt  Priority     Virtual Unit State                      on Node
_DSA106:   2    10000       Steady State
_DSA108:   3     8000       Steady State
_DSA110:   3     8000       Steady State
_DSA112:   3     8000       Steady State
_DSA114:   1     7000       Steady State
_DSA116:   1     7000       Steady State
_DSA150:   2     7000       Steady State
_DSA152:         7000       Not Mounted on this node
_DSA154:   3     6000       Steady State
_DSA156:   1     6000       Steady State
_DSA159:   2     5000       Steady State
_DSA74:    3     5000       Merge Active (47%)                       CASSID 
_DSA304:  2+1    5000       Merge Active (30%), Copy Active (3%)     MAX 
_DSA1104:  2     5000       Merge Active (29%)                       MAX 
_DSA300:  2+1    5000       Merge Active (59%), Copy Active (0%)     MAX 
_DSA0:    1+2    5000       Copy Active (83%)                        CASSID 
_DSA3:     2     3000       Steady State
_DSA100:   2     3000       Steady State
_DSA102:   1     3000       Steady State
_DSA104:   3     3000       Steady State
Total of 19 Operational shadow sets; 0 in Mount Verification; 1 not mounted
$

この例では,このシステムに存在する 20 個のシャドウ・セットが優先順位の高い順に表示されています。 クラスタ内のほかのシステムのうち,これらのシャドウ・セットをマウントしているシステムで障害が発生すると,シャドウ・セットはこのシステム上でこの順序でマージされます。

Mbr Cnt フィールドは,各シャドウ・セットにいくつのソース・メンバがあるかを示します。 メンバがコピー操作により追加中の場合,+1 または +2 と表示されます。 したがって,2+1 は,2 つのソース・メンバがあり,1 つのメンバが追加中であることを示します。 1+2 という表記は,ソース・メンバが 1 つしかなく,2 つのメンバがシャドウ・セットにコピー中であることを示します。

要約の行は,さまざまな状態で見つかったシャドウ・セットの合計数を示します。 “Operational shadow sets” は,1 つ以上のメンバを持つマウント済みのシャドウ・セットです。 コピー操作やマージ操作は実行中の場合と実行中でない場合があります。 このシャドウ・セットは,アプリケーションが読み書きで利用できます。 “Mount Verification” は,何らかのマウント・チェック状態にあるシャドウ・セットの数を示します。 マウント・チェック・タイムアウト時間を過ぎたシャドウ・セットも,この合計に含まれます。

その他の例については,『DCL ディクショナリ』を参照してください。

1.12.5 どのシステムがマージ操作やコピー操作を行うかを制御する

システムで障害が発生したり,シャドウ・セットを強制終了させると,この重大イベントにより,そのシャドウ・セットをマウントしているほかのすべてのシステムで,すべてのシャドウ・セットが再評価されます。 この時点で,すべての実行中のミニマージ操作,フル・マージ操作,コピー操作が中止され,リソースがシステムに戻されます。(ただし,システムがミニコピー操作を行っている場合,この操作は完了するまで続行されます。)

各システムは,一時状態にあるシャドウ・セットの管理を開始する前に,あらかじめ決められた時間 (秒単位) 待ちます。 この休止は,重大イベント回復遅延と呼ばれます。 これは,2 つのシステムパラメータ SHADOW_REC_DLY および RECNXINTERVAL に指定した値の合計です(それぞれのデフォルト値は 20 秒です)。

重大イベント回復遅延の値がすべてのシステムで同じ場合は,どのシステムがどのシャドウ・セットを管理するかを予測することはできません。 しかし,重大イベント回復遅延の値をシステムごとに変えることで,あるシステムがいつ一時状態の操作を管理し始めるかを予測することができます。

1.12.6 マージ操作の管理

マージ一時状態は,予測できないイベントです。 複数のシャドウ・セットに対する特定のシステム上でのマージ動作の管理は,各シャドウ・セットに対する優先順位レベルの設定値が異っていれば予測することができます。

以下の例では,4 つのシャドウ・セットがあり,このシステムでの SHADOW_MAX_COPY パラメータは 1 です。 値 1 は,同時に 1 つのマージ操作またはコピー操作しか行うことができないことを意味します。 この例では,マージ操作だけが関係する場合に,優先順位レベルを使用してシャドウ・セットを選択する方法を示します。

2 つのシャドウ・セットに優先順位レベルが割り当てられており,2 つのシャドウ・セットにはデフォルトの優先順位レベル 5000 が割り当てられています。

4 つのシャドウ・セット DSA1,DSA20,DSA22,および DSA42 が 2 台のシステムにマウントされています。 DSA20 および DSA42 では,ミニマージが有効になっています。

$ SET SHADOW/PRIORITY=7000 DSA1:
$ SET SHADOW/PRIORITY=3000 DSA42:
! DSA20: and DSA22: are at the default priority level of 5000

この例では,いずれかのシステムで障害が発生すると,すべてのシャドウ・セットがマージ要状態になります。 重大イベント回復遅延時間が経過した後,このシステムはシャドウ・セットを評価し,以下の順序で操作が実行されます。

  1. まず DSA20 のミニマージ操作が開始されます。 DSA20 の優先順位 5000 は DSA1 の優先順位 7000 よりも低いですが,ミニマージ操作はほかの操作よりも常に優先されます。 DSA20 と DSA42 はどちらもミニマージが有効になっていますが,DSA20 のほうが優先順位が高いため,DSA20 のミニマージ操作が最初に開始されます。

  2. DSA42 上でミニマージ操作が開始されます。 優先順位 3000 はすべてのシャドウ・セットの中で最低ですが,ミニマージ操作はほかの操作よりも優先されます。

  3. ミニマージ機能を持ったユニットはほかにないため,優先順位レベル 7000 の DSA1 が選択されてマージ動作が開始され,終了するまで実行されます。

  4. 残っているシャドウ・セット DSA22 (優先順位はデフォルトの 5000) 上でマージ操作が開始され,終了するまで実行されます。

1.12.7 コピー操作の管理

コピー一時状態は,ユーザが行った操作の結果であるため,予期することができます。 したがって,デバイスをシャドウ・セットに追加したことで起こるフル・コピー操作は,クラスタでの重大イベントとはみなされません。 コピー操作は,利用可能なリソースを持つ最初のシステムにより管理されます。

以下の例では,4 つのシャドウ・セットがあり,このシステムの SHADOW_MAX COPY パラメータは 1 であると仮定します。 優先順位レベルを割り当てていないシャドウ・セットには,デフォルトの優先順位レベルが割り当てられることを思い出してください。

以下の例では,次のことを仮定しています。

  • DSA1,DSA20,DSA22,および DSA42 は,複数のシステムにマウントされている。

  • DSA42 でのみミニマージが有効になっている。

  • DSA22 はすでにフル・コピー状態にあり,このシステムで管理されている。

  • DSA1 の優先順位レベルは 7000。

  • DSA42 の優先順位レベルは 3000。

  • DSA20 の優先順位レベルは 3000。

  • DSA22 の優先順位レベルはデフォルトの 5000。

ユーザが DSA1 にデバイスを追加します。 これは重大イベントではないため,DSA1 のフル・コピー操作の実行を優先させて DSA22 のフル・コピー操作を中断するといったことはしません。

この例を発展させるため,コピー操作が完了する前にシステムで障害 (重大イベント) が発生したとします。 すべてのシャドウ・セットはマージ要状態になります。 特に,DSA1,DSA20,および DSA22 はフル・マージ状態になり,DSA42 はミニマージ状態になります。

重大イベント回復遅延が経過すると,システムは一時状態にあるすべてのシャドウ・セットの評価を始めます。 以下の順序で操作が実行されます。

  1. DSA42 上でミニマージ操作が開始され,終了するまで継続されます。 この操作は,優先順位レベルに関係なく,ほかの操作より優先されます。

  2. DSA1上でコピー操作が開始されます。 コピー操作はフル・マージ操作より優先されるため,フル・マージ操作は開始されません。

  3. DSA1 でマージ操作が開始され,完了します。

  4. DSA22 でコピー操作が開始され,完了します。

  5. DSA22 でマージ操作が開始され,完了します。

  6. DSA20 でマージ操作が開始され,完了します。

このように,この例では優先順位レベルを使用して,システム上でのマージ操作とコピー操作の優先順位を指定しています。

1.12.8 実行中の一時状態の管理

SHADOW_MAX_COPY は,シャドウイングによるシステム・リソースの利用を左右する,動的システム・パラメータです。 次の DCL コマンドを使用すると,このパラメータの設定変更にすぐに反応するように,シャドウイングに指示することができます。

$ SET SHADOW/EVALUATE=RESOURCES 

このコマンドは,コマンドを実行したシステムで現在実行されているすべてのマージ操作とコピー操作を中断します。 次に,SHADOW_MAX_COPY の新しい値を使用して作業を再開します。

このコマンドは,これ以外の状況でも便利です。 たとえば,シャドウ・セットの優先順位レベルに 0 またはほかの低い値が設定されている場合,SET SHADOW /PRIORITY=n コマンドを使用して値を大きくすることができます。 その後,/EVALUATE=RESOURCES 修飾子を使用することで,一時状態のシャドウ・セットの優先順位が再評価されます。

コマンド修飾子の /PRIORITY と /EVALUATE=RESOURCES は,同じコマンド行で使用できます。

重大イベントが起きると,SHADOW_MAX_COPY リソースのすべてが適用されます。 SYSGEN SET コマンドと WRITE ACTIVE コマンドを使用して SHADOW_MAX_COPY の値を変更し,その後 SET SHADOW /EVALUATE=RESOURCES を実行することで,SHADOW_MAX_COPY の新しい値を直接すぐに有効にすることができます。

どのシステムが一時操作を制御しているかを確認するには,次のコマンドを入力します。

$ SHOW SHADOW/ACTIVE DSAn:

各シャドウ・セットに割り当てられている優先順位の値を確認するには,次のコマンドを入力します。

$ SHOW SHADOW/BY_PRIORITY DSAn:

1.13 一時状態イベントの目に見える影響

表 1-1 「一時状態イベントの目に見える影響」 は,一時状態イベントのユーザに見える影響を,OpenVMS Cluster システム内の 1 台のシステム上の 1 つのシャドウ・セットの観点からまとめたものです。 一時状態イベントの種類ごとに,マージ (フル・マージ,HBMM,コントローラ・ミニマージ) 操作やコピー (フル・コピーまたはミニコピー) 操作がすでに実行中の場合の,シャドウ・セットに対する影響を挙げてあります。 この表でキーとなっている用語,キャンセル (Canceled),再開 (Restarted),続行 (Continued),中断 (Suspended) は,Volume Shadowing for OpenVMS のメッセージと同じ意味です。

マージ操作とコピー操作の以下の特性に注意してください。

  • 同じシャドウ・セットでマージとコピーの両方が保留中の場合は,マージがミニマージの場合に限り,コピーよりマージが先に行われます。 これは,コントローラ・ベース・ミニマージ,ホスト・ベース・ミニマージ,フル・コピー,ミニコピーのいずれにも言えます。

  • 以前に発生したイベントの遅延時間の間に,遅延を伴うイベントが発生したときには,追加の遅延は起こりません。 以前の遅延時間が経過したときに,現在のイベントで必要なマージまたはコピーが処理候補として扱われます。

  • 以前のイベントの遅延時間の間に,遅延なしのイベントが発生しても,以前の遅延時間が経過するまでは,「遅延なし」イベントで必要なマージやコピーは処理候補として扱われません。

表 1-1 一時状態イベントの目に見える影響

イベント[1]

対象シャドウ・セット (SS)

新たに必要な作業

SS 上の以前のマージ/コピーの扱い

遅延[2]

以前のフル・マージまたは HBMM

以前のコントローラ・ミニマージ

以前のフル・コピー

以前のミニコピー

このシステムと共用の SS を 1 つ以上マウントしていたほかのシステムの障害。

障害が発生したシステムにマウントされていたすべての SS。

マージ要。

キャンセルし再開。

障害が発生したシステムでは再開。 それ以外では,追加作業を伴ってミニマージを続行。

キャンセルだが最終的には続行。

キャンセルだが最終的には続行。 障害が発生したシステム上にミニコピーのマスタ・ビットマップがあった場合は,フル・コピーとして続行。

あり

 

以前マージ状態またはコピー状態だったほかのすべての SS。

新たな作業なし。

キャンセルだが続行。

変更なし。

キャンセルだが続行。

キャンセルだが続行。

あり

        

このシステムと共用の SS をマウントしていなかったほかのシステムの障害。

以前マージ状態またはコピー状態だったほかのすべての SS。

新たな作業なし。

変更なし。

変更なし。

変更なし。

変更なし。

あり

        

ほかのシステムで SS が強制終了。 強制終了のシステムでは再開キューに書き込みあり。 SS はこのシステムにもマウントされている。

強制終了された SS。

マージ要。

キャンセルし再開。

障害が発生したシステムでは再開。 それ以外では,追加作業を伴ってミニマージを続行。

キャンセルだが続行。

キャンセルだが続行。

あり

 

以前マージ状態またはコピー状態だったほかのすべての SS。

新たな作業なし。

キャンセルだが続行。

変更なし。

キャンセルだが続行。

キャンセルだが続行。

あり

        

ほかのシステムが,そのシステムでマージまたはコピー操作が実行中の SS をディスマウントした。 SS はこのシステムでもマウントしている。

ほかのシステムでディスマウントされた SS。

新たな作業なし。

続行。

再開。

続行。

続行。

なし

 

以前マージ状態またはコピー状態だったほかのすべての SS。

変更なし。

変更なし。

変更なし。

変更なし。

変更なし。

なし

        

このシステムにマウントされている SS にメンバが追加された。

指定された SS。

コピー要。

キャンセルだが続行。

変更なし。

変更なし。

変更なし。

なし

 

以前マージ状態またはコピー状態だったほかのすべての SS。

新たな作業なし。

変更なし。

変更なし。

変更なし。

変更なし。

なし

        

マージまたはコピーが必要な SS のマウント。 SS はほかのシステムにはマウントされていない。

指定された SS。

コピー/マージ要。

フル・マージとして再開。

フル・マージとして再開。

再開。

フル・コピーとして再開。

なし

        

このシステムにマウントされている SS に対し,任意のシステムで SET SHADOW /DEMAND_MERGE コマンドを実行。

指定された SS がコントローラ・ミニマージを使用していない。

マージ要。

再開。

該当なし。

キャンセルだが続行。

キャンセルだが続行。

なし

 

指定された SS がコントローラ・ミニマージを使用している。

フル・マージ要。

再開。

中断しフル・マージとして再開。

キャンセルだが続行。

キャンセルだが続行。

なし

 

以前のマージ状態またはコピー状態だったほかのすべての SS。

変更なし。

変更なし。

変更なし。

変更なし。

変更なし。

なし

        

このシステムで SET SHADOW /EVAL=RESOURCES コマンドを実行。

以前マージ状態またはコピー状態で,このシステムにマウントされているすべての SS。

変更なし。

キャンセルだが続行。

変更なし。

キャンセルだが続行。

キャンセルだが続行。

あり

[1] 各イベントは,クラスタ内の 1 台のシステムの観点で記述されています。

[2] 遅延とは,操作を開始するまでに待つ,あらかじめ決められた時間の長さです。 これは,システム・パラメータ SHADOW_REC_DLY および RECNXINTERVAL で指定された値の合計です。

マージ操作またはコピー操作の動作に関するキー (定義はシャドウイングのメッセージのものと同じ)

  • キャンセル (Canceled) -- 資格を持ったシステム上で再開または続行できるように,操作は停止される。

  • 再開 (Restarted) -- 操作を再開する際には,同じシステム上で LBN 0 から再開する必要がある。

  • 続行 (Continued) -- 操作は,キャンセルまたは中断されたときに終了した位置から続行される。

  • 中断 (Suspended) -- 操作は,中断された操作が実行されていたシステム上でのみその SS に対する操作を開始,再開,続行できるような状態で停止される。

 

印刷用画面へ
プライバシー 本サイト利用時の合意事項
© 2005 Hewlett-Packard Development Company, L.P.