Failover řešení pro Debianí webserver

[ioku]

Dobrý den,
 ve firmě máme VPS od Wedosu, kde nám běží Debianí webový server. Nyní vymýšlíme nějaké failover řešení a nejlepší zatím vypadá pořídit další dvě VPS, kde přístupový bod A bude směrovat požadavky pomocí Pound nebo HAproxy na webserver B. Pokud se bude webserver B updatovat nebo se s ním cokoliv stane, tak se dá v řádu minut přepnout provoz na záložní server C, který má stejná data jako B.

                     A
                   /    \
                 B --> C

To bylo nastínění situace a teď otázky:

• Databáze na B i C budou fungovat lokálně, takže je potřeba nějak propagovat změny provedené na B do C, aby byla aktuální. Jak to udělat? Existuje nějaký inkrementální mysqldump?
• U wedosu se při pořízení VPS připlácí za IPv4 adresu. Stačilo by, aby pouze A měl IPv4 a B i C IPv6? Respektive, jak funguje přeposílání požadavků v Poundu nebo HAproxy? Tváří se jako by přes A vůbec neprošly?
• Neznáte nějaký nástroj na porovnání verzí snapshotů v Debianu? Něco ve stylu https://en.opensuse.org/Portal:Snapper a aby se to dalo použít na ext4?
• Pokud máte nějaké lepší řešení, kde nebude třeba pořizovat další dvě VPS, tak to také uvítám, ale tohle řešení má zase tu výhodu, že použitím směrovacího uzlu lze případně dokoupit další servery a použít směrovač jako loadbalancer.

Děkuji za všechny odpovědi.

[Reklama]

[to_je_jedno]

Tohle resite a pritom mate hosting na wedosu? Well...

[Sten]

• master-slave replikace
• Nevím, jak u HAproxy nebo Poundu, ale pokud tam dáte nginx jako reverzní proxy (když jde pouze o webový server), tak to fungovat bude.
• snapper
• To záleží, na co ten failover máte. Proti výpadku celé serverovny evidentně fungovat nebude.

[Mirek Prýmek]

@ioku: díky za hezký a praktický téma, jsem zvědavý na odpovědi a diskusi

master-slave replikace

Máš zkušenosti z produkce? Dá se u MySQL snadno slave povýšit na master (když master umře definitivně) a za běhu mu přidat nový slave? A jaké jsou zkušenosti z produkce, funguje to dobře? Nezakucká se to někdy kvůli replikaci?

To záleží, na co ten failover máte. Proti výpadku celé serverovny evidentně fungovat nebude.
[/list]
...ani proti výpadku uzlu A

Docela by mě zajímalo, jaká přesněji úvaha za tímhle návrhem architektury byla. Má jenom umožnit updatování uzlů B a C s tím, že A se updatovat nebude vůbec (to není posměšek, může to klidně tak být)?

Proti umření stroje jako takového (na nějaké nízké úrovni) to nechrání, protože pravděpodobnost umření A je potom stejná jako původního jednoho uzlu.

[Jan Forman]

GALERA CLUSTER FOR MYSQL to určitě vydrží... 

@ioku: díky za hezký a praktický téma, jsem zvědavý na odpovědi a diskusi

master-slave replikace

Máš zkušenosti z produkce? Dá se u MySQL snadno slave povýšit na master (když master umře definitivně) a za běhu mu přidat nový slave? A jaké jsou zkušenosti z produkce, funguje to dobře? Nezakucká se to někdy kvůli replikaci?

To záleží, na co ten failover máte. Proti výpadku celé serverovny evidentně fungovat nebude.
[/list]
...ani proti výpadku uzlu A

Docela by mě zajímalo, jaká přesněji úvaha za tímhle návrhem architektury byla. Má jenom umožnit updatování uzlů B a C s tím, že A se updatovat nebude vůbec (to není posměšek, může to klidně tak být)?

Proti umření stroje jako takového (na nějaké nízké úrovni) to nechrání, protože pravděpodobnost umření A je potom stejná jako původního jednoho uzlu.

[Reklama]

[moutzl]

