Výběr hypervizoru pro vysokou dostupnost

[Bzron]

Ako mas riesenu synchronizaciu medzi VPS prosim ta ? Dakujem

[Reklama]

[Jozko]

Osobne by som sa popozeral po niecom ako ma FBSD -> HAST + CARP
https://www.freebsd.org/doc/handbook/disks-hast.html

[M.]

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/

[Homeatcloud]

@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 :-).

[M.]

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

[Reklama]

[joohn]

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/ vo svojej infrastrukture. Samozrejme bez ujmy na dostupnosti aplikacie.

[Homeatcloud]

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.