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

HP OpenVMS: Volume Shadowing for OpenVMS 説明書

第1章 Volume Shadowing for OpenVMS の紹介

≫ 

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

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

この章では,Volume Shadowing for OpenVMS を紹介し, ボリューム・シャドウイング (ディスク・ミラーリングと呼ばれることもあります) でどのようにしてデータの高可用性が達成されるかを説明します。

1.1 概要

Volume Shadowing for OpenVMS は,データを複数のディスクに複製することで, アプリケーションやエンド・ユーザに対してデータの高可用性を提供します。 同じデータが複数のディスク・ボリュームに記録されるので,1 つのディスクに障害が発生しても残りのディスクで入出力要求のサービスを継続することができます。

HP Volume Shadowing for OpenVMS は,HP OpenVMS Integrity,OpenVMS Alpha,および OpenVMS VAX 上で利用できます。

注記: 本書では,OpenVMS Integrity および OpenVMS Alpha でのボリューム・シャドウイングについて説明します。 OpenVMS VAX におけるボリューム・シャドウイングについては,以前のバージョンの 『HP Volume Shadowing for OpenVMS 説明書』を参照してください。

OpenVMS Integrity で提供するすべてのボリューム・シャドウイング機能は OpenVMS Alpha でも提供されます。

Volume Shadowing for OpenVMS では, RAID 1 (redundant arrays of independent disks) テクノロジを実装しているため, 1 台のディスク・デバイスに故障が発生してもシステムやアプリケーションの操作を中断させることはありません。 複数のディスクにデータの複製が存在するため, 媒体劣化や通信パスの故障,あるいはコントローラやデバイスの故障など, ストレージ・サブシステムの単一障害点でシステム・ダウンが発生することはありません。

OpenVMS に対してディスク・クラス・デバイスと指定されたエンティティはシャドウセット内で使用できます。

システム・ディスクを含む 1~3 台の同じサイズのディスク・ボリュームをマウントしてシャドウセットを構成することができます。

OpenVMS Alpha バージョン 7.3–2 からは,ディスク・ボリュームの物理ブロックの数が異なっていてもシャドウセットを構成できます (1.3.2 項 「サポートされるデバイス」 参照)。 シャドウセット内の各々のディスクは,シャドウセットの メンバ です。 Volume Shadowing for OpenVMSでは,シャドウセットのディスクを論理的に 1 つに結合し,仮想ユニット (図 1-1 「仮想ユニット」 を参照)と呼ばれる 1 つの仮想デバイスとして扱います。 そのため,仮想ユニットとして扱われるシャドウセット内の複数のメンバは, アプリケーションやユーザからは, 高度に可用性のある 1 つのディスクとして見えます。

本書ではディスクとデバイスという用語は同じ意味で使用され,どちらもディスク・ボリュームのことを指します。 ディスク・ボリュームは,新しいファイル構造を置くために準備されたディスクのことです。

図 1-1 仮想ユニット

仮想ユニット

図 1-2 「シャドウセットの構成要素」 では,Volume Shadowing for OpenVMS が, 仮想ユニットを通じて 3 つの別々のシャドウセット・メンバに, データを書き込む様子を示しています。

図 1-2 シャドウセットの構成要素

シャドウセットの構成要素

ボリューム・シャドウイングの別の利点は,データの修復に役立つことです。 たとえば,1 つのシャドウセット・メンバのデータが読めなくなったときには, シャドウイング・ソフトウェアによって他のシャドウセット・メンバからデータを読むことができます。正しいデータがプロセスに返される前に, 最初に読めなかったメンバに書き込みが行われます。

注意:

ボリューム・シャドウイングにより,ディスクを使うアプリケーションやシステムの双方に対し,ディスク・ボリュームの単一障害点でシステムがダウンするというハードウェア上の問題が回避されます。 ただしボリューム・シャドウイングでは,ファイルを間違って削除したり, ソフトウェアの誤動作でディスク・ファイルが壊れるといったソフトウェアに起因する障害に対する保護は行いません。 ボリューム・シャドウイングを利用しても,通常のバックアップやジャーナリングは必要です。

Volume Shadowing for OpenVMS は,ときにはフェーズ II シャドウイングとかホストベースのシャドウイングと呼ばれます。 フェーズ I シャドウイング (コントローラ・ベースのシャドウイング) は OpenVMS バージョン 6.2 から廃止されました。

