Dotaz: postgres - load ballancer

[marcelius]

Dobry den,

mam dotaz ohledne postgresql serverem a load balancerem + nejaka replikace.

Aktualne provozujeme jeden postgresql server a nekolik aplikacnych serveru. Cilem je rozlozit zatez vsech pozadavku na postgresql server. Dale bychom chtel udelat nejake "always on" reseni pomoci master/slave replikace.

Mam myslenku to udelat takhle:

aplikacni server --> load balancer --> master (synchronni replikace) slave

Jake mate vy skusenosti? Napada Vas nejake jine reseni?

Moc dekuji

Odpovědi

[Max]

My používáme Oracle RAC + standby db (odkopírovávání transakčních logů + jejich import).
Obdobně to umí PostgreSQL, tzn. dva servery + společný storage pro db + replikace na vzdálenou db/storage.
Pokud přemýšlíš nad synchronní replikací, tak to není master - slave, ale master - master a je to dosti náročné.
Zkušenosti s tím bohužel nemám, ale jsem zvědav na někoho, kdo ano. Docela mně zajímá aktuální stav PostgreSQL.
Zdar Max

[Heron]

Postgres umí fungovat v master-slave synchronní replikaci, která znamená tolik, že potvrzení transakce se klientovi vrátí až ve chvíli, kdy doběhne na slave (takže data jsou spolehlivě jak na masteru, tak na replice).

http://www.postgresql.org/docs/9.5/static/warm-standby.html#SYNCHRONOUS-REPLICATION

Nejedná se tedy o master master.

[Max]

Aha, díky za info. V tom případě by to ale mělo být náročné jak master - master řešení, ne?
Zdar Max

[Heron]

On někdo nabízí skutečné obecné master master řešení? Tedy oba (nebo i víc) stroje jsou write a je jedno, kam commitnu transkaci? To bych chtěl vidět. Muselo by se tam synchronizovat tolik věcí, že by to příliš rychlé nebylo.

Synchronní replikace jen čeká na zápis na repliku. Tedy totéž, jako poslat stejnou transkaci na dva servery. Může to jít na oba současně (jestli se to tak dělá nevím). Takže to může být jen o něco málo pomalejší, než jeden server.

Ale já s replikacemi db příliš zkušeností nemám. Pracuju ve sféře, kde je lepší mít nedostupnost než mít vadná data. Nenašel jsem spolehlivé funkční řešení, které by nepřinášelo víc problémů než užitku.

Takové to klasické na master se zapisuje a na replikách běží selecty je použitelné pouze v místech, kde nevadí lag mezi masterem a replikou (a tedy nevadí že jeden server vrátí jiné informace než druhý). A nebo na místech, kde o tomto problému ani neví a vesele vrací vadná data.

[VSi]

On někdo nabízí skutečné obecné master master řešení?

Např. Oracle RAC přesně toto umožňuje. Minimálně dřívější verze vyžadovaly shared storage (s cluster filesystémem, nebo s přímým přístupem na blockdevice), jak je to v posledních nevím.

Pokud je tlak na výkon synchronizace u konkurečních zápisů, pomůže nějaký low-latency interconnect - infiniband, případně platformy s globálně sdílenou pamětí jako je SGI Altix.

Ale já s replikacemi db příliš zkušeností nemám. Pracuju ve sféře, kde je lepší mít nedostupnost než mít vadná data. Nenašel jsem spolehlivé funkční řešení, které by nepřinášelo víc problémů než užitku.

Ono je to vždy o poměru nákladů na takové řešení - jak pořízení tak provoz/správa - vs. ten užitek. Od určité úrovně je spolehlivé funkční řešení dostupné za nákladů, které už ten užitek navíc v např. podobě "lehce" vyšší dostupnosti nevyváží.

Takové to klasické na master se zapisuje a na replikách běží selecty je použitelné pouze v místech, kde nevadí lag mezi masterem a replikou (a tedy nevadí že jeden server vrátí jiné informace než druhý). A nebo na místech, kde o tomto problému ani neví a vesele vrací vadná data.

