On 2nd June VMware announced the End of Availability of VMware vCenter Heartbeat. It is no longer available for sale after this date, but existing customers are supported through to 2018. This marks a turning point for availability when it comes to vCenter. Is this another in a line of cases where VMware has killed a product before there is a suitable replacement or alternative? With vCenter Server Heartbeat gone, your options for availability of vCenter are now limited to VMware HA. But is it really gone?

In his Notes from MWhite newsletter on 7th June, Michael White described the End of Availability as follows:

“This is very odd.  There is no other product to replace Heartbeat.  I know VMware is working on stuff, but this makes no sense to me.  But as of June 2, VMware does not sell Heartbeat any longer.  If you own it already it will be supported to 2018.  But in the meantime, what do you do?  Aside from backups, and HA, there is not much if you want to really have good up-time.  I guess there is quite a back-story here since VMware has put people into a very awkward spot and I don’t think they do that lightly.”

I agree with Michael. This is odd. I’m sure VMware is working on something. The availability of vCenter is critical as more and more products are integrated into it. It’s critical for backups (and more importantly restores) to function, it’s critical for VDI workloads (which are an important business critical app when adopted widely), for monitoring tools and provisioning tools and cloud environments. If you manage a critical environment that must be available 24/7 and have reliable analytics, then vCenter is important and needs to be protected. But availability for vCenter hasn’t been easy for a long time (accept when using heartbeat), and there is a lot of dependence on it. It was never really architected for availability in the first place. It is essentially a single point of failure. We really can’t afford that in the world of the Software-Defined Datacenter. Another good article that explains this is Julian Wood‘s article titled What VMware’s EOL of vCenter Server Heartbeat means for availability?

vCenter Server Heartbeat was the solution of choice when you needed to protect not just against infrastructure failure, but also application service failure and application performance degradation, and have options to protect vCenter across a datacenters or across a WAN environment. I had architected a number of solutions for business critical apps environments or cloud environments that included Heartbeat. I’d also written about it on this blog such as in these articles:

vCenter Server Heartbeat Installation and Validation

vSphere 5.1 and vCenter Server Heartbeat 6.5 Deployment Considerations

Using vCenter Heartbeat to Protect Non-vCenter SQL DB? Think Again!

Changing vCenter Heartbeat to CA SSL Certificates

VMware Products Not Supported with SQL Server AlwaysOn Availability Groups

But vCenter is evolving and eventually something had to change. There was a presentation at VMworld some time ago about vCenters evolution to become much more of a federated solution,  much more scalable and much more highly available. So it was inevitable that the availability options would change too. This is still something for the future though and the plans have not yet been announced. For the here and now we still need to protect the vital SDDC management infrastructure. So what are your options for vCenter availability now that vCenter Heartbeat is not available?

1. Virtualize vCenter! If you don’t have vCenter Virtualized you’re missing out on the easiest way to increase availability. If you create a management cluster for your management VM’s including your vCenters, then you will be able to easily protect them with things such as item 2.

2. vSphere HA. This is how you protect your other VM’s and it works great for vCenter as well. At least up to about 99.9% availability. You can potentially increase availability further by using VM Monitoring and potentially App HA.

3. Backups of vCenter and/or a clone of vCenter or cold stand by.

In truth, none of the above solutions fully replace the functionality of heartbeat that made it valuable and important for critical environments that needed high availability and high availability of their management infrastructure. But vCenter Server Heartbeat didn’t protect all of the tools in VMware’s rapidly growing portfolio of products either. For example there was no support for vCAC, SRM, vCD, VCM, vCOps etc. All of the other tools that you’d like high availability for also. So perhaps that they now don’t have to worry about development of vCenter Server Heartbeat the availability and architecture of some of these other products will improve? Perhaps all of these products will integrate much more easily with each other, be more easily architected in a highly available manner? Maybe this will be one of the big talking points at VMworld in 2014.

But is vCenter Heartbeat Really Gone for Good?

The answer is NO! It’s just gone back to its roots. vCenter Server Heartbeat was always a product that VMware had OEM’d from Neverfail. So now that VMware has dropped vCenter Server Heartbeat Neverfail has taken it back and you can purchase the Neverfail IT Continuity Engine. The good news is that Neverfail’s IT Continuity Engine isn’t just limited to vCenter. It works with a whole host of other products. So while vCenter Server Heartbeat is dead from a VMware perspective, it is not gone, and certainly not forgotten.

