Výběr hypervizoru pro vysokou dostupnost

[Marv_1911]

Začínám řešit jeden projekt s dostupností 24/7 a v tuto chvíli řeším topologii serverů.

Zadání je následující:

Na serveru poběží
2x VPS webserver debian (synchronizace mezi VPS)
2x VPS aplikační server debian (synchronizace mezi VPS)
2x VPS databázový server debian (synchronizace mezi VPS)
Tím, že to poběží duplicitně bude zajištěna záloha v případě SW problémů.

Servery by měly být dva ve shodné HW a SW konfiguraci, tím bude zajištěna záloha v případě HW problému serveru.

Potřeboval bych doporučit vhodný Hypervizor pro tento model, aby byl zajištěn bezvýpadkový nepřetržitý provoz.

V tuto chvíli mě napadá:

OpenVZ
KVM

Díky za každý názor.

[Reklama]

[Daniel Kozak]

Začínám řešit jeden projekt s dostupností 24/7 a v tuto chvíli řeším topologii serverů.

Zadání je následující:

Na serveru poběží
2x VPS webserver debian (synchronizace mezi VPS)
2x VPS aplikační server debian (synchronizace mezi VPS)
2x VPS databázový server debian (synchronizace mezi VPS)
Tím, že to poběží duplicitně bude zajištěna záloha v případě SW problémů.

Servery by měly být dva ve shodné HW a SW konfiguraci, tím bude zajištěna záloha v případě HW problému serveru.

Potřeboval bych doporučit vhodný Hypervizor pro tento model, aby byl zajištěn bezvýpadkový nepřetržitý provoz.

V tuto chvíli mě napadá:

OpenVZ
KVM

Díky za každý názor.

krom vise zminenych bych doporucil se kouknout jeste na

https://www.ubuntu.com/cloud/lxd

[jeniceek]

Pokud to chceš myslet vážně a projekt ti to zaplatí tak VMWare.
Pokud ne tak v dnešní době bych to asi poskládal na Docker Swarm, virtualizace celého OS nemá z hlediska výkonu moc smysl.

[Martin Dráb]

Také může záležet na tom, co přesně znamená termín 24/7. Moje zkušenost s hypervizorem rozloženým se na více serverech je taková, že pokud jeden ze serverů padne, obvyklé řešení spočívá v převedení tam běžících virtuálek na jiný stroj, což znamená jejich restart.

Nevím, jak je na tom OpenWZ/KVM atd., ale VMWare umí i paralelní běh VPS na dvou serverech zároveň (možná i na více, to nevím), takže když jeden server odejde, virtuálku není třeba restartovat. Ale počítám, že takové řešení bude extra drahé (nejen kvůli licencím na VMWare).

[DK]

Také může záležet na tom, co přesně znamená termín 24/7. Moje zkušenost s hypervizorem rozloženým se na více serverech je taková, že pokud jeden ze serverů padne, obvyklé řešení spočívá v převedení tam běžících virtuálek na jiný stroj, což znamená jejich restart.

Nevím, jak je na tom OpenWZ/KVM atd., ale VMWare umí i paralelní běh VPS na dvou serverech zároveň (možná i na více, to nevím), takže když jeden server odejde, virtuálku není třeba restartovat. Ale počítám, že takové řešení bude extra drahé (nejen kvůli licencím na VMWare).

Rika se tomu live migrace a umi to i LXD (pomoci CRIU) - https://www.stgraber.org/2016/04/25/lxd-2-0-live-migration-912/ , takze pokud jde ciste o failover, tohle muze byt reseni

[Reklama]

[citanus006]

Rika se tomu live migrace a umi to i LXD (pomoci CRIU) - https://www.stgraber.org/2016/04/25/lxd-2-0-live-migration-912/ , takze pokud jde ciste o failover, tohle muze byt reseni

pletete si migraci (vmware vmotion) s provozovanim kopie vm 1:1 na jinem hostu( vmware fault tolerance)

[Darkhunter]

Zkus proxmox. Umí kvm, openVZ i LXC a má tam možnost dělat HA clustery.

[MarSik]

A hlavně nezapomeň na redundantní storage, síť a napájení (vč. těch síťových prvků). Nejvíce problémů, které vidíme v oVirtu, je způsobeno nějakým síťovým problémem. Veškerá synchronizace pak jde do háje, nekonečná migrace bez síťě nejede, storage těch VMek není dostupné, management té virtualizace není schopný zjistit stav hostů atd.

Btw, kolik 9 za desetinnou čárkou dostupnosti je 24/7?

[Marv_1911]

A hlavně nezapomeň na redundantní storage, síť a napájení (vč. těch síťových prvků). Nejvíce problémů, které vidíme v oVirtu, je způsobeno nějakým síťovým problémem. Veškerá synchronizace pak jde do háje, nekonečná migrace bez síťě nejede, storage těch VMek není dostupné, management té virtualizace není schopný zjistit stav hostů atd.

Btw, kolik 9 za desetinnou čárkou dostupnosti je 24/7?

Asi jsem se s tím 24/7 špatně vyjádřil. Služby, které na serverech poběží, by měly běžet stále, SLA by mělo být 99,99%.
Konektivita bude zálohovaná, síťové prvky budou, napájení bude zálohované dvěma zdroji, v serverech budou vždy dva zdroje. Toto vše mi je jasné...
Servery by měli jet jako kopie s tím, že když jeden padne, pojede to bez výpadku z druhého.

Koukal jsem na Proxmox a na HA cluster. Nevím ale, zda to takhle bude fungovat.
Nebo pak VWware vSphere Standard, to je ale pro dva dvouprocesorové hosty už docela ranec.

[Darkhunter]