Synchronní replika i u toho postgresu řeší právě tohle - commit write transakce čeká na potvrzení od všech replik, takže replika nikdy nevrátí data před tímto commitem.

[Max]

Poslední verze Oracle je na tom stále stejně. Ohledně RAC tedy nejlépe společný block device, který už si ohledá zápisi apod. v ASM v rámci Oracle Gridu.
Oracle samozřejmě nabízí i multimaster replikaci, i v rámci WAN, ale s tím zkušenosti nemám. Tak jako tak je vždy překážkou výkon (latence)
Zdar Max

[Heron]

Ohledně RAC tedy nejlépe společný block device

Jestli je ten společný blok device na jednom železe pro ty dva Oracle servery, tak mi není jasné, v čem je potom přínos master master replikace. Stejně to běží z jednoho disku (pole).

Resp. problém se přesouvá na storage vrstvu, jak storage vrstva zajistí master master replikaci těch block device přes více železa?

[VSi]

V této sféře se samozřejmě počítá s nějakou SAN infrastrukturou, která redundanci/replikaci a potřebný výkon standardně umí řešit. Takže ano, část problému se přesouvá na storage vrstvu. Může to být jedno pole s dual-channel architekturou, nebo typicky nějaký NetApp cluster, nebo něco jako řešení, které nabízí Pure Storage. V OSS světě jsou analogie DRBD nebo CEPH. Opět je pak na úhlu pohledu jestli tak nákladné řešení stojí za to.

[Heron]

V této sféře se samozřejmě počítá s nějakou SAN infrastrukturou

Jistě, ale ta infrastruktura bude u master master řešit úplně stejné problémy, jaké by (měl) řešil ten db server. Tím, že se to jen posune o vrstvu níž se problém nevyřešil (spíš mi přijde že právě naopak zkomplikoval, protože teď se ještě musí řešit paralelní zápis ze dvou míst do jednoho bloku - resp zabránění. Takže zámky. + k tomu ještě problémy zamykání těch transakcí v db). To už je lepší nějaká replikační proxy (Slony a spol.), který ten master master nějak zařídí (i pro PostgreSQL).

DRBD split brain jsem viděl a řešil tolikrát, že to za spolehlivé řešení ničeho nepovažuji (to jen poznámka mimo téma).

[Heron]

Slony

blbost, ten vlastně m-m neumí.

[Ivan]

Jen pro ilustraci jak to cele zacalo. Pred tim nez existoval nejaky SAN standard, nabizela IBMka DSA pole. Ta castesne kopirovala architekturu tonen ring. DSA disky mely jeden konektor na napajeni a dva konektory na data. Stejne tak DSA PCI adaptery mely dva konektory. Takze kdyz se to vsechno prokabelovalo tak vznikla kruznice, na ktere mohlo byt 28 disku a 4 adaptery (2 z kazdeho serveru). Nakonec se to posunulo tak, ze se kupovaly "obycejne" SCSI disky a ty se vkladaly do specialnich SSA ramecku.

Zamykani, konzistance dat na FS a pod to se resilo na urovni OS. To co to "pole" nabizelo bylo jen to, ze ke kazdemu disku povedou dve nezavisle datove cesty a ze kazdy disk bude napajen ze dvou nezavislych zdroju. A podobne naroky ma i ten RAC, staci mu JBOD SAN pole a dve nezevisle SAN site. I kdyz v praxi se to moc nepouziva, kdo ma penize na Oracle RAC, ten ma penize i na chytrejsi pole.

Chytrejsi low-end pole maji v sobe PCcko (s linuxem anebo z woknama) a pak maji 2 SAN adaptery, ty adaptery maji v sobe ASIC v nejakou mapovaci tabulkou. PCcko ma v sobe management s toho se pak plni ty mapovaci tabulky. Kdyz ale to PCko umre, tak ty adaptery pracuji dal - akorat uz nemuzete zasahovat do konfigurace toho pole.

