Spouštění úloh na pozadí - zálohy a workflow

[Mrkev 42]

Ahoj,

řeším zálohování a hledám nástroj na postupné spouštění skriptů v nějakém workflow.

Cílový stav:

• Mám k dizpocici hlavní server, který to celé řídí.
• Mám databázový server, na kterém potřebuju spustit skript, který udělá lokální zálohu toho serveru na sebe sama. Ta běží dlouho (hodinu až tři).
• Až to doběhne, tak potřebuju serveru se zálohami říct, aby si stáhl zálohy z databázového serveru. ( opět hodina běhu ).
• Až doběhne stažení zálohy, tak potřebuju říct testovacímu server, že má zahodit svoje data a natáhnout na sebe data ze zálohovacího serveru.
• Servery na sebe nevidí - mimo těch popsaných průstupů.

Hledám nějaké pěkné řešení, které dokáže pravidelně spouštět tři navazující skripty na různých strojích a reportovat, že se to povedlo či ne.

Zkoušel jsem Ansible a AWX (umí pěkně pravidelně spouštět úlohy na vzdálených serverech), ale spadlo na tom, že zálohovací skript běží přes hodinu.

Předpokládám, že existuje už nějaký software, který takový workflow řeší, ale neznám ho.

Nějaké nápady?

M

[Reklama]

[czechsys]

Mate v uvaze velkou chybu. Pokud trva zaloha db 1-3h, tak zaloha na disku neni konzistentni.

Pouzijte replikaci/snapshoty apod.

Vetsina slusnych backup programu navic ma pre-backup a post-backup faze. Anebo neco jako rundeck.

[koo5]

Taky nemam odpoved uplne k veci  Ale nedavno jsem si hral s takovou append-only databazi nad IPFS: https://github.com/koo5/demonitor
Na nekolika pocitacich pustim tuhle vec, a vsechny nody sdileji jeden log, aniz by na sebe videly, propoji se pres public ipfs nody.
Mam tam logiku ze podle konfigurace se na nejake node pravidelne spousteji nejake checky a na ostatnich nodach se vysledky kontroluji, a dalo by se to ruzne rozvinout ..
Ale je to jen nedotazeny experiment.

[lazywriter]

Pokud se jedná o zálohy databáze (jak jsem z dotazu pochopil, nebylo ani řečeno o jakou konkrétně se jedná), tj. ne filesystém, tak s konzistencí není problém, prototože dump se pouští v transakci.
Dále, není jasné "Servery na sebe nevidí - mimo těch popsaných průstupů". Jedná se o přístup do databáze nebo třeba i ssh? Jinak, dump databáze lze udělat i vzdáleně (např. rovnou na cílový server). Pak je další seskriptování jednoduché a stačí to víceméně poskládat třeba v jakémkoliv oblíbeném shell skriptu.

[Mrkev 42]

Díky za odpovědi.

Mate v uvaze velkou chybu. Pokud trva zaloha db 1-3h, tak zaloha na disku neni konzistentni.

Díky za poznámku.
I snapshot může trvat hodinu až tři hodiny. Je to zrovna tenhle případ.
(mysql i postgresql mají snapshotting, udělají snapshot a pak můžou dlouho kopírovat v rámci lokálního disku)

Vetsina slusnych backup programu navic ma pre-backup a post-backup faze. Anebo neco jako rundeck.

Díky za tip na Rundeck.

Umí Rundeck počkat, až doběhne akce na vzdáleném serveru? Dokáže se znovu připojit a počkat na dokončení skriptu i v případě, že se SSH spojení rozpadne? Podle návodu to není zřejmé.

Užít pre-backup a post-backup fáze ze zálohovacího SW by znamenalo, že se zálohovací server musí připojit někam, kde udělá navazující akce. To není úplně pěkné, protože nechceme, aby databázový server měl přístup k zálohám či jinam. ( v případě úspěšného útoku na bychom přišli o databázový server i o jeho zalohy ).

Proto hledám nějaký pěkný nástroj, který tohle dokáže "zorchestrovat".

[Reklama]

[Mrkev 42]

Dále, není jasné "Servery na sebe nevidí - mimo těch popsaných průstupů". Jedná se o přístup do databáze nebo třeba i ssh? Jinak, dump databáze lze udělat i vzdáleně (např. rovnou na cílový server). Pak je další seskriptování jednoduché a stačí to víceméně poskládat třeba v jakémkoliv oblíbeném shell skriptu.

Díky za poznámky.

Snažím se držet servery oddělené, co nejvíc to je možné.
Při řešení tedy není možné předpokládat přístup každý s každým, některé na sebe nevidí, apod. Pro řešení to asi není důležité.

Seskládat  v oblíbeném shell skriptu to je možné - původní řešení je hromada shellových skriptů slepených dohromady a běží to úspěšně pár let.

