Configuring vCenter Orchestrator Appliance for High Availability

I don't get it either
Dunes? Dunes.

UPDATED 09/07/14

This is the third post in my series for building a fully distributed vCloud Automation Center deployment. In this post, we’ll configure vCenter Orchestrator (vCO) for High Availability using two nodes and an vCloud Networking and Security Edge Gateway as a Load Balancer.  I’ll use the vCenter Orchestrator Appliance v5.  I want to ensure that both vCO nodes return the same, organizationally-trusted SSL certificate, so we’ll configure that too.


  • Database Server (ideally , it should be configured for high availability – I’ll be using a Microsoft SQL Server 2012 Failover Cluster)
  • Database for vCO
  • Credentials for database
  • Reserve IP addresses for two nodes and virtual IP
  • DNS records for both nodes and virtual IP (I’m using vcvco1 and vcvco2 for the appliance nodes and vcvco as the virtual)
  • Appropriate Identity Sources added to SSO
  • A vCO administrators security group with appropriate members
  • An Active Directory integrated Certificate Authority


In the steps below, text in red is not meant to be typed verbatim.  You’ll replace the value with something relevant to your environment.

Configure database settings (MSSQL)

To ensure that multiple Orchestrator nodes can use the database without clashing, you’ll need to enable a couple of optional settings.

Thiscan be done through script:ALTER DATABASE [vcvCO] SET ALLOW_SNAPSHOT_ISOLATION ON;

Or through theSSMS GUI:

Enable Miscellaneous options for the vCO database
Enable Miscellaneous options for the vCO database

