| 前へ | 次へ | 目次 | 索引 |
ボリューム・シャドウイングは，4 つの基本機能を実行します。どのディスク入出力サブシステムでも同じですが，最も重要な 2 つの機能は，読み込み書き込みの要求を満たすことです。残りの 2 つの機能は，コピーとマージであり，これらの機能はシャドウ・セットの管理に必要です。
コピー操作とマージ操作は，データの高可用性を実現するための基盤です。ある種の状況のもとでは，Volume Shadowing for OpenVMS は，すべてのシャドウ・セット・メンバの対応する LBN が同じ情報を持つことを保証するために，コピー操作やマージ操作を行う必要があります。ボリューム・シャドウイングではこれらの操作は自動的に実行されますが，この章ではこれらの操作の概要を説明します。
コピー操作とマージ操作は，アプリケーションやユーザ・プロセスがアクティブなシャドウ・セット・メンバに対して読み書きを実行している最中に行われます。このため，現在のアプリケーションの処理には最小の影響しか与えません。
6.1 シャドウ・セットの整合性
シャドウ・セットの存続期間に，あるシャドウ・セット・メンバと他のシャドウ・セット・メンバとの関係が，変化することがあります。シャドウ・セットは，すべてのメンバが同じデータを持っていると考えられるときは，安定状態だと見なされます。シャドウ・セットの構成が変化するのは，以下の理由で避けられません。
たとえば，オペレータがシャドウ・セットのメンバをディスマウントし，シャドウ・セットにそのメンバ・ディスクをマウントし直す場合を考えます。メンバが欠けている間に，シャドウ・セットの残りのメンバに，書き込み操作が行われたかもしれません。したがって，シャドウ・セットにマウントし直すメンバの中の情報は，シャドウ・セットの残りのメンバとは異なっている可能性があります。このような場合に，コピー操作 ( あるいは，ミニコピー操作 ) が必要になります。
別の例として，OpenVMS Cluster 構成のいくつかのシステムにシャドウ・セットがマウントされている状況を考えます。システムの 1 つが障害を起こすと，シャドウ・セットのメンバのデータは，障害を起こしたシステムが実行していた未完了の書き込み操作のために，不一致が発生しているかもしれません。シャドウイング・ソフトウェアは，マージ操作を実行してこの状況を解消します。
ボリューム・シャドウイングでは，どのような状況でも，コピー操作やマージ操作によって，シャドウ・セットに書き込まれたデータの整合性が保証されます。シャドウ・セットは，いくつかのメンバでコピー操作やマージ操作が行われているときは，遷移状態 であると見なされます。
また，ボリューム・シャドウイングでは，以下の方法によってもシャドウ・セットの整合性を維持します。
ボリューム・シャドウイングでは，シャドウ・セットの整合性を維持するために，2 つの内部メカニズムを使います。
ボリューム・シャドウイングは，シャドウ・セットのメンバ構成を制御するために， SCB を主なメカニズムとして使います。各々の物理ディスクには，シャドウイング・ソフトウェアが現在のシャドウ・セットのすべてのメンバの名前を記録している SCB があります。シャドウ・セットの構成が変化するたびに，すべてのメンバの SCB はアップデートされます。この機能によってクラスタ単位でのメンバ構成の同期が単純化しますが，この機能はシャドウ・セットを再構築する MOUNT の /INCLUDE 修飾子でも使われています。
ボリューム・シャドウイングは，シャドウ・セット・メンバの正当性とステータスを調べるために，シャドウ・セット世代番号を主なメカニズムとして使います。シャドウ・セット世代番号は，シャドウ・セットの各々のメンバに格納されているカウントアップされる値です。シャドウ・セットでメンバ構成の変更 ( メンバのマウント，ディスマウント，故障 ) が発生するたびに，残っているメンバの世代番号がカウントアップされます。たとえば，シャドウ・セットの世代番号が 100 のときに，あるメンバがセットからディスマウントされると，残りのメンバの世代番号は 101 にカウントアップされます。削除されたメンバの世代番号は，100 のままです。シャドウ・セットをマウントすると，シャドウイング・ソフトウェアは，物理ユニットの SCB に格納されている世代番号を調べ，コピー操作の必要性とコピー方向を判断します。
表 6-1 は，SCB に含まれる情報の一部です。
| SCB 情報 | 機能 |
|---|---|
| ボリューム・ラベル | ボリュームを一意に識別するための名前です。 1 つのシャドウ・セットでは，どのメンバも同じボリューム・ラベルを持つ必要があります。 |
| BACKUP リビジョン番号 | BACKUP/IMAGE による復旧では，ボリューム上でのデータの位置が再調整されるので，この変化を記録するためにリビジョン番号を設定します。マウント・ユーティリティ (MOUNT) は，要求されたシャドウ・セット・メンバのリビジョン番号を，現在のメンバまたは別に要求されたシャドウ・セット・メンバのリビジョン番号と比べます。リビジョン番号が違っている場合，シャドウイング・ソフトウェアは古いメンバのデータを最新にするために，コピー操作やマージ操作が必要かどうかを判断します。 |
| ボリューム・シャドウイング世代番号 | メンバがシャドウ・セットに加わったときに，ボリューム・シャドウイング世代番号がマークされます。MOUNT コマンドの /OVERRIDE=SHADOW_MEMBERSHIP 修飾子によって，この世代番号を 0 にすることができます。 |
| マウントとディスマウントのステータス | SCB のマウント・ステータス・フィールドは，そのボリュームがマウントされたときに設定され，ディスマウントされたときに設定解除されるフラグとして使われます。シャドウ・セットを書き込み可能でマウントしているノードの数のカウントもあります。MOUNT コマンドはボリュームをマウントするときにこのフィールドを調べます。フラグが設定されている場合，このディスク・ボリュームが正しくディスマウントされていないことを意味します。これはシステム障害の場合に発生します。正しくディスマウントされていないシャドウ・セットをマウントするとき，または書き込みカウント・フィールドが正しくない場合，シャドウイング・ソフトウェアは自動的にマージ操作を開始します。 |
ボリューム・シャドウイング・ソフトウェアは，シャドウ・セットをマウントするコマンドを受け取ると，即座にコピー操作やマージ操作が必要かどうかを判断します。いずれかが必要な場合，このソフトウェアはデータの不一致を無くすために操作を実行します。どちらのディスクがコピー操作のターゲットになるか不明の場合は， MOUNT コマンドを使うときに，/CONFIRM または /NOCOPY の修飾子を指定します。すべてのコピー操作を禁止する場合は，/NOCOPY 修飾子を使います。シャドウ・セットを対話型でマウントするときは， /CONFIRM 修飾子を指定して MOUNT がコピー操作のターゲットを表示し，操作を開始する前に許可を得るようにします。
シャドウ・セット・メンバを個別にディスマウントする際，ハード・ディスク障害のときと似た状況になります。仮想ユニット上のファイルがオープンされたままなので，削除された物理ユニットは 不正に ディスマウントされたとマークされます。
シャドウ・セットから 1 つのデバイスを削除すると，残りのシャドウ・セット・メンバの世代番号がカウントアップされ，以前のシャドウ・セット・メンバより新しくなったことがわかるようにされます。この世代番号によって，メンバをシャドウ・セットに再びマウントするときに，正しいコピー操作が行えるようになります。
6.2 コピー操作
コピー操作の目的は，ソース・ディスクのデータをターゲット・ディスクに複製することです。コピー操作が終われば，両方のディスクの内容は同じになり，ターゲット・ディスクもシャドウ・セットの完全なメンバになります。シャドウ・セットに対する読み込み書き込みのアクセスは，ディスクのコピー操作が行われている間も中断されません。
DCL コマンドの MOUNT は，ディスクが既存のシャドウ・セットにマウントされる際に，コピー操作を開始します。コピー操作は本質的には単純です。ソース・ディスクから読み込みが行われ，データがターゲット・ディスクに書き込まれるだけです。この操作は通常，LBN レンジと呼ばれる複数ブロックの単位で実行されます。OpenVMS Cluster 環境では，シャドウ・セットをマウントしているすべてのシステムは，ターゲット・ディスクを認識しており，それをシャドウ・セットの一部として持っています。ただし，実際にはただ 1 つの OpenVMS システムだけが，コピー操作を管理しています。
コピー操作には，次の 2 つの複雑な問題があります。
Volume Shadowing for OpenVMS では，オペレーティング・システムのバージョン番号やハードウェア構成に従ってこれらの状況を処理します。 OpenVMS バージョン 5.5-2 より前のソフトウェアを実行しているシステムでは，コピー操作は OpenVMS ノードで 補助無し コピー操作として実行されます ( 第 6.2.1 項 参照 )。
バージョン 5.5-2 以降では，新しいコピー機能が実装されたコントローラ上に構成されたシャドウ・セット・メンバへのコピー操作が機能強化されています。この機能強化によって，コントローラ がコピー操作を実行できるようになりました。この操作は，補助付き コピーと呼ばれます ( 第 6.2.2 項 参照 )。
Volume Shadowing for OpenVMS は，同じクラスタで，補助付きシャドウ・セットと補助無しシャドウ・セットの両方をサポートします。シャドウ・セットを作成したり，既存のシャドウ・セットにメンバを追加したり，システムをブートするときは，いつでもシャドウイング・ソフトウェアが，変化した構成に含まれるデバイスを調べ，デバイスが補助付きコピーをサポート可能かどうかを判断します。
6.2.1 補助無しコピー操作
補助無しコピー操作は，OpenVMS システムによって実行されます。ソース・メンバからターゲットへの実際のデータ転送は，ホスト・ノードのメモリを経由して行われます。補助無しコピー操作は CPU をそれほど使用しませんが，入出力を多用し，コピーを管理しているノードの CPU リソースを少し消費します。補助無しコピー操作は，インターコネクトの転送能力も消費します。
コピー操作を管理するシステムでは，ユーザとコピー入出力処理が，利用可能な入出力転送能力を平等に取り合います。クラスタ内の別のノードでは，ユーザの入出力処理が通常どおりに実行され，他のすべてのノードとの間でコントローラのリソースを取り合います。コピー操作はユーザの入出力処理の負荷が増えるにつれ，時間がかかるようになることに注意してください。
ボリューム・シャドウイング・ソフトウェアは，補助付きコピー操作機能 ( 第 6.2.2 項 参照 ) を使うことができない場合，補助無しコピー操作を実行します。補助無しコピー操作になる場合の多くの理由は，ソース・ディスクとターゲット・ディスクが同じコントローラ・サブシステムに接続されていないことです。補助無しコピー操作では，2 つのメンバを 1 つコマンド行で指定してシャドウ・セットに追加した場合，2 つのディスクを同時に補助無しコピー操作のターゲットにすることができます。補助無しコピー操作の対象となるディスクは，クラスタ内のどのコントローラに接続されていてもかまいません。
コピー操作の際には，ディスク全体を移動する，コピー済み LBN レンジと未コピーの LBN 領域を区切る論理的な垣根が作成されます。この垣根を コピー・フェンス と呼びます。コピー操作を管理しているノードはコピー・フェンスの正確な位置を認識しており，クラスタ内の別のノードに定期的にコピー・フェンスの位置を通知します。それにより，コピー操作を実行しているノードがシャットダウンしても，他のノードが，コピー操作を最初からやり直すのではなく途中から引き継ぐことができます。
コピー・フェンスのどちら側でも，読み込み入出力要求は，ソース・シャドウ・セット・メンバだけからサービスされます。
コピー・フェンスの位置とそれより前への書き込み要求は，シャドウ・セットのすべてのメンバに並列に発行されます。
コピー・フェンスより後への書き込み要求は，まずソース・メンバに対して実行され，その後，コピー・ターゲットのメンバに実行されます。
補助無しコピー操作を完了するために必要な入出力処理の時間と量は，ソース・ディスクとターゲット・ディスクのデータがどれだけ似ているかに大きく依存します。データが類似していないメンバをコピーする場合は，データが類似しているメンバをコピーする場合と比べて，少なくとも 2.5 倍の時間がかかります。
6.2.2 補助付きコピー操作
補助付きコピー操作は，補助無しコピー操作とは異なり，ホスト・ノードのメモリを経由するデータ転送は行いません。実際のデータ転送はコントローラ内で，直接，ディスク間のデータ転送として行われ，データがホスト・ノードのメモリを通過することはありません。したがって，補助付きコピー操作では，システムへのインパクト，入出力転送能力の消費，コピー操作に要する時間が少なくなります。
補助付きコピー操作の利点を得るためには，シャドウ・セット・メンバは同じコントローラからアクセスできる必要があります。シャドウイング・ソフトウェアは，DCD (ディスク・コピー・データ) コマンドという特別な MSCP コピー・コマンドを使って，コントローラに特定の LBN レンジをコピーすることを指示することで，コピー操作を制御します。補助付きコピーの場合，コピーのアクティブ・ターゲットになるのは，一時期に 1 つのディスクだけです。
OpenVMS Cluster 構成では，コピー操作を管理しているノードが， LBN レンジごとに，コントローラに MSCP DCD コマンドを発行します。そうするとコントローラがディスク間コピーを実行するので，インターコネクトの転送能力を消費することはありません。
デフォルトでは，Volume Shadowing for OpenVMS ソフトウェア (OpenVMS バージョン 5.5-2 以降 ) とコントローラは，ソース・ディスクとターゲット・ディスクが同じ HSC または HSJ のコントローラを通してアクセスできる場合，自動的に補助付きコピーを有効にします。
以下の場合には，シャドウイングは補助付きコピーを自動的に無効にします。
デュアル・ポート・ディスクの場合，両方のディスクを同じコントローラを通してアクセスできるようにするため，$QIO SET PREFERRED PATH 機能を使います。優先パスの設定についての詳細は，SYS$EXAMPLES の PREFER プログラムと，『OpenVMS I/O User's Reference Manual』を参照してください。
補助付きコピー機能を無効にしたり，再び有効にする方法については， 第 6.4 節 を参照してください。
6.3 マージ操作
マージ操作の目的は，シャドウ・セット・メンバのデータを比較し，不整合を無くすことです。マージ操作が開始されるのは，以下の状況のいずれかが発生したときです。
たとえば，書き込み要求がシャドウ・セットに対して行われ，すべてのシャドウ・セット・メンバから完了ステータスが返される前に，システム障害が発生したような状況では，以下の可能性があります。
オリジナルの書き込み要求の処理中に障害が発生したタイミングによって，これらの 3 つのシナリオのいずれかになります。ただし，システムが復旧した後は，各々のシャドウ・セット・メンバの対応する LBN には ( 古いまたは新しい ) 同じ データがあります。したがって，ここでの問題はデータ可用性ではなく，シャドウ・セット・メンバ間で起こりうる不一致を無くすことです。 すべての ディスクのデータが同じになれば，必要に応じて，ユーザがデータを再投入するか，データベース復旧，アプリケーション・ジャーナリング技法などによって，アプリケーション・データの不一致を無くすことができます。
たとえば，シャドウ・セットが 8 ノードにマウントされていて，そのうち 2 つでマウント検査がタイムアウトになると，これらの 2 つのノードでは，シャドウ・セットのマージ操作が必要になります。
マージ操作は，シャドウ・セットをマウントしている OpenVMS システムの 1 つで管理されます。シャドウ・セットのメンバは，同じデータを持っているか確認するために，互いに物理的に比較されます。これはボリューム全体にわたるブロックごとの比較で行われます。マージが進むにつれ，内容が異なるブロックはコピー操作によって ( 古いまたは新しいデータで ) 同じ内容にされます。シャドウイング・ソフトウェアには，どのメンバが新しいデータを持っているかわからないので，完全なメンバであればどれでもマージ操作の ソース・メンバになります。
シャドウイング・ソフトウェアは，常に 1 つのメンバを (OpenVMS Cluster にまたがる ) マージ操作の 論理マスタ として選択します。データの違いは，マージ・マスタから すべての ほかのメンバへ情報を伝えることで解消されます。
あるシャドウ・セットでマージ操作に責任を持つシステムは，LBN レンジの整合を取った後，このシャドウ・セットの マージ・フェンス をアップデートします。このフェンスはディスク全体にわたって「移動」し，シャドウ・セットのマージが終わった部分と終わっていない部分を区切ります。
フェンスのマージ済みの側へのアプリケーションからの読み込み入出力要求は，シャドウ・セットのどのソース・メンバによっても対応が行えます。フェンスの未マージの側へのアプリケーションからの読み込み入出力要求も，シャドウ・セットのどのソース・メンバによっても対応が行えますが，データが異なっている ( データを比較して検出される ) 場合は，要求したユーザまたはアプリケーションにデータが返される 前に，シャドウ・セットのすべてのメンバで訂正されます。
このように読み込み要求のときにデータの非整合を動的に訂正する方式によって，マージ操作のどの時点でシャドウ・セット・メンバが障害を起こしても，データ可用性に影響を与えないようになっています。
Volume Shadowing for OpenVMS は，同じクラスタ内で補助付きマージ操作と補助無しマージ操作の両方をサポートします。シャドウ・セットの作成，既存シャドウ・セットへのメンバの追加，またはシステムのブートのとき，シャドウイング・ソフトウェアは，変更された構成の各々のデバイスがマージ補助機能をサポートしているかどうかを調べます。
6.3.1 補助無しマージ操作
OpenVMS バージョン 5.5-2 より前のソフトウェアを実行しているシステムでは，マージ操作はシステムによって行われます。これは，補助無し マージ操作と呼ばれます。
ユーザの入出力要求へ与える影響を最小にするために，ボリューム・シャドウイングでは，ユーザやアプリケーションの入出力要求がマージ操作より優先されるようなメカニズムを採用しています。
シャドウ・サーバ・プロセスはマージ操作をバックグラウンド・プロセスとして実行し，障害が発生した場合のユーザ入出力処理への影響を少なくしています。このため，ユーザの入出力要求が多い場合は，補助無しマージ操作は完了までの時間が長くなります。また，マージ操作が完了する前に別のノードで障害が発生すると，進行中のマージは中断され，新しいマージが最初から行われます。
このような遅れがありますが，マージ操作中のデータ可用性と整合性は完全に保たれることに注意してください。すべてのシャドウ・セット・メンバは同程度に正しいデータを保持しています。
6.3.2 補助付きマージ操作
OpenVMS バージョン 5.5-2 から，補助付き マージ機能を備えたコントローラ上に構成されたシャドウ・セット・メンバでのマージ操作が機能強化されています。補助付きマージ操作は， ミニマージ とも呼ばれます。ミニマージ機能は，マージ操作に必要な時間を著しく短縮します。通常，ミニマージは数分で完了します。
HSC コントローラと HSJ コントローラはミニマージをサポートします。 HSG コントローラでのミニマージのサポートは計画中です。
ミニマージは，コントローラのメモリに記録されている書き込み操作の情報を使うことで，シャドウ・セットで書き込み動作が実際に行われていた領域だけを，マージします。これにより，補助無しマージでは必要になる全体の読み込みと比較スキャンが不要になり，システムの入出力リソースの消費が減少します。
コントローラ・ベースの書き込みログには，シャドウ・セットのどの LBN に ( 故障したノードからの ) 未完了の書き込み入出力要求があるかについて，正確な情報が記録されています。補助付きマージ操作を実行するノードは，シャドウ・セットの中で整合が取れていない可能性のある LBN をマージするために，この書き込みログを使います。1 メンバのシャドウ・セットでは，コントローラ・ベースの書き込みログは行われません。 1 つの OpenVMS システムでシャドウ・セットをマウントしているだけなら，コントローラ・ベースの書き込みログは行われません。
シャドウイング・ソフトウェアはシステム・ディスクでのミニマージを自動的に有効にすることはありません。これは，クラッシュ・ダンプ・ファイルを非システム・ディスク上に統合する必要があるからです。 DOSD( ダンプを行わないシステム・ディスク ) は， OpenVMS VAX と OpenVMS Alpha で，OpenVMS VAX バージョン 6.2 と OpenVMS Alpha バージョン 7.1 からサポートされています。 DOSD が有効になっていると，システム・ディスクでもミニマージが行えます。 |
ミニマージ操作は，OpenVMS バージョン5.5-2 以降が稼働しているノードで使えます。ボリューム・シャドウイングは，シャドウ・セットの物理メンバへのアクセスを行うコントローラがミニマージをサポートしていれば，自動的にミニマージを有効にします。サポートしているコントローラのリストについては，『Volume Shadowing for OpenVMS Software Product Description (SPD 27.29.xx)』を参照してください。ミニマージ操作はシャドウ・セット・メンバが異なるコントローラに接続されていても行えることに注意してください。これは，書き込みログのエントリが，コントローラ単位でシャドウ・セット・メンバごとに管理されているからです。
Volume Shadowing for OpenVMS は，以下の状況で，自動的にミニマージを無効にします。
以下の遷移状態の場合も，ミニマージ操作が無効になります。
使用できる書き込みログ・エントリの数は，コントローラの能力によって決まります。シャドウイング・ソフトウェアは，書き込み入出力情報をうまく管理するために十分なエントリがあるかどうかを，動的に判断します。使用できる書き込みログ・エントリの数が少なすぎるときは，シャドウイング機能は一時的にそのシャドウ・セットのログ機能を無効にし，そのノードとクラスタ内のすべてのノードの既存の使用可能なエントリを返します。一定の時間が経過した後，シャドウイング機能はこのシャドウ・セットについて書き込みログを再度有効にします。
コントローラは，各々の書き込み入出力要求に対する書き込みログ・エントリを，エントリがシャドウイング機能によって削除されるか，コントローラが再起動されるまで，保持しています。
複数ユニットのコントローラは，複数のディスクで書き込みログ・エントリを共有します。書き込みログ・エントリのプールはシャドウイング・ソフトウェアが管理します。コントローラが書き込みログ・エントリを使い切った場合，シャドウイング機能はミニマージを無効にし，補助無しマージ操作を実行します。シャドウ・セットをディスマウントしないでノードがクラスタから離れた可能性があります。書き込みログを使い切ることは，書き込みログを共有しないディスクでは通常起きないことに注意してください。
この節では，HSC コントローラで補助付きコピーとミニマージの操作を制御する方法を説明します。HSJ コントローラではこれらの操作を制御することはできません。
HSC コントローラのマージとコピーの性能補助機能を無効にするには，補助機能を無効にしたい各々の HSC コントローラで，以下の手順を実行します。
HSC> RUN SETSHO SETSHO> SET SERVER DISK/NOHOST_BASED_SHADOWING SETSHO-I Your settings require an IMMEDIATE reboot on exit. SETSHO> EXIT SETSHO-Q Rebooting HSC. Press RETURN to continue, CTRL/Y to abort: |
これらのコマンドを入力し終わると，HSC コントローラは自動的にリブートします。
INIPIO-I Booting...
|
補助機能を再び有効にするには，HSC コントローラで同様の手順を実行しますが， SET SERVER DISK コマンドには，/HOST_BASED_SHADOWING 修飾子を指定します。
補助機能が有効か無効かを調べるには，HSC コマンドの SHOW ALL を使います。以下の例は，シャドウイング補助ステータスを示す，SHOW ALL 表示の一部です。
HSC> SHOW ALL
.
.
.
5-Jun-1997 16:42:51.40 Boot: 21-Feb-1997 13:07:19.47 Up: 2490:26
Version: V860 System ID: %X000011708247 Name: HSJNOT
Front Panel: Secure HSC Type: HSC90
.
.
.
Disk Server Options:
Disk Caching: Disabled
Host Based Shadowing Assists: Enabled
Variant Protocol: Enabled
Disk Drive Controller Timeout: 2 seconds
Maximum Sectors per Track: 74 sectors
Disk Copy Data connection limit: 4 Active: 0
.
.
.
|
6.5 システムで障害が発生したときのシャドウ・セットの状態
システム，コントローラ，あるいはディスクに障害が発生した場合，シャドウイング・ソフトウェアは，適切なコピー，マージ，あるいはミニマージの操作を行ってデータ可用性を維持します。以下の節では，障害が発生したときに実行される一連の動作を説明します。この動作は，障害の種類と，シャドウ・セットが安定状態にあったか遷移状態にあったかによって異なります。
遷移が完了すると，ディスクは同じ情報を持つようになり，シャドウ・セットは安定状態に戻ります。
以下のリストは，コピーおよびミニコピー操作が行われているシャドウ・セットに起きる遷移を説明しています。特に明記されない限り，遷移は両方のコピー操作に適用されます。
ミニコピー操作を実行中のシャドウ・セットで仮想ユニットがディスマウントされた場合には，ミニコピーは継続されません。代わりに，ミニコピーが停止したポイントからフル・コピーが継続され，残りのすべてのブロックがコピーされます。
シャドウ・セットのコピー操作の最中にノード障害が発生すると，マージの動作は，シャドウイング性能補助機能が有効か無効かで異なります。
シャドウ・セットがミニマージの操作中だった場合，以下の遷移がおきます。
以下のリストでは，性能補助機能が使えない場合に，マージ操作を実行しているシャドウ・セットにおきる遷移を説明しています。
例 6-1 は，シャドウ・セットのメンバではなかった 2 つのディスク・ボリュームをマウントしてシャドウ・セットを作成したときに，何が起きるかを示しています。いずれのディスク・ボリュームもシャドウ・セットに属していなかったので，マウント・ユーティリティ (MOUNT) は，MOUNT コマンドに指定された最初のディスクがソース・メンバであると見なします。マウント・ユーティリティがディスクのボリューム・ラベルをチェックしたとき，それらのディスクが互いに異なっていることを検出し，このユーティリティは自動的にコピー操作を実行します。
この例で，DSA0 は仮想ユニット名，$1$DUA8 と $1$DUA89 はディスク・ボリューム名，そして SHADOWDISK はボリューム・ラベルです。
| 例 6-1 新しいシャドウ・セットを作成する際のコピー操作 |
|---|
$ MOUNT DSA0: /SHADOW=($1$DUA8:,$1$DUA89:) SHADOWDISK
%MOUNT-I-MOUNTED, SHADOWDISK mounted on _DSA0:
%MOUNT-I-SHDWMEMSUCC, _$1$DUA8: (FUSS) is now a valid member
of the shadow set
%MOUNT-I-SHDWMEMCOPY, _$1$DUA89: (FUSS) added to the shadow
set with a copy operation
$ SHOW DEVICE DSA0:
Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA0: Mounted 0 SHADOWDISK 890937 1 1
$1$DUA8: (FUSS) ShadowSetMember 0 (member of DSA0:)
$1$DUA89: (FUSS) ShadowCopying 0 (copy trgt DSA0: 1% copied)
|
例 6-1 の SHOW DEVICE の表示は，コピー操作中 ( 遷移状態 ) のシャドウ・セットを示しています。 $1$DUA8 と $1$DUA89 の SCB 情報は，これらのデバイスがシャドウ・セットに属していなかったことを示しているので，シャドウイング・ソフトウェアはコマンド行に指定された最初のデバイス ($1$DUA8) をコピー操作のソースとして使います。デバイス・ステータスの「ShadowSetMember」は，$1$DUA8 デバイスがソース・シャドウ・セット・メンバであることを示し，「ShadowCopying」は物理デバイス $11$DUA89 がコピー操作のターゲットであることを示しています。
新しいメンバを既存のシャドウ・セットにマウントするときに，その追加するデバイスが以前は同じシャドウ・セットのメンバであった場合を考えます。この場合は，新しいメンバのボリューム・ラベルは，現在のシャドウ・セット・メンバのボリューム・ラベルに一致していますが，新しいメンバの MOUNT 世代番号が，現在のメンバの世代番号に比べると，古くなっています。したがって，マウント・ユーティリティはこのメンバに対し，自動的にコピー操作を実行します。
例 6-2 は MOUNT コマンドの形式と， DSA9999 仮想ユニットで表わされるシャドウ・セットへ $3$DIA12 デバイスを追加するときに返される MOUNT ステータス・メッセージを示しています。 MOUNT コマンド行では現在シャドウ・セットにあるメンバ・ユニットをリストする必要がないことに注意してください。
| 例 6-2 既存のシャドウ・セットへメンバを追加する際のコピー操作 |
|---|
$ MOUNT /SYSTEM DSA9999: /SHADOW=$3$DIA12: AXP_SYS_071
%MOUNT-I-MOUNTED, AXP_SYS_071 mounted on _DSA9999:
%MOUNT-I-SHDWMEMCOPY, _$3$DIA12: (SHAD03) added to the shadow
set with a copy operation
$ SHOW DEVICE DSA9999:
Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA9999: Mounted 0 AXP_SYS_071 70610 1 1
$3$DIA7: (BGFUSS) ShadowSetMember 0 (member of DSA9999:)
$3$DIA5: (SHAD03) ShadowSetMember 0 (member of DSA9999:)
$3$DIA12: (SHAD03) ShadowCopying 0 (copy trgt DSA9999: 0% copied)
|
例 6-3 は，あるノードで 3 メンバのシャドウ・セットを解除し，その後すぐに別のノードにマウントし直すときに，何が起きるかを示しています。マウント・ユーティリティが各々のメンバのボリューム情報を調べると，ボリューム情報がシャドウ・セット内で統一されていることがわかります。したがって，シャドウ・セットをマウントする際に，コピー操作は不要です。
例 6-3 では，DSA10 が仮想ユニットで，$3$DUA10，$3$DUA11， $3$DUA12 がメンバ・ボリュームです。例の最初の部分には， SHOW DEVICE コマンドの出力が表示されていますが，これはシャドウ・セットがマウントされ，安定状態にあることを示しています。その後，ユーザは，DSA10 シャドウ・セットをディスマウントし，すぐにマウントし直しています。
| 例 6-3 シャドウ・セットの再構築でコピー操作を行わない場合 |
|---|
$ SHOW DEVICE D
Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA10: Mounted 0 VAX_SYS_071 292971 1 1
$3$DUA10: (MYNODE) ShadowSetMember 0 (member of DSA10:)
$3$DUA11: (MYNODE) ShadowSetMember 0 (member of DSA10:)
$3$DUA12: (MYNODE) ShadowSetMember 0 (member of DSA10:)
$ DISMOUNT /NOUNLOAD DSA10:
%%%%%%%%%%% OPCOM 24-MAR-1997 20:26:41.40 %%%%%%%%%%%
$3$DUA10: (MYNODE) has been removed from shadow set.
%%%%%%%%%%% OPCOM 24-MAR-1997 20:26:41.69 %%%%%%%%%%%
$3$DUA11: (MYNODE) has been removed from shadow set.
%%%%%%%%%%% OPCOM 24-MAR-1997 20:26:41.69 %%%%%%%%%%%
$3$DUA12: (MYNODE) has been removed from shadow set.
%%%%%%%%%%% OPCOM 24-MAR-1997 20:26:41.69 %%%%%%%%%%%
$ MOUNT /SYSTEM DSA10: /SHADOW=($3$DUA10:, $3$DUA11:, $3$DUA12:) VAX_SYS_071
%MOUNT-I-MOUNTED, VAX_SYS_071 mounted on _DSA10:
%MOUNT-I-SHDWMEMSUCC, _$3$DUA10: (MYNODE) is now a valid member of
the shadow set
%MOUNT-I-SHDWMEMSUCC, _$3$DUA11: (MYNODE) is now a valid member of
the shadow set
%MOUNT-I-SHDWMEMSUCC, _$3$DUA12: (MYNODE) is now a valid member of
the shadow set
$
|
例 6-4 は，マージ操作の際の SHOW DEVICE コマンドの出力を示しています。
システム障害が発生すると，ボリューム情報は各々のシャドウ・セット・メンバが正常にディスマウントされなかったことを示す状態になります。ノードをリブートした後で再び MOUNT コマンドを発行すると，シャドウイング・ソフトウェアはそのシャドウ・セットで自動的にマージ操作を実行します。
| 例 6-4 シャドウ・セットの再構築の際のマージ操作 |
|---|
$ SHOW DEVICE DSA42: Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt DSA42: Mounted 0 ATHRUZ 565997 1 1 $4$DUA2: (MYNODE) ShadowMergeMbr 0 (merging DSA42: 0% merged) $4$DUA42: (YRNODE) ShadowMergeMbr 0 (merging DSA42: 0% merged) |
| 前へ | 次へ | 目次 | 索引 |