Paralelni zapis bloku u RACu se resi na urovni databaze viz "Cache fusion" a "Block mastering". Zjednodusene receno se predpoklada, ze 1Gbit (10Gbit) cluster interconnect je rychlejsi nez nacteni dat z disku. Existuje sdilena hash tabulka, ktera rika, ktery node je masterem, ktereho bloku. A pokud nemam kopii bloku v cache, tak o nej pozadam jeho "mastera" a nenacitam ho z disku sam. Popsane je to napriklad zde:

http://gjilevski.com/2011/08/02/oracle-cache-fusion-private-inter-connects-and-practical-performance-management-considerations-in-oracle-rac/

http://oracleinaction.com/cache-fusion-demo/

K synchronizaci se pouziva "Pekaruv algoritmus", ktery vymyslel pan Lamport z Microsoft Research.

[Ivan]

Kecam nejmenovalo se to DSA (ta technologie) ale SSA: https://en.wikipedia.org/wiki/Serial_Storage_Architecture

[Max]

Na těch block device je ASM (share FS by Oracle pro db s možností redundance - nějako jako mirror v rámci ASM a bůh ví, co dalšího). U master-slave replikace řeší konzistenci snapshotama storage (tzn., když se dělají každou minutu, tak rollback dat max. minuta). U master/master nevím.
Jinak řešit to v rámci storage nese jednu podstatnou výhodu. Můžeš mít big storage + virtualizovat a řešit tak failover + backup v rámci storage pro všechny provozované VM + oracle nody + další app/servery.
Zdar Max

[Ivan]

Storage vrstva = SAN. Tzn. disky jsou pripojene na smyckach a kazda smycka je pripojena minimalne ke dvoum "SAN hlavam". A kazda hlava je v jine SAN siti. Jestli pole dela nejaky RAID, LVM(LUN) anebo je to jen JBOD, na tom uz moc nazalezi. Pokud je pole tupy, tak se dela mirror na urovni databaze. Samozrejme, ze muzete delat i SW raid nad dvema SAN poli.

Zdvojene je proste vsechno. Za predpokladu ze komponenty umiraji ve stylu, ze shori jasnym plamenem a nic po nic nezbyde, tak je to skutecne HA reseni (s multi-master replikace - takze je to i High Performace reseni). Problem, ze ze tato reseni jsou tak slozita, a maji tak malo instalaci, ze jsou nachylana k "systemovym chybam". Tzn, nejaka stupidni SW chyba, ktera afektuje jeden node, sebou vezme dolu cely cluster. V realu je docela diskutabilni jestli RAC vlastne zvysuje anebo snizuje dostupnost celeho reseni. Minimalne u verzi 9i a 10gR1 to bylo spise kontraproduktivni reseni - ono taky hodne zalezi na tom, jak je napsana aplikace.

PS: Dalsi kdo dela multi-master replikaci(ale bez sdilene storage) je LDAP server od IBM anebo HP Vertica(postavena na PostreSQL), ty ale asi nejsou cilene pro OTLP systemy.

[okbob]

HP Vertica má pouze Postgresový interface - ale jinak to s Postgresem nemá nic společného - vnitřek je úplně jiný - je už to nově postavená OLAP clusterová db - která v single instanci už ani negarantuje data.

[Heron]

Minimálně dřívější verze vyžadovaly shared storage (s cluster filesystémem, nebo s přímým přístupem na blockdevice), jak je to v posledních nevím.

No, takže se problém posouvá na storage vrstvu. To mi tedy jako řešení nepřipadá.

Synchronní replika i u toho postgresu řeší právě tohle - commit write transakce čeká na potvrzení od všech replik, takže replika nikdy nevrátí data před tímto commitem.

To jo, ale zase je to pomalé (pomalejší než klasické master - multislave pro selecty). Takže to řeší maximálně možnost přepnutí na vedlejší db server v případě havárie masteru.

Ono je to vždy o poměru nákladů na takové řešení - jak pořízení tak provoz/správa - vs. ten užitek. Od určité úrovně je spolehlivé funkční řešení dostupné za nákladů, které už ten užitek navíc v např. podobě "lehce" vyšší dostupnosti nevyváží.

