OpenVZ - jak to funguje?

[opnvz]

Doted jsem znal virtualizaci pouze ve smyslu izolovaneho stroje s emulovanym HW

Nyni mam VPS na OpenVZ, ktere pro muj ucel celkem staci. Znepokojuje me na nem vsak par veci.

- Ostatni uzivatele na stejnem HW nodu ovlivnuji load ktery namerim ve svem systemu prikazem uptime?
- Spravce celeho toho HW nodu mi system muze kdykoliv zrestartovat kdyz uzna za vhodny ze je cas na update jadra?
- Jsou data co na tom VPS mam min v bezpeci (ve smyslu min izolovany) nez kdyby ta virtualizace byla pres XEN nebo KVM?

[Reklama]

[dsfasdfasdf]

openvz je takovy lepsi chroot :-)

[Franta <xkucf03/>]

Restartovat virtuál ti může i na plnohodnotné virtualizaci, záleží, jak se s ním dohodneš a co je to za správce. Totéž platí o čtení tvých dat. U OpenVZ jsou sice na souborovém systému připojeném v hostiteli, zatímco u plné virtualizace je to typicky LVM oddíl nebo soubor na disku a FS je uvnitř něj, ale i tam má správce hypervizoru možnost si tvůj disk okopírovat nebo udělat snapshot a připojit si ho jinde.

Spíš než o technologii jde tedy o to, jak moc tomu poskytovateli věříš.

[Jenda]

- Ostatni uzivatele na stejnem HW nodu ovlivnuji load ktery namerim ve svem systemu prikazem uptime?
- Spravce celeho toho HW nodu mi system muze kdykoliv zrestartovat kdyz uzna za vhodny ze je cas na update jadra?
- Jsou data co na tom VPS mam min v bezpeci (ve smyslu min izolovany) nez kdyby ta virtualizace byla pres XEN nebo KVM?

- Myslím, že spíš ne. Zevnitř vidíš jakoby vlastní seznam procesů a load by se měl počítat z toho. Každopádně když bude stroj přetížený, budou i tvé procesy trvat déle a tak budeš mít load vyšší. Ale to je na každé virtualizaci.
- Ano, může (stejně, jako u plné virtualizace)
- Jsou jakoby přímo namountované, jsou „vidět“. U plné virtualizace se ten disk musí nejdřív namountovat. Nemyslím si ale, že by ten jeden příkaz mount dělal nějaký rozdíl v bezpečnosti.

[piter_sk]

Na full virtualizacii mozes citlive data sifrovat, spravca dom0 nema root pristup k masine (aspon ja neviem o sposobe ako ho ziskat bez toho aby si to uzivatel vsimol). Pri openvz ma root pristup a tym padom moze vsetko. Izolacia dat medzi uzivatelmi by mala byt v pohode.
Co sa tyka loadu... openvz (a kontajner vseobecne) sa pouziva okrem ineho aj koli moznosti oversellingu, takze nejake to ovlyvnenie tam je. Popravde sa vykonovo ovplyvnuju aj full virtualy - napriklad siet alebo  IO, co tiez vidno na loade.
Spravca moze restartovat aj fyzicky server, od toho je spravcom. Ale podla mna netreba restartovat kontajner koli aktualizacii hosta, da sa pouzit live-migration a tych par sekund downtimu, bez restartu, si ani nevsimnes.

[Reklama]

[Jenda]

Na full virtualizacii mozes citlive data sifrovat

A klíč a rozšifrovaná data uložím kde? Do paměti toho stroje?

