SolarWinds High Availability requirements
High Availability on a single subnet is provided for SolarWinds products released on Orion Platform version 2016.2 and later.
High Availability over multiple subnets is provided for SolarWinds products released on Orion Platform version 2017.3 and later.
The products and product versions must match between your primary and secondary pool members.
Visit SolarWinds KB MT6886 to build an upgrade path.
Supported products for HA
|Single subnet||Multiple subnets|
|Products running on Orion Platform 2016.2 and later||Products running on Orion Platform 2017.3 and later|
|Network Performance Monitor 12.0.1 and later||Network Performance Monitor 12.2 and later|
|Server & Application Monitor 6.3 and later||Server & Application Monitor 6.4 hotfix 1 and later|
|NetFlow Traffic Analyzer 4.2.1 and later||NetFlow Traffic Analyzer 4.2.2 and later|
|Network Configuration Manager 7.5.1 and later||Network Configuration Manager 7.7 and later|
|IP Address Manager 4.3.2 and later||IP Address Manager 4.5 and later|
|User Device Tracker 3.2.4 and later||User Device Tracker 3.2.4 and later when installed on Orion Platform 2017.3 and later|
|VoIP & Network Quality Manager 4.2.4 and later||VoIP & Network Quality Manager 4.2.4 and later when installed on Orion Platform 2017.3 and later|
|Storage Resource Monitor 6.3 and later||Storage Resource Monitor 6.5 and later|
|Web Performance Monitor 2.2.1 and later||Web Performance Monitor 2.2.1 and later when installed on Orion Platform 2017.3 and later|
The following products can be integrated with your Orion Platform-based product. The integration module between products is supported under SolarWinds High Availability, but the stand-alone product is not supported.
- Storage Manager 6.2.3
- Virtualization Manager 6.3.2 and later
- Firewall Security Manager 6.6.8
- Engineers Toolset 11.0.3 and later
- Database Performance Analyzer on Orion 10.2 and later
- Patch Manager 2.1.3 and later
Software and Hardware requirements
SolarWinds strongly recommends that the hardware and software of the standby server matches the primary server. Using matching system specifications and installed software ensures the same performance in the event of a failover.
- SolarWinds does not provide failover support for any database.
- Some SNMP trap, syslog message, and flow data is lost while waiting for the secondary server to become active.
|Requirements for both servers|
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
|Hardware||Must meet the minimum hardware requirements for the products you have installed on the primary server or closely match the primary server|
|Software||Must meet the minimum software requirements for the products you have installed on the primary server or closely match the primary server|
|IP address version||IPv4|
|Database connection||Connection to the SolarWinds Orion database
If protecting an NTA environment, both servers must be able to connect to the separate NTA Flow Storage database.
|Other (for virtual hostnames)||
Windows or BIND DNS administrative server credentials
BIND version 9.3 and later or Windows DNS on Windows Server 2008 and later
|53||UDP||SolarWinds High Availability Service||outbound||Used when failing over with a virtual hostname to update the virtual hostname's DNS entry and for periodic monitoring.|
|4369||TCP||RabbitMQ||bidirectional||TCP ports 4369 and 25672 must be open between the main and secondary servers to allow RabbitMQ clustering between the two servers. These ports exchange EPMD and Erlang distribution protocol messages for RabbbitMQ. They do not need to be open in additional polling engine pools.|
SolarWinds High Availability
|bidirectional||Port 5671 must be open into the HA pool with the main Orion server from all Orion servers.|
|17777||TCP||SolarWinds installer||bidirectional||Used when installing the standby server software. You can close this port after installation.|
|25672||TCP||RabbitMQ||bidirectional||TCP ports 4369 and 25672 must be open between the main and secondary servers to allow RabbitMQ clustering between the two servers. These ports exchange EPMD and Erlang distribution protocol messages for RabbbitMQ. They do not need to be open in additional polling engine pools.|
SolarWinds High Availability does not support IPv6 addresses.
- Members of the HA pool that includes your main Orion server must be able to resolve the short names of all the other servers.
- All additional polling engines must be able to resolve the host names of each member of the HA pool that includes your main Orion server.
- Additional web servers must be able to resolve the host names of all Orion servers.
- Pool members must be able to resolve each other's host name.
- Devices sending syslogs, SNMP traps, and NetFlow information to your Orion server must be configured to send the information to the VIP address or virtual hostname and receive requests from the pool.
- Devices must be able to accept inbound connections from the source IP addresses.
Additional requirements for single subnet deployments
- Both your primary and secondary servers must be on the same subnet.
- Both pool members must have static IPv4 addresses set on the network adapter. You do not need dedicated NICs.
- A virtual IP address must be available on the same subnet as the primary and secondary servers.
- Devices must be able to accept inbound connections from the VIP address.
Depending on your network, you may have additional requirements for single subnet deployments. Up to three IP addresses per pool may be in use among the VIP, primary, and secondary servers because of how Windows calculates the source IP address from the HA pool. You can modify your devices to receive requests from all IP addresses or determine which IP address is used as the source IP address.
Additional requirements for multiple subnet deployments
- Both your primary and secondary servers must be able to communicate with each other using the host names.
- Your primary and secondary servers must use different host names and IP addresses.
You may need to modify firewall rules to allow traffic from pool members and to the VIP address or virtual hostname. For example, you may need to modify the NetFlow firewall rules to allow incoming TCP traffic on port 2055 to go to the VIP address.