Я запускаю сервер, используя Debian Squeeze с несколькими контейнерами OpenVZ. Контейнеры работают в основном Squeeze, некоторые Lenny, а некоторые уже обновлены до Wheezy. Хост не делает ничего, кроме iptables и DHCP. Файловые серверы, прокси, почтовые серверы, Kerberos, LDAP, ... все это помещено в контейнеры. Система работала стабильно в течение многих лет и не претерпела серьезных изменений, за исключением некоторых правил брандмауэра в течение более года.
2 дня назад вдруг система рухнула. У меня было много проблем, когда я снова поднял его. Сначала это не позволило бы мне войти через ssh. вход в систему root запрещен: «Вас не существует. Уходи!' Локальный логин был в порядке. Через некоторое время SSH снова работает. По стечению обстоятельств я не использовал строку из истории bash повторно, а набрал новую команду, которая трижды проверялась, была идентична строке, которая раньше не работала, но работала до сбоя.
Затем система запустилась, но сетевой трафик на большинстве протоколов был заблокирован после SYN ACK. DNS, Telnet и SSH были в порядке, но остальное было беспорядком. После нескольких часов рыбалки в темноте и перезагрузки брандмауэра несколько раз все внезапно прошло хорошо. Я не мог найти ничего подозрительного в журналах - но я не судебный эксперт.
Сегодня nscd файлового сервера вышел из сокетов, чтобы связаться с LDAP из-за квоты контейнера. То, что никогда не случалось раньше. Я также видел много (> 30) сокетов, заявленных smbd.
/ 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' определенно работают в разных контейнерах.
Ну, я не вижу курящего пистолета, но я, вероятно, просто слепой. Настройка системы из известных / предполагаемых хороших резервных копий слишком сильно ударит по мне, чтобы попробовать ее без веских причин.
Буду признателен за любой совет, что проверить дальше.
Спасибо за вашу помощь.
Обновление : прилагая больше усилий в поиске некоторого предварительного курсора сбоя, я нашел следующее в системном журнале:
Я знаю, что это считается некритическим, но это, кажется, редкое событие. Усечение пакетов существует только в день второго сбоя. Нигде во всех доступных лог-файлах.
This looks like DoS, most likely originating from nework or from inside of one of compromised container.
I'd look into vmstat, run it continually every 5 seconds: vmstat 5 and take a note where resources are spent. You can also use screen and run vmstat 60 (every minute) in a separate window - this way you can notice spikes when they happen over longer period of time.
In this situation high/spiking System CPU(sy), high context switch rate (cs) and high IO (it shows both network and disk) will indicate 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
At the same time monitor the network traffic on host, i recommend ntop, ie:
$ nload -t 10000 -u H eth0
0
Shain Padmajan
It looks like an Disk I/O error. Run fsck and check for errors.
Я постараюсь запланировать время простоя для этого. Однако нигде нет журналов, связанных с ошибками диска ввода-вывода. Или ты видел что-нибудь?
Lars Hanke 10 лет назад
0
0
c4f4t0r
Maybe you don't have any file system errors, but I'm sure you see that warnings in your log, because you have many processes in D state (waiting for I/O) and the kernel is informing you of the long wait.
Я думаю, что это было так. Но почему? В нормальных условиях нет процессов в D-состоянии. Если на самом деле сеть вышла из строя, это может объяснить это. Но почему бы это пойти только на некоторые услуги? Почему это условие пережило перезагрузку? И почему это возникло снова?
Lars Hanke 10 лет назад
0
0
Armin
Ошибка указывает, что ваши процессы слишком долго (120 секунд) ждут доступа к дискам; это происходит на сильно загруженных серверах, где диски слишком заняты, чтобы реагировать на процессы.
Вы можете убедиться, проверив «Ожидание» под vmstat.