Schlagwort: OpenVZ

Aus den geplan­ten zwei Stun­den sind bei­na­he vier Stun­den gewor­den, in denen kei­ner der Diens­te auf unse­rem Ser­ver erreich­bar gewe­sen ist.

Der Grund hier­für war eine voll­stän­di­ge Umstel­lung der Vir­tua­li­sie­rungs­platt­form. Bis­her kam auf der Maschi­ne der VMware Ser­ver zum Ein­satz, der sich auf Dau­er lei­der als Res­sour­cen­ver­schwen­der her­aus­ge­stellt hat. Obwohl ich zwi­schen­zeit­lich schon auf zwei vir­tu­el­le Maschi­nen redu­ziert hat­te und in die­sen vir­tu­el­len Maschi­nen ver­hält­nis­mä­ßig weni­ge Diens­te lau­fen, war der Ser­ver häu­fig unter Voll­last, Log­ins auf den Maschi­nen haben viel zu lan­ge gedau­ert, manch­mal reagier­ten die vir­tu­el­len Maschi­nen kaum noch. Es wur­de also drin­gend Zeit nach einer Alter­na­ti­ve Aus­schau zu hal­ten.

Durch mei­ne Arbeit an der Ost­fa­lia Hoch­schu­le bin ich auf die Vir­tua­li­sie­rungs­lö­sung OpenVZ gestos­sen. OpenVZ ist kein Voll­vir­tua­li­sie­rer wie es VMware Ser­ver, Par­al­lels oder Vir­tu­al­Box sind, son­dern eine con­tai­ner­ba­sier­te Vir­tua­li­sie­rungs­lö­sung. Dank die­ser ande­ren Her­an­ge­hens­wei­se, die einem chroot-Ver­fah­ren ziem­lich ähnelt, ist der Res­sour­cen­be­darf bei ähn­li­chen Betriebs­sys­te­men ziem­lich gering. Als Nach­teil erkauft man sich die feh­len­de Mög­lich­keit, Fremd­sys­te­me, wie bspw. Win­dows, auf einem Linux-Ser­ver zu instal­lie­ren. OpenVZ eig­net sich also nur dann, wenn ohne­hin nur Linux-Vari­an­ten zum Ein­satz kom­men sol­len. Da dies in mei­nem Fal­le zutrifft, habe ich aber die per­fek­te Lösung für mei­ne Zwe­cke gefun­den. Wer neben Linu­xen noch Win­dows-Instal­la­tio­nen benö­tigt, soll­te einen Blick auf Prox­mox Vir­tu­al Envi­ron­ment wer­fen, ein Pro­dukt aus deut­schen Lan­den, wel­ches OpenVZ und eine KVM-Vir­tua­li­sie­rung mit lib­virt unter einen Hut bringt und das gan­ze Sys­tem sogar recht kom­for­ta­bel über eine web­ba­sier­te Kon­fi­gu­ra­ti­ons­ober­flä­che admi­nis­trie­ren lässt. Die­se Lösung exis­tiert sowohl als freie als auch als kom­mer­zi­el­le Vari­an­te.

Zurück zu OpenVZ. Um OpenVZ zu instal­lie­ren braucht es nicht son­der­lich viel Fach­wis­sen. Auf einem Debi­an-Etch-basie­ren­den Host genügt es, den pas­sen­den OpenVZ-Ker­nel ein­zu­spie­len. Die Kon­troll­werk­zeu­ge wer­den durch ent­spre­chen­de Abhän­gig­kei­ten auto­ma­tisch instal­liert. Der Instal­la­ti­ons­pro­zess soll­te auch dafür sor­gen, dass der Ker­nel beim nächs­ten Start des Host-Sys­tems auto­ma­tisch gela­den wird.

Das grund­le­gen­de Set­up ist damit auch schon abge­schlos­sen. Eine vir­tu­el­le Maschi­ne anzu­le­gen ist ziem­lich sim­pel:

vzctl create VM_ID --ostemplate TEMPLATE_NAME --ipadd IPADRESSE --hostname HOSTNAME (-- config CONFIG_NAME)

erzeugt eine neue VM mit der ID VM_ID (ein rei­ner Zah­len­wert), mit dem Betriebs­sys­tem aus TEMPLATE_NAME (dazu gleich mehr), mit der IP-adres­se IPADRESSE, dem Host­na­men HOSTNAME und optio­nal den Vor­ein­stel­lun­gen aus der Datei CONFIG_NAME.

Erklä­rungs­be­dürf­tig sind an die­ser Stel­le die Wer­te für die Para­me­ter —ostem­pla­te und —con­fig.

Um ein Betriebs­sys­tem in einen OpenVZ-Con­tai­ner zu instal­lie­ren wird nicht wie man es von einer KVM-Lösung gewöhnt ist mit­tels eines ISOs das Sys­tem ein­ge­spielt, es wird eine Art Tem­pla­te, also Vor­la­ge ver­wen­det. Die­se Tem­pla­tes gibt es zuhauf auf den Unter­sei­ten von OpenVZ, auch die Jungs von Prox­mox VE hal­ten eini­ge Tem­pla­tes bereit. Die TAR-GZ-Archi­ve müs­sen nicht ent­packt wer­den, sie wer­den ein­fach in das Tem­pla­te-Ver­zeich­nis von OpenVZ gespei­chert und ste­hen dann dort über den oben genann­ten Para­me­ter zur Ver­fü­gung. Zu beach­ten ist eigent­lich nur, dass der Tem­pla­tena­me ohne .tar.gz zu schrei­ben ist. Auf mei­nem Debi­an-Host ist es der Pfad

