De Service Console als NFS en iSCSI server

[Wimpie]

Vanaf versie 3.0 heeft VMware in ESX meer support voor storage van .vmdk files ingebouwd.
Naast de voor veel thuisgebruikers te dure FibreChannel SAN's en en SCSI disken is nu ook
support voor NFS en iSCSI beschikbaar.
Daarmee komt het zelf opzetten van een linux gebaseerd NFS en/of iSCSI servertje binnen
handbereik. De performance was echter nog niet om over naar huis te schrijven op mijn
100MBit netwerk: installatie van een W2k3 VM kostte meerdere uren.
Omdat ook de service console gebaseerd is op linux en deze tegenwoordig achter een virtual
switch zit, ligt het voor de hand om eens te kijken of die service console niet NFS server kan
worden. De service console is in principe wel te installeren op een IDE disk, maar VMFS
daarop kan niet. Die IDE disk zou echter wel via NFS en/of iSCSI aan de vmkernel kunnen
worden aangeboden. Omdat beide achter dezelfde vSwitch kunnen zitten, zijn we dan direct
van de 100MBit bottleneck verlost omdat de data binnen de server blijft.

Uiteraard bleek hierbij de praktijk weerbarstiger dan de theorie. VMware ondersteunt alleen
NFS v3 over TCP voor NFS, en precies dat hebben ze uit de linux kernel in de service
console gesloopt. Gelukkig zijn ze zo vriendelijk geweest om niet alleen de kernel source mee
te installeren, maar ook nog eens een compiler. Met de hieronder beschreven procedure is
het mogelijk om NFS v3 over TCP weer aan te zetten in de kernel en zo een lokaal service
console filesysteem te gebruiken als datastore.

Gesteund door het succes met NFS (met dank aan de VMware fora) ben ik uiteraard verder
gegaan met iSCSI. Ook dat is vervolgens vrij eenvoudig werkend te krijgen en het resultaat is
een ESX + SAN in a box :-)

In mijn specifieke geval had ik vervolgens nog steeds een performance probleem: hdparm gaf
me een disk speed van maar liefst 3.5 MB per seconde. Dat was terug te voeren op het niet
beschikbaar zijn van DMA. De service console komt met alleen een standaard IDE driver en
daarmee kon ik op mijn Shuttle-X mini PC (VIA chipset) geen DMA doen. Ik heb dit verder
niet gedocumenteerd, maar analoog aan de NFS techniek heb ik vervolgens ook de IDE
driver gebouwd. Tot mijn stomme verbazing kon ik die na de boot laden zonder hangen of
crashen en kon ik ook nog eens DMA inschakelen. Daarmee was de disk performance
25MB/s geworden en via iSCSI nog steeds 16MB/s. Daarmee is een werkbare situatie
ontstaan.

Regels beginnende met $ zijn zaken die feitelijk worden ingetikt op de command line

NFS

Maak een backup van je module, deze wordt later overschreven:
$ cp -p /lib/modules/2.4.21-37.0.2.ELvmnix/kernel/fs/nfsd/nfsd.o /root/

Bereid de kernel source tree voor:
$ cd /usr/src/linux-2.4
$ make mrproper
$ cp /boot/config-2.4.21-37.0.2.ELvmnix .config

Bouw de nieuwe module:

$ vi .config
Zoek naar CONFIG_NFSD_TCP en wijzig de regel in: CONFIG_NFSD_TCP=y
haal daarbij het commentaar teken (#) weg

$ vi Makefile
wijzig het eind van de EXTRAVERSION regel van ELcustom in ELvmnix

$ make oldconfig && make dep
$ vi include/linux/version.h
- voor ESX 3.0.0:
zoek naar VMNIX_BUILD wijzig deze regel in: #define VMNIX_BUILD "27701"
- voor ESX 3.0.1:
zoek naar VMNIX_BUILD wijzig deze regel in: #define VMNIX_BUILD "32039"
Als de regel niet bestaat voeg hem dan toe.

$ make modules
Probeer NIET om de kernel zelf te bouwen, dat leidt tot problemen.

Als de build lukt copieer dan de module naar de juiste locatie:.
$ cp ./fs/nfsd/nfsd.o /lib/modules/2.4.21-37.0.2.ELvmnix/kernel/fs/nfsd/

Testen:
stop eventueel draaiende portmapper, nfslock en nfs:
$ /etc/init.d/nfslock stop
$ /etc/init.d/nfs stop
$ /etc/init.d/portmap stop

Unload modules:
$ rmmod nfsd
$ depmod -a
Depmod mag geen unresolved symbols geven, anders even bovenstaande goed lezen en
nog eens proberen
Laden nieuwe module:
$ modprobe nfsd

Start services:
$ /etc/init.d/portmap start
$ /etc/init.d/nfs start
$ /etc/init.d/nfslock start

$ rpcinfo -p
Moet nu voor nfs de volgende 4 regels laten zien:
         100003 2 udp 2049 nfs
         100003 3 udp 2049 nfs
         100003 2 tcp 2049 nfs
         100003 3 tcp 2049 nfs

Service and Firewall Configuratie

$ vi /etc/init.d/nfs
wijzig regel 6:
$ chkconfig: - 50 20

Hierdoor wordt nfs eerder gestart tijdens de boot zodat de vmkernel de NFS datastore kan
mounten

$ chkconfig --level 345 nfs on
$ chkconfig --level 345 portmap on

Firewall openzetten
$ esxcfg-firewall -o 111,tcp,in,sunrpc
$ esxcfg-firewall -o 111,udp,in,sunrpc
$ esxcfg-firewall -o 369,tcp,in,rpc2portmap
$ esxcfg-firewall -o 369,udp,in,rpc2portmap
$ esxcfg-firewall -o 808,tcp,in,mountd
$ esxcfg-firewall -o 2049,tcp,in,nfs
$ esxcfg-firewall -o 2049,udp,in,nfs

$ vi /etc/sysconfig/nfs
Voeg de volgende regel toe
MOUNTD_PORT=808

Hierdoor gebruikt de mountd altijd poort 808 in plaats van een random poortnummer zodat de
firewall hiervoor geconfigureerd kan worden.

Start nu de ESX server opnieuw om alles te testen.

iSCSI

Als dit werkt gaan we verder met iSCSI:
Download v.0.3.8 van iSCSI Enterprise Target van SourceForge (
http://prdownloads.sourceforge.net/iscsitarget/iscsitarget-0.3.8.tar.gz?download). We moeten
deze versie gebruiken omdat de nieuwere iSCSI versies alleen kernel 2.6.x ondersteunen.

Pak de tarball uit en ga in de source directory staan

$ cd /tmp
$ tar xvzf <pad/naar/iscsi-target .tgz file>
$ cd iscsitarget*

Wijzig enkele regels in kernel/daemon.c en kernel/workerthread.c files i.v.m. een signal
locking issue. De aanhalingstekens zijn voor de leesbaarheid: tik deze niet in.
$ vi kernel/daemon.c
vervang twee keer "sigmask_lock" door "sighand->siglock"

$ vi kernel/workerthread.c
vervang nogmaals twee keer "sigmask_lock" door "sighand->siglock"

Indien nog niet gedaan bereid dan de kernel tree even voor:
$ cd /usr/src/linux-2.4
$ cp -p /boot/config* .config
$ make dep
$ cd -

Compileer de source
$ make KERNELSRC=/usr/src/linux-2.4

Installeer de spullen:
$ make KERNELSRC=/usr/src/linux-2.4 install

Definieer je targets in /etc/ietd.conf
$ cp -pi ietd.conf /etc/
$ vi /etc/ietd.conf

Laat de deamon starten tijdens de boot:
$ chkconfig --level 345 iscsi-target on
$ chkconfig --level 126 iscsi-target off

Open de firewall voor incoming iscsi traffic
$ esxcfg-firewall -o 3260,tcp,in,iscsi-target

Testen:
Maak bijvoorbeeld snel even een sparse file aan om aan te bieden als scsi target:
$ dd if=/dev/zero of=lun0 bs=1M count=0 seek=5000

De (minimale voor twee luns) config in ietd.conf is dan als volgt:
Target iqn.2001-04.com.blah:vmfsfile
      Lun 0 /export/lun0 fileio
      Alias File

Target iqn.2001-04.com.blah:vmfsdisk
      Lun 1 /dev/hda5 fileio
      Alias Disk

[eislon]

ik lees dit wel erg laat misschien, maar het valt mij ook op dat met XenExpress een gast-os als NFS server te gebruiken ook niet erg snel is op mijn 100Mbit netwerk.

Het werkt wel, maar je hebt wel geduld nodig.

[arjanhs]

ik lees dit wel erg laat misschien, maar het valt mij ook op dat met XenExpress een gast-os als NFS server te gebruiken ook niet erg snel is op mijn 100Mbit netwerk.

Het werkt wel, maar je hebt wel geduld nodig.

Het mooie hiermee is dat je gebruik kunt maken van ESX 3, zonder dat je SCSI disken enz nodig bent voor je VMFS volumes, zou moeten werken, heb het nog niet getest, misschien meer iets voor een tester, en eventueel deze handleiding daarna aan passen :-)