Vlákno názorů k článku Orchestrujeme pragmaticky: bez zbytečných nástrojů, s pomocí rsync od wabi - Nezlobte se, ale zbastlil jste řešení na které...

Nezlobte se, ale zbastlil jste řešení na které se nedá spolehnout.

Profesionální řešení mohou být i jednoduchá, ale věci jako "modlím se, aby nenastal zrovna ten případ, kdy přijdu o konzistenci db zrovna když to exne" se akceptovat nedají. Zábavná situace by zřejmě nastala kdyby Vám to umřelo třeba uprostřed toho rsyncu.

Nehledě na to, že s orchestrací to má opravdu pramálo společného.

Kdybych měl tedy kromě kritiky i navrhnout zlepšení, tak (bez zavlečení dalších jak říkáte složitostí):
* databázi rozhodně přenášet pomocí nástrojů k tomu určených (dump, i třeba iterativní, rsync, restore)
* nesynchronizovat celý server a potřebné soubory synchronizovat do vyhrazené složky na cílovém serveru a až odtud rozkopírovat na příslušná místa (tzn. když to lehne během rsyncu, neskončil jste s rozbitým záložním serverem)
* aktualizace serveru a instalace nových balíků dělat poctivě na obou serverech (obojí se dá napsat jako skript a spuštění je otázka jednoho příkazu). Nebo pomocí parallel ssh či podobného, ale tam vám hrozí, že při nějakém problému s aktualizací přijdete o oba servery zároveň.

Spolehlivost: jde o poměr cena/výkon. Můžete samozřejmě dosáhnout 99,9% spolehlivosti, ovšem za cenu toho, že vás to bude stát čas a námahu. Tohle řešení je možná z 95% spolehlivé, ale to je záměr!

Jde-li o konzistentní data: denně se dělá inkrementální záloha všech souborů a db dump. Případ, kdy by to lehlo zrovna v průběhu synchronizace, se stát může. Je ale mnohem větší pravděpodobnost toho, že se to nestane. A když se to stane? Tak databázi obnovím z dumpu ručně a tato práce bude pořád výrazně menší než práce, kterou bych spotřeboval na vývoj spolehlivějšího řešení.

Nekonzistence jiných souborů: obvykle se žádné soubory mezi live-backup serverem nemění, pouze když něco v systému aktualizuji. V takovou chvíli synchronizaci vypínám a sesynchronizuji to až najednou poté. Jistě, přímo v průběhu aktualizace by mohlo dojít k havárii. Ale pravděpodobnost je opět velmi nízká.

Spíš než k haváriím hardwaru tady dochází k tomu, že vypadne switch na straně providera a trvá, než to dá dohromady. Po tuto dobu může web běžet z backupu v read-only režimu.

Preferuji obecně přístup, že lepší je počítat s výpadky i nekonzistencemi, ale mít připraveny plány B i C, aby ty výpadky byly krátké a nekonzistence se daly odstranit. Nesetkal jsem se totiž s opravdu funkčním 99,9% failoverem. Naposledy jsem kvůli takovému "failoveru" letěl do Amsterodamu, protože kolega do dvou switchů v onom "failoveru" zapojil jen jeden ethernetový kabel. Nebo jiný zase vyrobil super obrovské úložiště v kombinaci mnoha raidů nad sebou, které by nikdy nemělo selhat. Ale když to selhalo, tak byl zrovna na dovolené a nikdo jiný tomu pořádně nerozuměl (bylo to sice popsáno ve wiki, ale přesto tak překomplikované, že nebylo snadné se z toho vyhrabat). Opět půldenní výpadek. Z pragmatického hlediska preferuji raději výpadek hodinu než celý den.

Riešenie so spoľahlivosťou 95% nie je žiadne riešenie, ale ďalší problém pridaný k pôvodnému! Najmä ak sa hodnota 95% vzťahuje na "availability", to je služba, ktorú vlastne nikto ani nejako veľmi nepotrebuje.

Aj tých 99.9% prezentovaných ako niečo rozprávkové je viac ako 8 hodín neplánovaného výpadku za rok, to sa dá zvládnuť aj bez automatického failoveru clustra, ak máme funkčný a rozumne navrhnutý monitoring, organizáciu pracovnej pohotovosti, dokumentáciu a zálohovanie.

Zlyhania ako zapojený len jeden kábel (na to sú snáď DR testy a procedúry na release to production) alebo zložité riešenie, ktorému rozumie len jeden človek (to by mal zachytiť ktorýkoľvek príčetný vedúci, to azda ten jeden ťahal nonstop pohotovosti?) a lety do Amsterdamu (lokálny kontakt v datacentre alebo akejkoľvek budove je dnes snáď samozrejmosť), to je vec, ktorá svedčí o zhnitosti príslušnej organizácie. Alebo sa jedná o nejakých garážnikov, a tí by radšej svoje tzv. howto (v skutočnosti "spatláme to, aby to nejako fungovalo") nemali šíriť verejne...

Případ, kdy by to lehlo zrovna v průběhu synchronizace, se stát může. Je ale mnohem větší pravděpodobnost toho, že se to nestane.

Poradím vám jedno KISS řešení. Na zálohovacím stroji použít FS s podporou snapshotů. ZFS nebo BTRFS, to už je jedno. Potom vůbec nebudete muset řešit, jestli synchronizace pravděpodobně spadne nebo nespadne, protože vám to bude jedno. Pokud po každé úspěšné synchronizaci provedete snapshot, máte konzistentní data i s nějakou historií do minulosti.

Toto je, podle mě, směr, jak se na problémy dívat. Správné řešení se pozná tak, že je jednoduché, samo se nabízí a vyřeší hned několik problémů současně a navíc přinese další možnosti, jak si věci ulehčit v budoucnu.

Takže když už budete mít FS s podporou snapshotů na zálohovacím stroji, tak jej můžete použít i na zálohovaném. A přenášet atomické snapshoty. A toto řešení je ještě jednodušší než vaše. Klidně totiž můžu udělat snap / send / receive FS i s tou DB. (ACID DB jsou na toto stavěné a bezproblémů přežijí atomický snapshot.)

Takže zavedením jedné další technologie jsem věc nezesložitil, ale zjednodušil a přineslo mi to i další výhody, které předchozí řešení vůbec neumožňuje - mít historii záloh, atomický a konzistentní stav FS a jednodušší skripty.

Naposledy jsem kvůli takovému "failoveru" letěl do Amsterodamu, protože kolega do dvou switchů v onom "failoveru" zapojil jen jeden ethernetový kabel.

Vy máte firemní kulturu, která zakazuje cokoliv testovat? Pokud už staví síťové failover řešení, tak je přece normální, že se otestuje (i třeba vypnutím portů). Odchází od zavřeného racku a ví, že ten připravený failover funguje.

Nebo jiný zase vyrobil super obrovské úložiště v kombinaci mnoha raidů nad sebou, které by nikdy nemělo selhat. Ale když to selhalo, tak byl zrovna na dovolené a nikdo jiný tomu pořádně nerozuměl (bylo to sice popsáno ve wiki, ale přesto tak překomplikované, že nebylo snadné se z toho vyhrabat).

V takovém případě (nasazení takové technologie) je přece normální udělat školení i pro kolegy a pokud se ukáže, že je to nad jejich síly (což je většinou známka toho, že je to i nad síly toho, kdo to postavil a takových technologií je hodně, a není to nic, za co by se měl člověk stydět, je spousta technologií, které jsou větší než typická IT firma), tak od toho plánu ustoupit a udělat jednodušší řešení.