Server virtualisatie of het aanbieden van virtuele servers – ook wel Virtual Private Servers genaamd – kent een ware opmars in het het hosting landschap.

Server virtualisatie bestaat al jaren op corporate niveau en in enterprise omgevingen maar wint de laatste tijd duidelijk aan terrein bij uitgewerkte dedicated server hosting oplossingen en biedt een uitstekende aanvulling op het uitbouwen van een high-end hosting platform met hoge beschikbaarheid.

De termen ‘Server Virtualisatie’ of ‘Virtuele servers’ winnen duidelijk aan terrein, maar wat is virtualisatie precies?

Het server virtualisatie aanbod is overal identiek, of toch niet?

We mogen gerust stellen dat server virtualisatie of virtuele servers aanzien worden als dé oplossing wat prijs/kwaliteit bewuste hosting betreft. Vaak wordt het aanschouwd als een alternatief voor de klassieke shared hosting en de in sommige gevallen misschien te dure dedicated server hosting oplossingen.

Er is echter een groot onderscheid dat dient gemaakt worden in de server virtualisatie markt. Het verschil zit hem in de manier waarop virtuele servers worden aangeboden. Voor veel hosting bedrijven zijn virtuele servers de heilige graal wat besparing op de energiefactuur betreft en het optimaal gebruik van hardware, wat deels ook correct is… Maar server virtualisatie biedt aanzienlijk meer voordelen dan slechts die twee facturen waar – laat ons eerlijk zijn – de gemiddelde klant niet echt van wakker zal liggen.

Vaak voorkomend is het Virtual Private Server (VPS of ‘virtuele servers’) aanbod. Deze vorm van server virtualisatie is gebaseerd op virtualisatie op het niveau van het operating systeem. Het hardware platform draait met andere één host operating systeem en zal dat operating systeem opdelen in verschillende guest operating systemen, met echter één beperking: de guest operating systemen moeten identiek zijn aan de host, aangezien deze zorgt voor de correcte communicatie tussen hard- en software.

Deze vorm van server virtualisatie is veel voorkomend, vaak betaalbaar en biedt als voordeel dat u op een schaalbare manier – naast andere klanten hun virtuele server – kan meegroeien op het platform.

Dergelijke VPS oplossingen maken de kloof tussen shared hosting en dedicated hosting kleiner, maar zijn in geen geval vergelijkbaar met de high-end virtualisatie oplossingen die FirstServed aanbiedt aan bedrijven.

Er zijn helaas ook nadelen aan verbonden: u kan voor high-end toepassingen geen operating systemen combineren op uw gekozen platform… Stel dat u bijvoorbeeld een Linux based mailserver wenst te draaien en een Windows based server operating systeem voor gebruik van een SQL Server databank. Dit zal niet gaan via operating system virtualisatie.

FirstServed biedt binnen haar expertise als server virtualisatie partner uiteraard deze oplossingen aan maar zal in geval van high-end hosting oplossingen de voorkeur geven aan Citrix XenServer, een server virtualisatie oplossing gebaseerd op een hypervisor.

De hypervisor biedt als enorme voordeel dat het host operating systeem volledig onafhankelijk is van de guest operating systemen die het herbergt.
Zo kan u op een XenServer perfect verschillende Linux based servers draaien maar ook Windows based servers, dit alles op hetzelfde hardware platform wat meteen de deur opent naar hosting oplossingen die server virtualisatie écht interessant maken: hoge beschikbaarheid (high-availability), beperking van downtimes, failover configuraties enz. Server virtualisatie biedt op dat moment aanzienlijk meer voordelen dan alleen maar het beperken van het stroomverbruik voor de hosting firma of het beter benutten van hardware resources.

Op de software markt zijn diverse spelers aanwezig als het om paravirtualisatie gaat of virtualisatie met behulp van een hypervisor: Citrix XenServer, VMWare ESX, de Microsoft Hyper-V oplossing…

