VCAP-DTD | Objective 3.2 | Determine the Database Architecture for a View Component Infrastructure Design

Determine the size and placement of the vCenter server database

VMware release a sizing calculator for vSphere 4.0 which can be found here which gives you a good guide as to the size of your database(s). Whilst nothing (that I have ever found or heard of) has been released since, you can still utilise the calculator within vCenter itself to determine the overall DB size. There are a number of factors that will determine the overall DB size which to me is not possible to work out manually so I wouldn’t have thought this would be a question in the exam.

Placement, however certainly could be. 

The first question in most cases is should I install the database on the local server (vCenter) or a remote server (a dedicated SQL server).

Local Installation

When I talk about installing the database locally, I’m not talking about using the bundles SQL Express option within vCetner, as this should never be used within Enterprise Class deployments, really, it shouldn’t really ever leave your lab. You can install a full databases server on your vCenter server be it Microsoft SQL or Oracle. This will provide enterprise level functions that are suitable for a production environment.

  • Faster – Having the data local on the same box is in most cases quicker than accessing the database over the network. You also won’t have to take into account factors such as network congestion. 
  • All in one solution – It also provides an ‘all in one box’, you won’t be affected by other applications utilising resources on the shared DB server.
  • Backup and Recovery – Finally having an all in one solution will be easier for backup and recovery, you won’t need to rely on other servers backup schedules or numerous remote agents as everything will be located on the same box.

I’ve listed a few benefits here, however when using View Composer vCenter becomes a critical Tier 1 application in the environment. If vCenter goes down, you loose the ability to provision any desktops. So, does your database need more protection that a single server, perhaps it needs to reside on an enterprise level database cluster.

Remote Installation

When talking about remote, I don’t mean in a different physical location but a remote server, so vCenter is installed on a single VM, then connected using ODBC to another network server running the DB. This again has it benefits:

  • Central DB Server – Most larger organisations already have a centralised server (group of servers) for hosting databases. If you start creating multiple DB installations for each application you design then it will be a nightmare to manage for your DBA team.
  • Separation of tasks –  This is perceived as VMware’s recommended choice. Servers have dedicated roles, and these roles should be on separate servers. The separation of tasks can also provide greater scalability benefits.
  • Corporate Policies – Most organisations has a DBA or team of DBAs. In more cases than not, they will have more experience in performance, optimisation and troubleshooting any issues with databases and database servers. 
  • Fewer resources required for vCenter – If you are going to install a database instance on your vCenter server then you are going to need to assign it the extra resource it will need to be able to sufficiently run this extra workload. 
  • DB Redundancy – I already touched on this in local installation, however SQL and Oracle can both be clustered,  providing resiliency in the case of a DB server failure. You cannot do this if the DB resides on the vCenter server.

Identify which database servers/platforms will be used in the design

This will nearly always be set out in the requirements of a design or the information will come out during stakeholder interviews. For example, if the customer already has a SQL environment and staff trained in managing this environment it is highly unlikely they will accept this deployment being designed on an Oracle platform. 

If the customer has a mixed environment you may well be led by licensing restrictions.

What ever the platform you are looking to deploy on simply ensure that it is fully supported for all of the View requirements (including View Events DB and the View Composer DB).

Determine size and placement of View Events Database

Looking through release notes and other documentation, I haven’t managed to find any officially supported calculators. You can assume that 2.5MB per desktop per month is required for the overall size of the events database. In real life, 1 – 1.5MB is a more realistic figure however this depends on how many refresh, logoff and recompose operations take place. 

Determine size and placement of View Composer Database

Again I can’t find any official documentation or calculators that help with this sizing, however you can safely assume that your Composer database will never get close to 5GB in size. Sizing for 5GB is a safe bet.