本文に進む 日本−日本語
日本ヒューレット・パッカードホーム 製品とサービス お客様サポート/ ダウンロード ソリューション ご購入の方法
≫ お問い合わせ
日本ヒューレット・パッカードホーム
HP OpenVMS: Volume Shadowing for OpenVMS 説明書

第7章 ミニコピーによるデータのバックアップ (Alpha)

≫ 

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

目次
まえがき
第1章:Volume Shadowingの紹介
第2章:システムに高度な可用性を構成する
第3章:ボリューム・シャドウイングを使うための準備
第4章:DCLコマンドによるシャドウセットの作成と管理
第5章:システムサービスによるシャドウセットの作成と管理
第6章:シャドウセットの整合性の保証
第7章:ミニコピーによるデータのバックアップ
第8章:シャドウ化されたシステムでのシステム管理作業
第9章:ボリュームシャドウイングの性能
付録A:メッセージ
用語集
索引
PDF
OpenVMS ホーム
ここから本文が始まります

目次

7.1 ミニコピーとは何か
7.2 コピーとミニコピーの異なる使い方
7.3 ミニコピーを使う理由
7.4 ミニコピーを使う手順
7.5 ミニコピーの制限
7.6 書き込みビットマップの作成
7.6.1 DISMOUNT での書き込みビットマップの作成
7.6.2 MOUNT での書き込みビットマップの作成
7.7 ミニコピー操作の開始
7.8 マスタおよびローカルの書き込みビットマップ
7.9 書き込みビットマップのメッセージとシャドウ・セットの制限を管理するシステム・パラメータ
7.10 DCL コマンドによる書き込みビットマップの管理
7.10.1 書き込みビットマップのサポートと動作の調査
7.10.2 書き込みビットマップ ID の表示
7.10.3 クラスタ・メンバの書き込みビットマップ・ステータスの表示
7.10.4 書き込みビットマップの削除
7.11 書き込みビットマップによる性能への影響
7.12 バックアップ用にシャドウ・セット・メンバを使う際のガイドライン
7.12.1 バックアップ用にシャドウ・セット・メンバを削除する
7.12.2 データ整合性の要件
7.12.3 アプリケーションの動作
7.12.4 RMS への配慮
7.12.5 マップされたファイル
7.12.6 データベース・システム
7.12.7 ベース・ファイル・システム
7.12.8 $QIO ファイル・アクセスと VIOC
7.12.9 マルチ・シャドウ・セット
7.12.10 ホスト・ベースの RAID
7.12.11 OpenVMS Cluster 操作
7.12.12 テスト
7.12.13 データの復元
7.12.14 データ整合性を確保する手順の再評価

この章では,OpenVMS バージョン 7.3 から導入された Volume Shadowing for OpenVMS のミニコピー機能を説明します。 ミニコピーとそれを実現するテクノロジである書き込みビットマップは, OpenVMS Alpha システムに完全に実装されています。OpenVMS VAX ノードでは, この機能を使っているシャドウ・セットに書き込みはできますが, マスタ書き込みビットマップを作成したり,DCL コマンドで管理することはできません。 アーキテクチャが混在している OpenVMS Cluster システムでミニコピーを使うためには,1 台の Alpha システムがあれば十分です。

ミニコピーの主な目的は, シャドウ・セット・メンバをシャドウ・セットに戻す時間を短縮することです。 通常,シャドウ・セット・メンバを削除するのはデータのバックアップのためであり, それがすむとシャドウ・セットのメンバに戻します。

7.1 ミニコピーとは何か

ミニコピー操作は,コピー操作を効率化したものです。ミニコピーによって シャドウ・セット・メンバのデータがシャドウ・セットに戻されたとき, シャドウ・セットのデータと同じになることが保証されます。

書き込みビットマップはシャドウ・セットへの書き込みを追跡し, シャドウ・セット・メンバをシャドウ・セットに戻す際の ミニコピー操作を指示するために使われます。

シャドウ・セット・メンバを削除する前は, 図 7-1 「アプリケーションによるシャドウ・セットへの書き込み」 に示すように,アプリケーションからの書き込みは直接シャドウ・セット (仮想ユニットとも言う) に送られます。

図 7-1 アプリケーションによるシャドウ・セットへの書き込み

アプリケーションによるシャドウ・セットへの書き込み

シャドウ・セット・メンバをディスマウントするときにミニコピー修飾子 (/POLICY=MINICOPY[=OPTIONAL]) を指定すると, 書き込みビットマップが作成されます。 シャドウ・セットへのその後の書き込みは,書き込みビットマップに記録されます。 書き込みビットマップへの記録は, 対応する書き込みの論理ブロック番号 (LBN) だけで, 内容ではないことに注意してください。 アドレスは,書き込みビットマップに 1 つ以上のビットを設定することで表現されます。 各々のビットは 127 ディスク・ブロックの範囲に対応します。

データが 127 ブロックの範囲のどこかのブロックに書き込まれると, その範囲に対応する書き込みビットマップのビットが設定されます。 ビットが設定されると,そのデータが,図 7-2 「アプリケーションによる書き込みビットマップへの書き込み」 に示すように,シャドウ・セットに書き込まれます。

図 7-2 アプリケーションによる書き込みビットマップへの書き込み

アプリケーションによる書き込みビットマップへの書き込み

メンバをシャドウ・セットを戻すとき,書き込みビットマップは, 図 7-3 「シャドウ・セット (仮想ユニット) に戻されるメンバ」 に示すようにミニコピー操作の指示のために使われます。 ミニコピー操作が行われている間でも, アプリケーションはシャドウ・セットの読み書きを継続できます。