Přesně tak. Prošel jsem mnoho řešení, nakonec se v praxi ukazuje jako nejlepší řešení single db server, který výkon zvládá (to není žádný problém), spolehlivé zálohy a údržba hw a záložní hw k disposici. V praxi ten hw zase tak často nepadá (rozhodně méně častěji, než různá replikační řešení) a i kdyby, tak se ten několikahodinový výpadek jednou za 10 let snese. Stejně i v tom DC vypínají elektriku častěji.

[VSi]

To jo, ale zase je to pomalé (pomalejší než klasické master - multislave pro selecty). Takže to řeší maximálně možnost přepnutí na vedlejší db server v případě havárie masteru.

Pomalejší než asychronní replika to přirozeně je. Pokud je ale významná část zátěže v SELECT operacích, tak je to relevantní řešení. Zápisy se proti single serveru o něco zpomalí (na dnešním HW a 10Gb nebo infiniband síti to není tak hrozné), ale mám možnost rozložit zátěž způsobenou složitými SELECT dotazy na několik dalších uzlů. Není to pro všechny případy, ale pro řadu aplikací to může být dobré řešení.

V praxi ten hw zase tak často nepadá (rozhodně méně častěji, než různá replikační řešení) a i kdyby, tak se ten několikahodinový výpadek jednou za 10 let snese. Stejně i v tom DC vypínají elektriku častěji.

S padáním replikačních řešení by se tedy dalo polemizovat. Já ke spokojenosti používám DRBD - v případě selhání HW není výpadek několikahodinový (s případnou ztrátou dat od poslední zálohy), ale v minutách. Jinde u postgresu používám alespoň asychronní replikaci a uchovávání WAL jako formu kontinuální zálohy. To vypínání elektriky z velké části řeší právě tak replikace, alespoň přes různé sály v DC. U komerčních replikovaných SAN lze slýchat různé story o nespolehlivosti, ale při objektivním pohledu to za předpokladu kvalifikované správy prostě funguje.

[Heron]

Já ke spokojenosti používám DRBD - v případě selhání HW není výpadek několikahodinový (s případnou ztrátou dat od poslední zálohy), ale v minutách.

Já už viděl tolik splitbrainů (v režimu primary / secondary), že DRBD neberu.

Jinde u postgresu používám alespoň asychronní replikaci a uchovávání WAL jako formu kontinuální zálohy.

JJ, tam kde to jde, tak online backup, jinde snapshoty těch db serverů. To je jasný.

U komerčních replikovaných SAN lze slýchat různé story o nespolehlivosti, ale při objektivním pohledu to za předpokladu kvalifikované správy prostě funguje.

U jednoho nejmenovaného produktu jedné významné firmy prostě suše oznámili, že jejich zálohovací řešení prostě nefunguje, protože u produktu jiné významné firmy nefunguje oznamování změněných bloků. Takže všechny inkrementy jsou v ...

Kdyby se za ty peníze, co stál ten nefunkční soft koupilo další železo, a rozhodila by se tam záloha třeba z toho online backupu, tak se pro bezpečí dat udělá lépe. Jenže to nemá dostatečně cool rozhraní s barevnými grafy.

---

Sakra, už ty moje komentáře začínají připomínat Jendu, když mluví o bezpečnosti a CVE. Ale nemůžu si pomoct, spolehlivě funguje OSS dostatečně prověřené verze, komerční soft v naší cenové kategorii (tzn 100tis za licenci) prostě nefunguje. Možná funguje nějaké superdrahé řešení za miliony, ale jsem si jist, že kdyby se tytéž peníze vrazily do HW a řešení se postavilo na OSS prověřených softech, tak se pro bezpečnost dat udělá víc.

[Max]

Co vím, tak my poptáváme řeší na klíč s certifikací. Prostě je shora vyžadována certifikace + mít zakoupený support.
Navíc jsou u nás samí windows správci, takže je třeba řešení formou klikačky, jinak bych se z toho mohl zbláznit ještě víc, než teď, protože by to celé bylo stále na mně, což je i teď, ale tak nějak doufám, že nebude.
Zdar Max
PS: druhá věc je, že se také děje to, že se pořídí nějaké řešení, to i firma nainstaluje, zaškolí a pak nám je to předáno pod správu, ale jak člověk do toho nevidí, neinstaloval to, tak sebemenší problém trvá vyřešit docela dlouho.

