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 <[email protected]> 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 ([email protected]) >http://www.freebsd.cz/listserv/listinfo/users-l -- FreeBSD mailing list ([email protected]) http://www.freebsd.cz/listserv/listinfo/users-l