Final Word

I don’t agree with removing a product from sale prior to an alternative that is of equal or better functionality being available. This is not the first time it’s happened, it’s happened to other products. How can anyone make sensible product investment decisions when you don’t know what the shelf life is of a product? In this case VMware HA really isn’t equivalent, but it’s the alternative that is included in the price and it’s what’s available from VMware today. Everybody should have their vCenters virtualized in any case. But in this case at least you can still get the additional level of vCenter high availability if required by going to Neverfail, who were the original makers of vCenter Server Heartbeat in any case.

You can have your say and give your feedback directly to the VMware Product Managers for vCenter availability and performance. They have started a survey and they want you to let them know about your environments. They are collecting the requirements around performance, availability and scaleability that will shape the future of vCenter. So have your say in the VMware vCenter Performance Survey.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2014 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

vCenter Server Heartbeat is a critical component used to protect vCenter Server from outages in a LAN configuration, which provides high availability, and for DR in a WAN configuration, which can also support site outages. It is the only supported way to get high availability for vCenter Server, and can also protect the vCenter Server Database, SSO, and some other components. If you’re running important business critical workloads and your management infrastructure is important to you, or you’re a cloud service provider, then you’ll be wanting to use vCenter Server Heartbeat. The Product Manager that is responsible for setting the direction for vCenter Availability and vCenter Server Heartbeat in particular is in need of your feedback. If you want to have input on the future direction of this important product now is your chance.

vCenter Server Heartbeat is a product that I’ve covered a bit on this blog in articles such as VMware Products Not Supported with SQL Server AlwaysOn Availability Groups, The Status of Microsoft Failover Clustering Support on VMware vSphere 5.1, vCenter Server Heartbeat Installation and Validation, vSphere 5.1 and vCenter Server Heartbeat 6.5 Deployment Considerations, Clustering Support on vCloud Director and vCenter Databases, vSphere 5.1 Generally Available – Important Upgrade Considerations, Using vCenter Heartbeat to Protect Non-vCenter SQL DB? Think Again!, and Changing vCenter Heartbeat to CA SSL Certificates. VMware has developed a short survey that won’t take long for you to complete. Your feedback is valuable and will be taken into consideration for future product development plans. So please provide your feedback here.

Final Word

I know how busy everyone is, but spending a few moments answering the survey questions would be of great value to all concerned. You will have a say in how VMware products are developed for the benefit of everyone. Any contributions and feedback you give are greatly appreciated. So please consider taking the time to provide your feedback.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2013 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

vCenter Heartbeat is the only supported and validated solution for providing high availability to vCenter Server, and can also protect the core components that go with it (such as SSO, VUM, Inventory Service etc). I strongly recommend vCenter Server Heartbeat be considered for environments where the management infrastructure availability is critical. I’ve used vCenter Server Heartbeat in a number of implementations. But it hasn’t always been easy to implement. The good news is that now thanks to the team at VMware and VMware KBTV we have a video that takes you through the installation and validation of vCenter Server Heartbeat in a vSphere 5.1 environment. In this article I’ll give you some insight into when you might want to deploy vCenter Server Heartbeat, and you can learn how by viewing the video.

As your environment grows and becomes more critical, as you start to virtualize business critical applications, deploy private or hybrid cloud, or virtual desktops, your management infrastructure such as vCenter also increases in criticality. Loss of access to vCenter can mean loss of major functionality, not just for support and troubleshooting but also provisioning, operations, and monitoring. In a 24/7 environment where availability is paramount this can have a major impact on your organization. This is where vCenter Server Heartbeat comes in. It will protect your vCenter system, and can also protect all the core components like SSO, VUM, Inventory Service, and even the vCenter MS SQL Database, by making it highly available. All of these components can be protected by a single heartbeat license even if they are deployed on separate servers or VM’s. It can be used in two different deployment modes that either provide local-site HA on the LAN or inter-site disaster recovery across the WAN. A list of all the components that vCenter Server Heartbeat can protect were listed in my article titled vSphere 5.1 and vCenter Server Heartbeat 6.5 Deployment Considerations, which also goes into some key design considerations for 5.1 environments.