図 7-3 シャドウ・セット (仮想ユニット) に戻されるメンバ

シャドウ・セット (仮想ユニット) に戻されるメンバ

システム管理者が 7.12 項 「バックアップ用にシャドウ・セット・メンバを使う際のガイドライン」 のガイドラインに従っている限り,ミニコピー機能を使うと, メンバをシャドウ・セットに戻す際のフル・コピーは不要になります。 この章では,コピーとフル・コピーは同じ意味で使っていることに注意してください。

いくつかの DCL コマンドを,書き込みビットマップの管理のために使うことができます。 OpenVMS Cluster システムでの書き込みビットマップの更新の管理や,ノードごとのシャドウ・セットの上限数を設定するためのシステム・パラメータが用意されています。

7.2 コピーとミニコピーの異なる使い方

ミニコピーが導入される前は,コピー操作は 2 つの目的で使われていました。 仮想ユニットにメンバを追加するのと, 削除されたメンバを元のシャドウ・セットに戻すためです。 メンバを仮想ユニットに戻すためには, そのメンバのデータをシャドウ・セットのデータに一致させなければなりません。

コピー操作は,複数メンバ・シャドウ・セットを作成するための代表的な方法です。 (DCL コマンド INITIALIZE/SHADOW を使用して,空の複数メンバ・シャドウ・セットを作成することもできます。) メンバをシャドウ・セットに戻す場合は, コピー操作よりもミニコピー操作の方が優れています。

通常,シャドウ・セット・メンバを削除する目的は, データをテープやディスクにバックアップするためです。

シャドウ・セット・メンバをバックアップ操作で使うためには, システム管理者は次の手順に従う必要があります。

  • SHOW DEVICE コマンドを使って, 仮想ユニットにマージ操作がマークされていないことを確認します。

  • アプリケーションの入出力を止めます。

    止める方法は,アプリケーションやコンピューティング環境に依存します。

  • シャドウ・セット・メンバを削除します。

  • アプリケーションを再起動します。

  • シャドウ・セット・メンバのデータをディスクやテープにバックアップします。

    バックアップを行っている間, アプリケーションはシャドウ・セットの残りのメンバにデータを書き込みます。

  • バックアップが完了したら, シャドウ・セット・メンバをシャドウ・セットに戻します。

注意:

この形式のバックアップがサポートされる条件についての詳細は, 7.12 項 「バックアップ用にシャドウ・セット・メンバを使う際のガイドライン」 を参照してください。

7.3 ミニコピーを使う理由

ミニコピー操作は,システム管理者の意志で, システム管理者が決めた時間に使うことができます。

ミニコピーを使うと,シャドウ・セットにメンバを戻すために要する時間が著しく短縮されるため,システム管理者が行うシャドウ・セット・メンバの削除と復元を柔軟に計画することができ,可用性が向上します。

ミニコピーの実行に要する時間は,ディスクを外していた間にシャドウ・セットに加えられた変更の量に比例します。 コピー時間が短縮されることで,バックアップの管理が容易になります。

表 7-1 「ミニコピーとフル・コピーの性能比較」 には一連のテスト結果を示しています。 ここではシャドウ・セットに多様な書き込みが行われたときのフル・コピーとミニコピーに要する時間の比較を行っています。 表 7-1 「ミニコピーとフル・コピーの性能比較」表 7-2 「ミニコピーとハードウェア補助付き (DCD) コピーの性能比較」 は,ミニコピーを使ったときに得られる性能向上の目安として参考にしてください。

表 7-1 ミニコピーとフル・コピーの性能比較

設定されているビットの割合

フル・コピーの時間 (秒)

ミニコピーの時間 (秒)

フル・コピーの時間に対するミニコピーの時間の割合

100%

4196.09

3540.21

84.4%

90%

3881.95

3175.92

81.8%

80%

3480.50

2830.47

81.3%

75%

3290.67

2614.87

79.5%

70%

3194.05

2414.03

75.6%

60%

2809.06

2196.60

78.2%

50%

2448.39

1759.67

71.9%

40%

2076.52

1443.44

69.5%

30%

1691.51

1039.90

61.5%

25%

1545.94

775.35

50.2%

20%

1401.21

682.67

48.7%

15%

1198.80

554.06

46.2%

10%

1044.33

345.78

33.1%

5%

905.88

196.32

21.7%

2%

712.77

82.79

11.6%

1%

695.83

44.90

6.5%

 

表 7-2 「ミニコピーとハードウェア補助付き (DCD) コピーの性能比較」 は,別の一連のテストの結果です。 多様な書き込みについて,ハードウェア補助付きコピー (HSJ コントローラで MSCP ディスク・コピー・データ (DCD) コマンドを使用) とミニコピーに要求する時間を比較しています。

表 7-2 ミニコピーとハードウェア補助付き (DCD) コピーの性能比較

設定されているビットの割合

DCD コピーの時間 (秒)

ミニコピーの時間 (秒)

DCD コピーの時間に対するミニコピーの時間の割合

100%

1192.18

1181.61

99.1%

90%

1192.18

1097.03

92.0%

80%

1192.18

979.06

82.1%

70%

1192.18

862.66

72.4%

60%

1192.18

724.61

60.8%

50%

1192.18

627.24

52.6%

40%

1192.18

490.70

41.2%

30%

1192.18

384.45

32.3%

20%

1192.18

251.53

21.1%

10%