[VSi]

Já už viděl tolik splitbrainů (v režimu primary / secondary), že DRBD neberu.

V režimu primary / secondary by splitbrain měl vzniknout jen velmi těžko vzhledem k tomu, že na secondary se až do failover okamžiku přímo nezapisuje. Až dojde na failover, secondary zajistí shození původního primary a přepne se. Zpět to řeším ručně. Pokud se dobře nakonfiguruje cluster manager, tak by podobné situace z principu neměly vznikat. Nevím o jaké šlo verze, já to používám poslední asi 3 roky, kdy už je jaderná část DRBD v upstreamu.

U primary / primary je to horší, při určitém pořadí spadnutí a spuštění uzlů k split-brain může dojít i když není přerušená komunikace mezi nimi, proto ho nakonec raději nepoužívám.

Ale nemůžu si pomoct, spolehlivě funguje OSS dostatečně prověřené verze, komerční soft v naší cenové kategorii (tzn 100tis za licenci) prostě nefunguje. Možná funguje nějaké superdrahé řešení za miliony, ale jsem si jist, že kdyby se tytéž peníze vrazily do HW a řešení se postavilo na OSS prověřených softech, tak se pro bezpečnost dat udělá víc.

Ano, řada "entry-level" komerčního SW a hlavně HW funguje mizerně, a OSS řešení může v takovém segmentu dopadnout lépe. Relace 100tis za licenci nebo nižší stovky tisíc za HW jsou entry-level. U řešení "za miliony" ale často OSS nic se srovnatelnými parametry nenabízí; nebo to nikdo nenabízí jako prověřené řešení se supportem, což ve větším měřítku prostě je riziko. U velkých storage má dobře nakročeno CEPH, jeho nasazení pod OpenStack, a tam bych tipoval že dost velkou roli sehrála dostupnost komerčního suportu od Inktank (pohlcen RedHat-em). Nicméně koupit NetApp MetroCluster je pořád "jistota".

[Heron]

Nevím o jaké šlo verze, já to používám poslední asi 3 roky

Tohle je tak 5 let staré. Bohužel to nemá adekvátní servis a zavolají jen když je průser.

U řešení "za miliony" ale často OSS nic se srovnatelnými parametry nenabízí

Tak ono je otázka, zda je to potřeba. Nechci za každou cenu odporovat, ale my provozujeme několik řešení na úrovni ČR, kde jeden produkt má share tak 30%, druhý skoro 50% a třetí někde mezi tím.

Na toto nasazení pro ČR bohatě stačí OSS a (pro vás) levné servery se vyloženě nudí. Toto hw řešení suma sumárum asi tak za 3M by jakš takš stačilo pro 100% ČR (kdyby se to optimalizovalo, tak i pro SR).

(Chápu, že v české diskusi má kde kdo servery pro stovky miliard uživatelů, ale mě ČR bohatě stačí.)

U velkých storage má dobře nakročeno CEPH

Mám to v todo, zatím nebyl dostatek času.

[VSi]

... (Chápu, že v české diskusi má kde kdo servery pro stovky miliard uživatelů, ale mě ČR bohatě stačí.)

Já souhlasím, že často se v korporátní i státní sféře používají předimenzovaná a zbytečně drahá HW řešení.

Ale tohle přece není primárně o počtu uživatelů nebo geografickém zaměření. Rozhodující je typ aplikace - objem dat a povaha operací nad nimi, zejména nakolik je možné (a účelné) náročné operace přesunout mimo databázi. Pokud mám systém, se kterým pracují ve špičce současně tisíce až desítky tisíc přihlášených uživatelů a databáze musí řešit náročné transakční a analytické úlohy, tak může skutečně vyjít, že OSS a komoditní HW neposkytuje řešení. Navrch takové aplikace obvykle nevznikají z roku na rok, ale mají poměrně dlouhou historii sahající do doby, kdy třeba ten Postgres nebyl zdaleka v takovém stavu jako teď, a tím je dána vazba třeba na Oracle.

