日本-日本語

製品  >  ソフトウェア  >  OpenVMS  >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS V7.3-2
ライブラリ

タイトルページ
目次
まえがき
第 1 章:システム構成の概要
第 2 章:ビジネス要件とアプリケーション要件の決定
第 3 章:システムの選択
第 4 章:インターコネクトの選択
第 5 章:ストレージ・サブシステムの選択
第 6 章:SCSI と Fibre Channel ストレージに対するマルチパスの構成
第 7 章:ストレージ・インターコネクトとしての Fibre Channel の構成
第 8 章:可用性を目的とした OpenVMS Cluster の構成
第 9 章:可用性とパフォーマンスを目的とした CI OpenVMS Cluster の構成
第 10 章:スケーラビリティを目的とした OpenVMS Cluster の構成
第 11 章:システム管理の手法
付録 A :インターコネクトとしての SCSI
付録 B :MEMORY CHANNEL 技術概要
付録 C :CI-to-PCI アダプタ (CIPCA) サポート
付録 D :マルチサイト OpenVMS Cluster
索引
PDF
OpenVMS ホーム

HP OpenVMS
OpenVMS Cluster 構成ガイド


目次 索引



この節では,複数のSYSUAF.DAT ファイルや複数のキュー・マネージャの使用方法など,その他のマルチ環境の手法について説明します。

11.4.1 複数の SYSUAF.DAT ファイルの使用

ほとんどの OpenVMS Clusterは,1 つのユーザ権限 (SYSUAF.DAT) ファイルで管理しますが,複数のユーザ権限ファイルを利用すれば,ユーザがアクセスできるシステムを限定することができます。この方法では,すべてのシステムのアクセスを必要とするユーザには複数のパスワードが必要になります。

複数の SYSUAF.DAT ファイルを運用する場合は,セキュリティに気をつけてください。 OpenVMS VAX および OpenVMS Alpha オペレーティング・システムでは,複数のセキュリティ・ドメインをサポートしていません。

関連項目: SYSUAF.DAT エントリなど,シングル・セキュリティ・ドメイン内では同一でなければならないフィールドの一覧については,『OpenVMS Cluster システム』を参照してください。

Alpha システムでは,多くのプロセス割り当て量が必要なため,システム管理者は複数の SYSUAF.DAT ファイルを用意して対応することがあります。しかし,これは最適な解決方法とは言えません。複数の SYSUAF.DAT ファイルを作成するのは,ノードによって環境を変えるためであり,プロセス割り当て量を増やすのが本来の目的ではありません。プロセス割り当て量を増やす方法としては,SYSUAF.DAT ファイルを 1 つとし, SYSUAF.DAT ファイルで指定したプロセス割り当て量を無効にするシステム・パラメータを使用して Alpha システムのリソースを管理する方法をお勧めします。

11.4.2 複数のキュー・マネージャの使用

OpenVMS Cluster におけるバッチ・トランザクションとプリント・トランザクションの数が多すぎて混雑している場合,複数のキュー・マネージャを実装してバッチとプリントの負荷をノード間に分散させることができます。

OpenVMS Cluster には,QMAN$MASTER.DAT ファイルを 1 つずつ配置します。複数のキュー・マネージャは,複数の*.QMAN$QUEUES ファイルと *.QMAN$JOURNAL ファイルで定義します。キュー・マネージャ・ファイルの各ペアを別々のディスクに配置します。 QMAN$MASTER.DAT ファイルにアクセスが集中するようであれば,半導体ディスクに常駐させて,OpenVMS Cluster が処理できるバッチ・トランザクションとプリント・トランザクションの数を増やします。たとえば,バッチ・キューとプリント・キューに別々のキュー・マネージャを作成できます。

関連項目: 複数のキュー・マネージャの実装例とコマンドについては,『OpenVMS システム管理者マニュアル (上巻)』を参照してください。

11.5 クォーラムの手法

OpenVMS Cluster システムは,クォーラム・アルゴリズムを利用してストレージのアクセスを同期します。クォーラム・アルゴリズムとは,OpenVMS Cluster システムでリソースを共用する方法を "決定する(ボートする)" 多数のOpenVMS Cluster メンバが存在するかどうかを確かめる数学的手法です。接続マネージャは,動的な値としてクォーラムを計算し,OpenVMS Cluster メンバの大半が機能しているときにだけ処理を実行します。

