Dotaz: Přechod velkého systému na virtualizaci

[frenzymadness]

Zdravím a prosím o radu.

Již několik let pracuji ve firmě, kde se staráme o značné množství webhostingů převážně s eshopy. Máme k dispozici asi dvě desítky serverů většinou na debianu a většina z nich je určena právě pro hosting aplikací. Některé z nich mají SW a některé HW RAID. Zálohování probíhá po síti na dva samostatné servery kombinací rsync + rdiff.

Problém nastává v případě výpadku, kdy je třeba nainstalovaný záložní server nakonfigurovat podle serveru, který vypadl, a ze zálohovacího serveru nakopírovat i milióny souboru (převážně obrázků) na nově zapojený stroj. Toto samozřejmě trvá i při použití netcatu velice dlouho a prodlužuje to znatelně dobu výpadku a přidává vředy správcům.

Mám nějaké malé zkušenosti s virtualizací, ale zatím mi to popravdě přineslo spíše potíže než užitek.

Můj dotaz tedy zní: Myslíte si, že by se dal podobně veliký systém serveru migrovat na nějakou virtualizaci a umožnit tak lepší, rychlejší a pro správce pohodlnější řešení výpadků jednotlivých serverů? Máte s tím nějaké zkušenosti? Mohli by jste mne postrčit správným směrem?

Díky moc za odpovědi.

---

---

Odpovědi

[ondro]

Virtualizacia by vam pomohla. Mali by ste odzalohovane cele virtulane servery a pri havarii by ste ich jednoducho obnovili plus dosynchronizovanie zmien od poslednej zalohy virtulaneho servera. Odpadla by konfiguracia zalozneho servera a aj kopirovania by bolo menej.

Ideal je mat min. dva nody (fyzicke servery) + SAN vo fail-over konfiguracii. Toto riesenie ale uz ide dost do penazi a oplati sa az pri urcitom objeme virtualizacie (tazko odhadnut, ci vam by sa to oplatilo). Pri takejto konfiguracii by problemy s vypadkami mali razantne klesnut a klesla by aj dlzka vypadkov.

Da sa to riesit aj bez SAN a fail-over ale tam treba ratat s dlhsimi vypadkami a vyssou moznostou straty dat. Pozor na jednu vec. Ak vam padne fyzicky server, na ktorom budu tie virtualne, tak pridete o vsetky virtulane servery a nielen o jeden ako teraz.

Zalezi ake vypadky sa u vas castejsie vyskytuju (HW ci SW) a ake vypadky si mozte dovolit.

Urcite by to bolo prinosom, len si je potrebne premysliet, navrhnut a hlavne vyskusat recovery plan pri havarii.

Pri vasej konfiguracii by to mohlo ist aj bez virtualizacie. Odporucal by som sa zamysliet ako zjednodusit konfiguraciu zalozneho servera lebo toto je asi najhorsia vec (pouzivat unfikovanu HW konfiguraciu, mat odzalohovane konfiguraky alebo klon celeho servera,...). Obnovu dat zo zalohy extra nezrychlite (kopirovat kopu malych suborov da zabrat). Virtualizacia nieje vseliek.

[j]

Mam zkusenost s provozem 4 serveru ve vmware clusteru a funguje to velmi dobre. Samo v zavislosti na zakoupeny licenci. Pri standardnim licencovani stroje pri vypadku HW sice zbuchnou, ale obratem se nastartujou na jednom z bezicich stroju. Je k tomu treba bud diskovy pole, ktery videj vsechny stroje v clusteru nebo licence na prislusny SW, ktery umi udelat "jako pole", ale pokud vim z max 3 serveru (jednoduse vytvori virtualni uloziste a distribuuje data tak, ze vypadek jednoho stroje neva).

Takze pokud to potrebujes provozovat na trochu profi urovni, diskovymu poli se nevyhnes.

Samo, moh bys si to zaridit rucne (mit kopie virtualu) a ty rucabo pri vypadku spustit. Ale pri 20 serverech ... by ti z toho brzo jeblo.

