BlogIT » Virtualisation Tips III: Technicalities
Virtualisation Tips III: Technicalities
In the previous 2 blogs, the soft side of virtualisation was touched. This part is about the real stuff (no offence to non-techies meant). Though this part is technical, there are some tips to save money below, so non-techies may want to read this as well.
Tip III.1: Bring on the load
Most appliances in the data centre have optimal efficiency at about 80% load. This is true of server power supplies, CPU's themselves, but also the air-conditioning. So in a data centre that is not full, either because it is new, or because all services have migrated to virtual servers and the rest of the hardware is turned off, turn off some air-conditioning units. 18-20 degrees Celsius is cool enough. One unit with 80% load uses a lot less energy than two running at 40%.
From the cost perspective, this is what virtualisation is all about. Making more efficient use of hardware. It also means, that is is not wise to push beyond the 80% barrier, as energy consumption will that to rise exponentially.
Tip III.2: Start small
For the deployment of new services, start as small as possible with hardware. Virtual machines can grow, dependent on the Hypervisor, even without downtime. Create an agreement for fast delivery of new physical servers with a hardware vendor and scale up when you need it.
Normally hardware for a new service was created with the 3 or 5 year depreciation cycle in mind. As long as the infrastructure is set up in a scalable way, you only need to scale to survive the delivery period of new hardware, which is typically one month.
Tip III.3: Think big
Big boxes (servers) bring flexibility. With the current technology, virtual systems can only scale to the limit of the physical server. Furthermore, to make optimum use of virtualisation, at least more than a couple of virtual machines should be running on the same hardware. So if you use virtual machine with more than 2 virtual CPU's, you'll want big machines.
The biggest x86_64 compatible servers currently on the market have 32 CPU cores and can allocate 512GB of memory. These boxes are ideal. Also, because they have lots of usable PCI-e slots. You'll need these for you I/O interfaces.
Many vendors try to make you believe that blade servers are the optimal choice for virtualisation. Not so. Blades typically have only few CPU cores and have problems if more than 2 network interfaces are needed.
Blades to to be seen as a competitive technology to virtualisation. (It has its merits, but this us a blog about virtualisation)
In terms of network, the ideal network for bix boxes is 10GbE. The technology is coming down in cost rapidly. With 10GbE, you'll probably not need more than 2 interfaces per server. You'll need at least 2 for availability purposes. More than 2 interfaces will actually be useless, as a typical server will even have problems fully utilizing one 10GbE card.
Tip III.4: 64 not 32
Virtualisation should only be used in combination with 64 bit operating systems. 32 bit systems have a limit of 4GB of memory, which is not enough. Theoretically it is possible to run 32bit virtual systems on a 64bit Hypervisor, but is is best to keep everything 64bit.
Tip III.5: Use the dynamics
Modern Hypervisors ans operating systems may allow you to dynamically manage resources. Extra CPU's and storage can be added at runtime. This allows you to shift resources around. More resources to batch oriented applications at night and more to on-line during the daytime, if you're not a 24x7 web shop of course.
Though resources can be added and removed on the fly, it is not a good idea to do this with internal memory allocations. Adding more memory will not be a problem, but taking it away might be, since all unices try to use all memory in the box, either for applications, or for cache.
Dynamic allocations can also be used for fail over purposes. Most Java based application servers can be clustered. Typical deployments contain at least 2 application servers and a load balancer. For many applications this is overkill. Virtualisation in combination with central storage can offer a solution using live migration of running virtual systems to other physical machines. This can be done without interruption. However, if the original physical machine suddenly dies, live migration is not possible and the virtual system will have to be booted on another piece of hardware. This will cause a service interruption of a few minutes.
If this violates your requirements, you could use a cluster of 2 virtual machines. One to handle all requests and one as standby. The standby virtual system can be run with very little resources (no load anyway) and will thus have little impact on the other virtual machines running on that same physical box. If the physical box with the primary virtual system dies, the load balancer will transfer the load to the second virtual system. This one can then scale up in resources. This one is not my idea, but was given to me by a consultant from RedHat. He assured me that this was working well in real world situations.