Wat kan server virtualisatie of een setup met virtuele servers voor u betekenen?

 FirstServed kan voor u diverse hosting oplossingen bieden op basis van server virtualisatie: het opzetten van een platform waarbij u beschikt over twee hardware platformen welke in een actieve/standby modus worden geconfigureerd. Uw server draait in een virtuele omgeving op de ene machine en zal in geval van hardware problemen overschakelen en opgestart worden op de standby machine. Via heartbeat detectie in combinatie met verschillende parameters controleren wij of uw server correct functioneert. Wat gegevensopslag betreft werkt FirstServed naast de on-board RAID oplossing eveneens met een network RAID: uw gegevens worden over beide machines gerepliceerd over het netwerk zodat u in alle gevallen een functionerend redundant opslagplatform ter beschikking heeft.

Hiervoor maakt FirstServed gebruik van het alom vertegenwoordigde en de op enterprise niveau geïmplementeerde DRBD oplossing (Distributed Replicated Block Device). DRBD is niet nieuw, het wordt reeds jaren gebruikt voor opzetten van high-availability data clusters in tal van bedrijfskritische toepassingen. Op het moment van omschakeling naar het standby platform is uw data op beide hardware platformen beschikbaar.

Een ander voordeel van server virtualisatie die frequent door ons wordt toegepast is de schaalbaarheid (scalability) en optimale toekenning van hardware resources voor uw virtuele servers.

U kan op uw hardware platform perfect opteren voor verschillende virtuele high-end servers: een database server die in een apart proces draait en een aparte processor krijgt toegewezen, een mailserver die gebruik maakt van een aparte processor en voldoende geheugen, de webserver die in zijn eigen geïsoleerd proces draait…

Drie afzonderlijk, individueel en eenvoudig te beheren server configuraties die eenvoudig te upgraden zijn en naar een ander platform kunnen verplaatst worden zonderde klassieke migratie problematiek. Hosting zonder zorgen!

Wenst u vrijblijvend meer informatie over de server virtualisatie oplossingen van FirstServed, ons aanbod virtuele servers of high-end, op maat uitgewerkte high-availability server virtualisatie oplossingen? Onze ervaring in dit vakgebied en de verschillende case studies die reeds in de praktijk hun voordelen hebben bewezen zullen u zeker en vast overtuigen.

Needed command set:
tw_cli
    start the commandline

info c0
    display information about controller 0

rescan
    Detect new drives

maint remove c0 p1
    Remove the drive on Controller 0 Port 1

maint deleteunit c0 u1
    Remove the Unit 1 from controller 0

maint rebuild c0 u0 p1
    Rebuild Unit0 of Controller0 on Port 1

info c0 u0 rebuildstatus
    display status of rebuilding

New harddrive procedure (c0 u0, new drive in p1):
start the command line
    tw_cli
View controller information
    info c0
remove old drive if necessary
    maint remove c0 p1
Scan for new drive
    rescan
Delete default unit from new drive
    maint deleteunit c0 u1
View controller information
(p1 should not be in any unit, if it is, chances are you’ve done something terribly wrong)
    info c0
Add the new drive to Unit0
    maint rebuild c0 u0 p1
View controller information
(Unit0 should show up as rebuilding now)
    info c0
Exit the CLI
    quit

In short:
tw_cli
    info c0
    maint remove c0 p1
    rescan
    maint deleteunit c0 u1
    info c0
    maint rebuild c0 u0 p1
    info c0
    quit

———————————————————–
Warning:
    Please pay attention during this procedure.
    Failing to do so may result in massive data-loss!
