VMware Cloud Community
vmproteau
Enthusiast
Enthusiast
‎02-07-2013 06:54 AM

Basic vs Multi-Site SSO

I am still finding these models confusing. Specifically when it comes to the benefits of multi-site configuration. I'm hoping someone can clarify. Here's a 2-site example:

  • I have a Dallas site with a local SSO installed on it's own server separate from vCenter

  • I have a California site with a local SSO installed on it's own server separate from vCenter

In the first scenario, I configure both sites with Basic SSO:

  1. To manage both sites Administrators will need to login to with 2 separate web client sessions correct?

  2. If so, how would remote performance compare to say managing a 4.1 remotely in linked mode as we do now?
  3. If the Dallas SSO goes down, no one can manage Dallas until it is back up correct?

In the second scenario, I configure Multi-Site with Dallas as Primary SSO:

  1. In this scenerio, a local SSO replica is maintained at remote sites only for faster "local" access

  2. I don't see any advantage for remote management from the above Basic configuration. Just added overhead?

  3. In Multi-Site, if the Dallas SSO goes down Dallas is still inaccessible until it is back up correct? (unless you temporarily add that vCenter to another SSO)

The only reason I see to do multi-site is if you are planning to use Linked-Mode and ONLY because it seems to be a prerequisite requirement. The current manual import/export multi-site SSO requirements and other overhead will cause my team to now rethink the benefits Linked Mode. Unless I'm misunderstanding, the SSO topology implementations are very sketchy and I may opt for Basic Mode at all sites until this is more fully cooked?

0 Kudos
5 Replies
a_nut_in
Expert
Expert
‎02-13-2013 05:20 AM

Interesting question, this

In the first scenario, I configure both sites with Basic SSO:

  1. To manage both sites Administrators will need to login to with 2 separate web client sessions correct?
  2. If so, how would remote performance compare to say managing a 4.1 remotely in linked mode as we do now?
  3. If the Dallas SSO goes down, no one can manage Dallas until it is back up correct?

    4. 1. Correct

    2. I don't find a comparision chart or an actual performance statistics on this but I also have not come across an issue related with degraded console performance. The closest I could find was the below link, but then again, it does not actually give a counter to state whether console access in vSphere client or Web Client was faster

    http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-vSphere-51-Performance-Technical-Whitepap...

    3. Correct

    In the second scenario, I configure Multi-Site with Dallas as Primary SSO:

    1. In this scenerio, a local SSO replica is maintained at remote sites only for faster "local" access
    2. I don't see any advantage for remote management from the above Basic configuration. Just added overhead?
    3. In Multi-Site, if the Dallas SSO goes down Dallas is still inaccessible until it is back up correct? (unless you temporarily add that vCenter to another SSO)

      4. The only reason I see to do multi-site is if you are planning to use Linked-Mode and ONLY because it seems to be a prerequisite requirement. The current manual import/export multi-site SSO requirements and other overhead will cause my team to now rethink the benefits Linked Mode. Unless I'm misunderstanding, the SSO topology implementations are very sketchy and I may opt for Basic Mode at all sites until this is more fully cooked?

      I do think there are multiple ways in which the second scenerio can play up.

      1. Multisite - the "local" access bit above

      2. Multisite HA - answers point 3

      3. As to point 2, the above two answers might help clear the confusion 🙂

      http://pubs.vmware.com/vsphere-51/topic/com.vmware.vsphere.install.doc/GUID-C6F362AF-397C-4271-A9A1-...

      So essentially I think what the confusion above is that there are actually three modes as opposed to two you have mentioned.

      Let me know if this has helped

      a

Do remember to mark my post as "helpful" or "correct" if I've helped resolve or answer your query!
vmproteau
Enthusiast
Enthusiast
‎02-13-2013 06:59 AM

Thanks for taking the time to respond. As for HA, I am aware of that mode but, left it out initilally because the implementation I'm looking at is on a very tight timeline and putting SSO behind Load Balancers at 2 locations may add complications and delay I wasn't sure we could afford. I was opting for a simpler initial configuration that could later be modified to HA. If deadlines get pushed we may reconsider.

