У меня есть настройка с 3 виртуальными машинами (1 сервер приложений на CentOS6 и 2 сервера баз данных на CentOS7). Последние 1-2 недели у нас были проблемы с тайм-аутами при подключении к серверам баз данных (и между двумя серверами, которые находятся в кластере).
Поставщик базы данных (Couchbase) может видеть из журналов, что соединения принудительно закрыты:
WARN com.couchbase.endpoint - [com.couchbase.endpoint][UnexpectedEndpointDisconnectedEvent] The remote side disconnected the endpoint unexpectedly
Журналы также показывают, что пакеты отбрасываются, например:
[warn] Interface ‘ens32’ (removedip) failures: RX:2863 / TX:0 - Details:
- RX packets:308,593,167 errors:0
dropped:2,863 overruns:0 frame:0
Виртуальные машины размещены на одном хосте, который является VMware ESXi (версия 6.5). Таким образом, онидолжениметь возможность иметь хорошие связи друг с другом.
А что изменилось за последние пару недель? Обновления безопасности на ОС ВМ и версии сервера базы данных (с 6.6.0 до 7.0.0). Обновление базы данныхне следуетизменить что-либо в сети, но, очевидно, именно поэтому я впервые связался с поставщиком базы данных...
Любые идеи по поиску виновника будут высоко оценены :-)
Редактировать:
Следуя совету Кэмерона, я просто запустил короткую трассировку сети и загрузил ее в Wireshark на локальной машине. Затем я открыл "Expert information" и получил это:
Мне нужно сказать, что перед сервером приложений находится прокси-сервер Nginx. Он обрабатывает SSL и "поднимает его" перед тем, как попасть на сервер приложений. Просто глядя на информацию, я бы ожидал, что два "красных" блока будут связаны с запросами, поступающими извне, а не с сервера приложений на серверы баз данных.
Но я не совсем уверен, на что обращать внимание в результатах? - и, полагаю, мне нужно дать ему поработать немного дольше - но, возможно, без информации извне?
Редактировать 2
Пока сидел и смотрел на это, проблема действительно возникла... - поэтому я быстро снова запустил tcpdump. Так что результаты могут не содержать первопричину - но должны быть более релевантными, чем первые:
Блоки, которые я развернул, похоже, связаны с взаимодействием с одним из серверов баз данных.... :-)
Но что означают эти результаты и как приблизиться к выявлению причины?
решение1
добро пожаловать в Server Fault.
Учитывая возраст; CentOS 6 сейчас не поддерживается, весьма вероятно, что вы страдаете от несовместимости SSL/TLS; конечно, если вы подключаетесь через него. Мы, конечно, пережили множество таких событий за время работы с RHEL6, когда SSL2 и т. д. постепенно отключались по умолчанию. Аналогично с различными точечными версиями Java (некоторые точечные выпуски в серии 1.7 были особенно капризными)
Другая возможная причина, учитывая, что вы запускаете рабочую нагрузку CentOS на ESXi, заключается в том, что вы можете работать с недостатком энтропии, что приводит к блокирующему поведению, которое может привести к тайм-аутам и проблемам кластера, что приводит к прерываниям соединения. До Java 8 Java была особенно восприимчива к этому. Вы можете судить, является ли это проблемой для вас, посмотрев на /proc/sys/kernel/random/entropy_avail с течением времени; если он опускается ниже 128 или около того и не возвращается обратно, то у вас голодание энтропии. Распространено на виртуальной машине, где нет активности клавиатуры и мыши; вы можете попробовать запустить демон сбора энтропии, если это так.
Кстати, я бы не стал делать вывод из этих журналов, что что-то [еще] активно закрывает эти соединения; просто соединение закрылось в то время, когда одна из сторон этого не ожидала. Это может быть связано с такими вещами, как тайм-аут, исключения, сбой процесса и т. д. и т. п.
Вы говорите, что сервер базы данных был обновлен... это было обновление ОС с CentOS 6? Приложение также было обновлено или его подняли и перенесли?
Привет, Кэмерон.