This video is a first installment of a series answering the most common questions asked by the VMware user community when deploying vCenter Server Heartbeat. Whether deploying in High Availability or Disaster Recovery deployment modes, this video will offer key points, tips and considerations for a successful deployment. The video is originally published on the VMware Support Insider Blog – vCenter Heartbeat Installation and Validation. I hope you get a lot out of this video and watch out for more videos in the series.

Final Word

vCenter Server Heartbeat is the best way to protect and provide high availability to vCenter and many of the core components. As I’ve previously written Cluster of the vCenter Server Database is not supported by VMware as a means of providing high availability, and neither is Database Mirroring. But Heartbeat does so much more than just protect the database, it provides intelligent application level high availability that includes monitoring performance metrics, so it knows when to switch over to the stand by or when to restart a service. With the proper design and implementation vCenter Server Heartbeat can provide worry free high availability protection for your core VMware management components. I recommend you consider vCenter Server Heartbeat for your environment and wish you luck with your implementation if you go down that road.

Two additional articles I’d recommend you read that cover vCenter Server Heartbeat are below:

Clustering Support on vCloud Director and vCenter Databases

Using vCenter Heartbeat to Protect Non-vCenter SQL DB? Think Again!

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2013 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

Some of you may also remember the article I wrote titled Using vCenter Heartbeat to Protect Non-vCenter SQL DB? Think Again!. vCenter Server Heartbeat is only licensed and supported to provide HA and protect certain components. This article will outline what components are supported with the new vSphere 5.1 release and some important design and deployment considerations.

To ensure you’re aware of what components are supported for protection with vCenter Server Heartbeat I have included them below. This is directly from the vCenter Server Heartbeat Product Documentation. The case remains that if the component isn’t listed below it is not supported and only the MS SQL Server databases relevant to the components below (if any) are supported for protection by vCenter Server Heartbeat.

Supported Components

vCenter Server Versions 5.1

■ VMware vCenter Inventory Service

■ VMware ADAM

■ VMware USB Arbitration Service

■ VMware vCenter Server

■ VMware vSphere Client

■ VMware vSphere Web Client

■ VMware vCenter Update Manager

■ VMware vSphere Update Manager Download Service

■ VMware vCenter Orchestrator Configuration

■ VMware vCenter Orchestrator Server

■ VMware vSphere ESXi Dump Collector

■ VMware Syslog Collector

■ VMware vSphere Auto Deploy

■ VMware vSphere Authentication Proxy

■ VMware vCenter Host Agent Pre-Upgrade Checker

■ VMware vCenter Single Sign On

■ VMware vSphere Profile-Driven Storage Service

■ RSA SSPI Service

■ View Composer 1.1, 2.0, 2.7, and 3.0

Note Remote deployment of View Composer is supported starting with View Composer 3.0

■ VMware View Composer

■ VMware Universal File Access

■ vCenter Converter Enterprise

When considering vCenter Server Heartbeat for your environment I would recommend you get VMware involved in the design and deployment, or at least someone (Partner / Consultant) that is experienced with it’s implementation (blatant plug: like my company). It provides great features and excellent availability but does introduce additional complexity. VMware or your preferred partner can help you navigate the complexity and ensure a robust handover to operations to ensure you get what you expect.

Key Design Considerations

vCenter Server Heartbeat can be configured to protect the supported components either when they are on the same system as vCenter Server (one exception below to note) or if they are on separate systems. In the case of separate systems you will configure each system as a Heartbeat Protected pair. It is important to note that this is still considered a single vCenter Server Heartbeat License. vCenter Server Heartbeat can also be configured to protect the MS SQL Server database system that hosts all of the database schemas for the supported components. But it must not be used to host any other database schemas for components that are not explicitly supported. Doing so would be a serious breach of your license agreement.

You should strongly consider changing the SSL Certificates that vCenter Server Heartbeat uses for secure communications to ensure that you are not vulnerable to a Man in the Middle (MiTM) attack and also to stop those annoying warning messages that you get when you log into the classic vSphere client. You can refer to my article titled Changing vCenter Heartbeat to CA SSL Certificates for the process.

If you are running a multi-site SSO deployment or HA SSO deployment you should consider if you need to also use vCenter Server Heartbeat at all. I would recommend you review the following Documentation and KB’s before considering your options with SSO. Overall given the complexity of SSO using vCenter Server Heartbeat may well be a far simpler solution to meeting the goal of a highly available SSO infrastructure for your vSphere environments.