spravca dom0 nema root pristup k masine (aspon ja neviem o sposobe ako ho ziskat bez toho aby si to uzivatel vsimol

Má plný read-write přístup k disku a k paměti. K čemu pak je potřeba root?

Co sa tyka loadu... openvz (a kontajner vseobecne) sa pouziva okrem ineho aj koli moznosti oversellingu

Plná virtualizace taky.

[piter_sk]

Na full virtualizacii mozes citlive data sifrovat

A klíč a rozšifrovaná data uložím kde? Do paměti toho stroje?

spravca dom0 nema root pristup k masine (aspon ja neviem o sposobe ako ho ziskat bez toho aby si to uzivatel vsimol

Má plný read-write přístup k disku a k paměti. K čemu pak je potřeba root?

Co sa tyka loadu... openvz (a kontajner vseobecne) sa pouziva okrem ineho aj koli moznosti oversellingu

Plná virtualizace taky.

Jasne, da sa vsetko. a nikdy nemas istotu.
Ide skor o to ako obtiazne je sa k tym datam dostat. Neviem si predstavit ze by som hackoval vlastnych klientov aby som sa pozrel na ich data (tu je to skutocne o dovere). O neadministrovane servery sa zaujimam len v dvoch pripadoch: na ziadost klienta a ked je nejaky problem. Ked je nejaky problem, kontaktujem klienta aby zakrocil (priklad - jeho stroj je vyuzivany na ddos). Ked sa neda spojit s klientom, jedine co mozem legalne zrobit je limitovat alebo uplne odpojit masinu. Pri kontajneri (nepracujem s kontajnermi, takze len pisem co by som v krajnom pripade zrobil) je malickost napojit sa ako root, kuknut co sa deje a zakrocit, popripade zmenit limity cpu a jadier atd - bez restartu. Inymi slovami ked prenajimam full virtual, neratam s tym ze niekto iny bude mat root pristup, pri kontajneri s tym ratam.
Co sa tyka toho sifrovania, mas pravdu...
Overselling full virtualov a kontajnerov su dve odlisne veci. Pri kontajneroch moze padnut vela strojov na jedno jadro, pri full alebo paravirtualizacii to az take bezne nieje - zodpovedaju tomu aj ceny, samozrejme.

[Jan Forman]

Tak ono záleží na co to kdo potřebuje... já bych řekl, že OpenVZ se hodí hlavně pro ty, co si to provádí administraci sami
a požadujou od toho

a) možnost využití 100% CPU a 100% RAM (naprosto flexibilní) jedním VPS pokud ostatní nejsou aktivní + minimální limit.
b) správu VPS přes master node (přímým spuštěním příkazů atd).
c) snadnou online migraci jednotlivých strojů + snapshoty
d) vysoký výkon
e) vynikající limitování zdrojů (lepší než v KVM, VMWare apod) lze nastavit kde-co.
Za mě super na vlastní cloudové systémy.
d) téměř stoprocentní stabilitu (nikdy jsem neviděl padlý stroj vyjma HW kolapsů)

Pokud to chci rozdělovat cizím - tam už ty výhody může někdo brát jako nevýhody.
Tam bych bral KVM s tím, že bude výrazně pomalejší a stabilita není stoprocentní.

[Jenda]

Overselling full virtualov a kontajnerov su dve odlisne veci. Pri kontajneroch moze padnut vela strojov na jedno jadro, pri full alebo paravirtualizacii to az take bezne nieje - zodpovedaju tomu aj ceny, samozrejme.