Některé vaše úvahy sdílím, ale představa, že celý segment enterprise HW je kult do kterého všichni sypou takové peníze ze zvyku, když by se to snadno dalo dělat levněji a lépe, je imho mimo realitu.

[Max]

Jsem toho názoru, že OSS stačí, ale :
- nejsou lidi
- mgmt chce certifikované a supportované řešení
- není time měsíce testovat nějaké řešení, zda to splní očekávání :-/.

Jako příklad si vezmu do huby Kapicu :
- nejdříve KVM nad btrfs + DRBD + dopisoval a opravoval ručně HA, aby to fungovalo + si kompiloval vlastní jádro kvůli drbd a btrfs (v době, kdy jsem u něj byl na čumendo, se mu po simulovaném pádu jednoho nodu automaticky nenahodily KVM na druhém a byl lehce překvapen s tím, že na to ještě koukne)
- mezitím začal testovat CEPH, který se mu nepodařil rozjet
- dále začal nasazovat glusterfs a migrovat na něj věci, ale našel pár nepěkných mušek
- aktuálně testuje, nebo už možná nasazuje Scheepdog

Je to borec, je nabušený vědomostma a má v hlavě, ale když to vezmu, stále řeší jednu a tu samou věc (lokální KVM + storage cluster/failover).

Osobně jsem zkusil naladit FreeNAS a narazil jsem na několik problémů : stará verze NFS, úplně idiocké default hodnoty + to má stejně nepěkné bugy. Teď už bych do toho nešel a naladil bych čisté FreeBSD.
Každopádně i trápení s Areca řadičem jsem zažil a ty jsi obdobné problémy měl taktéž.
Dále jsem testoval oVirt a do produkce bych si ho troufnout taktéž nedal.

Kdybychom jeli jen linuch, tak asi ok, ale když jedeme i Oracle, Exchange, windows, MSSQL, Citrix, tak fakt ne. Člověk by řekl, že nasadí Proxmox, ale pak čte lidi v diskusi, co tvrdí, že windows na tom občas zlobí (třeba jsou extrémně líný) a na ofiku forku si na to stěžují.
V práci řešíme to samé, a jsem rád, když nakonec koupíme NetApp, protože je to all-in-one s jejich FS WAFL (což je obdoba ZFS) + vše je redundantní, sladěné, klikací a cena je ve finále hodně dobrá (co jsme dostali naposledy cen. nab na dva storage o 2x 80TB RAW, tak jsem byl mile překvapen).

Ale to jsem se už hodně odklonil od tématu. Já tím chtěl jen říci, že někdy OSS není úplně tak rentabilní, nebo neexistuje vhodná OSS alternativa :-/.
A nebo jsem jen nevidomý a potřebuji, aby mi někdo rozsvítil oči.
Zdar Max

[Heron]

Jako příklad si vezmu do huby Kapicu

Aleš má výhodu v hromadě času a tento čas vrací ostatním v podobě poznámek v blozích a na své wiki.

Nevidím do jeho provozu, ale tipuju, že určitě není nutné nasazovat takto složité systémy a že to dělá spíš proto, že ho to baví a navíc si tím zjednodušuje práci. Proč ne a jsem za jeho činnost moc rád.

Osobně jsem zkusil naladit FreeNAS a narazil jsem na několik problémů : stará verze NFS, úplně idiocké default hodnoty + to má stejně nepěkné bugy. Teď už bych do toho nešel a naladil bych čisté FreeBSD.

No otázkou je, zda to byl dobrý krok. Některé moje produkční storage jsou obyč linuxy exportující NFS a tím to hasne. Normální ext3/4 (podle stáří), exportfs a konec. Potom se to připojí do vmware a běží na tom produkce. Proč vymýšlet složitosti? Když se to pokazí, tak nastavit druhej linux s NFS je otázka chvilky, nahrnou se tam image ze záloh (resp. my to mámě udělané přes replikace).

