いくつかのOpenVZコンテナでDebianSqueezeを使用してサーバーを実行しています。コンテナは主にSqueezeで実行され、一部はLennyで実行され、一部はすでにWheezyに更新されています。ホストはiptablesとDHCPを超えてそれほど多くのことをしません。ファイルサーバー、プロキシ、メールサーバー、Kerberos、LDAPなどはすべてコンテナに入れられます。システムは何年もの間安定して動作し、1年以上の間いくつかのファイアウォールルールを除いて大きな変更はありませんでした。
2日前に突然システムがクラッシュしました。私はそれを再び持ち出すのに多くの問題を抱えていました。最初は、ssh経由でログインできませんでした。 rootログインが拒否されました 'あなたは存在しません。どこかに行って!'ローカルログインは問題ありませんでした。しばらくして、sshが再び機能しました。偶然にも、bash履歴の行を再利用しませんでしたが、新しいコマンドを入力しました。このコマンドは、以前は機能しなかったがクラッシュ前は機能していた行と同じであることが3回チェックされました。
その後、システムは実行されましたが、SYNACKに続いてほとんどのプロトコルのネットワークトラフィックがブロックされました。 DNS、Telnet、SSHは問題ありませんでしたが、残りは混乱していました。暗闇の中で数時間釣りをし、ファイアウォールを数回リロードした後、突然すべてが再びうまくいきました。ログには疑わしいものは何も見つかりませんでしたが、私は法医学の専門家ではありません。
今日、ファイルサーバーのnscdは、コンテナーのクォータのためにLDAPに接続するためにソケットから出ました。今までになかったこと。また、smbdによって要求されたソケットがたくさん(> 30)見られました。
/ var/log/messagesは syslog とまったく同じように見えました。 /var/log/kern.logには、クラッシュの理由に関する次の追加情報があります。
/var/log/kern.log:2950:Sep 19 10:46:57 asgard kernel: [6529441.320086] INFO: task sendmail:32181 blocked for more than 120 seconds.
/var/log/kern.log:2982:Sep 19 10:48:57 asgard kernel: [6529561.324525] INFO: task kdmflush:1932 blocked for more than 120 seconds.
/var/log/kern.log:3005:Sep 19 10:48:57 asgard kernel: [6529561.324694] INFO: task xfssyncd:10162 blocked for more than 120 seconds.
/var/log/kern.log:3027:Sep 19 10:48:57 asgard kernel: [6529561.324934] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:3060:Sep 19 10:49:51 asgard kernel: [6529561.325129] INFO: task imapd:31749 blocked for more than 120 seconds.
/var/log/kern.log:3084:Sep 19 10:49:51 asgard kernel: [6529561.325248] INFO: task cleanup:32194 blocked for more than 120 seconds.
/var/log/kern.log:3106:Sep 19 10:50:57 asgard kernel: [6529681.324028] INFO: task flush-253:3:3216 blocked for more than 120 seconds.
/var/log/kern.log:3142:Sep 19 10:50:57 asgard kernel: [6529681.324224] INFO: task kjournald:6859 blocked for more than 120 seconds.
/var/log/kern.log:3166:Sep 19 10:50:57 asgard kernel: [6529681.324366] INFO: task syslogd:11720 blocked for more than 120 seconds.
/var/log/kern.log:3198:Sep 19 10:50:57 asgard kernel: [6529681.324574] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:7152:Sep 19 19:29:41 asgard kernel: [ 1440.617090] INFO: task sendmail:11892 blocked for more than 120 seconds.
最後の「sendmail」クラッシュは、マシンを再起動した後のものでした。それ以来、そのようなイベントは発生しませんでした。 「imapd」と「postgres」は間違いなく異なるコンテナで実行されます。
ええと、喫煙銃は見当たりませんが、おそらく盲目です。既知の/推定される適切なバックアップからシステムをセットアップすると、非常に正当な理由なしにそれを試すのが非常に困難になります。
次に何をチェックするかアドバイスをいただければ幸いです。
ご協力いただきありがとうございます。
Update:クラッシュの前兆を探すことにもっと力を入れて、syslogで次のことを見つけました:
Sep 19 10:09:56 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]: **WARNING** packet truncated (10490->8232)
Sep 19 10:09:56 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]: **WARNING** packet truncated (17442->8232)
Sep 19 10:11:02 asgard ntop[7965]: **WARNING** packet truncated (11650->8232)
Sep 19 10:11:02 asgard ntop[7965]: **WARNING** packet truncated (10202->8232)
Sep 19 10:11:29 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
Sep 19 10:13:27 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
Sep 19 10:20:33 asgard ntop[7965]: **WARNING** packet truncated (8754->8232)
これは重要ではないと思われますが、まれなイベントのようです。パケットの切り捨ては、2回目のクラッシュの日にのみ存在します。利用可能なすべてのログファイルの他のどこにもありません。
これはDoSのように見えますが、おそらくネットワークから、または侵害されたコンテナの1つの内部から発生しています。
Vmstatを調べて、5秒ごとに継続的に実行します。vmstat5を実行し、リソースが使用されている場所をメモします。 screenを使用して、別のウィンドウでvmstat 60(毎分)を実行することもできます。これにより、長期間にわたって発生したスパイクに気付くことができます。
この状況では、高/スパイクシステムCPU(sy)、高コンテキストスイッチレート(cs)、および高IO(ネットワークとディスクの両方を示します)はDoSを示します。
$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 9584 6820 132432 23256 1 1 136 12 1 1 83 1 15 0 0
0 0 9584 6696 132432 23256 0 0 0 0 20 32 0 0 99 0 1
同時に、ホスト上のネットワークトラフィックを監視します。つまり、ntopをお勧めします。
$ nload -t 10000 -u H eth0
ファイルシステムエラーはないかもしれませんが、D状態(I/Oを待機している)のプロセスが多数あり、カーネルが長い待機を通知しているため、ログに警告が表示されると確信しています。
ディスクI/Oエラーのようです。 fsckを実行し、エラーを確認します。
このエラーは、プロセスがディスクにアクセスするのに長時間(120秒)待機していることを示しています。これは、ディスクがビジー状態でプロセスに応答できない非常に混雑したサーバーで発生します。
Vmstatの下の「Waiting」をチェックすることで確認できます。