Problém se shell skripty nastane v okamžiku, když se něco pokazí a hledáme ve kterém kroku se to pokazilo. Pak by nějaké pěkné rozhraní orchestrátoru pomohlo. - Něco, jako RunDeck, či Ansible Tower.  Oba mají ale své limity a tak hledím, jestli neexistuje alternativa o které nevím.

[k3dAR]

[...] původní řešení je hromada shellových skriptů slepených dohromady a běží to úspěšně pár let.

Problém se shell skripty nastane v okamžiku, když se něco pokazí a hledáme ve kterém kroku se to pokazilo. [...]

ty skripty muzou ukladat do souboru/ů co uz provedli, centralni skript pak podle toho pozna ze muze prejit na dalsi krok, pri preruseni (chyba skriptu, crash ci reboot server, cokoliv), ty soubory tam stale jsou a bude videt kde to skoncilo... nezapomenout je mazat po uspesnem dalsim kroku, nebo celem cyklu, pripadne jeste prikladat info o PID daneho procesu, pak na centrale poznas ze sice jeste neni soubor "krok3-hotovo.txt", ale  zaroven ze nebezi proces PID ulozenej v krok3-start.pid atd..

[czechsys]

Pokud se jedná o zálohy databáze (jak jsem z dotazu pochopil, nebylo ani řečeno o jakou konkrétně se jedná), tj. ne filesystém, tak s konzistencí není problém, prototože dump se pouští v transakci.

V jaky transakci? Treba postgresql dump je cisty select, co je na tom transakcniho? Jako, ze to zamkne celou db, aby to udelalo zalohu, aby se nezmenilo nic v tabulkach behem dumpu?

[czechsys]

Užít pre-backup a post-backup fáze ze zálohovacího SW by znamenalo, že se zálohovací server musí připojit někam, kde udělá navazující akce. To není úplně pěkné, protože nechceme, aby databázový server měl přístup k zálohám či jinam. ( v případě úspěšného útoku na bychom přišli o databázový server i o jeho zalohy ).

Proc by mel mit db server pristup na zalohovaci server, kdyz veskere akce provede zalohovaci server? Pull metoda.

[SB]

Proc by mel mit db server pristup na zalohovaci server, kdyz veskere akce provede zalohovaci server? Pull metoda.

Jak je to s bezpečností, když se zálohovací server dostane na všechny zálohované servery?

[Ondřej Kolín]

Nevymyslel bych kolo a snazil bych se nasadit na zalohovani nejake hotove reseni. Ja jsem v minule praci spokojene pouzival bacula. Nechate proces bezet pod nejakym uzivatelem a pripadne mu pres sudo date pristup na konkretni skripty, ktere pro zalohovani potrebujete.

Samozrejme umi spoustet skripty pred i po zalohovanim.

[czechsys]

Proc by mel mit db server pristup na zalohovaci server, kdyz veskere akce provede zalohovaci server? Pull metoda.

Jak je to s bezpečností, když se zálohovací server dostane na všechny zálohované servery?

Rozhodne lepe, nez kdyz se vsechny zalohovane servery dostanou na zalohovaci server.

[Death Walker]

Pokud se jedná o zálohy databáze (jak jsem z dotazu pochopil, nebylo ani řečeno o jakou konkrétně se jedná), tj. ne filesystém, tak s konzistencí není problém, prototože dump se pouští v transakci.

V jaky transakci? Treba postgresql dump je cisty select, co je na tom transakcniho? Jako, ze to zamkne celou db, aby to udelalo zalohu, aby se nezmenilo nic v tabulkach behem dumpu?

Postgres nie je mysql aby koli kazdej kravine zamykal. Pri update neprepisuje povodny riadok ale ho zapise na koniec tabulky. Povodny riadok, ak sa uz nenachadza v ziadnej transakcii, oznaci ako zmazany. Pri najblizsom vacuum sa fyzicky zmaze. Alebo autovacuum, co pride skor.

Takze dump z postgresu je v stav serveru, ked zacala transakcia. Popri tom moze zbytok procesov prepisovat, zapisovat.

[Death Walker]

Proc by mel mit db server pristup na zalohovaci server, kdyz veskere akce provede zalohovaci server? Pull metoda.

Jak je to s bezpečností, když se zálohovací server dostane na všechny zálohované servery?

No, ak je to spravne nastavene tak utocnik sa moze dostat najskor na db server (napr, prostrednictvom aplikacneho servru). Potom teoreticky az na zalohovaci. Ale ak pristupuje zalohovaci server na db, tak je malo pravdepodobne ze napadnuty db sa dostane na zalohy - nema pristupy.

Zalohovaci je dobre zriesit tak ze na tie db servre ma pristup pod uzivatelom, ktory ma len nevyhnutne prava k tomu co potrebuje - select a nic viac.  Tym padom zalohovaci server nemoze modifikovat db server.