Miniaturni cluster

[Jan Dušátko]

> > Jakákoliv "sofistikovaná" metoda hrozí, že se rozbije...
> 
> Muzes klidne vynechat privlastek "sofistikovana" a bude to porad
> pravda.
> 
> Vzdycky je tam zbytkovy riziko a snaha o jeho odstraneni by mela koncit
> v okamziku, kdy je vetsi nez naklady na jeho zmenseni.
> 
Pokud si zakaznik preje a zakaznik plati, vyvratit jsem to uz skousel.
Kazdopadne budu to resit drastickym pristupem - sekvence 55AA na seriovy
port zpusobi restart potencialne nefunkcniho stroje a presun sluzeb na
restartujici (ten co zpusobil restart, ne ten co se bude restartovat).
Detekce bude pouze dotazem na jednotlive sluzby, nefunkcnost jedine z nich
zpusobi migraci sluzeb vcetne CARP interface.

Restartovany stroj po inicializaci zajisti plnou synchronizaci a pote se
pokusi prevzit zpet sve role. Pokud se mu to nepodari, bude se to brat jako
rozbite a da mi to varovani (neuspesny start sluzeb, neodmountovany
souborovy system, nereagujici puvodne sekundarni system).

V pripade trech migraci za sebou se prepinani zastavi a da mi to varovani.
Bude se to brat jako "rozbite".

Data se zalohuji po hodinach do snapshotu, vecer se necha jediny. Snapshoty
jsou tyden zpet a potom ke kazdemu poslednimu v mesici za jeden rok zpet.
Ostatni roky jsou jenom 31.12.

Jednou tydne probiha zalohovani celeho ZFS (zfs send), vcetne vsech
snapshot.

Jinak jsem zkousel resit zalezitosti tykajici se HAST a pfsync. Po
zkusenostech bych pfsync nasazoval uz jen v pripade, kdy mam tri interface
(vnitrni, vnejsi a synchronizacni). HAST je mozne pri dostatecne sirce pasma
nastavit I na jednom (klienti na 100Mb a sit 1Gb je postacujici pripad).

Momentalne resim distribuovany DHCP a LDAP, DNS je replikovany (dva NS
servery, kazdy na jednom fyzickem stroji).

Honza