Ceva se închide conexiunile în VM-urile mele CentOS - cum să depanez cel mai bine?

Am o configurare cu 3 VM-uri (1 server de aplicații pe CentOS6 și 2 servere de baze de date pe CentOS7).În ultimele 1-2 săptămâni am avut probleme cu timeout-urile la conectarea la serverele de baze de date (și între cele două servere care se află într-un cluster).

Furnizorul de baze de date (Couchbase) poate vedea din jurnale că conexiunile sunt forțate închise:

WARN com.couchbase.endpoint - [com.couchbase.endpoint][UnexpectedEndpointDisconnectedEvent] Partea de la distanță a deconectat punctul final în mod neașteptat

Jurnalele arată, de asemenea, că pachetele sunt abandonate, cum ar fi:

[avertisment] Eșecuri de interfață âens32â (eliminare a datelor): RX:2863 / TX:0 - Detalii:
- Pachete RX: 308.593.167 erori: 0
a scăzut:2.863 depășiri:0 frame:0

VM-urile sunt găzduite pe aceeași gazdă care este un VMware ESXi (versiunea 6.5). Astfel ei ar trebui să să poată avea legături bune unul cu celălalt.

Și ce s-a schimbat în ultimele două săptămâni? Actualizări de securitate pentru sistemele de operare VM și versiunea serverului de baze de date (de la 6.6.0 la 7.0.0). Actualizarea bazei de date nu ar trebui schimba orice în rețea, dar evident este motivul pentru care am contactat prima dată furnizorul de baze de date...

Orice idee pentru a găsi vinovatul este foarte apreciată :-)

Editați | ×:

Urmând sugestia lui Cameron, am rulat o scurtă urmărire a rețelei și am încărcat-o în Wireshark pe computerul meu local. Apoi am deschis „Informații despre experți” și am primit asta: Trebuie să spun că există un server proxy Nginx în fața serverului de aplicații. Se ocupă de SSL și „o ridică” înainte de a accesa aplicația. Server. Doar uitându-mă la informații, m-aș aștepta ca cele două blocuri „roșii” să fie legate de cererile venite din exterior - și nu din aplicație. server la serverele bazei de date.

Dar nu sunt sigur ce să caut în rezultate? - și cred că trebuie să mai las puțin - dar poate fără informațiile din exterior?

Editare 2

În timp ce stăteam și mă uitam la el, problema a apărut de fapt... - așa că am pornit rapid din nou tcpdump. Deci, rezultatele ar putea să nu conțină cauza principală - dar ar trebui să fie mai relevante decât prima: Blocurile pe care le-am extins par a fi legate de comunicarea cu unul dintre serverele de baze de date.... :-)

Dar ce înseamnă aceste rezultate și cum mă apropii de a găsi cauza?

bun venit la Server Fault.

Având în vedere vârsta; CentOS 6 fiind acum fără suport, ar fi foarte probabil să suferiți de incompatibilități SSL/TLS; presupunând, desigur, că vă conectați prin asta. Cu siguranță am experimentat o mulțime de astfel de evenimente de-a lungul timpului cu RHEL6, deoarece SSL2 etc. a fost dezactivat progresiv în mod implicit. În mod similar, cu diferite versiuni punctuale ale Java (unele versiuni punctuale din seria 1.7 au fost deosebit de distractive)

Un alt motiv posibil, având în vedere că rulați o sarcină de lucru CentOS pe ESXi, este acela că ați putea să nu faceți entropie, ceea ce provoacă un comportament de blocare care poate duce la expirări de timp și probleme de cluster, ceea ce duce la întreruperi de conexiune. Până undeva în Java 8, Java a fost deosebit de sensibil la acest lucru. Puteți judeca dacă aceasta este o problemă pentru dvs. uitându-vă la /proc/sys/kernel/random/entropy_avail în timp; dacă ajunge sub 128 sau cam asa ceva și nu revine, atunci ai foamete de entropie. Frecvent pe un VM unde nu există activitate de tastatură-mouse; ați putea încerca să rulați un daemon de colectare a entropiei, dacă acesta este cazul.

BTW, nu aș concluziona din acele jurnale că ceva [altceva] forțează în mod activ acele conexiuni să se închidă; este doar că conexiunea s-a închis într-un moment în care una dintre părți nu se aștepta. Acest lucru s-ar putea datora unor lucruri precum timeout, excepții, blocarea procesului etc.

Spui că serverul de baze de date a fost actualizat... a fost o actualizare a sistemului de operare de la CentOS 6? A fost și aplicația actualizată sau a fost ridicată și mutată?

Noroc, Cameron