Synchronizing Orchestrator elements between Orchestrator servers
by Daniel Langenhan
VMware vRealize Orchestrator Cookbook - Second Edition
- VMware vRealize Orchestrator Cookbook Second Edition
- VMware vRealize Orchestrator Cookbook Second Edition
- Credits
- About the Author
- About the Reviewers
- www.PacktPub.com
- Preface
- 1. Installing and Configuring Orchestrator
- 2. Optimizing Orchestrator Configuration
- Introduction
- Tuning the appliance
- Tuning Java
- Configuring the Kerberos authentication
- Configuring access to the local filesystem
- Configuring the Orchestrator service SSL certificate
- Orchestrator log files
- Redirecting Orchestrator logs to an external server
- Backup and recovery
- Control Center titbits
- 3. Distributed Design
- Introduction
- Building an Orchestrator cluster
- Load-balancing Orchestrator
- Upgrading a cluster
- Managing remote Orchestrators
- Synchronizing Orchestrator elements between Orchestrator servers
- 4. Programming Skills
- Introduction
- Version control
- Changing elements in a workflow
- Importing and exporting Orchestrator elements
- Working with packages
- Workflow auto documentation
- Resuming failed workflows
- Using the workflow debugging function
- Undelete workflows and actions
- Scheduling workflows
- Sync presentation settings
- Locking elements
- 5. Visual Programming
- 6. Advanced Programming
- Introduction
- JavaScript complex variables
- Working with JSON
- JavaScript special statements
- Turning strings into objects
- Working with the API
- Creating actions
- Waiting tasks
- Sending and waiting for custom events
- Using asynchronous workflows
- Scripting with workflow tokens
- Working with user interactions
- 7. Interacting with Orchestrator
- Introduction
- User management
- User preferences
- Using Orchestrator though the vSphere Web Client
- Accessing Orchestrator REST API
- Accessing the Control Center via the REST plugin
- Running Orchestrator workflows using PowerShell
- Using PHP to access the REST API
- 8. Better Workflows and Optimized Working
- 9. Essential Plugins
- 10. Built-in Plugins
- Introduction
- Working with XML
- Working with SQL (JDBC)
- Working with SQL (SQL plugin)
- Working with PowerShell
- Working with SOAP
- Working with Active Directory
- Working with SNMP
- Working with AMQP
- 11. Additional Plugins
- 12. Working with vSphere
- 13. Working with vRealize Automation
- Introduction
- Working with the vRA-integrated Orchestrator
- Automating a vRA instance in Orchestrator
- Configuring an external Orchestrator in vRA
- Adding Orchestrator as an infrastructure endpoint
- Adding an Orchestrator endpoint
- Integrating Orchestrator workflows as XaaS Blueprints
- Managing AD users with vRA
- Using the Event Manager to start workflows
This recipe will show how to use synchronization to update Orchestrator objects between two Orchestrator servers.
We will need at least one workflow, action, or other Orchestrator object that can be synced.
Additionally, we also need two Orchestrator servers; they should not be in a cluster. For test purposes, you can deploy an Orchestrator appliance without any additional configuration.
We will use a workflow in this example. The same method applies to all other Orchestrator elements that can be synchronized:
- Right-click on a workflow (or a folder) and select Synchronize.
- You will now be asked to enter the IP or FQDN of the other Orchestrator server as well as some credentials for the connection. Click on Login.
- You will now see a summary of all workflows you have selected for synchronization on both Orchestrator servers:
- A: Here, the version number of a given workflow is shown
- B: You have four options that we will discuss in the How it works... section of this recipe
- C: Clicking on the magnifying glass icon will produce a split screen that shows you the difference between the versions (see the recipe Version control in Chapter 4, Programming Skills)
- Click on Synchronize ! to synchronize the workflows.
Synchronizing Orchestrator objects is one of the easiest ways to make sure that two servers have the same elements. This doesn't work for clusters as both Orchestrators in a cluster share the same database (same workflow IDs). A good example here is a sync between a development environment and a production environment.
When synchronizing a local element that doesn't exist on the remote server, Orchestrator will not only create the element but also the folder structure for it. This will make sure that the same structure exists on both servers. Also, the ID of the Orchestrator object will be kept the same when synchronizing.
Please note that depending on which direction you sync, the options you see might be different:
|
Action |
Description |
|
None |
This is not what you expect. This will update the remote version with the local version. If the element doesn't exist on the remote side, it will create it there. |
|
Update |
Update will take the version from the remote server and will overwrite the local version. |
|
Commit |
This will take the local version and overwrite the remote version. |
|
Delete |
If an element doesn't exist on the remote server, you can choose to delete the local version. |
The recipe Managing remote Orchestrators in this chapter.
The recipe Working with REST in Chapter 9, Essential Plugins.
-
No Comment