アプリケーションやユーザは,非シャドウイング I/O 操作と同じコマンドや,プログラム言語の構文およびセマンティクスを使用して,シャドウセットのデータの読み書きを行います。 システム管理者は,非シャドウイング・ディスクと同じコマンドやユーティリティを使用して,シャドウセットの管理と監視を行います。 相違点は,個々のディスクに対してではなく,仮想ユニットを介してアクセスすることだけです。

1.2 ボリューム・シャドウイングの機能と操作

シャドウセットの作成と,各メンバのデータ整合性の確保のための代表的なボリューム・シャドウイング操作は,マウント,コピー,アシストコピー,ミニコピー (OpenVMS バージョン 7.3 から導入),マージ,ミニマージです。 これらの操作中も,システムは読み取り/書き込み要求を処理し続けることができるため,継続的に高い可用性が提供されます。

マージとミニマージ以外のすべてのボリューム・シャドウイング操作は, システム管理者の管理の下で行われます。 マージとミニマージは, シャドウセット・メンバのデータ整合性に影響を与えるハードウェアやソフトウェアの障害が発生したときに,ボリューム・シャドウイング・ソフトウェアによって自動的に開始されます。 ただし,4.9 項 「マージ操作とコピー操作の優先順位付け」で説明するように異なる優先順位を割り当てることにより, マージの順序を制御することができます。 また,表 3-1で説明するシステムパラメータ SHADOW_PSM_DLY および SHADOW_REC_DLY により, マージおよびコピーに作用するデフォルトの遅延時間を変更することもできます。

システム管理者は SHADOWING システム・パラメータによってボリューム・シャドウイング機能を有効にします。 システム管理者は SHADOW_MAX_COPY システム・パラメータによって, 特定のノードで並列実行されるマージ操作とコピー操作の数を制御できます。 ボリューム・シャドウイングで使われるこれらのシステム・パラメータやその他のシステム・パラメータについては, 3.3 項 「ボリューム・シャドウイングのパラメータ」3.4 項 「ビットマップ・システム・パラメータ」 で説明します。

Volume Shadowing for OpenVMS を直接起動することはできません。 その代わりに DCL コマンドの MOUNT と DISMOUNT で起動します。 MOUNT コマンドはボリューム・シャドウイング・ソフトウェアと連携してシャドウセットを作成します。 DISMOUNT コマンドはボリューム・シャドウイング・ソフトウェアと連携して, シャドウセット・メンバを削除し,シャドウセット全体を解除します。

HSJ や HSC のコントローラが構成時に存在している場合, ミニマージとアシストコピーの操作をサポートするソフトウェアが組み込まれます。 OpenVMS Alpha Version 7.3-2 および OpenVMS Integrity Version 8.2 で導入された ホストベース・ミニマージ (HBMM) は,Fibre Channel および SCSI ディスク・デバイスでミニマージ操作を可能にします。

OpenVMS は,$MOUNT,$DISMOU,$GETDVI というシステム・サービスで, シャドウセットを作成し管理するプログラミング・インタフェースも備えています。 このプログラミング・インタフェースについては 第5章 「システム・サービスによるシャドウセットの作成と管理」 で 説明します。

表 1-1 「ボリューム・シャドウイングの主な機能,対応する操作,および関連するソフトウェア」 にはボリューム・シャドウイングの主な機能と, それに対応する操作と操作に必要なソフトウェアを示します。 これらの操作の詳細は,第4章 「DCL コマンドによるシャドウセットの作成と管理」第6章 「シャドウセットの整合性の保証」第7章 「ミニコピーによるデータのバックアップ (Integrity および Alpha)」 で説明します。

表 1-1 ボリューム・シャドウイングの主な機能,対応する操作,および関連するソフトウェア

機能

操作

使用するソフトウェア

シングル・メンバのシャドウセットを作成する

マウント

SHADOWING システム・パラメータの設定と MOUNT/SHADOW コマンド

マルチ・メンバのシャドウセットを作成する

マウントとコピー

SHADOWING システム・パラメータの設定と MOUNT/SHADOW コマンド。 2 番目または 3 番目のメンバが追加されるときに,シャドウイング・ソフトウェアはコピー操作を自動的に開始します。 OpenVMS V8.4 では,6 メンバまで追加することができます。

