日本-日本語

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

OpenVMS マニュアル


≫ 

OpenVMS V8.3
ライブラリ

タイトルページ
目次
まえがき
第 1 章:OpenVMS Cluster システムの管理の概要
第 2 章:OpenVMS Cluster の概念
第 3 章:OpenVMS Cluster インターコネクト構成
第 4 章:OpenVMS Cluster オペレーティング環境
第 5 章:共用環境の準備
第 6 章:クラスタ・ストレージ・デバイス
第 7 章:クラスタ・キューの設定と管理
第 8 章:OpenVMS Cluster システムの構成
第 9 章:大規模な OpenVMS Cluster システムの構築
第 10 章:OpenVMS Cluster システムの保守
付録 A :クラスタ・システム・パラメータ
付録 B :共通ファイルの作成
付録 C :クラスタのトラブルシューティング
付録 D :LAN 制御のためのサンプル・プログラム
付録 E :LAN 制御のためのサブルーチン
付録 F :NISCA プロトコルのトラブルシューティング
付録 G :NISCA トランスポート・プロトコル・チャネル選択および輻輳制御
索引
PDF
OpenVMS ホーム
OpenVMS | HPE 日本(日本ヒューレット・パッカード株式会社)

OpenVMS
OpenVMS Cluster システム


目次 索引

第 10 章
OpenVMS Cluster システムの保守

クラスタが起動され,動作するようになったら,サイト固有の日常の保守操作を行うことができます。たとえば,ディスクのバックアップやユーザ・アカウントの追加,ソフトウェアのアップグレードやインストール,フィードバック・オプション付きの AUTOGEN の定期的な実行,システムのパフォーマンスの監視などを行うことができます。

現在の構成データの記録を管理することも必要です。特に,ハードウェア・コンポーネントやソフトウェア・コンポーネントの変更は記録しておく必要があります。サテライト・ノードを含むクラスタを管理する場合は, LAN の動作を監視することが重要です。

以下の特殊な保守操作が必要になることがあります。

  • 予測しないコンピュータ障害が発生した後のクラスタ・クォーラムの復元

  • 条件付きシャットダウン操作の実行

  • LAN および複合インターコネクト・クラスタでのセキュリティ機能の実行



10.1 データとファイルのバックアップ

定期的なシステム管理手順の一部として,OpenVMS Backup ユーティリティを使用して,オペレーティング・システム・ファイル,アプリケーション・ソフトウェア・ファイル,関連ファイルを別のデバイスにコピーしなければなりません。

OpenVMS Cluster で行う一部のバックアップ操作は,シングル OpenVMS システムの場合と同じです。たとえば,使用中のディスクの追加型バックアップや,非共用ディスクのバックアップは同じです。

クラスタで使用するバックアップ・ツールとしては, 表 10-1 に示すものがあります。

表 10-1 バックアップ方法
ツール 使い方
オンライン・バックアップ 以下のディスクをバックアップするために,実行中のシステムから使用する。

  • システムのローカル・ディスク

  • システム・ディスク以外のクラスタ共用可能ディスク

  • システム・ディスク

警告: バックアップを実行する時点で書き込みのためにオープンされているファイルは,正しくバックアップされないことがある。

メニュー・ドリブンまたは +スタンドアロン BACKUP 以下のいずれかの方法を使用する。

  • OpenVMS Alpha または VAX ディストリビューション CD-ROM にアクセスできる場合は,ディスクに格納されているメニュー・システムを使用して,システムをバックアップする。このメニュー・システムは, CD-ROM をブートしたときに自動的に表示され,以下の操作が可能である。

    • DCL 環境を開始し,その環境からシステム・ディスクでバックアップおよび復元操作を実行できる (スタンドアロン BACKUP の代わりに使用できる)。

    • POLYCENTER Software Installation ユーティリティを使用して,オペレーティング・システムとレイヤード製品をインストールまたはアップグレードできる。

    関連項目: メニューを使用する手順については,『 OpenVMS Upgrade and Installation Manual』と『OpenVMS システム管理者マニュアル』を参照。

  • OpenVMS VAX ディストリビューション CD-ROM にアクセスできない場合は,スタンドアロン BACKUP を使用して,システム・ディスクのバックアップと復元を行わなければならない。スタンドアロン BACKUP の場合:

    • 以下の理由から,注意して使用しなければならない。

      1. クラスタに参加しない。

      2. ボリュームの所有権やファイル I/O の同期がクラスタ内の他のシステムとの間でとられない。

    • コンソール・メディアの代わりに,システム・ディスクからブートできる。スタンドアロン BACKUP はどのシステム・ディスクでも予約ルートに構築される。

    関連項目: スタンドアロン BACKUP の詳細については,『OpenVMS システム管理者マニュアル』を参照。