Deploy and configure the First Orchestrator Appliance

  1. Using the vSphere or vSphere Web Client, deploy the appliance from OVF to an available HA cluster.  I named mine vcvco1.
  2. Adjust the resources if necessary and power on vcvco1.
  3. Browse to https://vcvco1:5480, logon as root
  4. Set the timezone, confirm the network settings and hostname.  I set the hostname to the vcvco, the cluster name. Log out of the VAMI.
  5. Browse to https://vcvco1:8283, logon as vmware
  6. Navigate to the Network section
  7. (Optional) on the Network tab, set the IP address to the actual address.  Leave the port numbers at default
  8. On the SSL Trust Manager tab, type the URL to your SSO server (eg:  https://vcsso.domain.local:7444) and click the Import button.  Verify that the certificate information is correct and click Import to add it to the trust.  Repeat this for your vCenter Server(s).
  9. In the Authentication Section, you can choose LDAP or SSO.  I’m going to configure it for SSO.  Enter your sso hostname (eg: vcsso.domain.local).  Click the Advanced Settings Link to see and verify that the Token service and Admin service URLs are fully populated with the correct port number (7444).  Enter  the user name and password for anSSO administrator (eg: administrator@vsphere.local) in the appropriate boxes.  Click the RegisterOrchestrator button. Wait for it….
    Registered with SSO, but not configured
  10. After the registration is confirmed, select the correct group in the vCO Admin – domain and group dropdown list. Then, click the Accept Orchestrator Configuration button.
  11. In the Database section; again I’m using SQL Server, but you’d select what’s appropriate for your environment.
  12. After the connection is made, click the link to Create the database tables, then Apply Changes.
  13. On the Licenses section, enter the host name of the vCenter Server and credentials, then click Apply Changes.
  14. Install any plugins you need (vCAC, ViPR, Powershell, etc) and restart the service to complete the plugin installation.

Create Package Signing Certificate

  1. On the Server Certificate section, click the “Create a certificate database and self-signed server certificate” link.  Enter vcvco.domain.local – that’s the load-balanced name, not the actual hostname – for the Common Name, set the organization, ou and country, then click Create.
  2. Still in the Server Certificate section, click “Export a certificate signing request”.  Save the vCO_SigningRequest.csr file to your system.
  3. Log into the Microsoft CA certificate authority Web interface. By default, it is http://servername/CertSrv/.
  4. Click the Request a certificate link.Click advanced certificate request.
  5. Click the Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file link.
  6. Open the certificate request (vCO_SigningRequest.csr) in notepad. Copy the content between —–BEGIN CERTIFICATE REQUEST—– and —–END CERTIFICATE REQUEST—–
  7. Paste the copied content into the “Base-64-encoded certificate request” textarea. Select Web Server as the Certificate Template.
  8. Click Submit to submit the request.
  9. Click Base 64 encoded on the Certificate issued screen. Click the Download Certificate Chain link.
  10. Save the package as C:\certs\certnew.p7b.
  11. Double-click thep7b to open it incertmgr.  Navigate to Certificates – Current User\C:\Certs\Certnew.p7b\Certificates.
    Certs in P7b
    Certs in P7b
  12. You’ll see two certificates here (unless you have intermediate certificates, then you’ll have more).
  13.  Right-click the one for the vCO server, choose All Tasks|Export.  Save the file as Base-64 encoded X.509 (.CER) as vco.crt
  14. Right-click the one for root CA server, choose All Tasks|Export.  Save the file as Base-64 encoded X.509 (.CER) to as root.cer .  Close certmgr.
  15. Before vCO will accept the CA-signed certificate, we have to import the root certificate.  Launch the Orchestrator Client.  You can use https://vcvco1.domain.local:8281/vco/client/client.jnlp
  16. Login to thevCO client as a member of thevCO Admins group
    Login to vCO Client
    Login to vCO Client
  17. In the client, launch Certificate Manager from Tools|Certificate Manager.
  18. Under Known Certificates, click the “Import Certificate” button.  Browse to and select root.cer that you saved earlier.  Verify that the certificate details are correct and client the “Import Certificate” button to finish. Close or minimize the vCO Client.
  19. Back on the Server Certificate section of the vCO configuration, click “Import a certificate signing request signed by a certificate authority”.  Select the vco.crt file you saved and click import.  If you get an error here, make sure you’ve imported the correct root (and any intermediate) cert into vCO.

Replace vCO Client certificate

Now, if you navigate to https://vcvco1.domain.local:8281/vco, you’ll see that the certificate is still untrusted.  Let’s fix that.  The certificate and key is stored with a specific alias and password, we’re going to replace them, but reuse the alias and password.

  1. SSH into vcvco1 as root
  2. Navigate to /etc/vco/app-server/security and make a copy of the jssecacerts keystore file

    cd /etc/vco/app-server/security
    cp ./jssecacerts ./jssecacerts.backup

  3. Use keytool to delete the item with the “dunes” alias. The keystore password is “dunesdunes”

    keytool -keystore ./jssecacerts -delete -alias dunes -storepass dunesdunes

    Delete "dunes" alias
    Delete “dunes” alias
  4. Use keytool to create a CSR. The certreq alias must be “dunes”.  Exporting the csr to the fie named vcvvcoreq.csr

    keytool -keystore ./jssecacerts -storepass dunesdunes -certreq -alias dunes -file vcvcoreq.csr

    Create CSR named vcvco.csr
    Create CSR named vcvco.csr
  5. Use filezilla or SFTP again to retrieve the csr
  6. Just like we did for the package signing certificate, submit a new request to your CA.
  7. This time, just download the certificate (not the certificate chain) in DER format instead of base64.  save the file as vcoDER.cer.
  8. Use filezilla or SFTP to copy vcoDER.cer to /etc/vco/app-server/security on vcvco1.  (you can actually place it anywhere, but this makes sense)
  9. Using keytool again, import the CA-signed cert into the keystore. The passwords are kept ‘dunesdunes”.

    keytool -keystore ./jssecacerts -storepass dunesdunes -importcert -alias dunes -keypass dunesdunes -file ./vcoDER.cer

    Import the cert
    Import the cert
  10. Restart the vCO services

    service vco-server restart

Prepare Second Orchestrator Appliance

  1.  Shutdown the first vCO appliance (vcvco1) to be safe
  2. Clone vcvco1 to a new VM named vcvco2, be sure to update the hostname and IP address in the vApp Properties. (Although it doesn’t affect the guest OS in this case)
  3. The cloned VM will retain the original IP address and hostname, so browse to https://vcvco1:5480, logon as root and set the correct IP address and hostname.
  4. Once vcvco2 is on the correct IP address, you can power on vcvco1
  5. Browse to https://vcvco2:8283, logon as vmware.
  6. On the Network area, select the correct IP address and apply changes.

Configure the cluster

Cluster mode, both nodes up
Cluster mode, both nodes up
  1. Browse to the vCO Configuration web interface, http://vcvco1:8283.  Logon as vmware.
  2. Under Server Availability, select Cluster mode
  3. Set the number of active nodes to 2, leave the heartbeat values at default unless you have a reason to change them. Click “Apply Changes”.  Note that there will be times when you’ll have to set the number of active nodes to 1.
  4. Under Startup Options, restart service.  This may not be necessary, but in my case, the nodes were not listed until after I restarted the vCO service.
  5. Repeat steps 1-4 on vcvco2


Preparing to load-balance
Note – this worked for me, YMMV

  1. Using vCNS Manager, locate the appropriate edge gateway, click Actions|Manage to open it for editing
  2. On the Configure Tab, edit the interface that will listen on the virtual IP
  3. Edit the Subnet and add the Virtual IP. It’s probably not the primary IP. Save and publish those changes.
    Add the virtual IP to the Edge Gateay
    Add the virtual IP to the Edge Gateay
  4. On the Load Balancer tab, on the Pools page, click “Enable”, then “Publish Changes”
  5. Click the green plus to add a load-balancing pool
  6. Enter a recognizable Name and Description, click “Next”.
    Load Balancer Pool
  7. On the Services step, check HTTPS, set Balancing Method to “ROUND_ROBIN” and the Port to 8281.Clck “Next”.
    Services (HTTPS:8281)
  8. On the Health Check step, set it as shown. Click “Next” when done.
    Health Check
  9. On the members step, click the green plus to add the IP address of yourvCO servers to the pool. I suggest keeping the weight for each at 1, while both nodes are active.  There are times when you’ll want to make one node active though (details below).  Keep the HTTPS port and Monitor Port at 8281 for each. Click “Next” once all you membersare added.
    vCO Members
  10. Review the Ready to complete step and click “Finish” if it all correct
  11. Click the Publish Changes Button before proceeding
  12. Click the “Virtual Servers” link, then the green plus to add a Virtual Server
    vCO Virtual Server
  13. Enter a meaningful name and description, provide the Virtual IP adddress that you added to the edge earlier, select the Pool created in the steps above and Enable HTTPS on port 8281. Set the Persistence Method to SSL_SESSION_ID and make the “Enabled” box is checked. Click “Add” then “Publish Changes”
  14. Test by navigating to https://vcvco.domain.local:8281/vco and verifying that the certificate matches.
  15. IMPORTANT UPDATE! – Repeat steps 7-14 above for TCP 8286 and 8287.  Without these undocumented ports, neither the vCO client nor the vCAC appliance will connect to the vCO cluster.

Additional steps
Put the two vCO nodes in a vApp, set them to start a few minutes apart to prevent both nodes from trying to initialize the database concurrently.

Use vApp to stagger the startup of the vCO nodes
Use vApp to stagger the startup of the vCO nodes


Notes, Caveats and Warnings

When writing information to vCO, such as designing and importing new workflows, VMware requires that only one vCO node be active.  I suggest that before you connect vCAC to vCO, you take the following steps:

  1. Logon to vcvco1 configuration as vmware , set the number of active nodes under Server Availability to 1.  Apply changes.
  2. Logon to vcvco2 configuration as vmware , set the number of active nodes under Server Availability to 1.  Apply changes.
  3. Watch the Service Availability area, wait for it to indicate that one node is in standby. If you’re impatient as I am, you can restart the service on vcvco2.  It should come up as standby.  Record which node is RUNNING.
  4. Logon to vCNS Manager, locate the appropriate Edge Gateway for the vcvco virtual server.
  5. Edit the Load Balancer pool, leave the RUNNING node with a weight of 1, set all other nodes’ weight to zero

Once the workflows have been created and edited and you want to resume distribution of vCO jobs among the nodes, just reverse these changes, setting the active nodes to 2 and the weights to 1 for both nodes.

Do not connect the vCO client to the virtual address.  In this case, only TCP8281 is forwarded and the vCO client needs additional ports forwarded to the nodes.  Other load-balancers/NAT devices may not have this issue.

This post may get some edits as I work through the rest on the vCAC distributed build.

I still have no idea why the certificate alias and password is “dunes”.  UPDATE – The company that was bought by VMware that originally developed the product that is now vCO was named “Dunes”.


Work with vCO over SSL


vCO 5.5.1 release notes

3 thoughts on “Configuring vCenter Orchestrator Appliance for High Availability”

  1. Great post – thanks! I am mid writing a very similar post over on for my vCAC distributed build out series when I stumbled across yours 🙂

  2. Brian,
    I’m curious how you are setting the hostname to the cluster name… doesn’t vCO automatically set the hostname based on reverse DNS queries for the configured IP address? Do you have reverse DNS entries for your node IPs resolving to the vCO cluster name?

    I also noticed that your certificate references the cluster name only, and not the individual FQDN’s of the nodes behind the VIP. Wouldn’t you want to add the node FQDN’s as SAN names on the certificate?

    1. Wow, thank you. As a tentative answer, I ended up setting the name on each host to the cluster name and yes I think you’d want to include the node FQDNs as SANs on the cert (I just wasn’t sure how to do that) I’ll give this some more research and update it for clarity. Thanks again for reading and letting me improve the post.

Comments are closed.

%d bloggers like this: