人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

お世話になります。Webサーバ管理者です。
CentOS6.5、Plesk11で専用サーバを(G?O社)レンタルし、
ホスティングを提供しております。
筐体は1年前に新規で契約したのですが、
先日、主要サービスが停止し、SSH、シリアルコンソールでもアクセスできなくなり、
止むを得ず、データセンタースタッフの方で電源再投入をしてもらいました。
ところが、再起動することができず、多くのホスティング利用者に大きな迷惑をかけてしまいました。(結局バックアップデータで別筐体に移動させ事態は収束)

そこで質問させて頂きたいのですが、
【1】Linuxサーバが再起動できるかどうか
事前にシミュレーションする方法はありますでしょうか?
【2】Linuxサーバが死にそうか?確認する方法はありますでしょうか?
(あいまいな表現ですみません)
【3】ホスティングサーバの運用として
SNMP等での死活・負荷監視、ログチェック、SPAM対策、セキュリティパッチ
以外に行うべきことについてご教示頂けませんでしょうか?


●質問者: digital-server
●カテゴリ:コンピュータ インターネット
○ 状態 :終了
└ 回答数 : 1/1件

▽最新の回答へ

1 ● JULY
●2000ポイント ベストアンサー

【1】Linuxサーバが再起動できるかどうか事前にシミュレーションする方法はありますでしょうか?

無いです。強いて言うと、仮想マシン上であれば、その仮想マシンのコピーを作って、ということができなくは無いですが、物理マシン上であれば無いです。

電源を強制的に落としたのであれば、起動できなくなる可能性が高くなるのは仕方がないので、そこは覚悟するしか無いです。

【2】Linuxサーバが死にそうか?確認する方法はありますでしょうか?

OS が完全に停止するような、ソフトウェア的なトラブルの前兆を捉えるとすれば、メモリの利用率、プロセス数、CPU の負荷状況、ルートパーティションの使用率、といったあたりをモニターすることは考えられます。

ただ、短時間で急激な変化を起こすような場合では、その前兆を捉えることはできないので、必ず確認できるわけではありません。

ハードウェア上のトラブルは、こういった「借り物の専用サーバ」の場合、ユーザが監視するのか、サービス提供が監視するのかわかりませんが、ユーザ側での監視には制限があるかもしれません。

通常、サーバのメーカーから、ハードウェア状態を SNMP 経由で取得するためのソフトウェアが配布されているのですが、「借り物の専用サーバ」でそういったものが利用できるかわかりません。

【3】ホスティングサーバの運用として
SNMP等での死活・負荷監視、ログチェック、SPAM対策、セキュリティパッチ
以外に行うべきことについてご教示頂けませんでしょうか?

真剣に可用性を考えるであれば、本当はクラスタリングをするのが王道です。ただ、借りている専用サーバ、という制約では、実現は難しいと思います。

先述のハードウェア状態の監視もそうですが、ハードウェア上のトラブルに対しては、借り物の専用サーバでは限界がある、という感じがします。であれば、いっそ AWS のような IaaS サービスの方が、ハードウェアの心配をユーザ側が心配する必要が無い、というメリットがあると思います。

ハードウェア上のトラブルは無視するとして、ソフトウェア上のトラブルのことを考えると、リソース監視は強化した方が良いと思います。メモリやディスクの利用状況は押さえておきたいところです。

あとは、きちんとログを見ることでしょうか。本当は、今回のトラブルがどういった原因で発生したのか、きちんとログを解析したり、そもそも、きちんとログが取れるように設定しておく、ということが大切だと思います。


digital-serverさんのコメント
ご回答ありがとうございます。大変参考になりました。 ログのチェックですね。 もしよろしければ、合わせて細かい部分でご教示頂ければと思うのですが... FTP、SSHはIP制限で自分しか利用できないようにしているため、 メールログとmessagesだけチェックしています。 過去に別筐体でmessagesにHDDエラーが出ていた経験があったので 「err」の部分一致で抽出するスクリプトで簡便にチェックしていましたが、 こんなチェックでは不十分でしょうか? 時々は念入りに見て、サービスの再起動の頻度なども見てはいましたが... このところは、メールSPAM(パスワードアタック等)が、とんでもなく多い為、 メールログ

digital-serverさんのコメント
から怪しいものはHosts.denyでブロックするスクリプトを使ってブロック、 そのせいで、libwrap・・・のメッセージでmessagesが埋め尽くされています。

JULYさんのコメント
ログをどう監視し、どう役立てるかは、ある意味、永遠のテーマですね。これといった正解は無くて、最後は、目的に応じて各自が工夫、となってしまいます。 「err」という文字列で抽出して、というのも、それで十分の場合もあれば、不十分な場合もあって、ログ全体を見ながら、適宜調節していく、ということは大切だと思います。 libwrap のログが messages 多くて、ということであれば、ログファイルを分けることをおすすめします。 CentOS Ver.6 以降であれば、syslog サーバとして rsyslog が使われているので、プログラム名やメッセージの内容によってログファイルを分けたりすることもできますし、特定の条件に合致したログに対してメールを飛ばすこともできます。 余裕があれば、別途ログサーバを用意して、そっちにログを飛ばすようにしておけば、今回のケースのように、対象サーバにログインできなくても、直前までどんなログが出力されていたかを知ることができます。 私も全然使いこなしていませんが、rsyslog は結構、高機能で、たとえば、httpd のログのように syslog サーバを介さないログファイルも扱えたりもします。巷では fluentd を使ったログの集約、というのが流行っていますが、rsyslog だけでも、かなり高度なことができるので、いろいろトライしてみると良いと思います。

digital-serverさんのコメント
大変実践的で的確なアドバイスありがとうございました。 早速rsyslog試してみたいと思います。 ありがとうございました。
関連質問

●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