Designing ESX Resource Pools

Posted on March 4th, 2008 in cluster, drs, esx, esx 3i, esx3.5, fail over, how to, services, vc2, vc2.5, vi3, vmetc.com by Rich

How do you design resource pools in an ESX Cluster? There are two strategies that are the most popular in my experience. The first strategy creates resource pools based on CPU and Memory shares for host resource conflict management, and the second strategy uses reservations and limits to guarantee physical resources and ensure VM containment. This post will use a 3 ESX host example to explain both strategies. Please feel free to comment on the pros and cons of each or why you think one is better than the other.

In the example scenario three ESX hosts each have 16 GB RAM and 2 dual core 3.0 Ghz CPUs. The three hosts will all be members of the same ESX cluster.

To scale up or scale out?

Posted on October 14th, 2007 in availability, cluster, esx, fail over, vmware by Rich

When designing VI would you rather scale vertically or horizontally? That is, would you rather increase the number of VMs per ESX host, or increase the total number of ESX hosts in your environment?

A couple of years ago with ESX 2.X it was always about the consolidation ratio.

“How many VMs can I fit on a server that has 32gb of RAM?”

“What’s my ROI on a 16 CPU server?”

Even today a healthy percentage of clients maintain this strategy. Usually for the following reasons:

  • Rack space may be limited
  • VM application connectivity or performance may be maximized
  • VMs with large amounts of RAM and multiple cpus are needed.
  • Switch ports are limited

Now with the features of VI3 it’s more feasible, and sometimes more cost effective, to have many smaller servers as your ESX hosts.

“Should I use a Bladecenter?”

“How many servers will it take to consolidate my datacenter”

Clients who scale horizontally usually:

  • Have a dynamic environment with constant growth
  • Have a more restrictive annual budget.
  • Administer application “farms” spread across hosts (Citrix, Exchange, clustered or load balanced applications)
  • Have multiple network segments to put VMs on (DMZ, Development, Internet, contractor)

In my opinion VI3 facilitates a horizontal scale out strategy that makes more sense. Recent enhancements by hardware manufacturers are focusing on performance and availability for multiple sessions hosted on virtual servers without emulation. Dual core, quad core, Intel VT, AMD-V, and other emerging features make smaller servers more efficient and capable of hosting larger numbers of virtual machines. Assuming a VI design prevents a vmotion boundary, scaling horizontally also helps ensure host fail-over and availability to manage hardware problems or software updates without taking guest VMs offline.

Which strategy do you agree with or recommend, and why?

Design a clustered VM application that can fully leverage VMotion, DRS, and HA?

Posted on October 9th, 2007 in SAN, appliance, cluster, datacore, esx, iSCSI, lefthand, mscs, openfiler, storage, treesum, vmware, vsa by Rich

This post is more of an idea then a report. If you’ve experimented with a design similar to my thoughts below please post a comment and let me know!

Have you tried to configure VMs in a MS cluster across separate ESX hosts? How about clustering a physical server with a VM? VMware’s guide can be found here. Referencing this guide I am specifically talking about “Clustering Virtual Machines Across Physical Hosts (Cluster Across Boxes)” and “Clustering Physical Machines and Virtual Machines (Standby Host)”.

Read the guide and you’ll find there are several prerequisites and restrictions. The most important ones being:

  • you must use RDMs in physical mode for shared storage
  • dedicate at least 2 physical nics to the VMs
  • you can not use multipathing software
  • you must use the LSILogic virtual SCSI adapter in your VMs
  • you can only use 32 bit VMs. You can not cluster with 64 bit VMs
  • iSCSI disks are not supported. NAS disks are not supported.
  • you can only use 2 node clustering
  • the boot disks for the VMs must be on local storage
  • clustered VMs can not participate in an ESX cluster and use VMotion, DRS and HA

So how do we design a clustered VM application that can fully leverage VMotion, DRS, and HA?