Что-то закрывает соединения в моих виртуальных машинах CentOS - как лучше всего устранить неполадки?
У меня есть установка с 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 на моем локальном компьютере. Потом открыл «Экспертную информацию» и получил вот что:
Я должен сказать, что перед сервером приложений стоит прокси-сервер 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? Приложение тоже было обновлено, или его подняли и сдвинули?
Ура, Кэмерон