• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

vCenter High Availability

K

KapsZ28

2[H]4U
Joined
May 29, 2009
Messages
2,114
This is basically identical to what I am trying to build out. http://www.hypervizor.com/diags/vCloud-Director-MGMT-Pod-Public-Cloud-v-1.pdf I am trying to figure out the best and easiest way to setup the multiple vCenter servers and MS SQL clustering. As you can see in the diagram, there will a Resource vCenter and Management vCenter on one ESXi host which needs to be Highly Available with two vCenters on another ESXi host.

For one, I am trying to use Microsoft SQL 2008 R2 Standard instead of Enterprise because management wants to keep costs down. If that is not possible, let me know. From what I read, Standard only supports two node clustering. My current setup is using one SQL DB server for each ESXi host. Not sure if you are supposed to install multiple vCenters on the same DB server or not. It already looks like I need multiple SQL instances as SSO automatically tries to use RSA_USER during the install. And it looks like having multiple instances of SQL makes the clustering even more complicated.

I don’t suppose you can use FT for a vCenter server?

Based on the diagram, what is the easiest way I can setup four vCenter servers with HA? Or I should say, what is the “correct” way to do it?
 
Using a SQL cluster isn't fully supported by VMware. They'll still provide best effort support, however.

http://kb.vmware.com/selfservice/mi...nguage=en_US&cmd=displayKC&externalId=1024051

Obviously they would prefer you use vCenter Heartbeat.

You can use FT for vCenter but you'd again be unsupported since FT supports only 1 vCPU and vCenter's minimum requirement is 2 vCPUs.

Why SQL 2008 R2? SQL 2012 has improved failover clustering but with Standard you'd still be limited to two cluster nodes. vSphere supports SQL 2012 as of 5.1 Update 1. vCloud Director supports it as well but now that I research it, looks like Chargeback doesn't yet. :p
 
Just started watching the heartbeat video. So, with heartbeat, you can protect both a vCenter server and the SQL server? Does heartbeat replicate the data or something? Haven't finished watching. Just saw that you clone your server and install heartbeat. Sounds like that will be a lot easier than SQL clustering. Any drawback to using heartbeat?
 
What are you trying to accomplish?

SQL is separate from vCenter and has nothing to do with the vCenter heartbeat. IMO you want to design your SQL HA first, then design your vCenter HA.
 
renixinq said:
What are you trying to accomplish?

SQL is separate from vCenter and has nothing to do with the vCenter heartbeat. IMO you want to design your SQL HA first, then design your vCenter HA.
Click to expand...

That is what I am trying to down, "now". After I already configured vCenter. :D Basically going back and starting with SQL because none of this was planned first since management was in such a rush to deploy it.

Based on what I read about Heartbeat, it does support SQL. http://blogs.vmware.com/vsphere/201...-vcenter-server-databases-when-using-sql.html

If I am using Heartbeat, wouldn't I just clone SQL and setup a Heartbeat between them? Same goes for the vCenter servers.
 
Would it be better to use one SQL server with two SQL instances, (one for each vCenter,) or two separate SQL servers?
 
So, before I setup the second vCenter, just wondering if it is OK if I use the same SQL server for two separate vCenters with two SQL instances, or should I setup two separate SQL servers?
 
Actually, will Hearbeat protect all the databases on our SQL server? Besides the vCenter DB, there is the SSO DB, and a DB for our vCloud server. If Heartbeat isn't going to protect the vCloud DB, then we definitely can't use it.
 
Again, heartbeat has nothing to do with SQL. The only thing it acts upon is the service and will not protect your data.

IMO it would be better to have different SQL servers unless you have a DBA on hand that has the skills to support a multi-instance SQL install.
 
renixinq said:
Again, heartbeat has nothing to do with SQL. The only thing it acts upon is the service and will not protect your data.

IMO it would be better to have different SQL servers unless you have a DBA on hand that has the skills to support a multi-instance SQL install.
Click to expand...

definitely make sure your dba knows wtf they are doing too in this case. Let's play count the Times a dba has brought down a mssql cluster rebooting a box
 
renixinq said:
Again, heartbeat has nothing to do with SQL. The only thing it acts upon is the service and will not protect your data.

IMO it would be better to have different SQL servers unless you have a DBA on hand that has the skills to support a multi-instance SQL install.
Click to expand...

Can you please explain to me how Heartbeat has nothing to do with SQL when this VMware article specifically says it supports SQL?

http://blogs.vmware.com/vsphere/201...-vcenter-server-databases-when-using-sql.html

Even the VMware video shows you how to protect the SQL server and there are other VMware articles pertaining to Heartbeat and SQL.

So what am I missing here?
 
I don't think you understand what heartbeat is doing.

Heartbeat is at it's lowest form a ping on a service. The service goes down it acts upon it by attempting to restart it. Heartbeat does offer some redundancy by replicating data through the software (vCenter) but it will not provide you redundancy on the SQL instance should there be a reason the service will not start. From the little I know about heartbeat it does not directly interact with the SQL engine or DB. I hope that clarifies it for you.
 
