Archives for April 2009

vCenter Server as a Tier 1 App

April 13, 2009 5 Comments

As virtualization becomes more and more pervasive across the data center, many of my customers are now considering their vCenter Server as a tier 1 application. This means more focus is being places on maintaining the availability of vCenter Server. To quote Gene Kranz:

“Failure is not an option.”

vCenter Server is central to the following aspects of a virtualized data center:

provides DRS & DPM monitoring and host load management
enables vMotion (central to both DRS and DPM)
centralized management portal for all VMs and ESX server running in a cluster (ESX and VMs still run without vCenter, but management become much more cumbersome)
feeding data from VMs and ESX to other IT management platforms
hosts SRM plugin for VM business continuity between data centers
provisions desktops for View (desktop virtualization)

There are a number of different strategies that can be taken to provide availability of the vCenter Server, these typically fall into one of two categories: a cold standby server or a warm standby server. Since the time needed to manually bring up a cold standby server for a large vSphere deployment can easily reach into the hours, most large organization tend toward a warm standby scenario and leverage some software automation to trigger the fail over. There are many options here that fall into the general categories of clustering or host replication. These tend to be complex and not always application specific.

To fill this gap and provide the monitoring and fail over needs of running vCenter Server as a teir 1 application, VMware recently released vCenter Server Heartbeat, which provides monitoring and automated fail over of both the vCenter Server and (optionally) the vCenter database.

Key aspects of Center Server Heartbeat:

Monitors application (vCenter Server and optionally vCenter Database), network, and OS
- underlying technology licensed from NeverFail for vCenter Server and SQL Server awareness and fail over
Supports VM or Physical deployments of vCenter Server
Uses replication engine to replicate data and transactions to standby server
fail over of vCenter and Database across wan or LAN
Protects from Split Brain scenario if a network outage were to occur
Fail over of IP address so all hosts/VMs continue to function with vCenter normally
Easy to configure, auto cloning of vCenter Server VMs (if deployed virtually) to create stand by server

My recommended approach to providing Tier 1 availability of the vCenter server

Ideally: run your vCenter server as a VM and utizliae vCenter Server Heartbeat to monitor and fail over vCenter. All accomplished with the minimal amount of configuration due to vCenter Server Heartbeat’s VM cloning capabilities.
Minimally: run vCenter server as a VM and configure a HA pair for that VM. vCenter HA operates independantly of vCenter Server and will function even when the vCenter serer fails. Becuase it is designed to provide general HA for a wide variety of situations, it is not application aware like vCenter Server Heartbeat. Also, many architects don’t prefer this solution becuase the fail over is being provided by the tool that you are trying to protect. But, it is better than no fail over solution for vCenter Server.

ESX 3.5 Update 4 Fixes ProcHot Status Issue

April 9, 2009 Leave a Comment

Yesterday one of my customers who runs HP Servers alerted me to a recent VMware KnowledgeBase article. He was nice enough to annotate the article with some screens shots from his environment. I received his permission to post this as today’s VMware Admin Guest Blogger.
So, if you’re running HP Servers and been annoyed by the error warning from the Intel ProcHot Sensor, ESX 3.5 Update 4 erases this annoyance.

—

Issue
On HP systems with the Intel PROCHOT sensor, a warning is issued, and yet the PROCHOT label is “Normal.” Furthermore, the HealthState setting of the sensor is “10”. This situation occurs because of an HP firmware issue where the digital discreet sensor asserts conflicting states. Below is a screen shot showing this in vCenter.

esx35u3-prochot-ss

Solution
This issue is resolved in ESX Server 3.5 Update 4 in that these conflicting states are now appropriately managed. Therefore, the sensor’s label and Healthstate setting would now be displayed as “Unknown,” which is proper given the information received from the firmware.

esx35u4-prochot-ss

Correctly Calculating Percentage Virtualized

April 8, 2009 4 Comments

Everyone knows the adage “there are lies, damn lies, and statistics.” This about the later, the statistics. When you are managing anything it’s true that you can’t improve what you can’t measure. So if you are trying to improve your IT business using virtualization, you need to accurately measure the percentage of your environment that is virtualized.

Most think this is an easy thing to calculate. However, as I discussed this topic with colleagues and clients it became clear that this number is not always a straight forward calculation and that many people were calculating it wrong.

As an example, take the following situation:

Acme Corporation had 550 servers before they started their server virtualization project. If, after the first phase of virtualizing Acme Corporation ends up with 100 physical servers with 50 of them running hypervisors supporting 500 virtual machines, what percentage of acme corporation’s computing environment is virtualized?

Loading ...

S
c
r
o
l
l

D
o
w
n

F
o
r

D
e
t
a
i
l
s

Most people I talk to about this have falsely thought the environment was 50% virtualized. Half of the physical servers are running virtualized. But that doesn’t take into consideration that there are 500 work loads (computers) that were virtualized and condensed onto fewer servers.

So then the correct answer must be the one achieved by taking the number of physical servers divided by the number of VMs to determine the percentage virtualized. 500%. Wait, that doesn’t make sense. How can you be more than 100% virtualized? (exactly…)

So, what’s the correct answer?

91%.

Here is the correct formula:

% virtualized = VMs / (physical servers running non-virtualized + VMs)

You’re taking the total compute work loads (measured by Operating System containers) divided by the virtualized compute work loads. So 500 VMs / 50 physical servers + 500 VMs = .909090 or 91% (ok, ok…so I rounded up to try and throw you off.)

So next time IT management asks you “What percentage virtualized are we?”, you’ll know how to correctly answer.