Что-то закрывает соединения на моих виртуальных машинах CentOS — как лучше всего устранить неполадки?

У меня есть установка с 3 виртуальными машинами (1 сервер приложений на CentOS6 и 2 сервера баз данных на CentOS7).Последние 1-2 недели у нас были проблемы с тайм-аутами при подключении к серверам баз данных (и между двумя серверами, которые находятся в кластере).

Поставщик базы данных (Couchbase) может видеть из журналов, что соединения принудительно закрываются:

ПРЕДУПРЕЖДЕНИЕ com.couchbase.endpoint - [com.couchbase.endpoint][UnexpectedEndpointDisconnectedEvent] Удаленная сторона неожиданно отключила конечную точку

Журналы также показывают, что пакеты удалены, например:

[предупреждение] Интерфейс âens32â (удален ip) сбои: RX: 2863 / TX: 0 - Детали:
- Пакеты RX: 308 593 167 ошибок: 0
выпало: 2863 переполнение: 0 кадр: 0

Виртуальные машины размещены на том же хосте, что и VMware ESXi (версия 6.5). Поэтому они должен иметь хорошие связи друг с другом.

И что изменилось за последние пару недель? Обновления безопасности для ОС ВМ и версии сервера баз данных (с 6.6.0 до 7.0.0). Обновление базы данных не должен изменить что-либо в сети, но, очевидно, это причина, по которой я сначала связался с поставщиком базы данных...

Любые идеи по поиску виновника высоко ценятся :-)

Редактировать:

Следуя предложению Кэмерона, я просто запустил короткую трассировку сети и загрузил ее в Wireshark на моем локальном компьютере. Потом я открыл "Экспертную информацию" и получил вот это: Нужно сказать, что перед сервером приложений стоит прокси-сервер Nginx. Он обрабатывает SSL и «снимает его» перед тем, как попасть в приложение. сервер. Просто глядя на информацию, я ожидаю, что два «красных» блока будут связаны с запросами, поступающими извне, а не из приложения. сервера к серверам баз данных.

Но я не совсем уверен, что искать в результатах? - и я думаю, мне нужно дать ему поработать еще немного - но, возможно, без информации извне?

Редактировать 2

Когда я сидел и смотрел на это, проблема действительно возникла ... - поэтому я снова быстро запустил tcpdump. Таким образом, результаты могут не содержать основной причины, но должны быть более актуальными, чем первые: Блоки, которые я расширил, похоже, связаны с связью с одним из серверов баз данных.... :-)

Но что означают эти результаты и как мне приблизиться к поиску причины?

Добро пожаловать в 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? Приложение тоже было обновлено, или его подняли и сдвинули?

Ваше здоровье, Кэмерон