07:00am: The product was announced officially by VMware, and the bits were available for download.
08:00am: I was in my office checking the VMW’s website to download Lab Manager 4.0, and then I thought why not, let’s do the AppSpeed as well.
08:30am: I fired up the VMworld Europe 2009 AP12 session to refresh my memory about the AppSpeed.
09:00am: I was blown away by the presentation, so I decided to forget about the LM4.0 for a bit and give the AppSpeed a spin.
09:15am: the AppSpeed was up & running on my physical lab.
10:00am: I started deploying it on one of my production ESX clusters for tier-2 and dev apps.
11:00am: when the AppSpeed started to do its thing and show some statistics I was utterly stunned!
08:00pm: I created this video at home on my virtual ESX labs for publishing the next day.

If you want to get to the meat and potatoes of the AppSpeed installation and configuration, you can just view this video to get you started. If you want to see how it might look like in real production, and how it personally saved my day, jump to the next section.

Note: As you saw in the video, my lab doesn’t have yet any real applications workload, so there is actually no traffic to be metered.

The AppSpeed saved my day!
I recently designed two SharePoint farms running on VI3 as per VMware & Microsoft recommendations and guidelines, each farm consisted of 2 WFE VMs with NLB, 1 Indexing VM server, with 2 Active/Passive physical SQL nodes for the backend database. The SP farms worked perfectly well most of the time, however, sometimes we used to get some strange delay in page loads, and it was happening randomly across deferent pages and not in any particular time. I kept looking and looking for any reason that would be causing these delays from the virtual environment, but nothing. Yesterday when I deployed the AppSpeed in my production, I was able to see that one of my VMs running the Microsoft SCOM was producing a hell of SQL transactions to the SQL cluster. Since the SCOM is not that critical in our environment, where we heavily depend on other monitoring software like the ManageEngine Application Monitor & OpManager, I stopped the SCOM and I instantly saw a noticeable drop down in the Mem & CPU utilization on the SQL cluster. From that moment till the time of writing these words, the SharePoint farms are performing perfectly well. Our DBAs were able to identify that our physical SQL cluster needs an urgent memory upgrade, and in fact considering virtualizing it completely on our new vSphere installation.

Are you a VMware expert?
The AppSpeed is not meant to replace any of your existing monitoring tools that you are happy with. It’s another great visibility tool for doing that, not to mention the SLA part and the integration with the vCloud technologies. I just wanted to tell you that you still need this even if you are a VMware expert who knows how to use the traditional tools for performance analysis. Let me give you a very practical example:
In the SharePoint scenario that I’ve described above, I could still identify the problem as follows:

• I can use the ManageEngine Application Monitor to identify that there is a high memory utilization on the SQL nodes.
• I can use the NetFlow protocol on VMware ESX 3.5 (as demonstrated here) to identify that the SCOM VM is having a high traffic on the vSwitch out to the SQL cluster.
• I can use esxtop to record, play or analyze in high details that the ESX servers and the SharePoint VMs are either ideal or performing perfectly normal all the time.

Now, ask yourself this: why do I need to do all that if there is a tool that can just give me the complete picture? How much time and effort do I need in order to go through this entire cycle?

To conclude all the above, in the AppSpeed presentation there was a part saying this: “AppSpeed reduces finger pointing and allows IT to focus on solving root cause of issues”. This is not marketing words, it’s a fact I literally experienced yesterday in my production environment.

I really, really wanted to share some screenshots, but since it’s running in my production I couldn’t do that here. Even with graphics editing, I’ve never been a fan of doing something like that. I do promise though that I will put some application workloads in my lab and return back with more videos or screenshots.

I extracted some screenshots from the VMworld session I mentioned at the beginning of my post, just to give you a real feel of what you see. It’s still not comparable to what you will experience in your own environment. I do encourage you to do that, whether you are on vSphere or still on VI3 like me.

Why would you use it?
Despite that fact that you can use VMware’s HA to protect your vCenter Server, this can be achieved only when you run it as a VM, while many customers and deployments out there (me included) still use the vCenter as a physical server. Even in case of using VMs, things like HA and FT (available in vSphere4) will only protect you from hardware failures, not an application or OS crashing. From here the vCenter HB (my own acronym!) is appealing! Whether it’s your vCenter service, network connectivity or even the OS, the vCenter HB can protect you from any failure that may occur through these elements.

How to start?
This is the core beauty of the product, you don’t need to restructure or design your vCenter architecture from the scratch, it’s as simple as this:
If you run physical: You can wither P2V to a new VM, or Backup/Restore to another physical server.
If you run virtual: You only need to clone the VM and you’re done.

How it works?
The vCenter HB works pretty much like a traditional cluster, you need to have a private link between the Active/Passive nodes, to maintain the heartbeat process. vCenter HB hides the passive node from the network using packet filtering, so it’s not entirely like MSCS where you have separate IP address for each node and virtual IP to operate on.

The vCenter HB has an additional mechanism to ensure the health of the active node, it’s not just a matter of a ping-response process, in fact, it can failover based on other criterias like: the CPU utilization is getting very high, the disk I/O .. and so forth.

The switchover scenarios:
Manual Switchover: This is obviously a manual process when the SysAdmin wants to perform a planned maintenance on the vCenter Server/Components.
Auto Switchover: This is the process of switching over from one node to another based on the health and criterias you set your self, like performance degradation, or even in the event of the application failure.

Failover: this is scenario happens when the complete hardware goes down, the OS crashes or the private link is down.

It’s worth mentioning here also that the vCenter Hearthbeat has a great feature for replicating specific files/fodders that you choose. One of the things that I can think of is the Sysprep files for example, you may change/add from time to time the associatedfiles for Sysprep in your active node, and map the same on the passive node. Through vCenter Heartbeat you can have this piece of mind by setting your own replication for specific folders to have that automated for you.

Some considerations when deploying the solution:

There are some considerations that you need to be aware of prior to deploying the solution, listed below in no specific order:

• vCenter Server Heartbeat currently works only on windows OS, there is no support yet for the up-coming release of the Linux based vCenter Server.
  
• vCenter HB can protect other components like: Update Manager, License Server, Capacity Planer, Converter and SQL server “only” if they run on the same protected vCenter server.
  
• There is no support now for other vCenter products like: Lab Manager, SRM, Lifecycle and Stage Manager. In case of a switchover/failover, it will appear to these other applications that the vCenter was just restarted, each product (SRM for example) handle the restoration process of the connection between itself and the vCenter Server. It is in the roadmap of the vCenter heartbeat that these applications will be protected out-of-the-box.