when relevant content is
added and updated.
VMware and Foedus joint issued a white paper some time called Tips and Tricks of Implementing Infrastructure Services on ESX Server. It’s a good read, although the first two paragpahs are meant for the virtualization-uninitiated and can be skipped if you are familiar with how to use VMware, VMotion, DRS, and HA to acheive redundancy and uptime improvements. The paper does focus largely on Windows networking, with Active Directory being repeatedly referenced. Since similar non-Windows services (such as OpenLDAP, OpenDirectory, eDirectory, etc. etc.) are affected in similar ways, it’s still a good cross-platform read despite the focus on Microsoft technologies.
If you are only going to scan the paper, there is one section I highly recommend reading, because it’s very ofen overlooked – Shutdown and Startup Sequence.
* I * Cannot * Stress * the * Importance * of * this * Enough *
Things crash – even in the best environment, you can expect to have problems now and again, and not planning this out just because you have other forms of reliable failover is no excuse. I have personally seen, in the lab and in practical reality, what happens when this tool isn’t used – it gets very nasty when you have a database server come up AFTER the server hosting and application that needs to access a database comes up, or when VPN servers come up early in the order and can’t find an authentication source.
A great tip for larger companies:
User environments with many Active Directory driven policies will want to ensure that the ESX Server %Ready time as viewed in the ESXTOP utility stays under 10
There is also the obligatory mention of time-syncing. Going back to my view on startup sequence… if you don’t install VMware Tools, you will have clock drift. If you have clock drift, services that depend on timed replication (particularly DNS, Active Directory, File Replication Services, and the Distributed File System). If you have an operating system that isn’t compatible with VMware Tools, the simple answer is this – don’t virtualize it.
What I was pleasantly surprised to see was a strong chunk of space allocated to setting up DMZ environments in VMware, which is somewhat of a sticky subject because of the two main ways it can be done (in virtual switching, or in the physcial network using additional nics in the host). The paper references one of my favorite open source projects of all time IPCop, a firewall that supports mulitple DMZs and is available as a VMware applicance. The paper’s approach is, appropriately for the material, focussed on the virtual swithcing, and they cover it well. Truthfully, I think the papwer should be renamed “How to use VMware and IPCop to make a DMZ, plus some other generic advice” because of the time they spend on DMZ vs. everything else.
To setup up IPCOP as a DMZ firewall, create two virtual switches on one or more ESX Server hosts named DMZ-EXT and DMZ-INT. Plug the red NIC of IPCOP into DMZ-EXT and the orange NIC into DMZ-INT. Plug the green NIC into whatever virtual switch is associated with the internal LAN address space.
This paper is less a tips and tricks paper and more of a general advice paper, so I wasn’t overly impressed. From the title I was expecting more focus on VMware tips and tricks, but because of the DMZ section, it still gets 7 pokers.