1192.18

128.11

10.7%

5%

1192.18

71.00

6.0%

0%

1192.18

8.32

0.7%

 

7.4 ミニコピーを使う手順

ミニコピー操作を使うには,以下の手順に従います。

  1. 書き込みビットマップを開始します。

    書き込みビットマップは,シャドウ・セットからメンバを削除するときに, DISMOUNT コマンドに新しい修飾子 /POLICY=MINICOPY[=OPTIONAL] を指定すると開始されます。 7.6.2 項 「MOUNT での書き込みビットマップの作成」 で説明するように, 1 つまたは 2 つ少ない数のメンバをシャドウ・セットにマウントするために, MOUNT コマンドを使っても,書き込みビットマップが開始されます。

  2. シャドウ・セット・メンバをシャドウ・セットに戻すときに, ミニコピー操作のために書き込みビットマップを使います。

    そのシャドウ・セット用の書き込みビットマップが存在する場合, ミニコピー操作は,デフォルトで次の MOUNT コマンドで起動されます。

    $ MOUNT DSA42/SHAD=$4$DUA42 volume-label
    

    ミニコピーだけが実行されるようにするには,次の例に示すとおり, /POLICY=MINICOPY 修飾子を使います。

    $ MOUNT DSA42/SHAD=$4$DUA42 volume-label/POLICY=MINICOPY
    

    ミニコピーのための書き込みビットマップが存在しない場合は, マウントは失敗します。

    ミニコピー操作が完了すると, そのディスクに対応する書き込みビットマップは消去されます。

MOUNT および DISMOUNT コマンドの /POLICY=MINICOPY[=OPTIONAL] 修飾子の使い方の詳細は,7.6 項 「書き込みビットマップの作成」7.7 項 「ミニコピー操作の開始」 を参照してください。

7.5 ミニコピーの制限

以下は,ミニコピーを使う場合の制限です。

  • OpenVMS Cluster 内のすべてのノードが,OpenVMS Alpha バージョン 7.2--2, OpenVMS バージョン 7.3 (以降),またはこれらのバージョンの組み合わせのいずれかで稼働している場合にだけ, クラスタ内でミニコピーを使用することができます。 OpenVMS VAX バージョン 7.3 は, OpenVMS Alpha ノードがマスタとなるビットマップをサポートし, 加わることができます。 クラスタ内でこれらよりも前のバージョンの OpenVMS を使おうとすると, ミニコピー機能は使用できなくなります。

  • 書き込みビットマップは一度しか使えません。

    たとえば,ディスマウントされた 3 メンバ (D1,D2,D3) のシャドウ・セットがある場合,D1 だけを /POLICY=MINICOPY[=OPTIONAL] 修飾子を指定してマウントし直すと,書き込みビットマップが作成されます。 このシャドウ・セットに D2 を戻そうとすると,自動的にミニコピーが実行されます。 そして残りのメンバ D3 をシャドウ・セットにマウントすると, 今度はフル・コピー操作が実行されます。

    この最後のメンバ D3 のフル・コピーを避けるためには,/POLICY=MINICOPY を指定して,シャドウ・セット・メンバを一度に 1 つずつディスマウントします。 こうすれば,シャドウ・セットのメンバごとに書き込みビットマップを用意できます。 各々のディスクをシャドウ・セットに戻すとき, それぞれにミニコピーが可能になります。

  • 1 つの MOUNT コマンドで 2 つのメンバを指定すると,どちらのメンバがミニコピー操作でアップデートされるか優先度をつけることはできません。

    ミニコピーが即座に行われるようにするためには,各々の MOUNT コマンドで, 1 つのシャドウ・セット・メンバだけを指定します。そしてミニコピーが開始されるのを待ち,別の MOUNT コマンドで次のメンバを追加します。

  • ボリューム・シャドウイング・ソフトウェアによって,シャドウ・セットに既にマージ操作がマークされている場合,マージ操作が行われ, 書き込みビットマップは作成されません。

  • 仮想ユニットがディスマウントされたときに, 仮想ユニットの未使用の書き込みビットマップがメモリに残ります。 仮想ユニットが再びマウントされると,自動的に削除されます。

    7.10.4 項 「書き込みビットマップの削除」 で説明するように, 余分な書き込みビットマップは,DELETE コマンドで削除できます。

  • 間違いやすいエラー・メッセージ

    書き込みビットマップを開始してシャドウ・セット・メンバを (DISMOUNT/POLICY=MINICOPY[=OPTIONAL] を指定して) ディスマウントしようとすると,シャドウ・セット・メンバでマージ操作が実行中か, コピーのターゲットになっている場合, 次のエラー・メッセージが表示されます。

    %DISM-F-SRCMEM, only source member of shadow set cannot be dismounted
    

    ミニコピーの将来のバージョンでは, もっとわかりやすいエラー・メッセージに変更される予定です。

  • マスタ書き込みビットマップを 1 つ以上持っているノードがシステム・ダウンあるいはクラッシュすると,そのノード上のビットマップは抹消されます。 したがって,マスタ・ビットマップが抹消されたシャドウ・セットは, ミニコピー操作ができなくなります。その代わりにフル・コピーが実行されます。

  • シャドウ・セット・メンバがエラーやタイムアウトでシャドウ・セットから切り離されると,書き込みビットマップは使えなくなります。 書き込みビットマップはシャドウ・セット・メンバが明示的にディスマウントされたときだけ,ミニコピーで使うことができます。

  • アーキテクチャが混在した OpenVMS Cluster システムでミニコピー機能を使う場合, すべての VAX システムで SHADOW_MAX_COPY システム・パラメータを 0 にすることをお勧めします。この設定を行うと,Alpha 上でミニコピーを行おうとしたときに, VAX 上でコピーが行われることが防げます。 ただし,アーキテクチャが混在したクラスタで, シャドウ・セットにメンバを追加する作業が VAX システムに割り当てられることは, ほとんどありません。これは,VAX システムではミニコピーが行えないので, 代わりにフル・コピーが実行されるためです。SHADOW_MAX_COPY については, 3.3 項 「ボリューム・シャドウイングのパラメータ」 を参照してください。

  • OpenVMS Alpha バージョン 7.2–2 または 7.3 が稼働しているシステムでは,シャドウ・セットにメンバを戻すためにミニコピー操作が使われたシステム・ディスク・シャドウ・セット内のダンプ・ファイルにアクセスするには,追加の手順が必要です。 詳細は,1.4.2.1 項 「ミニコピーが使われた場合の,シャドウ化されたシステム・ディスクのダンプ・ファイルの取得」 を参照してください。

