Local or Remote vCenter Database?

Local or Remote vCenter Database
The age old question: Whether tis nobler in the mind to have your vCenter database locally, or to suffer the slings and arrows (really, it’s not much more difficult) of setting up your database on a remote server? This is an important question, as both logical and legitimate cases can be made for either side.

Currently in the process of setting up a test lab for myself, this is one of the questions I asked. This was an easy question for me though as being a test environment for just me I wanted to do things I haven’t had much experience before, so I am going the remote route.

VirtualVCP has a post here which covers this topic pretty well

Advantages of a Local database

• Can use the bundled version of Microsoft SQL Server 2005 Express for smaller deployments of up to 5 hosts and 50 virtual machines
• Removes the network dependency between the vCenter server and the database server and is therefore more robust
• Easier to maintain as you only have to maintain one server and not two
• If vCenter is installed on a VM, a single backup will be performed for both vCenter configuration files as well as the vCenter database.

Disadvantages of a Local database

• Increases resource requirements for the vCenter Server
• Not a very flexible solution as it is more difficult for database administrators to manage.

Advantages of a Remote database

• This is convenient to support and maintain by the DBA team on existing database servers
• Resource requirements for the vCenter server is lower
• The vCenter database can be hosted in a SQL Failover cluster for high availability

Disadvantages of a Remote database

• Requires a robust network connection between the vCenter server and database server. vCenter will crash if connectivity is lost

There are a few more things to think about though…

Are you going to have need for other databases, such as Update Manager, Orchestrator or any other which are VMware or infrastructure related?

If so, it is one idea to put all your VMware environment databases on one server. This way you are consolidating your databases to one location, making it easier to backup, and even have the option of setting up a cluster for redundancy.

Do you have a DBA team at your organization that may be unhappy if you begin standing up several databases which are decentralized from their databases?

In this case, if you do have a DBA team you should definitely consult them and manage your databases for you. Chances are they will be more knowledgeable and with them managing it, you don’t have to worry about maintaining, troubleshooting, backing up, or anything other database related tasks. In short, if you have a team dedicated to databases, let them handle their area of expertise.

If you are your own database team, it would probably be easier on you if you centrally located your databases in one location, or at least a few consolidated locations. Being your own database team though….it’s obviously your call.

As a final statement, it is also just considered best practices to keep your applications (vCenter, VUM , etc) separate from their databases. One main reason for this is not having just one point of failure.

I hope this helps!

Additional Refernce:

VMware vSphere Design