Linux-VServer - instalace a spuštění (diskuse)

[Milan Lajtoš]

No, moze to byt sice pekny clanok (este som ho necital), no urcite nie som sam, ktory caka na interview s Markom Shuttleworthom.. Ak dobre viem, tak uz bol davno slubeny, no nic som zatial ohladom toho nevidel.. Den, co den cakam na polnoc a stale nic.. Dlho som sa drzal, no teraz mi uz akosi povolili nervy a musel som sa konecne vyjadrit..

[mibo]

Take cekam, ale teda asi bych si otevrel abicko beztak, ctu vse, proste pulnoc odbyla, klik na abicko, hihi ale teda nejvetsi podraz by byl davat clanky ve 2 hodiny v noci treba :D

[Michal Kubeček]

A proč to místo do vzkazů pro redakci, kam by to patřilo, píšete k článku, se kterým vaše připomínka absolutně nijak nesouvisí?

[Michal Vyskočil]

Rozhovor těžko vyjde dřív, než se Robert vrátí z dovolené a dokončí překlad. Pravděpodobně vyjde příští týden

[Luboš Doležel (Doli)]

Článek je už nahrubo přeložený do češtiny - ještě se čeká na autorizaci anglického originálu.

[Jaroslav Tomeček]

Onlouvám se, ale z článku mi vypadl důležitý odstavec. Už jsem na to upozornil redakci, snad to opraví.

Virtuální server spouštíme a ovládáme pomocí utility vserver. Její syntax je:

vserver [ options ] [vserver name] [options]

První položkou options mohou být:

• build - Pro vytvoření serveru name, jak bylo popsáno výše.
• enter - Pro vstup do virtuální serveru name, pokud je spuštěn.
• exec - Pro spuštění příkazu uvnitř serveru name jako root. Příkaz je uveden včetně svých parametrů jako druhá položka options.
• suexec - Spouští příkaz uvnitř serveru name pod určitým uživatelským číslem. Syntax je vserver name suexec userid command, kde userid je číslo uživatele a command je příkaz včetně parametrů.
• service - Ovládá služby uvnitř serveru name. Příkladem může být: vserver name service httpd start.
• start - Spouští server name.
• stop - Ukončuje server name.
• running - Test, jestli server name běží. Neněží-li server, příkaz vrací jeho návratový kód.
• status - Vrací informace o serveru name jako stav, uptime, počet procesů, ...
• restart - Restartuje server name.

[Luboš Doležel (Doli)]

Přidal jsem to tam - je to na správném místě?

[Jaroslav Tomeček]

Je, dekuji

[phero]

Funguje i to tak, že jako hostitelský systém mám "normální systém", jen nainstaluji jiný balíček s jádrem a pak můžu používát vserver místo chrootu?

[Jaroslav Tomeček]

V podstate ano.

[tlamik]

Ja sem doted pouzival XEN, pokud s nim take mate nejake zkusenosti, muzete popsat vyhody VServeru oproti XENu, popripade i obracene? At si udelam lepsi predstavu.

[Jaroslav Tomeček]

S XENem prilis velke zkusenosti nemam. K hlavnim vyhodam, ktere znam a ke kterym se dostaneme v prubehu serialu, patri moznost temer libovolne zmeny nastaveni hardwarovych zdroju za chodu, nizke rezijni ztraty, unifikace (4. dil), sdileni soub.syst.(4. dil), spousteni procesu v kontextu z hostitelskeho systemu (2. dil).

[Jan Kokoska]

Ja se omlouvam, ale to ty stezejni rozdily bohuzel nejsou.

Vserver je predstavitel "OS-level" virtualizace primo v jadru Linuxu a pro tuhle metodu je typicke napriklad to, ze procesy z virtualnich stroju scheduluje primo ten kernel. Vetsinu akci provadi primo kernel s plnou znalosti parametru bezicich procesu, takze budete mit velkou praci v jakemkoli benchmarku namerit mezi OS-level virtualizaci jako Vserver a mezi nativnim Linuxem vetsi rozdil vykonu, nez bude chyba mereni. Tzn. rezijni ztraty velmi blizke nule.

