Fórum Root.cz
Hlavní témata => Server => Téma založeno: opnvz 27. 09. 2014, 02:11:54
-
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?
-
openvz je takovy lepsi chroot :-)
-
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ěříš.
-
- 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.
-
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.
-
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.
-
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.
-
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í.
-
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ů.
-
- 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.
-
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.
-
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
-
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
-
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.
-
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.
-
mozny zdroj informaci je vpsfree.cz a lide kolem nej.
-
mozny zdroj informaci je vpsfree.cz a lide kolem nej.
pravda.
-
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.
Ak ten stroj limitujes schvalne na 40%, je logicke ze zvysok cpu casu pouzijes inde. Popravde som nevedel ze to xen dokaze. amazon ma "xen na mieru", nepouzivaju open source xen pokial viem.
Jenda nepisal o openVZ, ale o full virtuali:
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.
To, ze sa full alebo paravirtualne servery navzajom neovlyvnuju co sa tyka CPU je podla mna pravda. Vidim to v produkcii a pripada mi to logicke. Ak treba, mozem to testnut v praci.
To, ze sa ovlyvnuju kontajnery (povodna otazka) mi tiez pride logicke. Tu ale zalezi na konfiguracii limitov. Mohli by to potvrdit ludia z vpsfree, ako napisal to_je_jedno, alebo by sa to dalo vyskusat. Staci vytvorit a spustit 10 rovnakych kontajnerov, na vsetkych spustit napr. "cat /dev/zero > /dev/null &" a monitorizovat load. Potom na jednom spustit to iste 10x. Tiez mozem testnut ak nikto iny nemoze.
Zdravim.
-
To, ze sa full alebo paravirtualne servery navzajom neovlyvnuju co sa tyka CPU je podla mna pravda. Vidim to v produkcii a pripada mi to logicke. Ak treba, mozem to testnut v praci.
To, ze sa ovlyvnuju kontajnery (povodna otazka) mi tiez pride logicke. Tu ale zalezi na konfiguracii limitov. Mohli by to potvrdit ludia z vpsfree, ako napisal to_je_jedno, alebo by sa to dalo vyskusat. Staci vytvorit a spustit 10 rovnakych kontajnerov, na vsetkych spustit napr. "cat /dev/zero > /dev/null &" a monitorizovat load. Potom na jednom spustit to iste 10x. Tiez mozem testnut ak nikto iny nemoze.
Zdravim.
Nejak jsme se do toho zamotali, uz ztracim prehled, co nam vlastne neni jasne. Kdyz spustis tri virtualy na dvoujadre, tak se o to dvoujadro budou delit - tj. na jeden virtual vyjde o neco min nez 2/3 jadra, to je prece jasny, ne? Neovlivnovat by se mohly jenom v pripade, ze bys jedno konkretni jadro vylozene vyhradil exkluzivne pro jeden konkretni VM.
-
- 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.
Příkaz mount v bezpečnosti rozdíl neudělá, ale pokud má virtuálka vlastní blokové zařízení (a na něm až oddíly a fs), tak si to blokové zařízení může šifrovat. Dělá se to. Při každém bootu potom admin zadá heslo ("lokálně" přes konzoli, nebo nějak vzdáleně přes boot time ssh).
-
Příkaz mount v bezpečnosti rozdíl neudělá, ale pokud má virtuálka vlastní blokové zařízení (a na něm až oddíly a fs), tak si to blokové zařízení může šifrovat. Dělá se to. Při každém bootu potom admin zadá heslo ("lokálně" přes konzoli, nebo nějak vzdáleně přes boot time ssh).
To jsem adresoval v té části, jestli klíč a rozšifrovaná data uloží do paměti, kterou host může taky dumpovat.
Konzoli není problém logovat a z boot-time sshd (nejspíš na nešifrované /boot partition) si zkopírovat privátní klíč. Možná tohle myslel předřečník tou vyšší bezpečností; je pravda, že už to není chvilkové „nakouknutí“, ale rozhodně nic nepřekonatelného.
-
To jsem adresoval v té části, jestli klíč a rozšifrovaná data uloží do paměti, kterou host může taky dumpovat.
Konzoli není problém logovat a z boot-time sshd (nejspíš na nešifrované /boot partition) si zkopírovat privátní klíč. Možná tohle myslel předřečník tou vyšší bezpečností; je pravda, že už to není chvilkové „nakouknutí“, ale rozhodně nic nepřekonatelného.
Ano, toho jsem si všiml po té, co jsem reagoval na uvedený komentář. Je pravda, že rozšifrovaný klíč bude uložen v paměti (jak snadné je jej lokalizovat netuším, rád se nechám poučit). Na druhou stranu pokud už někdo řeší toto, tak pravděpodobně nebude chtít provozovat takto citlivý server jako vmko na veřejném hostingu.
-
a v tu chvili uz mu zase staci kontejnery :)
-
To, ze sa full alebo paravirtualne servery navzajom neovlyvnuju co sa tyka CPU je podla mna pravda. Vidim to v produkcii a pripada mi to logicke. Ak treba, mozem to testnut v praci.
To, ze sa ovlyvnuju kontajnery (povodna otazka) mi tiez pride logicke. Tu ale zalezi na konfiguracii limitov. Mohli by to potvrdit ludia z vpsfree, ako napisal to_je_jedno, alebo by sa to dalo vyskusat. Staci vytvorit a spustit 10 rovnakych kontajnerov, na vsetkych spustit napr. "cat /dev/zero > /dev/null &" a monitorizovat load. Potom na jednom spustit to iste 10x. Tiez mozem testnut ak nikto iny nemoze.
Zdravim.
Nejak jsme se do toho zamotali, uz ztracim prehled, co nam vlastne neni jasne. Kdyz spustis tri virtualy na dvoujadre, tak se o to dvoujadro budou delit - tj. na jeden virtual vyjde o neco min nez 2/3 jadra, to je prece jasny, ne? Neovlivnovat by se mohly jenom v pripade, ze bys jedno konkretni jadro vylozene vyhradil exkluzivne pro jeden konkretni VM.
ja si myslim ze nie. ak spustis 3 virtuali na dvojjadre, ubytok vykonu bude rovnaky pre vsetky a vykon jedneho virtualu nebude zavisiet na zatazi ostatnych dvoch. Prikontajneroch toto neplati.
-
ja si myslim ze nie. ak spustis 3 virtuali na dvojjadre, ubytok vykonu bude rovnaky pre vsetky a vykon jedneho virtualu nebude zavisiet na zatazi ostatnych dvoch. Prikontajneroch toto neplati.
Pokud spustim na dvojjadre tri VirtualBoxy, tak jsou to tri procesy. Kdyz virtual nic nedela, proces nevytezuje procesor, kdyz dela, vytezuje. Čili plánování je imho úplně stejný jako u procesů a oproti kontejnerům je jedinej rozdíl: když si v kontejneru spustím deset procesů, budou mít desetinásobnou převahu proti kontejneru s jedním procesem (za předpokladu, že tam nemám nějaký omezení na hw).
-
ja si myslim ze nie. ak spustis 3 virtuali na dvojjadre, ubytok vykonu bude rovnaky pre vsetky a vykon jedneho virtualu nebude zavisiet na zatazi ostatnych dvoch. Prikontajneroch toto neplati.
Pokud spustim na dvojjadre tri VirtualBoxy, tak jsou to tri procesy. Kdyz virtual nic nedela, proces nevytezuje procesor, kdyz dela, vytezuje. Čili plánování je imho úplně stejný jako u procesů a oproti kontejnerům je jedinej rozdíl: když si v kontejneru spustím deset procesů, budou mít desetinásobnou převahu proti kontejneru s jedním procesem (za předpokladu, že tam nemám nějaký omezení na hw).
suhlas. takto som to myslel celu dobu.
-
Ano, toho jsem si všiml po té, co jsem reagoval na uvedený komentář. Je pravda, že rozšifrovaný klíč bude uložen v paměti (jak snadné je jej lokalizovat netuším, rád se nechám poučit). Na druhou stranu pokud už někdo řeší toto, tak pravděpodobně nebude chtít provozovat takto citlivý server jako vmko na veřejném hostingu.
Na AES existuje velice rychlá utilita aeskeyfind (vyzkoušeno, funguje i pro dm-crypt s AES-XTS, klíč v GB dumpu najde i na horším počítači pod minutu), pak ještě existuje rsakeyfind (nezkoušeno). Na ostatní šifrovací algoritmy nevím o tom, že by něco existovalo, takže se klíč musí najít buď vyzkoušením všech možností, nebo nějak chytře debuggerem (pokud máš distribuční jádro, mohlo by pomoct opatřit si debug symboly a ten klíč si prostě přečíst).