お世話になります。Webサーバ管理者です。

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

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

回答の条件
  • 1人1回まで
  • 登録:
  • 終了:2015/02/15 18:39:19
※ 有料アンケート・ポイント付き質問機能は2023年2月28日に終了しました。

ベストアンサー

id:JULY No.1

回答回数966ベストアンサー獲得回数247

ポイント2000pt

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

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

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

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

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

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

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

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

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

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

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

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

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

他2件のコメントを見る
id:JULY

ログをどう監視し、どう役立てるかは、ある意味、永遠のテーマですね。これといった正解は無くて、最後は、目的に応じて各自が工夫、となってしまいます。

「err」という文字列で抽出して、というのも、それで十分の場合もあれば、不十分な場合もあって、ログ全体を見ながら、適宜調節していく、ということは大切だと思います。

libwrap のログが messages 多くて、ということであれば、ログファイルを分けることをおすすめします。

CentOS Ver.6 以降であれば、syslog サーバとして rsyslog が使われているので、プログラム名やメッセージの内容によってログファイルを分けたりすることもできますし、特定の条件に合致したログに対してメールを飛ばすこともできます。

余裕があれば、別途ログサーバを用意して、そっちにログを飛ばすようにしておけば、今回のケースのように、対象サーバにログインできなくても、直前までどんなログが出力されていたかを知ることができます。

私も全然使いこなしていませんが、rsyslog は結構、高機能で、たとえば、httpd のログのように syslog サーバを介さないログファイルも扱えたりもします。巷では fluentd を使ったログの集約、というのが流行っていますが、rsyslog だけでも、かなり高度なことができるので、いろいろトライしてみると良いと思います。

2015/02/15 12:37:53
id:digital-server

大変実践的で的確なアドバイスありがとうございました。
早速rsyslog試してみたいと思います。
ありがとうございました。

2015/02/15 18:38:43

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

回答リクエストを送信したユーザーはいません