Na druhe strane Xen je mozne vyuzit pro plnou hardwarovou virtualizaci na novych procesorech (http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors), kde tedy muzete (legalne) virtualizovat i nepozmenene Windows, nebo vyuzit tzv. para-virtualizace, kde ma hostovany virtualni stroj pozmeneny kernel pro lepsi spolupraci se schedulerem hypervisoru (tedy Xenu). Tam kde si muzete vybrat je to urcite lepsi volba, tzn. Linux je lepsi para-virtualizovat, kdezto Windows, pokud uz musite, je treba virtualizovat bez zlepsene asistence Xenu (pro rychlejsi I/O apod).

V dusledku jsou rezijni ztraty prave ten hlavni rozdil mezi Vserverem a Xenem, tedy pokud cast vaseho problemu neni virtualizovat Windows, kde neni mezi opensource technologiemi co resit a je to Xen (KVM myslim v tomhle smeru zatim daleko nebude, i kdyz naslapnuto ma dobre). Pak tam jsou veci jako migrace bezicich instanci z jednoho stroje na druhy, kterou udelate na Xenu... a muzete blizce nasimulovat na Vserveru, ale treba minuta downtime bude (u Xenu jsou to zlomky sekundy).

Konkretne k vasemu seznamu rozdilu:

- zmena nastaveni zdroju za chodu -- souhlas, ale spise slabina Xenu. Zdroje neni mozno sdilet, neni mozno udelat overcommit pameti, neziskate takovou "economy of scale" jako na Vserveru, kde proste nastavite maximalni dovolene alokace a nechate je vsechny brat z jedne nepredrozdelene hromady. U Xenu ji musite predrozdelit a nemuzete dynamicky sdilet volne zdroje vaseho fyzickeho stroje mezi temi virtualnimi.

Takze Vserver na tom neni spatne ve srovnani se Xenem! Ale pozor, jde to udelat podstatne lepe: OpenVZ (www.openvz.org). Dynamicke sidleni funguje stejne jako u vserveru *a* limity je mozno menit za behu jako u Xenu.

- nizke rezijni ztraty -- tohle uz jsem probral, Xen na tom neni a z principu veci ani nemuze byt prilis dobre (je na tom o mnoho lepe nez *srovnatelne* technologie, tedy VMware, UML, Bochs apod). Mohu byt i konkretni, srovnani Xen vs. OpenVZ (coz je totez v tomhle aspektu jako VServer): http://www.hpl.hp.com/techreports/2007/HPL-2007-59.pdf

- sdileni souboroveho subsystemu mate tam, kde udelate hardlinky, to s tou kterou virtualizaci nesouvisi. Nebo mate na mysli neco jineho?

- proces ve VM (virtualni masine) pustite patrne z obou, ve Vserveru udelate tohle:

vserver JMENO suexec root PRIKAZ PARAM1 PARAM2 ...

V Xenu predpokladam, ze by mohlo fungovat neco jako tohle:

echo PRIKAZ | xm console JMENO

Pocitam, ze tohle budete vedet lepe.

V OpenVZ, kdyz uz o nem mluvim (zminujete se o nem take?), preferuji tohle:

vzctl exec2 ID PRIKAZ ...

ID je jako jmeno u Vserveru, ale OpenVZ ma na rozdil od Vserveru odjakziva staticke ciselne ID virtualnich kontextu, ve Vserveru je ta moznost nejakou dobu k dispozici (rozhodne v 2.2, kde uz musi byt i explicitne pri konfiguraci jadra zvoleno, ze chcete starou podporu kontextu dynamickych, pro ktere podpora ve 2.3 zmizi zcela a zustanou jen staticke konfigurovane pro kazdou instanci v /etc/vservers/jmeno-vserveru/context).

Zaverem se omlouvam za przneni cestiny, ale pro schedulovani apod. proste ceska slova neznam, klidne me poucte.

[MartinT]

Takze Vserver na tom neni spatne ve srovnani se Xenem! Ale pozor, jde to udelat podstatne lepe: OpenVZ (www.openvz.org). Dynamicke sidleni funguje stejne jako u vserveru *a* limity je mozno menit za behu jako u Xenu.

Zdá se, že z praxe znáte jak vserver, tak i OpenVZ. Jsou jestě nějaké další "zásadnější" rozdíly mezi vserver a OpenVZ ? Jedná se mi o to, že kernel s vserever je standardní součástí Debianu, kdežto pro používání OpenVZ v Debianu je zapotřebí ručně aplikovat patch (a to při každém security update). Díky za odpověď.

