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