+VAX 固有

アプリケーションやユーザの要件に応じて,バックアップ・プロセスは定期的に実行するようにしてください。バックアップ・スケジュールを作成する際は,ユーザとアプリケーションによるシステムの利用が少ない時刻にバックアップを行うように調整してください。

関連項目: OpenVMS Backup ユーティリティの詳細については,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル (上巻 ) 』を参照してください。

10.2 OpenVMS オペレーティング・システムの更新

OpenVMS オペレーティング・システムを更新する場合は, 表 10-2 の手順に従います。

表 10-2 OpenVMS オペレーティング・システムのアップグレード
ステップ 操作
1 システム・ディスクをバックアップする。
2 各システム・ディスクに対して 1 回ずつ,更新手順を実行する。
3 必須アップデートをインストールする。
4 そのシステム・ディスクからブートされる各ノードで AUTOGEN を実行する。
5 UETP (User Environment Test Package) を実行して,インストールをテストする。
6 OpenVMS Backup ユーティリティを使用して,新しいシステム・ボリュームのコピーを作成する。

関連項目: 詳細については,適切な OpenVMS アップグレードおよびインストール・マニュアルを参照してください。

10.2.1 ローリング・アップグレード

OpenVMS オペレーティング・システムでは,複数のオペレーティング・システムを使用している OpenVMS Cluster システムは,システム・ソフトウェアをアップグレードする間もサービスを提供できます。このプロセスを ローリング・アップグレード と呼びます。これは,すべてのノードがアップグレードされるまで,各ノードが順にアップグレードされ,リブートされるからです。

システムを 1 つのシステム・ディスクから 2 つ以上のシステム・ディスクに移行しなければならない場合は,以下の操作を行います。

ステップ 操作
1 第 8.5 節 の手順に従って,ディスクの複製を作成する。
2 システム・ファイルの調整については, 第 5.10 節 の説明に従う。

ここに示した各関連項目は,システム・ディスクを追加し,複数のシステム・ディスクに共通のユーザ環境を準備することにより,キュー・データベース,ライトリスト,プロキシ,メール,その他のファイルなどの共用システム・ファイルを OpenVMS Cluster システム全体で使用可能にするときに参照すると役立ちます。

10.3 LAN ネットワーク障害の分析

OpenVMS オペレーティング・システムでは, LAN で発生した OpenVMS Cluster ネットワーク障害を分析するのに役立つサンプル・プログラムが提供されています。 SYS$EXAMPLES:LAVC$FAILURE_ANALYSIS.MAR プログラムを編集して,利用することにより,障害が発生しているネットワーク・コンポーネントを検出し,切り分けることができます。ネットワーク障害分析プログラムを利用すると,障害が発生しているネットワーク・コンポーネントを検出して切り分けるのに必要な時間を短縮することができ,その結果,クラスタの可用性を大幅に向上できます。

関連項目: ネットワーク障害分析プログラムの詳細については, 付録 D を参照してください。

10.4 構成データの記録

OpenVMS Cluster システムを効果的に管理するには,すべてのハードウェア・コンポーネントとソフトウェア・コンポーネントの現在の状態,およびこれらのコンポーネントに対して行った変更に関する正確な記録を保存しておかなければなりません。クラスタ・コンポーネントを変更すると,クラスタ全体の動作に大きな影響がある可能性があります。障害が発生した場合は,この記録を調べて,問題の診断に役立てることができます。

