Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP-UX   >  Knowledge-on-Demand

逆引きUNIXメンテナンス・ガイド

〜こんな時、どうするの?Solaris経験者もこれで安心〜
システム対策編
HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
逆引きUNIXメンテナンス・ガイド- システム対策編 -
逆引き
UNIXメンテナンス・ガイド
- システム管理編 -
パーティションや
論理ボリュームの管理
ユーザー管理
- システム対策編 -
障害を検出する
トラブルを解決する
ページ:  戻る   |   1   2

トラブルを解決する

ミラーディスクを復旧させるには?

ミラーされているボリュームから障害が起きたハードディスクを切り離し、ディスクを交換した後、ミラーを再構成するという手順になる。壊れたディスクは/dev/disk/disk14と仮定して話を進めていく。

まず、pvchangeコマンドを使って/dev/disk/disk14をボリュームから切り離す。

# pvchange -a N /dev/disk/disk14
Warning: Detaching a physical volume reduces the availability of data
within the logical volumes residing on that disk.
Prior to detaching a physical volume or the last available path to it,
verify that there are alternate copies of the data
available on other disks in the volume group.
If necessary, use pvchange(1M) to reverse this operation.
Physical volume "/dev/disk/disk14" has been successfully changed

ホットスワップが可能なディスクであれば、切り離した時点で交換が可能だ。新しいディスクに交換しよう。交換後、scsimgrを使ってLUN WWIDの切り替えを行う。

$ scsimgr replace_wwid -D /dev/rdisk/disk14
scsimgr:WARNING:
Performing replace_wwid on the resource may have some impact on system operation.
Do you really want to replace? (y/[n])? y	
scsimgr: Successfully validated binding of LUN paths with new LUN.

scsimgrコマンドを実行すると、ioscanコマンドで新しいディスクが確認できる。

# ioscan -m lun
Class I Lun H/W Path      Driver  S/W State H/W Type Health  Description
========================================================================
disk 14 64000/0xfa00/0x0  esdisk  NO_HW     DEVICE   offline HP MSA Vol
                  /dev/disk/disk14      /dev/rdisk/disk14
...
disk 28 64000/0xfa00/0x1c esdisk  CLAIMED   DEVICE   online  HP MSA Vol
        0/1/1/1.0x3.0x0
                  /dev/disk/disk28      /dev/rdisk/disk28

上のように新しいディスク/dev/disk/disk28が取り外した/dev/disk/disk14のlunpathに割り当てられている。/dev/disk/disk28を旧ディスクのLUNインスタンスに割り当てよう。

# io_redirect_dsf -d /dev/disk/disk14 -n /dev/disk/disk28

これで新しいディスクが/dev/disk/disk14に割り当てられた。ディスクにLVMの情報を書き戻す。

# vgcfgrestore -n /dev/vg01 /dev/rdisk/disk14
Volume Group configuration has been restored to /dev/rdisk/disk14

あとは、ボリュームに/dev/disk/disk4を接続するだけだ。

# pvchange -a y /dev/disk/disk14
Physical volume "/dev/disk/disk14" has been successfully changed.

以上のような手順でミラー化されたボリュームの復旧が完了する。

壊れた論理ボリュームを復旧させるには?

ディスクの故障などから普及させるためには、利用しているボリュームグループの情報がバックアップされている必要がある。ボリュームグループの構成情報を保存するにはvgcfgbackupコマンドを使う。

# vgcfgbackup /dev/vg00

このようにして保存されている構成情報があるなら、論理ボリュームを普及させるのは難しくない。当然ながら、以降の作業を行う前に壊れてしまった論理ボリュームをアンマウントしておいてほしい。
まず、vgchangeコマンドを使ってボリュームグループをインアクティブにする。

# vgchange -a n /dev/vg00

その上で壊れてしまったディスクを交換する。仮に/dev/disk/disk5としよう。このディスクに構成情報をリストアする。

# vgcfgrestore -n /dev/vg00 /dev/rdisk/disk5

あとはボリュームグループをアクティブに戻せばよい。

# vgchange -a y /dev/vg00

その後、再マウントを行いデータのリストア等を行えばよいわけだ。

ファイルシステムがマウントできない

物理メディアやボリュームがマウントできないとき、もっとも良くある原因はそのファイルシステムをサポートしていないというものだ。HP-UXがサポートしているファイルシステムは、下記などを参照してほしい。

