Linux-VServer - instalace a spuštění

7. 8. 2007 | Jaroslav Tomeček | Systém | 11966×

V minulém díle jsme se podívali na zoubek virtualizaci obecně. V dnešním díle se seznámíme podrobněji s Linux-VServerem a jeho instalací.

Linux-VServer

Linux-VServer je zástupcem virtualizace na úrovni jádra OS. Projekt byl založen Jacquesem Gélinasem a nyní jej vyvíjí skupina programátorů kolem Herberta Pötzla pod licencí GPL. Jednotlivé servery obsluhuje upravené jádro Linuxu. V souvislosti s Linux-VServerem se servery nazývají bezpečnostní kontexty (security contexts), zkráceně kontexty, v kterých je spouštěn a provozován virtuální server (VPS). Každý běžící VPS má svoji vlastní správu nezávislou na ostatních. Systém využívá a rozšiřuje již existující vlastnosti a služby jádra. Jsou to zejména Linux capabilities, omezení výpočetních zdrojů (resource limits), atributy souborů (file attributes) a chroot.

Autoři jádro rozšířili o podporu kontextů, v kterých jsou procesy spuštěny, izolovány a zneviditelněny pro jiné kontexty. Pro usnadnění administrace existuje hostitelský kontext (Host context), v němž běží vlastní systém, a pro přehled procesů všech VPS je vytvořen Spectator kontext. Oba tyto kontexty jsou v současnosti implementovány jako jeden administrátorský kontext nazývaný hostitelský.

Jádro obsahuje rozšíření pro virtualizaci síťového rozhraní. Linux-VServer nepoužívá virtuální zařízení, které by zvýšilo zátěž systému, ale speciální techniky umožňující přidělovat IP adresy procesům. Bližší popis nás čeká v kapitole zabývající se konfigurací síťových rozhraní.

Pro oddělení diskových oblastí projekt používá upravené původní rozhraní chroot. Pro každý VPS se při spuštění uchovává nejvyšší možný adresář (kořenový adresář serveru), čímž je zabráněno úniku z privátní diskové oblasti. V budoucnu by v Linux-VServeru tento mechanismus měl být nahrazen vhodnějším.

Instalace systému

Systém vyžaduje instalaci upraveného jádra Linuxu a utilit sloužících k instalaci, správě a manipulaci s virtuálními servery. Kontexty jsou implicitně instalovány v adresáři /vservers. Příprava samotného hostitelského systému je poměrně jednoduchá. Obtížné je sestavení, konfigurace a správa virtuálních serverů. Správce by si měl být od začátku vědom, k jakým účelům bude server sloužit a jaké vlastnosti od něj bude požadovat. Úprava chybného nastavení může být totiž velmi složitá.

Upravené jádro Linuxu vytvoříme tak, že na zdrojové kódy běžného jádra Linuxu řady 2.6, které je možné stáhnout z http://www.kernel.org ve formě komprimovaného souboru, aplikujeme patch Linux-VServeru odpovídající verze, který je k dispozici na http://linux-vserver.org v podobě diff souboru. Můžeme zvolit z několika vývojových verzí.

Dále je třeba nainstalovat vserver-utils, balíček utilit a pomocných programů potřebných ke správě a provozu virtuálních serverů. Tyto programy je také možné stáhnout z domovské stránky projektu.

Po instalaci a restartu systému by se měl spustit démon vprocunhide, který se stará o viditelnost souborů v adresáři /proc každého ze serverů.

Vytvoření virtuálního serveru

Virtuální server vytvoříme pomocí utility vserver. Například server test postavený na distribuci Fedora Core 6 založíme příkazem:

# vserver test build -m apt-rpm \
> --hostname=servername.mydomain.tld \
> --interface eth0:1.2.3.4/24 --context=42 -- -d fc6

Přepínač -m značí metodu, kterou bude virtuální server sestaven. Argumenty mohou být apt-rpm, rpm a yum. Pak pro stažení potřebných balíčků z Internetu nebo jiného zdroje bude použit program apt-get, rpm nebo yum. Pro server založený na distribuci Debian je možné aplikovat metodu s argumentem debootstrap, která využije instalovaný balíček debootstrap nebo, pokud na systému instalován není, stáhne jej z Internetu. Metoda skeleton založí pouze základní adresářovou strukturu a konfigurační soubory a příprava virtuálního serveru je dále ponechána na správci. Do adresářové kostry může zapsat předpřipravený server, který stáhne ze stránek projektu, nebo může vytvořit vlastní distribuci.

Argumentem přepínače --hostname je síťové jméno virtuálního serveru.

Přepínač --interface konfiguruje IP adresu virtuálního serveru s označením délky prefixu a síťového zařízení, které bude virtuální server využívat. Zařízení můžeme v serveru přidělit alias. Chceme-li, aby bylo síťové zařízení eth0 ve virtuálním serveru označeno například jako guest0, pak použijeme argument přepínače --interface ve tvaru guest0=eth0:192.168.0.1/24. Tento přepínač je možné použít vícenásobně.

