skoch
Enthusiast
Enthusiast

vRA 7 embedded vRO or external?

Jump to solution

Looking at deploying a distributed HA vRA 7 environment and I haven't been able to determine if the embedded vRO appliances are HA and/or if they are recommended over external vRO appliances.

Does anyone know?

Tags (2)
1 Solution

Accepted Solutions
GrantOrchardVMw
Commander
Commander

External can be active/active or active passive. It's all in how you choose to configure the deployment.

vRO can process 100 concurrent workflows, so I'd be looking at how many concurrent tasks may be triggered as part of provisoning/deprovisioning and use that as a basis. Remember that there is no reason not to start with internal and then switch later if you find that there are performance issues.

Grant

Grant http://grantorchard.com

View solution in original post

0 Kudos
14 Replies
AlexJudge
VMware Employee
VMware Employee

The current recommendation is to go with external vRO instances for distributed installations.

GrantOrchardVMw
Commander
Commander

They are deployed in active/active when you use the wizard to perform deployment.

Full scale testing hasn't been performed on the internal instances yet, as Alex has said if you are running to the limits of vRO then external is recommended.

Running internal is definitely supported and for the most part I'll be trying to direct people that way.

Grant

Grant http://grantorchard.com
skoch
Enthusiast
Enthusiast

Thanks! The deployment is medium size <10,000 VMs with multi-tier PaaS blueprints calling out to Chef for app install and NSX for LB/firewall rules. I definitely think vRO will be busy, but not sure what that will equate to in OPS. I like the idea of embedded vRO as the upgrade path and supportability seem to be easier, but I want to make sure I don't leave the customer needing external appliances to be deployed.

You mentioned that embedded are active/active, are the external appliances also active/active now?

Steve

0 Kudos
GrantOrchardVMw
Commander
Commander

External can be active/active or active passive. It's all in how you choose to configure the deployment.

vRO can process 100 concurrent workflows, so I'd be looking at how many concurrent tasks may be triggered as part of provisoning/deprovisioning and use that as a basis. Remember that there is no reason not to start with internal and then switch later if you find that there are performance issues.

Grant

Grant http://grantorchard.com
0 Kudos
Hazenet
Enthusiast
Enthusiast

So if using the Embedded vRO on a vRA7 Clustered installation (deployed using the wizard), what is the best/correct way to do development on the vRO Server?

Shutdown second vRO node, do development with the vRO Client and startup the second vRO node again?

Or would it be better to deploy a 3rd vRO node, which would of cause be Non-Clustered, do all development there, and then push the developed content via the Multinode Plug-in to the embedded vRO Cluster?

(My understanding is that the vRO Client does not support a vRO Cluster, is that correct?)

0 Kudos
jexplorer
Contributor
Contributor

Hello gentlemen - we are in the same situation as the OP, but decided to go with the embedded vRO. Question is, should we put the ports 8281/8283 behind an external load balancer (F5 in our case), instead of pointing to individual vRA node. From the docuemtation, embedded vRO is internally load balanced but still not ure if we have to use vRA1/vRA2 when connecting to vRO client as well as adding the vRO in portal as orchestration endpoint. There isn't much documentation on this. Your help is greatly appreciated.

Thanks,

0 Kudos
prestonville
Enthusiast
Enthusiast

Our vRA environment fits into the high availability small limits in the 7.x reference architecture document and also has considerably <100 concurrent vRO transactions. Reference doc says you can choose either embedded or external vRO options as discussed here. After reading the install notes for 7.x it says on p58 (extract below) to use external vRO only.

vRealize Orchestrator Use external implementations of vRealize Orchestrator with high-availability deployments. If you use a vRealize Orchestrator server on a vRealize Automation appliance, configure it to be external. Embedded versions should never be used.

Should I take note of that statement in the install notes and not use embedded vRO in a small high availability environment?

I've also been heard that the embedded vRO is active\passive when used by vRA but here you posted its active/active. Which is correct? 

Thanks

Chris

0 Kudos
GrantOrchardVMw
Commander
Commander

It is active/active when it comes to serving connections.

From an availability perspective it gets a little more tricky. vRO itself is Active/Active, but the underlying postgres instance is active/passive. Thus if you lose the wrong vRA node and postres goes down, you lose vRO. In that case you've also lost vRA so I'm not sure that it matters too much.

Grant

Grant http://grantorchard.com
0 Kudos
GrantOrchardVMw
Commander
Commander

8281 won't be needed for embedded, it's served on 443.

For the client, connect directly to a node, not to the LB address.

Grant

Grant http://grantorchard.com
0 Kudos
esloof
Expert
Expert

This has changed in version 7.2

Distributed Deployment Checklist

The vRealize Automation appliance includes an embedded version of vRealize Orchestrator that is now recommended for use with new installations. In older deployments or special cases, however, users might connect vRealize Automation to a separate, external vRealize Orchestrator. See https://www.vmware.com/products/vrealize-orchestrator.html.

For information about connecting vRealize Automation and vRealize Orchestrator, see VMware vRealize Orchestrator Plug-In for vRealize Automation.

