Embotics® vCommander™ connects to one or more hypervisors to provide powerful automation and reporting options alongside improved user experience for producers and consumers of virtual services. This tight integration with your virtual estate means that the hardware requirements for vCPUs, memory and disk space scale in lockstep with its rate of occupancy and activity. Use the guidelines in this section to establish a good starting point for your installation, and be prepared to allocate more resources over time as your virtual estate grows.


Factors Impacting Hardware Requirements


Each of the factors listed below impacts the load on vCommander:

  • VM occupancy, the total number of VMs under management
  • VM transience, the frequency with which VMs are created and destroyed
  • Number of concurrent logins
  • Frequency and depth of reporting
  • Retention of historical data


Both VM occupancy and transience increase the amount of activity in the environment, which means that vCommander is receiving more telemetry to process. Similarly, the more users concurrently accessing the system and report runs generating activity also increase the overall load.


This being said, it’s sometimes difficult to predict what resources will be required, so the table below provides guidelines tiers of vCommander deployment based on typical use. You can also contact our support team to discuss requirements further should you have any questions or unique configurations worth considering.


Profile
Description
Base Requirements
Evaluation
A single-vCPU deployment used to evaluate vCommander's feature set. Will not grow significantly beyond original occupancy and is not expected to be used for production.

  • 1 vCPU / 2.0 GHz dual core
  • 4.0 GB memory
  • 2.0 GB disk space
  • Default Postgres database


Small
A single-vCPU production deployment for static environments of fewer than 500 VMs, supporting fewer than 10 concurrent users, with infrequent reporting.

  • 2 vCPU / 2.0 GHz Quad core
  • 4.0 GB memory
  • 1.0 GB disk space (installation)
  • 4.0 GB disk space (data partition)
  • Dedicated application server
  • Microsoft SQL Database


Medium
A dual-vCPU production deployment for synamic environments with fewer than 1500 VMs, supporting fewer than 30 concurrent users, with frequent reporting.

  • 2 vCPU / 2.0 GHz quad core
  • 6.0 GB memory
  • 1.0 GB disk space (installation)
  • 10.0 GB disk space (data partition)
  • Dedicated application server
  • Separate Microsoft SQL Database
  • DB data file (mdf) and log file (ldf) stored on separate disks


Enterprise
A dual-vCPU production deployment for dynamic environments with more than 1500 VMs, supporting more than 30 concurrent users, with frequent reporting.

  • 2 vCPUs / 2.0 Ghz quad core
  • 8.0 GB memory
  • 1.0 GB disk space (installation)
  • 10.0 GB disk space (data partition)
  • JVM memory increased to 6 GB 
  • Dedicated application server
  • Separate Microsoft SQL Database
  • SAN backing for database files




Important: No upgrade path exists that allows you to change database platforms from the default Postgres database to Microsoft SQL Server. As such, Postgres should only be used for evaluation purposes, or for small environments not expected to experience any growth. Otherwise, Embotics support can assist you with keeping some of your ownership and custom attributes applied to VMs, but other important data may be lost during the transition between database platforms.

 

Holistic Approach to Performance


It’s important to consider the whole environment when looking at vCommander sizing and performance, to make sure you understand from where performance demands originate. Going through the questions below will help provide insight factors potentially impacting performance.

  • When using shared database servers, when are the other applications most active?
    If vCommander is expected to be very active when spikes are already occurring, consider allocating more resources or using another server.

  • When will you run backups on the database?
    Backups should be scheduled for times during off-peak hours when fewer users will require access to the system.

  • How much data must you retain, and for how long?
    Purging data you no longer need will improve the database performance. vCommander ships with a default one year purge for event history. For optimal performance it is recommended that you augment data purging to also include performance, historical, and billing record history.

  • Have you optimized your reporting and scanning schedules?
    Any scheduled activity, like running reports and searches or your datastore scan should be scheduled for off-peak hours and staggered so that no two activities are executing concurrently.

  • Is your vCommander up to date?
    Embotics continuously reinvests engineering resources to optimize performance and eliminate software defects which slow the system down. Keeping up to date means taking advantages of the most recent improvements.

  • Have you excluded vCommander executables from virus scans?
    Given proper security measures are in place throughout the rest of the environment, there should be no need to scan the vCommander executables found in the <Install_Directory>\tomcat\bin\ folder. In some cases, scanning these files for viruses will slow the system down considerably, and should be avoided. Read Microsoft’s best practices for exclusions on SQL Servers here.

 

Monitoring vCommander Performance


In order to ensure your users continue to have an excellent experience with vCommander, it’s important to monitor system performance over time, so that you can accommodate increasing system demand for resources. Once of the best ways to do so is to manage the application and database servers with vCommander, so that you will receive rightsizing recommendation based on the performance metrics collected by vCommander or integrated monitoring systems.

There are many other applications available for monitoring system performance. When employing such a system, make sure to look at both the application server and database server, and see if you can correlate performance spikes to other activity in your environment. Set clear performance thresholds to guarantee acceptable performance for your users, and provide more resources once the threshold’s been passed.

Troubleshooting Performance


When you believe that you have experienced a loss of system performance, and wish to investigate further, you can investigate on your own prior to engaging our support team. Refer to the knowledgebase article Troubleshooting vCommander™ Performance Issues and if you are unable to resolve the issue, send an email to Embotics Technical Support