latoga labs

This morning a little birdie pointed me to an HP Reference Architecture document that is hot off the press: HP BladeSystem Reference Architecture: HP Virtual Connect Flex-10 and VMware vSphere 4.0 which appears to be the vSphere 4.0 update to the previous reference architecture HP produced for VI3.  If you’re running or architecting vSphere deployments with HP blade systems (as a number of my clients are), you should check out this doc.

One of vSphere 4.0 most understated features in my opinion is Fault Tolerance.  I truly see this as a capability of vSphere that goes overlooked by most people (especially those who are focused on the cost of a vSphere deployment…as Fault Tolerance is included in vSphere Advanced and higher packages).  Not to long ago, companies paid millions of dollars to achieve a lock step fault tolerant solution.  Today, with vSphere, you can enable Fault Tolerance on a VM with just the click of your mouse.  I want to clarify the key points on Fault Tolerance that most of my clients seem to ask me about; this won’t be a deep technical discussion on Fault Tolerance, that has been covered by others already and you can find those in the links I have included at the end of this article.

I still find it amazing how the spectrum of availability solutions still gets confused by IT administrators and executives alike.  So, first a brief refresher on this spectrum:

• Load Balancing: Multiple running copies of an application, failure may affect end user.  Load Balancing via a network connection load balancer is the lowest common denominator for availability.  Actually, these solutions are typically used to achieve scale out of applications that can’t scale out on their own.  Load balancers allow you to run multiple copies of the same stateless (typically REST based) application.  The nature of the client’s connection to the application determines what availability impact a load balancer has.  If a failure occurs between a client’s connection the client should not be affected by the failure.  However, if the failure occurs during a client’s connection the client most likely will be affected by the failure in some nature, possibly losing their work (REST, stateless short transactions less affected; non-REST, long connections more affected). By definition load balancing will increase the utilization on multiple servers…that’s what it’s designed to do.  I spent five years crafting load balancing solutions for clients back in the late 90’s…and yet I still come across confusion here from time to time.
• High Availability: Single running copy of an application, failure will affect end users.  High Availability simply means that when a failure occurs, the highly available application will start running on another server.  In vSphere, this means the environment will turn on the VM on another ESX hosts to ensure minimal amount of down time for users of the application.  Typically, the user will be affected by the failure.
• Fault Tolerance: Multiple (typically two) running copies of an application, failure will not affect end user.  Fault Tolerance means that you are running two copies of the application in lock step, what ever instruction gets executed on the primary also gets executed on the secondary.  This doubles the resource utilization in your environment, but ensures that a failure has no impact on the end user.  When a failure occurs, the IP address of the primary system moves to the secondary system and the user continues doing what ever they were doing because the secondary system was processing the same instruction as the primary when it failed.  By this definition, Fault Tolerance isn’t ideal for every application due to the higher cost of resource utilization, if you’re running at 80% utilization of your VM prior to Fault Tolerance, you will be running two VMs at 80% when Fault Tolerance is turned on.

What makes vSphere’s Fault Tolerance feature a diamond in the rough is this zero downtime solution is baked into the virtualization infrastructure that you may already own.  For those key applications where zero downtime is valuable, it’s there to be turned on with minimal additional cost. There are some hardware requirements that you need to be kept in mind: like an additional network for the FT messages to be passed across (two networks if you want a 100% fault tolerant system), and ensure you have the right type of processor.  But these are similar requirements for most comparable solutions.

What makes Fault Tolerance a bit rough is the fact that it only supports one VCPU Virtual Machines.  If you application need multiple VCPUs, you’re out of luck.  At least for today.  Considering Fault Tolerance is a 1.0 feature, this limitation is understandable.  It’s even more appreciated when you consider what is happening under the covers to keep the instructions in sync across two VMs, watch the following video from VMware Principal Engineer Doug Scale for the details:

Now imagine the complexity of trying to track, synchronize, and replay the processing instructions for multiple processors. Going back and using my basic Computer Science knowledge from my first year in college makes it obvious to me that supporting multiple processors is magnitudes more challenging that support one processor. So you gotta start somewhere!

Taking all this into consideration there are multiple applications that my clients are looking at as candidates for Fault Tolerance.  From mail servers and messaging servers to custom applications where down time needs to be avoided.  Before it used to apps where “downtime needs to be avoided at any cost“, but with vSphere Fault Tolerance it has become more like “avoided at a little cost”.

What apps do you have that you’re considering Fault Tolerance for?  Tell me about them by leaving a comment.

Additional Resources on vSphere Fault Tolerance

• Training Lab simulator for vSphere Fault Tolerance (FT) (via VMWARE INFO) -  “See” FT in action thanks to this simulation created by the VMware Training team.
• Check ESX CPU And VM OS Requirments for vSphere Fault Tolerance (via VM /ETC) – Make sure you meet the hardware requirements for FT…or use the New SiteSurvey utility from VMware checks for Fault Tolerance compatibility
• VMware Fault Tolerance at your home-lab (via Eric Sloof) – after reading the last two, find out how to set this up for testing at home…
• vSphere Availability Guide (pdf) – for the full skinny on Fault Tolerance and HA in vSphere.
• How does Fault Tolerance prevent a split brain scenario? (via The VMguy) – Understand what happens when failure does occur.
• VMware engineers caution IT pros: Use Fault Tolerance sparingly (via SearchServerVirtualization) – a bit of a misleading title, but reiterates my comments above: FT is different than HA, has specific use cases, and does use additional resource.
• Don’t forget to search the VMware Knowledge Base for the latest articles on Fault Tolerance

VMware Studio 2.0 Beta was made publicly available over the weekend.  Studio 2.0 helps configure, build, deploy and customize vApps And Virtual Appliances within a vSphere environment.  Follow the link for full details.

