Hlavní navigace

Vlákno názorů k článku Orchestrujeme pragmaticky: bez zbytečných nástrojů, s pomocí rsync od anonym - A co takhle misto celeho serveru synchronizovat pres...

  • Článek je starý, nové názory již nelze přidávat.
  • 29. 1. 2020 7:24

    bez přezdívky

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

  • 29. 1. 2020 10:12

    alfi .

    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ý :-)

  • 29. 1. 2020 11:27

    czechsys

    Presne tak.

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

  • 29. 1. 2020 12:28

    Jan Molič

    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.

  • 30. 1. 2020 11:36

    Heron

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