Submit a ticketCall us

Announcing NCM 7.7
With NCM 7.7, you can examine the rules that make up an access control list for a Cisco ASA device. Then you can apply filters to display only rules that meet the specified criteria, order the rules by line number or by the hit count, and much more.
See new features and improvements.

Home > Success Center > Network Performance Monitor (NPM) > Migrate Failover Engine WAN Configuration to SolarWinds Orion High Availability

Migrate Failover Engine WAN Configuration to SolarWinds Orion High Availability

Updated: September 8, 2017 | Migration Guide

This guide details how to migrate from a Failover Engine (FoE) WAN configuration to SolarWinds High Availability (HA). You can also migrate from an FOE LAN configuration to SolarWinds HA.

Migrating from FoE to SolarWinds HA is an easy process. You simply create and manage an HA pool in the Orion Web Console, using a provided installer to sync the secondary server products and configurations with the primary server. You can migrate to SolarWinds HA using your current server pairs or add new servers for HA pools. When migrating, you may need to upgrade your Orion Platform products.

Multi-subnet HA is available for SolarWinds Orion Platform products running on version 2017.3 These instructions include upgrade steps as needed.

Can I use FOE and SolarWinds HA in the same environment?

Yes, you can continue to use FOE and SolarWinds HA in the same Orion Platform environment. SolarWinds HA supports primary and secondary server pools for the Orion server and Additional Polling Servers. For example, you can install FOE to protect your primary/secondary Orion server, and HA to protect your Additional Polling Engines.

You cannot run FOE and SolarWinds HA to protect the same server. Only use FOE or HA to protect one server pair.

Benefits of SolarWinds HA

  • Access HA as an integrated feature through the Orion Web Console.
  • Easily set up HA through the Orion Web Console for your main polling engine and additional polling engines.

    SolarWinds HA does not support HA for additional web servers or Enterprise Operations Console (EOC).

  • Create and manage HA pools through the Orion Web Console.
  • Download an installer for your secondary server to install products and sync configurations.
  • Leverage servers with different specifications in HA pools.
  • Monitor and manage failovers directly through the Orion Web Console.

SolarWinds HA is different than FoE in that it does not require the user to maintain alias interfaces to address members individually. Each polling member maintains their own unique IP address, which is always accessible. HA uses a virtual host name for each pool that points to the active pool member. 

SolarWinds Orion natively supports HTTPS out-of-the-box. You do not need to make additional changes to your IIS. Ensure the site is bound to all adapters (the default) and not a specific adapter. You should not need to forcibly rebind the certificate to a different interface upon failover using HA.

System and network requirements

Before migrating from FoE to SolarWinds HA, you should verify your systems meet the requirements for the new product versions and HA. SolarWinds HA supports High Availability pools with physical to physical (P2P), physical to virtual (P2V), virtual to physical (V2P), and virtual to virtual (V2V) pairs.

To take advantage of SolarWinds HA for multiple subnets, you may need to also upgrade your Orion Platform products. HA is available in Orion Platform 2017.3 and supported products versions.

This guide includes upgrade instructions, if needed, for your HA migration.

We highly recommend using a new secondary server. If using VM servers, you can delete and create a new VM server for the secondary server. If using physical servers, prepare a new secondary server. Reusing the same FOE secondary server is not recommended. If you use this server, you will need to completely wipe the server and reinstall the OS.

System requirements

Hardware/
Software
Requirements for both servers
Operating System

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

  • You can use other DNS servers using your own scripts.
  • The primary and secondary server can be joined to a Windows domain

If protecting an NTA environment, both servers must be able to connect to the separate NTA Flow Storage database. SolarWinds HA does not protect the Flow Storage Database. If you wish to provide High Availability for the NTA  Flow Storage Database, follow the steps outlined in this article.

  • 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.
  • SolarWinds HA does not support IPv6 addresses.

Port requirements

Port Protocol Service/
Process
Direction Description
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.
5671 TCP

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.

Networking requirements

  • 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.

You may need to modify firewall rules to allow traffic from pool members and to the VIP address.

Supported Orion Platform product modules

Supported products include:

  • Network Performance Monitor (NPM) 12.2 and later
  • Server & Application Monitor (SAM) 6.4 hotfix 1 and later
  • Network Traffic Analyzer (NTA) 4.2.2 and later
  • Network Configuration Manager (NCM) 7.7 and later
  • IP Address Manager (IPAM) 4.5 and later
  • User Device Tracker (UDT) 3.2.4 and later when installed on Orion Platform 2017.3 and later
  • VoIP Network Quality Manager (VNQM) 4.2.4 and later when installed on Orion Platform 2017.3 and later
  • Storage Resource Manager (SRM) 6.5 and later
  • Web Performance Monitor (WPM) 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 protected by under SolarWinds High Availability, but the standalone product is not supported.

  • Database Performance Analyzer (DPAO) 10.2 and later
  • Engineers Toolset 11.0.3 and later
  • Firewall Security Manager (FSM) 6.6.8
  • Patch Manager 2.1.3 and later
  • Storage Manager (STM) 6.2.3
  • Virtualization Manager (VMan) 6.3.2 and later

