Názory k článku Orchestrujeme pragmaticky: bez zbytečných nástrojů, s pomocí rsync

Zastavovat DB pro zalohy? Od nas se chce nedosazitelnych pet devitek, ne devet petek.

Jde to i lepe, staci udelat LVM snapshot a rsyncnout to z nej. Taky kdyz delam zalohy, tak snapshotuji starsi verze na cilovem stroji. Hodi se to: kdyz se vam smaze cast DB a vy si to nevsimnete, tak jinak prijdete o moznost to obnovit.

Zastavena je jen db na cilovem stroji (kam zalohujeme). Na primarnim (odkud bereme zalohu) porad bezi. Je to sice takove "dirty" reseni, ale funguje (rekneme v 99% pripadech, a zbyva jen modlit se ze nenastane to jedno procento kdy zaloha nebude konzistentni)...

Kolik testu jste udelal, ze tvrdite, ze je zaloha konzistentni na 99% pripadu?

Takhle to má Oracle a možná MySQL (v placené edici). PostgreSQL to tak nemá, a řekl bych, že MySQL ve free verzi také ne.

Je to uz nejaky rok co jsem delal admina ale je nesmysl ze pokud je oracle v backup modu tak se zapisuje jen do redo logu. Samozrejme se zapisuje i do tablespace.

https://www.datavail.com/blog/oracle-tablespace-hot-backup-mode-revisited/

Myslim si, ze LVM snapshot bude fundamentalne rovnako poskodeny, ako keby sa kopirovali zive data. Aj keby sa spravil trojity odpichnuty flushberger, stale nie je zarucene, ze nejaka aplikacia nema nabuffrovane data v aplikacnej pamati a subory na disku su aj tak nekonzistentne. Co je mimo ine aj dovod, preco vacsina FS nejournaluje data, ale iba metadata. Neexistuje sposob ako povedat, ze data su konzistentne. Aj ak nejake bariery v API existuju, drviva vacsina aplikacii ich nepouziva.

Záleží to na konkrétní aplikaci. Např. databázové servery jsou dělané tak, že když počítač v kterémkoli okamžiku přijde o napájení a na disku tedy tím pádem zůstane zapsané to, co tam v danou chvíli bylo, nedojde k poškození dat. Případně i tak, aby byla v databázi zapsaná i poslední potvrzená transakce – pokud je správně nastavený ovladač souborového systému a samotný disk (nebo RAID), tj. aby na disku bylo zapsané skutečně to, co si databáze myslí, že zapsané je.

Nebo-li nedá se obecně říci, zda data mohou být poškozena nebo nemohou – záleží na tom, zda s takovou situací aplikace počítá a zápisy na disk a fsync řadí tak, aby data na disku byla vždy v konzistentním stavu.

Ještě drobnost, nepoužíval bych termín „poškozená“, ale „nekonzistentní“. Ona při tom ustřižení napájení (nebo vytvoření snapshotu nezávisle na databázi) budou poškozená i ta data transakční databáze, která s takovým výpadkem počítá – data nebudou ve stavu, v jakém by měla být při vypnutém databázovém stroji. Rozdíl je v tom, že databáze se z takového stavu dokáže plnohodnotně obnovit a třeba dotočit transakce, které má zatím zapsané jen v transakčním logu ale ještě je nemá propsané do datových struktur.

Tu sa bohuzial dopustate extrapolacie nespravnym smerom. Predpokladate, ze na zaklade toho, ze transakcne databazy su nadizajnovane tak, ze v pripade vypadku data neostanu poskodene, ale staci prehrat transakcny log, je to tak u kazdej aplikacie.

Takyto pristup moze vyustit v smutne zistenie, ak sa na serveri bude prevadzkovat nejaka aplikacia, ktora takto tolerantna nie je, resp. nie je full-ACID. Ak mi na serveri bezi bohata zmes aplikacii, musim predpokladat, ze tam je aspon jedna aplikacia, ktora sa takto nechova a tym padom sa takto nechova system ako celok.

Predpokladate, ze […] je to tak u kazdej aplikacie.
Právě naopak, výslovně jsem upozorňoval na to, že je to speciální vlastnost transakčních databází, a většina jiných aplikací se tak nechová.

To stale neriesi hlavny problem - ze aplikacia mohla chtiac, alebo nechtiac - neflushnut data z internych buffrov akehokolvek typu do operacneho systemu. Tam potom ani tato ficura blokujuca buffre na urovni kernelu nema dosah.

