第 10 章OpenVMS Cluster システムの保守
クラスタが起動され,動作するようになったら,サイト固有の日常の保守操作を行うことができます。たとえば,ディスクのバックアップやユーザ・アカウントの追加,ソフトウェアのアップグレードやインストール,フィードバック・オプション付きの AUTOGEN の定期的な実行,システムのパフォーマンスの監視などを行うことができます。
現在の構成データの記録を管理することも必要です。特に,ハードウェア・コンポーネントやソフトウェア・コンポーネントの変更は記録しておく必要があります。サテライト・ノードを含むクラスタを管理する場合は, LAN の動作を監視することが重要です。
以下の特殊な保守操作が必要になることがあります。
10.1 データとファイルのバックアップ 定期的なシステム管理手順の一部として,OpenVMS Backup ユーティリティを使用して,オペレーティング・システム・ファイル,アプリケーション・ソフトウェア・ファイル,関連ファイルを別のデバイスにコピーしなければなりません。 OpenVMS Cluster で行う一部のバックアップ操作は,シングル OpenVMS システムの場合と同じです。たとえば,使用中のディスクの追加型バックアップや,非共用ディスクのバックアップは同じです。 クラスタで使用するバックアップ・ツールとしては, 表 10-1 に示すものがあります。
定期的なシステム管理手順の一部として,OpenVMS Backup ユーティリティを使用して,オペレーティング・システム・ファイル,アプリケーション・ソフトウェア・ファイル,関連ファイルを別のデバイスにコピーしなければなりません。
OpenVMS Cluster で行う一部のバックアップ操作は,シングル OpenVMS システムの場合と同じです。たとえば,使用中のディスクの追加型バックアップや,非共用ディスクのバックアップは同じです。
クラスタで使用するバックアップ・ツールとしては, 表 10-1 に示すものがあります。
注意: バックアップを実行する時点で書き込みのためにオープンされているファイルは,正しくバックアップされないことがある。
関連項目: メニューを使用する手順については,『OpenVMS インストレーション・ガイド [翻訳版]』と『OpenVMS システム管理者マニュアル』を参照。
アプリケーションやユーザの要件に応じて,バックアップ・プロセスは定期的に実行するようにしてください。バックアップ・スケジュールを作成する際は,ユーザとアプリケーションによるシステムの利用が少ない時刻にバックアップを行うように調整してください。
関連項目: OpenVMS Backup ユーティリティの詳細については,『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル (上巻 ) 』を参照してください。 10.2 OpenVMS オペレーティング・システムの更新 OpenVMS オペレーティング・システムを更新する場合は, 表 10-2 の手順に従います。
OpenVMS オペレーティング・システムを更新する場合は, 表 10-2 の手順に従います。
関連項目: 詳細については,適切な OpenVMS アップグレードおよびインストール・マニュアルを参照してください。 10.2.1 ローリング・アップグレード OpenVMS オペレーティング・システムでは,複数のオペレーティング・システムを使用している OpenVMS Cluster システムは,システム・ソフトウェアをアップグレードする間もサービスを提供できます。このプロセスを ローリング・アップグレード と呼びます。これは,すべてのノードがアップグレードされるまで,各ノードが順にアップグレードされ,リブートされるからです。 システムを 1 つのシステム・ディスクから 2 つ以上のシステム・ディスクに移行しなければならない場合は,以下の操作を行います。
OpenVMS オペレーティング・システムでは,複数のオペレーティング・システムを使用している OpenVMS Cluster システムは,システム・ソフトウェアをアップグレードする間もサービスを提供できます。このプロセスを ローリング・アップグレード と呼びます。これは,すべてのノードがアップグレードされるまで,各ノードが順にアップグレードされ,リブートされるからです。
システムを 1 つのシステム・ディスクから 2 つ以上のシステム・ディスクに移行しなければならない場合は,以下の操作を行います。
ここに示した各関連項目は,システム・ディスクを追加し,複数のシステム・ディスクに共通のユーザ環境を準備することにより,キュー・データベース,ライトリスト,プロキシ,メール,その他のファイルなどの共用システム・ファイルを 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.8.2 項 を参照してください )。このファイルは,サテライトを追加または削除するときや, Ethernet ハードウェア・アドレスを変更するたびに更新されます。このファイルには,サテライトの重要なすべてのネットワーク構成データが格納されています。 サイトで予測しない状況が発生して,構成データが失われた場合は, NETNODE_UPDATE.COM を使用して復元できます。また,個々のサテライトのデータを取得しなければならない場合も,このファイルを読み込むことができます。ファイルはときどき編集して,古くなったエントリを削除しておく必要があります。 例 10-1 は,サテライト EUROPA と GANYMD がクラスタに追加された後,ファイルの内容がどのようになるかを示しています。
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.8.2 項 を参照してください )。このファイルは,サテライトを追加または削除するときや, Ethernet ハードウェア・アドレスを変更するたびに更新されます。このファイルには,サテライトの重要なすべてのネットワーク構成データが格納されています。 サイトで予測しない状況が発生して,構成データが失われた場合は, NETNODE_UPDATE.COM を使用して復元できます。また,個々のサテライトのデータを取得しなければならない場合も,このファイルを読み込むことができます。ファイルはときどき編集して,古くなったエントリを削除しておく必要があります。 例 10-1 は,サテライト EUROPA と GANYMD がクラスタに追加された後,ファイルの内容がどのようになるかを示しています。
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.8.2 項 を参照してください )。このファイルは,サテライトを追加または削除するときや, Ethernet ハードウェア・アドレスを変更するたびに更新されます。このファイルには,サテライトの重要なすべてのネットワーク構成データが格納されています。 サイトで予測しない状況が発生して,構成データが失われた場合は, NETNODE_UPDATE.COM を使用して復元できます。また,個々のサテライトのデータを取得しなければならない場合も,このファイルを読み込むことができます。ファイルはときどき編集して,古くなったエントリを削除しておく必要があります。 例 10-1 は,サテライト EUROPA と GANYMD がクラスタに追加された後,ファイルの内容がどのようになるかを示しています。
構成レコードには,少なくとも以下の情報を含まなければなりません。
10.4.2 サテライト・ネットワーク・データ CLUSTER_CONFIG.COM を初めて実行してサテライトを追加する場合,このプロシージャはブート・サーバの SYS$SPECIFIC:[SYSMGR] ディレクトリに NETNODE_UPDATE.COM ファイルを作成します ( 共通環境クラスタの場合は,このファイル名を SYS$COMMON:[SYSMGR] ディレクトリに変更する必要があります。 第 5.8.2 項 を参照してください )。このファイルは,サテライトを追加または削除するときや, Ethernet ハードウェア・アドレスを変更するたびに更新されます。このファイルには,サテライトの重要なすべてのネットワーク構成データが格納されています。 サイトで予測しない状況が発生して,構成データが失われた場合は, NETNODE_UPDATE.COM を使用して復元できます。また,個々のサテライトのデータを取得しなければならない場合も,このファイルを読み込むことができます。ファイルはときどき編集して,古くなったエントリを削除しておく必要があります。 例 10-1 は,サテライト EUROPA と GANYMD がクラスタに追加された後,ファイルの内容がどのようになるかを示しています。
CLUSTER_CONFIG.COM を初めて実行してサテライトを追加する場合,このプロシージャはブート・サーバの SYS$SPECIFIC:[SYSMGR] ディレクトリに NETNODE_UPDATE.COM ファイルを作成します ( 共通環境クラスタの場合は,このファイル名を SYS$COMMON:[SYSMGR] ディレクトリに変更する必要があります。 第 5.8.2 項 を参照してください )。このファイルは,サテライトを追加または削除するときや, Ethernet ハードウェア・アドレスを変更するたびに更新されます。このファイルには,サテライトの重要なすべてのネットワーク構成データが格納されています。
サイトで予測しない状況が発生して,構成データが失われた場合は, NETNODE_UPDATE.COM を使用して復元できます。また,個々のサテライトのデータを取得しなければならない場合も,このファイルを読み込むことができます。ファイルはときどき編集して,古くなったエントリを削除しておく必要があります。
例 10-1 は,サテライト EUROPA と GANYMD がクラスタに追加された後,ファイルの内容がどのようになるかを示しています。
$ 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$DGA11:<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$DGA11:<SYS11.> define node GANYMD tertiary loader sys$system:tertiary_vmb.exe
関連項目: DECnet-Plus の NCL コマンドについては,DECnet-Plus のマニュアルを参照してください。 10.5 OPCOM メッセージの制御 サテライトをクラスタに追加した状態では, OPCOM (Operator Communication Manager) は以下のデフォルト設定になっています。 OpenVMS Cluster 構成で,ワークステーションを除く他のすべてのシステム: OPA0: がすべてのメッセージ・クラスに対して有効に設定されます。 ログ・ファイル SYS$MANAGER:OPERATOR.LOG がすべてのクラスに対してオープンされます。 OpenVMS Cluster 構成内のワークステーションの場合, OPCOM プロセスが実行されている場合でも, OPA0: は有効に設定されません。 ログ・ファイルはオープンされません。 10.5.1 OPCOM のデフォルト設定の変更 表 10-3 は,コマンド・プロシージャ SYS$MANAGER:SYLOGICALS.COM で以下のシステム論理名を定義して,OPCOM のデフォルト設定を変更する方法を示しています。
サテライトをクラスタに追加した状態では, OPCOM (Operator Communication Manager) は以下のデフォルト設定になっています。
10.5.1 OPCOM のデフォルト設定の変更 表 10-3 は,コマンド・プロシージャ SYS$MANAGER:SYLOGICALS.COM で以下のシステム論理名を定義して,OPCOM のデフォルト設定を変更する方法を示しています。
表 10-3 は,コマンド・プロシージャ SYS$MANAGER:SYLOGICALS.COM で以下のシステム論理名を定義して,OPCOM のデフォルト設定を変更する方法を示しています。
$ DEFINE/SYSTEM OP$OPA0_CLASSES CENTRAL,DISKS,TAPE $ DEFINE/SYSTEM OP$OPA0_CLASSES "CENTRAL,DISKS,TAPE" $ DEFINE/SYSTEM OP$OPA0_CLASSES "CENTRAL,DISKS",TAPE
OPC$OPA0_ENABLE が定義されていない場合でも, OPC$OPA0_CLASSES を定義できる。この場合,クラスは,有効に設定されているどのオペレータ・コンソールに対しても使用されるが,オペレータ・コンソールを有効に設定するかどうかは,デフォルトを使用して判断される。
10.5.2 例以下の例では,OPC$OPA0_CLASSES システム論理名を使用して,有効に設定するオペレータ・クラスを定義する方法を示しています。以下のコマンドを使用すると,SECURITY クラス・メッセージは OPA0 に表示されなくなります。
$ DEFINE/SYSTEM OPC$OPA0_CLASSES CENTRAL,PRINTER,TAPES,DISKS,DEVICES, - _$ CARDS,NETWORK,CLUSTER,LICENSE,OPER1,OPER2,OPER3,OPER4,OPER5, - _$ OPER6,OPER7,OPER8,OPER9,OPER10,OPER11,OPER12
大規模なクラスタでは,状態遷移 (コンピュータがクラスタに追加されたり,クラスタから削除される状態) で,ブート・サーバのコンソール・デバイスに多くの複数行の OPCOM メッセージが生成されます。 DCL コマンド REPLY/DISABLE=CLUSTER を適切なサイト固有のスタートアップ・コマンド・ファイルに指定するか,またはシステム管理者のアカウントから会話方式でコマンドを入力することにより,このようなメッセージが表示されないようにすることができます。 10.6 クラスタのシャットダウン
SYSMAN ユーティリティの SHUTDOWN コマンドには, OpenVMS Cluster のコンピュータをシャットダウンするために, 5 つのオプションが用意されています。
これらのオプションについて,以下で説明します。 10.6.1 NONE オプション デフォルトの SHUTDOWN オプションである NONE を選択すると,シャットダウン・プロシージャはスタンドアロン・コンピュータをシャットダウンする場合の通常の操作を実行します。間もなくクラスタに再び追加する予定のあるコンピュータをシャットダウンする場合は,デフォルト・オプション NONE を指定できます。その場合,そのコンピュータがクラスタに間もなく再追加されるものと,オペレーティング・システムが判断するため,クラスタ・クォーラムは調整されません。 "Shutdown options [NONE]:" プロンプトに対する応答として, DISABLE_AUTOSTART=n オプションを指定できます。ただし,n は,シャットダウン・シーケンスで自動起動キューが無効に設定されるまでの分数です。詳細については, 第 7.13 節 を参照してください。 10.6.2 REMOVE_NODE オプション 長時間にわたってクラスタに再び追加される予定のないコンピュータをシャットダウンする場合は, REMOVE_NODE オプションを使用します。たとえば,コンピュータに必要な新しいハードウェアが納入されるのを待っている場合や,コンピュータを当面スタンドアロン操作用に使用する場合などがあります。 REMOVE_NODE オプションを使用する場合は,削除されるコンピュータのボーツがクォーラム値に加算されないことを反映するために,クラスタの残りの部分のアクティブ・クォーラムが現在の値より小さい値に調整されます。シャットダウン・プロシージャは, SET CLUSTER/EXPECTED_VOTES コマンドを実行することにより,クォーラムを再調整します。その場合, 第 10.11 節 で説明する通常の制約が適用されます。 注意: システム管理者は,新しい構成を反映するように, OpenVMS Cluster の他のコンピュータで EXPECTED_VOTES システム・パラメータを変更しなければなりません。
デフォルトの SHUTDOWN オプションである NONE を選択すると,シャットダウン・プロシージャはスタンドアロン・コンピュータをシャットダウンする場合の通常の操作を実行します。間もなくクラスタに再び追加する予定のあるコンピュータをシャットダウンする場合は,デフォルト・オプション NONE を指定できます。その場合,そのコンピュータがクラスタに間もなく再追加されるものと,オペレーティング・システムが判断するため,クラスタ・クォーラムは調整されません。
"Shutdown options [NONE]:" プロンプトに対する応答として, DISABLE_AUTOSTART=n オプションを指定できます。ただし,n は,シャットダウン・シーケンスで自動起動キューが無効に設定されるまでの分数です。詳細については, 第 7.13 節 を参照してください。 10.6.2 REMOVE_NODE オプション
長時間にわたってクラスタに再び追加される予定のないコンピュータをシャットダウンする場合は, REMOVE_NODE オプションを使用します。たとえば,コンピュータに必要な新しいハードウェアが納入されるのを待っている場合や,コンピュータを当面スタンドアロン操作用に使用する場合などがあります。
REMOVE_NODE オプションを使用する場合は,削除されるコンピュータのボーツがクォーラム値に加算されないことを反映するために,クラスタの残りの部分のアクティブ・クォーラムが現在の値より小さい値に調整されます。シャットダウン・プロシージャは, SET CLUSTER/EXPECTED_VOTES コマンドを実行することにより,クォーラムを再調整します。その場合, 第 10.11 節 で説明する通常の制約が適用されます。
注意: システム管理者は,新しい構成を反映するように, OpenVMS Cluster の他のコンピュータで EXPECTED_VOTES システム・パラメータを変更しなければなりません。