I wrote this blog article for Rackspace to go on their Blog. Original can be found HERE on the Rackspace Blog site.
VMware® vCenter™ Site Recovery Manager™ is used to orchestrate the failover of a group of virtual machines (VMs) from one location to another. It’s a really useful tool to have in your arsenal to tackle the daunting task of disaster recovery (DR), especially if you take a little time to plan for how and when it will be used.
Have you ran into one of these errors before:
|
1 2 3 4 5 6 7 8 9 |
[exec] AxisFault [exec] faultCode: ServerFaultCode [exec] faultSubcode: [exec] faultString: fault.drextapi.fault.ConnectionLimitReached.summary [exec] faultActor: [exec] faultNode: [exec] faultDetail: [exec] {urn:srm0}SrmFaultConnectionLimitReachedFault:<connectionLimit>10</connectionLimit> [exec] fault.drextapi.fault.ConnectionLimitReached.summary |
Or
|
1 2 3 4 5 6 7 8 9 10 11 12 |
[exec] AxisFault [exec] faultCode: ServerFaultCode [exec] faultSubcode: [exec] faultString: dr.fault.SessionLimitExceeded [exec] faultActor: [exec] faultNode: [exec] faultDetail: [exec] {urn:srm0}MethodFaultFault:<vim25:reason>Invalid fault</vim25:reason> [exec] dr.fault.SessionLimitExceeded [exec] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [exec] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [exec] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) |
Or in the GUI:Lost connection to remote SRM server. Unable to login. The maximum number of SRM users has been reached.RJ, from RJApproves.com, & I had been plagued by these messages for weeks, maybe even months. Well, we finally got it all figured out!
On May 25th, I published this post covering some scenarios on how to use Site Recovery Manager & Active Directory. Michael White from VMware responded with some good info. He had an awesome suggestion of using a script to cold clone a DC daily to use for testing.
Let’s take a look at some ways we can get this done:
I’ve been reading a lot around VMware’s Site Recovery Manager and considerations surrounding Active Directory. Most of what you will read says ‘NEVER’ protect AD with SRM, only use native AD replication, especially since SRM & vCenter at your Recovery Site require AD to be running anyway.
But what if you have multiple domains for different uses? This is where the lines become blurred. Think about this for a second:
Now here is where I say ‘why wouldn’t you protect AD with SRM?’ In a true disaster, the protected site is gone, no AD exists anywhere, so using SRM to bring them up on the recovery site makes sense. Is my logic flawed?
However, if I had my application AD living at both sites, using native replication, I agree 100% in not including your Domain Controllers in your SRM Recovery Plan. This leads to my concern…
To me, the only way to really test your DR plan (in this instance, your SRM Recovery Plan) is to not have anything different between them.
I noticed today that one of my two SRM servers wasn’t online in vCenter. I did some quick checking and found the service itself wasn’t running, and the last log entry was from seven days ago (the SRM log is located here “C:\ProgramData\VMware\VMware vCenter Site Recovery Manager\Logs”).
It has some info about it being shutdown, and it turns out that was our production patch cycle that rebooted the server. I checked ODBC, all was well, could manually connect to the database just fine. I also checked on the other SRM server, but it was 100%. I restarted both servers and nothing changed: one worked, the other didn’t.
I’m guessing since the service wouldn’t start, it wouldn’t update the log (which is why last write time was June 7th). The windows application log was unhelpful, and the system log only had the typical message
|
1 2 |
The VMware vCenter Site Recovery Manager Server service failed to start due to the following error: The service did not respond to the start or control request in a timely fashion |
On a whim, I decided to delete the System ODBC connection and recreate it. After that, SRM started fine.
I’m still on version 5.0, no Update 1 yet. If I encounter this problem again, I’ll upgrade to Update 1 and see if it comes back.
Just thought I’d share.