7.6 書き込みビットマップの作成

書き込みビットマップの作成には,DCL コマンドの DISMOUNT と MOUNT が使われます。MOUNT コマンドは,書き込みビットマップを使ったミニコピー操作を開始するためにも使われます (7.7 項 「ミニコピー操作の開始」 を参照)。

7.6.1 DISMOUNT での書き込みビットマップの作成

DISMOUNT コマンドで書き込みビットマップを作成するには, /POLICY=MINICOPY[=OPTIONAL] 修飾子を指定します。 /POLICY=MINICOPY=OPTIONAL を指定すると,十分なメモリがあれば, 書き込みビットマップが作成されます。書き込みビットマップが作成されたかどうかにかかわらず,ディスクはディスマウントされます。

次の例は, DISMOUNT コマンド の /POLICY=MINICOPY=OPTIONAL 修飾子の使い方を示しています。

$ DISMOUNT $4$DUA1 /POLICY=MINICOPY=OPTIONAL

このコマンドは,シャドウ・セットから $4$DUA1 を削除し, 可能ならば,書き込みビットマップへのログの書き込みを開始します。

/POLICY=MINICOPY とだけ (すなわち,=OPTIONAL を省略) 指定して, ノードに書き込みビットマップを作成するのに十分なメモリがなかった場合は, ディスマウントは失敗します。

7.6.2 MOUNT での書き込みビットマップの作成

以下の条件のとき,MOUNT コマンドで書き込みビットマップを作成できます。

  • 以前マウントされていたシャドウ・セットが,正しくディスマウントされていた。

    複数メンバのシャドウ・セットは,以前のマウントでは,同一のノード, 同一クラスタの別のノード,あるいは,クラスタ外の別のノードに, マウントされていなければなりません。

  • シャドウ・セットをマウントしようとしているノードがクラスタに組み込まれている場合,そのシャドウ・セットは現在, クラスタ内のどのノードにもマウントされていない。

  • シャドウ・セットをマウントするとき,1 メンバ少なくしてマウントする。

  • MOUNT コマンドで /POLICY=MINICOPY[=OPTIONAL] 修飾子を指定する。

このコマンドで作成される書き込みビットマップは, 後でシャドウ・セットの以前のメンバをシャドウ・セットにマウントするときに, ミニコピー操作で使われます。

/POLICY=MINICOPY=OPTIONAL 修飾子を指定したときに, シャドウ・セットがクラスタ内の別のノードに既にマウントされていた場合, MOUNT コマンドは成功しますが,書き込みビットマップは作成されません。

7.7 ミニコピー操作の開始

シャドウ・セット・メンバに書き込みビットマップが存在する場合, シャドウ・セットにシャドウ・セット・メンバを戻すために MOUNT コマンドを実行すると,デフォルトでミニコピー操作が開始されます。 これは, MOUNT コマンドに /POLICY=MINICOPY=OPTIONAL 修飾子を指定したのと同じです。 書き込みビットマップが存在しない場合,フル・コピーが行われます。

MOUNT コマンドで /POLICY=MINICOPY=OPTIONAL 修飾子を使う例は, 次のとおりです。

$ MOUNT DSA5/SHAD=$4$DUA0/POLICY=MINICOPY=OPTIONAL volume-label

シャドウ・セット (DSA5) が既にマウントされていて, このシャドウ・セット・メンバ ($4$DUA0) に書き込みビットマップが存在している場合,このコマンドでは,ミニコピー操作によって, デバイス $4$DUA0 がシャドウ・セットに追加されます。 書き込みビットマップが存在していない場合, このコマンドはフル・コピーで $4$DUA0 を追加します。

ミニコピー操作が行われるときだけ MOUNT コマンドを成功させたいときは, /POLICY=MINICOPY とだけ (つまり,=OPTIONAL を省略) 指定します。 この場合,書き込みビットマップが使えなければ,マウントは失敗します。

7.8 マスタおよびローカルの書き込みビットマップ

OpenVMS Cluster システムでは, マスタ書き込みビットマップ は, 書き込みビットマップを作成する DISMOUNT や MOUNT のコマンドを発行したノードに作成されます。 マスタ書き込みビットマップが作成される際に,シャドウ・セットがマウントされているクラスタ内のすべてのノードでは,ノードにメモリが十分あれば, ローカル書き込みビットマップ が自動的に作成されます。

