Configuring an external database

In this recipe, we will attach Orchestrator to an external database. This is a more secure and reliable method than using the embedded database.

Getting ready

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.

Tip

When you replace the database, you will have to reconfigure the following items: Licensing and Server Certificate.

How to do it...

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.

Database information

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	-

Using the Orchestrator Configuration tool

1. Open the Orchestrator Configuration tool.
2. Click on the Database section.
3. Select the Database type. The information on the screen will adapt to your choice.
4. Enter all the relevant information and click on Apply changes.
5. An error occurs, which is totally OK. It just means that the database is empty and needs tables.
6. Click on the Create the database tables link.
7. Then click on Apply changes again.
   

Using the workflow

1. Open the Orchestrator Client.
2. Navigate to Library | Configuration | Database.
3. Right-click on the appropriate workflow for your database and select Start Workflow.
4. Enter all the relevant information and click on Submit.
5. Wait until the workflow has successfully finished.
   

How it works...

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

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.

Database roles

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.

There's more...

Here are some things you might find useful.

Microsoft SQL

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.

Oracle

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.