Recently, Loop1 Systems has had the opportunity to play as an active participant in the Beta program for the next gen release of the All New High Availability (HA) product for Orion. For those of you whom have struggled with designing or using past products sponsored by SolarWinds, I think you are going to be pleasantly surprised with the practicality and ease of management by this new solution to the problem.
Let’s start with a history of how this solution has come to be. The very first product addressing redundancy offered by SolarWinds, for all of you oldies out there, was the HotStandby server. This solution was practical and it worked… as long as everything lived in the same network. HotStandby was eventually EoL’d by SolarWinds and we had a span of time with no good solution besides active-active and having fully deployed servers ready to stand up in case of emergency. Who wants to stand up a server though when you should be evacuating your home due to a pending coastal storm. We all needed SolarWinds to come up with a solution that would allow Orion to be always available and failover automatically.
Introducing Failover Engine (FOE). FOE did address the problem. It would back the server up and it would automatically failover if the server had a problem. The problem with FoE though was that it was hugely cumbersome and complicated upgrades. With SolarWinds active focus on development of the Orion product, the hardships introduced to the upgrades became a real headache. This doesn’t even account for just the headache of making sure FoE was reliable. …And we saw the EoL of Failover Engine.
Now, SolarWinds has introduced their new High Availability (HA) product. The HA product allows Orion servers, operating with the same capacities, to be aware of each other. If a catastrophic event were to happen with one of the servers, HA will automatically failover to the opposite server. This is a 1:1 relationship as it is designed today – no other servers can be added to the pool for added redundancy yet. HA can notify you, the administrator, via email when an event happens or problems with a server are occurring. Also, a shared VIP allows for a shared IP address between the servers that not only allow for access to the Orion web interface hosted on the main poller pool, but also a shared IP for both servers to receive Syslog and SNMP traps as well as Netflow data.
Another highlight of the HA is that the code is already in the installer for the Orion product installation. You don’t need to install an additional package to your existing ‘Production’ Orion server to make this work. We’re already starting off on the right track by minimizing down time for the production Orion server.
Now for the down side: The current release of the Orion HA only supports the opposite server to be in the same subnet. This is truly HA and not DR as it stands now. But with every cloud, there is a silver lining. The Beta HA is supported in a DR design. The IP addresses for the two servers can be lined up in two separate subnets. This gets us excited!
If you are interested in talking about HA and how to implement it best in your network, drop us an email or give us a call. Loop1 is happy to help!