Ten proxmox HA cluster by tak měl fungovat.
Buď můžeš mít ty dva proxmox hosty zaplý jako load balancer nebo je tam možnost to mít zaplý jako failover.
Zdá se mi to pro tebe jako nejjednodušší řešení.

[Jan Forman]

Pokud to má být bez výpadku, musí se v neustále synchronizovat celý systém - storage ideálně na SANu nebo distribuovaný. Dále se musí synchronizovat RAM a v pravidelných intervalech zastavit CPU. Z toho vyplývá, že takové řešení má brutální dopad na výkon a systémy by obvykle měli být propojený dedikovanou 10Gbit síťovkou direct.

Mnohem lepší je tedy mít opravdový cluster (tedy software podporující běh na mnoha strojích současně) a né takové napodobeniny. S běžným softwarem to nebude pořádně fungovat nikdy.

Nejčastější řešení u obyč systémů tedy je po kolapsu primárního systému odstartovat záložní a mezi tím se porve quorum o to, jestli to je OK. Nebo tedy jako vMotion s tím nekonečným neukončeným migrováním...

Ty opravdické prostě běží distribuovaně od narození a je jim v podstatě všechno jedno.

[Jan Forman]

Teď čtu, že to všechno bude dvakrát. Reakce byla na komentáře níže - jak to všechno běží snadno v HA. Takže moje odzkoušená řešení jsou

1) OpenVZ vyšla nová verze 7, nicméně migrace má být přes CRIU (stále mi příjde, že se ladí).
Součástí je distribuovaný storage, prý super výkonný - nevím nezkoušel jsem, ale věřím jim. Je to ISO (celý stroj na CloudLinuxu).

2) Docker - má limity, ale pokud funguje je fajn (rychlý)

3) Proxmox (KVM) - bude to líné (LXC zatím raději ne - spousty nedořešených věcí) občas nějaký ten bug

4) VMWare - je celkem drahý, rychlost nižší jak OpenVZ, LXC, Docker zase celkem stabilní platforma

5) OpenStack (KVM) - docela složité, KVM samozřejmě líné.

6) XEN - nemám ho rád (osobní antipatie) :-) taky funguje

Nejjednodušší varianta bude Proxmox nebo VMWare. Proxmox často vykazuje určité nedodělávky.

[Homeatcloud]

Zdravím!
Pokud je mi známo, tak synchronizovaný běh dvou VM umí jenom VMware. Spíš bych ho nepodoručoval a udělal vysokou dostupnost na aplikační úrovni. Začal bych odspodu a postavil databázi na MySQL Galera clusteru nebo jiném master-master řešení, aby nebylo potřeba řešit problémy s fail over a hlavně fail back. Deadlockům se vyhnete, když před to dáte HAProxy, který bude směrovat požadavky vždy na první dostupný server. Aplikační servery a webové servery by měly ideálně být bezestavové, takže mezi ně dáte též HAProxy s load balancingem. Může to být i ta samá instance HAProxy. Na takovém řešení je postavený Public cloud https://www.homeatcloud.cz/cloud, každá služba OpenStacku je tam 3x a mimo lidské chyby (ehm..) je téměř nemožné to shodit. Čislo 3 je potřeba kvůli quorum algoritmu. Když jsou v master-master konfiguraci jen dvě databáze, tak při výpadku jedné padnou obě, aby se zabránilo split-brain situaci. Třetí server je možné nahradit Arbitrem na nějakém slabším nebo virtuálním stroji.
Pokud se nepletu, tak na virtuální služby SLA se čtyřmi devítkami nemáme, ale na pronájmy serverů a housing ano. A ano, hardwarový load balancer na firewallu Fortigate nabízený u pronájmů serverů by se dal použít i na instance v cloudu, pokud by někdo chtěl vyšší výkon než dá HAProxy.

[Marv_1911]

Zdravím!
Pokud je mi známo, tak synchronizovaný běh dvou VM umí jenom VMware. Spíš bych ho nepodoručoval a udělal vysokou dostupnost na aplikační úrovni. Začal bych odspodu a postavil databázi na MySQL Galera clusteru nebo jiném master-master řešení, aby nebylo potřeba řešit problémy s fail over a hlavně fail back. Deadlockům se vyhnete, když před to dáte HAProxy, který bude směrovat požadavky vždy na první dostupný server. Aplikační servery a webové servery by měly ideálně být bezestavové, takže mezi ně dáte též HAProxy s load balancingem. Může to být i ta samá instance HAProxy. Na takovém řešení je postavený Public cloud https://www.homeatcloud.cz/cloud, každá služba OpenStacku je tam 3x a mimo lidské chyby (ehm..) je téměř nemožné to shodit. Čislo 3 je potřeba kvůli quorum algoritmu. Když jsou v master-master konfiguraci jen dvě databáze, tak při výpadku jedné padnou obě, aby se zabránilo split-brain situaci. Třetí server je možné nahradit Arbitrem na nějakém slabším nebo virtuálním stroji.
Pokud se nepletu, tak na virtuální služby SLA se čtyřmi devítkami nemáme, ale na pronájmy serverů a housing ano. A ano, hardwarový load balancer na firewallu Fortigate nabízený u pronájmů serverů by se dal použít i na instance v cloudu, pokud by někdo chtěl vyšší výkon než dá HAProxy.

Díky za rady. Jako DB by měla být Oracle Express, na aplikačním serveru poběží Project Grizzly a webserver bude Apache. Tohle potřebuji zkombinovat a postavit tak, aby to bylo co nejméně náchylné na výpadky.

[and]

Nechci podsouvat, ale 99.99% a Oracle Express? Tato kombinace mi nedava zadny smysl.