Martin T

[Jan Kokoska]

Mate pravdu, tyhle dve virtualizacni technologie skutecne znam z praxe, o Xenu mam pouze hodne nacteno.

U OpenVZ neni prilis diskuze o patchovani vlastniho kernelu, popripade patchovani debianskeho... jen to zkuste, uprava patche, aby sednul, neni vubec trivialni. S OpenVZ neni de facto na vyber s kernely, proste se drzite OpenVZ stable rady a tim to konci. Oni aplikuji bezpecnostni patche sami, takze trackujete tu radu. Debiani balicek jejich kernelu samozrejme snadno postavite, kernel-package a make-kpkg na ten kernel funguje podle ocekavani.

Doporucim tuhle radu a presne ten vanilla kernel, na ktery rikaji, ze to je, ne 2.6.18.X pro nejnovejsi X, nebude vam fungovat.

http://download.openvz.org/kernel/branches/2.6.18/current/

OpenVZ je jinak trosku jiny zivocich nez Vserver.... OpenVZ je designovano (temihle lidmi, silny kalibr: http://www.swsoft.com/en/company/team/ ), "design-driven", kdezto Vserver vyvoj je spis "event-driven", jak rika primo Herbert Poetzl, mysli tim, ze Vserver ceka na to co se stane ve vanille a podle toho se prizpusobi... takze Vserver patch aplikujete snadno na celou radu kernelu a vzdy budete mit rychle patch na novou kenrelovou radu, je mozna i koexistence s radou jinych patchu (mam radu custom kernelu -thinkpad, kde rovnez provozuji vservery, ale takde swsusp2 patch (vservery hibernuji spokojene, neni v tom zadny problem), nebo -firewall, kde uspesne spoluzije s KLIPS patchem z projektu Openswan, apod.) Nic takoveho s OpenVZ obvykle neni mozne... zkuste byt trochu odvaznejsi se zmenou nastaveni sitovych modulu (iptables zalezitosti apod) a uz se vam to nezkompiluje! OpenVZ kernel je velmi alergicky na stourani i v konfiguracnim souboru. Ale pokud jste schopny s nekolika malo omezenimi zit (a s temi co ne, nacpete vyvojarum, oni to obratem opravi), tak vlastnosti a solidnost jejich implementace Vserver jednoznacne predci.

Zaverem tedy: u Vserveru pouzivate temer jakykoliv kernel+Vserver patch; u OpenVZ pouzivate OpenVZ kernel, nejlepe jejich stable radu. Muzete se v OpenVZ kernelu sam vrtat, preji hodne zdaru, me ale vetsinou zmeny prisly dost netrivialni, takze jsem to neresil (neco malo C za sebou mam, i kernelove).

[MartinT]

Dotaz ohledně mount parametrů nosuid,nodev,noexec .. ve vserver kontextu.

Jestli jsem to dobře pochopil, v hostitelském systému danému kontextu vytvořím jeho "/" a nainstaluji/nakopíruji mu tam co potřebuje. Na serverech využívám separátní oddíly pro /usr, /var, /tmp a /home s různě nastavenými parametry nosuid,nodev,noexec ... . Jak je to s tímto u vserver kontextu ? Může si sám mountovat přidělené oddíly (s danými parametry) ? //ale to by IMHO bylo docela náročné na počet oddílů na disku//. Nebo mu to lze "vnutit" z hostitelského systému v podobě nějakých "ACL capabilities" ? Či aspoň bude ctít tyto parametry diskového prostoru hostitelského systému ?

Díky za info.

Martin T

[Jaroslav Tomeček]

Na tohle asi neodpovim s jistotou, jednak jsme to nezkouseli a pak nemam k dispozici VServer. Co vim jiste: VServer je ponekud dost konzervativni a na kontextu nechava minimum pravomoci. Z tohoto duvodu ma nastaveni z hostitelskeho kontextu prioritu. Zaroven z kontextu neni mozne montovat "kdeco" a "kdovijak". Predpokladam, ze z hostitelskeho serveru nebude problem oddily namontovat a pak je vyuzivat v kontextu. Nevidim duvod, proc by se spravnym nastavenim nemelo byt mozne montovat timto zpusobem i pod kontextem. V nejhorsim moznem pripade muzete vytvorit "startovaci" skript kontextu /etc/vservers/<servername>/scripts/prepre-start, kde vse pripojite dle potreby z hostitele. Doporucuji se zeptat primo na http://linux-vserver.org/Communicate, bud na IRC nebo mailing listu, autoru.

[Jan Kokoska]

Martine, dobry dotaz!

Vserver kontext standardne nemuze mountovat a odmountovat vubec nic. Chybi mu totiz par POSIXovych "capabilities", coz v pripade potreby resim takhle:

echo SECURE_MOUNT >> ccapabilities
echo SECURE_REMOUNT >> ccapabilities
echo BINARY_MOUNT >> ccapabilities

Snadno ty vyznamy vygooglite.

Nemuzete ve vserveru ani vytvaret specialni soubory zarizeni pomoc mknod atd, opet v defaultu chybi capability:

echo MKNOD >> bcapabilities

Pokud neni jasne, co za magicke soubory ze se tim vytvari, jsou to konfiguracni soubory te ktere vserverove instance, ktere sidli v /etc/vservers/jmeno-vserveru/ . Pro aplikovani techto nastaveni je vserver bohuzel potreba vzdy restartovat (i kdyz jsem v tom smeru zaznamenal nejake zachvevy snahy o zlepseni, konkurence to totiz umi, viz muj dalsi komentar).

Ne ze bych vam tyhle zmeny standardne doporucoval, spis je pro me jednodussi vam to nakopirovat ze svych poznamek pro pripad, kdy jsem je vyjimecne udelat musel (neni to prilis dobry napad nechavat zapnute, obirate se potencialne o bezpecnost, pokud vserver davate nekomu jinemu nez kdo ma pristup k samotnemu fyzickemu stroji). Kdy se mi to hodilo? Kdyz jsem opravdu potreboval ve vserveru namountovat stazene ISO na loopback pro precteni souboru z nej.

Nemuzete delat "raw sockety", takze zapomente na traceroute, nmap, wireshark, atd. Opet vsechno, co bylo v zajmu bezpecnosti vserver kontextu odebrano mu zase muzete zpatky pridat, pokud to opravdu potrebujete.

Samotny disk vidite ve vserveru obvykle jako /dev/hdv1, "v" nejspis jako virtualni. Pokud je root vserveru jenom adresar na systemu, velikosti disku vidite jako velikost systemu. Pokud pouzivate vserverove kvoty, vidite velikosti podle kvot. Pokud pouzivate pro root vsereveru LVM oddily, vidite pochopitelne velikosti tech oddilu ;) Moznosti jak uzivatele ve vserveru omezit co se tyce vyuziti disku je cela rada..