KB2034074 – Installing vCenter Single Sign On in a Multi-Site Deployment

KB2034918 – vCenter Single Sign On FAQ

Install and Configure vCenter Single Sign On for a High Availability Deployment

You may choose to protect SSO with vCenter Server Heartbeat for local site availability at each of the sites in your multi-site deployment. This would avoid having to separately configure the load balancing and may avoid modifying the Lookup Service URL as described in the documentation. This is because the principal public IP / host name of the Heartbeat Pair in a Local LAN configuration won’t change when it fails over to the secondary node.

In a multi-site scenario or when you are protecting SSO for local site HA you should separate SSO off from the vCenter Server system and run it on a separate server. The main reason for this is that you will likely have multiple vCenters using the same SSO and it makes sense not to have it tied to any particular vCenter Server system. The second reason is that failover between primary and secondary nodes of a vCenter Server system protected by vCenter Servar Heartbeat will fail if you are running SSO on the same system as vCenter. This second situation will be addressed in a vCenter 5.1 Update 1 and vCenter Server Heartbeat 6.5 Update 1.

Final Word

Using vCenter Server Heartbeat can greatly simplify the High Availability configuration and protection of the vCenter Single Sign On systems when considering a multi-site deployment or a local site High Availability Deployment. When you are licensed for vCenter Server Heartbeat the same license can be used to protect all the key components that make up a vCenter Server System, including the MS SQL Server databases of those key components. If you management infrastructure is important to you, and having access to all these core management components is important to you I would strongly recommend you consider making vCenter Server Heartbeat part of your solution architecture. I have implemented it now for many clients in either private or public cloud and also normal vSphere environments and it has saved them countless hours of restoration activity and saved them from a lot of downtime including planned maintenance. When Virtualizing Business Critical Applications it would be very unwise not to have vCenter Server Heartbeat as part of the strategy for protecting the core vCenter management systems considering it is only a rounding error for the licenses in the greater scheme of things.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

It was good to read recently on Duncan Epping’s blog Yellow Bricks that database clustering support for vCloud Director is added in version 5.1. vCloud Director now supports both Oracle RAC and also Microsoft Cluster Services or Microsoft Failover Clustering for MS SQL Server for it’s database. This was previously not supported in vCloud Director 1.0 and 1.5. But what is the support situation for all of the other components when it comes to database clustering, including vCenter Server?

The announcement regarding clustering support for vCloud Director 5.1 databases can be found in kb 2037802. It is really great that VMware has made it clear what the support situation is with no ambiguity.

Here is my understanding of the current state of play with regard to clustered database support (RAC and MSCS/MSFC) based on publicly available information (or lack thereof), this is for the main components of the VMware Cloud Suite that would generally be deployed in most environments:

Single Sign-On (SSO) – Not Supported, vCenter Server Heartbeat is the supported and recommended solution for database high availability

vCenter Server – Not Supported, vCenter Server Heartbeat is the supported and recommended solution for database high availability.

vCenter Server Virtual Appliance – Not Supported, No Database HA currently Supported

vCenter Update Manager – Not Supported, vCenter Server Heartbeat is the supported and recommended solution for database high availability

vCloud Director – Supported from version 5.1 both Oracle RAC and MSCS/MSFC

vCenter Chargeback – Oracle RAC Only from v1.6.2 (refer release notes)

vCenter Orchestrator – Oracle RAC 11g (refer kb 1022828), or vCenter Server Heartbeat

So what do I mean when I say Not Supported? I mean there is no explicit support statement from VMware that they have tested and verified the configuration with clustered databases at the time of writing this article. VMware will provide best efforts support and still help customers troubleshoot their environments. But like most vendors if they suspect a problem caused by the clustered database or clustering technology will refer the customer back to the vendor of that technology. I know many customers that are running vCenter with Oracle RAC databases at the back end successfully and have never had any problems, provided they set it up correctly and tested it, including failover scenarios (should be active/passive configuration). Likewise with a clustered MS SQL database customers have run that successfully as well with vCenter. In many cases the clustering of the database is completely transparent to the application. But that is not always the case depending on how the components connect to and communicate with their database.