Mysql cluster s dvema nodama, 2x apache + memcached jako workery, pred nima nginx reverse proxy.
funguje fajn, neresi pad providera

[Sten]

master-slave replikace

Máš zkušenosti z produkce? Dá se u MySQL snadno slave povýšit na master (když master umře definitivně) a za běhu mu přidat nový slave? A jaké jsou zkušenosti z produkce, funguje to dobře? Nezakucká se to někdy kvůli replikaci?

Dá se přepnout snadno (stačí vypnout replikaci a MySQL se stane master, pro ostatní slavy je pak nejjednodušší to udělat změnou lokálního DNS). Funguje to spolehlivě, původní master je ale po obnově vhodné vymazat, nastavit jako slave a spustit synchronizaci, protože se málokdy dokáže srovnat s tím, že už není master. Zkoušel jsem i master-master replikaci, ale tam se to rozpadalo na můj vkus příliš často (replikace není ACID).

Docela by mě zajímalo, jaká přesněji úvaha za tímhle návrhem architektury byla. Má jenom umožnit updatování uzlů B a C s tím, že A se updatovat nebude vůbec (to není posměšek, může to klidně tak být)?

Aktualizace lze řešit třeba rotací uzlů.

Proti umření stroje jako takového (na nějaké nízké úrovni) to nechrání, protože pravděpodobnost umření A je potom stejná jako původního jednoho uzlu.

Ta pravděpodobnost umření není stejná, server často umře/vypadne na přetížení (uswapuje se, dojde RAM nebo místo na disku, deadlocknou se procesy ap.), vůči čemuž je proxy node, kde neběží koncová (a náročná) aplikace, mnohem odolnější.

[Mirek Prýmek]

Ta pravděpodobnost umření není stejná, server často umře/vypadne na přetížení (uswapuje se, dojde RAM nebo místo na disku, deadlocknou se procesy ap.), vůči čemuž je proxy node, kde neběží koncová (a náročná) aplikace, mnohem odolnější.

Jasne, to jsem myslel tim "na nějaké nízké úrovni". Proto se na to ptam, jaka presne uvaha tomu predchazela. Tyhle vys-urovnovy problemy totiz jde resit i jinak (ulimit, oddeleny partitiony, chrooty, kontejnery, ...).

[j]

@ioku: díky za hezký a praktický téma, jsem zvědavý na odpovědi a diskusi

master-slave replikace

Máš zkušenosti z produkce? Dá se u MySQL snadno slave povýšit na master (když master umře definitivně) a za běhu mu přidat nový slave? A jaké jsou zkušenosti z produkce, funguje to dobře? Nezakucká se to někdy kvůli replikaci?

Ja mam zkusenost jednu vlastni (spis pokusnou, vicemene jsem si hral) a pak nekolik zprostredkovanych. Nikdy vice. Replikace na MySQL (ale nejen tam) je jak cerna magie a woodoo dohromady. Chvilu to funguje, pak se to rozesere a davat to dokupy je nocni mura kohokoli, kdo to nekdy potreboval. Neni vetsi poteseni, nez kdyz ma clovek v kazdy databazi jina data, a musi resit, ktera jsou ta spravna ...

Kdykoli sem o tom s nekym mluvim, tak mi rek, ze si dela dumpy, a kdyz prijde o par dat, ze se svet nezbori.[/list]

[DK]

@ioku: díky za hezký a praktický téma, jsem zvědavý na odpovědi a diskusi

master-slave replikace

Máš zkušenosti z produkce? Dá se u MySQL snadno slave povýšit na master (když master umře definitivně) a za běhu mu přidat nový slave? A jaké jsou zkušenosti z produkce, funguje to dobře? Nezakucká se to někdy kvůli replikaci?

Ja mam zkusenost jednu vlastni (spis pokusnou, vicemene jsem si hral) a pak nekolik zprostredkovanych. Nikdy vice. Replikace na MySQL (ale nejen tam) je jak cerna magie a woodoo dohromady. Chvilu to funguje, pak se to rozesere a davat to dokupy je nocni mura kohokoli, kdo to nekdy potreboval. Neni vetsi poteseni, nez kdyz ma clovek v kazdy databazi jina data, a musi resit, ktera jsou ta spravna ...

