This section provides information on what's required to run Commander in evaluation, regular, and enterprise environments.
Software requirements
Virtualization and Cloud Platforms Supported |
|
Operating Systems Supported for Commander Installation |
|
Languages Supported |
|
Databases Supported |
|
Browsers Supported |
Commander and the Service Portal don't support multiple connections in the same browser. Use a different browser to open another session. |
Network |
|
Licensing |
|
Hardware requirements
The following table provides Commander deployment tiers based on typical use for on premise and public cloud Commander installations. Note that a Commander instance must be deployed on its own server independent from other applications and services.
See Scaling Required Hardware for more deployment details. You can also create a case through the Snow Support Portal to discuss requirements if you have any questions or unique configurations.
Sizing Profile | Base Requirements |
|---|---|
Evaluation A deployment to evaluate Commander's feature set. It should contain fewer than 1000 VMs and have fewer than five concurrent users, with infrequent reporting. It shouldn't grow significantly beyond original occupancy, and it's not expected to be upgraded to production. | Application Server
|
Regular A deployment for production environments with fewer than 1500 VMs, supporting fewer than 30 concurrent users, with frequent reporting. | Application
|
Enterprise A production deployment for dynamic environments with more than 1500 VMs, supporting more than 30 concurrent users, with frequent reporting. | Application
|
| Sizing Profile | Base Requirements |
|---|---|
Evaluation A deployment to evaluate Commander's feature set. It should contain fewer than 1000 VMs and have fewer than five concurrent users, with infrequent reporting. It shouldn't grow significantly beyond original occupancy, and it's not expected to be upgraded to production. | Application
|
Regular A deployment for production environments with fewer than 2500 VMs, supporting fewer than 30 concurrent users, with frequent reporting. | Application
|
Enterprise A production deployment for dynamic environments with more than 2500 VMs, supporting more than 30 concurrent users, with frequent reporting. | Application
|
Sizing Profile | Base Requirements |
|---|---|
Evaluation A deployment to evaluate Commander's feature set. It should contain fewer than 1000 VMs and have fewer than five concurrent users, with infrequent reporting. It shouldn't grow significantly beyond original occupancy, and it's not expected to be upgraded to production. | Application
|
Regular A deployment for production environments with fewer than 2500 VMs, supporting fewer than 30 concurrent users, with frequent reporting. | Application
|
Enterprise A production deployment for dynamic environments with more than 2500 VMs, supporting more than 30 concurrent users, with frequent reporting. | Application
|
VM Access Proxy hardware requirements
The optional Commander VM Access Proxy allows you to secure your virtualized infrastructure behind a firewall while still permitting your users secure console, RDP, VNC, and SSH access to their VMs. For information on how to install and configure the VM Access Proxy, see Set Up VM Access Proxies. If you are currently using a version 3.0 - 3.7 VM Access Proxy, it's highly recommended that you upgrade. For more information, see Upgrade Commander VM Access Proxy.
Minimum requirements:
- Dedicated 64-bit Linux machine
Running the VM Access Proxy version 3.10 in a container hosted on Ubuntu Linux 20.04 is the only distribution and version fully supported by Snow Software. Errors may occur if other distributions don't have the required packages in the same locations.
- Version 3.10 or higher of the Linux kernel
- iptables version 1.4 or higher
- Docker engine 18.09+
- Docker-compose tool 1.8.0+
- 2 CPUs
The more CPUs available, the more concurrent connections the VM Access Proxy can handle.
- 2 GB memory
- 10 GB disk space
- Time synchronization using either an NTP server or vCenter host
Network requirements
The following ports are used by the various Commander components. You configure some of these ports during installation, and you can also configure ports after installation using the Snow Commander Control Panel. Certain ports can be configured only through a system property. For more information, create a case through the Snow Support Portal.
IMPORTANT: To protect the security of the Commander system, all ports must be firewalled, with the exception of ports that are required to be inbound.
Where the direction is outbound, this implies a corresponding inbound connection to the target.
Network Requirements - Basic Operations
Network Requirements - Authentication
Network Requirements - Optional
Network Requirements - Client Connections
All of these connections go from the client browser to the respective servers.
Network Requirements - Advanced Configuration
Installation architecture
The following diagram shows the typical architecture of an on-premise Commander installation. For information on the recommended architecture for public cloud installation, see Deploy Commander in AWS.
Required administrative accounts
Commander requires an administrative account on each cloud account. The account must have full administrative access on the entire cloud account. Administrator privileges are required for a number of functions that Commander performs, including retrieving VM and infrastructure information, managing VM identity, powering VMs on and off, and other policy actions.
We recommend that you create a uniquely identifiable administrative account on each cloud account. Creating a unique account name allows you easily to track Commander commands sent to the cloud account by Commander or by Commander users.
When configuring an Amazon Web Services (AWS) cloud account, if you can't create an administrative account with the required permissions, you can create an IAM policy as an alternative. For more information, see IAM policy. For more information about best practices for configuring and managing AWS cloud accounts, see Deploy Commander in AWS.
Commander doesn't make use of VMware's Linked Mode feature. Commander communicates with each vCenter directly.
Third-party integrations
The following table lists standard third-party integrations for Commander.
Category | Integration |
|---|---|
Authentication | |
Windows SSO | |
Configuration Management and Software Deployment/Automation | |
IPAM | |
Application Monitoring | |
Notification | |
Workflow Automation | |
For non-standard third-party integrations, you must download additional components such as scripts, workflow plug-in steps, or workflow modules for use with Commander. For more information about other supported third-party integrations, and the additional components required, see the Snow Software Cloud Management Integrations GitHub page.
In testing its products, and in particular their interactions with other vendors' products (e.g., Microsoft Windows, SQL Server), Snow Software (“Snow”) uses default installations of the supported versions and editions of these third-party products, configured as per the Snow System Requirements document.
Many of these third-party products offer additional features and configuration options. Please refer to each third-party product's documentation for details.
These additional third-party product features and configurations are not tested by Snow for compatibility purposes, and unless otherwise stated might have an impact on the functionality and performance of Snow products.
Snow products may not operate in accordance with the applicable Snow product documentation in environments where these additional third-party features and configurations are implemented.
For these reasons, any implementation of such additional third-party product features and configurations must be validated by the installation's technical owner(s) on a case-by-case basis and implemented under their responsibility.
As best practices would suggest, a preliminary implementation on an expendable test environment and a complete backup and restore strategy are highly recommended before any such implementation of third-party product features.
