 |
≫ |
|
|
|
この章では，ミニマージ操作，この操作が発生する状況，ミニマージとフルマージの違いについて説明します。
また，関連するさまざまなポリシーと修飾子，HBMM の使用に関するガイドラインについても説明します。
ここでは，以下の内容について説明します。
-
-
-
-
-
-
-
HBMM が有効な場合の /DEMAND_MERGE の使用
-
HBMM 機能に加え，マージ操作とコピー操作に優先順位を付ける新しい機能を，4.9 項 「マージ操作とコピー操作の優先順位付け」で説明します。
フルマージやミニマージの回復操作の目的は，シャドウセット・メンバのデータを比較して，すべてのメンバの全論理ブロックのデータを一致させることです。
各ブロックは，論理ブロック番号 (LBN) で識別されます。
回復操作の際，アプリケーションの入出力は継続されますが，速度は遅くなります。
フルマージ操作やミニマージ操作は，シャドウセットがマウントされている OpenVMS システムのいずれかで管理されます。
本書では，ミニマージ操作とマージ操作は，それぞれミニマージ回復操作とマージ回復操作を指します。
フルマージ操作やミニマージ操作は，以下の場合に開始されます。
-
システムで障害が発生したため，アプリケーションの書き込みが不完全になった可能性がある場合。
-
シャドウセットでマウント・チェックが開始され，特定の条件下でマウント・チェックがタイムアウトになるか異常終了した場合 (8.1.2 項 「マウント・チェックのタイムアウトによるマージ」を参照)。
-
システム管理者が SET SHADOW/DEMAND_MERGE コマンドを実行した場合。
8.1.1 システム障害によるマージ | |
シャドウセットをマウントしているシステムで障害が発生した際に，シャドウセットに対して書き込み要求を出し，完了状態がアプリケーションに返される前にシステムが障害となったとすると，シャドウセットのメンバ間でデータの不整合が起こる可能性があります。
-
-
-
いくつかのメンバは新しいデータを持っており，残りのメンバは古い データを持っている。
どの状態になるかは，オリジナルの書き込み要求の処理中に障害が発生したタイミングによって決まります。
システムの回復動作の際に，Volume Shadowing for OpenVMS は，各シャドウセット・メンバ上の対応する LBN に同じデータ (古いデータまたは新しいデータ) が格納された状態にします。
8.1.2 マウント・チェックのタイムアウトによるマージ | |
マウント・チェックが開始され，マウント・チェックがタイムアウトになるか異常終了した場合は，以下の条件が真であればマージ状態になります。
-
タイムアウトになったシステムのシャドウ・ドライバの内部キューに，未完了の書き込み入出力要求がある場合。
-
そのシャドウセットがクラスタ内のほかのシステムにマウントされている場合。
マウント・チェックがタイムアウトになった (またはマウント・チェックが異常終了した) システムは，そのシャドウセットをマウントしているほかのシステムにマージ操作が必要であることを通知し，シャドウセットをディスマウントします。
たとえば，シャドウセットが 8 台のシステムにマウントされていて，そのうち 2 台のシステムでマウント・チェックのタイムアウトが発生した場合，これら 2 台のシステムは，内部キューに書き込み入出力がないか確認します。
書き込み入出力が見つかると，そのシャドウセットはマージが必要となります。
8.1.3 SET SHADOW/DEMAND_MERGE によるマージ | |
SET SHADOW/DEMAND_MERGE コマンドは，指定されたシャドウセットまたは全シャドウセットのマージを開始します。
この修飾子は，INITIALIZE/SHADOW コマンドで /ERASE 修飾子を指定せずにシャドウセットを作成した場合に便利です。
SET SHADOW/DEMAND_MERGE の使用方法の詳細は，
『DCL ディクショナリ』および『Volume Shadowing for OpenVMS 説明書』
を参照してください。
8.1.4 マージ操作とミニマージ操作の比較 | |
フルマージ操作では，シャドウセットのメンバが互いに比較され，同じデータが格納されていることが保証されます。
これは，ボリューム全体にわたってブロックごとの比較を行うことで実現されます。
しかし，この操作は長時間を要する可能性があります。
これに対し，ミニマージ操作は非常に高速です。
揮発性のコントローラ・ストレージまたは OpenVMS システム上の書き込みビットマップに記録されている書き込み操作の情報を使用して，ボリューム・シャドウイングでは，書き込み操作が行われたと分かっているシャドウセットの領域だけをマージします。
これにより，フルマージ操作で必要となるボリューム全体の走査が不要となり，システム I/O リソースの消費を減らすことができます。
HBMM が導入される前はミニマージはコントローラ・ベースで実行されたため，HSJ，HSC，および HSD コントローラでしか利用できませんでした。
8.1.5 高速なミニマージおよびミニコピー操作 | |
Volume Shadowing for OpenVMS Version 8.4 では，書き込みビットマップに設定された
次のビットの先読み機能により，ミニコピーおよびミニマージの性能が向上しています。
SHADOW_SERVER と SYS$SHDRIVER 間の実際の QIO 数は，
ミニマージおよびミニコピーをより速く完了させることができるこの手法により減少します。
HBMM は，ミニマージ操作に必要な情報を提供してくれるビットマップとポリシーに依存します。
ユーザのシステム環境によっては，HBMM の DEFAULT ポリシーを 1 つ指定するだけで十分な場合もあります。
HBMM を使用してシャドウセットを回復させるためには，以下の条件を満たしている必要があります。
-
-
HBMM ポリシーがシャドウセットに関連付けられていること。
-
HBMM ポリシーで指定された 1 台以上のシステムにシャドウセットがマウントされていること。
シャドウセットにポリシーが関連付けられ，シャドウセットが複数のシステムにマウントされていれば，そのシャドウセット専用のビットマップが作成されます。
HBMM ポリシー定義で指定されたマスタ・リストから選ばれたシステムは，マスタ・ビットマップを保有しているため，ミニマージ操作を実行することができます。
シャドウセットがマウントされているその他のシステムは，各マスタ・ビットマップに対するローカル・ビットマップを保有しています。
8.2.1 マスタ・ビットマップとローカル・ビットマップ | |
各ビットマップにつき，マスタ・バージョンがクラスタ内のいずれかのシステムに 1 つだけ存在し，関連付けられたシャドウセットをマウントしているほかのシステムは，すべてローカル・バージョンを持ちます。
ミニマージ操作は，マスタ・ビットマップを持っているシステムだけが実行できます。
OpenVMS Version 8.3 以前のバージョンでは，1 つのシャドウセットは，最大 6 つの HBMM マスタ・ビットマップを持つことができます。
OpenVMS Version 8.4 以降では，最大 12 の 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 のメモリが使用されます。
8.2.2 HBMM ポリシー | |
ポリシーは，1 つ以上のシャドウセットについて以下の属性を指定します。
-
マスタ・ビットマップを保有する権利を持つシステムの名前。
-
マスタ・ビットマップを保有するシステムの数。
OpenVMS Version 8.3 以前のバージョンでこの数を省略すると，指定したシステムから最初の 6 システムが選択されます。
OpenVMS Version 8.4 以降では，シャドウセットに最大 12 のシステムを持つことが可能で，システム数の指定を省略すると利用できる最初の 12 システムが選択されます。
-
ビットマップがリセットされるしきい値(512 バイト・ブロック単位)。
省略すると，デフォルトで 1,000,000 ブロックになります。
ポリシーには名前を付けることができます。
特定の属性を持つ予約名 DEFAULT および NODEFAULT を指定することもできます(8.4 項 「HBMM ポリシーに適用される規則」を参照)。
名前のないポリシーを作成して特定のシャドウセットに割り当てることもできます。
名前付きポリシーの利点は，名前を指定するだけで再利用できることです。
複数のポリシーを作成し，クラスタでのミニマージ操作をカスタマイズすることができます。
ポリシーの定義，割り当て，割り当て解除，削除を行い，シャドウセット上で HBMM を有効にしたり無効にするには，SET SHADOW/POLICY コマンドに HBMM 固有の修飾子を指定して実行します。
SET SHADOW/POLICY は，HBMM ポリシーを指定するための唯一のユーザ・インタフェースです。
MOUNT コマンドを使用してポリシーを定義することはできません。
ポリシーは，シャドウセットをマウントする前に定義することができます。
8.4 項 「HBMM ポリシーに適用される規則」で説明しているように，ほかの方法を使用してポリシーをシャドウセットに関連付けることもできます。
SHADOW_REC_DLY，SHADOW_PSM_DLY，および SHADOW_HBMM_RTC の 3 つのパラメータが HBMM をサポートします。
これらのパラメータの詳細については，
3.3 項 「ボリューム・シャドウイングのパラメータ」
を参照してください。
HBMM ポリシー指定は，HBMM ポリシー・キーワードのリストを括弧で囲んだ形式で指定します。
HBMM ポリシー・キーワードは，MASTER_LIST，COUNT，および RESET_THRESHOLD です。
3 つのキーワードのうち，MASTER_LIST だけが必須です。
COUNT や RESET_THRESHOLD を省略すると，デフォルト値が使用されます。
ポリシー指定の例については，
8.6.1 項 「HBMM ポリシーの定義方法」
および
『OpenVMS DCL ディクショナリ』 を参照してください。
ここでは，これらのキーワードの使用方法と指定する際の規則を説明します。
MASTER_LIST キーワードは，マスタ・ビットマップを保有する候補とするシステム (複数可) を指定するために使用します。system-list の値は，単一のシステム名，コンマで区切ったシステム名のリストを括弧で囲んだもの，またはワイルドカード文字のアスタリスク (*) です。
例:
-
-
MASTER_LIST=(node1,node2,node3)
-
システム・リストが単一のシステムまたはワイルドカード文字である場合は，括弧は省略できます。
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=n
RESET_THRESHOLD キーワードは，ビットマップがクリア対象になる前に設定することができるブロックの数を指定します。
マスタ・ビットマップに設定される各ビットは，マージが必要なブロックに対応しています。
したがって，マージ時間はこの値の影響を受けます。
RESET_THRESHOLD を超えると，ビットマップはクリアされます。
ただし，しきい値を超えてもすぐにリセットされるとは限りません。
この属性の値をいくつに設定すればよいかについては，8.5.2 項 「ビットマップの RESET_THRESHOLD 値の設定の考え方」および3.3 項 「ボリューム・シャドウイングのパラメータ」を参照してください。
HBMM ポリシーに対してはリセットしきい値を 1 つだけ関連付けます。
このため，1 つのポリシーに対して RESET_THRESHOLD キーワードを複数指定することはできません。
RESET_THRESHOLD キーワードの範囲がポリシー全体であるため，ポリシーに複数のマスタ・リストを指定するときに，このキーワードをマスタ・リストに対応付けて指定することはできません。
RESET_THRESHOLD キーワードを省略すると，デフォルト値として 1,000,000 が使用されます。
次のポリシーの例では，明示的にリセットしきい値を指定しています。
(MASTER_LIST=*, COUNT=4, RESET_THRESHOLD=800000)
|
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 ポリシーがあれば，それを適用しようとします。(デバイス固有のポリシーが存在するか確認したり，特定のポリシーを表示する方法については，8.6.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 が有効になります (8.6.2 項 「シャドウセットへの HBMM ポリシーの割り当て方法」を参照)。
-
マスタ・ビットマップを持つシステムでシャドウセットがマウントされていないか，ポリシーが定義されていない場合，SET SHADOW DSAn /ENABLE=HBMM コマンドで HBMM を有効にしようとしても，失敗します。
-
新しいシステムがクラスタに参加したときには，そのクラスタに現在あるポリシーが継承されます。
ポリシーの変更
-
名前付きのポリシーは，自由に作成，変更，削除できます。
名前付きポリシーを変更しても，その名前付きポリシーの以前のバージョンを使用してマウントしたシャドウセットには，その変更は引き継がれません。
-
シャドウセットで HBMM が有効になっている場合は，ポリシーとマウント済みシャドウセットの関係は変更できません。
そのシャドウセットで HBMM を無効にした後でないと，そのシャドウセットに別のポリシーを割り当てることはできません。
-
ポリシーの有効期間
-
どのポリシーも，少なくとも 1 台のシステムが動作中であれば，そのクラスタで有効です。
しかし，すべてのシステムがシャットダウンすると，すべてのポリシー定義と関連付けは消えます。
システムでクラスタを形成する時に，再度ポリシーを定義して割り当てる必要があります。
そのため，システム・スタートアップ・プロシージャの中で，必要な HBMM ポリシーを定義することをお勧めします。
-
ポリシーの割り当ては，HBMM を無効にしたり，シャドウセットをディスマウントしても，クラスタ内で 1 台以上のシステムが動作している限り持続します。
HBMM ポリシーを確立するプロセスは継続的であり，構成が変わり，HBMM の動作とそれがシステムのさまざまな運用に与える影響についての理解が深まるにつれて変化します。
ここで説明するいくつかの留意点は，さまざまな構成でどのようなポリシーが適しているかを判断するのに役立ちます。
設定はハードウェア構成やソフトウェア構成，システムの負荷，運用上の要件によって変わります。
これらのガイドラインは，お使いの構成に対する初期設定を選択するのに役立ちます。
お使いの構成で結果を観察して，システム環境に合わせてさらに調整を加えることができます。
8.5.1 マスタ・ビットマップを保有するシステムの選択 | |
ポリシーで指定するマスタ・ビットマップの数と，マスタ・ビットマップを保有するホストを選ぶ際には，いくつかの検討要素があります。
最初の問題は，構成でマスタ・ビットマップをいくつ使用するかという点です。
OpenVMS Version 8.3 以前のバージョンでは，
シャドウセットごとの HBMM マスタ・ビットマップ数の最大値は 6 です。
OpenVMS Version 8.4 以降では，シャドウセットごとの最大数は 12 です。
マスタ・ビットマップを追加するたびに，書き込み性能に若干の影響があり，各システムでメモリを消費します(8.2.1 項 「マスタ・ビットマップとローカル・ビットマップ」で説明したとおりです)。
マスタ・ビットマップを 1 つしか使用しないと，単一障害点ができることになり，マスタ・ビットマップを保有しているシステムが障害になると，シャドウセットでフルマージが実行されることになります。
したがって，メモリ消費とフルマージの悪影響を比較検討する必要があります。
複数のマスタ・ビットマップを使用すればフルマージが必要になる可能性を最小限にすることができます。
マスタ・ビットマップを保有するシステムを選ぶ際のもう 1 つの問題は，さまざまなシステムの入出力の帯域幅です。
ミニマージは，必ずマスタ・ビットマップを持っているシステムで実行されることを心に留めておいてください。
したがって，サテライト・クラスタ・メンバのように帯域幅が狭いシステムは向いていません。
構成のディザスタ・トレランスも決定する際の重要な要素です。
複数のサイトの複数のシステムでマスタ・ビットマップを保有するように指定すれば，サイト全体の接続が失われた場合でもミニマージが実行されるようになります。
2 サイト構成ではマスタ・ビットマップ・システムの半分を各サイトに置くようにし，3 サイト構成ではマスタ・ビットマップの 1/3 ずつを 3 つのサイトに置くようにします。
8.5.2 ビットマップの RESET_THRESHOLD 値の設定の考え方 | |
しきい値リセット値を選択する際，I/O 性能におけるビットマップ・リセットの効果と
HBMM ミニマージを実行するのに要する時間のバランスを取る必要があります。
リセット値の設定は，アプリケーションの I/O 性能に影響しない範囲でなるべく低くします(これによりマージ時間が短縮されます)。
値を低くし過ぎると I/O 性能が低下します。
値を高くし過ぎるとマージに余計な時間がっかります。
HBMM ビットマップでは，シャドウセットへの書き込みが常時記録されます。
ビットマップ中の設定されているビットの数が増えるほど，ミニマージの際に必要なマージ量も増えます。
HBMM では，ある条件 (3.3 項 「ボリューム・シャドウイングのパラメータ」を参照) が満たされた場合にビットマップをクリアします (各メンバの整合をとるため，処理中の書き込みがすべて完了したことを確認した後)。
クリアされたばかりで設定されたビットが少ないビットマップでは，ミニマージがより速く実行できます。
ただし，ビットマップのリセットは，入出力性能面で負担がかかります。
ビットマップをリセットする前に，シャドウセットに対するすべての書き込み入出力を休止し，実行中の書き込み入出力の完了を待つ必要があります。
その後ビットマップがクリアされます。
この操作は，シャドウセットごとに全システムで実行されます。
そのため，頻繁にリセットが起きるようなしきい値の設定は避けてください。
実行されたリセットの回数は，SHOW SHADOW コマンドを使って確認することができます。
次の例のように，HBMM Reset Count が最後の部分に表示されます。
$ 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: 100000
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 2 Last Reset 29-JAN-2004 10:13:53.90
Modified blocks since last bitmap reset: 11181
.
.
.
$
|
ビットマップにビットを設定する必要があるような書き込みは，すでに書き込み済みとしてマークされている領域への書き込みよりも，若干遅くなります。
このため，あるシャドウセットへの書き込みの多くが「ホットな」ファイルに集中している場合は，リセットしきい値を大きくして，同じビットのセットとクリアが繰り返されないようにすることをお勧めします。
逆に，リセットしきい値が大きすぎると，HBMM の効果が薄れてしまいます。
たとえば，ビットマップの 50 % が設定されていると (つまり，最後にリセットされてから，シャドウセットの 50 % が書き込まれた)，HBMM マージではフルマージの約 50 % の時間がかかることになります。
同じポリシーに異なる RESET_THRESHOLD 値を指定することにより，
ポリシーを有効に保った状態で RESET_THRESHOLD 値を変更することができます。
(RESET_THRESHOLD キーワードを含め，
ポリシーを指定するための構文については，
8.3 項 「HBMM ポリシー指定の構文」
で説明します。)
以下の例では次の方法について説明します。
-
シャドウセット DSA3233 の情報を表示する。 -
名前のないポリシーを作成し DSA3233 に割り当てる。
-
ポリシーが DSA3233 に割り当てられたことを確認する。
-
割り当てたポリシーの RESET_THRESHOLD 値を変更する。
-
RESET_THRESHOLD の変更が反映されていることを確認する。
|
$!
$! To display status information about DSA3233
$!
$ Show Shadow DSA3233
_DSA3233: Volume Label: OSCAR
Virtual Unit State: Steady State
No Enhanced Shadowing Features in use
VU Timeout Value 3600 VU Site Value 0
Copy/Merge Priority 3233 Mini Merge Disabled
Recovery Delay Per Served Member 30
Merge Delay Factor 200 Delay Threshold 200
Device $1$DGA32
Read Cost 2 Site 0
Member Timeout 120
Device $1$DGA33 Master Member
Read Cost 2 Site 0
Member Timeout 120
$!
$! To create a policy and assign it to DSA3233
$!
$ SET SHADOW/POLICY=HBMM=(master_list=(ATHRUZ,ATWOZ,A2ZIPF),count=2,-
reset_threshold=420000) DSA3233:
$!
$! To confirm that the policy was assigned to DSA3233
$!
$ Show Shadow DSA3233
_DSA3233: Volume Label: DSA3233
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 3233 Mini Merge Enabled
Recovery Delay Per Served Member 30
Merge Delay Factor 200 Delay Threshold 200
HBMM Policy
HBMM Reset Threshold: 420000
HBMM Master lists:
Up to any 2 of the nodes: ATHRUZ,ATWOZ,A2ZIPF
HBMM bitmaps are active on ATHRUZ,ATWOZ
Modified blocks since bitmap creation: 0
Device $1$DGA32
Read Cost 2 Site 0
Member Timeout 120
Device $1$DGA33 Master Member
Read Cost 2 Site 0
Member Timeout 120
$!
$! To change the Reset Threshold value
$!
$ SET SHAD/POLICY=HBMM=(master_list=(ATHRUZ,ATWOZ,A2ZIPF),count=2, -
reset_threshold=840000) DSA3233:
$!
$! To confirm the change to the Reset Threshold value
$!
$ Show Shadow DSA3233
_DSA3233: Volume Label: DSA3233
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 3233 Mini Merge Enabled
Recovery Delay Per Served Member 30
Merge Delay Factor 200 Delay Threshold 200
HBMM Policy
HBMM Reset Threshold: 840000
HBMM Master lists:
Up to any 2 of the nodes: ATHRUZ,ATWOZ,A2ZIPF
HBMM bitmaps are active on ATHRUZ,ATWOZ
Modified blocks since bitmap creation: 0
Device $1$DGA32
Read Cost 2 Site 0
Member Timeout 120
Device $1$DGA33 Master Member
Read Cost 2 Site 0
Member Timeout 120 |
|
8.5.3 複数ポリシーの使用 | |
HBMM ポリシーは，マスタ・ビットマップ・システムに関する意思決定を実現するために定義します。
サイトによっては，単一のポリシーでも意思決定を効果的に実現できます。
ほかのサイトでは，より細かな指定が必要となり，複数のポリシーを作成することになります。
クラスタに広帯域なシステムが十分あり，マージの負荷を分散させたい場合，
複数のポリシーが必要になります。
ミニマージは，マスタ・ビットマップを保有しているシステム上でしか実行されないことに注意してください。
そのため，広い帯域幅を持つ 12 台のシステムでミニマージ操作またはマージ操作を行うように設定する場合には (すべてのシステムでシステム・パラメータ SHADOW_MAX_COPY が 1 以上の場合)，マスタ・ビットマップをこれらの広帯域幅システムに分散させるようにしてください。
複数の HBMM ポリシーは，各シャドウセットで異なるビットマップ・リセットしきい値が必要になる場合にも便利です。
マスタ・ビットマップ・システムのリストは，各ポリシーは同じまま，しきい値を異なる値にすることができます。
ここでは，HBMM を設定し管理するための主な作業を説明します。
8.6.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 台に限定し，ビットマップをクリアするしきい値としてより大きな値を指定しています (デフォルトは 1,000,000 ブロック)。
$ SET SHADOW /POLICY=HBMM=( -
_$ (MASTER_LIST=(NODE1,NODE2,NODE3), COUNT=2), -
_$ RESET_THRESHOLD=1250000) -
_$ /NAME=POLICY_1
|
OpenVMS Version 8.4 では，
DISMOUNT キーワードを使用している場合，
最大 12 の HBMM マスタ・ビットマップを持つことができます。
DISMOUNT キーワードの例は，
「MULTIUSE と DISMOUNT の例」
を参照してくださ。
SET SHADOW/POLICY=HBMM コマンドの完全な DCL 構文については，TBS を参照してください。
8.6.2 シャドウセットへの HBMM ポリシーの割り当て方法 | |
名前付きポリシーまたは名前なしポリシーをシャドウセットに割り当てることができます。
既存の名前付きポリシーを割り当てるには，次のコマンドを使用します。
$ SET SHADOW DSAn:/POLICY=HBMM=policy-name
|
名前なしポリシーをシャドウセットに割り当てるのにも同じコマンドを使用しますが，ポリシー名の代わりに，使用したいポリシー属性を指定します。
たとえば次のようにします。
$ SET SHADOW DSA1:/POLICY=HBMM=(MASTER_LIST=(NODE1, NODE2, NODE3), COUNT=2)
|
この例では，RESET_THRESHOLD キーワードが省略されているため，ビットマップ・リセットしきい値は，デフォルトの 1,000,000 ブロックになります。
8.6.3 シャドウセットで HBMM を有効にする方法 | |
HBMM は，以下の条件でシャドウセット上で自動的に有効になります。
-
シャドウセットをマウントする際に HBMM ポリシーが存在し，シャドウセットがマウントされているシステムの少なくとも 1 台が，ビットマップ・マスタ・システムである。
-
シャドウセットをマウントした後に HBMM ポリシーが作成され，シャドウセットがマウントされているシステムの少なくとも 1 台が，ビットマップ・マスタ・システムである。
また，ポリシーが存在し，シャドウセットがビットマップ・マスタ・システムにマウントされていれば，SET SHADOW/ENABLE=HBMM コマンドでも HBMM を有効にできます。
8.6.4 シャドウセットで HBMM を無効にする方法 | |
シャドウセットで HBMM を無効にするには，次のコマンドを使用します。
$ SET SHADOW DSAn:/DISABLE=HBMM
|
シャドウセットで HBMM を無効にする理由としては，以下のものが考えられます。
-
シャドウセットに関連付けられたポリシーを変更するため。
-
シャドウセットに関連付けられたポリシーを削除するため。
-
HBMM をサポートしていないシステムにそのシャドウセットをマウントするため。
HBMM をサポートしていないシステムにマウントするためには，まず HBMM を無効にし，次にそれをマウントしている HBMM 機能を持ったすべてのシステムからディスマウントする必要があります。
HBMM は，再度有効にするか，そのシャドウセットに対して新しいポリシーを定義するまで，無効のままになります。
8.6.5 シャドウセットに関連付けられたポリシーの削除方法 | |
シャドウセットに関連付けられたポリシーを削除する前に，HBMM が有効な場合には無効にする必要があります。
その後，次のコマンドを入力して，シャドウセットからポリシーの関連付けを削除することができます。
$ SET SHADOW DSAn:/POLICY=HBMM/DELETE
|
このコマンドは，このシャドウセットに設定された任意のポリシーを削除し，シャドウセットを初期 HBMM 状態に戻します。
それと同時に，シャドウセットは DEFAULT ポリシーの対象となります。
8.6.7 システムで HBMM を無効にする方法 | |
システムで HBMM を無効にする方法には次の 2 つがあります。
-
-
システムにマウントされている各システムで SET SHADOW/PRIORITY=0 DSAn コマンドを実行し，各シャドウセットでのマージ操作とコピー操作の優先順位にゼロを設定する。
8.6.8 名前付きポリシーをクラスタから削除する方法 | |
名前付きポリシーを削除するには，次の例に示すように，/DELETE 修飾子を使用します。
$ SET SHADOW /POLICY=HBMM/NAME=policy-name/DELETE
|
このコマンドを実行すると，指定した名前のポリシーが削除され，クラスタ全体に影響が現れます。
割り当て済みのポリシーがシャドウセットから削除されることはありません。
8.6.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
|
8.6.10 ポリシーの表示方法 | |
ポリシーは，SHOW SHADOW コマンドで表示することができます。
以下の内容を表示できます。
-
指定したシャドウセットに関連付けられているポリシー
-
-
クラスタ内でポリシーが割り当てられている全シャドウセットと，各ポリシーの定義
-
クラスタに存在するすべての名前付きポリシーとその定義
特定のシャドウセットのポリシーの表示
特定のシャドウセットに関連付けられたポリシーを表示するには，次のコマンドを実行します。
$ SHOW SHADOW DSAn:/POLICY=HBMM
|
出力結果の例を以下に示します。
$ SHOW SHADOW DSA999:/POLICY=HBMM
HBMM Policy for device _DSA999:
HBMM Reset Threshold: 1000000
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: 750000
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: 1000000
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: 1000000
HBMM Master lists:
Up to any 2 of the nodes: FLURRY,FREEZE,HOTTUB
HBMM Policy for device _DSA99:
HBMM Reset Threshold: 1000000
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: 1000000
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: 1000000
HBMM Master lists:
Up to any 6 nodes in the cluster
HBMM Policy PEAKS_ISLAND
HBMM Reset Threshold: 1000000
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: 1000000
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: 1000000
HBMM Master lists:
Up to any 2 of the nodes: QUEBEC,ICELND,SWEDEN
Any 1 of the nodes: ALASKA,GRNLND
|
8.6.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
|
8.6.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))
|
シャドウセットの HBMM が有効になっており，積極的に HBMM を使用している場合，SET SHADOW/DEMAND_MERGE DSAn: コマンドを実行するとミニマージ操作が開始されます。
ミニマージ操作の代わりにフルマージを強制的に実行するには，SET SHADOW/DEMAND_MERGE DSAn: コマンドを実行する前に，そのシャドウセットで HBMM を無効にする必要があります。
HBMM を無効にする方法については，8.6.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 コマンドで，シャドウセットのメンバ間に違いが見つかった場合。
-
ミニマージやフルマージが入出力のスループットに与える影響を測定したい場合。
表 8-1 「一時状態イベントの目に見える影響」 は，一時状態イベントのユーザに見える影響を，OpenVMS Cluster システム内の 1 台のシステム上の 1 つのシャドウセットの観点からまとめたものです。
一時状態イベントの種類ごとに，マージ (フルマージ，HBMM，コントローラ・ミニマージ) 操作やコピー (フルコピーまたはミニコピー) 操作がすでに実行中の場合の，シャドウセットに対する影響を挙げてあります。
この表でキーとなっている用語，キャンセル (Canceled)，再開 (Restarted)，続行 (Continued)，中断 (Suspended) は，Volume Shadowing for OpenVMS のメッセージと同じ意味です。
-
キャンセル (Canceled) -- 資格を持ったシステム上で再開または続行できるように，操作は停止される。
-
再開 (Restarted) -- 操作を再開する際には，同じシステム上で LBN 0 から再開する必要がある。 -
続行 (Continued) -- 操作は，キャンセルまたは中断されたときに終了した位置から続行される。 -
中断 (Suspended) -- 操作は，中断された操作が実行されていたシステム上でのみその SS に対する操作を開始，再開，続行できるような状態で停止される。
マージ操作とコピー操作の以下の特性に注意してください。
-
同じシャドウセットでマージとコピーの両方が保留中の場合は，マージがミニマージの場合に限り，コピーよりマージが先に行われます。
これは，コントローラ・ベース・ミニマージ，ホストベース・ミニマージ，フルコピー，ミニコピーのいずれにも言えます。
-
以前に発生したイベントの遅延時間の間に，遅延を伴うイベントが発生したときには，追加の遅延は起こりません。
以前の遅延時間が経過したときに，現在のイベントで必要なマージまたはコピーが処理候補として扱われます。
-
以前のイベントの遅延時間の間に，遅延なしのイベントが発生しても，以前の遅延時間が経過するまでは，「遅延なし」イベントで必要なマージやコピーは処理候補として扱われません。
表 8-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 台以上のシャドウセット・メンバとの接続が失われ，シャドウ・メンバのタイムアウト時間内に回復しなかった場合に，既存の HBMM ビットマップがミニコピー・ビットマップとして機能することを意味します。
OpenVMS Version 8.3 でこの機能が追加されるまでは，接続が回復した後で除外されたメンバをシャドウセットに復帰させる作業には時間がかかりました。
これは，除外されたメンバを復帰させるにはフル・コピーが必要なためでした。
ミニコピー操作にビットマップを利用できるようになったことにより，フル・コピー操作を実行するよりも時間が短縮できるようになりました。
接続が失われると，シャドウセットのボリューム処理は一時停止されます。つまり，接続が回復するか，タイムアウト時間 (SHADOW_MBR_TMO の値で決まります) が経過するまで，書き込みおよび読み取りが一時的に停止されます。
タイムアウト時間内に接続が回復しないと，そのメンバはシャドウセットから除外され，残りのメンバに対する読み書き I/O が再開され，ビットマップによって書き込みが追跡されます。
このビットマップの名前は HBMMx から rrsex に変更され，除外されたメンバ用のミニコピー・ビットマップとして機能します。
| | |
|
| 注記:
1 台または 2 台のメンバが除外され，すべてのメンバがシャドウセット・メンバとして復元された後も，HBMM ビットマップの機能は有効なまま残ります。
HBMM ビットマップの機能は，シャドウセットが 3 台のメンバで構成され，1 台のメンバが除外された場合にだけ役立ちます。
|
| | |
|
除外されたシャドウセット・メンバのいずれかに対する接続が回復すると，シャドウセットに再度マウントすることができます。
除外されたメンバのメタデータが既存のビットマップと一致する場合は，それがミニコピー操作で使用され，メンバがシャドウセットに復帰します。
2 台目のシャドウセット・メンバも同時に除外された場合は，そのメンバもそのビットマップを使用することができます。メンバがシャドウセットに復帰した後，ビットマップの名前は HBMM ビットマップ名に戻ります。
1 台以上のメンバがシャドウセットから除外されている時間を最小限にする理由は以下のとおりです。
-
シャドウセットのメンバが減っている間，データの可用性が危険な状態にあります。
-
シャドウセット・メンバが除外されても，残りのメンバに対する読み書きは継続されます。
除外されたメンバが復帰する前に多数の書き込みがあると，そのメンバをシャドウセットに復帰させるのに時間がかかります。
これは，ディザスタ・トレラント (DT) 構成で特に重要です。
ボリューム処理時の自動的なビットマップ作成を有効にするには，そのシャドウセットの HBMM ポリシーを設定し，ポリシーに新しい MULTIUSE キーワードを追加します。
OpenVMS Version 8.3 以降では，一定の条件のもと，HBMM 書き込みビットマップを使用してミニコピーを実行することができます。
MULTIUSE 属性を指定することにより，
接続が失われた結果としてシャドウセットからメンバが削除されたときに
フルコピーが実行されないようにすることでできます
(たとえば，リモート・サイトへのリンクが失われたときに MEDOF が発生します)。
MULITUSE がミニコピーを開始できない場合は，データの安全性を保証するためにフルコピーが行なわれます。
MULTIUSE 属性を使用してミニコピーを実行するには
以下のことが必要です。
-
すべての VMS クラスタ・メンバは OpenVMS Version 8.3 以上と
最新の Volume Shadowing のキットが実行されている必要があります。
-
HBMM を有効にします。
Multiuse 属性は HBMM 書き込みビットマップを使用します。
-
次のように，Multiuse 属性を指定する HBMM ポリシーを定義します。
SET SHADOW DSAnnn/POLICY=HBMM=((Master=(Node1, Node2), Count=2, Multiuse=1), (Master=(Node3, Node4), Count=2, Multiuse=2))
この構文のパラメータの意味は以下のとおりです。
-
Node1 および Node2 は
サイト A にあります。 -
Node3 および Node4 は
サイト B にあります。 -
Count には，このサイトで作成されるマスタ・ビットマップ数を指定します。
この値はリストしているノード数以下でなければなりません。
マスタ・ビットの総数は 6 に制限されます。
この値は，DISMOUNT=n を使用すると最大 12 まで増やせます。
DISMOUNT キーワードについての詳細は，
表 4-3 「SET SHADOW コマンドの修飾子」
および
8.11 項 「MULTIUSE と DISMOUNT の例」
を参照してください。
-
Multiuse には，
メンバがシャドウセットから自動的に削除される際に
マルチユース・ビットマップに変換できるマスタ・ビットマップ数を指定します。
この値は，そのサイトの COUNT の値以下でなければなりません。
シャドウセット・メンバを削除する際，このポリシーを使用するシャドウセットに対して作成された 2 つのマスタ HBMM ビットマップのうち，
サイト A では 1 つの HBMM マスタ・ビットマップのみがマルチユース・ビットマップに変換されます。
サイト B では，両方のマスタ・ビットマップが
マルチユース・ビットマップとして使用できます。
シャドウセットからメンバが削除されるまでは，
SHOW DEVICE/BITMAP コマンドの出力は，ミニマージ・ビットマップとしてビットマップを表示します。
メンバが削除されビットマップが実際に変換されるまでは，マルチユース・ビットマップとしては示されません。
マルチユース・ビットマップは HBMM リカバリを実行するのに使用できます(ノードが落ちてマージが発生する場合)。
あるいは，マルチユース・ビットマップは，
ミニコピーを使用して以前のメンバをシャドウセットに戻すのに使用できます。
マルチユース・ビットマップは，ミニコピーを使用して新しいメンバをシャドウセットに追加することはできません。
また，回復不能なドライブ・エラーでディスクが削除された場合，
壊れたディスクを戻す可能性は低いためビットマップはマルチユースに変換されません。
8.10.1 Multiuse 属性と DISMOUNT キーワード | |
DISMOUNT キーワードは，メンバを手動で削除する際にマルチユース・ビットマップへ変換する HBMM ビットマップの数を指定します。
MULTIUSE を省略した場合，ボリューム処理時の自動ミニコピーは有効にはなりません。
このため，マルチユース・ビットマップに変換される HBMM ビットマップはありません。
DISMOUNT を省略した場合，最大で 6 つの HBMM ビットマップだけをマルチユース・ビットマップとして使用することができます。
DISMOUNT キーワードの例については，8.11 項 「MULTIUSE と DISMOUNT の例」
を参照してください。
例 8-1 MULTIUSE および DISMOUNT キーワードの使用 (I)
$ SET SHADOW DSA1/POLICY=HBMM=(MASTER=*,COUNT=12,MULTIUSE=12,DISMOUNT=1)
|
この例では，12 のすべてのビットマップをマルチユース・ビットマップとして使用できるようにポリシーを設定しています。
DISMOUNT/POLICY=MINICOPY コマンドを実行すると，
1 つのミニマージ・ビットマップをマルチユース・ビットマップに変換します。
このマルチユース・ビットマップを MINICOPY コマンドとともに使用して，マウントを外したメンバをシャドウセットに戻すことができます。
つまり，シャドウセット・メンバの自動削除時に 12 のすべてのビットマップを使用することができ，手動削除時に 1 つのビットマップを使用できることを指定しています。
|
$ SHOW SHADOW
_DSA1: Volume Label: DDD
Virtual Unit State: Steady State
Enhanced Shadowing Features in use:
Host-Based Minimerge (HBMM)
Automatic Minicopy (AMCVP)
Dismount uses Multiuse Bitmaps
VU Timeout Value 3600 VU Site Value 0
Copy/Merge Priority 5000 Mini Merge Enabled
Recovery Delay Per Served Member 30
Merge Delay Factor 200 Delay Threshold 200
HBMM Policy
HBMM Reset Threshold: 1000000
HBMM Master lists:
Up to any 12 nodes in the cluster - Multiuse: 12 Dismount: 1
HBMM bitmaps are active on NODEA,KRISNA,MEERAA
Modified blocks since bitmap creation: 0
Device $1$MDA50 Master Member
Read Cost 1 Site 0
Member Timeout 120
Device $1$MDA51
Read Cost 1 Site 0
Member Timeout 120
$ SHOW DEV/BIT
Device BitMap Size Percent Type of Master Active
Name ID (Bytes) Populated Bitmap Node
DSA1: 000A0001 12 0.01% Minimerge NODEA Yes
000A0002 12 0.01% Minimerge KRISNA Yes
00090003 12 0.01% Minimerge MEERAA Yes
$ SHOW DEV DSA1
Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA1: Mounted 0 DDD 10139 1 3
$1$MDA50: (NODEA) ShadowSetMember 0 (member of DSA1:)
$1$MDA51: (NODEA) ShadowSetMember 0 (member of DSA1:)
NODEA$dismount $1$MDA51:/poli=mini
$ SHOW DEV/BIT
Device BitMap Size Percent Type of Master Active
Name ID (Bytes) Populated Bitmap Node
DSA1: 000A0001 12 0.01% Multiuse NODEA Yes
000A0002 12 0.01% Minimerge KRISNA Yes
00090003 12 0.01% Minimerge MEERAA Yes
$
|
|
例 8-2 MULTIUSE および DISMOUNT キーワード (II)
$ SET SHADOW DSA10/POLICY=HBMM=((MASTER=(*),COUNT=12,MULTIUSE=12,DISMOUNT=12))
|
この例では，12 のすべてのビットマップがマルチユース・ビットマップとして使用できることを規定したポリシーが設定されています。
DISMOUNT/POLICY=MINICOPY コマンドを実行すると，
12 のミニマージ・ビットマップがマルチユース・ビットマップに変換されます。
マウントを外したメンバをシャドウセットに戻すには，
MINICOPY コマンドでこのマルチユース・ビットマップを使用することができます。
つまり，シャドウセット・メンバの自動削除時あるいは手動削除時に 12 のすべてのビットマップを使用することができることを指定しています。
|
$ SHOW DEVICE DSA10/BIT
Device BitMap Size Percent Type of Master Active
Name ID (Bytes) Populated Bitmap Node
DSA10: 00010085 6196 0.01% Minimerge LEXUS Yes
00010086 6196 0.01% Minimerge DARWIN Yes
00010087 6196 0.01% Minimerge NAPALM Yes
00010088 6196 0.01% Minimerge SPIFF Yes
00010089 6196 0.01% Minimerge CALVIN Yes
0001008A 6196 0.01% Minimerge LOPEZ Yes
0001008B 6196 0.01% Minimerge OBELIX Yes
0001008C 6196 0.01% Minimerge KRUSTY Yes
0001008D 6196 0.01% Minimerge GIMLI Yes
0001008E 6196 0.01% Minimerge HOMER Yes
0001008F 6196 0.01% Minimerge OOTY Yes
00010090 6196 0.01% Minimerge HOBBES Yes
$ DISMOUNT $1$DGA4996: /POLICY=MINI
$ SHOW DEVICE DSA10/bit
Device BitMap Size Percent Type of Master Active
Name ID (Bytes) Populated Bitmap Node
DSA10: 00010085 6196 0.01% Multiuse LEXUS Yes
00010086 6196 0.01% Multiuse DARWIN Yes
00010087 6196 0.01% Multiuse NAPALM Yes
00010088 6196 0.01% Multiuse SPIFF Yes
00010089 6196 0.01% Multiuse CALVIN Yes
0001008A 6196 0.01% Multiuse LOPEZ Yes
0001008B 6196 0.01% Multiuse OBELIX Yes
0001008C 6196 0.01% Multiuse KRUSTY Yes
0001008D 6196 0.01% Multiuse GIMLI Yes
0001008E 6196 0.01% Multiuse HOMER Yes
0001008F 6196 0.01% Multiuse OOTY Yes
00010090 6196 0.01% Multiuse HOBBES Yes
|
|
ミニコピーが完了し，マウントの外されていたメンバがシャドウセットに戻されると，
マルチユース・ビットマップはミニマージ・ビットマップに変換されます。
$ SHOW DEVICE DSA301/BIT
Device BitMap Size Percent Type of Master Active
Name ID (Bytes) Populated Bitmap Node
DSA301: 00010085 6196 0.01% Minimerge LEXUS Yes
00010086 6196 0.01% Minimerge DARWIN Yes
00010087 6196 0.01% Minimerge NAPALM Yes
00010088 6196 0.01% Minimerge SPIFF Yes
00010089 6196 0.01% Minimerge CALVIN Yes
0001008A 6196 0.01% Minimerge LOPEZ Yes
0001008B 6196 0.01% Minimerge OBELIX Yes
0001008C 6196 0.01% Minimerge KRUSTY Yes
0001008D 6196 0.01% Minimerge GIMLI Yes
0001008E 6196 0.01% Minimerge HOMER Yes
0001008F 6196 0.01% Minimerge OOTY Yes
00010090 6196 0.01% Minimerge HOBBES Yes
|
次の例では，12 のすべてのビットマップ・スロットが使用されているため，さらにコマンドを使用してビットマップを作成しようとすると失敗する例を示しています。
$DISM $1$DGA4993: /POLICY=MINI
%DISM-W-CANNOTDMT, $1$DGA4993: cannot be dismounted
%SYSTEM-F-WBMERR, WBM error during dismount
|
|