When it comes to components that don’t use traditional ODBC connectivity to the database, such as SSO and the vCenter Virtual Appliance, support for clustered MS SQL databases is a bit more difficult. This seem to be primarily why in my opinion SSO is not currently supported with a MS SQL clustered database. For vCenter Server Virtual Appliance it doesn’t support MS SQL at all, but does support Oracle. Oracle RAC Support for the vCenter Server Virtual Appliance is currently going through validation from what I’ve heard and will in the future be supported.

Remember when it comes to support and VMware if something is not included in public documentation, including the product documentation and KB articles, and is not in the product interoperability matrix, then it is not supported. If the support statement isn’t explicit then you can assume that VMware will do everything they can to help (based on my experience and reading relevant kb’s), but it’s on a best efforts basis only.

I’ve mentioned vCenter Server Heartbeat a couple of times above. Some of you may also remember the article I wrote titled Using vCenter Heartbeat to Protect Non-vCenter SQL DB? Think Again!. To ensure you’re aware of what components are supported for protection with vCenter Server Heartbeat I have included them below. This is directly from the vCenter Server Heartbeat Product Documentation. The case remains that if the component isn’t listed below it is not supported and only the databases relevant to the components below (if any) are supported for protection by vCenter Server Heartbeat.

vCenter Server Versions 5.1

■ VMware vCenter Inventory Service

■ VMware ADAM

■ VMware USB Arbitration Service

■ VMware vCenter Server

■ VMware vSphere Client

■ VMware vSphere Web Client

■ VMware vCenter Update Manager

■ VMware vSphere Update Manager Download Service

■ VMware vCenter Orchestrator Configuration

■ VMware vCenter Orchestrator Server

■ VMware vSphere ESXi Dump Collector

■ VMware Syslog Collector

■ VMware vSphere Auto Deploy

■ VMware vSphere Authentication Proxy

■ VMware vCenter Host Agent Pre-Upgrade Checker

■ VMware vCenter Single Sign On

■ VMware vSphere Profile-Driven Storage Service

■ RSA SSPI Service

■ View Composer 1.1, 2.0, 2.7, and 3.0

Note Remote deployment of View Composer is supported starting with View Composer 3.0

■ VMware View Composer

■ VMware Universal File Access

■ vCenter Converter Enterprise

When considering vCenter Server Heartbeat for your environment I would recommend you get VMware involved in the design and deployment, or at least someone (Partner / Consultant) that is experienced with it’s implementation (blatant plug: like my company). It provides great features and excellent availability but does introduce additional complexity. VMware or your preferred partner can help you navigate the complexity and ensure a robust handover to operations to ensure you get what you expect.

Final Word

Depending on the component there are different solutions to provide database high availability. There is no standard across the board between the different VMware components that make up the new vSphere 5.1 Cloud Suite. I expect as the suite develops we will start to see a lot more standardisation in this respect and to see more availability options. Careful consideration needs to be given to providing high availability when deploying the suite within current constraints. As and when the availability options change I will update this post.

Given that this has been based on the easily accessible and publicly available information it’s possible I’ve got something wrong. If so I’d be happy to correct it, so please let me know.

Note: Anyone who is wondering what MSFC is it’s the new term Microsoft use to name their clustering technology. In the past (Windows 2003 and previous) it was called Microsoft Cluster Services, and now it’s called Microsoft Failover Clustering. Many people use the term MSCS to describe both, but MSFC is vastly improved over the previous MSCS.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

I’ve been doing a lot of work with vCenter Heartbeat recently, which is a product I really like and my customers appreciate and see a lot of value from. I was very fortunate to get an opportunity to speak to the product manager about the product in quite a lot of depth. While I can’t tell you anything that is covered by NDA, I can tell you some interesting and important information that has come out of these conversations. This is extremely relevant to vCloud Directory environments where SQL is being used as the database, and also Enterprise environments using vCenter Heartbeat that have other VMware Management Tools such as Site Recovery Manager.

VMware Best Practices and common sense both suggest it’s a good idea to build in availability for the databases that are the Achilles Heel of your virtual infrastructure, such as the databases for vCenter, vCloud Director, Site Recovery Manager, vCenter Configuration Manager, vCenter Chargeback etc. However in some cases for some of these products traditional DB high availability solutions such as SQL Mirroring or Failover Clustering are not supported by VMware.  So you might choose to just protect the database server with VMware HA, and that might be fine in most cases, even though the operating system instance then becomes a single point of failure and has to go down when some OS patches are applied. If your database can get by with only 1 vCPU you could also consider VMware FT.