Pokud bys pak chtel zajistit bezvypadkovy provoz, je to mozny, ale pokud jsou me informace aktualni, na jeden virtualni stroj je treba zajistit konektivitu min 6Gbit (syncuje se RAMet). Jinak v pripade planovany udrzby lze samo virtualni stroje premigrovat za chodu.

[frenzymadness]

Diskové pole by nebyl problém. Mám aktuálně dva servery s HW raidem na zálohování a na každý z nich se vejdou data ze všech hostingových strojů. Jakou virtualizaci resp. s jakými nástroji mi můžete doporučit? Představuji si to jako několik výpočetních uzlů, jeden hypervisor, systém postavený na OpenVZ a jedno nebo dvě sdílené síťové uložiště. Takový HA cluster.

[linuxik]

Obavam se, ze pod pojmem diskove pole, si predstavujeme kazdy neco jineho. Server s "nejakou" raid kartou opravdu neni diskove pole. HW Raid je dobry pro standalone server, ale pro 20 serveru rozhodne vykonove stacit nebude a se spolehlivosti to take nebude zadna slava. HA cluster s openvz je v pripade, ze mate pouze linux OS asi nejlepsi volba.

[Punny]

presne, jako diskove pole neco treba s HW iSCSI controlerem, treba Dell MD3600i neni vubec spatna hracka, ja bych dnes sel zase do KVM...pokud nechcete nic narocneho tak proxmox by mohl take stacit...umi jak openvz tak KVM

[lertimir]

Umí openvz i migraci virtuálu mezi fyzickými servery za běhu jako to umí VMWare? Pro HA to je velmi užitečná vlastnost, která umožní bez výpadku přesunout virtuály při varováních a server opravovat.

[pavlix]

Umí openvz i migraci virtuálu mezi fyzickými servery za běhu jako to umí VMWare?

Miluju takto položené otázky. Netuším, jak to umí VMWare, takže je možné, že ano. Stejně tak je možné, že to umí úplně jinak. Ba dokonce je to velmi pravděpodobné, protože od VMWare bych čekal něco sofistikovaného, zatímco OpenVZ to má řešeno vcelku primitivně, ale to skutečně vařím z vody.

Mimochodem, jestli to VMWare umí bez narušení síťové komunikace, tak to jsou asi kouzelníci, protože přesun dat v nulovém čase je už docela hezkou ukázkou černé magie :).

[lertimir]

Nezkoumal jsem jestli to umí bez narušení síťové komunikace. v postatě provede snapshot paměti, přesune na jiný procesor paměť a spustí od bodu přerušení, reálné časy výpadku jsou 1-4 vteřiny v závislosti na velikosti virtuálu a rychlosti komunikace mezi servery. Na druhou stranu přerušení datového toku na nějakou vteřinu by TCP kanál nemělo rozbít. Jen tam bude v té chvíli delay.

[Ivan]

Tohle vmware resi tak ze ma v sobe virtualni Cisco switch, ktery umi komunikovat s tema fyzickyma. V esx hostech konci VLAN trunky. Da se zaridit, ze se behem migrace guesta neztrati ani jeden packet.

[kyytaM]

Virtualny Cisco switch je plateny komponent, ktory nie je pre zivu migraciu potrebny. V XENe to funguje tak, ze sa medzi dvoma hostitelmi kopiruje RAM migrovaneho virtualneho stroja a ked je uz delta dostatocne mala, tak sa na povodnom hostitelovi virtualny stroj zapauzuje, dokopiruje sa zvysny rozdiel na noveho hostitela, kde sa virtualny host nasledne spusti - nesmie samozrejme chybat gratuitous ARP. K strate paketov pochopitelne dojst moze v dobe ked je stroj zapauzovany, respetkive kym prepinac nespracuje GARP, ale v pripdae TCP dojde k preposolaniu, v pripade UPD je to uz na konkretnej aplikacii.

[Ivan]

JJ mas pravdu virtualni switch toho umi vic. Pokud se ale nepletu tak ESX umi "preposlat" packety z jednoho hosta na druhy.

[pavlix]

Da se zaridit, ze se behem migrace guesta neztrati ani jeden packet.

Na to není ani tak potřeba virtuální switch jako zadržení paketů do doby než si je může virtuální stroj vyzvednout.