Mně přijde, že tohle naprosto nezávisí na technologii (a v praxi jsem viděl overselling na obou a sám se starám o několik „oversellnutých“ (v uvozovkách, jsou to interní systémy, ne prodej VPS) KVM i OpenVZ serverů.

[openvz]

- Ostatni uzivatele na stejnem HW nodu ovlivnuji load ktery namerim ve svem systemu prikazem uptime?

K tomu jeste dodam, ze system monitoruji Monitorixem. Bezi mi tam vzdy stejne skripty ve stejne casy ktere jsou +- stejne narocne.(maalo narocne)  Vzdy o vikendu je load graf vyyrazne mensi nez pres vsedni dny.

Neumim si to vysvetlit jinak nez ze ten load neovlivnuji pouze ja.

[piter_sk]

Overselling full virtualov a kontajnerov su dve odlisne veci. Pri kontajneroch moze padnut vela strojov na jedno jadro, pri full alebo paravirtualizacii to az take bezne nieje - zodpovedaju tomu aj ceny, samozrejme.

Mně přijde, že tohle naprosto nezávisí na technologii (a v praxi jsem viděl overselling na obou a sám se starám o několik „oversellnutých“ (v uvozovkách, jsou to interní systémy, ne prodej VPS) KVM i OpenVZ serverů.

Ako som pisal, s kontajnermi nepracujem, teda zatial nie, takze prax nemam ale viac menej viem ako funguju (nieco ako kombinacia cgroups, chroot a virtualnej siete ).
Ja to vidim takto - ak sa mylim, opravte ma niekto, prosim:
Jan Forman to vlastne spomenul - vyhoda kontajnerov je ze mozes vytazit cpu a ram hosta na 100%. Toto je vyhoda z pohladu predavajuceho, alebo pri internych systemoch kde mas nad vsetkym kontrolu, ale nie z pohladu kupujuceho. Vo svete hostingu tuto kontrolu nemas. Ak tomu dobre rozumiem, dalo by sa to opisat ako vyuzivanie idle cpu tvojho kontajneru inym. Akonahle nastane potreba cpu u teba, ale tvoj "idle cpu" uz pouzivaju ine masiny, niekde sa to prejavit musi. A preto existuju vpsky za $2,90 ale zohnat full virtual pod $20 je celkom problem, ci nie?
V pripade hypervisorov (ja pracujem s xenom) idle cpu virtualnej masiny moze vyuzivat iba dom0, nie ina masina. Ak prezenies pocet virtualnych cpu oproti realnym, mas problemy so stabilitou (toto tu uz tiez niekto povedal) ale vytazenie vcpu na jednej masine neovlyvni moznost vytazenia vcpu na druhej - co sa tyka cpu a ram su si rovne - vyhoda pre kupujuceho. Ale ovplyvnuju sa navzajom cez storage a siet. Siet sa da vyriesit cez QoS. Storage neviem ci sa da vyriesit.

[Jenda]

Jan Forman to vlastne spomenul - vyhoda kontajnerov je ze mozes vytazit cpu a ram hosta na 100%.

U plné virtualizace není problém vytížit CPU. Jediné, co má klient +/- garantované, je paměť, a i ta lze trochu oversellnout, pokud vynutíš Memory balloon.

V pripade hypervisorov (ja pracujem s xenom) idle cpu virtualnej masiny moze vyuzivat iba dom0, nie ina masina.

Tohle je podle mě nesmysl. Nemám problém na stroji se 4 jádry spustit 8 KVM virtuálů po 2 jádrech. Ten virtuál vypadá jako proces a ty se schedulují normálně mezi procesory. A když CPU výkon dojde, tak se prostě přepínají a každý chvíli běží a chvíli je scheduled.

A preto existuju vpsky za $2,90 ale zohnat full virtual pod $20 je celkom problem, ci nie?

http://www.finalhosting.cz/cz/27/server/zobrazit/virtualni

[Mirek Prýmek]

Tohle je podle mě nesmysl. Nemám problém na stroji se 4 jádry spustit 8 KVM virtuálů po 2 jádrech. Ten virtuál vypadá jako proces a ty se schedulují normálně mezi procesory. A když CPU výkon dojde, tak se prostě přepínají a každý chvíli běží a chvíli je scheduled.

Je to nesmysl. U xenu to dokonce top ukazuje jako "stolen time". Proto na AWS xen instancich nema smysl resit load klasickymi prostredky zevnitr virtualu, protoze to dava nesmyslne vysledky - je potreba pouzit CloudWatch (amazonni metriky pro konkretni virtual).

Viz napr. https://forums.aws.amazon.com/thread.jspa?threadID=67697

[piter_sk]

Tohle je podle mě nesmysl. Nemám problém na stroji se 4 jádry spustit 8 KVM virtuálů po 2 jádrech. Ten virtuál vypadá jako proces a ty se schedulují normálně mezi procesory. A když CPU výkon dojde, tak se prostě přepínají a každý chvíli běží a chvíli je scheduled.

Je to nesmysl. U xenu to dokonce top ukazuje jako "stolen time". Proto na AWS xen instancich nema smysl resit load klasickymi prostredky zevnitr virtualu, protoze to dava nesmyslne vysledky - je potreba pouzit CloudWatch (amazonni metriky pro konkretni virtual).

Viz napr. https://forums.aws.amazon.com/thread.jspa?threadID=67697

Zil som v tom, ze stolen time je cpu cas "ukradnuty" pre dom0, nie pre inu VM. A mam aj priklad z praxe - padali nam masiny bez zjavneho dovodu. Bolo to sice pocas backupu, ale grafika (VM) nam nic neukazala. Ked sme ale pozreli na grafiku dom0, cele cpu zozralo IO-wait. Vtip bol v tom, ze sme obmedzili dom0 na 1 jadro a 1G RAM (aby sme mohli zarucit klientom to jadro co im predavame. Na starsich masinach dokonca robili cpu pinning, cize som vedel ktore fyzicke jadro je ktoreho klienta - cpu sa DA garantovat, akurat to je podla mna blbost). Ked sme tento limit odstranili, dovolili sme dom0 "kradnut" viac cpu casu od virtualnych masin a problem sa vyriesil (teda... treba vyriesit ozajstny problem - bottleneck v storage systeme, ale aspon nepadaju masiny)
A tiez z praxe - na dom0 mam +/- 15 masin, ak je jedna vytazena na 100% cpu (nie io), neovlyvni ziadnu inu VM v ramci dom0. Ale je pravda ze na tych neovlyvnenych som si stolen time nevsimal...
Tiez je pravda ze my overselling nerobime, takze len uvazujem: Ak su to procesy, ktore po tom ako dojde cpu prejdu do scheduled, prioritu maju rovnaku, nie? to znamena ze aj ked je VM proces prepinany, ma menej cpu casu, ale ten co ma jej nevezme ina VM, len dom0.

[Mirek Prýmek]

Zil som v tom, ze stolen time je cpu cas "ukradnuty" pre dom0, nie pre inu VM.

Je to mozny, zas tak jsem to nikdy nepotreboval resit - coby jenom uzivatele toho virtualu me jenom zajimalo, jak zjistit svoji zatez, nad zbytkem jsem nedumal

Podle tohodle
http://www.axibase.com/cloud/2010/07/22/ec2-monitoring-the-case-of-stolen-cpu/ kdyz je virtual omezenej na 40% cpu, tak zbytek je oznacenej jako stolen - prijde mi divny, ze by hypervisor ten cas nepridelil jinymu virtualu, proc by to tak bylo?

Kazdopadne jak psal Jenda, u OpenVZ neni zadny "virtual" a procesy by mely byt schedulovany uplne normalne jako procesy AFAIK.