OneView for vCenter Scale

[Poyatier]

Greetings! I haven't seen any documentation on scaled-out-architecture for the use of OV4VC and I'm curious if folks have any information they can share.  I'm specifically looking at a large, multi-vcenter-envrionment.  7 vCenters (2 in one SSO Domain, another 2 in a different SSO Domain, and 3 in yet another SSO domain).  Over 2k hosts in various generations/builds of ProLiant DL360, DL380, BL460, SY480, gen9s gen10s and gen10+s.  Additionally, all these enviornments are managed by roughly 8 OneView instances that are either OneView VM appliances for the DLs & BLs, or OneView Synergy appliances for the Synergy SY blades.

So, I'm looking for scaling questions on the appliances.  Can ONE OV4VC OVA/Appliance handle all of them?  Should there be one for each SSO domain or one for each vCenter? Are there suggestions on how much disk to add for storing all the SPPs (for use with the new vCenter 7.0U3/vLCM setup)?  Should I increase the memory/cpu of the OV4VC Appliance?

Lots or architecture questions that I just don't see in any of the documentation.  To be honest, the documentation on the subject is REALLY light (unless I'm looking in the wrong spots for it).

Thanks in advance,

Matt

[Doug de Werd]

There are a lot of variables when it comes to scaling, so it is hard to give an exact number. For example, Synergy with Virtual Connect is more taxing than a rackmount DL.

And OV4VC can definitely handle multiple OneView/Synergy instances, as well as multiple vCenters.  It's more about the total number of resources than it is for the OneViews or vCenters.

As for VLCM and SPPs - OV4VC does not actually store the SPPs. It relies on the local or remote (recommended) storage that OneView or Synergy uses for SPP storage.  It would probably be best to set up a single SPP repository to be shared by all OneView and Synergy instances.

I'll try to get some more detailed info on how many OV4VC instances you would need.  My suspicion is that you would probably need a couple and want to split them up across your SSO domains.

Doug

[Doug de Werd]

I got some more info from our engineering team, and here are their recommendations:

1. Start with 3 OV4VC instances, one for each 3 SSO domain.
2. Register only the same SSO domain vCenter in each single OV4VC instance.
3. Register only required OneView instance for each OV4VC appliance. If vCenter 1 is having 500 hosts managed by 3 OneView then register only those 3 OneViews in that specific OV4VC instance. This will avoid unnecessary search for the host reference in other OneView.
4. In simple terms we recommend one OV4VC instance per 500 hosts. If any SSO domain is having more than 500 host you can add additional OV4VC instance and split the load. 
5. Don’t increase the Storage and CPU beyond what is recommended in our User Guide. This extra resource may not be utilized fully by the OV4VC appliance.

[Poyatier]

Doug,

You've been a big help so far.  Thanks for taking the time.  Taking the suggestions of at-least one OV4VC instance per SSO domain (we have 3), and then further reducing by qty 500 per instance, the only next-logical way I could think to further split to keep the number of hosts low was the following table (ie, by vCenter/host region).  If feels a bit bloated in the OV4VC count but I know we're growing our host count too so wanted to leave headroom.  Does this look about right based on your feedback from engineering?

[Doug de Werd · Accepted solution]

A few more comments from the engineering team:

This proposed approach is perfect if they want to keep it logically separate.

But there are possibilities for improvement if they are interested.

1. Mgmt and VDI SSO domains can be merged if they have network connectivity between them. These domains have very small numbers of hosts.
2. The first two regions in the SVR domain can also be merged based on number of hosts.

[Poyatier]

Thanks Doug, much appreciated!