(For some reason, it’s the name has been pre-pended with a lower-case v…yet?  )

Today was the day everyone has been waiting for, vSphere 4 is now publicly available!  This also means that all existing VMware customers who want to migrate to vSphere need to start working with the new vSphere license keys instead of the old license files.  While a change like this is never easy, the vSphere team has done a good job on make this process as simply as possible through the launch of an updated License Portal.

I’ve had a number of clients already ask me about this portal and working with the new License Keys, so I thought I would help the entire VMware community by creating this quick guide to the new portal.  Keep in mind that the change of licensing in vSphere means that the old VI3 licenses that were associated to a pair of CPUs are converted to License Keys that are associated to a single CPU.  This is the reason why you may see your license counts double.

vSphere License Portal

License Portal vSphere Tabs

When you log into your VMware License Portal, you will still land on the page that allows you to manage your VI3 licenses.  You can switch to your vSphere licenses by clicking on the tab in the upper right corner, or the vSphere link at the top of the table showing your VI3 licenses.

List of vSphere License Keys

On the vSphere License Keys page, you will see a list of the different vSphere 4 licenses you are entitled to.  Expand the row of specific license type to see all keys that are currently available.  The first time you view your vSphere keys, you will most likely have a small number of keys that contain all the CPUs that you purchased.  This is where the ability to Divide and Combine your License Keys comes in.

Dividing License Keys

Selecting vSphere License to Divide

When you click on the Divide button, you can select a License Key that you would like to divide.  You can only divide up one License Key at a time.  Select the key and click Continue.

Dividing Up a vSphere License Key

Now a dialog box will pop up which will allow you to divide up the CPUs from the selected Key.  You can chose to divide the key into 2 or more keys.  Simply select the number of new keys from the drop down list, and then enter the combination of CPUs you want in the new keys.  The information about the order that purchased the original license key is displayed for your reference.  The Total value at the bottom of the screen will show you in real time if you’re new keys have used all the CPUs from the original key.

Confirming Your License Key Division

Lastly, a dialog box will pop up confirming the new license key division you just configured.  There is also a warning that the change you are about to make could affect others.  By clicking Confirm you old license key will be divided up into your selected number of new License Keys.

The division process is what you will use to take your original license key containing all your entitled CPUs and carve out smaller license keys for deployment across your organization.

Combining License Keys

Selecting vSphere Keys to Combine

From your list of License keys, clicking on the combine button will also you to select which existing License Keys you want to combine into a new larger License Key.  Select the specific keys using the check boxes on the right, then click Continue button.

Confirming Your vSphere License Key Combination

Next a confirmation dialog box will appear to confirm these are the keys you want to combine.  Again, a nice and concise warning about affecting other users and your EULA.

Adding Comments to a vSphere License Key

After combining (or dividing) your License Keys, you will see an updated list of vSphere License keys.  By expanding a single license key, you can add additional comments to the license key in the portal.  This is valuable to keep track of who a license may have been created for within your organization.

Searching License History

Searching Your vSphere License Key History

Under the License Key History tab, you will find the ability to search through your list of License Keys.  Most Enterprise customers will end up with hundreds of license keys created by and for multiple groups within their company.  The search capabilities now allow you to search based upon the Event Type associated with a key.  So if you’re looking for history on who divided a key, you can find it.

Conclusion

While not an all inclusive guide to the new vSphere License Portal, hopefully this quick quide will help you get up to speed dealing with the migragion from VI3 to vSphere 4. For a full tutorial on vSphere Licensing, make sure to check out the vSphere Migration – Licensing video.  Also check out the vSphere4 Licensing Guide (pdf).

Thanks to a tweet today from cloudmeme, I found the InternetNews.com article VMware CTO : Cloud or software mainframe? where VMWare’s CTO, Steve Harrod, is quoted:

“Some call it a software mainframe others call it cloud, it depends on when you were born,”

I have heard a number of VMware’s executives use the term “software mainframe” when describing the new VMware Cloud OS, vSphere.  And as Steve indicated in his quote, it’s all about finding a term that resonates with the generation of your audience.

Today I joined in a virtualization discussion between the IT management teams of two Fortune 500 companies.  One of the more timely items that was discussed (with regards to the above article) was the implementing of an internal cloud.  One of the executives described it as a “change-request-less data center” where the business client is abstracted from the technology and given a transparent view of their own utilization within the data center.  Then, an executive from the other company nodded and said “getting back to a mainframe, a software mainframe”.

They were discussing their interpretations of what it meant for their business to have an internal cloud within their data center infrastructure.  And the reality is that it is starting to look more like an easily expandable, multi-vendor, distributed/modular mainframe enabled by software.

I found it interesting that the key aspect that defined an internal or enterprise cloud for these executives was the fact that the transparency of utilization was there (just like for an internet cloud and just like on the mainframe), but that the chargeback for the cost of that utilization may not be there.  Most enterprises don’t have the internal financial systems set up to do chargeback of computing resources.  And for an enterprise to change their internal  financial system is a non-trivial task.

However, levering virtualization technology to build an internal cloud that has the ability to track and report on utilization (even if the cost is null) puts the enterprise into a very powerful position:

• Quicker servicing of their business customers needs
• a simplified infrastructure which reduces operational expenses via automation and standardized IT offerings
• the ability to run the existing computing jobs of the business with little or no modifications
• a self service model which helps reduce operational costs even more
• transparency to the business clients to help them understand how much of the IT infrastructure they are using and socially drive them to use it more consciously
• an environment in which the technology can be managed at any time because it is abstracted from the business users
• and the ability to change their internal financial system in the future without major upgrades to their data center or infrastrcuture.

The software mainframe.  The enterprise cloud.