Migrate the main polling engine pair to SolarWinds HA

To migrate to SolarWinds HA, you will uninstall FoE HA from your primary server. You should prepare a new secondary server for HA. SolarWinds HA supports HA servers for your main polling engine and additional polling engines.

 

Before you begin, you need the following:

  • The secondary HA server
  • An available HA pool license
  • A host name to use as the virtual hostname and a DNS account with privileges to update the DNS entry
  • Open port 5671 (TCP) on the primary (incoming) and secondary (outgoing) servers
  • Open ports 4369 and 25672 (TCP) on the main polling engine  primary and secondary server. These ports are not required when protecting additional polling engines.

As part of your migration to SolarWinds HA, you may need to upgrade your products. If you upgrade, the upgrade order must follow (1) main polling engine, (2) additional polling engines, and finally (3) additional web servers.

These instructions should be followed for all HA environments: physical to physical, virtual to virtual, and other variations.

 

1. Stop FoE services on the primary and secondary servers

Uninstall FoE from the primary server

  1. Stop the FoE services on the primary and secondary servers.
  2. Uninstall FoE from the primary server.

You can also remove the interfaces for the second network card. SolarWinds HA does not require or use a second network card for communication between the primary and secondary servers.

If you have an FoE pair for your additional polling engines, also uninstall FOE on that primary server.

2. VM: Delete the VM secondary server

Physical: Prepare a new secondary server

If you have a VM for your secondary server, delete the VM. Create a new VM for the secondary server.

If you have a physical for your secondary server, we recommend preparing a new secondary server. If you intend reusing the server, you must uninstall all Orion Platform products including FoE, wipe the computer, reinstall the OS, and reconfigure the hostname and IP address.

3. If needed: Upgrade Orion Platform product modules

SolarWinds HA for multiple subnets is available in Orion Platform 2017.3. If you need to upgrade, complete the upgrades across your environment before creating the HA pool.

You may need to upgrade your Orion Platform products to use SolarWinds HA. Verify your upgrade path with the Product Upgrade Advisor. The Orion installer also provides an upgrade path during the installation process. For full product upgrade steps, see the SolarWinds Upgrade Guide.

  1. Upgrade Orion Platform product modules on the main polling engine, primary server. You will set up the secondary server in step 4.
  2. Upgrade Orion Platform product modules on the additional polling engines.
  3. Upgrade Orion Platform product modules on the additional web server.

    SolarWinds HA does not support HA on additional web servers.

4. Activate HA Pool licenses
  1. Click Settings > All Settings > License Manager.
  2. Select a license.
  3. Click activate.
  4. Enter your license information.
5. Setup the secondary server for HA
  1. Download and install the secondary server software. Click Settings > All Settings > High Availability Deployment Summary.
    Click Setup a new HA server.
  2. On the Setup a High Availability Server dialog, click Download installer now.
  3. Move the downloaded installer to your secondary server and run it. This software installs all product modules and exact configurations from the primary server to the secondary server.
6. Create the High Availability Pool
  1. In the Orion Web Console, click Settings > All Settings > High Availability Deployment Summary.
  2. Click Setup High Availability pool next to your standby server.
  3. Enter the pool name and the virtual hostname.
  4. Click Create Pool to complete the pool setup.

 

  1. In the Orion Web Console, click Settings > All Settings > High Availability Deployment Summary.
  2. Click Setup High Availability pool next to your standby server.
  3. Choose the server you want to make highly available.
  4. Enter the pool name and the virtual hostname. Do not include the domain name in the virtual hostname.
  5. Select the DNS type.
    • Microsoft DNS

      We recommend a local administrator account configured for WMI access. For non-local administrator accounts, we recommend an administrator account with full DACL and remote WMI management enabled.

    • BIND DNS

      The BIND server must allow the virtual hostname to update dynamically. The operating system must also allow for dynamic updates to the DNS.

    • Other
      • Use this option if you can use scripts to update the DNS entry for the host name.
      • SolarWinds cannot validate the DNS server IP address or DNS zone for this selection.
  6. Click Next to complete the pool setup. The software validates the virtual hostname against the selected DNS server. If the host entry already exists, you are prompted to overwrite the entry or change the virtual hostname.

Your main server or additional polling engine is now highly available and can failover to the standby server.

When the pool is created, the High Availability Deployment Summary displays the active and standby servers grouped under the pool name.

  • You may need to refresh the page to see the correct pool and server status.
  • You may set the DNS Time to Live of your virtual hostname record in your script. SolarWinds recommends setting your DNS Time to Live to a shorter time period, such as a minute. You may also need to flush your browser's DNS cache by closing and reopening your browser after manual switchover.

 

You do not need to be online. The secondary server only needs access to the primary server in the LAN.

 

Learn more...

For additional information on requirements and settings, see the HA documentation.

Last modified
11:40, 14 Sep 2017

Tags

Classifications

Public