[MartinT]

Díky za odpověď (oběma). Po přečtení čĺánku jsem se zamýšlel nad možnostmi využití vserver v mém případě a toto mi vrtalo hlavou. Jak to popisuje Jan Kokoska, jde tedy v principu o "vylepšený chroot" (IMHO značně). Přidávat capabilities pokud to není nezbytně nutné pro aplikace ve VPS opravdu není dobrý nápad, vše je asi lepší řešit z hostitelského systému. A pokud chci mít pro jednotlivé vservery separátní oddíly je pak LVM asi nutnost (vzhledem k počtu potencionálních vserverů a možnosti změny velikostí oddílů). Ještě budu mít jeden dotaz ohledně IP adres, ale dám jej do extra threadu, viz níže.

MartinT

[Jan Kokoska]

Pokud kontrolujete vsechny vservery, nemusite resit nic, proste je date na jeden disk vedle sebe. Je dobre, aby to nebyl root disk, ja pouzivam maly root a veskery zbytek jako /data, v pripade vserver stroju /data/vservers jako root vserver instanci. Vserver je skvely pro vasi vlastni administraci, takze tohle pouziti je plne opodstatnene.

Pokud to nekomu {pro|roz}davate a neverite tem uzivatelum, mate s Vserverem vic problemu nez zaplneni disku. DOSnou ten fyzicky system z jednoho vserveru je trivialni a at nastavujete ulimity a rlimity jak budete chtit, nic moc s tim nenadelate (posunete to do urovne o neco mene trivialni, ale porad to pujde). OpenVZ je diky svemu zazemi komercniho Virtuozza, ktere je na tohle v zasade delane, o dost dal a user_beancounters, ktere tam mate k dispozici, nasadi jednotlivym VM instancim podstatne lepsi sveraci kazajku.. je to v praxi pouzitelne a nabidnutelne klientum. Samozrejme porad bezite pod jednim kernelem, takze teoreticky problem stale muze byt... pokud vam to silne vadi, da se uz doporucit jedine Xen nebo KVM. Tam ale prijdete o spoustu fyzickych zdroju tim statickym rozdelenim (minimalne u Xenu, KVM je jeste hodne nove a zatim jsem ho netestoval), takze je to cesta mnohem vetsiho overheadu a vetsich financnich nakladu na porizeni i provoz jedne VM. Za lepsi bezpecnost se plati. OpenVZ povazuju osobne za velmi rozumny kompromis a aktualne (cca letos) ho preferuji (jakkoli se mi za nekolik let Vserveru nastradalo dost).

