Multiple Virtual Center Servers?

[JasonVmware]

Hello,

I was just wondering what the best practice is for if you have multiple virutal center servers. I currently have 1 Virutal Center Server managing all my ESX servers in my network however I would like to setup a 2nd one in another office for disaster recovery purposes or incase I loose connection with the other office for a long period of time. Now I know you can't have a ESX server assigned to 2 different VC servers so what would be the best practice in this case. Would you just assign all the ESX servers in the other office to its local VC server and all the other ESX servers in the home office would get assigned to its local VC server.

Also if the VC server in either office where to fail for a long period of time would it be a big job to assign the other ESX servers to the remaining VC server ?

[madda]

The best way of doing this is hosting the VC as a VM on the hosts, and then having HA between them. HA only requries VC when it is being setup, once HA is setup it is managed just by the hosts. So if the host with the VC VM on goes down, HA will kick in and bring it up on the other host in the cluster.

As a host can only belong to 1 VC, this is the easiest way of configuring a VC for us in DR

[JonRoderick]

If you're running your VC virtually, how about mirroring the SQL DB to another site to protect against database loss and restore the DB from backup to protect against database corruption.

As for loss of the VC server - as Madda says, you can run happily without VC for a time, though infrastructure management will be a pain.

Our DR plan involves building a new VC server, attaching it to the existing database and reconnecting the hosts in the clusters when everything's up and running.

We're not doing anything with SSL certs so no complications there.

Jon

[meistermn]

1.) The SQL DB of the VC should be clustered (MS Cluster or better on a Geo Veritas Cluster).

2.) VC and VC DB should be separated. (physical or virtual).

3.) If VC running in a VM then an option is to make a clone of the VC VM. Ifthe orginal VM VC crashes use the clone So VC DB should be separated.

4.) If your headquarter has many ESX Host over 50 then VC should be physical

5.) If the VC is in a branch office , then wan latency can a problem.

6.) For manage several VC's have a look at VC Admin Portal Technology Preview

http://communities.vmware.com/community/beta/vcadminportal

7.) Separate VMware Update Manager from VC . I run it in a separate VM. Is Vmware Update Manager Cluster award? I would say no.

8.) Nice artical about VM in VC

9.) I run Netapp Metrocluster over the primary and secondary Site(DR). So LUN's are mirrored. There are although other ways to do it.

[kjb007]

I use separate VC's in my main site and my DR site. Both environments have ESX servers up and running, and in a disaster scenario, your connection will not exist, so you wouldn't be able to manage your servers remotely. This is also a more preferrable, as SRM will need it setup in this manner, as it will integrate with the vCenter's.

I also run my VC as a vm, so it will fail if my entire environment fails, as the redundancy is already built-in for me. That being said, I also replicate my datastore LUNs, so in a worst case scenario, I have my vc replicated as well, in case I need to get anything out of it. Since I am managing my hosts in my remote site with a different VC, with a different set of hosts, it's a moot point, but as I said, I am replicating my LUNs, so vCenter gets a free ride.

-KjB

[JasonVmware]

So if my latency if poor between the main site and the branch office is it possible to setup a 2nd VC at the branch office and just assign those ESX servers to that local VC and controll that branch office with that VC server and controll the rest of the network with the VC at the main site ?

Also when you virutlize your VC that vm should be put into your Vm Network portgroup right? or should it be in a Vm Network portgroup on the same virtual switch as your service console ?

[kjb007]

The answer to your first question is yes. Latency is not a good thing for management as it makes for a very poor experience when trying to manage things. Also, if you have DRS and such enabled, sending data back and forth across slow links will not leave be pleasant. Leave the local ESX hosts with a local VC, unless your connection is a good one.

When you virtualize VC, it will be the same vm as any other. Depending on what network you chose to put it on, you will have to put it into the respective portgroup. If you keep your vm management network separate from your vm's, and vc is on your management network. Then, you will have to create a new portgroup on the vSwitch you have your service console on. Since you can't plug in your vc vm into your service console portgroup, you'll need a new vm portgroup for the management network.

-KjB

[JasonVmware]

Yeah I have a VM Network port group on the same vSwitch as my service console for the VC as it is currently virutlized however I was wondering if it may be better to move it onto the other VM Network portgroup on the other vSwitch to leave the management and Vmotion stuff completely seperate. Would this be advised or is it better to create a new VM port group on the same vswitch as my Vmkernal / Service console just for my VC vm

[meistermn]

Jason did you look at the following document?

http://vsolutionplaybook.com/Virtual-Desktops-Clients/tools-files/WKO_Remote_Office_cheatsheet_q108....

Look at page 2-4

[kjb007]

I keep my "management" traffic all together. I consider the vc traffic similar to my service console and vmotion traffic, so my vc, esx, and vmotion are all on the same network. I keep that network isolated from all others. So, I don't mix that vSwitch with any other either. So, I try to keep enough of an "air gap" between management and vm traffic. Those stay on one vSwitch, and my vm traffic goes on other vSwitch's.

-KjB

[mike_laspina]

Hi,

I think in your case the answer is to keep it simple. In other words no clusters volume replication etc.

Virtualize the VC if it's not already and create a hot clone of it to the remote location using a scheduled script task once a week and its there if you need it.

If it was used in a more critical way e.g. VDI etc then you would have to create a high level of service, but it is just a management tool and therefore it can go out of sink without impacting it's function.

Regards,

Mike

[madda · Accepted solution]

I agree with Mike that is the best solution for your situation, there is no need to over complicate issues. For a small step further, maybe cluster the database so that the database is always in sync then you just need to reattach the DR clone to the database if the main site goes down.