シャドウセットからメンバを削除する

デバイスのディスマウント

DISMOUNT コマンド

シャドウセットを解除する

(仮想ユニット名を指定して) シャドウセットをディスマウントする

DISMOUNT コマンド

ハードウェア障害が発生しても, すべてのシャドウセット・メンバが同一のデータを保持すること保証する

マージまたはミニマージ

シャドウイング・ソフトウェアは, ハードウェア障害やソフトウェア障害を検知すると,この操作を自動的に行います。 構成に HSJ または HSC のコントローラが存在する場合,あるいはシステムまたはシャドウセットが HBMM 用に構成されている場合,ミニマージが実行されます。

ディスマウントされたシャドウセット・メンバをシャドウセットに戻す

コピー,アシストコピー,またはミニコピー

MOUNT コマンドとシャドウイング・ソフトウェア。 これらによりコピー (適切に構成されているときはミニコピー) が実行されます。

 

1.3 ハードウェア環境

Volume Shadowing for OpenVMS は,特別なハードウェアを必要としません。 すべてのシャドウイング機能が OpenVMS Integrity および OpenVMS Alpha で実行できます。

ボリューム・シャドウイングを実行するためには, 少なくとも以下のハードウェアが必要です。

  • 1 台の CPU

  • 1 台のマス・ストレージ・コントローラ

  • 以下のいずれかのタイプのディスク・ドライブ

    • DSA (Digital Storage Architecture)

    • SCSI (Small Computer Systems Interface)

    • Fibre Channel

以下の項では,ハードウェア・サポートの概要を説明します。 詳細は,HP Volume Shadowing for OpenVMS の『Software Product Description』(SPD 27.29.xx) を参照してください。

1.3.1 メモリ要件

OpenVMS バージョン 7.3 からは,Volume Shadowing for OpenVMS を実行するためには,以下の追加メモリが必要になりました。

  • OpenVMS Integrity および OpenVMS Alpha システムでは,ノードごとに 24 KB のメモリが必要

    このメモリ要件は,デフォルト設定を変更しない限り,Volume Shadowing for OpenVMS を実行しない場合でも必要です。

    このメモリが利用できない場合は,ノードをブートすることができません。

  • 各ノードのシャドウセットごとに,4.5 KB のメモリが必要

    このメモリはビットマップが作成可能になる前に必要になります。 このメモリが利用できないと,マウントが失敗します (つまり, シャドウセットがノードにマウントされません)。 MOUNT コマンドが失敗した場合,次のメッセージが表示されます。

    %MOUNT-F-INSFMEM, insufficient dynamic memory
    
  • シャドウセット・メンバのストレージ 1 GB ごとに,ノードにマウントされるシャドウセットのビットマップのために,ノードごとに 2.0 KB のメモリが必要です。 (各々のシャドウセットは最大 6 つのビットマップを持つことができます。 また,HBMM のサポートにより,1 つのシャドウセットで最大 12 のビットマップを持つことができます。) メモリの必要量を計算するときは, メンバごとに 50 GB の 2 メンバのシャドウセットの場合は,100 GB ではなく, 50 GB とすることに注意してください。

    たとえば,メンバごとに 200 GB のストレージがあるシャドウセットでは, クラスタ内の各々のノードのビットマップには,420 KB のメモリが必要になります。 このメモリが利用できないノードでビットマップ書き込み要求が発生しても,ビットマップは作成されません。

    マスタビットマップが作成されても,次にシャドウセットがマウントされる別のノードに十分なメモリが存在しない場合には,ローカル・ビットマップは作成されません。 WBM_OPCOM_LVL システム・パラメータに 1 (これがデフォルト) または 2 が設定されていると,次の OPCOM メッセージが表示されます。

    Unable to allocate local bitmap - running in degraded mode.
    

    ローカル・ビットマップを持たないノードからの書き込みは, 最初にシャドウセットがマウントされたノードに登録されます。

これらの必要メモリ量は,累加する必要があります。たとえば,10 個のシャドウセットがマウントされているシステムで, 各々のシャドウセットに 50 GB のメンバ・ディスクがある場合, 追加で 1,069 KB のメモリが必要ですが,この計算は以下のとおりです。

  • 24 KB: ノードごと (ボリューム・シャドウイングの使用に関係なく)

  • 45 KB: (10 シャドウセット x 4.5 KB/システムにマウントされている装置)

  • 1000 KB: (50 x 2.0 KB/ディスクの 1 GB x 10 シャドウセット)

  • 1069 KB: 必要メモリ量の合計