クォーラム・ボーツを決定する要素は次のとおりです。

  • パラメータ VOTES がゼロを超える値に設定してあるシステム

  • クォーラム・ディスクと呼ばれる所定のディスク

各 OpenVMS Cluster システムには,クォーラム・ディスクを 1 つだけ配置できます。クォーラム・ディスクはシャドウ・セットのメンバにはできませんが,システム・ディスクにすることはできます。

接続マネージャは,"クォーラム・ディスク・ウォッチャ"からクォーラム・ディスクの情報を入手します。クォーラム・ディスク・ウォッチャは,クォーラム・ディスクとの間にアクティブな直接接続を持つ,任意のシステムです。

11.5.1 クォーラム手法のオプション

クォーラム・ディスクには,少なくとも直接接続を持つシステムが 2 つ必要です。これによってシステムのどちらかに障害が発生しても,クォーラム・ディスク・ボーツにアクセスできます。

クォーラム手法を検討するにあたり,どのような障害状況のときに OpenVMS Cluster の処理を続行するかを決めておく必要があります。 表 11-4 は,その 4 つのオプションを示したものです。

表 11-4 クォーラムの手法
手法のオプション1 説明
"予想"最高ノード数が残っていれば,処理を続行する。 すべてのノードにボーツを与え,クォーラム・ディスクは使用しません。この手法では,ノードが 3 個以上必要です。
(3 つ以上のノードの内) ノードが 1 つでも残っていれば,処理を続行する。 この手法では,クォーラム・ディスクが必要です。

全システムのボーツ合計数より 1 つ少ない値までクォーラム・ディスクのボーツ数を増やすと (また,EXPECTED_VOTES システム・パラメータの値も同じだけ増やす),ノードが 1 つだけのクラスタをクォーラム・ディスク・ウォッチャとして実行できます。この場合,ボーツ・システムの過半数になるまで待たなくても OpenVMS Cluster システムを利用できます。

(2 ノード OpenVMS Cluster) ノードが 1 つでも残っていれば,処理を続行する。 各ノードとクォーラム・ディスクにボーツを与えます。

2 ノード OpenVMS Cluster は,特別な事例です。クォーラム・ディスクを確立すると, 2 ノード OpenVMS Cluster の可用性を強化できます。このような構成では,クォーラム・ディスクまたは 1 ノードが故障してもクォーラムを維持し運用を続行することができます。この場合,両方のノードが,両方ともクォーラム・ディスク・ウォッチャになるように, (CI,DSSI,SCSI,または Fibre Channel によって) ストレージに直接接続される必要があります。

OpenVMS Cluster の重要ノードが 1 つでも処理を続行する。 一般に,この手法では,サーバにはボーツが与えられ,サテライトには与えられません。 3 つ以上のサーバがあり,クォーラム・ディスクがないことが前提です。

1これらの手法は,互いに排他的です。どれか 1 つだけを選択してください。

関連項目: クォーラム・ディスク管理の詳細については,『OpenVMS Cluster システム』を参照してください。

11.6 状態遷移の手法

OpenVMS Cluster の状態遷移は,OpenVMS Cluster システムに対してシステムを追加したり削除したとき,そして OpenVMS Cluster がクォーラム・ディスクの状態遷移を検出すると発生します。接続マネージャは,これらのイベントを受けて OpenVMS Cluster 内のデータの一貫性を維持するように対応します。

状態遷移が問題になるのは,システムが OpenVMS Cluster システムに対して頻繁に追加あるいは削除され,それによって障害が発生する場合です。

ユーザとアプリケーションに対する状態遷移の間隔と効果は,遷移の理由,構成,使用中のアプリケーションによって決まります。遷移を有効に管理すれば,システム・マネージャは以下の対応ができます。

  • 障害の検出と遷移の所要時間

  • ボリューム・シャドウイングのコピー,マージ処理など,遷移の影響



11.6.1 状態遷移の処理