One option that some customers may think might be viable is using vCenter Heartbeat to not only protect the vCenter Database, but also the database of the other VMware Management Tools and components (like vCloud Director, Chargeback or Site Recovery Manager). This would eliminate costly complex solutions and the outages that can sometimes be associated with them. This also has the advantage of minimizing SQL licenses, and also using a common protection mechanism for the vCenter System and also it’s database and the related database of the other management tools. I know of a number of customers that have done just this and used vCenter Heartbeat to protect their vCenter, vCloud, Chargeback, and other VMware Product DB’s. You might think this sounds like a good idea, but you would be wrong!

So I am clear: This is not a supported configuration and this is explicitly against the VMware vCenter Server Heartbeat EULA. vCenter Heartbeat can only be used to protect the remote SQL Databases of vCenter, Update Manager, and View Composer and only if running on the same shared database instance and server.

So can you still run a single shared Database server for all the VMware SQL DB’s? Yes you can, but you must have two or more SQL instances installed on the shared SQL server. One instance for the Heartbeat Supported DB’s that can be protected by vCenter Heartbeat, and another SQL instance (or more) for the DB’s of the products that can’t be protected by vCenter Heartbeat. This might not be an optimal or feasible design choice, but it is supported. The only other alternative is completely separate DB servers for the vCenter Server Heartbeat supported SQL Database schemas (vCenter, Update Manager, View Composer), and one or more for everything else.

All of the supported plug-ins and components that can be protected are listed in the vCenter Heartbeat Installation Guide. You will not see the DB’s for Site Recovery Manager, Chargeback, vCloud Director, Configuration Manager or VMware Service Manager listed as supported, because they are not. You will also not see the View Events Database listed as supported either.

Perhaps the product marketing blurb on the VMware web site could be made more clear, I have quoted below and was current as at 30/03/2012 (03/30/2012):

“Ensure Availability and Disaster Recovery

VMware vCenter Server Heartbeat delivers high availability and disaster recovery for VMware vCenter Server and all of its components across the LAN or WAN, including the database and plug-ins like VMware vSphere Update Manager, eliminating costly, complex outages. VMware vCenter Server Heartbeat protects and recovers the VMware vCenter Server database instance, even if it’s installed on a separate server.”

It’s the “plug-ins like VMware vSphere Update Manager” statement that could be a little bit misleading. Just be aware this doesn’t mean you can use it for protecting the database of things like vCloud Director.

Another important thing to note about vCenter Heartbeat is that it only supports protecting SQL 2008 R2, not SQL 2008 R2 SP1, although it does support Windows 2008 R2 SP1. Some of the VMware Management tools also don’t yet support SQL 2008 R2 SP1. You should always check the Product Interoperability Matrix when designing solutions. Not every solution is listed and there have been times where it is not up to date (such as currently there are no supported DB’s listed for Chargeback 2.0.1), but this is fairly rare. If you think something doesn’t look right on there contact VMware and they are normally able to quickly resolve the problems.

SQL 2008 R2 (no SP) is the lowest common denominator currently supported by most of the VMware product range that supports SQL. Unless you want to get into a complex situation of supporting multiple variants of Database for different VMware products I would recommend you you stick with this for now.

Now on the topic of protecting the Database of vCloud Director specifically, which is an important database if you are a public cloud provider, what HA options are available? Well if you’re using MS SQL Server as your Database then the only currently supported option is VMware HA or FT to protect the DB VM. With the FT option your DB needs to be configured with only a single vCPU, which will likely only be viable in very small environments. MSCS Failover Clustering and SQL DB Mirroring are not supported in the current 1.5.1 release of vCloud Director. If you’re running Oracle then you have the option of an active/passive configuration of RAC where the service is only active on one node at a time, or VMware HA if you choose. This situation will likely be addressed in upcoming releases.

If you need to know if a particular form of DB high availability is supported you should check the product documentation or log a Service Request with VMware Support, if you can’t find it explicitly supported. Without an explicit statement of support in the product documentation it is likely unsupported.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.