マスタ書き込みビットマップには,シャドウ・セットをマウントしているクラスタ内のすべてのノードでのシャドウ・セットへの書き込みがすべて記録されます。ローカル書き込みビットマップには, ローカル・ノードでのシャドウ・セットへの書き込みがすべて記録されます。

ローカル書き込みビットマップを持つノードがシャドウ・セットの同じ論理ブロック番号 (LBN) へ複数回書き込みを行っても, 最初の書き込みの LBN だけがマスタ書き込みビットマップに送られることに注意してください。 ミニコピー操作では,LBN がアップデートされた事実だけを使い, その LBN が変更された回数は使いません。

ローカル書き込みビットマップを作成するための十分なメモリがノードに存在しない場合,そのノードは,書き込みのたびにメッセージを直接マスタ書き込みビットマップに送ります。 これにより,アプリケーションの書き込み性能が落ちます。

7.9 書き込みビットマップのメッセージとシャドウ・セットの制限を管理するシステム・パラメータ

OpenVMS Cluster システムには,マスタ書き込みビットマップとそれに対応するローカル書き込みビットマップとの間のアップデート・トラフィックを管理するために使われるシステム・パラメータがあります。 別のパラメータには,書き込みビットマップのシステム・メッセージをオペレータ・コンソールに送信するかどうか,そして送信する場合にメッセージの量を制御する新しいシステム・パラメータがあります。 これらのシステム・パラメータは動的です。 つまり,実行中のシステムで変更できます。 これらのパラメータを,表 3-4 「書き込みビットマップのシステム・パラメータ」 に示します。

また,新しいボリューム・シャドウイング・システム・パラメータとして, 1 つのノードに存在できるシャドウ・セットの最大数を指定する SHADOW_MAX_UNIT も用意されました。 このパラメータは,表 3-1 「ボリューム・シャドウイングのパラメータ」 で説明しています。

書き込みビットマップのメッセージ・トラフィックを管理するシステム・パラメータによって,マスタ書き込みビットマップをアップデートするためのメッセージをバッファリングして, 単一の SCS メッセージとしてパッケージ化するか, あるいは毎回,直接送るかを制御します。 このシステム・パラメータは,メッセージ・トラフィックの上限および下限のしきい値とトラフィックを計測する周期を設定するために,使われます。

各々のリモート・ノードで発行される書き込みは,デフォルトでは, 個別の SCS メッセージとして,マスタ書き込みビットマップのあるノードに送られます。 これを,シングル・メッセージ・モード と言います。

リモート・ノードから送られてくる書き込みが,指定された周期で上限しきい値に到達した場合,シングル・メッセージ・モードは バッファード・メッセージ・モード に切り替わります。 バッファード・メッセージ・モードでは,最大 9 個のメッセージが, 指定された周期内に収集され,1 個の SCS メッセージとして送られます。 メッセージ・トラフィックが多い時間帯では, マスタ書き込みビットマップへの複数のメッセージをグループ化し, 1 つの SCS メッセージとして送ると,通常,個々のメッセージを別個に送るより効率的です。

7.10 DCL コマンドによる書き込みビットマップの管理

SHOW DEVICE,SHOW CLUSTER,および DELETE のコマンドが, 書き込みビットマップを管理するために機能拡張されました。

7.10.1 書き込みビットマップのサポートと動作の調査

あるシャドウ・セットに書き込みビットマップが存在するかどうかは, DCL コマンドの SHOW DEVICE/FULL device-name で調べることができます。 シャドウ・セットが書き込みビットマップをサポートしていれば,device supports bitmaps が, bitmaps activeno bitmaps active のいずれかとともに,表示されます。 デバイスが書き込みビットマップをサポートしていなければ, 書き込みビットマップについてのメッセージは何も表示されません。

以下のコマンド例は, どの書き込みビットマップもアクティブでないことを示しています。

$ SHOW DEVICE/FULL DSA0

Disk DSA0:, device type RAM Disk, is online, mounted, file-oriented device,
    shareable, available to cluster, error logging is enabled, device supports
    bitmaps (no bitmaps active) .

    Error count                    0    Operations completed                 47
    Owner process                 ""    Owner UIC                      [SYSTEM]
    Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
    Reference count                2    Default buffer size                 512
    Total blocks                1000    Sectors per track                    64
    Total cylinders                1    Tracks per cylinder                  32
    Volume label              "TST0"    Relative volume number                0
    Cluster size                   1    Transaction count                     1
    Free blocks                  969    Maximum files allowed               250
    Extend quantity                5    Mount count                           1
    Mount status              System    Cache name      "_$252$DUA721:XQPCACHE"
    Extent cache size             64    Maximum blocks in extent cache       96
    File ID cache size            64    Blocks currently in extent cache      0
    Quota cache size               0    Maximum buffers in FCP cache        404
    Volume owner UIC        [SYSTEM]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD

  Volume Status:  ODS-2, subject to mount verification, file high-water marking,
      write-back caching enabled.

Disk $252$MDA0:, device type RAM Disk, is online, member of shadow set DSA0:.

    Error count                    0    Shadow member operation count       128
    Allocation class             252
                                             

Disk $252$MDA1:, device type RAM Disk, is online, member of shadow set DSA0:.

    Error count                    0    Shadow member operation count       157
    Allocation class             25

7.10.2 書き込みビットマップ ID の表示

DCL コマンドの SHOW DEVICE/BITMAP device-name で, ノード上の各々の書き込みビットマップの ID を調べることができます。 SHOW DEVICE の /BITMAP 修飾子は,/FULL 以外の修飾子と組み合わせることはできません。SHOW DEVICE/BITMAP の表示には, 省略形と完全形があります。省略形がデフォルトです。