1.3.2 サポートされるデバイス

シャドウセットを構成する物理ディスクの要件は以下のとおりです。

  • OpenVMS Alpha バージョン 7.3–2 からは,異なるサイズのデバイスをシャドウセットの形成に使用できるようになりました。 この機能は,DDS (dissimilar device shadowing) と呼ばれます。 DDS を使用するには,メンバのサイズが異なるシャドウセットをマウントしているすべてのシステムが,OpenVMS V8.2 以降あるいは OpenVMS Alpha V7.3-2 以降を実行していなければなりません。

    OpenVMS Alpha バージョン 7.3–2 より前は,Volume Shadowing for OpenVMS では,シャドウセット内のすべてのメンバが同じサイズ (つまり,各メンバのブロック数が完全に同じ) でなければなりませんでした。 ディスク技術が急速に進歩しているため,この要件は現実的でなくなってきました。 大きなデバイスで使用されないスペースが生ずることより,異なるサイズのデバイスでも使用できるという柔軟性の方が重要になっています。

    運用上は,異なるサイズのデバイスをシャドウイングできるということは,既存のシャドウセットに,より大きなディスク・デバイスを追加できるということを意味します。 シャドウセットは,オリジナルのシャドウセットのファイル・システム・サイズを維持します。 より大きなディスクを追加した後は,小さいディスクを削除すると,シャドウセットのジオメトリ (シリンダ,トラック,およびセクションの数) が,残っている最小のディスクのジオメトリに変わります。 ただし,論理ボリューム・サイズ (つまり,ファイル・システム・サイズ) は変わりません。

    シャドウセットのすべてのメンバの MAXBLOCK サイズは,シャドウセットのストレージ制御ブロック SCB$L_VOLSIZE に格納されている論理ボリューム・サイズ以上でなければなりません。 マウントされているすべてのメンバは,この値を持ちます。 小さいボリュームが不要になった場合,またはシャドウセットのファイル・システム・サイズを大きくする必要がある場合は,OpenVMS Alpha バージョン 7.3–2 で導入された 動的ボリューム拡張 (DVE) 機能を使用できます。 DDS 機能と DVE 機能の両方を使用すると,論理ボリュームをオフラインにすることなく,論理ボリュームを連続的に拡大することができます。 DVE の詳細は,3.5 項 「動的ボリューム拡張 (Integrity および Alpha)」を参照してください。

    注記: ボリューム拡張の際には,新しいボリューム・サイズを含めて書き込みビットマップが再作成されるように,HBMM を無効にしたあと再度有効にすることが必要です。 この操作を行なわないと,拡張された部分は完全なマージが行なわれるため期待するマージ時間よりも長くなる可能性があります。

    各々のディスクのブロック数は, SHOW DEVICE /FULL コマンドで調べることができます。ブロック数は, Total blocksn のように表示されます。

  • ディスクは,Files-11 の ODS-2 (On-Disk Structure Level 2) または ODS-5 (On-Disk Structure Level 5) のデータ・ディスクである必要があります。 Files-11 構造では,オペレーティング・システムがデータを容易に見つけ出せるように,データの受け取りおよび格納のためのボリュームの準備がされています。 ボリューム・シャドウイングは, ユーザやアプリケーションから Files-11 インタフェースを通じて入出力要求を受け取ると,個々のシャドウセット・メンバにデータをシャドウ化します。

  • ディスクとコントローラは次のいずれかのタイプでなければなりません。

    • StorageWorks Fibre Channel

    • StorageWorks SCSI

    • MSCP (mass storage control protocol) 準拠

  • ディスク・ボリュームはハードウェアによる書き込み保護を行ってはなりません。 ハードウェアによる書き込み保護を有効にしていると, ボリューム・シャドウイング・ソフトウェアでボリュームの整合性を維持することができません。

  • READL コマンドと WRITEL コマンドをサポートしていない SCSI ディスクでは, シャドウイング・データの (ディスク不良ブロック・エラーの) 修復が行えないので, サポートが制限されます。このようなディスクがあると, 修復できないエラーが発生した場合に,シャドウセットからメンバが削除されることがあります。 SCSI ディスクが READL コマンドと WRITEL コマンドをサポートしているかどうかを調べる方法は, 4.11.5.1 項 「SDA による他社製 SCSI デバイスの情報取得」 を参照してください。

  • Smart Array 5300 (KZPDC) および XP ストレージ・アレイ・デバイスは, そのシャドウセットのすべてのメンバが耐障害デバイスであれば シャドウセット・メンバになることができます。 KZPDC コンントローラ上の耐障害デバイスは, 基礎となるいずれかの LUN でメディア障害が発生した際にデータエラーを修復できるデバイスです (論理ユニット番号 (LUN) で識別されるデバイス)。 XP ストレージ・アレイ・ファミリのコントローラは, 存在するすべての LUN が耐障害デバイスで形成されていることを必要とします。

    下記のような耐障害デバイスで構成されるデバイスを使用して すべてのシャドウセット・メンバが形成されるという制限付きで, Volume Shadowing for OpenVMS を KZPDC コントローラとともに使用できます。

    • RAID 1,コントローラ・ベースのミラーリングとも呼ばれる

    • RAID 5,パリティ付きのストライピング

    • RAID Advanced Data Guarding (ADG), 複数のパリティ・デバイスを使用したストライピング

    OpenVMS Alpha Version 7.3-2 以降では,異機種デバイス・シャドウイング (DDS) すなわち各メンバの総ブロック数が異なるようなシャドウセットをサポートします。 DDS により,KZPDC コントローラを任意のコントローラ下のデバイスとシャドウ化することができます。

    以前のバージョンの OpenVMS では, マルチメンバ・シャドウセットを作成するには, すべてのデバイスが Volume Shadowing for OpenVMS に対して同じ総ブロック数を報告する必要がありました。 構成ユーティリティは,要求されたサイズに対して作成可能な最も近いサイズで 総ブロック数を KZPDC あるいは MSA1000 デバイスで設定します。 KZPDC および MSA1000 デバイスは同じ計算方法を使用するため, 同じ要求サイズで両者に作成されたデバイスは同じサイズが設定されます。 これにより,Volume Shadowing がマルチメンバ・シャドウセットを作成することが可能になります。

    注意: 耐障害デバイスが使用されていない場合は,Volume Shadowing でマルチメンバ・シャドウセットを作成できない場合があります。 たとえば,1 つのデバイス (物理ディスクあるいは非耐障害デバイス) でシングルメンバ・シャドウセットが形成されている場合,修復不可能なデータ・エラーがデバイスで発生しても Volume Shadowing を使用してシャドウセットに別のメンバを追加することはできません。 シャドウセットに 2 番目のメンバが追加されると,Volume Shadowing はソース・デバイスを読み取ってターゲット・デバイスにコピーします。 ソース・シャドウセット・メンバからデータ・エラーが読み取られると,Volume Shadowing は現在のすべてのシャドウセット・メンバに "バッド・スポット" を作成しようとします。 いずれかのシャドウセット・メンバでバッド・スポットの作成要求が失敗すると, シャドウセットは 1 メンバに縮小されます。