Jinde mám pro ulehčení btrfs, na tom valím kontejnery (pro testy). Opravdu nevidím důvod pro nasazení FreeNAS (teď nemyslím proto, že je to BSD, ale proto, že je to zase nějaká vrstva navíc - i kdyby existovalo FreeBTRFS, tak nevidím důvod pro to to instalovat).

Kdybychom jeli jen linuch, tak asi ok, ale když jedeme i Oracle, Exchange, windows, MSSQL, Citrix, tak fakt ne. Člověk by řekl, že nasadí Proxmox, ale pak čte lidi v diskusi, co tvrdí, že windows na tom občas zlobí (třeba jsou extrémně líný) a na ofiku forku si na to stěžují.

Jasně, tak máš tam větší mix věcí a je to složitější, ale proboha proč zase proxmox? Nainstaluju linux, kvm už tam je, přidám qemu a věci kolem, nastavím síť a skončil jsem. Když si chci trochu ulehčit život, tak přidám libvirt. Nemusím řešit další vrstvy v ovirtu, proxmoxu apod. kravinách. (Čtvrt roku mě volá jeden člověk, kterému v proxmoxu něco neběží a ptá se mě, na co má kliknout. Já nevím, já to nikdy neviděl. Ale na cli by to měl během jednoho dne. Stejně je to jen virtálka, někde je image disku a někde jsou definice vmka. Jestli to má v bash skriptu a pouští qemu-kvm, tak je to přece jedno.)

Ale to jsem se už hodně odklonil od tématu. Já tím chtěl jen říci, že někdy OSS není úplně tak rentabilní, nebo neexistuje vhodná OSS alternativa :-/.

Tak to si musí každý spočítat sám. Já se pohybuju v OSS světě a komerční svět vnímám tak jak jsem popsal. Řekl bych, že jsme přesně v té oblasti, kdy je ten software sice relativně drahý na pořízení, ale současně příliš levný na to, aby něco uměl. Takže to přináší vlastně jen nevýhody. Jestli si někdo spočítá, že se mu software vyplatí, tak ať. Mě to zatím přináší jen problémy a ty peníze za ten soft bych raději viděl jinde.

[Max]

ad Aleš : se vším souhlas, já jen chtěl naznačit, že to není tak easy a evidentně to nejde napoprvé ani napodruhé.
ad proxmox/oVirt : je to jednoduché, jednak ty featurky, co to má + odladěná nastavení, dále je tu šanci, že s tím kolegové windowsáci budou umět
Jinak jen tak mezi náma, u nás ve firmě sice jedeme Oracle, ale nepoužíváme u něj nic speciálního, uživatelů je něco přes tisíc, přes db teče úplně vše (automatizované maily, edi zprávy apod.), ale převážné výkonové faily jsou v samotných selectech. Jednou za čas si jeden programátor najde čas a řeší nějaké dlouho běžící selecty a stává se, že předělá select, co běží 30min na nějaký, co běží 1min apod.
Mno a v současné chvíli máme na Oracle navázaný kromě našeho IS i sap, dms i objednávkový systém, takže jsme pěkně zaháčkovaný.
Zdar Max

[Heron]

ale převážné výkonové faily jsou v samotných selectech

Ano. U nás někdy bohužel převládne názor "tak nakoupíme ssdčka" místo toho, aby se to napsalo lépe. Naštěstí, ty chyby mají mocninnou nebo lépe exponenciální složitost, takže ani ssd neudrží krok moc dlouho a stejně se to musí nakonec optimalizovat. To potom časy běhu dotazů spadnou klidně 1000x (resp. složitost spadne na log, nebo rovnou konstantní). Ne, že bych měl něco proti ssd, ale vadí mi, když makají zbytečně na něčem hrůzném.

[rich]

Radeji si precti co to ten RAC vubec je http://www.oracle.com/technetwork/products/clustering/rac-wp-12c-1896129.pdf

[Max]