たとえばFATやNTFSのディスクにアクセスするのであれば、Windows機を別途用意してHP-UXにCIFSをインストールし、ネットワークファイルシステムとしてFATやNTFSにアクセスするという方法が考えられる。
その他のHP-UXがサポートしないファイルシステムについても、たとえばLinux機を別途用意してNTFSを経由してLinux機上にマウントしたファイルシステムにアクセスするといった方法で対処するとよいだろう。

NFSで正常にリモートディスクがマウントできない

NFSサーバーのリモートディスクがマウントできない原因は、ネットワーク系のトラブルがもっとも多い。特にチェックする必要があるのは、/etc/resolv.conf、/etc/hostsの2つのファイルだ。
/etc/resolv.confにはDNSの情報を記しておく。DNSが正しく引けなければNFSサーバーの名前を引くことができずマウントに失敗するわけだ。

/etc/resolv.confの例
domain ux.support.net
nameserver 172.16.5.2

一方、DNSで引けないサーバーは/etc/hostsにIPアドレスとホスト名の対応を記しておく必要がある。

/etc/hostsの例
127.0.0.1       localhost       loopback

172.16.0.61     vh1-mp
172.16.0.62     vh2-mp

これら2つのファイルに問題がない場合、NFSサーバー側でマウント可能な権限が与えられていない可能性が大きい。サーバー側の管理者に問い合わせるか、サーバー側の設定を調べてみるとよいだろう。サーバー側の/etc/exportsでNFSのマウントが許可されているかどうかを調べる。また、NFSサーバー側ではポートマッパー(rpc.portmap)が動作していなければならない点にも注意してほしい。

スタートアップスクリプトに問題があるときの対処方法

HP-UXでは/etc/rc.config.d/以下の設定ファイルにより、スタートアップスクリプト(/etc/rcN.d/以下)の実行が制御されている。問題を起こしているスタートアップスクリプトに対応する/etc/rc.config.d/以下のファイルを参照してみるとよい。
/etc/rc.config.d/以下のファイルでは、一般にスタートアップスクリプトで参照する環境変数が設定されている。どのように設定すればトラブルが解消できるかはケースバイケースで一概には言えないが、/etc/rc.config.d/以下のファイルを変更することで何らかの解決が得られるかもしれない。

ゾンビプロセスが大量に発生するときの対処方法

psコマンドで<defunct>と表示されるプロセスがゾンビプロセスだ。ゾンビプロセスが発生する原因はいくつかあるが、通常はそのプロセスが終了しており、親プロセスから破棄される通知を待っているという状況であると考えられる。
そのため、一時的に<defunct>と表示されるプロセスが増えるのは異常ではなく、時間経過ともに<defunct>なプロセスが減っていくようであれば、親プロセスからの終了通知が行われている可能性が高いので、そう神経質になる必要はない。
いつまでたってもなプロセスがなくならず、数がどんどん増えていくというような場合、親プロセスに問題が生じているかもしれない。そのプロセスの親を探し、終了させることで<defunct>なプロセスをなくすことができ、また発生を抑えられるはずだ。
その後、親プロセスに生じている原因を突き止めれば、ゾンビプロセスの大量発生を解決できるだろう。

ディスクのデフラグを行いたい

デフラグの必要性はファイルシステムによっても異なるが、vxfsであればfsadmコマンドを使ってディレクトリエントリの再構成やデータエクステントの再構成を行うことができる。

# fsadm -F vxfs  -D -d directory

上記でdirectoryに指定したディレクトリの断片化の情報が表示されると同時に、再構成が行われる。

# fsadm -F vxfs -E -e mount_point

上記で、データエクステントの断片化の情報が表示され、また再構成が実行できる。

デバイスファイルを消してしまったときの対処方法

mksf、insfコマンドを使って復活できる。たとえば、/dev/disk/以下を消してしまったのであれば、

# mksf -C disk

というように、mksfに-Cオプションでデバイスクラスとしてdiskを指定してやると、/dev/disk以下のデバイスファイルが作成される。
/dev/以下のファイルをすべて再構成するのであれば、insfコマンドを使おう。

# insf -e
最初に戻る 戻る ページ:  戻る   |   1   2

関連情報

先行きの見えない今、Solarisからの移行は必然。乗り遅れる前に、HPが最短ルートをお知らせします。

Solarisで使用するコマンドとHP-UXで使用するコマンドを比較したものです。

特集


その他のコラム(特集)もお読み下さい

 
 

本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

印刷用画面へ
プライバシー ご利用条件・免責事項