High Availability 2.0 provides the first peek into supporting redundancy for Orion across subnets. This was previously referred to WAN deployment or Disaster Recovery with the Failover Engine, but under High Availability we refer to this simply as a multi-subnet failover configuration. In other words, this provides the same automated, near instantaneous, failover and recovery mechanisms as High Availability does in its first release, but extends that functionality to support pollers spread across different subnets. Those could be different sites, a dedicated disaster recovery location, or possibly even the cloud.
When installing the Primary Orion server you will follow the normal 'Advanced' installation process that you would for any other Orion product. Ensure not to select the 'Express' install option during installation, as a separate server running Microsoft SQL 2012 or later is required. When the Configuration Wizard runs you will be prompted to provide the Username, Password, and IP address of the SQL server you will be using for the installation.
Once the primary server is up and running using the NPM 12.2 installer, you will need to perform a similar installation on the secondary server using the separate High Availability installer which can be downloaded from within the Orion web interface under [Settings -> All Settings -> High Availability Deployment Summary -> Setup A New HA Server -> Get Started Setting Up a Server -> Download Installer Now].
Download the High Availability Secondary Server Installer
Next, execute the installation by double clicking on the "SolarWinds-Orion-Installer.exe" downloaded or copied to the secondary server. Enter the IP address of fully qualified domain name (FQDN) of your main Orion server, along with 'Admin' or equivalent credentials used to log into the Orion web interface and click 'Next'. On the following step of the Wizard, select the additional server role you wish to install. Since this will be a High Availability Backup for the main Orion server, select 'Backup Server for Main Server Protection' and click 'Next'.
Enter IP of Main Orion Server & Provide 'Admin' Credentials
Select Server Role to Install
Once the Installation completes the Configuration Wizard will be started. When prompted to provide information regarding the SQL server database, ensure you utilize the same SQL instance and SQL database that was chosen for the primary Orion server.
The following video, while arguably boring to watch, demonstrates the secondary server installation process.
As soon as both the primary and secondary servers are installed, return to the Orion web interface under [Settings -> All Settings -> High Availability Deployment Summary]. There you will be able to join the two servers into a multi-subnet failover pool.
|Click 'Set up High Availability Pool"|
|Enter a Virtual Hostname and click 'Next'|
|Select your DNS Server Type|
Enter the IP Address of your DNS Server, the DNS Zone (E.G. solarwinds.com) and administrative credentials to the DNS server to create the shared virtual hostname
If you are running BIND DNS, enter the IP address of your BIND DNS server, the DNS Zone, your TSIG secret key name, and the TSIG shared secret key value.
Once complete, review the summary and click "Create Pool"
When done, you will have pooled two Orion servers together across multiple subnets into a redundant, high availability pool
The following short video walks through this process in under a minute.
Is it possible to use a service account without admin rights for the HA configuration? Our customer is not willing to provide DNS admin creds at any cost...
I read this one 1 doc where non admin acc can be used with some roles.. is this true?
Yes, it's possible to use a least privilege service account to update the virtual hostname by following the steps outlined in the KB article below.
I did show the document but the customer has concerns over certain permissions where it refers high privilege access even for non-admin account..
Is there any document that talks about what exactly does the account do in back-end? Their main concern is that a 3rd party source should not have direct rights to DNS as its their entire network related and also agnst the security policies...Hence they are asking all details about the account and the process behind this configuration...
The only thing that is done is a new DNS record is created for the virtual hostname which points to the IP address of the active member of the pool. When a failover occurs, the DNS entry is updated to point to the new active member in the pool. It's fairly straightforward.
Another option that may work for you and works for us since my previous post:
Deploy the primary poller with a HA node in an alternate DC using multi subnet failover
Deploy an additional poller in each DC
All the polling workload is on the additional pollers and the primary poller is in essence just a brain, this meant the requirement to update DNS for us goes away, in the primary pool configuration the DNS name and DNS server are dummy records meaning we don't touch DNS servers or have to worry about permissions.
We are running SQL Always on across the two DC's and have a process defined to update the polling engine ID in the event of a DC failure.
So you are saying not to have application level failover but instead go with Windows level OR any other level of failover mechanism?
Although i didnt get your point on usage of APE here.
Hi pratikmehta003 The suggestion is that a workaround for MultiSubnet HA without DNS would be to add an Additional Polling Engine in each of the two HA locations which has HAwith VIP. You then send all traps, Syslog, net flow etc to the Additional poller VIP rather than the Primary DNS.
This does require a lot more spend as you would need 2 x APE license and 2 x HA license on top of what you already have.
Ah, I see.. but this won't work out for us at the moment
I am trying to convince the customer to use the solution available from
solarwinds and also provided them email from support stating what exactly
the account does while configuring HA and it doesn't have ant impact..
but still not successful, will try to make them understand by giving step
by step procedure and hopefully they agree...
We have already bought HA license and customer is proposing to use F5 but
that again might require two active instances as per what I have
On Thu, Jun 28, 2018, 1:17 PM dgsmith80
SolarWinds doesn't support an Active/Active HA solution. The HA is a Primary / Standby setup with the ability to select a preferred active primary. There are some ways around the DNS such as Load balance etc. Sadly I don't have enough experience with F5 to inform you of the best way to configure them for use with an Active/Standby solution such as SolarWinds. Hopefully, someone else in the community can contribute to that for you.
Not a prob Smith. I am checking on the process of F5 as well... Let's see
if I do something positive then will post it here...
On Thu, Jun 28, 2018, 2:09 PM dgsmith80
I have HA in our dev environment and have been running through some failover scenarios. I brought this up to Sean Martinez at Orlando SWUG this week, as well.
There is a single point of failure in the multi-subnet HA configuration as it requires only a single MS DNS server IP. If that server is lost in any fashion, HA won't be able to update the DNS A record.
I apologize if this has been brought up already. Is there a plan to improve this portion of HA?
We're currently trying to get this working but we're having issues when connecting to DNS.
We have a ticket open but i think they're stumped too.
We're trying to configure an APE on a different domain to the primary server with HA, so need to configure the DNS server to be one in the different domain.
When we go through the wizard it always says DNS server does not exist.
ICMP & TCP53 to the remote DNS server from the primary server is working.
I've been through the following KB and confirmed everything there is in place, Required DNS Permissions to set up a High Availability Pool and access Microsoft DNS - SolarWinds Wo...
The credentials we've configured can log onto the DNS server and manage DNS.
We've tried the NAT IP and the private IP in the wizard but both fail.
Has anybody come across this before?
What you describe is likely a trust issue between domains. If there is no trust, then you may need to either establish a one-way trust or utilize an alternative method for updating the DNS name. One option is to run a different DNS server local to Orion and perform DNS replication between domains. It may sound messy but to a DNS expert, this is really quite common and fairly straightforward. Another option is to create a subdomain that you can update. E.G. if 'solarwinds.com. is your domain, then create a DNS sub-domain running on the Orion server itself or elsewhere called something like 'ha.solarwinds.com'. Assuming your virtual hostname for your Orion server is 'Orion', then the full DNS name would be 'orion.ha.solarwinds.com'. That is likely the simplest option.
I just configured HA pool today for 1 customer. using virtual Hostname and Microsoft DNS option.
But customer came back stating the ID used for DNS is getting locked out. So could this be anything from Solarwinds end?
I'll assume you're referring to offline activation? Regardless, all licenses are managed by the main polling engine and handed out to servers through centralized licensing.
Regarding the virtual hostname being optional.
We are planning a large scale deployment with multiple APE's and AWS's to front the web console and polling/node traffic.
The primary polling engine will be in a HA pool and ideally in a multi subnet setup and in essence just the brain, if we leave the virtual hostname blank will there be any issues with APE's and AWS's communicating back to the active member of the pool?
Additional Web Servers and Additional Polling Engines need to communicate with the 'Active' Main Orion server. This is done using the hostname. When a failover occurs the hostname of the 'active' main Orion server is updated in the database, and this is the name the AWS/APE will use to connect to the 'Active' main Orion server. So long as this name is resolvable by and the IP address reachable by each of the scalability engines, then there should be no problem. This does NOT require a virtual hostname. In fact, if these servers are across different subnets and hostname resolution is not available via DNS for any reason, then you can simply add the hostname and IP address of both the primary and secondary main Orion servers to the Hosts file of your scalability engines to ensure hostname resolution functions properly.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.