Submit a ticketCall us

Systems Monitoring for Dummies
Our new eBook will teach you the fundamentals and help you create monitors and alerts that are effective, meaningful, and actionable. Monitoring is more than a checkbox on your to-do list. This free eBook will give you practical advice to help you succeed in all aspects of monitoring – discovery, alerting, remediation, and troubleshooting. Don’t miss out on this indispensable resource for newbies, experienced IT pros, and everyone in between. Register Now.

Home > Success Center > Archive > 2017September28 - SRM Deletes > High Availability in SRM

High Availability in SRM

Table of contents
Created by Nigel, last modified by Gerald.Prado on Sep 28, 2017

Views: 32 Votes: 0 Revisions: 2

SolarWinds High Availability (HA) provides failover protection for your Orion server and additional polling engines to reduce data loss. If your primary server fails, the HA feature allows your secondary server to take over all services, such as polling and alerting, with minimal downtime. SolarWinds HA protects your main server, also known as your main polling engine, and additional polling engines. It does not protect your databases or your additional web servers.

SolarWinds supports physical-to-physical, physical-to-virtual, virtual-to-physical, and virtual-to-virtual failover in an IPv4 LAN environment.

How does it work?

When you configure your environment for SolarWinds High Availability, place your secondary server on the same subnet as the primary server. Configure the secondary server to use the same network and database resources as the primary server. In the Orion Web Console, add both servers to an HA pool, which is accessed through a single Virtual IP (VIP) address to route incoming requests and messages to the current, active server.


The SolarWinds HA software monitors the health of both servers in the pool, and both servers keep open communication channels over TCP port 5671 to exchange information. When a critical service goes down, such as the SolarWinds Information Service, the software attempts to restart the service. If the service goes down a second time within a set amount of time, the software initiates a failover to the standby server.

After a failover to the secondary server is complete, the secondary server becomes the active server and continues to act as the active server until another failover event occurs. The secondary server assumes all of the responsibilities of primary server, including receiving syslogs, SNMP traps, and NetFlow information through the VIP. You can manually failover to your primary server to return it to active service.

Last modified