Možnost freeze má vícero fs (třeba XFS) a LVM při snapshotu posílá info FS, aby se alespoň zapsal journal (extX), nebo rovnou freeze (XFS).

Ale nejlepší je používat FS přímo s podporou snapshotů, protože ten fs má veškeré informace o aktivitě a umí udělat atomický snapshot ve vhodnou chvíli (dokončení všech zápisů apod.)

Nebo mít data v DB, dobře zacházet s transakcemi a tedy mít v každém okamžiku po potvrzení transakce konzistentní data. A k zálohování DB používat nástroje k tomu určené.

FS *nema* veskere informacie o aktivite. Ma iba tie informacie o aktivite, ktore mu niekto dorucil. Problem je v tom, ze sucastou tychto informacii nie je priznak, ci sucasny stav je "transakcne korektny". Napriklad ak aplikacia zapise 8MB blok do suboru, a tento zapis sa stihne flushnut niekam po FS, takze o nom FS vie a vie ho spracovat, FS nemoze vediet, ci k tomuto zapisu neprisluchaju nejake dalsie data, ktore napr. aplikacia prave pocita. A ak ich zapise, tak bude vysledny subor z pohladu aplikacie corrupnuty, pretoze nebude obsahovat data, ktore aplikacia prave pocita, ale aplikacia napr. musela flushnut data z predosleho vypoctu, aby mala dost prostriedkov na dalsie kolo vypoctov. Zaroven vsak prave zapisany blok prepisal informacie, ktore sa odkazovali na data, ktore este prepisane neboli.

Z pohladu FS je vsetko ok, pretoze predsa do snapshotu dal vsetko o com vedel, ze je on the fly. Z pohladu aplikacie su ale data odpad, pretoze cast dat zodpoveda starsej generacii informacie, nez zvysok. Vysledkom je corrupnuty subor bez ohladu na snahu.

Idea vsetko vkladat do DB (budem implicitne predpokladat transakcnu RDBMS) je jednoducho naivna. RDBMS (ale vo vseobecnosti akakolvek ACID capable databaza) je vhodna iba na limitovane mnozstvo use-caseov. Existuje mnoho pripadov, kedy ju mozne nie je pouzit bud z dovodu ohavnosti interface-u, alebo absolutne nevyhovujuceho vykonu.

TL;DR: Snazim sa len poukazat na to, ze fakt, ze snapshotovanie funguje na DB neznamena, ze je to vseliek. V skutocnosti je to skor vynimka, nez pravidlo.

A co takhle misto celeho serveru synchronizovat pres rsync jen daný web nebo weby, coz uspori cas pri kopirovani?
A na hlavni i zalozni webový server pristupovat pres proxy server se sdilenou plovouci virtuální IP, ktera predava pozadavky na weby dle vahy?
Databáze synchronizovat ne kopirováním spojeným s možnou ztrátou dat a možnými komplikacemi s inkonzistencí, ale pres databázový cluster? A na databáze pristupovat take pres proxy?
Pribude jen jedna vrsva navic - proxy servery, ale vyhody prevazuji - konzistentni kopie databází, rychlá kopie webů, pri selhání primárních serverů proxy server automaticky prepne sama sebe a take webovy a databazovy provoz na zalozni servery, tim padem netreba resit manualni zmenu DNS pri pristupu zevnitr?
Pri pristupu z internetu muzeme pouzit nejaky failover pro verejne dns smerujici na dane proxy, takze netreba resit zmenu DNS ani pri prsitupu z internetu?
Ve vysledku velmi robustni autonomni reseni s minimalni potrebou manualniho zasahu v pripade selhani primarnich serverů.

Taky mi přijde divné synchronizovat celý server (když např. nevím, jaké jsou tam poslední aktualizace balíčků). U nás funguje velmi dobře
- rsync kopíruje soubory k webu (php, obrázky, logy), třeba jednou za 15 min.
- mysql se synchronizuje master<->master, po výpadku se změny dotáhou automaticky. V mysql musí být i sesssions.
- záložní stroj monitoruje produkční a pokud nedostane odezvu, změní DNS s krátkou platností (třeba 5 min.) tak, aby ukazovala na něj :-)

Aktualizace balíčků nebo změny konfigurace apache a spol. je třeba ručně udělat dvojmo, ale těch zase není tolik. A výhodou je, že můžu začít na záložním serveru, kde není žádný provoz, vše otestovat a pak teprve nasadit na ostrý :-)

Presne tak.