Putting HA aside for this discussion, I then wanted to determine Mutli-Site (non HA) SSO Disaster Recovery scenerios to set expectations on recovery time estimates. My understanding is if I lose an SSO in either site I could:

  1. Rebuild that site's SSO: In this case, I could temporarily repoint and reregister the VSphere 5.1 infrastructure to the remaining remote SSO. After local SSO is rebuilt, repeat the repoint and reregister to the new local SSO. I read the instructions for doing this and as many things SSO looks very manual and convuluted. Anyone have any experience with this repointing?
  2. VMware Fault Tolerance: What about this option for the SSO server in each site. At first glance this seems like a possible alternative to full fledged SSO HA. Is FT valid and supported for SSO?
  3. Full VMware Clones: I considered clones of each sits's SSO server after initial configuration. Shoud I ever lose an SSO, I thought I might be able to just power one back on an be back in business however, this KB see to suggest not. SSO appears to be very sensative to even small changes. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=203617...
  4. Restore from backup: It seems odd but, I take from the KB that even a standard system state restore or image based restore would not necessarily be a valid DR option?

Much of the SSO manual processes, documentation and reported issues seem to show a relatively immature 1.0 product. My thought was to implement this in a way to allow for the easiest transition to the inevitable 2.0 rip and replace upgrade.

0 Kudos
a_nut_in
Expert
Expert
‎02-13-2013 09:58 AM

  1. Rebuild that site's SSO: In this case, I could temporarily repoint and reregister the VSphere 5.1 infrastructure to the remaining remote SSO. After local SSO is rebuilt, repeat the repoint and reregister to the new local SSO. I read the instructions for doing this and as many things SSO looks very manual and convuluted. Anyone have any experience with this repointing?
  2. VMware Fault Tolerance: What about this option for the SSO server in each site. At first glance this seems like a possible alternative to full fledged SSO HA. Is FT valid and supported for SSO?
  3. Full VMware Clones: I considered clones of each sits's SSO server after initial configuration. Shoud I ever lose an SSO, I thought I might be able to just power one back on an be back in business however, this KB see to suggest not. SSO appears to be very sensative to even small changes. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=203617...
  4. Restore from backup: It seems odd but, I take from the KB that even a standard system state restore or image based restore would not necessarily be a valid DR option?

Much of the SSO manual processes, documentation and reported issues seem to show a relatively immature 1.0 product. My thought was to implement this in a way to allow for the easiest transition to the inevitable 2.0 rip and replace upgrade.

1. Repointing usually works fine, but yes, is not an intuitive process

http://kb.vmware.com/kb/2033620

2. FT cannot be used with VC - as I believe a seperate product called Virtual Center Heartbeat is what is supported

http://www.vmware.com/products/vcenter-server-heartbeat/

http://communities.vmware.com/message/1417252

3. Correct. Cloning the SSO machine usually breaks it

4. A restore from backup might fail as well.

The safest option would thus actually be a multisite HA for SSO going by the looks of it. Not sure if anyone else has any other suggestions that might have worked on their environment?

Thanks

a

Do remember to mark my post as "helpful" or "correct" if I've helped resolve or answer your query!
vmproteau
Enthusiast
Enthusiast
‎02-13-2013 10:17 AM

Thanks again. You have been much more helpful than VMware support on the subject to date.

2. To clarify I have installed SSO on a separate server from vCenter so, FT would be just for SSO. Is that still not supported to your knowledge?

3. With respect to HA, I would still want to identify a DR process for SSO in case I lost both.

Like the majority of vCenter administrators I generally accept vCenter as a single point of failure however, for vCenter, I have a detailed DR plan. If I am also willing to accept an SSO single point of failure, I'd like to understand what options I have for DR so I can set recovery time expectations.

I have been unable to get a direct answer from support. It sounds like the only realistic, reliable DR option is a new SSO and a repoint and re-register. That's fine if that's the answer but, I'd like to confirm. If anyone has gone through this exercise and has additional information I'd appreciate it.

I have also posed to VMware support and will post the reply if I receive one.

0 Kudos
a_nut_in
Expert
Expert
‎02-13-2013 11:55 AM

2. To clarify I have installed SSO on a separate server from vCenter so, FT would be just for SSO. Is that still not supported to your knowledge?

3. With respect to HA, I would still want to identify a DR process for SSO in case I lost both.


FT would not work and would be an unsupported configuration. But then, the below link is one way to backup and restore an SSO server and does not involve building a server from scratch and re-registering all components

http://kb.vmware.com/kb/2034928

Let me know if this helps

Regards

a

Do remember to mark my post as "helpful" or "correct" if I've helped resolve or answer your query!
0 Kudos