以下の指針は,実際の遷移時間を短縮し,遷移後の影響を最小限にするための方法をまとめたものです。

  • ノードと OpenVMS Cluster 間の接続が切れないように以下の方法で対応してください。

    • システム全体でインターコネクトに冗長性を与える。

    • インターコネクト,プロセッサ,アダプタの容量不足だけではなく,ディスクとメモリのリソース欠乏を防ぐ。

    • 無停電電源装置 (UPS) を使用する。

    • 大規模 OpenVMS Cluster におけるワークステーションのシャットオフでクラスタ内の全システムの操作に支障が生じないようユーザに通知する。

  • OpenVMS Cluster のノード数が 2 個でない限り,クォーラム・ディスクを使用しない。

  • 可用性を強化できるように,シャドウ・セット・メンバはできるだけ共用バスに常駐するようにする。

  • ノード,ディスク,アダプタ,インターコネクト,仮想回路の障害を検出する時間は,システム・ポーリング・パラメータで制御します。ポーリング時間を短縮すると,変化に対するクラスタの応答は良くなりますが,一時的な障害に弱くなります。タイマの設定にあたっては,重大障害からの迅速な回復と一時的障害に対する"過敏さ"とのバランスを考えてください。
    表 11-5 は,検出時間を短縮する際に設定する OpenVMS Cluster ポーリング・パラメータをまとめたものです。これらのパラメータの値は,各 OpenVMS Cluster と同じ値に設定することをお勧めします。

    表 11-5 OpenVMS Cluster ポーリング・パラメータ
    パラメータ 説明
    QDSKINTERVAL クォーラム・ディスク・ポーリング間隔を指定します。
    RECNXINTERVL 接続マネージャが別のシステムとの通信を復元するときの所要時間を指定します。
    TIMVCFAIL 仮想回路障害の検出に必要な時間を指定します。

  • アプリケーション回復時間を計画に入れておいてください。アプリケーション・ユーザに対する状態遷移の影響を評価するときは,アプリケーション回復フェーズに,ジャーナル・ファイルの再生,回復ユニットのクリーニング,再度ログインするユーザのことを考慮してください。

関連項目: OpenVMS Cluster 遷移とそのフェーズ,システム・パラメータ,クォーラム管理の詳細については,『OpenVMS Cluster システム』を参照してください。

11.7 マルチ・バージョンの移行サポートと保証サポート

HP では,複合バージョンと複合アーキテクチャの OpenVMS Cluster システムに対し,2 つのレベルのサポート,移行サポートと保証サポートを提供しています。

保証サポートとは,OpenVMS Cluster 上に 2 つのバージョンが共存することを認めているものであり,これらの構成を使用している利用者から寄せられた問題にはすべて回答します。

移行サポートは,OpenVMS の旧リリースで提供されていた Rolling Upgrade サポートの上位セットであり,保証されていない複合バージョンで利用できます。移行サポートとは,新しいバージョンの OpenVMS VAX や OpenVMS Alpha に段階的に移行しつつある構成で,共に使用できるバージョンを明確に示すサポートです。弊社は,これらの構成に対して提出される問題レポートに回答します。ただし,例外事例については,問題に対する回答の中で,保証されている構成に移行するよう依頼する場合があります。

弊社は,アーキテクチャに関係なく,クラスタ内で同時に実行できる OpenVMS のバージョンを 2 つだけサポートします。移行サポートは,カスタマのクラスタ環境に対して,最小限の影響で,保証されている OpenVMS Cluster 複合バージョンに移行するのを支援するサポートです。

表 11-6 は,各バージョンの組み合わせに対するサポート・レベルです。

表 11-6 OpenVMS Cluster の保証サポートと移行サポート
  Alpha/VAX V7.3 Alpha V7.2--xxx/
VAX V7.2
Alpha/VAX V7.1
Alpha/VAX V7.3 保証 移行 移行
Alpha V7.2-- xxx/
VAX V7.2
移行 保証 移行
Alpha/VAX V7.1 移行 移行 保証

