Fórum Root.cz
Hlavní témata => Server => Téma založeno: Marv_1911 20. 12. 2016, 15:22:36
-
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.
-
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
-
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.
-
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).
-
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
-
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)
-
Zkus proxmox. Umí kvm, openVZ i LXC a má tam možnost dělat HA clustery.
-
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?
-
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.
-
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í.
-
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.
-
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.
-
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 (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.
-
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 (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.
-
Nechci podsouvat, ale 99.99% a Oracle Express? Tato kombinace mi nedava zadny smysl.
-
Ako mas riesenu synchronizaciu medzi VPS prosim ta ? Dakujem
-
Osobne by som sa popozeral po niecom ako ma FBSD -> HAST + CARP
https://www.freebsd.org/doc/handbook/disks-hast.html
-
Pokud je mi známo, tak synchronizovaný běh dvou VM umí jenom VMware.
Umí to i KVM (pokud se bavíme o běžné PC platformě, pro jiné taková řešení existují už od dávnověku). Teď nevím, zda dané patche jsou už přímo v KVM ofiko nebo stále bokem, ale dá se to používat. Synchronizace je nejlépe přes Infiniband karty (ty už asi umí používat konečně i VMware a i HyperV).
Jinak pokud má tazatel dost peněz, tak ucelené podobné řešení (včetně duálního HW) nabízí Stratus, kde si hraje na 5 devítek a nějaké drobné k tomu... http://www.stratus.com/solutions/platforms/ftserver/
-
@M.: Kdybys k tomu KVM HA měl nějaký odkaz, tak bych si to rád prohlédl. Já vím, že pro OpenStack existuje experimentální VM HA jménem Masakari. Dělají ho Japonci a umí (přibližně) to, že na hypervizorech běží Pacemaker a při výpadku vadný hypervizor odstřelí (fencing) a do pár sekund znovu spustí všechny VM jinde. Celkem to chápu, protože InfiniBand je celkem drahé řešení (i když naše kombinace 2x 10Gb/s Ethernet a 2x 8 Gb/s FC taky stála dost) a cloudy se většinou snaží šetřit a běžet raději pouze na Ethernetu. Na Masarykově univerzitě mají třeba Hadoop přes Infiniband prostě proto, že se jim tam ty stroje někde válely a ne proto, že by Hadoop potřeboval mikrosekundovou latenci :-).
-
@Hometcloud: Řešíme HA - high availability (po chcípnutí jedné služby je daná služba znovu spuštěna někde jinde v řádu sekund-desítek sekund) nebo FT - fault tolerant (kde když chcípne služba na jednom místě, tak v řádu desítek milisekund pokračuje na jiném místě cca v bodě, kde to chcíplo na prvním místě)?
Přiznám se, že OpenStack neznám, ale měl jsme za to, že HA umí od přírody sám o sobě a netřeba na to do něj nějaké další udělátko. U KVM se řeší běžně HA pomocí clusteru, provozujeme RHCS (což je PaceMaker u RHEL7) a nad tím KVMka od dob RHEL5, předtím na RHEL4 a Xen nad tím (a za dob RHEL3 to byly ještě služby přímo běžící nad HW bez virtulizace migrované dle potřeby).
Pro HA řešení stačí Ethernet, switche jsou za pusu, Pro FT a některé další aplikace distribuovaného zpracování dat/výpočtů je vhodnější Infiniband, kdy jde o lepší odezvu, garantované časování plnou obsluhu všeho v HW (minimulně to poslení RDMA pomalu začíná pronikat i do Ethernetu 10+ Gbps). Pokud mám jen pár strojů (2-3) v rámci jendoho racku, tak Infiniband 40 Gbps propojení je za pusu, když nepotřeuji Infinibnd switch.
Pro fault tolerant řešení do KVM/QEMMU jsou dva projekty: Kemari a MicroCheckpointing.
-
Naco sa nahanat za XX.XXX% infrastrukturnou dostupnostou, ked je jasne, ze chyby a vypadky sa deju a budu diat stale. Radsej nadizajnuj aplikaciu podla "Design for Failure" pristupu a mozes si pustat vsetky zle zchaosene opice (Chaos Monkey) https://cloudnative.io/blog/2015/04/fear-the-chaos-monkey-think-again/ (https://cloudnative.io/blog/2015/04/fear-the-chaos-monkey-think-again/) vo svojej infrastrukture. Samozrejme bez ujmy na dostupnosti aplikacie.
-
OpenStack je navržený pro HA řídící vrstvy, takže když se v distribuci použije např. HAProxy a keepalived a všechny databáze a fronty běží v clusteru, tak vydrží hodně. I když ve starších verzích tam byly často problémy, když třeba při přetížení nastal failover a pak failback, tak seněkteré komponenty pak správně nepřipojily k RabbitMQ a přitom se tvářily, že běží. To dokáže zkazit den.
Workload HA v OpenStacku standardně není. Ten projekt Masakari se to snaží přidat.
A jak koukám na ta FT řešení pro KVM, tak vypadají dosti mrtvě. Poslední aktivita před rokem a půl. Nicméně děkuju za to čtení. Už tuším, jak to asi má udělané ten VMware.