Posts tagged lab

vSphere 5: The eagle has landed

1

VMware today released the new version of ESX: vSphere 5. As a VMware minded person I immediately started to download the packages. First things first: Read the manual Upgrade vCenter Server to the new version. This process was quite straight forward. First you update the vCenter server itself, then the vCenter Client, then the Update Manager and finally you install the new Web services.

After installing all vCenter Services it’s time to rock. I noticed a few things: The new vCenter Web services only supports Windows and Linux. The basic stuff works, but I was not able to connect to a console from my iMac running OSX Lion 10.7. That’s really a shame VMware, since you do support Firefox on Linux. The main problem here is that there is no native desktop version available to manage vSphere from your Mac so I really hoped the new Web Services where able to fill this gap. Unfortunately it didn’t, which was quite disappointing.

The second problem I faced was updating my two nodes running ESXi 4.1 to ESXi 5 using the Update Manager. The ESX-nodes where running a Dell ESXi-image so the Update Manager was not able to perform an upgrade using the ESXi5 image from VMware itself due to driver incompatibility. Not a real issue for me. Just burn the ISO to a disk and walk up the stairs to my lab, inserting CD’s and perform the upgrade manually. Although my Dell PowerEdge 840 desktops where not listed on VMware’s hardware list, ESXi 5 runs smooth on these servers.

LAB environment:
Like said, my home lab contains one cluster build on two Dell PowerEdge 840 desktop servers. Both servers have a PERC 5i RAID-controller with 2x 146 Gbyte SAS and 2x 160 Gbyte SATA disks. Both servers have 8 Gbyte of RAM, which is the maximum the server supports. A dual core Intel Xeon 3040 is used as a processor. The only issue I have is that the servers only have 1 Network Card on-board. Though it’s a Gbit port, more NIC’s would be nice to use more features typically done in a lab environment. I have some PCI-e NIC’s available, so when I’m in a good mood I’ll install ESXi on an USB-stick and replace the RAID-controller with the new network cards.

Network storage is provided by an Synology DiskStation DS211 which has 2 iSCSI targets, 512 Gbyte each. Since the unit is running a 2 TByte raid-array build on SATA-disks, this is not really a fast solution but it still performs running 12 Virtual Machines, more than enough for lab purposes.

Gratis ESXi High Availlability

3

Soms wil je een hoge beschikbaarheid bouwen voor servers maar heb je een klein budget. Nu kun je met allerlei open source software gaan knutselen en rommelen en daarbij gemakshalve vergeten hoeveel uren je hiermee bezig bent om het maar goedkoop te laten lijken. In het verleden heb ik voor een klant wel eens een High Availlability (HA) set-up gemaakt op basis van twee Dell R200 servers met ESXi 3.5 (update 2) en een Linksys NAS. De investering voor hardware was amper 2000 euro voor deze omgeving, het aantal uren om alles werkend te krijgen was 4, inclusief testen en documentatie.

Om te beginnen zal ik zeggen dat HA in een klein aantal gevallen voordelen zal bieden. Het zal je namelijk enkel beschermen tegen uitval aan hardware. Met moderne hardware is de kans op storingen echter minimaal, de meeste fouten (>90%) kent nog steeds een menselijke oorzaak. Dat gezegd hebbende: let’s rock!

Op beide servers installeer je VMware ESXi. Destijds heb ik het met versie 3.5 (update 2) gedaan. Of het met vSphere danwel ESXi4 nog steeds werkt: geen idee. Installeer de storage, (iSCSI heeft de voorkeur boven NFS) en zorg dat beide servers bij dezelfde storage pool kunnen komen.

Vanuit beide nodes gaan we een heartbeat doen, dan wil zeggen kijken of de andere server nog beschikbaar is. Wanneer dit gedurende 15 pings niet zo is (dit is een relatief korte tijd, maar wachten tijdens testen is vervelend omdat systeembeheerders altijd ongeduldig zijn) dan zal hij de virtuele servers gaan opstarten op de andere node. We maken hiervoor een script met de naam esx_ha.sh en zetten deze in de /usr/bin. Zorg er wel voor dat het script uitvoerbaar is.

#!/bin/bash
if ! ping -c 14 10.0.0.1 > /dev/null; then
for $i in `cat /etc/other_host` ; do vmware-cmd -s register $i  && vmware-cmd $i start ; done
fi
sleep 16
if ! ping -c 14 10.0.0.1 > /dev/null; then
for $i in `cat /etc/other_host` ; do vmware-cmd -s register $i  && vmware-cmd $i start ; done
fi

Vervolgens moeten we een lijst van alle virtual machines hebben. Dat doen we met het onderstaande commando. Voer deze op beide ESXi hosts uit en SCP deze dan naar de andere ESXi node toe in de /etc directory. In het bestanbd komt een lijst met alle geregistreerde VM’s. Deze kun je nog bewerken omdat er mogelijk machines in staan die je geen HA wil geven. Ook de volgorde is belangrijk, omdat de bovenste VM als eerste opgestart gaat worden bij een storing. De sleep 16 waarde geeft de tijd tussen het opstarten weer.

vmware-cmd -l | sed ’s/\ /\\ /g’ > /root/other_host

Wat we nu nog moeten doen is een crontab aanmaken die elke minuut zal draaien om te kijken of de andere host nog leeft. Nu snap je ook waarom het eerste script eigenlijk dubbel uitgevoerd is. We kunnen een cron namelijk enkel eens per minuut laten lopen. Met de sleep 16 waarde zetten we de lopende cron in de wacht. Tel hier de (2x) 14 pingpogingen bij en je zult precies op 60 seconden uitkomen. Onderstaande kun je in je /etc/crontab zetten op ESXi hosts.

MAILTO=”mail@example.com”
* * * * * /usr/bin/esx_ha.sh

Bovenstaande is natuurlijk verre van een nette oplossing voor bedrijfskritische toepassingen maar wel een leuk voorbeeld om in een lab uit te voeren. Probeer zelf te achterhalen wat ieder commando doet en ga niet klakkeloos lopen copy/pasten omdat je anders de werking ervan niet gaat snappen.

Go to Top