| 前へ | 次へ | 目次 | 索引 |
クラスタが起動され，動作するようになったら，サイト固有の日常の保守操作を行うことができます。たとえば，ディスクのバックアップやユーザ・アカウントの追加，ソフトウェアのアップグレードやインストール，フィードバック・オプション付きの AUTOGEN の定期的な実行，システムのパフォーマンスの監視などを行うことができます。
現在の構成データの記録を管理することも必要です。特に，ハードウェア・コンポーネントやソフトウェア・コンポーネントの変更は記録しておく必要があります。サテライト・ノードを含むクラスタを管理する場合は， LAN の動作を監視することが重要です。
以下の特殊な保守操作が必要になることがあります。
定期的なシステム管理手順の一部として，OpenVMS Backup ユーティリティを使用して，オペレーティング・システム・ファイル，アプリケーション・ソフトウェア・ファイル，関連ファイルを別のデバイスにコピーしなければなりません。
OpenVMS Cluster で行う一部のバックアップ操作は，シングル OpenVMS システムの場合と同じです。たとえば，使用中のディスクの追加型バックアップや，非共用ディスクのバックアップは同じです。
クラスタで使用するバックアップ・ツールとしては， 表 10-1 に示すものがあります。
| ツール | 使い方 |
|---|---|
| オンライン・バックアップ | 以下のディスクをバックアップするために，実行中のシステムから使用する。
警告: バックアップを実行する時点で書き込みのためにオープンされているファイルは，正しくバックアップされないことがある。 |
| メニュー・ドリブンまたは +スタンドアロン BACKUP | 以下のいずれかの方法を使用する。
|
アプリケーションやユーザの要件に応じて，バックアップ・プロセスは定期的に実行するようにしてください。バックアップ・スケジュールを作成する際は，ユーザとアプリケーションによるシステムの利用が少ない時刻にバックアップを行うように調整してください。
関連項目: OpenVMS Backup ユーティリティの詳細については，『Compaq OpenVMS システム管理ユーティリティ・リファレンス・マニュアル (上巻 ) 』を参照してください。
10.2 OpenVMS オペレーティング・システムの更新
OpenVMS オペレーティング・システムを更新する場合は， 表 10-2 の手順に従います。
| ステップ | 操作 |
|---|---|
| 1 | スタンドアロン BACKUP を使用して，システム・ディスクをバックアップする。 |
| 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 レコード情報
構成レコードには，少なくとも以下の情報を含まなければなりません。
関連項目: クラスタ・システム・パラメータについては， 付録 A を参照。
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 サテライトのブート
クロスアーキテクチャ・ブート機能を使用する場合は，以下のガイドラインに従ってください。
以下の例では，クロスアーキテクチャ・ブートを実行するように 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 |
その後，サテライトをブートするには，以下の操作を行います。
| 前へ | 次へ | 目次 | 索引 |