0 Kudos
LividBliss
Enthusiast
Enthusiast

Embedded is good for POC deployments and scenarios with limited resources.  Very surprised VMware recommends Embedded now, here is why:

The big negative with Embedded vRO is that it shares the same VM/Postgres DB with vRA.  With Embedded, any vRO maintainence (Plugin Installs, Sync Issues, Updates, Certificate Replacements, etc.) that requires a reboot will require you to reboot vRA with it, because it's the same appliance.  vRA with Embedded vRO takes ~10 minutes to boot up and start all services, whereas External vRO is ~90 seconds.  And you cannot migrate Embedded vRO/vRA Postgres to External vRO Postgres.  Plus, with Embedded, you cannot use a vCenter/SSO Authentication source.

0 Kudos
daphnissov
Immortal
Immortal

Here are my thoughts on the situation having deployed both external and embedded vRO systems for dozens of production vRA deployments.

The big negative with Embedded vRO is that it shares the same VM/Postgres DB with vRA.

This is actually a positive because, by sharing that vPostgres instance, it allows the embedded vRO instances to cluster whereas to create a cluster with external vRO requires MS SQL, and there are all sorts of performance problems associated with that just due to the nature of things.

With Embedded, any vRO maintainence (Plugin Installs, Sync Issues, Updates, Certificate Replacements, etc.) that requires a reboot will require you to reboot vRA with it, because it's the same appliance.

Every one of the examples you listed does not require an appliance reboot. This might have been the procedure you used in the past when executing these actions, but that is not a requirement and it works perfectly fine to simply recycle the service instead. In fact, I've not encountered any situation when using embedded vRO that has necessitated power cycling the entire appliance.

vRA with Embedded vRO takes ~10 minutes to boot up and start all services, whereas External vRO is ~90 seconds.

This is true, because there are massive numbers of additional services with in the vRA appliance, not because it's somehow crippled in comparison.

And you cannot migrate Embedded vRO/vRA Postgres to External vRO Postgres.

You can, but it is not a direct database migration and is therefore somewhat laborious.

Plus, with Embedded, you cannot use a vCenter/SSO Authentication source.

If you're using embedded to begin with (i.e., embedded into ​vRA) then there's no point in using vCenter/SSO auth anyhow.

0 Kudos
LividBliss
Enthusiast
Enthusiast

Good for you, I also have deployed Medium and Large size vCAC/vRA/vRO Clusters dozens of times in the Fortune 1000 for VMware PSO and the biggest Partners, all over the US.

Everyone of those situations requires a reboot, although the whitepapers claim it' simple a service restart.  Most 3rd Party Plugins simply need a reboot, even for version updates.  CA Signed Certs can really mess up a vRO Cluster (Embedded and External) in some 7.x versions (SHA256 bugs) and reboots are required to change them out, try it.  There are Internal KBs, check it out.

Plus this scenario even requires a reboot, replacing the vRA Cafe 7.3 Plugin that left out the Request IDs - your own post.

Removal of fixed vRA café plug-in for vRO 7.3

There are real world use cases for using vCenter/SSO as the Authentication Source in vRO instead of vRA, especially with LB Prod Class PSCs available in Muti-Site scenarios.  And not everyone wants to manage a 2nd "vsphere.local" in their environment.  It also lightened the load and footprint for vRA by not using vRA Appliances as an Authentication Source - they shouldn't have taken this feature out of 7.x (was able to use vCenter SSO in 6.x, didn't even need an Identity Appliance).  Should be able to point to vCenter/PSC for Authentication (like AD for all MS products), its a more mature code, many years ahead of Identity Appliances/Managers in dev hours invested.

Next time an Embedded vRO Cluster is out of sync try using the GUI to restart services and fix it.  Then try resetting "vco-server" and "vco-configurator" in the console.  And there is no sync button anymore, not even appending "?advanced" to the URL brings the button back like it used to.  Reboot.

Just about every client chooses External once they work with the Embedded for awhile for Production class deployments. They hate the reboot times, and having "all the eggs in one basket".

And don't get me started on sharing a Postgres with vRA or migrating to an External.  Can you imagine if other Appliances with different functions, used by other products, shared a DB?  That's like saying a vCenter and vRA should share a Postgres DB, or vROPs and vRA, etc.

And External works better with SovLabs Modules IMO too.

Embedded is a novelty for POC, but not good enough to support 100s or 1000s of users.

Reciting whitepaper answers just doesn't work with clients - I have been brought in too many times to fix broken vRA/vRO deployments from other consultants and help find/report too many bugs with these products.

LividBliss
Enthusiast
Enthusiast

VMware Knowledge Base 54982 and VMware Knowledge Base 54143

I rest my case.  Spotted this with SovLabs four months ago working with a client in the field.  Embedded vRO wasn't ready for Production - the Shared DB Architecture of an External Orchestrator Cluster is not available in an Embedded vRA Cluster; there are asynchronous replication duplicate entries and sometimes missing entries because vRA and Embedded vRO use a Postgres DB in an active/passive by default.