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:
Oracle 11g
SQL Server 2005
SQL Server 2008
SQL Server 2012
SQL Server Express
PostgreSQL
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.
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 |
- |
Click on the Database section.
Select the Database type. The information on the screen will adapt to your choice.
Enter all the relevant information and click on Apply changes.
An error occurs, which is totally OK. It just means that the database is empty and needs tables.
Click on the Create the database tables link.
Then click on Apply changes again.
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.