(Nor FirstServed, not the writer, takes any responsibility for the content of this article or any result that may come from using it.

Since XenServer and XenEnterprise do not support installing the operating system on an MD software RAID device during the installation, you’ll have to undertake a few steps afterwards if you want to mirror your boot disks.

This article is largely based on Harry de Jong’s solution, as posted on the XenSource forums, with a few differences:

• There’s no need to copy mdadm.static from another server to the Xen host;
• The initrd ramdisk’s configuration is a bit simpler;
• There’s no need to swap the physical disks, which means the procedure can be accomplished remotely.

Create identical partitions to your boot disk /dev/sda on your second disk /dev/sdb

If /dev/sda looks like this:

/dev/sdb should look like this:

Do not forget to set the partition type to ‘fd’ (Linux RAID autodetect) instead of the default 83 (Linux).

Create the necessary device nodes

Create your MD RAID 1 arrays (with missing disks)

/dev/sda2 is just an empty, unmounted partition used by XenServer for upgrades.

Copy the Xen Storage Manager data over to RAID

Replace the uuid in the vgextend line above with the uuid of your own Xen SR.  Use ’sm info’ to display your SR’s uuid.

Remove /dev/sda3 from the SR volume group and add it to the RAID array

Mount /dev/md0 and copy the filesystem to it

Make a new initrd ramdisk containing the MD RAID drivers

Modify /mnt/etc/fstab so the system will mount / from /dev/md0 instead of LABEL=/-main.  Replace "LABEL=/-main" by "/dev/md0".

Create a new boot image and uncompress it:

Since mkinitrd looks at /etc/fstab to determine what device the root volume is on, it has now added the necessary raid drivers to the new boot image.

Uncompress the current ramdisk and add the raid drivers to it

Now add the raid module from the new ramdisk and modify the init file:

Add the following lines before the second line containing "/sbin/udevstart":

Add the following lines before the line containing "echo Creating root device":

Note: if you’ve created other MD raid devices, add a ‘raidautorun’ statement for them as well.

Copy the new ramdisk to the /mnt/boot folder and add modify GRUB’s boot menu

Replace "root=LABEL=/-main" by "root=/dev/md0" in all menu entries.

Unmount /dev/md0

Set up the Master Boot Record on /dev/sdb

Modify GRUB’s boot menu to boot from the second disk

Replace the line in the first XenServer entry that says "root (hd0,0)" with "root (hd1,0)". Also replace "root=LABEL=/-main" by "root=/dev/md0" in all menu entries.  This will allow you to boot from /dev/md0 instead of /dev/sda.  In case something goes wrong, you could always reboot using one of the other entries, which still point to /dev/sda.

Reboot

If all goes well, you should see your system mounting /dev/md0 as the filesystem root.  If not, reboot using one of the other GRUB menu entries and check out the previous steps.

Change /dev/sda’s partition types from Linux to Linux RAID autodetect

The result should be something like this:

Add the missing partitons to the RAID arrays

Then wait for the sync to complete:

Copy the running RAID setup to /etc/mdadm.conf

Be sure to add a line ‘DEVICE partitions’ at the top of /etc/mdadm.conf if you want to define MD devices that span a whole disk instead of just a partition.  Without this line, MD won’t be able to detect your drives as MD components at boot.

That’s it!

We recently took to installing our Linux servers from a USB stick.  This is much more efficient than downloading four of five cd iso’s time and again, since Linux distros like Fedora and CentOS keep spawning new releases constantly.  So we just write the rescue cd iso to a usb stick, and proceed with a network install.  This works like a charm, except that for a few times running, after completing the installation, instead of being met with the grub boot menu, we were dropped to the Grub shell brutally.  This had us stmied for a while, until we realized that for some dumb reason or other, Grub insists on recognizing the USB stick we install from as device hd0.  This means that during installation, Grub writes itself a nice config file containing the line

which points to the second drive, in our case our first hard disk, /dev/sda.  After installation - without the USB stick, Grub sees /dev/sda as the first device, hd0, and proceeds to boot the hd1 device, which now is /dev/sdb instead of /dev/sda.  Since the MBR (master boot record) was only written to /dev/sda, there’s no way Grub can boot from /dev/sdb.

In order to solve all this, from within the Grub shell, do the following:

This will instruct Grub to see both the hard disks as hd0 - since in case the first hard disk fails, /dev/sdb is effectively the first device, and install the MBR and Grub on them.  After this, reboot and do not forget to edit your grub.conf.  Change the line that reads

to

This way, Grub will once again boot from its first device as it was meant to.

Installing Grub and the MBR on the second device of your RAID 1 array should be done in any case, even if you don’t experience USB stick troubles.  If you do not, in case of a failure of your first hard disk, your system will be unable to boot until you install the MBR and Grub on your second hard disk.