[pavlix]

v postatě provede snapshot paměti, přesune na jiný procesor paměť a spustí od bodu přerušení

Tenhle popis podle mě odpovídá tomu, jak pracuje migrace OpenVZ.

[lertimir]

Pokud to OpenVZ umí, tak jsem jedině rád. Samozřejmě vždy tohle potřebuje nějaké diskové pole v pozadí na kterém virtuálka pojede v obou případech, protože snapshot paměti se sice v nějakém rozumném čase přenést dá, ale snapshot disku stěží.

[pavlix]

Jestli ty nástroje umí pracovat i s tím diskovým polem nebo jestli bys to musel dobastlit sám, to netuším. Já jsem to před časem zkoušel s kompletním přesunem včetně diskových dat. Samozřejmě se to dá řešit různě, například i tím, že přímo guest používá vnější storage pro většinu věcí.

[j]

Jak bylo receno, tohle neni pole. Ja tu mam trebas vnx5100 - to je nejnizsi rada od EMC - stoji to prekvapive celkem malo penez, navic pole musi mit taky odpovidajici konektivitu a to nejaky Gbit kabel do normalniho switche rozhodne neni. Da se to samo postavit na eth hw - jen to chce 10g switch. Nebo se to stavi na fiberu.

BTW: Co budes delat, kdyz ti chcipne ten HW radic ...??? Nj, ses v pr... Pole ma "radice" dva. Stejne jako se vse co je cestou dubluje => vypadek zadnyho prvku neohrozi provoz (trebas ty switche potrebujes taky dva).

[Jan Kratochvíl]

Mohu doporučit toto:

http://www.proxmox.com/products/proxmox-ve

Je to jednoduché a open...

[frenzymadness]

Na virtualizaci to vypadá skvěle, ale jak je to s distribucí výkonu mezi jednotlivými uzly resp, jak se to dá natáhnout přes více fyzických serverů s okamžitou migrací virtuálky při výpadku fyzického stroje?

[ZS-Man]

Proxmox umi fungovat jako HA cluster, max. 16 nodu. Takze kdyz ti jeden node lehne, za chvilku uz ty VM startuji na jinem. Samozrejme potrebujes sdilene diskove uloziste pro ty VM. Na ten cluster bys mel mit minimalne 3 nody, ale jdou i dva + jeden mrnavej iscsi disk.

[-MM-]

Mohu doporučit toto:

http://www.proxmox.com/products/proxmox-ve

Je to jednoduché a open...

Prosím tě co to tady meleš!! A Trial License je jako co ??

[Punny]

nez napises takhle celkem agresivni prispevek, si precti co tam je jako trial licence ;)

[-MM-]

nez napises takhle celkem agresivni prispevek, si precti co tam je jako trial licence ;)

Agresivní příspěvek.. tak to mam dost... :D Trial licenci jsem samozřejmě četl, a co to má jako společného s tím, že je to zadarmo, když to zadarmo není...???

[Punny]

+1 s idiotem se nebavim :D precti si k jakemu produktu se vztahuje ktera licence chytroline :D

[MMMMMMMMM]

Proxmox VE zadarmo je. Ale není k němu podpora, za tu si pěkně zaplatíte.

[Punny]

virtuali ti urcite spoustu problemu usnadni, ale prvne si musis zjistit co vse na tom pobezi, treba velke DB by mohli mit problemy.
Prvne jeste bude chtit nejake storage a zde je vetsinou nejvetsi kamen urazu, jelikoz tu zde uz leze celkem do penez. Ale nevim jak velke to ma byt, co vse a kolik na tom pobezi...takze tezko rici :) chtelo by to nejaka konkretni cisla.

[linuxik]

Zaklad bude koupit diskove pole. Samotna virtualizace sice o neco muze zkratit obnovu server (nemusis obnovovat milion malych souboru), ale stale to nebude ono. Resil jsem nedavno neco podobneho a ani jsme virtualizaci nakonec nepotrebovali. Servery maji boot ze site, vsechna data jsou na diskovem poli. V pripade ze odejde HW serveru, vytahne se ze skrine nahradni a nabootuje puvodni OS. S linuxem zadny problem, ani nemusi byt stejny HW, staci mit v initrd ovladac pro diskovy radic. Pokud mate 20 serveru nemela by byt investice cca 200k do nejakeho levnejsiho iSCSI diskoveho pole a poradneho switche zase takovy problem.