1.4 サポートしている構成

Volume Shadowing for OpenVMS は,広範囲のシステム構成でデータの高可用性を提供します。 1 ノードのシステムから大規模な OpenVMS Cluster システムまでサポートしているので,データの高可用性を最も必要とするところに提供できます。

シャドウセット・メンバの場所については, OpenVMS オペレーティング・システムや OpenVMS Cluster システムの SPD で定義されている正しいディスク構成であれば,制限がありません。

  • OpenVMS オペレーティング・システム:SPD 25.01.xx

  • OpenVMS Cluster ソフトウェア:SPD 29.78.xx

ディスク・ボリュームが,アクティブなシャドウセットのメンバとして既にマウントされている場合,そのディスク・ボリュームを別のノードのスタンドアロン・ディスクとしてマウントすることはできません。

1.4.1 シャドウセットの最大数

複数メンバのシャドウセットの場合,スタンドアロン・システムあるいは OpenVMS Cluster システムで最大 500 シャドウセットをサポートします。 シングル・メンバ・シャドウセットの場合,スタンドアロン・システムあるいは OpenVMS Cluster システムで最大 10,000 のシャドウセットをサポートします。 なお,この総数には,ディスマウントされたシャドウセット,使われていないシャドウセット,ビットマップが割り当てられていないシャドウセットも含まれます。 これらの制限は,コントローラやディスクのタイプには無関係です。 シャドウセットはパブリック・ボリュームとしてもプライベート・ボリュームとしてもマウントすることができます。

OpenVMS バージョン 7.3 からは,SHADOW_MAX_UNIT システム・パラメータを使用して,1 つのノード内に存在できるシャドウセットの最大数を指定できるようになりました。 SHADOW_MAX_UNIT についての詳細は,3.3 項 「ボリューム・シャドウイングのパラメータ」および3.3.1 項 「ボリューム・シャドウイング・パラメータを使う上でのガイドライン」を参照してください。

1.4.2  6メンバ・シャドウセットのサポート

OpenVMS Version 8.4 では,これまでの 3 メンバ・シャドウセットのサポートを拡張し,6 メンバのシャドウセットをサポートします。 この機能拡張は,マルチサイトの耐障害構成に役立ちます。 3 メンバのシャドウセットの場合,3 サイトの耐障害構成では各サイトで 1 シャドウ・メンバのみ構成可能でした。 この場合,2 つのサイトで障害が発生すると残りの 1 サイトのメンバは単一障害点となります。 6 メンバ・シャドウセットであれば,3 つのサイトのそれぞれのシャドウセットで 2 つのメンバを持つことができ,可用性が高まります。

以下に例を示します。

DS10 $ SHOW DEV DSA5678:
Device                  Device           Error    Volume         Free  Trans Mnt
 Name                   Status           Count     Label        Blocks Count Cnt
DSA5678:                Mounted              0  SIXMEMBER       682944     1   1
$6$DKB0:      (WSC236)  ShadowSetMember      0  (member of DSA5678:)
$6$DKB100:    (WSC236)  ShadowSetMember      0  (member of DSA5678:)
$6$DKB200:    (WSC236)  ShadowSetMember      0  (member of DSA5678:)
$6$DKB300:    (WSC236)  ShadowSetMember      0  (member of DSA5678:)
$6$DKB400:    (WSC236)  ShadowSetMember      0  (member of DSA5678:)
$6$DKB500:    (WSC236)  ShadowSetMember      0  (member of DSA5678:)
DS10 $

1.4.2.1 バージョン混成クラスタでの互換性

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

1.4.2.2  6メンバ・シャドウセットの下位互換性

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

1.4.3 システム・ディスクのシャドウイング

データ・ディスクと同じようにシステム・ディスクもシャドウイングすることができます。 したがって,シャドウイングされたディスクからブートするシステムでは, システム・ディスクの単一障害点でシステムダウンになることはありません。 システム・ディスクのシャドウイングは,複数のコンピュータがブートする共通システム・ディスクを持つ OpenVMS Cluster システムでは,特に重要です。 ボリューム・シャドウイングでは OpenVMS の分散ロック・マネージャを使うため, ロックが有効になる前にクォーラム・ディスクにアクセスしなければなりません。 クォーラム・ディスクのシャドウイングはできないことに注意してください。

シャドウイングされたデータ・ディスクを Integrity サーバと Alpha システムで共有することはできますが,システム・ディスクはそれぞれ別にする必要があります。 システム・ディスクはアーキテクチャ毎に 1 つ必要になります。

1.4.3.1 ミニコピーが使われた場合の,シャドウ化されたシステム・ディスクのダンプ・ファイルの取得 (Alpha のみ)

システムが 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』でその詳細が説明されています。

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

  1. システム障害が発生した時点のコンソール出力を調べ, どのデバイスにシステム・ダンプ・ファイルがあるか調べます。

    コンソールには,クラッシュ・ダンプが書き込まれたデバイスが表示されます。 デバイスのシャドウセット・メンバにはクラッシュ・ダンプ・ファイルのフルコピーだけが含まれています。

  2. 次のコマンドを実行して,ダンプが書き込まれたメンバに小さな値を割り当てます。

    $ SET DEVICE/READ_COST=nnn $allo_class$ddcu
    

    ダンプが書き込まれたメンバへの読み取りコストを小さな値に設定すると, SDA または SDA の COPY コマンドによって行われる読み取りがすべてそのメンバに 対して行われます。/READ_COST に 1 を設定することをお勧めします。

  3. システム・ダンプの解析またはコピーを終了したら, シャドウセット・メンバの読み取りコストの値を以前の値に戻す必要があります。 以前の値とは,ボリューム・シャドウイング・ソフトウェアによって自動的に割り当てられたデフォルトの設定でも, 以前にユーザが割り当てた値でも構いません。 読み取りコストを以前の値に戻さない場合は, すべての 読み取り入出力が READ_COST を 1 に設定したメンバに対して行われるので, 読み取り性能が不必要に低下することになります。

    シャドウセット・メンバの READ_COST の設定をデフォルトの値に戻すには, 次のコマンドを実行します。

    $ SET DEVICE /READ_COST=0 DSAnnnn
    

