Prepping for VMware virtualization for customers

I chose Dell as my hardware platform, VMware for my host hypervisor, and I am starting with a 2 system ‘cluster’.  (I use the word ‘cluster’ not because they are clustered in a way that most people think of things, but in that they will share SAN LUNs for their storage allowing migration from one server to another.)

Last week was like having a birthday – I received two systems from Dell for our virtualization initiative that we’ll be launching in the near future.  Very exciting.

Measured power utilization of the new servers is quite reasonable at 4.6A maximum current draw using 14 of the 16 cores running at 100%.

I did this by running SETI@Home over approximately 36 hours using 3 4 vCPU systems and 1 2 vCPU system.

Now, for those of you that get into hardware, the specs!

  • Dell R905 rack mount server
  • 128GB ECC RAM
  • 2 73GB 15K RPM 2.5″ disk in RAID1 mirror
  • 4 built in 1Gbps ethernet ports
  • 2 dual port 1Gbps ethernet cards
  • 2 Qlogic 2460 4Gbps F/C HBAs

Whew, that’s a lot of compensating I must say!

Both servers are connected to a Compellent SAN with two 2TB LUN volumes mapped to both servers formated as VMFS3 filesystems.  The VMFS filesystem supports concurrent access to multiple VMware Virtual Infrastructure servers, with some blog sites claiming upwards of 8 ESX servers connected to a single LUN.  At this time, the two 2TB volumes are mapped, but I am rethinking what I should really do for the sizes of the LUNs and number of guest systems I want to operate per LUN.  This may take some trial and error because some blog entries list 4 guests per LUN, while others are unclear or talk about monitoring latency and moving busy guests to other LUNs if there is too much contention.  Oh why can’t this be more black and white!  Oh yah, because then it would be easy…

By allowing multiple VI3 servers to connect to the same filesystem gives us (the operators of the systems) the ability to do a many things easily.  My main goal is just the cold movement of guest systems from one host to another.  This requires the guest system to be shut down (powered off in a sense), then I can remove it from the inventory of one host and add it to the inventory of the other host.

With changes in pricing (options that users will later be able to choose from), we (ipHouse) can offer

  • hot migration from one host to another including the hot migration of the customers data from one LUN to another
  • high availability services on a guest system basis (one host goes down, automatically bring it up on another)
  • disaster recovery services (via either P2V or V2V basis using VMware tools and SAN to SAN replication)

I can’t hint yet about the service offerings we will be doing, unfortunately.

Comments are closed.