This blog post beings a multi-part series which aims to help customers better understand the vCenter Server Appliance (vCSA) and its vPostgres database. We believe the vCSA should be the deployment model of choice but there are many misconceptions and myths about the vCSA and its components. In this first blog post we’ll focus on the database technology used in the vCSA – vPostgres. By the end of this post we hope that you will have a much better understanding of the vCSA’s database and how it differs from the traditional operating model with MSSQL and Oracle.
The release of vSphere 6.0 brought with it many enhancements including scale & feature parity for the vCSA when compared to its Windows-based counterpart. Prior to vSphere 6.0, customers were only able to use the vCSA and its embedded vPostgres database to manage up to 100 hosts and 3000 VMs whereas a Windows-based vCenter could manage up to 1000 Hosts and 10,000 VMs. While it was possible to leverage an external Oracle DB with the vCSA to reach the same scale numbers as a Windows vCenter, the overarching goal of the appliance model is to decrease deployment and operational complexity. So, to say it another way, we want the appliance to be self-contained and not rely on external databases. With vSphere 6.0 we now have that scale parity with the embedded vPostgres database.
The Database
The database is absolutely a critical piece of vCenter Server. In fact, many customers have a team of DBAs that are solely focused on architecting and maintaining optimized databases. Keeping the backend to their applications running smoothly and at the appropriate performance levels provides a huge value to their respective businesses. When looking at the appliance model, specifically the vCSA and its embedded vPostgres database, we find that some customers are hesitant to move the responsibility of database management from the DBAs to the virtual infrastructure team. This is quite understandable. The key concept that we want to show, however, is that we’re greatly simplifying what is required to deploy, configure, and manage the vCenter Server database.
One thing to also consider is that with the appliance model we can build in some great efficiencies and optimizations. We have control over the Operating System (SUSE Linux in this case), the vCenter application, and the vPostgres database. We know the workload characteristics and can design the entire stack against these known quantities. That’s much harder to do with only owning one layer (the vCenter Server application layer in this case) in the conventional deployment model, e.g. installing vCenter on Windows with an external database. Having complete visibility into the application and database has many benefits and enables us to produce an appliance that takes much less care and feeding than other deployment models involving an external, 3rd party database.
vPostgres Features
Let’s take a look at vPostgres so that we can better understand some of reasons why this embedded model is optimal. First, vPostgres is based upon the open source database PostgreSQL. For vCenter Server 6.0 we use PostgreSQL 9.3 and we’ll continue to update the PostgreSQL version with later releases of vCenter Server. From a technical perspective, we believe PostgreSQL is the most powerful open source RDBMS. PostgreSQL also supports multiple platforms including Linux (SLES and Red hat), Windows, HPUX, and UNIX to name a few. Our vCenter Server currently runs on a subset of those platforms (SLES Linux and Windows). Some of the best features of vPostgres that relate to vCenter Server are:
Tuning – VMware has defined higher default values for critical settings when compared to standard PostgreSQL including the settings for shared_buffers, checkpoint_segments, and wal_buffers. This leads to better performance out of the box with a nominal tradeoff in disk space and memory usage.
Vacuuming – PostgreSQL databases require periodic maintenance known as vacuuming. Vacuuming is periodically run for the following reasons:
To recover or reuse disk space occupied by updated or deleted rows.
To update data statistics used by the PostgreSQL query planner.
To update the visibility map, which speeds up index-only scans.
To protect against loss of very old data due to transaction ID wraparound or multixact ID wraparound.
There is a configurable auto-vacuuming process and VMware has configured those parameters to best suit vCenter Server.
Backup / Restore – The Write Ahead Log (WAL) enables backups to occur during operations without having to quiesce the database or vCenter Server application. The WAL records every change made to the database’s data files and can be replayed to restore consistency to the database. This mechanism is what enables backups to occur at an image level without worry of corruption or shutting down services. This also makes it unnecessary to manually backup the vCSA vPostgres DB on its own.
Backup & Restore
Now that we understand a little bit more about vPostgres let’s briefly discuss the supported backup methods for the vCenter Server Appliance and its embedded vPostgres database. It should be clear from the documentation that we fully support our own vSphere Data Protection (VDP) product (which, by the way, is based off of EMC’s Avamar technology). But what might not jump out is that we also support many 3rd party backup products that use the VMware vSphere Storage APIs – Data Protection (formerly known as vSphere APIs for Data Protection. The key in all of this is that whichever of these two backup methods you choose, an image level backup is required. A file level backup or database-only backup is not a supported method and will lead to issues during restore. So, if you still happen to be running vCenter on a physical machine (which is ok but we believe running a virtual vCenter Server generally is best) then you’ll need a backup tool that is able to create image based backups of physical machines. Note that this is a requirement that was introduced vCenter Server 5.1 release due to some architectural changes to vCenter Server, its database, and SSO. Specifically, the following data lives outside the vCenter Server 6.0 Database:
VM Storage Policies
Tags & Tag Categories
SSO Configuration
Roles & Permissions
Licensing
So, the point here is that in vSphere 6.0 (and 5.1 & 5.5 for that matter) simply restoring the vCenter Server database to a new vCenter Server will no longer be enough like it was in earlier versions. An image level backup is the only way to capture all of the information we need for a successful restore of both the vCenter Server and Platform Services Controller.
Speaking of the Platform Services Controller (PSC), let’s quickly address the supported backup options for it as well. An appliance-based PSC is really much the same machine as a vCSA – there are just different services running. Also, the PSC does not require a database. And to keep with the simplicity theme we support the same image based backup methods using VDP or the VMware vSphere Storage APIs – Data Protection. In vSphere 6.0 U1 some enhancements were made so that customers no longer need to backup all PSCs in an SSO domain at the same time. In 6.0 U1 and later, a restored PSC will be able to resynchronize itself with its replication partner(s).
Conclusion
In this first blog post we covered the vCSA and some general vPostgres knowledge. Hopefully its clear why we chose vPostgres as the databases technology for the vCSA and you have some high level knowledge on some of its most important features. VMware believes in the appliance model and we think that vCenter Server is even better in this form factor. In the next blog post in this series we’ll talk about some of the operational aspects of vPostgres to help increase the comfort level and enable more customers to adopt the vCSA.