/var/lib/vz/template/cache

Der Para­me­ter —con­fig dient der Ver­wen­dung einer Stan­dard­vor­la­ge für einen neu­en Con­tai­ner. Da die Kon­fi­gu­ra­ti­ons­da­tei­en von OpenVZ recht schwer ver­ständ­lich sind, bie­tet sich das Tool

vzsplit

an. Nach dem Auf­ruf des Tools wird man nach der Anzahl der auf dem Ser­ver gewünsch­ten VMs gefragt. Die­se Aus­ga­be kopiert man dann ein­fach in eine Datei, wel­che wie­der­um im Ver­zeich­nis

/etc/vz/conf

gespei­chert wird. Der Datei­na­me muss mit ve begin­nen und mit .conf-sam­ple enden, damit er als Vor­la­ge die­nen darf. Die Zei­chen zwi­schen die­sen Zei­chen wie­der­um wer­den dem Para­me­ter —con­fig über­ge­ben. Heißt die Datei also ve-16ve.conf-sample muss der Schal­ter —con­fig 16ve hei­ßen. Am Ende eines sol­chen Tem­pla­tes ist das Ein­fü­gen einer Zei­le mit dem Inhalt ONBOOT=“yes” emp­feh­lens­wert, damit die VM beim Neu­start des Hosts gleich mit gestar­tet wird.

Nach der in weni­gen Sekun­den erle­dig­ten Erstel­lung eines neu­en Con­tai­ners müs­sen noch eini­ge Grund­ein­stel­lun­gen gesetzt wer­den:

vzctl set VM_ID --nameserver NAMESERVER_IP --userpasswd root:ROOTPW --diskspace nG:mG --save

Der Para­me­ter —disks­pace wird mit einem Soft- und einem Hard-Limit ange­ge­ben. n und m sind jeweils durch Zah­len­wer­te zu erset­zen, die auch phy­si­ka­lisch auf der Fest­plat­te des Hosts statt­fin­den.

Mit einem beherz­ten

vzctl start VM_ID

soll­te die neu ange­leg­te VM star­ten und ein paar Mel­dun­gen auf dem Bild­schirm aus­ge­ben. Mit

vzctl enter VM_ID

mel­det man sich direkt in der VM an und kann auch ohne funk­tio­nie­ren­des Netz­werk oder SSH in der Maschi­ne arbei­ten. Als aller­ers­tes soll­te man, unab­hän­gig vom ver­wen­de­ten Tem­pla­te alle Paket­lis­ten und Pake­te aktua­li­sie­ren. Danach kann man wie gewohnt arbei­ten, Pake­te instal­lie­ren, etc. Soll die VM ange­hal­ten wer­den, wird auf dem Host der Befehl

vzctl stop VM_ID

auf­ge­ru­fen. Die VM wird nun sau­ber her­un­ter­ge­fah­ren.

Wie mein Freund und Kol­le­ge Arne her­aus­ge­fun­den hat, muss man Ubun­tu 10.04.1 nach einem Sys­tem­up­date noch Manie­ren bei­brin­gen, da sonst das Netz­werk nicht funk­tio­niert. Damit Ubun­tu im Con­tai­ner wie­der kom­mu­ni­zie­ren kann, muss fol­gen­de Datei samt Inhalt ange­legt wer­den:

/etc/init/openvz.conf# OpenVZ - Fix init sequence to have OpenVZ working with upstartdescription "OpenVZ"start on startuptaskpre-start script  # mount -t devpts devpts /dev/pts  # mount -t tmpfs varrun /var/run  # mount -t tmpfs varlock /var/lock  mkdir -p /var/run/network  # if [ ! -e /etc/mtab ]; then    # cat /proc/mounts > /etc/mtab  # fi  # touch /var/run/utmp  # chmod 664 /var/run/utmp  # chown root.utmp /var/run/utmp  # if [ "$(find /etc/network/ -name upstart -type f)" ]; then  #   chmod -x /etc/network/*/upstart || true  # fiend scriptscript  start networking  # initctl emit filesystem --no-wait  # initctl emit local-filesystems --no-wait  # initctl emit virtual-filesystems --no-wait  # init 2end script

Nach einem Neu­start der VM soll­te das Netz­werk wie­der funk­tio­nie­ren.

Auf­ge­fal­len ist mir auch, dass in vie­len Tem­pla­tes als Zeit­zo­ne Mos­kau gesetzt ist, was natür­lich auch ent­spre­chend des Stand­orts eures Ser­vers geän­dert wer­den soll­te.

OpenVZ ist eine unheim­lich fle­xi­ble Lösung, wenn nur Linux-OSe ein­ge­setzt wer­den sol­len. Das Anle­gen einer neu­en VM ist in weni­gen Sekun­den gesche­hen, der Start einer sol­chen dau­ert nicht län­ger. Ein Freund ver­riet mir, dass auf gro­ßen Ser­vern, die im pro­fes­sio­nel­len Web­hos­ting ein­ge­setzt wer­den, durch­aus bis zu 200 sol­cher vir­tu­el­len Con­tai­ner unter­ge­bracht wer­den kön­ne, ohne Per­for­mance­ein­bu­ßen fest­zu­stel­len. Aber auch für klei­ne Unter­neh­men bie­tet sich eine sol­che Lösung
a
n. Mein Ser­ver steht im Übri­gen bei Hetz­ner und stemmt jetzt immer­hin vier vir­tu­el­le Maschi­nen, in denen schon ein wenig Leben herrscht.