構成に関する現在の記録の管理は,日常の操作にとっても,問題が発生したときのトラブルシューティングにとっても必要です。

10.4.1 レコード情報

構成レコードには,少なくとも以下の情報を含まなければなりません。

  • 物理的なクラスタ構成を示すダイアグラム (LAN 構成ダイアグラムの保存方法については, 付録 D を参照)

  • すべてのコンピュータの SCSNODE および SCSSYSTEMID パラメータ値

  • VOTES および EXPECTED_VOTES パラメータ値

  • すべてのコンピュータの DECnet 名とアドレス

  • クラスタ関連システム・パラメータの現在の値,特に HSC サブシステムとコンピュータの ALLOCLASS および TAPE_ALLOCLASS の値
    関連項目: クラスタ・システム・パラメータについては, 付録 A を参照。

  • CI によって接続されているすべてのコンピュータのデフォルト・ブートストラップ・コマンド・プロシージャの名前と場所

  • クラスタ・ディスク・デバイスとテープ・デバイスの名前

  • LAN および複合インターコネクト・クラスタで,サテライトの LAN ハードウェア・アドレス

  • LAN アダプタの名前

  • LAN セグメントまたはリングの名前

  • LAN ブリッジの名前

  • ワイヤリング・コンセントレータの名前,または DELNI または DEMPR アダプタの名前

  • すべてのハードウェア・コンポーネントのシリアル番号

  • ハードウェア・コンポーネントまたはソフトウェア・コンポーネントに対して行った変更 (サイト固有のコマンド・プロシージャを含む),および変更の日時



10.4.2 サテライト・ネットワーク・データ

CLUSTER_CONFIG.COM を初めて実行してサテライトを追加する場合,このプロシージャはブート・サーバの SYS$SPECIFIC:[SYSMGR] ディレクトリに NETNODE_UPDATE.COM ファイルを作成します ( 共通環境クラスタの場合は,このファイル名を SYS$COMMON:[SYSMGR] ディレクトリに変更する必要があります。 第 5.10.2 項 を参照してください )。このファイルは,サテライトを追加または削除するときや, Ethernet または FDDI ハードウェア・アドレスを変更するたびに更新されます。このファイルには,サテライトの重要なすべてのネットワーク構成データが格納されています。

サイトで予測しない状況が発生して,構成データが失われた場合は, NETNODE_UPDATE.COM を使用して復元できます。また,個々のサテライトのデータを取得しなければならない場合も,このファイルを読み込むことができます。ファイルはときどき編集して,古くなったエントリを削除しておく必要があります。

例 10-1 は,サテライト EUROPA と GANYMD がクラスタに追加された後,ファイルの内容がどのようになるかを示しています。

例 10-1 NETNODE_UPDATE.COM ファイルの例

$ RUN SYS$SYSTEM:NCP 
    define node EUROPA address 2.21 
    define node EUROPA hardware address 08-00-2B-03-51-75 
    define node EUROPA load assist agent sys$share:niscs_laa.exe 
    define node EUROPA load assist parameter $1$DJA11:<SYS10.> 
    define node EUROPA tertiary loader sys$system:tertiary_vmb.exe 
    define node GANYMD address 2.22 
    define node GANYMD hardware address 08-00-2B-03-58-14 
    define node GANYMD load assist agent sys$share:niscs_laa.exe 
    define node GANYMD load assist parameter $1$DJA11:<SYS11.> 
    define node GANYMD tertiary loader sys$system:tertiary_vmb.exe 

関連項目: DECnet-Plus の NCL コマンドについては,DECnet-Plus のマニュアルを参照してください。

10.5 クロスアーキテクチャ・サテライト・ブート

クロスアーキテクチャ・サテライト・ブートを利用すると, VAX ブート・ノードは Alpha サテライトにブート・サービスを提供でき, Alpha ブート・ノードは VAX サテライトにブート・サービスを提供できます。一部の OpenVMS Cluster 構成では,クロスアーキテクチャ・ブートのサポートにより,日常のシステム操作が単純化され,VAX システムと Alpha システムの両方を含む OpenVMS Cluster の管理の複雑さを軽減することができます。