Jen u toho db failoveru, ta situace se tam hodne lisi dle daneho typu databaze, oproti tomu je prepinani samotneho fs jednoduche.

Ovšemže web proxy či DB multimaster by tam být mohly. Také LVM snapshoty/rsync či btrfs snapshoty a volume send/receive. Jenže to je právě ono: zesložitit to jde vždycky.

> A na hlavni i zalozni webový server pristupovat pres proxy server se sdilenou plovouci virtuální IP, ktera predava pozadavky na weby dle vahy?

Backup server v kanceláři není určen k běžnému provozu, a tudíž by na něj za normálního stavu neměly jít žádné requesty. Smyslem toho celého je, zajistit provoz webu v případě, že dojde k úplné havárii live serveru. Jinak řečeno, aby web nebyl po 4 dny zcela offline, ale aby se zobrazovalo aspoň něco. Třeba jen v read-only režimu, nebo prostě cokoli jen ne timeout.

>Databáze synchronizovat ne kopirováním spojeným s možnou ztrátou dat a možnými komplikacemi s inkonzistencí, ale pres databázový cluster? A na databáze pristupovat take pres proxy?

Kdyby tam byl jakýkoli cluster, tak při jakémkoli upgradu té databáze bude nutné, udělat podobné kroky i na backup serveru. Nedávno třeba pgsql 10 na pgsql 11. V tomhle případě bych musel řešit jak pgsql, tak mysql. Nevím jestli pgsql umí multimaster, myslím že jen master-slave? Nicméně, bezúdržbové by to nebylo. Spravoval jsem pár mysql databází v multimaster a když se něco podělalo (na víc dní než bylo maximum logu), tak to potom dávat dohromady, byla občas sranda (split brain).

Zde je pro mě nejdůležitější, že na ten backup server nemusím vůbec sáhnout. Na live serveru přitom často probíhají upgrady celého systému, databází i aplikace.

Jenže to je právě ono: zesložitit to jde vždycky.

Dělat věci správně neznamená je zesložitit. Vy se sice v závěru článku odkazujete na Suckless a KISS principy, ale nezlobte se na mě, asi jste je nepochopil. Cílem není to dělat tak jednoduše jak to jde, cílem je do dělat především správně a až potom jednoduše. Je na to krásný Exupéryho citát: "dokonalé není to, kam už nelze nic přidat, ale to, odkud nelze nic odebrat".

Vámi uvedené DB určitě nepřežijí kopírování datových souborů během provozu. Možná jste měl štěstí, možná jsou ty DB malé, možná tam zrovna nebyl provoz. Je možné, že ty DB jsou spíše readonly a zápis do nich jde jen s vydáním nového článku, což může být jednou za pár dnů. V takovém případě je možné, že záloha po souborech projde.

Ale na živé DB rozhodně ne a toto nelze doporučovat.

Postupy, jak správně zazálohovat DB se liší produkt od produktu. Ano, některé DB lze uvést do stavu, kdy do datových souborů nebudou zapisovat a lze je zkopírovat i nástroji typu rsync, ale tohle platí pouze za podmínky, že je zařízeno odlévání logů (viz PG PITR). A pochopitelně je nutné to testovat. (Není nic horšího, než mít aktuální base backup a 14 dnů staré logy.) Ostatně proto také existují nástroje jako pgBarman, které tyto věci automatizují a hlídají.

Podobným způsobem spravuji asi 40 serverů a řeknu vám, že je to naprosto suckless!
Nějak mi v závěru článku chybí informace, kdy naposledy jste zkusil ten web ze záložního serveru provozovat. Protože teprve to řekne, zda jste byl úspěšný nebo ne. Vám to možná připadá samozřejmé, ale čtenář by na to mohl zapomenout, když to není explicitně zmíněno.

Druhá věc je, že to podle mne nemá nic společného s orchestrací, je to jen průběžná aktualizace stand-by záložního serveru. Pod orchestrací bych si představil, že takovouhle dvojici hlavní server – stand-by server nyní budete schopen připravit na lusknutí prstu, tj. nebudete např. nikde znovu ručně vyjmenovávat, které soubory se mají vynechávat. Vy jste automatizoval zálohování, orchestrace je automatizace správy. Ale jako příklad použití rsync u je to samozřejmě hezká ukázka.

