Kategorien
Technologie

KSM (Kernel SamePage Merging) in der Praxis

Das Gan­ze klingt zwar nach bösem Voo­doo, funk­tio­niert aber tat­säch­lich: Ker­nel Same­Page Mer­ging. Mög­lich ist das seit Ker­nel 2.6.32 und funk­tio­niert, ver­ein­facht dar­ge­stellt, so, dass der Ker­nel ver­sucht, iden­ti­sche Spei­cher­in­hal­te zu iden­ti­fi­zie­ren und die­se qua­si intern zu verlinken.

In der Pra­xis set­ze ich das auf einem von mir ver­wal­te­ten Clus­ter mit 14 Kno­ten ein, der mit der auf Vir­tua­li­sie­rung und Clus­te­ring spe­zia­li­sier­ten Linux-Dis­tri­bu­ti­on Prox­mox läuft. Prox­mox ver­eint KVM und con­tai­ner­ba­sier­te Vir­tua­li­sie­rung unter einem Dach, indem auf der einen Sei­te ein ange­pass­ter Linux-Ker­nel für die para­virt-ops-Schnitt­stel­le ein­ge­setzt und auf der ande­ren Sei­te OpenVZ für die con­tai­ner­ba­sier­te Vir­tua­li­sie­rung ver­wen­det wird. Der letz­te Arti­kel hier han­delt von die­sem The­ma. Prox­mox wird direkt auf jedem der Kno­ten instal­liert und danach über eine recht kom­for­ta­ble und moder­ne Web­ober­flä­che administriert.

Zurück zum The­ma, KSM. Ich habe einen ent­spre­chen­den Ker­nel auf einem der Kno­ten instal­liert und betrei­be auf die­sem drei KVM-Maschi­nen mit Win­dows Ser­ver 2008 R2. Alle drei Maschi­nen haben 4 GB RAM zuge­wie­sen bekom­men, soll­ten also 12 GB RAM benö­ti­gen. Jetzt kommt der Knack­punkt: jeder die­ser Kno­ten ver­fügt nur über 8 GB phy­si­ka­li­schen Spei­cher. Rein rech­ne­risch klappt das also nicht, der Kno­ten müss­te anfan­gen zu swap­pen. In der gra­fi­schen Über­sicht des Kno­tens zeigt Prox­mox eine RAM-Aus­las­tung von theo­re­ti­schen 10 GB an, tat­säch­lich wer­den aber nur unge­fähr 3,75 GB ver­wen­det, über die Hälf­te des ver­bau­ten RAMs ist also noch frei. Da die Basis aller drei Instal­la­ti­on iden­tisch ist, kann der nun theo­re­tisch drei Mal beleg­te Spei­cher zu einem Bereich zusam­men­ge­fasst und somit zu 2/3 ein­ge­spart werden.

Das Ver­fah­ren hat natür­lich nicht nur Vor­tei­le: die auf­wän­di­ge­re Spei­cher­ver­wal­tung kos­tet CPU-Zeit. Wenn aber zu erwar­ten ist, dass die instal­lier­ten VMs haupt­säch­lich viel RAM aber wenig Rechen­leis­tung benö­ti­gen, spielt das eine eher unter­ge­ord­ne­te Rol­le. In mei­nem Fal­le kommt pro Kno­ten ein Intel Core2Quad Q9550 zum Ein­satz. CPU-Leis­tung ist also aus­rei­chend da.

Red­Hat hat es geschafft, auf einer Test­ma­schi­ne mit 16 GB RAM 52 (!) VMs mit Win­dows XP par­al­lel zu betrei­ben, jeder Maschi­ne war 1 GB vir­tu­el­les RAM zuge­ord­net wor­den. Noch mal in Zah­len: theo­re­tisch belegt wor­den wären 52 GB, prak­tisch genutzt aber nur 16 GB.

Kategorien
Uncategorized

Ein paar Worte zur Downtime von gestern, 24.10.10

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 halten.

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 Variante.

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 simpel:

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 Verzeichnis

/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 werden:

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 stattfinden.

Mit einem beherzten

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 heruntergefahren.

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 werden:

/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 funktionieren.

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 sollte.

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.