複合バージョンのクラスタでは,OpenVMS の旧バージョンに修正キットをインストールする必要があります。 OpenVMS バージョン 7.3 の場合, OpenVMS の旧バージョンを実行しているすべてのノードに,必要な修正キットをインストールしていない限り,2 つの機能,XFC およびボリューム・シャドウイングの minicopy 操作は,複合バージョンのクラスタのどのノードでも実行できません。修正キットは,OpenVMS Alpha/VAX バージョン 7.1 のボリューム・シャドウイングの minicopy 操作を除き,すべてのバージョンでどちらの機能についても利用できます。

必要な修正キットの完全なリストについては,『 OpenVMS V 7.3 リリース・ノート【翻訳版】』を参照してください。

11.8 1 つの OpenVMS Cluster に Alpha システムと VAX システム

OpenVMS Alpha システムと OpenVMS VAX システムは,同じ OpenVMS Cluster に組み込んで,両方の柔軟性と移行の機能を利用できます。Alpha の処理能力を既存の VAXcluster に追加することで,システムやハードウェアに固有のアプリケーションを活用できます。

表 11-6 は,弊社が移行サポートと保証サポートを提供する OpenVMS バージョン・ペアです。

11.8.1 アーキテクチャを横断しての OpenVMS Cluster のサテライト・ブート

OpenVMS Alpha バージョン 7.1 と OpenVMS VAX バージョン 7.1 では,VAX ブート・ノードから Alpha サテライトとブート・サービスを提供でき,また逆に,Alpha ブート・ノードからは VAX サテライトにブート・サービスを提供することができます。このサポートをクロス・アーキテクチャ・ブートといい,構成の柔軟性とサテライトに対するブート・サーバの可用性を高めることができます。

クロス・アーキテクチャ・ブートが必要な構成状況としては,次の 2 通りが考えられます。

  • VAX システム・ディスクと同じ可用性が高くパフォーマンスにすぐれた領域で, Alpha システム・ディスクを構成したい。

  • Alpha ブート・サーバが CI ストレージや DSSI ストレージを VAX ブート・サーバと共用している。 Alpha の唯一のブート・サーバに障害が発生した場合,Alpha ブート・サーバのリブート前に Alpha サテライトをリブートしたい。



11.8.2 制限事項

OpenVMS オペレーティング・システムおよびレイヤード・プロダクトのインストールとアップグレードは,アーキテクチャを越えて実行することはできません。たとえば, OpenVMS Alpha ソフトウェアのインストールとアップグレードには Alpha システムを使用します。クロス・アーキテクチャ・ブートを利用できる OpenVMS Cluster システムを構成するとき,各アーキテクチャから少なくとも 1 システムは,インストールとアップグレードに使用できるディスクで構成してください。

システム・ディスクに常駐できる OpenVMS オペレーティング・システムのバージョンは 1 つだけであり,アーキテクチャ固有のバージョンとします。たとえば, OpenVMS VAX バージョン 7.1 を OpenVMS Alpha バージョン 7.1 のシステム・ディスクに共存させることはできません。

11.9 バックアップとストレージの管理手法の選択

どのようなシステムでも,人的ミスと同様にハードウェア障害や電気的障害から逃れることはできません。重要なデータは,バックアップをとり,このようなエラーを最小限に抑えるようにしなければなりません。バックアップに利用できる時間とリソースによって方法はさまざまです。

11.9.1 バックアップ手法の選択手順

バックアップ手法を選択するには,以下の手順に従ってください。

手順 説明
1 障害の発生時に失われる作業量の範囲を決めます。これにより,バックアップ実行の必要頻度が決まります。
2 バックアップ時に,データを使用できない時間を決めます。これで,バックアップの方法が決まります。
3 頻度,バックアップを実行する頻度や時刻,日にち,週などのバックアップ・スケジュールを作成します。

次の項目を決めます。

  • 毎日,毎週,毎月のバックアップ・データ量。

  • バックアップはフル・バックアップとするか,増分バックアップとするか。それぞれの実行頻度。

4 十分なバックアップ媒体が得られるかを確認します。当初必要なバックアップ媒体の容量と,必要量の増加ペースを決定します。
5 採用するバックアップ手法で,バックアップ媒体をサイト外部で保管する必要があるかどうかを決定します。


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項