NASストレージ障害によるLinuxシステムリカバリの一例

NASオペレーティングシステムのカーネルはLinuxで、持っているストレージは16枚のハードディスクがあって、全部で2つのグループに分けて、各グループはRAID 5をして、Linuxオペレーティングシステムは正常に起動することができなくて、サービスがcupsまで起動してそこで停止して、ボタンctrl+cは強制的に切断しても応答していないで、ハードディスクの状態を見て、すべて正常で、警報あるいは警告現象がありません。

これらの現象により,まずNASハードウェアは問題ないと判断し,NASメモリディスクも正常であるべきであり,現在Linuxが起動できないのはLinuxシステム自体に問題があるはずであるため,まずLinuxシステムから調査を行う.

1、初回処理プロセス

NASシステム自体はLinuxカーネルにファイルシステム管理ソフトウェアを搭載しており、管理ソフトウェアはシステムディスク、システムサービス、ファイルシステムなどを管理し、操作することができる。通常、Linuxカーネルに基づくNASシステムはinit 3またはinit 5モードに起動すべきである。NASはLinuxのカーネルモジュールといくつかの簡単なサービスしか使用していないため、だからNASの下のLinuxシステムはきっとinit 3モードの下で起動すると判断して、それでは今マルチユーザーの文字のインターフェースの下で起動することができなくて、どうしてLinuxを直接単一のユーザー(init 1)モードの下に入らせませんか、単一のユーザーモードの下でただシステムの必要ないくつかのサービスを有効にするだけで、cpusサービスはアプリケーションのレベルで、きっと“init 1”モードの下で起動しないため、これによりcupsが起動できないという問題が回避されるので,次の作業はLinuxのシングルユーザモードに入ることである.

多くのLinuxリリースでは、起動したブートインタフェースで関連する設定でシングルユーザモードに入ることができ、NASの起動手順を確認することで、このLinuxシステムがRHEL/centosリリースと極めて類似していると基本的に判断できるので、RHEL/centosでシングルユーザモードに入る方法を試してみましょう。

RHEL/centosがシングルユーザモードに入るのは簡単で、システムがブートウェルカムインタフェースに起動して、eを押して、それから正しいカーネルブートオプションを編集して、一番後ろに「single」オプションを加えて、最後に直接「b」を押してシングルユーザに入ることができます。

次に、NASを再起動し、ハードウェアセルフテストを開始し、Linuxを起動し、このNASの起動ウェルカムインタフェースを待っていたが、ウェルカムインタフェースが出てこないまま、カーネルミラーに直接入り、カーネルをロードする段階になった。カーネルガイドインタフェースがなく、どのようにシングルユーザーに入るか、簡単に考えた結果、それともハードウェアの検出が終わった後に直接キーボードの“e”を押すことを決定して、奇跡は現れて、また本当にできて、NASはカーネルのガイドのインターフェースに入って、簡単に観察することを通じて(通って)、第2の正にガイドするカーネルのオプションを発行して、そこでキーボードの上下のキーを移動して、このカーネルを選択して、それからボタンの“e”で、カーネルのガイドの編集のインターフェースに入って、この行の一番後ろで、「single」を押して、戻るキーを押して、前のインタフェースに戻り、「b」を押して単一のユーザーの誘導を開始し、1分後、システムは願い通りに単一のユーザーの下のshellコマンドラインに入った。

シングルユーザモードに入ると、できることが多くなります。まず、cupsサービスをマルチユーザモードで自己起動して閉じ、コマンドを実行します。

chkconfig --levle 35 cups off

実行に成功したら、システムを再起動してマルチユーザモードに入り、システムが正常に起動できるかどうかを確認します。

2、第二次処理プロセス

cupsサービスを起動して起動して閉じた後、NASを再起動して、問題が依然としてあることを発見して、NASはやはりcupsサービスに起動してそこで停止して、まさか上の命令は実行して成功していませんか?cupsサービスの起動が禁止されているのに、どうして起動したのですか?そこで、NASを再起動し続け、再びシングルユーザーモードに入り、問題がどこにあるのかを見てみましょう。

シングルユーザーに入ってから、再度chkconfigコマンドを実行しても、依然として成功することができます。cupsサービスに問題があるのか、まずプロファイルを見て、以下のコマンドを実行します。

vi /etc/cups/cupsd.conf

ここで問題が見つかりましたviはcupsdを開きます。confでは、「write file in swap」というメッセージが表示されます。ファイルは実在しているのに、仮想メモリとは何か考えてみると、NASデバイスのLinuxシステムパーティションが正しくマウントされていない可能性があります。そのため、シングルユーザーに入ると、すべてのファイルが仮想メモリに格納されます。検証は非常に簡単です。「df」コマンドを実行して確認すればいいのです。次の図に示します。

ここから、Linuxのシステムパーティションはマウントされていないことがわかります。「fdisk-l」でディスクパーティションの状態を確認し、次の図のように出力します。

出力から分かるように、NASのシステムディスクは/dev/sdaであり、/dev/sda 1と/dev/sda 2の2つのシステムパーティションのみが区分されているが、データディスクはRAID 5で完了しており、システム上のデバイスIDはそれぞれ/dev/sdb 1と/dev/sdc 1であり、単一ユーザがデフォルトでNASディスクをマウントしていないため、ここではNASのシステムディスクを手動でマウントし、以下のコマンドを実行する。

 [root@NASserver ~]#mount /dev/sda2 /mnt

[root@NASserver ~]#mount /dev/sda1 /opt

ここの/mnt、/optは勝手にマウントされたディレクトリですが、他の空のディレクトリにマウントして、マウントが完了し、それぞれこのディレクトリに入って内容を見てみましょう。下図のように:

この2つのコンテンツの表示により、/dev/sda 2パーティションはLinuxのルートパーティションであり、/dev/sda 1は/bootパーティションであるべきであると初歩的に判断した。パーティションがマウントされました。dfコマンドを再度実行してマウント状況を確認します。下図に示します。

ここまで、問題を発見しました。/dev/sda 2ディスクパーティションには使用可能なディスク領域がありませんが、このパーティションはNASシステムのルートパーティションであり、ルートパーティションには空間がありません。システムの起動に問題があるに違いありません。

次に、前述の例に考えてみると、システムcupsサービスは起動時に起動ログをルートパーティションに書き、ルートパーティションはスペースがないためログを書くことができなくなり、その結果、cupsサービスが起動できなくなったため、NASシステムがcupsサービスを起動するたびに停止した原因が明らかになった。

NASシステムにはルートパーティションと/bootパーティションしかないため、システムによって生成された関連ログはルートパーティションに格納され、ルートパーティションがいっぱいになりました。まずクリーンアップできるのは/varディレクトリの下のシステム関連ログファイルです。通常、クリーンアップできるディレクトリには/var/logがあり、以下のコマンドで/var/logログディレクトリがディスク領域サイズを占めていることを確認します。

[root@NASserver ~]#  du -sh /var/log

50.1G    /var/log

コマンド出力により/var/logディレクトリがルートパーティションの70%しか占めていない空間を発見し、このディレクトリの下のログファイルを整理するとルートパーティション空間の大部分を解放し、整理を完了し、NASシステムを再起動し、システムcupsサービスが正常に起動し、NASサービスも正常に起動したことを発見した。

以上、NASストレージ障害によるLinuxシステムのリカバリ事例のすべてのプロセスについて説明しました。読んでくれてありがとう。皆さんの役に立つことを望んでいます。引き続き注目してください。私たちはもっと優秀な文章を分かち合うように努力します。