Přepínačem --context vynutíme statický kontext tohoto virtuálního serveru a přidělíme mu číslo. Pokud přepínač není uveden bude kontextové číslo přidělováno dynamicky při startu virtuálního serveru.

Argument fc6 určuje, že virtuální server bude sestaven podle šablony operačního systému Fedora Core 6, které jsou uloženy v adresáři /etc/vservers/.distributions/. Pro -m skeleton nemá přepínač význam.

Přepínačem -d určíme instalaci z Internetu, přepínač -b určuje lokální zdroj. Pokud po přepínači uvedeme opět přepínač -m s argumentem určujícím cestu k instalačním balíkům, bude virtuální server vytvořen z tohoto zdroje.

Síťové zařízení, které bude moci kontext využívat, určíme pomocí --netdev (například --netdev eth0).

Přepínačem --flags nastavujeme speciální příznaky virtuálních serverů jako jsou sched, nproc, jednotlivé přepínače oddělujeme čárkou.

Přepsání již existujícího virtuálního serveru se stejným názvem vynutíme přepínačem --force.

Kontextová čísla – vytvoření, spuštění kontextu

Při vytváření virtuálního serveru neboli kontextu můžeme zadat jeho statické kontextové číslo (volba --context utility vserver s přepínačem --build). Číslo je využíváno při určování příslušnosti procesu nebo souboru k virtuálnímu serveru. Systém touto identifikací zajišťuje izolaci a bezpečnost serverů. Kontextové číslo je v terminologii Linux-VServeru označováno zkratkou xid. Neuvedeme-li jej při vytváření virtuálního serveru, je generováno dynamicky při startu virtuálního serveru, avšak nevýhoda takového řešení spočívá v rozdílném čísle kontextu po každém spuštění.

Kontextové číslo je po jméně kontextu, které slouží ke snadnému zapamatování, nejdůležitějším identifikátorem virtuálního serveru. Využívají jej utility Linux-VServeru spravující běžící kontexty. Právě z tohoto důvodu by bylo vhodné, aby měl každý kontext svoje jedinečné statické číslo.

Pokud jsme nenastavili kontextové číslo při vytváření virtuálního serveru, můžeme tak učinit vložením zvoleného kontextové čísla do souboru /etc/vservers/<id_of_vserver>/context. Zvolíme-li kontextové číslo, které bylo přiděleno už dříve jinému kontextu, pak utilita vserver nahlásí chybu.

Kontextová čísla běžících virtuálních serverů můžeme vypsat utilitou vserver-stat.

Některé funkce a nastavení virtuálních serverů, například diskové limity Linux-VServeru, lze použít pouze se statickým kontextovým číslem.

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ího 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ěží. Neběží-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.

Ve dřívějších verzích Linux-Vserveru jsme dynamické přidělení a případnou změnu kontextu mohli provést utilitou chcontext. Ta byla nahrazena několika utilitami, z nichž nejdůležitější jsou vcontext, vattribute a vuname:

• vcontext – Vytvoří kontext a spustí v něm proces nebo změní kontext běžícího procesu. Nápovědu získáme zadáním vcontext --help. Spuštění procesu ls s přepínačem -l v novém kontextu 1000 může vypadat takto:

  # vcontext --create --xid 1000 -- ls -l

• vattribute – Nastavuje capabilities a příznaky pro procesy v daných kontextech. Nápovědu získáme po zadání vattribute --help. Chceme-li vypnout capabilities nebo příznaky, uvedeme před jejich označení znak ! nebo ~.
• vuname – Nastavuje a zobrazuje identifikační údaje o kontextu, například hostitelské jméno, verzi kontextu a podobné záznamy ukládané v adresáři /etc/vservers/test0/uts. Nápovědu získáme po zadání vuname --help.

Utitility vcontext, vattribute a vuname je možné využít pro dynamické vytvoření nového kontextu pro proces, ale bez založení nového virtuálního serveru. Umožňují také migraci procesu z hostitelského uzlu do kontextu, což je jednou z největších předností Linux-VServeru nejen oproti ostatním zástupcům virtualizace na úrovni jádra, ale i ostatním virtualizačním nástrojům.

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.

Smazání kontextu

Linux-VServer neobsahuje utilitu pro mazání virtuálních serverů. Musíme tedy smazat adresář s ukládanými soubory serveru, který je implicitně v adresáři /vservers, a odpovídající konfigurační soubor a adresář v /etc/vservers. Adresáře mají stejný název jako kontext, konfigurační soubor navíc s koncovkou .conf. Virtuální server při mazání nesmí být spuštěný.

Tak už máme nainstalované jádro Linux-VServeru a umíme vytvořit virtuální server s jednoduchou konfigurací. Také víme, že každý kontext má své jedinečné číslo. Příště se podíváme na instalaci OpenVZ.

       

Komentáře

[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?