注意: クロスアーキテクチャ・ブートのサポートが技術的に可能な限り,弊社は今後もこのサポートを提供します。しかし,OpenVMS オペレーティング・システムの将来のリリースでは,このサポートは削除される可能性があります。

10.5.1 構成例

この後の構成例では,Alpha と VAX のブート・ノードとサテライト・ノードを含む OpenVMS Cluster を構成する方法を示しています。各アーキテクチャには,インストールとアップグレードで使用されるシステム・ディスクがそれぞれ必要です。

警告: OpenVMS オペレーティング・システムとレイヤード製品のインストールおよびアップグレードは,異なるアーキテクチャ間で行うことができません。たとえば,OpenVMS Alpha ソフトウェアのインストールとアップグレードは, Alpha システムを使用して実行しなければなりません。クロスアーキテクチャ・ブート機能を使用する OpenVMS Cluster システムを構成する場合,インストールとアップグレードで使用できるディスクを装備したシステムを各アーキテクチャで少なくとも 1 台構成してください。 図 10-1図 10-2 に示した構成では,ワークステーションが 1 台ずつ,この目的でローカル・ディスクを使用するように構成されています。

図 10-1 では,DSSI インターコネクトを使用する 2 台の VAX ブート・ノードと複数の VAX ワークステーションを含む既存の VAXcluster 構成に,複数の Alpha ワークステーションが追加されています。高い可用性を実現するために, Alpha システム・ディスクは複数のブート・サーバからアクセスできるように DSSI 上にあります。

図 10-1 VAX ノードによる Alpha サテライトのブート


図 10-2 の構成には,もともと 1 台の VAX ブート・ノードと複数の VAX ワークステーションが含まれていました。その後,VAX ブート・ノードがパフォーマンスの高い新しい Alpha ブート・ノードに変更されました。また,数台の Alpha ワークステーションも追加されました。もともと含まれていた VAX ワークステーションはそのまま構成に残されており,ブート・サービスを必要としています。新しい Alpha ブート・ノードはこのサービスを実行できます。

図 10-2 Alpha ノードと VAX ノードによる Alpha サテライトと VAX サテライトのブート




クロスアーキテクチャ・ブート機能を使用する場合は,以下のガイドラインに従ってください。

  • OpenVMS ソフトウェアのインストールとアップグレードの手順は,アーキテクチャに応じて異なります。オペレーティング・システムのインストールやアップグレードを行う場合は,適切なアーキテクチャのシステムから直接アクセスできるディスクに対して行わなければなりません。異なるアーキテクチャのシステム・ディスクを装備したブート・サーバを構成する場合は,以下の 3 つのシステム管理手順が必要になります。

    • 同じアーキテクチャのシステムから直接アクセスできるディスクにオペレーティング・システムをインストールします。

    • 作成されるシステム・ディスクを移動して,ターゲット・ブート・サーバで直接アクセスできるようにします。構成に応じて,この操作は Backup ユーティリティを使用して行うか,または物理的にディスクを移動することによって行います。

    • サテライト・ブート要求をサービスできるように,ブート・サーバのネットワーク・データベースを設定します。この操作を実行するための手順の例については, 第 10.5.3 項 を参照してください。

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

  • CLUSTER_CONFIG コマンド・プロシージャを使用できるのは,そのプロシージャを実行するノードと同じアーキテクチャのクラスタ・ノードを管理する場合だけです。たとえば,Alpha システムから CLUSTER_CONFIG を実行する場合,このプロシージャは Alpha システム・ディスクだけを操作することができ, Alpha システムに対してだけノード管理手順を実行できます。

  • レイヤード製品のクロスアーキテクチャ・インストールはサポートされません。



10.5.3 DECnet の構成

以下の例では,クロスアーキテクチャ・ブートを実行するように DECnet データベースを構成する方法を示しています。この機能は, DECnet for OpenVMS (フェーズ IV) を実行するシステムに対してだけ提供されます。