renixinq said:
I don't think you understand what heartbeat is doing.

Heartbeat is at it's lowest form a ping on a service. The service goes down it acts upon it by attempting to restart it. Heartbeat does offer some redundancy by replicating data through the software (vCenter) but it will not provide you redundancy on the SQL instance should there be a reason the service will not start. From the little I know about heartbeat it does not directly interact with the SQL engine or DB. I hope that clarifies it for you.
Click to expand...

I see what you are saying, but I am just as likely to have a SQL Cluster failure as I am any other SQL issue. And since VMware doesn't fully support SQL Clustering, they could easily push me to Microsoft for support if I ran into a problem. At least with Heartbeat I can manually failover to the other SQL server if needed.

But I have to say in my years of working with VMware, I rarely ever see a DB problem especially when running on a dedicate server. Most issues tend to be with the vCenter server.

And since I am practically the sole person to support this, http://www.hypervizor.com/diags/vCloud-Director-MGMT-Pod-Public-Cloud-v-1.pdf, I would like to keep it as simple as possible. I already have to deal with 12 separate databases. I'd rather them just replicated than clustered.
 
My suggestion would be separate SQL VM's for each vCenter VM with heartbeat monitoring it all. I don't know if this is multi-site but setup the proper affinity/anti-affinity rules and you'll have a very high availability with that setup. With that setup I believe the most likely cause for outage would be host failure and with HA and DRS in vSphere that will be mitigated some. I'm a proponent of single purpose SQL installations especially if you're the accidental DBA.
 
I wanted to have a separate DB server for each vCenter, but because of licensing and management being cheap, they didn't want it that way. Whatever we install is paid for monthly. So it would have been an extra Server 2008 R2, SQL, and Heartbeat license.
 
http://kb.vmware.com/selfservice/mi...ype=kc&docTypeID=DT_KB_1_1&externalId=2041620

Heartbeat _DOES_ replicate the data for MS SQL, and it _DOES_ protect the database. This is how you create a highly available vCenter instance, especially for the cloud in a supported manner. I'm doing the same thing as you are right now. As long as your vCenter server and SQL servers are virtual machines it makes the process much easier. You can failover between the nodes and this provides availability even during patching, etc. You can protect the database whether it is local to the vCenter server or remote, either way.
 
defuseme2k said:
http://kb.vmware.com/selfservice/mi...ype=kc&docTypeID=DT_KB_1_1&externalId=2041620

Heartbeat _DOES_ replicate the data for MS SQL, and it _DOES_ protect the database. This is how you create a highly available vCenter instance, especially for the cloud in a supported manner. I'm doing the same thing as you are right now. As long as your vCenter server and SQL servers are virtual machines it makes the process much easier. You can failover between the nodes and this provides availability even during patching, etc. You can protect the database whether it is local to the vCenter server or remote, either way.
Click to expand...

This is so much easier than dealing with SQL Clustering.
 
So I got Heartbeat all setup on three pairs of servers. Two pairs of vCenter and one pair of SQL servers. Seems to work pretty well. You can even manually add additional services that you want monitored and protected. I used Fault Tolerance for my vShield Manager and I will be building a second vCloud Director server with load balancing. Below is the Heartbeat Manager.

 
FT for vShield Manager is overkill. Nothing wrong with overkill..but there is no problem having vShield Manager reboot w/ HA instead. The only real downside is that you couldn't make changes during that time.

Heartbeat is a great product (licensed NeverFail) that never took off due to cost.
 
NetJunkie said:
FT for vShield Manager is overkill. Nothing wrong with overkill..but there is no problem having vShield Manager reboot w/ HA instead. The only real downside is that you couldn't make changes during that time.

Heartbeat is a great product (licensed NeverFail) that never took off due to cost.
Click to expand...

They might as well roll it into Enterprise Plus to dangle another feature out there for customers.
 
NetJunkie said:
FT for vShield Manager is overkill. Nothing wrong with overkill..but there is no problem having vShield Manager reboot w/ HA instead. The only real downside is that you couldn't make changes during that time.
Click to expand...

Probably true. I think the reason is because this is for vCloud Director which relies on vShield for networking and we are trying to keep vCloud as highly available as possible.
 
Child of Wonder said:
They might as well roll it into Enterprise Plus to dangle another feature out there for customers.
Click to expand...

I was just looking on VMware's website and it says the U.S. suggested list price per instance is $9,995! That would be $30k for us, but luckily we are a Solution Provider and just pay much lower monthly fees for all VMware products.
 
Child of Wonder said:
They might as well roll it into Enterprise Plus to dangle another feature out there for customers.
Click to expand...

They probably would if they could. The problem is that most of the license, I'm sure, goes to NeverFail. So they can't just heavily discount it.
 
vShield Manager (vCloud Networking and Security) requires more than one vCPU now so no FT until they change FT to accommodate more vCPU's.

The edge gateway appliances, however can be deployed with high availability(redundant pair)
 
Last edited:
You must log in or register to reply here.
Back
Top