IT MEMO: 2009年8月アーカイブ
トラブル続きではあるのですが、ふと思う、自分の運の強いところは、自分が、居る時もしくは、帰れる状況下で、トラブルが発生してくれているところ。
人に任せたい気持ちも、山々なのですが、ややこしいサーバーが多すぎて、とりあえず、バイトとか、派遣では、任せられないんですよね。
会社の人材は、東京にほぼ集中しちゃってるし^^;
でも、まー、そう言う意味では、運は強いと思うので、強い間に、色々解決したいなと、思っています
人に任せたい気持ちも、山々なのですが、ややこしいサーバーが多すぎて、とりあえず、バイトとか、派遣では、任せられないんですよね。
会社の人材は、東京にほぼ集中しちゃってるし^^;
でも、まー、そう言う意味では、運は強いと思うので、強い間に、色々解決したいなと、思っています
契約している会社で定期的にNICが落ちる会社がある
既に、かなり変な構成になっているので、ハードウェアの保守の保証外、、、
とりあえず、全くアプリ構成、仕様を知らないので、トラブルが来たらネットワークの再起動で対応してます。
しかし、今日、そのネットワークの再起動で、いつも落ちる側ではない方の、NICが落ちました
ちなみに
eth0 は外部で、外部に公開ウェブサーバーとして動作
eth1 は内部で、MSSQLサーバーと通信
ログ見るとこんな感じ
Aug 2 13:19:00 xxxxxxx ifdown: ifcfg-eth1: line 11: /root: is a directory
Aug 2 13:19:00 xxxxxxx kernel: eth1: interrupt 5 taken in poll
Aug 2 13:45:41 xxxxxx kernel: NETDEV WATCHDOG: eth1: transmit timed out
Aug 2 13:45:41 xxxxxx kernel: eth1: TX Timeout
とりあえず、一番上の行は、解決
それ以外は、意味がわかりませんw
ま、NIC1側が内部でとりあえず変な通信しているので、そっちで何か引き起こしているのは、間違いないと思うのですが。全てが、丸投げで、自社でも、仕様書が無い状況なので、、、、、
さて、どうなるやら。。。。
既に、かなり変な構成になっているので、ハードウェアの保守の保証外、、、
とりあえず、全くアプリ構成、仕様を知らないので、トラブルが来たらネットワークの再起動で対応してます。
しかし、今日、そのネットワークの再起動で、いつも落ちる側ではない方の、NICが落ちました
ちなみに
eth0 は外部で、外部に公開ウェブサーバーとして動作
eth1 は内部で、MSSQLサーバーと通信
ログ見るとこんな感じ
Aug 2 13:19:00 xxxxxxx ifdown: ifcfg-eth1: line 11: /root: is a directory
Aug 2 13:19:00 xxxxxxx kernel: eth1: interrupt 5 taken in poll
Aug 2 13:45:41 xxxxxx kernel: NETDEV WATCHDOG: eth1: transmit timed out
Aug 2 13:45:41 xxxxxx kernel: eth1: TX Timeout
とりあえず、一番上の行は、解決
それ以外は、意味がわかりませんw
ま、NIC1側が内部でとりあえず変な通信しているので、そっちで何か引き起こしているのは、間違いないと思うのですが。全てが、丸投げで、自社でも、仕様書が無い状況なので、、、、、
さて、どうなるやら。。。。