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