Pronlema:
Fujitsu szerver, RHEL 7.7 rajta, illetve Docker par containerrel (MACVLAN).
Kulso esztkoz SIP kommunikaciot csinal, kuldi az RTP csomagokat az egyik Docker contenernek, majd kihuzzuk az egyik PSU-t a szerverbol es a kommunikacio megszakad nehany ezredmasodpercre ezzel:
ICMP "destination unreachable (Port unreachable)" --- ezt a kontener kuldi vissza a kulso eszkoznek
Azaz mintha a containerben megszunne/eltunne a UDP port par miliszekundumra, vagy tulzottan besokallna, azaz nem tudna fogadni a bejovo RTP csomagokat.
Es mindez akkor csak HA KIHUZZUK AZ EGYIK PSU-t !! Azaz valami triggerelodik...
Otlet?
Valaki tapasztalt hasonlot?
Esetleg mit tennetek a debugban?
(az is erdekes, hogy utana folytatodik a kommunikacio, szoval recoverelodik a cucc! - de sajnos ez a keves ido eleg ahhoz, hogy par cucc atallitodjon a rendszerben negativ iranyban)
- 331 megtekintés
Hozzászólások
Egyaltalan az is a kerdes, hogy melyik layer kuldi ki ezeket az ICMP csomagokat, ha latja, hogy beerkeznek RTP (UDP) csomagok, de nincs aki fogadja oket?
A RHEL network stack? A Docker network stack? Vagy az applikacio (framework - >Java) maga?
- A hozzászóláshoz be kell jelentkezni
Amikor kihúzod az egyik tápot, nézd meg a kernel logokat: https://serverfault.com/questions/305311/how-to-view-linux-kernel-logs-…
Nem lehet, hogy a hálókártya drivere észlel valamit, és egy pillanatra eltűnik az interfész, vagy ilyesmi?
- A hozzászóláshoz be kell jelentkezni
dmesg nem mutat semmit, a kmsg-t ma megnezem.
- A hozzászóláshoz be kell jelentkezni
akkor is fennáll a jelenség, ha a PSU-ból húzod ki a delejt?
- A hozzászóláshoz be kell jelentkezni
Bocs, a PSU-bol huzom ki termeszetesen a tapkabelt, menet kozben.
- A hozzászóláshoz be kell jelentkezni
Kontakthibás a hálózati kábel :-D
- A hozzászóláshoz be kell jelentkezni
Mindketto PSU-nal ezt csinalja, kulon kabelen vannak.
Egyebkent azt nem ertem, ha egyik kontaktos is es kihuzom, a masiknak elegnek kellene ahhoz lennie, hogy elvigye a rendszert.
- A hozzászóláshoz be kell jelentkezni
Én az ethernetre gondoltam - amikor kihúzod a PSU-t, megmozdítod az ethernet kábelt...
- A hozzászóláshoz be kell jelentkezni
Mikor a PSU-k közöttt váltás van akármennyi időre is de van kiesés én ezt normálisnak gondolnám. Alapból azok nem dolgoznak csak ha kell és a switch akármennyi mp-t is vagy század másodpercet időbe vesz. Én fentebb venném az icmp csomagok küldésének idejét, asszem azt is lehet megadni hogy milyen sűrűn küldje és kérjen visszajelzést.
- A hozzászóláshoz be kell jelentkezni
én biztos kipróbálnám hogy a host oprendszerből tolnám az icmp-t és ha ott is van szakadás akkor nem a docker és hasonló layerekben kell keresni a hibát.
elég messzire vezethet ez a dolog, így tippre alaplap tervezési problémára is tippelhetek akár, lehet meg kéne keresni a fujitsu supportot.
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
support ticket mar kikuldve a Fujistu-nak, de nem hinnem, hogy erdemi valaszt kapunk
hogy erted ezt a host oprendszer kitolast?
- A hozzászóláshoz be kell jelentkezni
úgy h nem a dockerből hanem az alap oprendszerből futtatnám a pinget
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
"de sajnos ez a keves ido eleg ahhoz, hogy par cucc atallitodjon a rendszerben negativ iranyban"
Pedig azert na, RTP meg SIP eseten a csomagvesztes az eg elegge alap dolog, nem is ertem, hogy erre miert nem vagytok szoftverben felkeszulve. Ezek a protokollok direkt ugy vannak kitalalva, hogy alatta total instabil lehet a halozat.
- A hozzászóláshoz be kell jelentkezni
Ugy tunik, az app bezarja a portot milisecundumokra, ez okozza a gondot. Nem az ICMP packetek.
Mit javasolnatok milisecundumos port bezaras tesztelesere?
- A hozzászóláshoz be kell jelentkezni
Egy konténerizált, microservice környezetben ez megintcsak nem kellene, hogy gondot okozzon. Konténerek jönnek-mennek, erre megfelelő resiliency patternekkel kell felkészülni.
Nem azt kell tesztelned, hogy pár ezredmásodpercig zárvaa port, hanem azt, hogy a rendszer többi része hogy kezeli le azt, hoyg akár egy, három, öt másodpercig vagy óráig zárva a port, és hogyan veszi észre, hogy újra lehet kapcsolódni? Úgy látom, nálatok semmi resiliency nincsen kiépítve.
Szóval nem a pár ezredmásodperc a lényeg, hanem az, hogy a rendszer többi része számára ez miért ennyire fontos, és miért nem tudnak kijönni ebből az állapotból? Hiszen ezek szerint ha egyáltalán leállás van valahol, akkor azt sem tudják kezelni.
- A hozzászóláshoz be kell jelentkezni
Azt hiszed en ezt nem tudom? ha egy kicsit belelatsz egy nagy ceg design es fejlesztesi sebessegebe, ez nem ugy megy, hogy szolok a fejlesztonek, hogy a sz.r applikaciod miert nem kezeli le ezt, meg azt. Ugyanis ennek az atfutasi ideje hetek, amire ezt befejleszti.
Itt az van, hogy jon egy hiba, a mar "eladott" rendszeren, amit persze nem vettek eszre a tesztek alatt, mert az masik hardveren futott! nagy okosok! Azt hittek, hogy a Docker az mindenhato, majd megeszi ezt is. Hat nem.
A fejleszto azt mondja, hogy nem kap CPU-t a process, emiatt eldobja a kapcsolatokat. Az mar nem biztos, hogy erdekli, hogy deritem ki, miert nem kap CPU-t?
En azt mondom, a port bezarodik, de ezt bizonyitanom kell. Nincs mese. strace szoba johet, de ettol nem vagyok tulzotan feldobva...
A leallast tudjak kezelni, iivel a SIP onmagaban ilyen, de ebben az esetben a par milisecundum is eszrevevodik, es ez a baj...
- A hozzászóláshoz be kell jelentkezni
Jelenleg ott tart a dolog, hogy nem az "ICMP unreachable.." dolog miatt van a cucc, ez valami mas.
Most azt nezegetem, hogy a szerver (kernel) hogyan kommunikal a PSU-val.
Valami otlet, mit kellene itt neznem? Es miilyen tool-lal?
Pl. a ipmitool sdr type "Power Supply" nem mutat semmit.
- A hozzászóláshoz be kell jelentkezni