Cloud Applications Marketplace Cloud Operations Industry Expert vCenter Operations vRealize Operations

David Davis on vCenter Operations- Post #5 – vCenter Operations Manager Architecture

In my last article in this series, Understanding VMware vCenter Management Suite Editions, I discussed the various editions that make up the vC Ops Suite, what vSOM is, and the various pieces of the vC Ops Suite including vCenter Operations Manager, vCenter Configuration Manager, vCenter Hyperic, vCenter Infrastructure Navigator, vCenter Chargeback Manager, and the custom UI.

In this article, I want to dive into vCenter Operations Manager specifically, and discuss the architecture of the product. In my post on Evaluating VMware vCenter Operations Management Suite, I talked about how important it was for you, as a potential virtualization management software customer/user, to understand the architecture of the product you are selecting. So what about the vCenter Operations Manager architecture? How does it work and what makes it unique? Let’s find out.

What Is The Architecture of vCenter Operations Management Suite?

For good or bad, when admins deploy vApps, they don’t tend to think about the architecture of an application. The good side of this is that “you shouldn’t have to”, if you just want to use the app, right? You don’t have to install a new guest OS, install a database, install an app, or even connect it to the database. While vApps are a blessing, the potential downside might be that, as a vSphere Admin, a vCenter Operations Manager consultant, or an admin of a large vC Ops installation – you should know the architecture of the applications and database that is running inside of what you deployed and use everyday. Additionally, as I mentioned in previous articles, understanding the architecture of an application determines many things. For example, the architecture of an application will determine its scalability, it’s extensibility, and more. One day, when the application stops working for some unknown reason, the architecture will determine the ease of troubleshooting, in many cases.

As we learned in previous articles,  there is a LOT more to the vCenter Operations Management Suite than just vCenter Operations Manager.

vC Ops Overview Graphic

The vC Ops Suite can manage physical servers, virtual infrastructure and hypervisors like vSphere and Hyper-V, storage, business critical applications like SAP, SQL Server, Exchange, Oracle etc., as well as public clouds like Amazon AWS. The platform provides application visibility, reporting, alerting, analytics, automation, and log data integration. vC Ops integrates the management disciplines of performance, availability, capacity, configuration, and compliance. Extensibility is offered through an ecosystem of management packs, APIs, and SDKs with it all being managed by the vC Ops operations console. Again, this functionality is provided by the numerous vC Ops applications that make up the suite – vC Ops Manager, Configuration Manager, Hyperic, Infrastructure Navigator, and Chargeback Manager. The included functionality is of course dependent on which vC Ops Suite edition you have selected.

What Is The Architecture of vCenter Operations Manager?

Rather than going into the architecture of every application in the suite, let’s hone in on vCenter Operations Manager specifically. vCenter Operations Manager is deployed as an OVF format vApp that contains two virtual machines. Those virtual machines both run SUSE Linux Enterprise Server (SLES) version 11. The same vApp is used for the Standard, Advanced, and Enterprise Editions. They are broken up into the user interface VM (UI-VM) and Analytics VM.

Here’s what an architectural diagram looks like for vCenter Operations Manager:


At this point, let me offer a little quiz to ensure that you are paying attention. How many databases make the vC Ops Manager application function?

The answer is 3 databases. There is a Postgres database in the UI VM, a Postgres database in the Analytics VM and an FSDB (file system database used to hold raw collected metrics) in the Analytics VM as well.

Moving up from the databases at the bottom, it’s the UI-VM that does capacity analytics, based on the data stored in the analytics VM. The UI-VM also presents the information you see in the vSphere Web Client when vCenter Operations Manager is loaded, in the enterprise web application (only used when using the custom enterprise edition), and in the administration web application (the vCenter Operations Admin configuration portal). Rolled up capacity data is stored in the Postgres database.

The second VM, the Analytics VM, is what collects data from vCenter, computes those derived metrics (Collector), stores the metrics in the file system database (FSDB), passes metric information between vCenter Operations Manager components (ActiveMQ – the message bus), and the Postgres database (which stores all other data collected, including objects, relationships, events, dynamic thresholds, and alerts).

To summarize the services running to support this architecture, you have the following:


All of these services can be monitored and managed from the vC Ops admin interface or through the command line using SSH and they use the following network ports to do their job:

  • 22 – for SSH access to either of the vC Ops VMs
  • 80 – redirects to port 443 for secure communication
  • 443 – for the vC Ops portal or vC Ops Admin interface
  • 1194 – between the two vC Ops VMs, over the encrypted tunnel

Note: with vCenter Operations Management Suite Enterprise edition, you do have the option to perform a standalone installation of vC Ops in Windows or Linux Server (with a SQL or Oracle backend) but this should not be confused with the custom dashboard option.

3 Things you Didn’t Know About vCenter Operations Manager Architecture

From researching this topic and talking to VMware engineers, I learned numerous things I didn’t know about vC Ops architecture. I specifically asked VMware Senior Technical Marketing Manager Hicham Mourad, who blogs on this VMware Cloud Management blog, for some little known interesting facts about vCenter Operations Manager. Here are three of the “I bet you didn’t know…” vCenter Operations Manager facts:

  1. Open VPN Encrypted Tunnel – if you were paying attention closely, you noticed that in the diagram above, it showed an Open VPN encrypted tunnel between the two vC Ops vApp VMs, above. This tunnel (using port 1194 as I showed in the network port list) is what allows the two vC Ops VMs to work together. This is an all-software tunnel service running inside the SLES Linux OS on each host where VM’s know each other by using the internal names of firstvm-internal and secondvm-internal network adaptors.
  2. Fully Functional vcops-admin Command – everything that can be done in the admin graphical user interface can also be done from the Linux command line using the vcops-admin script and it’s many options.
  3. New Easier Updating – Now with vC Ops 5.8+ releases, there are two .PAK files. One PAK file is for updating the underlying SLES 11 OS to the latest version. The second .PAK file is for upgrading previous versions of the vCenter Operations Manager vApp to the latest version. This ability to upgrade the underlying OS that vC Ops runs on allow you to keep that virtual appliance OS secure and is a required piece of the vC Ops upgrade.

Sizing vCenter Operations Manager

When deploying vCenter Operations Manager for the first time, one of the things you need to take into consideration is the size of the virtual infrastructure you will manage with vC Ops. The size of the infrastructure you are managing will determine the size you should configure the vC Ops vApp VMs to be.

During the vApp deployment process (which I will be covering next in my vC Ops Deployment article), you’ll be asked if you want the vApp to be small, medium, or large size. These sizes match up with a range of VMs that will be in your deployment and those also correspond to the vCPU and vRAM configuration of the vApps to support those VMs. You can always update this to add more resources by shutting down the vApp, and then increasing the resources on the VM’s and then powering the vApp back up. CPU and memory is straight forward.. For Storage you add additional drives, and LVM (logical volume management) will kick in on boot up and AUTOMATICALLY add the storage.

Here’s how it breaks down:


Additionally, depending on the amount of data that you choose to collect, you may need to resize the vApp virtual disk. You can use the info on this graphic to help:


With a solid background in vC Ops Manager architecture, we now know “how it works” and are ready to deploy it. In my next article, learn about my experience installing vCenter Operations Manager in my lab along with tips and tricks to help ensure your installation goes perfectly, as planned, the first time.


Leave a Reply

Your email address will not be published.