Több virtual IP kezelése clusterben/gépcsoportban

Linux-haladó

Sziasztok!

Van esetleg valakinek olyan toolra tippje, ami virtuális IP címeket kezel több gépen mint erőforrás? Igen, tudom corosync, RHCS, stb.stb. A gondom az, hogy a feladat annyi lenne, hogy egymástól független gépeken 1-1 virtuális IP címet kellene mozgatni leállás/probléma esetén a többi node-ra és vissza.

Tehát az alapfelállás:

server1 IP: 10.0.10.1
server1 VIP: 10.0.10.11

server2 IP: 10.0.10.2
server2 VIP: 10.0.10.12

serverN IP: 10.0.10.N
serverN VIP: 10.0.10.1N
 

Tételezzük fel, hogy lerohad a server1 (vagy a rajta futó X process), ezt a topológiát kellene baromi gyorsan elérni:

server1 DOWN

server2 IP: 10.0.10.2
server2 VIP: 10.0.10.12
server2 VIP2: 10.0.10.11

serverN IP: 10.0.10.N
serverN VIP: 10.0.10.1N

 

Corosynccel tudom a megoldást, keepalived esetén nem tudom h. ezt tudnám-e valahogy kezelni, viszont ezeket szinte mindet bonyolultnak érzem és nem ugrik be semmi szimpla megoldás. Barkács megoldást nem szeretnék (értsd python, bash, stb), csak valami lightweight cuccot, ami ezt tudja kezelni.

Ha nincs ilyen, akkor kénytelen leszek corosyncezni, de nagyon ágyúval verébre lenne érzésem szerint.

 

Köszi mindenkinek!

  • 374 megtekintés

A service több IP-re tud bindolni, de unicast címek kellenek neki sajnos. Egyébként nem szupertitkos a dolog, SipWise rtpengine az állat, amit szeretnék horizontálisan skálázni. Odáig oké h. redisben tárolja minden node h. nála milyen rtp folyamatok vannak, a többi tudja is ezeket folytatni, de az IP címeket muszáj mozgatni, mert azon kell h. folytatódjon a megszakadt kommunikáció, mert a kliens felé nem tudom updatelni az rtp szerver címét menet közben (vagy ha van ilyen SDP, akkor még azt valahogy lehetne implementálni :) )

Bevallom anycast teren hianyosak az ismereteim. 
Pont ez lenne a bonyolult benne. De ahogy nezem egyebkent tok jo lenne, mert nagyjabol pont azt csinalja ami nekem kell. Csak a proxy iranyabol mas mas weight kellene tartozzon az osszes backendhez es ha egy ledurran akkor megy tovabb ha jol ertem. 
 

Letezik ebbol “for dummies” konyv? :)

Ez nem egy for dummies topic. Ha hajlandó vagy a mostani hálózatot átalakítani amiatt, hogy szerviz IP címek hirdethetőek legyenek, így az ugyanazt a szolgáltatást adó IP-t a másik szerveren éred el (minden gépen felkonfigurálva minden IP vagy csak 1/2 IP címet hagyva a megmaradó IP cím(ek)). Ebben az esetben még mindig ott a feladat, hogy biztosítsd a session persistence-t és a szolgáltatás elérhetőséget minden szerveren ( nem írtad mi a szolgáltatás, biztos nem ICMP echo )

A témakör nem egyszerű, sőt ha picit megbolondítjuk valami HA-val (nem csak az IP hanem a szerviz működését is vizsgálni kell OpenBFDD, frr bfd, haproxy,.... ) akkor még bonyolultabb lesz.  Említettél valami proxy-t azaz ezek backend szolgáltatások, de nem értelmezhető, ha van HA már a proxyn miért kellene ide extra logika.

Ezt en is sejtettem. Mar h nem for dummies topic, ezt akarta jelenteni a kerdes utan az emoji. 
az h az alkalmazas kezelje a helyzetet meg van oldva. 
a jelenlegi mukodes az h van 2,3,n gep, mindenkinek van egy egy fix ip cime, arra mennek a requstek. 
ha kihal egy backend akkor az azon folyo hangcsatorna megszakad. 
ha kezzel az ip cimet attolom egy masik node-ra, akkor folytatodik a hangcsatorna. 
tehat alkalmazas oldalon jok vagyunk, csak az ipket kell a szolgaltatas mukodesetol fuggoen koltoztetgetni a node-ok kozott. 
barmely node barmely kiesett node sessionjet tudja folytatni, igy full random is lehet a dolog. 
a vrrp/carp/keepalived tema ehhez tul szimpla, mert 2 gep az alapfelallas ugye, szoval ugy velem h vagy network oldalrol kell kozeliteni (ospf, bgp, anycast), vagy corosync pacemaker. 
a corosync pacemakerrel is az a baj h nem az a kategoria amit barmelyik linuxos “szaki” hajnal 2-kor megszerel ha szethullik. 
ez az alap problemam gyakorlatilag. 
de valoszinu nem nagyon tudok mas iranyba menni, mert ez meg mindig egyszerubb mint pl egy bgp. 

( GaLbi | 2023. 03. 10., p – 17:00 )

Szerkesztve: 2023. 03. 10., p – 17:01

VRRP?

Mint “szaki” jobban bejonne a corosync az egyszerubb es szamomra atlathatobb konfig es resource kezelese miatt. 
 

de mint “architekt” a keepalived-t mar hasznaljuk masra, tul lehet elni a szerverek szamaval megegyezo instance groupok kezeleset, monitorozasunk is van ra es egyszerubb hibat kezelnj vele, mint kb barmi massal. 
 

futok egy minta konfigot a keepalived-vel is, aztan meglatjuk hogy nez ez ki mondjuk 4 szerverrel, 4 instance grouppal osszerakva. 

( azbest | 2023. 03. 10., p – 17:19 )

Ezt nem úgy szokták, hogy HA vagy load balancer vagy valami hasonló van előttük?

HaProxy is tud olyat, hogy több node-on egy közös virtualIP alatt futnak és azok továbbítják a nodeokhoz a kéréseket. Kieshet proxy node is és feladatvégő node is.

Meg amúgy ezt manapság nem mezitlábas gépekkel szokták, hanem valami konténeres rendszerben, ami szét tudja tenni a terhelést és redundanciát, hibatűrést is tud.

Igen, ezt úgy szokták, kivéve ha RTP és 10k portot kell tudni nyitni per VM :)

Ha ez HTTP lenne nem lenne még kérdés sem róla, csak ez elég spec dolog. Sajnos nem tudom azt megcsinálni, amit írtál, mert alkalmazás szinten meg van oldva a state tárolás (értsd HA), csak az IP címeket kellene a gépek között mozgatni ha probléma van valamelyikkel.

Külön "gáz", hogy elég gyorsan kellene mozgatni, hogy minél rövidebb ideig szakadjon meg a hangátvitel.

Ha jól emlékszem esxi alatt nem egy gépnek, hanem egy gépcsoportnak lehet virtuális ip-je, ami pont azért közös, hogy bármelyik kieshet mögüle. Kell egy réteg, ami továbbítja az élő vm-hez és a vm-eken valami, ami követi az állapotokat.

Terheléseloszlás és nodeszám skálázódás kapcsán úgy emlékszem opensips-et is használtunk. Lehet rtpproxyval együtt.
https://blog.opensips.org/2021/06/09/media-re-anchoring-using-opensips-…