Máte pravdu, v tomto případě o "orchestraci" úplně nejde. Nicméně podobné řešení orchestrace s rsyncem funguje jinde: proxmox + PXE boot a pak se to tam natlačí právě rsyncem (tedy v místě, kde by jinak nastoupil do hry třeba puppet). Zde, kvůli jednomu backup serveru, jsem tuhle automatickou prvotní instalaci udělal ručně. Odkaz na web, který běží na tom backupserveru, nechci nikde zveřejňovat, nicméně Vám ho můžu poslat mailem.

Zalezi od databazy k databaze. Kopirovanie zivej databazy za behu je napr. na BerkeleyDB uplne legalny (a preferovany!) sposob hot backupu a offline restore replikacnych slave-ov. Existuju len dve podmienky:
1) kopirovanie prebieha po blokoch definovanej velkosti (automaticky splnene ak sa pouzije cp z coreutils)
2) logy sa skopiruju ako posledne
[3)] na restorovanom hoste sa pri spusteni vykona catastrophic restore, co sa aj tak stane automaticky, pokial nie je aplikacia velmi nestandardne nastavena

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í.

Koukám, že kritiku tu už napsali z velké části jiní. Já jen dodám heslovitě:

* Záloha by se měla číst atomicky (někdo tu navrhoval LVM snapshoty). Jinak může nastat spousta různých problémů. Mohu třeba přesouvat soubor z adresáře A do B. V adresáři A při zálohování už nebude, v adresáři B ještě nebude. To se klidně může stát, když se adresář B bude číst dříve než A. Podobný problém může nastat v různých podobách, třeba i uvnitř souboru, jak naznačujete u databází.
* Záloha by se měla zapisovat atomicky aspoň do té míry, že když exne zálohování v půlce, mám aspoň konzistentní předchozí verzi.
* V případě zálohy se může hodit i nějaká historie.
* Není mi jasné, zda na tom cílovém serveru to má i běžet, ale asi ano. Potom i nasazení na cílový server je dobré udělat ± atomicky podle potřeb. I u statického webu může být nějaké atomické řešení žádoucí, jinak v nějaký čas se může stránka odkazovat na neexistující soubory.
* Nevím, co si mám vzít z toho, že vám to funguje na 40 serverech. Nevím, co vám na nich běží, jak dlouho to takto funguje, ani jak ověřujete, že to skutečně funguje. Možná bych našel i někoho, kdo spravuje desítky serverů bez záloh a funguje mu to. V obou případech platí, až to jednoho dne fungovat nebude, může být příliš pozdě to řešit. Ale možná zjistíte, že ony „zbytečné“ nástroje nejsou až tak zbytečné.

Hezký článek o několika opšnách a use-casech nástroje rsync. Jen tu na Rootu o rsyncu asi už byly články, a lepší.

Autor by se mohl vyvarovat subjektivního hodnocení (a povyšování) svých postupů versus postupů jiných. Nakonec i kritika ostatními diskutujícími ukazuje, že autorovy postupy jsou přinejmenším pochybné.

Slovo "orchestrace" bych použil pro něco jiného.

Osobně si myslím, že kvalitní sysadmin se neměří tím, že je schopný v krátkém čase ubastlit devadesátiprocentní řešení, ale naopak tím, že dělá věci neprůstřelně, i když pomalu a na pohled neefektivně. Tím nijak nerozporuju radu, že je na každou věc používat vhodné (a nepřeinženýrované) nástroje.

Mimochodem, už ta motivace na začátku článku je taková pochybná. Jako zálohu produkčního webu použít vyřazený počítač, umístěný v kanceláři.

S tou databází je to samozřejmě blbost - nelze kopírovat za běhu databázi (minimálně ne Postgres). Resp. je to možné, za předpokladu archivace transakčních logů (ale to tu autor nezmiňuje). Pokud nechcete přijít o databázi, tak rozhodně běžící Postgres nekopírujte.

Chapu spravne, ze se kopiruje z produkcniho na backup server? Ja to povazuji za bezpecnostni riziko, protoze pokud nekdo ziska vladu nad produkcnim serverem, tak muze zlikvidovat i backup server.
Osobne jsem backup RSYNCem pres SSH resil obracene, ze backup server se pripojoval na produkcni server a data si ztahoval k sobe.

Bývaly doby, kdy na root psali články opravdoví odborníci.

Dnes koukám vezmete cokoliv. Jak už tady padlo mnohokrát přede mnou, článek popisuje nefunkční slepenec, který funguje jen náhodou. Rozhodně nejde o něco, co by bylo hodné následování.

Vidím to jako selhání redakce, že vůbec takový text vydá.