[drunkezz]

jj imo najlepsie riesenie....nechat data na shared storidzi a nech si k nemu pristupuju execution nody v neexkluzivnom mode

D.

[afadf]

A ak sa ti dojebe storage a nemas backupy tak pa pa...

[drunkezz]

samozrejme....ale preco by clovek robil nereplikovany/nebackupovany storage???

D.

[j]

A tys nekdy videl chcipnout diskovy pole tak, ze doslo ke ztrate dat? Ja teda vzivote ne, a to uz sem toho videl celkem dost - ze chcipne disk nebo jeden radic ... totiz provoz pole nijak nenarusi (a da se to vetsinou dokonce vymenit za chodu).

[Nikt0]

Mam v prevadzke virtualne riesenie pre cca 20 virtualnych masin s web serverami v konfiguracii: fyzicky master server <-> fyzicky slave server (identicke stroje) + 2x storage server (jeden pre master a jeden pre slave server). zalohy sa robia krizovo a na externy disk + sa robi synchronizacia raz denne dat z master na slave. 5 rokov bezproblemovej prevadzky....

[Mirek]

Mám odzkoušenou KVM virtualizaci ( RedHat nebo CentOS )a facha i nad velkými ERP super. Samozřejmě jsem nevirtualizoval náročné Oracle. LIVE migrace fachala při neshozené konkšně usera. Pokud ti mohu poradit, zkus se podivat na SAS pole a SAS switche, dostaneš se výkonově někde jinde než je iSCSI a navíc nebudeš mít problém s IP stackem. Koukni na stranky ABACUSu, vybereš si i cenově přijatelné servery. Berou to od nich hostingy.

[frenzymadness]

Moc díky všem za rady. Pomocí aktuálních prostředků, které mám si to představuji následovně:

Na tři výkonné mašiny nahodím proxmox a udělám z toho cluster. Jednotlivé fyzické stroje budu migrovat na tento cluster jako virtual s tím, že každý uvolněný fyzický stroj bude následně do clusteru připojen. Jednotlivé virtualy půjde v případě nedostatku výkonu migrovat na jiný fyzický uzel a tím optimalizovat výkon i počet zapojených fyzických nodů. Například dokáže jeden výkonný stroj pojmout tři virtuály, které nyní běží samostatně na třech fyzických strojích - tím by se ušetřil i příkon a snížil se počet potencionálně chybového starého HW.

Protože se asi jen tak nedostanu k redundatnímu diskovému poli, které by to výkonově celé utáhlo, bude každý virtuál obsahovat svá vlastní data (hostingy).

Na jeden zálohovací server se budou denně dělat klasické zálohy soubor po souboru (aby se v případě chyby programátora nemusel obnovovat celý server) a na druhý z nich se budou podle náročnosti dělat minimálně jednou denně (ideálně vícekrát) zálohy celých virtuálních mašin.

Pokud padne fyzický stroj, nastartují se virtuály ze zálohy na jiném nodu. Díky absenci storage serverů nebude taková situace bez výpadku, ale kopírování třeba 320 GB serverů jako jednotek souborů bude trvat kratší dobu než kopie stejného objemu dat v malých souborech ze zálohy. Zároveň se díky kopii celého serveru nebude muset nic nastavovat ani ladit - vše bude v původní konfiguraci padlého serveru.

Podle výkonu se pak opět virtuály zmigrují tak, aby byl výkon rozdělen rovnoměrně.

Co na to říkáte? Zapomněl jsem na něco, nebo mám někde mezeru? Samozřejmě se do toho nehrnu bezhlavě a vše budu nejdříve testovat, ale jako koncept se mi to zdá dobré.

[linuxik]

Fungovat to bude, jen budes muset pouzit KVM virtualizaci. V OpenVZ jsou "disky" pro virt. stroje mapovane do adresaru(je to jen trochu lepsi chroot), takze by se nic nezmenilo .