第1章 Volume Shadowing for OpenVMS の紹介

最大 6 メンバをサポートする拡張メンバーシップ機能を使用して シャドウセットをマウントしようとするシステムでは， OpenVMS V8.4 が稼働していなければなりません。 仮想ユニットがマウントされているシステムが拡張メンバーシップに対応していない場合，3 メンバを超えてマウントしようとすると処理が失敗します。 また，拡張メンバーシップを使用している仮想ユニットを拡張メンバーシップに対応していないシステムが MOUNT コマンドで他のノードにマウントしようとすると，その操作は失敗します。 仮想ユニットにおける拡張メンバーシップの使用が一旦有効になると， たとえその後メンバ数を 3 以下に減らしても， その仮想ユニットがクラスタワイドでディスマウントされるまで その特性が維持されます。 なおこの機能は OpenVMS VAX では提供されませんが， 仮想ユニットで拡張メンバーシップが使用されているかどうかの 特性は記録されるため互換性は維持されます。 このため，Alpha あるいは Integrity サーバでこの新しい機能を使用しないで ディスクがマウントされている場合は， 仮想ユニットを OpenVMS VAX にマウントすることができます。

拡張メンバーシップ・ディスクの情報の保管には， ディスクのストレージ制御ブロック (SCB) の新しい領域が使用されます。 このため，6メンバ・シャドウセットをサポートしていない OS バージョンでの 6 メンバ・シャドウセットのマウントは， コマンド行でメンバ指定(ただし最大 3 メンバ)された場合のみ機能します。 古いバージョンで $MOUNT/INCLUDE コマンドを実行すると SCB の新しいメンバーシップ領域を見つけることができないため， 以前のどのメンバも含めることはできません。

システムが OpenVMS Alpha バージョン 7.2–2 またはバージョン 7.3 を実行しており，メンバをシャドウセットに戻すためにミニコピー操作を使う場合，システム・ディスク・シャドウセットからダンプ・ファイル (SYSDUMP.DMP) にアクセスするための追加の手順を実行する必要があります。 この項ではこの追加の手順について説明します。

なお，OpenVMS Alpha バージョン 7.3–1 からは，SDA (System Dump Analyzer) に導入された /SHADOW_MEMBER 修飾子により，この手順は不要になりました。 SDA (以下の手順 2 で使用) は，ダンプ・ファイルを解析する OpenVMS ユーティリティであり，『OpenVMS System Analysis Tools Manual』でその詳細が説明されています。

基本的なファイル・システムがクラッシュ・ダンプを書き込んだ場合， その書き込みは書き込みビットマップのデータ構造に記録されていません。 そのため，以下の手順が必要になります。

Integrity サーバのシステム・ディスクには，OpenVMS ブート・ローダ，EFI アプリケーション，ハードウェア診断ツールを含む FAT (ファイル・アロケーション・テーブル) パーティションが最大 2 つ存在します。 OpenVMS のブートストラップ・パーティションと診断パーティション (存在する場合) は，それぞれ OpenVMS システム・ディスク内の次のコンテナ・ファイルにマップされます。

SYS$LOADABLE_IMAGES:SYS$EFI.SYS

SYS$MAINTENANCE:SYS$DIAGNOSTICS.SYS

これらの FAT パーティションの内容は，コンソールの EFI Shell> プロンプトに，fsn: デバイスとして現れます。 これらの fsn: デバイスは， EFI Shell> プロンプトでのユーザ・コマンド入力，または EFI コンソール・アプリケーションや EFI 診断アプリケーションによって直接変更することができます。 システム・ディスクを共用する OpenVMS 環境または EFI コンソール環境のいずれにも，パーティションの変更は通知されません。 OpenVMS 環境と EFI コンソール環境は，これらのコンソールによる変更を全く意識しません。 そのため，OpenVMS コンソールや使用する他の任意の EFI コンソールでは，この変更に適切に連携して同期を取る必要があります。

次のどちらかまたは両方の手段で，構成内のコンソールを変更するときには注意が必要です。

このような OpenVMS システム・ディスク環境は，前もって単一メンバのホストベース・ボリューム・シャドウセット，または非シャドウ・システム・ディスクに移行し，さらに，次のような操作で fsn: デバイスをシェル・レベルで変更するときには，Shell> プロンプトへの同時アクセスを行わないようにアクセスを調整する必要があります。

上記の予防措置をとらなかった場合には，ブート・パーティションに対応する fsn デバイスでの変更や，診断パーティションに対応するデバイスでの変更は直ちに，または次回の OpenVMS のホストベース・ボリューム・シャドウイングのフルマージ操作の後に，書き換えられて失われます。

たとえば，シャドウ・システム・ディスクのいずれかの物理メンバでコンテナ・ファイルの内容が EFI コンソールのシェルによって変更されても，ボリューム・シャドウイング・ソフトウェアは物理デバイスへの書き込みがあったことは認識できません。 システム・ディスクが複数のメンバからなるシャドウセットの場合には，シャドウセット・メンバである他の物理デバイスのすべてに対して同じ変更を行う必要があります。 そうしないと，システム・ディスクで次にフルマージ操作が行われたときに，これらのファイルの内容が元に戻ってしまいます。 マージ操作は，EFI での変更が行われてから数日後，または数週間後に行われることもあります。

さらに，シャドウ・システム・ディスクでフルマージがアクティブになっている場合には，いずれのファイルもコンソールの EFI シェルを使って変更してはなりません。

進行中のフルマージ操作を停止する方法や，シャドウ・セットのメンバ構成を調べる方法については，第8章 「ホストベース・ミニマージ (HBMM)」 を参照してください。

これらの注意事項は，ホストベースのボリューム・シャドウイング用に構成されている Integrity システム・ディスク，または複数の OpenVMS Integrity システムで構成されて共用されているシステム・ディスクにのみ適用されます。コントローラ・ベースの RAID を使用している構成，システム・ディスクでホストベースのシャドウイングを使用していない構成，別の OpenVMS Integrity システムと共用していない構成では影響を受けません。

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

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

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

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

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

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

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

ミニコピーの場合，すべてのクラスタメンバがミニコピーをサポートしている必要があります。 一方 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.4.8 項 「HBMM の制限事項」に示すように，ビットマップをサポートしているバージョンの Volume Shadowing for OpenVMS が動作し，HBMM 機能を持っていないシステムは，HBMM をサポートしているシステムのクラスタのメンバになることは可能ですが，HBMM シャドウセットをマウントすることはできません。)

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

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

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