1.4.3.2  EFI シェルでシャドウ化されたシステム・ディスクを操作する場合の注意事項

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 Integrity サーバのシステム・ディスクに対する OpenVMS のホストベースのボリューム・シャドウイング

  • システム・ディスクを共用している Integrity 環境間での,共用システム・ディスクと EFI コンソールへの同時アクセス

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

  • 診断パーティション内での診断ツールのインストールまたは操作

  • パーティション内またはリムーバブル・メディアから実行する診断ツールに OpenVMS Integrity サーバのシステム・ディスク上のブート・パーティションまたは診断パーティションの変更を許可する

  • これらの環境の EFI Shell プロンプトからブート・パーティションまたは診断パーティションを直接的または間接的に変更

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

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

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

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

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

1.4.4 バージョンが混在した OpenVMS Cluster システムでのミニコピーの使用

Integrity サーバと Alpha システムで構成された OpenVMS Cluster システムでミニコピー機能を使う場合は, クラスタ内の すべてのノード で,この機能を含むバージョンの OpenVMS を使う必要があります。 ミニコピー機能をサポートするのは, OpenVMS Integrity V8.2 以降および OpenVMS Alpha V7.2-2 以降です。

| HPE 日本(日本ヒューレット・パッカード株式会社) アーキテクチャが混在した OpenVMS Cluster システムでミニコピー機能を使う場合は, すべての VAX システムの SHADOW_MAX_COPY システム・パラメータを 0 に設定することをお勧めします。 この設定を行うことによって,Alpha 上でミニコピーを行おうとしたときに,VAX 上で実行されてしまうのを防ぐことができます。 アーキテクチャが混在したクラスタでは,稀に,シャドウセットにメンバを追加するタスクが VAX システムに割り当てられることがあります。 VAX システムではミニコピーを実行できないので,代わりにフルコピーが実行されます。 SHADOW_MAX_COPY についての詳細は, を参照してください。 -->

1.4.5 シャドウセット,バウンド・ボリューム・セット,およびストライプ・セット

シャドウセットは,バウンド・ボリューム・セットやストライプ・セットの構成要素とすることができます。 バウンド・ボリューム・セットは, MOUNT コマンドで /BIND 修飾子を指定することによって, ボリューム・セットにバインドされた 1 つまたは複数のディスク・ボリュームで構成されます。 1.4.6 項 「OpenVMS Cluster システムにまたがるシャドウイング・ディスク」 では, 複数の OpenVMS Cluster システムにまたがるシャドウイングについて説明しています。 10.5 項 「ストライピング (RAID) の実装」 では,ストライピングについての詳細を説明し,RAID (redundant arrays of independent disks) テクノロジとボリューム・シャドウイングの関係を説明しています。

1.4.6 OpenVMS Cluster システムにまたがるシャドウイング・ディスク

ホストベースでボリューム・シャドウイングを構成すると, 複数の物理コントローラに接続されたディスクを OpenVMS Cluster システムでシャドウイングすることができます。 シャドウセットのすべてのメンバが同じコントローラに接続されていなければならないという制限はありません。 コントローラが独立していると,コントローラの接続関係や OpenVMS Cluster システムでの位置とは無関係にシャドウセットの管理を行うことができ,データ可用性の強化や柔軟な構成が可能になります。

クラスタ全体のシャドウイングでは,メンバは OpenVMS Cluster システムのどこに位置することも可能で,サポートされている OpenVMS Cluster インターコネクトのいずれを経由しても MSCP サーバのサービスを受けることができます。 OpenVMS Cluster インターコネクトには,CI (computer interconnect),Ethernet (10/100 と Gigabit),ATM,DSSI (Digital Storage Systems Interconnect),および FDDI (Fiber Distributed Data Interface) などがあります。 たとえば,FDDI と WAN サービスを使っている OpenVMS Cluster システムでは, 数百 km 離すことが可能で,システムの可用性や耐災害性が向上します。