以下の説明に従って, 例 10-2例 10-3 のコマンド・プロシージャをカスタマイズします。

変更前 変更後
alpha_system_disk または vax_system_disk サーバの適切なディスク名
label サーバのディスクの適切なラベル名
ccc-n サーバ・サーキット名
alpha または vax サテライトの DECnet ノード名
xx.yyyy サテライトの DECnet area.address
aa-bb-cc-dd-ee-ff サテライトのロードで使用されるサテライト上の LAN アダプタのハードウェア・アドレス
satellite_root サテライトのシステム・ディスクのルート (たとえば SYS10)

例 10-2 は,ローカルにマウントされている Alpha システム・ディスクをサービスするように VAX システムを設定する方法を示しています。

例 10-2 VAX ブート・ノードでの Alpha サテライトの定義

 
$! VAX system to load Alpha satellite 
$! 
$!  On the VAX system: 
$!  ----------------- 
$! 
$!  Mount the system disk for MOP server access. 
$! 
$ MOUNT /SYSTEM alpha_system_disk: label ALPHA$SYSD 
$! 
$!  Enable MOP service for this server. 
$! 
$ MCR NCP 
NCP> DEFINE CIRCUIT ccc-n SERVICE ENABLED STATE ON 
NCP> SET CIRCUIT ccc-n STATE OFF 
NCP> SET CIRCUIT ccc-n ALL 
NCP> EXIT 
$! 
$!  Configure MOP service for the ALPHA satellite. 
$! 
$ MCR NCP 
NCP> DEFINE NODE alpha ADDRESS xx.yyyy
NCP> DEFINE NODE alpha HARDWARE ADDRESS aa-bb-cc-dd-ee-ff
NCP> DEFINE NODE alpha LOAD ASSIST AGENT SYS$SHARE:NISCS_LAA.EXE 
NCP> DEFINE NODE alpha LOAD ASSIST PARAMETER ALPHA$SYSD:[satellite_root.] 
NCP> DEFINE NODE alpha LOAD FILE APB.EXE 
NCP> SET NODE alpha ALL 
NCP> EXIT 

例 10-3 は,ローカルにマウントされている VAX システム・ディスクをサービスするように, Alpha システムを設定する方法を示しています。

例 10-3 Alpha ブート・ノードでの VAX サテライトの定義

 $! Alpha system to load VAX satellite 
 $! 
 $!  On the Alpha system: 
 $!  -------------------- 
 $! 
 $!  Mount the system disk for MOP server access. 
 $! 
 $ MOUNT /SYSTEM vax_system_disk: label VAX$SYSD 
 $! 
 $!  Enable MOP service for this server. 
 $! 
 $ MCR NCP 
 NCP> DEFINE CIRCUIT ccc-n SERVICE ENABLED STATE ON 
 NCP> SET CIRCUIT ccc-n STATE OFF 
 NCP> SET CIRCUIT ccc-n ALL 
 NCP> EXIT 
 $! 
 $!  Configure MOP service for the VAX satellite. 
 $! 
 $ MCR NCP 
 NCP> DEFINE NODE vax ADDRESS xx.yyyy
 NCP> DEFINE NODE vax HARDWARE ADDRESS aa-bb-cc-dd-ee-ff
 NCP> DEFINE NODE vax TERTIARY LOADER SYS$SYSTEM:TERTIARY_VMB.EXE 
 NCP> DEFINE NODE vax LOAD ASSIST AGENT SYS$SHARE:NISCS_LAA.EXE 
 NCP> DEFINE NODE vax LOAD ASSIST PARAMETER VAX$SYSD:[satellite_root.] 
 NCP> SET NODE vax ALL 
 NCP> EXIT 

その後,サテライトをブートするには,以下の操作を行います。

  1. サーバの特権付きアカウントから適切なコマンド・プロシージャを実行します。

  2. コマンド・プロシージャに前に入力したハードウェア・アドレスによって表されるアダプタを介して,サテライトをブートします。


目次 索引

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