Kdykoli sem o tom s nekym mluvim, tak mi rek, ze si dela dumpy, a kdyz prijde o par dat, ze se svet nezbori.[/list]

MySQL replikace funguje bezproblemove, pokud se to nekomu nechce nastavovat, tak muze vzdycky pouzit Percona XtraDB Cluster (vykonostne je to dale nez klasicke MySQL)

A davat pozor na split-brain

[Sten]

@ioku: díky za hezký a praktický téma, jsem zvědavý na odpovědi a diskusi

master-slave replikace

Máš zkušenosti z produkce? Dá se u MySQL snadno slave povýšit na master (když master umře definitivně) a za běhu mu přidat nový slave? A jaké jsou zkušenosti z produkce, funguje to dobře? Nezakucká se to někdy kvůli replikaci?

Ja mam zkusenost jednu vlastni (spis pokusnou, vicemene jsem si hral) a pak nekolik zprostredkovanych. Nikdy vice. Replikace na MySQL (ale nejen tam) je jak cerna magie a woodoo dohromady. Chvilu to funguje, pak se to rozesere a davat to dokupy je nocni mura kohokoli, kdo to nekdy potreboval. Neni vetsi poteseni, nez kdyz ma clovek v kazdy databazi jina data, a musi resit, ktera jsou ta spravna ...

Kdykoli sem o tom s nekym mluvim, tak mi rek, ze si dela dumpy, a kdyz prijde o par dat, ze se svet nezbori.[/list]

Pokud musíte řešit, která data jsou ta správná, asi jste zkusil master-master replikaci, která v MySQL zrovna moc nefunguje (protože ta replikace není ACID, takže třeba auto-increment se musí nastavit v každé databázi tak, aby to nemohlo kolidovat, což zase znamená, že řazení podle ID není řazení podle času). U master-slave jsou správná data vždy na masteru.

[ioku]

...
Aktualizace lze řešit třeba rotací uzlů.
...

Díky za všechny předchozí rady, ale k téhle bych měl ještě dotaz.
Jak přesně si tu rotaci představujete? Že bych měl například jen dva uzly a používal by se ten, na který by se směroval DNS záznam?
Netrvalo by pak při nějakém výpadku moc dlouho, než by se změna DNS dostala až k uživatelům?

[ioku]

Docela by mě zajímalo, jaká přesněji úvaha za tímhle návrhem architektury byla. Má jenom umožnit updatování uzlů B a C s tím, že A se updatovat nebude vůbec (to není posměšek, může to klidně tak být)?

Proti umření stroje jako takového (na nějaké nízké úrovni) to nechrání, protože pravděpodobnost umření A je potom stejná jako původního jednoho uzlu.

O umření stroje se nestarám, v tomhle spoléhám na poskytovatele VPS. Tohle řešení je jen a pouze kvůli updatům a budoucímu rozšíření.
Když nezohledním fyzickou vrstvu, pak server může selhat na databázi, updatu webové aplikace nebo změně konfigurace.
První dvě možnosti mám vyřešené zálohou souborů, konfigurace je pro mě ten největší problém, protože nejsem žádný guru, ale začátečník. Požadavky se však pořád zvyšují, takže musím konfiguraci často upravovat a chci to dělat s co nejmenším rizikem.

[Sten]

...
Aktualizace lze řešit třeba rotací uzlů.
...

Díky za všechny předchozí rady, ale k téhle bych měl ještě dotaz.
Jak přesně si tu rotaci představujete? Že bych měl například jen dva uzly a používal by se ten, na který by se směroval DNS záznam?
Netrvalo by pak při nějakém výpadku moc dlouho, než by se změna DNS dostala až k uživatelům?

Stačí tam dostatečně dopředu snížit TTL třeba na deset minut a nějakou dobu nechat jet oba stoje jako proxy najednou. Jde o řešení aktualizace, ne failover, tam byste musel mít nízké TTL pořád.