図 1-3 「MSCP サーバを経由してアクセスされるシャドウセット」 は,複数のノードに存在するローカル・アダプタに,シャドウセット・メンバが接続された状況を示しています。 この図の中で,ディスク・ボリュームは,2 つのノード ATABOY と ATAGRL の各々にローカルに接続されています。 MSCP サーバは Ethernet を経由したシャドウセット・メンバへのアクセスを可能にします。 ディスク・ボリュームは, 異なるノードにローカルに接続されていますが,同じシャドウセットに属しています。 1 つのノードにローカルに接続されているメンバでも, MSCP サーバを経由することで,リモート・ノードからアクセスすることができます。

図 1-3 MSCP サーバを経由してアクセスされるシャドウセット

MSCP サーバを経由してアクセスされるシャドウセット

シャドウイング・ソフトウェアはシャドウセットを各ノードに分散させて保持し, シャドウセットを OpenVMS Cluster システムにマウントします。 OpenVMS Cluster 環境では,各ノードはシャドウセットを独立に作成し, 維持します。各ノードにあるシャドウイング・ソフトウェアは, 仮想ユニット名で表現される各々のシャドウセットを, それぞれの物理ユニットにマップします。シャドウセットは他のノードにはサービスされません。 シャドウセットを複数のノードからアクセスする必要がある場合は,各々のノードに同じシャドウセットを作成します。 シャドウイング・ソフトウェアは,複数のノードにマウントされたシャドウセットに対し,クラスタ単位のメンバ構成の一貫性を維持します。

OpenVMS Cluster システムにマウントされたシャドウセットを, クラスタ内のあるノードでマウントしたりディスマウントしても, システム内の別のノードで実行しているアプリケーションやユーザに対しては, 何の影響もありません。たとえば,OpenVMS Cluster システムの 1 つのノードからシャドウセットをディスマウントしても,それをマウントしている別のノードでのシャドウセット操作を継続させることができます。

1.4.7 HBMM の構成要件

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

  • HP Integrity サーバおよび Alpha システムで構成されるクラスタでは,すべての HP Integrity サーバで OpenVMS Integrity V8.2 以降が動作し,すべての Alpha システムで OpenVMS Alpha V7.3-2 (HBMM キットと共に) または V8.2 以降が動作している必要があります。

    HBMM についての詳細は,第8章 「ホストベース・ミニマージ (HBMM)」を参照してください。

  • 1.3.1 項 「メモリ要件」 で説明しているように,ビットマップをサポートするために十分なメモリが必要です。

1.4.8 HBMM の制限事項

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

1.4.8.1 クラスタ構成の制限

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

  • 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.4.8.2 シャドウセット・メンバの制限事項

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

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

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

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

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

1.4.9 バージョン混成またはアーキテクチャ混成の OpenVMS Cluster システムでの HBMM

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

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

書き込みビットマップをサポートしている以前のバージョンの OpenVMS は以下のとおりです。

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

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

1.4.9.1 拡張シャドウイング機能

ミニコピーの場合,すべてのクラスタメンバがミニコピーをサポートしている必要があります。 一方 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 でも,そのシャドウセットをマウントできます。

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

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

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

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

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

1.5 インストレーション

Volume Shadowing for OpenVMS は SIP (System Integrated Product) なので, オペレーティング・システムをインストールするときに同時にインストールされます。 OpenVMS Integrity では,Volume Shadowing のライセンスは Enterprise OE および Mission Critical OE に含まれています。 Foundation OE には含まれていませんが,別途購入することはできます。 OpenVMS Alpha で Volume Shadowing を使用する場合は,OpenVMS のベース・オペレーティング・システム・ライセンスとは別に独自のライセンスが必要です。 シャドウ化されたシステム・ディスクからブートされるすべてのノードにシャドウイングがライセンスされ,それらのシステムで有効になっていなくてはなりません。 ご使用の OpenVMS のアップグレード/インストレーション・マニュアルの説明を参照してください。

Volume Shadowing for OpenVMS のライセンスの詳細は, 3.2 項 「Volume Shadowing for OpenVMS のライセンス登録」 を参照してください。

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