Máš pravdu.
Jinak master - master jde "jednoduše" postavit pomocí storage clusteru. Zrovna vybíráme nějaké řešení storage a zjišťovali jsme i tuto možnost (nakonec do toho nepůjdeme). Podmínkou je mít mezi dvěma serverovnama aspoň 4 optické páry(aby bylo řešení mezi lokalitama odolné vůči výpadků dvou jakýkoli síťových prvků) + storage, co to dají (teď máme v hledáčku i Netapp).
Nad takovým storage už můžeš mít x nodů v rámci více lokalit.
V rámci storage pak můžeš dělat konzistentní snapshoty(teď nevím, jakým způsobem je předáván flush virtuálům) v různých intervalech (držet třeba posledních 20 snapshotů po minutě, posledních 10 snapshotů po 3h a posledních 5 snapshotů po 24h apod.). + mít ještě bokem pro jistotu standby.
Zdar Max

[Sten]

Postgres umí master-master replikace, ale typicky se to dělá přes divide & conquer, protože cokoliv jiného je, jak správně uvádíte, buď pomalé nebo náchylné na konflikty.

[EtDirloth]

Postgresql nevie genericku asynchronnu master-master replikaciu, kde by bolo jedno, na ktory node sa zapise. Dokonca ani hot-standby replika (slave) nie je uplne transparentne pouzitelna ako load-balancing node, pretoze aj citanie z nej moze zlyhat pri subehu s niektorymi typmi zmien na master node.

Zaujimalo by ma, ako moze pomoct divide & conquer s prekonanim fundamentalnych problemov master-master redundancie akym su riesenie konfliktov a split-brain.

[lazywriter]

Postgres rozhodně NEumí běžet víc instancí serveru nad společnými daty. A kdo to zkusí, tak se rychle setká s poškozenou databází.

[Max]

Máš pravdu, spletl jsem se. Sami to mají na wiki : Shared Storage
A EnterpriseDB to také neumí : Does Postgres Advanced Server support RAC?
Tímto se omlouvám za mystifikace a děkuji za upozornění.
Zdar Max

[frm]

priklad takoveho reseni:

http://linux.xvx.cz/2014/10/loadbalancing-of-postgresql-databases.html

takove snahy mne ujistuji v tom, ze nejrozumnejsi je to , co doporucuje pan Stehule:

dej tam minimalne 32 GB pameti a rychle harddisky

[okbob]

Rozložit zátěž na synchronizované postgresí servery v režimu master/master mi přijde jako dost nešťastný nápad. Samozřejmě, že záleží na intenzitě zápisu, pokud je 99% čtení, tak by to mohlo i fungovat - ale jinak má synchronizace takovou režii, že se to nemůže vyplatit - navíc díky synchronní replikaci N (N je počet serverů) snižujete dostupnost - nebo musíte mít dynamické zapínání/vypínání serverů, které je dost pracné nakonfigurovat a uřídit. Provozovat synchronizovaný cluster má smysl jen v případě, že nemůžu sáhnout do aplikace. Něco jiného je cluster nesynchronizovaných databází (serverů), kdy N zákazníků mám v jedné databázi - a v případě problémů s výkonem N snížím, a přidám nové servery. To, je řešení, které skutečně škáluje - a navíc výpadek serveru Vám (když už máte více serverů) ovlivní jen malé procento zákazníků. Takhle fungoval Skype nad Postgresem, takhle fungují např. GoodData nad Postgresem.

Synchronizace je nezbytná, když nemůžete sáhnout do aplikace - jinak je to jedno z nejhorších možných řešení - skvělé pro dodavatele hw - komplikované, vyžadující ohromný výkon a tudíž drahé, luxusní.

[lazywriter]

Na nějakou konkrétní radu je to poměrně málo informací. Co je důvodem toho požadavku? Výkon, spolehlivost, bezpečnost? Jaká je struktura dotazů - více selecty nebo změny dat (v tom případě, víc update nebo jenom inserty)? Kolik se připojuje klientů (procesů) v jednu chvíli. Kolik a jak dlouhých dotazů se provádí. Jaká je současná zátěž serveru (i/o, cpu, memory)?

Obecně, v případě hodně klientů, kteří dělají málo dotazů (např. jen desítky za vteřinu) stačí před master postavit pgBouncer a pokud je dost SELECTu, tak je přesměrovat na jeden dva slavy.