日本-日本語

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

OpenVMS マニュアル


≫ 

OpenVMS V8.3
ライブラリ

タイトルページ
目次
まえがき
第 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 ファイルにアクセスが集中するようであれば,半導体ディスク (SSD) に常駐させて,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 マルチ・バージョンの移行サポートと保証サポート

弊社では,バージョン混在およびアーキテクチャ混在環境の OpenVMS Cluster システムに対し,移行サポートと保証サポートの 2 つのレベルのサポートを提供します。

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

  • Alpha Version 8.2 と I64 Version 8.2

  • Alpha Version 7.3-2 と I64 Version 8.2

  • Alpha Version 7.3-2 と Alpha Version 8.2

  • Alpha Version 7.3-2,Alpha Version 8.2,および I64 Version 8.2

  • Alpha Version 7.3-2 と VAX Version 7.3

  • VAX Version 7.3 と Alpha Version 8.2

移行サポートは,カスタマのクラスタ環境で,保証されている OpenVMS Cluster 構成へ最小限の影響で移行するのを支援するためのサポートです。移行サポートでは,新しいバージョンの OpenVMS VAX や OpenVMS Alpha に段階的に移行していくユーザのために,ともに使用できるバージョンを明確に示します。弊社は,これらの構成に対して提出される問題レポートに回答します。ただし,例外的にソリューションの一環として,保証されている構成に移行するようユーザに依頼する場合があります。

複合バージョンのクラスタでは, OpenVMS の旧バージョンに修正キットをインストールする必要があります。必要な修正キットの完全なリストについては,『HP OpenVMS Version 8.2 リリース・ノート [翻訳版]』を参照してください。

11.8 同一 OpenVMS Cluster 内の Alpha,VAX,および I64 システム

OpenVMS Alpha システムと OpenVMS VAX システムの組み合わせや, OpenVMS Alpha システムと OpenVMS I64 システムの組み合わせは,柔軟性と移行機能の両方を持たせるために,同じ OpenVMS Cluster に組み込めるようになっています。さらに,異なるプラットフォームを使用することで,システムやハードウェアに固有のアプリケーションを使用できます。

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.3 を OpenVMS Alpha バージョン 7.3 のシステム・ディスクに共存させることはできません。


目次 索引

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