zpozdeny CARP master

[Vilem Kebrt]

Asi jsem dřevák, ale já dva servery s haproxy hlídám pres heartbeat, na vnějšku si to ověřuje křížem služby (po privátních) a předává veřejnou. A používám pouze sync tabulek spojení mezi pfkama na těch strojích a to po další vnitřní lince.
Vilém

⁣Odesláno z BlueMail ​

22. 3. 2018 9:52, 9:52, Dan Lukes <dan at obluda.cz> napsal/a:
>On 22.3.2018 7:31, Bc. Tomáš Skocdopole | IT-BOX wrote:
>> CARP ohlida stroje po sitove strance (a myslim ze dobre), ovsem uz
>neohlida
>> jestli napriklad nespadlo haproxy
>
>To po nem ani nelze spravedlive chtit - ruznych sitovych sluzeb je 
>hromda a neexistuje obecny test jak zjistit, jestli funguji - to
>vzdycky 
>musi obstarat test na miru sity konkretni sluzbe.
>
>Ostatne, CARP je na to pripraveny - prave k tomu existuje sysctl oid 
>net.inet.carp.demotion
>
>A k dispozici je vazba i v opacnem smeru - CARP udalost je do userlandu
>
>propagovana v podobe DEVD udalosti. No a tam uz na ni lze reagovat 
>spustenim scriptu a provedenim cehokoliv co v takovem pripade povazujes
>
>za nutne.
>
>Tohle, oboji, maji vyresene celkem rozumne.
>
>> - na to mit dle meho jedine nejakou
>> nadstavbu (script/daemona), ktery hlida zda-li bezi haproxy a pokud
>ne, tak
>> prepne masinu pomoci CARP do slave.
>> I kdyz mozna by bylo vhodnejsi aby slave masina hlidala process
>haproxy na
>> master stroji.
>
>Externi kontrola je, kdyz je mozna, vzdycky lepsi - ten 'slave' stroj
>se 
>klidne mohl dostat do stavu, kdy z hlediska CARP bezi, ale jinak je 
>zcela nepouzitelny - nebezi na nem pozadovana sluzba, ani nedokaze
>bezet 
>proces, ktery ji mel hlidat.
>
>Zrovna tenhle problem by CARP mohl resit i lepe - vedle 
>net.inet.carp.demotion by muselo existovat nejake dalsi oid, jehoz 
>hodnotu by CARP subsystem prubezne zvetsoval a pokud by jeji hodnota 
>prekrocila stanovenou mez, tak by se CARP adres vzdal. A bylo by na 
>userlandovem kontrolnim procesu aby hodnotu tohoto oid pravidelne 
>"srazel dolu". Proste - watchdog. To by pokrylo i pripady, kdy je jadro
>
>systemu funkci, ale userland efektivne nefunkcni.
>
>> Jen bych se zeptal - vzdy je potreba N+1 IP adres, nebo je nejaky
>figl, jak
>> provozovat CARP pomoci jedne (jen abych zbytecne neplytval verejnyma
>IP)?
>
>Jo, tak to nevim, CARP az do takovych detailu skutecne neznam. Tak
>nejak 
>nevidim duvod aby to neslo, ano, CARP potrebuje pro svoji "sluzebni" 
>komunikaci nejake adresy, to ale klidne mohou byt adresy privatni a na 
>zaklade teto komunikace by si mohl predavat adresu, ktera je z jine
>site 
>(tedy treba i verejna IP), ale je mozne, ze takove konfiguraci neco 
>principialne brani. A nebo je to jen implemntacni problem (z hlediska 
>protokolu by to slo, ale FreeBSD neni jak pozadovanou konfiguraci
>"vnutit")
>
>Na to je jednoducha odpoved (pokud se ti nikdo neozve s "jo, to mam") -
>
>proste to zkus (idealne ne na produkcnim prostredi ;-) )
>
>> U me jeste vyvstala otazka jak klonovat konfiguraci mezi tou dvojici
>stroju.
>> Protoze krome IP adresy stroje a hostname je konfigurace naprosto
>identicka.
>
>Mozna by slo najit i zcela obecne reseni tohoto problemu, ale o mnoho 
>snazsi bude hledat reseni synchronizace konkretnich komponent -
>obzvlast 
>pokud je jejich konfigurace zalozena na textovych souborech.
>
>Treba usynchronizovat obsah /etc a /usr/local/etc je vice-mene
>trivialni 
>uloha. V tom nejtupejsim pripade to proste jednou za cas preneses.
>
>Pozor ale na to, jaka mas prani - mohla by se ti totiz zplnit.
>
>Takovyhle system vypada lakave, na druhou stranu znamena, ze pokud 
>neuvazenym zasahem do konfigurace rozboris jeden stroj, zahy budes mit 
>nefunkcni vsechny - a k cemu pak cely HA cirkus bude ?
>
>Dan
>
>
>-- 
>FreeBSD mailing list (users-l at freebsd.cz)
>http://www.freebsd.cz/listserv/listinfo/users-l