Krokodox's Blog

Det var inte en enkel eller självklar operation visade det sig. I alla fall inte om man som jag utgår från Citrix XenServer och försöker sätta sig in i hur det är uppbyggt. Eftersom jag kan noll om Linux så började jag där jag stod: med XenServer.

Citrix har visserligen lagt till stöd för dm-multipath för åtkomst till Storage Repository (SR), men det gäller inte för själva bootningen av XenServer. Vad ska man med ett redundant SAN till om måste ha kvar lokala hårddiskar? Nej, jag gav mig fasen på att detta *måste* gå att få att fungera annars är Linux inte moget för affärskritiska installationer.

Det tog inte lång stund innan jag hittade att i alla fall RedHat kan och har alldeles föredömligt enkel installation av sin Linux (RHEL) för bootning via SAN. Det är ypperligt i och med att Citrix bygger XenServer på CentOS, vilket i sin tur är en klon av RHEL.  Tyvärr så måste Citrix ha missat att denna funktionalitet är i allra hägsta grad väsentlig, för det är lögn i h-e att få igång boot via SAN om man samtidigt vill att bootdisken ska vara multipathkapabel.

Visserligen går det alltså bra att installera XenServer på ett LUN som presenteras av BIOS på HBA, men bara för att LUN-et presenteras som en lokal hårddisk så är den inte alls skyddad av multipath. Citrix Xenserver går fetbort med andra ord, oavsett om det är DELL’s paketerade och för-licensierade eller Citrix egen variant.

Så jag vidgade mina vyer och funderade ett tag på att installera XenServer från CentOS, alltså skapa en helt egen installation.  Eller att återigen uppta mina försök med Opensolaris. Inget av alternativen var särskilt lockande, egen komposition skulle innebära att jag mister Citrix nästan ypperliga administrationsverktyg XenCenter och Opensolaris är lite i limbo nu sen Oracle köpte SUN.

Oracle ja. Då kom jag på att dom hade upprört Linuxvärlden för något år sen när dom klonade RHEL (CentOS?) och skapade en egen Linuxvariant: Unbreakable Linux. För övrigt är det den enda Linuxplattform som Oracle stödjer för installation av sin välrenommerade databasserver. Och att dom dessutom efter mycket om och men numera stödjer installation av databasservern på sin egen hypervisor, byggd på Xen.

Oracle sitter alltså numera på en egen välsupportad Linuxdistribution, en egen välsupportad hypervisor samt ett av de bästa (om inte det bästa!) Unixoperativsystemet: Solaris. Dessutom köpte dom upp och lade ner VirtualIron, även den byggd på Xen, till förmån för sin egen distribution av XenServer. Och som om det inte vore nog så äger Oracle numera både MySQL, målet för min utflykt i virtualiserings-djungeln, samt VirtualBox, den enligt mig bästa klientvirtualiseringsmiljön.

Så jag tänkte att om OVM duger för Oracle så kan det knappast vara fy skam. I och med att Oracle tidigare inte tillhandahöll egen hårdvara så måste deras Linux / XenServer distribution fungera på de flesta stora HW leverantärernas servrar. Att Oracle främst förknippas med stora installationer borde innebära att det här med fibrechannel, SAN, multipath, etc. är kända och väldokumenterade företeelser.

Efter lite säkning fick jag napp! EMC har alldeles nyligen skapat ett dokument som steg-för-steg visar hur man sätter upp Oracle VM (OVM, Oracles XenServerdistribution) med multipath och bootning från deras Clariion CX SAN: http://www.emc.com/collateral/hardware/white-papers/h6904-deploying-oracle-vm-clariion-wp.pdf 

Bingo! Det var exakt detta jag behövde. En stabil och välpolerad paketering av XenServer som är gjord med tanke på hög tillgänglighet, dessutom väldokumenterad och det bästa av allt: graaatis! 🙂

Jag laddade hem OVM och började genast plocka isär installations CD-n för att se om den kunde bootas via PXE istället. Även detta visade sig vara väldokumenterat: http://itnewscast.com/chapter-4-oracle-vm-server-sizing-installation-and-updates#Oracle_VM_Server_PXE_Kickstart_Installation

