Puncte:0

Toate sesiunile ssh prin serverul de salt la un vm încetinesc sau chiar expiră dacă dați ping la un server mort din interiorul uneia dintre sesiuni

drapel au

Env: vm1 și vm2 (ambele redhat8.2) sunt în spatele aceluiași gateway (Ubuntu 20.04.2), iar acest gateway acționează și ca server de salt pentru macbook-ul meu la ssh la vm1 și vm2. Acest gateway este gateway-ul implicit atât pentru vm1, cât și pentru vm2.

Situatie: Eu fac ssh la vm1 cu 2 sesiuni prin serverul de salt și, de asemenea, fac ssh la vm2 prin serverul de salt.

Problemă: Dacă „ping” orice server mort sau „arping” orice server inaccesibil din interiorul uneia dintre sesiunile mele ssh la vm1, atunci ambele 2 sesiuni la vm1 devin foarte lente, chiar și timeout. Și devine extrem de lent când încerc din nou să ssh la vm1 prin serverul de salt.

Observare: Și lucrul interesant este că dacă fac ssh de la vm2 la vm1, atunci totul funcționează bine, această nouă sesiune este destul de rapidă și pot face orice operațiuni normale, ca de obicei, fără încetiniri. Și dacă opresc procesul ping sau arping aici înainte ca cele 2 sesiuni ssh la vm1 să expire, atunci după câteva minute, ambele sesiuni ssh la vm1 devin din nou normale.

Ai idee de ce se întâmplă asta? Mulțumesc mult!

macbook --> gateway (jump server x.x.0.1) --> vm1,vm2 (x.x.3.101, x.x.3.102)

xu wang avatar
drapel au
Și am găsit că încetinirea are loc între serverul de salt și vm1, pentru că dacă fac ssh la vm1 direct de pe serverul de salt, este și extrem de lent. deci se pare că acționând atât ca gateway implicit, cât și ca server de salt pentru vm1 a provocat un fel de conflicte care arp pot fi legate...
xu wang avatar
drapel au
Se pare că am găsit posibila cauză rădăcină, deoarece serverul de salt este folosit ca gateway implicit pentru un număr mare de vms, așa că, de fapt, nu are adresa mac a vm1 în cache, deoarece a trimis întotdeauna tone de solicitări arp cerând adresa mac a tuturor vm-urilor din spatele acestuia, așa că trebuie întotdeauna să trimită o transmisie arp pentru a cere adresa mac a vm1, dar cumva, inundația de mesaje arp boradcast care solicită adresa mac a serverului mort încetinește foarte mult procesul pentru gateway pentru a obține adresa mac de la vm1.
xu wang avatar
drapel au
acesta este motivul pentru care toate sesiunile la vm1 devin foarte lente. și pentru că vm2 are deja adresa mac a vm1 în memoria cache, deci nu există nicio încetinire când trec ssh de la vm2 la vm1. Mă gândesc să adaug dimensiunea cache-ului arp pentru gateway pentru a atenua această problemă...

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.