Ubuntu do-release-upgrade és a keepalived esete

Keepalived volt: 1.3.9,  lett 2.0.19, és örömmel tapasztalom, hogy "Warning - script chk_haproxy is not used" üzenettel örvendeztet meg - és tényleg tudomást sem vesz arról, hogy a haproxy fut-e vagy sem...

 

Szerencsére van még két node, ahol "rendesen" működik, úgyhogy egy újabb egyszerűnek indult szívességből lesz komolyabb reszelni való...

Pedig tényleg faék egyszerű dolgot kéne csinálnia: figyelni a haproxy processzt, és ha nincs, akkor átadni a VIP címet egy olyan node-nak, ahol van - azaz pont azt, amit az 1.3.9-es csinált...

 

( zeller | 2023. 04. 17., h – 12:17 )

Szerkesztve: 2023. 04. 17., h – 12:20

Úgy néz ki, megvan a "bűnös"... Az 1.3.9-nek nem volt baja azzal, hogy volt a konfigban vrrp_sync_group (egy vrrp instance benne), azt ignorálta, és a scriptet használta. A 2.x viszont be is szól, hogy "Sync group VG1 has only 1 virtual router(s) - this probably isn't what you want", mielőtt kiböki a "Warning - script chk_haproxy is not used" sort.

Kitakarítva a konfigot (volt benne még egy rakat "ott maradt" csingilingi, talán még a napóleoni háborúk idejéből is akár...) remélhetőleg jó lesz. Tanulság: néha jó újragondolni akár nulláról egy kritikusabb konfigurációt.

( NagyZ v | 2023. 04. 19., sze – 20:32 )

a keepalived annyira 90-es evek, hogy bagoszagu. modern L3 szevasztok!

haproxy tipikusan olyan amit nagyon jol lehet anycast IP moge rakni frr-rel, csak a systemdben megfeleloen kell definialni a fuggosegeket: frr leallit (ez leveszi a forgalmat), haproxyval azt csinalsz amit akarsz, frr visszaindit (jon megint a forgalom mert elkezdi hirdetni az anycast IP-t).

az enterprise haproxy tud tcp state sharinget is, ott a juzer eszre sem vesz egy maintenancet sem peldaul, de amugy max 1 reconnect.

Hogyan csinálod a health checket?

Eléggé favágó megoldás hogy leállítod az FRR-t ha nem elérhető a szolgáltatás.

Akkor már inkább ExaBGP-vel oldom meg a BGP-t annak van healthcheck modulja. Bár újabban állítólag lehet Lua-ban scriptelni az FRR-t is.

Vagy a loopbackról leveszem az anycast IP-t vagy.... van itt néhány lehetőség...

Néhány cikk a témában akit érdekel:

https://blog.plessis.info/blog/2020/02/11/haproxy-exabgp/

https://blog.sdn.clinic/2018/02/anycasted-services-with-debian-bird-any…

https://yetiops.net/posts/anycast-bgp/

https://vincent.bernat.ch/en/blog/2018-multi-tier-loadbalancer

Persze az egész már ott elbukhat, ha az első L3 eszközöd nem képes ECMP-re, mert pl egy tűzfal...

localban tudod health checkelni a haproxyt termeszetesen, illetve a gepnek van unicast IPje is azon is healthcheckelhetsz, de ha ennel tobbet szeretnel, akkor meseld el, mit szeretnel pontosan health checkelni.

en nem szeretem se a birdot, se az exabgpt, frr4life :)

ha a loopbackrol leveszed az anycast IP-t akkor az frr nem fogja tovabb hirdetni, ez is megoldas, nem kell feltetlen leallitani. nalunk a haproxy stop megcsinalja az frr-t, es egyutt dolgoznak, igy egyszerubb az elet.

ha az L3 eszkozod nem tud ECMP-t akkor bazd ki a kukaba, oda valo.

Ha a haproxy frontend nem elérhető (DOWN) akkor vegye ki a hozzá tartozó anycast IP-t a hirdetésből. Ez a cél. És akkor már legyen automatikusan felderített az összes frontend IP. Az első linken amúgy van egy hasonló megoldás erre.

Az L3 eszközeim köszi jól vannak, csak lássuk be, hogy egy meglévő infrán azért nem mindenhol lehet ezt megcsinálni . A régi L2-es trükkök azok mindig működnek.

Egyébként az anycast jóval elegánsabb mint a VRRP groupokkal és priority-kkel bohóckodni ezt tény.