[MartinT]

Z napsaného se domnívám, že IP adresy na fyzické rozhraní zavede a dále obsluhuje hostující server. Tedy jenom v něm je možné provádět firewalling a další případně požadované operace (překlad adres, QoS, shaping ... ). Otázkou je, zdali je zapotřebí mít pro jednotlivé VPS různé IP Adresy, nebo jde z hostitelského serveru přidělovat i jen některé porty jedné IP adresy více VPS ? Pokud je zapotřebí mít pro jednotlivé VPS různé IP adresy, jde mezi hostitelem a VPS vytvořit nějakou virtuální LAN a porty jedné (vnější) IP adresy pak sdílet v rámci překladu adres na hostiteli ?

MartinT

[Jan Kokoska]

U Vserveru skutecne muze firewall/qos delat pouze root kontext. Pokud udelame malou odbocku k OpenVZ, tam je i virtualni sitovy interface veth a firewall/qos si muze delat primo virtualni stroj sam (plus druhy ma zvenci od roota).

Vserver muze mit tolik IP, kolik mu jich date. Jedna IP muze byt v nekolika Vserverech, jake porty si na ni v tom kterem obsadite je vase vec (v pripade konfliktu budete mit klasicke "cannot bind" chybove hlaseni na jiz obsazenem portu). Urcite budete chtit zajistit, aby root kontext neposlouchal s zadnou sluzbou na 0.0.0.0, protoze tohle by neutralizovalo tu sluzbu ve vsech Vserverech. Napriklad se to tyka ssh. Vysledkem je rozdeleni na administrativni IP fyzickeho stroje a na produkcni IP sluzeb/Vserveru. Vsechna tahle IP jsou samozrejme z pohledu kernelu localhost (neopusti stroj zadnou externi routou).

V root kontextu muzete mit libovolne preklady, REDIRECTy portu, apod, bude to fungovat podle ocekavani. Pochopitelne neni mozne nikomu prodat iluzi, ze ma ve Vserveru svoji IP, pokud ji nema, ale pokud stavite z virtualnich masin klastr s omezenym poctem verejnych vstupnich bodu, muzete preklad udelat na jednom miste a zbytek Vserveru mit na soukromych IP apod.

[MartinT]

Dík za informace z praxe (zde i výše), dobrý podklad k rozhodnutí..

MartinT

[shaman2nd]

Dobry den,

jelikoz tato diskuze vypada jeste relativne zive, zkusim se otazat zde. Chtel bych na jednom dostatecne vykonnem stroji rozjet zaraz Xen i VServer virtualizaci. VServer by mel byt instalovan v xenovske dom0 (hostitel). Duvodem je to, ze Xen potrebuji pro rozjeti hostovaneho OS, ktery bude obhospodarovat aplikace, ktere bych v hostitelskem systemu nerozjel. Zaroven ostatni aplikace chci provozovat na hostitelskem systemu (tedy systemu tohoto typu), nebot se mi libi nizka rezie tohoto zpusobu virtualizace a nepotrebuji mit dalsi xenovske hosty se zbytecnou rezii. Mate nekdo s timto budto primou zkusenost nebo alespon dostatecnou teoretickou zakladnu k tomu, abyste tento napad mohli zcela zahodit nebo naopak vylepsit?