
VMware vRealize Orchestrator Cookbook
By :

In this recipe, we will attach Orchestrator to an external database. This is a more secure and reliable method than using the embedded database.
We will need a database; the following databases are supported with vCO 5.5.2.1:
You will need to create an empty database for Orchestrator, and you should also create a dedicated user account for Orchestrator to access the database.
You should be comfortable with using one of the methods described in the Two ways to configure Orchestrator recipe.
If your Database requires SSL, you will need to import the SSL certificate first; for this, see the Important Orchestrator base configurations recipe in this chapter.
When you replace the database, you will have to reconfigure the following items: Licensing and Server Certificate.
Both configuration methods will be shown; choose the one you prefer. In this example, we have added a SQL database to Orchestrator. The other databases are not that much different.
The following information is needed for each type of database:
Database type |
Oracle |
SQL Server |
PostgreSQL |
---|---|---|---|
Login |
required |
required |
required |
SSL |
optional |
optional |
optional |
Hostname |
required |
required |
required |
Port |
1521 or custom |
1433 or custom |
5432 or custom |
Database name |
- |
required |
required |
Instance |
required |
optional |
- |
Domain |
- |
optional |
- |
Use NTLMv2 |
- |
optional |
- |
The Orchestrator database contains the entire configuration, workflows, workflow runs, events, runtime information, actions, and a lot more. Therefore, it is quite important to consider using an external database. Without an external database, certain Orchestrator features, such as resuming a workflow after an Orchestrator Server crash, will not work or will be impaired.
All Orchestrator versions come with the embedded PostgreSQL database or use the vCenter Server database. A production environment dictates the use of an external database that integrates with the business continuity processes of your company.
In addition to this, the embedded database isn't really sized or optimized for large deployments and doesn't allow the use of Orchestrator Clustering.
Using the vCenter Server database for Orchestrator is not really a very pretty solution either. IT best practices dictate using dedicated resources for production environments. Putting the database on the same VM as Orchestrator is something to think about as it results in a competition for resources between the database and the Java process.
Sizing is hard to predict. Each workflow run consumes around 4 KB, and most objects (for example, vCenter Server Object) require around 50 KB each. VMware recommends 1 GB for a production database. The good thing is that Orchestrator regularly runs clean-up jobs to reduce the database content. Also have a look at the User preferences recipe in Chapter 5, Basic Orchestrator Operations, where we discuss certain properties that influence how much information is kept in the database.
For the initial setup (and for updates), you should give the dedicated Orchestrator user the db_owner rights on the Orchestrator database.
For a normal usage scenario the Orchestrator user only requires the db_dataread and db_datawrite rights.
Here are some things you might find useful.
Giving the database the settings ALLOW_SNAPSHOT_ISOLATION and READ_COMMITTED_SNAPSHOT will reduce the chance of a deadlock occurring and is also a prerequisite for Orchestrator clusters.
The database should have NLS_CHARACTER_SET = AL32UTF8 set before you start allowing Orchestrator to build its tables.
To avoid an ORA-01450 error, it is important that you have the database block size configured in accordance with your database index.
Change the font size
Change margin width
Change background colour