どのビットマップもアクティブでない場合,ビットマップ ID は表示されません。 no bitmaps active というメッセージが表示されます。

以下の例は,SHOW DEVICE/BITMAP の表示です。

$ SHOW DEVICE/BITMAP DSA1 
Device         BitMap        Size        Percent of 
Name           ID            (Bytes)     Full Copy 
DSA1:          00010001      652         11%  

以下の例は,SHOW DEVICE/BITMAP/FULL の表示です。

$ SHOW DEVICE DSA12/BITMAP/FULL 
Device  Bitmap  Size   Percent of  Active Creation        Master  Cluster Local Delete  Bitmap  
Name    ID     (bytes) Full Copy          Date/Time       Node    Size    Set   Pending Name 
                       
DSA12: 00010001  652    11%       Yes  5-MAY-2000 13:30...300F2    127      2%    No   SHAD$TEST
注意:

ビットマップ名は,SHOW/DEVICE/FULL を指定したときだけ表示され,SHAD$volume-name の後に複数 (約 30 文字) の読めない文字が続く形式で表示されます。 これらの読めない文字は,ビットマップの世代番号,作成時刻,およびその他の詳細を内部的に表すために使用されます。 ビットマップ名は,内部的にのみ使用されます。 ビットマップ ID は,システム管理者が使用します。

7.10.3 クラスタ・メンバの書き込みビットマップ・ステータスの表示

以下の例に示すように,SHOW CLUSTER 表示の中で ADD BITMAPS コマンドを発行することによって,ビットマップ情報の表示を指定することができます。

$ SHOW CLUSTER/CONTINUOUS

Command > ADD BITMAPS
Command > ADD CSID

View of Cluster from system ID 57348  node: WPCM1     14-FEB-2000 13:38:53

      SYSTEMS              MEMBERS       
  NODE   SOFTWARE    CSID   STATUS    BITMAPS  

 CSGF1   VMS X6TF    300F2   MEMBER    MINICOPY  

 HSD30Y  HSD YA01    300E6                  

 HS1CP2  HSD V31D    300F4                  

 CSGF2   VMS X6TF    300D0  MEMBER    MINICOPY  

この例で,MINICOPY は,ノード CSGF1 と CSGF2 がミニコピー操作をサポートできることを意味します。 クラスタ・ノードがミニコピーをサポートしていない場合,MINICOPY の代わりに UNSUPPORTED が表示され, クラスタ内でミニコピー機能が無効になっています。

7.10.4 書き込みビットマップの削除

ミニコピー操作が完了すると, 対応する書き込みビットマップは自動的に削除されます。

1 つ以上の書き込みビットマップを削除したい場合があります。 ビットマップを削除したい理由には,以下のものがあります。

  • 書き込みビットマップで使われているメモリを回収する

  • 書き込みビットマップの記録を停止する

書き込みビットマップは,/BITMAP 修飾子を指定して DCL コマンドの DELETE を実行することで削除できます。 ビットマップ修飾子を使って,削除したいビットマップの ID を指定することができます。 たとえば,次のとおりです。

$ DELETE/BITMAP/LOG 00010001

%DELETE-I-DELETED, 00010001 deleted

7.11 書き込みビットマップによる性能への影響

書き込みビットマップが性能に与える影響は,2 つの要素で決まります。 ローカルおよびマスタの書き込みビットマップ間のメッセージ・トラフィックと各々のビットマップに必要なメモリ量です。

メッセージ・トラフィックはメッセージ・モードを変更することで調整できます。 メッセージ・モードのデフォルトはシングル・メッセージ・モードです。 バッファード・メッセージ・モードでは,システム全体の性能が改善されますが, 各々のプロセスの書き込みがマスタ書き込みビットマップに記録されるまでの時間が通常長くなります。 これらのモードについての詳細は, 7.9 項 「書き込みビットマップのメッセージとシャドウ・セットの制限を管理するシステム・パラメータ」 を参照してください。

「メモリ要件」 で説明しているように,書き込みビットマップを使用するとメモリの使用量が増えます。 使用しているシステムのメモリ使用状況によっては,メモリの追加が必要になるかもしれません。

7.12 バックアップ用にシャドウ・セット・メンバを使う際のガイドライン

Volume Shadowing for OpenVMS は, オンライン・バックアップ・メカニズムとして使うことができます。 アプリケーションの設計や操作手順が正しければ, マウントされているシャドウ・セットから削除したシャドウ・セット・メンバは, バックアップに使えます。

Volume Shadowing for OpenVMS を使って,ファイル・システムやアプリケーション・データベースのコピーをバックアップ用に取得する標準的な方法は,仮想ユニットがマージ状態にないことを確認し, 仮想ユニットをディスマウントし,その後仮想ユニットを, メンバを 1 つ減らした状態でマウントし直すことです。 OpenVMS バージョン 7.3 より前では, マウントされていてアクティブに使われている仮想ユニットから, バックアップ用にシャドウ・セット・メンバを個別にディスマウントするときの, 一般的な制限事項についてのドキュメントがありました。 この制限事項は,メンバを削除する際の,ファイル・システム, アプリケーション・データ, 仮想ユニットに格納されているデータベースのデータ整合性に関するものでした。

しかし,この制限事項はアプリケーションの真の連続運転 (24 時間 x 7日) が必要なときには受け入れ難いため,アプリケーション・ソフトウェアとシステム管理が連携することで,適切なデータ整合性が確保できる場合は, この制限事項は不要と考えられます。

7.12.1 バックアップ用にシャドウ・セット・メンバを削除する

現在サポートされている OpenVMS のリリースでは, 以下の条件が満たされていれば,DISMOUNT を使って, データのバックアップ用にシャドウ・セットからメンバを削除することができます。

  • シャドウ・セットが マージ状態ではないこと。 シャドウ・セットのコピー操作が実行中でないという条件も満たすことをお勧めします。

  • メンバを削除した後でも十分な冗長性が維持できていること。 アクティブなシャドウ・セットのメンバを 2 つより少なくしないことをお勧めします。 言い換えると,シャドウ・セットではコントローラのミラーリングや RAID 5 を採用することをお勧めします。

メンバを削除するには,以下の手順に従ってください。

  1. システム管理手順またはアプリケーション・ソフトウェアあるいはその両方で, 仮想ユニット全体でのデータ整合性を確立します。このトピックは複雑なので, この章の残りの大部分ではこのトピックについて説明します。

  2. マージ状態と冗長性の要件が満たされていることを確認します。

  3. 仮想ユニットから,バックアップするメンバを削除します。

  4. ステップ 1 で行ったデータ整合性の処置を停止します。

7.12.2 データ整合性の要件

シャドウ・セット・メンバを削除すると, いわゆる クラッシュ対応コピー ができます。 つまり,削除されたメンバに格納されているデータのコピーは, その時点でシステム障害が発生した場合と同レベルの整合性を持ったものです。 クラッシュ対応コピーからの復旧は,アプリケーションの設計, システムとデータベースの設計,そして操作手順によって保証されます。 復旧を保証する手順は,アプリケーションとシステムの設計に依存するため, サイトごとに異なります。

システム障害が発生したときの状態は,データが書き込まれていない, データを書き込もうとしたがディスクに書き込まれていない,というものから, すべてのデータが書き込まれたというものまで多岐にわたります。 以下の項では,障害が発生したときに処理中の書き込みがあった (すなわち,書き込もうとしたがディスクに書き込まれていない) 場合に, 関係するオペレーティング・システムの要素と動作を説明しています。 使っている環境でデータ整合性を確保する手順を確立する場合に, これらの問題を考慮してください。

7.12.3 アプリケーションの動作

データ整合性を達成するためには,アプリケーションの動作が停止され, すべての操作が停止している必要があります。操作が進行していると, バックアップされたアプリケーション・データとの不整合がおきます。 多くの対話型アプリケーションでは,ユーザが操作しなければ, 動作が停止する傾向がありますが,アプリケーションの動作を確実に停止するには, アプリケーション自身に意識させる必要があります。 ジャーナリングやトランザクションの技法が, 進行中の不整合の問題解決に使えますが,使うためには細心の注意が必要です。 また,アプリケーションの他に,バックアップ・データに影響を与える可能性のある, システムの対話型操作も,停止する必要があります。

7.12.4 RMS への配慮

RMS ファイル・アクセスを使っているアプリケーションでは, 以下の問題を認識しておく必要があります。

7.12.4.1 キャッシングと遅延書き込み

アプリケーションのオプションによっては,RMS では, アップデートの完了がアプリケーションに報告された後でも, ディスクへの書き込みが遅延されることがあります。ディスク上のデータは, RMS バッファ・キャッシュに対するその他の要求に対応したり, 共有ファイル環境では協調プロセスが同じデータまたは近くのデータを参照することによって,アップデートされます。

順編成ファイルへの書き込みは,常にメモリにバッファされ, バッファが満杯になるまでディスクへ書き込まれません。

7.12.4.2 エンド・オブ・ファイル (EOF)

順編成ファイル の EOF ポインタは, 通常,ファイルがクローズされたときのみアップデートされます。

7.12.4.3 インデックスのアップデート

索引編成ファイルで 1 つのレコードをアップデートすると, 複数のインデックスのアップデートが必要になることがあります。 これらのアップデートは,アプリケーションのオプションによっては キャッシュされることがあります。インデックスのアップデートが 不完全なときにシャドウ・セットを分割すると, インデックスとデータ・レコードの間に,不整合が生ずることがあります。 遅延書き込みが無効になっていれば,RMS は不完全なインデックス・アップデートで, アップデートが失われることはあっても, インデックスが壊れることがないような順序で書き込みを処理します。 しかし,遅延書き込みが有効になっていると, インデックス・アップデートを書き込む順番が予測不可能になります。

7.12.4.4 実行時ライブラリ

種々の言語の入出力ライブラリでは,RMS の種々のバッファリングと遅延書き込みのオプションを使っています。言語によっては, アプリケーションが RMS のオプションを制御できるものがあります。

7.12.4.5 $FLUSH

アプリケーションでは,データ整合性を確保するために,$FLUSH サービスを使うことができます。 $FLUSH サービスは,アプリケーションで完了したすべてのアップデート (順編成ファイルの EOF も含む) が, ディスクに記録されたことを保証します。

7.12.4.6 ジャーナリングとトランザクション

RMS には,ロール・フォワード,ロール・バック, およびリカバリ・ユニット・ジャーナルのオプション機能があり, OpenVMS トランザクション・サービスを使ったトランザクション回復機能もサポートしています。これらの機能を使って, 削除されたシャドウ・セット・メンバから,進行中だったアップデートを取り消すことができます。このような技法を使うためには, データやアプリケーションを注意深く設計する必要があります。 ベース・データ・ファイルとともに, ジャーナルを含む仮想ユニットのバックアップを取ることが重要です。

7.12.5 マップされたファイル

OpenVMS では,プロセスおよびグローバル・セクション・サービスを通じて, 仮想メモリのバッキング・ストアとしてのファイルをアクセスすることができます。 このモードのアクセスでは, プロセスの仮想アドレス空間はファイル・データのキャッシュの働きをします。 OpenVMS では,バッキング・ファイルを強制的にアップデートするための $UPDSEC サービスを用意しています。

7.12.6 データベース・システム

Oracle® のようなデータベース管理システムは,ジャーナリングやトランザクションによる回復機能が組み込まれているので,シャドウ・セットの分割によるバックアップに適しています。 シャドウ・セット・メンバをディスマウントする前に, 次の形式の SQL コマンドを使って, Oracle データベースを " バックアップ・モード " にする必要があります。

ALTER TABLESPACE tablespace-name BEGIN BACKUP;

このコマンドによって, テーブルスペースの各々のコンポーネント・ファイルの回復ポイントが設定されます。 回復ポイントは,データベースのバックアップ・コピーによって, 後で整合状態に回復できることを保証します。 バックアップ・モードは,次の形式のコマンドを使って終了させます。

ALTER TABLESPACE tablespace-name END BACKUP;

データベース・データ・ファイルと同時に, データベース・ログと制御ファイルもバックアップすることが重要です。

7.12.7 ベース・ファイル・システム

基本的な OpenVMS ファイル・システムは,空きスペースをキャッシュします。 ただし,すべてのファイル・メタデータ操作 (たとえば,作成や削除) は, 「注意深いライト・スルー」方式で実行されるため,結果は, アプリケーションに完了が報告される前に,ディスク上で確定しています。 空きスペースの一部は失われる可能性がありますが, 通常のディスク再構築で回復できます。 シャドウ・セット・メンバをディスマウントするときにファイル操作が進行中だった場合は,ちょっとした不整合が起きることがありますが, これらは ANALYZE/DISK で修復できます。 注意深く書き込みの順番を守れば, ディスクを修復する以前に, データの不整合でディスクの完全性が危うくなることはありません。

7.12.8 $QIO ファイル・アクセスと VIOC

OpenVMS は,ファイル・データをキャッシュするために,仮想入出力キャッシュ (VIOC) を使用しています。 ただし,このキャッシュはライト・スルーです。OpenVMS バージョン 7.3 では, 拡張ファイル・キャッシュ (XFC) が導入されましたが, これもライト・スルーです。

$QIO サービスを使ったファイル書き込みでは,呼び出したプログラムに完了が通知される前にディスクへの書き込みが完了しています。

7.12.9 マルチ・シャドウ・セット

マルチ・シャドウ・セットの場合,バックアップのためにシャドウ・セットを分割するのは,大仕事です。 シングル・シャドウ・セットのメンバを削除するのは簡単ですが,マルチ・シャドウ・セットから複数のメンバを同時に削除する手段はありません。 整合性を維持してバックアップする必要があるデータがマルチ・シャドウ・セットにまたがっている場合, すべてのシャドウ・セット・メンバをディスマウントする間, アプリケーションの動作は停止している必要があります。 そうしないと,データがマルチ・ボリュームでクラッシュ対応でなくなります。 関連するシャドウ・セットのディスマウントを高速化するために, コマンド・プロシージャその他の自動化技法を使うことをお勧めします。 マルチ・シャドウ・セットに Oracle データベースが格納されている場合は, データベースの回復性を確保するために, Oracle データベースをバックアップ・モードにしておいてください。

7.12.10 ホスト・ベースの RAID

OpenVMS のソフトウェアの RAID ドライバは,マルチ・シャドウ・セットの特別な場合です。 ソフトウェア RAID セットは,それぞれのシャドウ・セットが複数のメンバで構成されるマルチ・シャドウ・セットで構成できます。 ソフトウェア RAID ドライバの管理機能によって, 構成要素のそれぞれのシャドウ・セットから,不可分な操作でメンバを 1 つディスマウントできます。 RAID ソフトウェアのもとで使われるシャドウ・セットの管理は,整合性を確保するために, 常に RAID 管理コマンドを使って行う必要があります。

7.12.11 OpenVMS Cluster 操作

データ整合性を維持するためのすべての管理操作は, 関連するアプリケーションを実行している OpenVMS Cluster システムのすべてのメンバで実行する必要があります。

7.12.12 テスト

テストだけでは,バックアップ手順の正しさは保証されません。 ただし,テストは,バックアップと回復の手順を設計する上で重要な要素です。

7.12.13 データの復元

データの復元方法を深く考えることをしないで,バックアップ手順だけを検討する場合があります。 しかし,すべてのバックアップ戦略の究極の目的は, 障害時のデータ復元です。復元や回復の手順はバックアップ手順同様, 注意深く設計しテストする必要があります。

7.12.14 データ整合性を確保する手順の再評価

この節の説明は OpenVMS バージョン 7.3 (およびそれ以降) の機能と動作に基づいていますが,それより前のバージョンにも当てはまります。 OpenVMS の将来のバージョンでは, データ整合性を確保するために必要な手順に影響を与えるような機能が追加されたり, 仕様変更が行われる可能性があります。 OpenVMS の将来のバージョンにアップグレードするサイトでは, バックアップ後も整合性が確保されるように, 手順を再評価し,OpenVMS の変更や非標準の設定に備える必要があります。

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