I princip så packade jag upp installations CD skivan till en mapp (http://minserver/boot/ovm) på min webserver och lade till ett nytt menyalternativ i bootmenyn för pxelinux så var det hela klart för testning.

Även om dokumentationen inte alls stämde med vad jag tillslut lyckades snickra ihop så var den en mycket god hjälp på vägen. Det tog faktiskt mindre än två timmar från det att jag ”upptäckte” OVM tills det att installationen bootade via PXE.

Tyvärr tog min tur slut där. Även om själva bootningen via PXE var en smal sak att få igång så hamnade jag i trubbel i och med att installationen inte fattade ett jota av mina LUN-er och misslyckades hela tiden med att rensa / skapa partitioner.

Trots detta bakslag så gav jag mig inte. Själva bootningen och loggningen under uppstart var det den snyggaste (och då menar jag inte snygg såssom estetisk med flashiga färger) och mest polerade som jag har sett hittills. OVM verkade helt enkelt vara för bra för att jag skulle ge upp redan. Så jag lusläste EMC’s dokumentation och på sidan 10 stod det klart och tydligt:

”…you will need the linux mpath option during the initial installation, because Oracle VM Server supports enabling DMMP during installation.”

Äntligen! Nu gällde det bara att para ihop detta magiska kommando med PXE bootning så skulle alltså installationen kunna flyta på såsom jag ville från början.  Nästa steg var alltså att återgå till dokumentet om PXE installation och sy ihop allt. När jag läste dokumentationen så upptäckte jag nästa grej som befäste min tro på OVM: möjlighet till prekonfigurerad och därmed automatiserad installation med hjälp av Anaconda/Kickstart.

Detta var verkligen, verkligen ett stort steg framåt i jämförelse med den futtiga och begränsade ”answerfile.xml” som Citrix Xenserver har att erbjuda. En titt i dokumetationen för Kickstart samt exemplen på sidan för OVM / PXE visade att möjligheterna är om inte helt så nästan oändliga: http://fedoraproject.org/wiki/Anaconda/Kickstart.

Dokumentationen för Anaconda visade sig även den innehålla guldkorn: http://fedoraproject.org/wiki/Anaconda_Boot_Options

Under mina försök med att automatisera installationen av Citrix XenServer mha answerfile.txt blev jag bara frustrerad över att det resulterade i att eth0 pga PXE bootning(?) inte blev konfigurerad trots inställningar i answerfile-en. I jämförelse med OVM lyser det verkligen igenom att Citrix XenServer inte riktigt är redo för enterpriseinstallationer såsom Citrix vill hävda.

Det intressantaste i mitt tycke var möjligheten att kunna peka ut vilket av nätverkskorten som skulle användas för installation efter PXE bootning, nämligen parametern ”ks=bootif”. Denna inställning talar om för Anaconda att den ska använda nätverkskortet med MAC-adressen som pekas ut av parametern BOOTIF, som i sin tur tydligen sätts av pxelinux om man i dess konfigurationsfil sätter parametern ”IPAPPEND 2”.

Det hela resulterade alltså i att följande rader lades till i filen ”pxelinux.cfg/default” i TFTP servern:

LABEL OVM
MENU LABEL ^O Oracle VM Server Install
KERNEL http://minserver/boot/ovm/images/pxeboot/vmlinuz mpath
IPAPPEND 2
INITRD http://minserver/boot/ovm/images/pxeboot/initrd.img ksdevice=bootif ks=http://minserver/boot/ovm/kickstart.cfg

Själva filen ”kickstart.cfg” innehåller följande:

# Kickstartfil för Oracle VM Server

install
url –url http://minserver/boot/ovm

lang en_US.UTF-8
keyboard sv-latin1
timezone –utc Europe/Stockholm

network –device eth0 –noipv6 –bootproto dhcp
network –device eth1 –noipv6 –bootproto static –ip=192.168.99.99 –netmask=255.255.255.0

firewall –enabled –port=21:tcp –port=22:tcp –port=53:udp –port=53:tcp –port=80:tcp –port=2049:tcp –port=5900-5950:tcp –port=8002:tcp –port=8003:tcp –port=8899:tcp –port=7777:tcp –port=6389:tcp
selinux –disabled

authconfig –enableshadow –enablemd5
rootpw –iscrypted XXXXXXXXXX

ovsagent –iscrypted XXXXXXXXXX
ovsmgmntif eth0

# Partitionera hårddisken utan lokal SR (bortkommenterad)
clearpart –all –initlabel –drives=mapper/mpath0
part /boot –asprimary –fstype ext3 –size=100 –ondisk=mapper/mpath0
part / –fstype ext3 –size=3072 –ondisk=mapper/mpath0
#part /OVS –fstype ocfs2 –size=1024 –grow –ondisk=mapper/mpath0
part swap –recommended –ondisk=mapper/mpath0
bootloader –location=mbr –dom0_mem=543 –driveorder=mapper/mpath0

%packages –excludedocs
 @office
 @admin-tools
 @editors
 @text-internet
 @gnome-desktop
 @dialup
 @core
 @base
 @games
 @java
 @base-x
 @graphics
 @printing
 @sound-and-video
 @ovs-virtualization
 @graphical-internet
 tftp
 bridge-utils
 squashfs-tools

%post
 # Sätt på SNMP
 chkconfig snmpd on

# Skapa parameter för serverns IP adress (S_IP)
eval `ifconfig eth0 | awk -F ”[: ]+” ‘NR==2 {print ”export S_IP=” $4}’`

# Hämta konfigurationsfil och skapa parametrar
cd /tmp
wget http://minserver/boot/ovm/hostnames.txt

eval `grep ”DOMAIN=” hostnames.txt | awk -F ”[= \r]” ‘{print ”export S_DOMAIN=” $2}’`
eval `grep ”CONTACT=” hostnames.txt | awk -F ”[= \r]” ‘{print ”export S_CONTACT=” $2}’`
eval `grep ”SPA=” hostnames.txt | awk -F ”[= \r]” ‘{print ”export S_SPA=” $2}’`
eval `grep ”SPB=” hostnames.txt | awk -F ”[= \r]” ‘{print ”export S_SPB=” $2}’`
eval `grep ”$S_IP=” hostnames.txt | awk -F ”[= \r]” ‘{print ”export S_HOSTNAME=” $2}’`
# Sätt serverns namn
sed -i -e ”s/HOSTNAME=.*$/HOSTNAME=$S_HOSTNAME.$S_DOMAIN/” /etc/sysconfig/network
rm -f /var/log/HostIdFile.txt
# Hämta och installera EMC Navisphere Agent
cd /tmp
wget http://minserver/boot/ovm/emc/NaviHostAgent-Linux-32-x86-en_US-6.29.5.0.66-1.i386.rpm
rpm -Uvh NaviHostAgent-Linux-32-x86-en_US-6.29.5.0.66-1.i386.rpm

# Skapa en agentID.txt som talar om hur Navisphere ska kommunicera med Clariion
echo $S_HOSTNAME.$S_DOMAIN > /agentID.txt
echo $S_IP >> /agentID.txt

# Ändra konfigurationsfil för Navisphere Agent så den visar rätt i Navisphere Manager
sed -i -e ”s/Navisphere Agent$/$S_HOSTNAME.$S_DOMAIN/” /etc/Navisphere/agent.config
sed -i -e ”s/John.*$/$S_CONTACT/” /etc/Navisphere/agent.config
# Hämta och installera EMC admsnap kommandot
cd /tmp
wget http://minserver/boot/ovm/emc/admsnap-2.9.0.0.8-0.i386.rpm
rpm -Uvh admsnap-2.9.0.0.8-0.i386.rpm

# Ändra hosts filen
echo $S_IP $S_HOSTNAME.$S_DOMAIN $S_HOSTNAME >> /etc/hosts
# Starta Navisphere Agent
/etc/rc.d/init.d/naviagent start

Det som skiljer denna fil från en ”standardinstallation” är att jag lagt till TCP port 6389 för att EMC’s Navisphere Manager ska kunna ha kontakt med min Clariion samt att jag inte låter den skapa en lokal SR i och med att denna ska ligga på SAN-et och att jag vill att SNMP ska startas i samband med serverstart.

Avslutningsvis så hämtar den EMC Navisphere Agent och snapadm verktyget, installerar dessa och låser upp kommunikationsvägen till EMC Clariion SP-erna samt skapar en agentID.txt fil med information om hur Navisphere ska kommunicera med Clariion.

Ersätt XXXXXXXXXX i filen ovan med en MD5 krypterad sträng för de lösenord som du vill ha. MD5 strängen skapas enklast med följande kommando:

# grub-md5-crypt

Den frågar dig efter lösneordet två gånger och återkommer med den MD5 krypterade strängen.

Ersätt Y.Y.Y.Y och Z.Z.Z.Z med IP adressen för SPA respektive SPB i EMC SAN-et.