Now that the new Orion Failover Engine has been out for a couple of months, I wanted to discuss some of the common conversations I have had with folks as well as some of the common questions.

When I talk to customers, the first thing I do is discuss the two methods you can use to deploy the Orion Failover Engine -- high availability and disaster recovery. So, what the heck is the difference between the two?

1. High Availability – failover of the Orion applications within the same site, data center, or LAN. For example, the primary Orion server has a hard drive failure and switches over to another server within the same rack.

2. Disaster Recovery – failover of the Orion applications across the WAN to another site or Data Center. For example, the Primary Data Center in United States gets completely knocked offline with a flood and power outage and switches over to another Data Center in Europe.

Once I establish which method a customer prefers, I discuss that option in further detail. Since I don’t know which you prefer, let’s walk though each in more detail and discuss some considerations for you to take into account when choosing a deployment option.

High Availability:

This deployment option requires two NICs on each of the primary and secondary servers. The first NIC on both servers will be connected to the network and will share the same IP Address. The second NIC on each server is the failover channel, in which the heartbeat occurs, as well as real-time file and registry replication.

I know, I know… two servers cannot be on the network at the same time with the same IP Address. As part of the Orion Failover Engine package, we install a packet filter on the NICs, so only the active server is actively connected to the network, broadcasting and receiving traffic.

One benefit of the packet filtering approach is that when a failover occurs, your users browse to the same IP Address, and Orion can use the same database backend. As a Network Engineer, the larger benefit to you is any Syslog, SNMP Trap or Netflow device traffic you have been sending to Orion won’t have to be reconfigured to send to a new IP Address.

image

Disaster Recovery:

First, please do not make fun of my Visio skills in the below diagram :).

The primary difference for a Disaster Recovery versus the setup that I outlined above is the following.

  • Primary IP Address for Primary and Secondary server will not be the same as they are on different subnets
  • If you have configured your devices to send Syslog, SNMP Traps and Netflow by IP Address, then this will need to be reconfigured to send to the secondary IP Address or, when you initially setup this stuff, you should configure it to send to both IP Addresses.
  • You will need to work with your SQL DBA on how to handle SQL failover. We have provided some initial options, which you can find here.

image

Q&A:

Question: My Orion is deployed on a physical server, do I have to have a physical server for my secondary/backup machine?  
Answer: No, the Orion Failover Engine supports multiple hardware deployment options which include:

  • Physical to Physical
  • Physical to Virtual
  • Virtual to Virtual

You can read more about this here.

Question: How good is this stuff, this is a brand new product. Is it a 1.0?  
Answer: No, the Orion Failover Engine is based off of technology from the NeverFail Group. VMware has also licensed the NeverFail technology for their High Availability and Disaster Recovery offering and the shipping version is 6.4, so this is a proven technology.

Question: Where can I learn more about the details of the Orion Failover Engine?  
Answer: Review this document here

Question: So how will this work when I need to apply Microsoft patches or other software that will require me to reboot the machine?  
Answer: The Orion Failover Engine allows you to manually fail over the secondary server and suspend any replication of data between the primary and secondary until your updates are complete. Then you can fail back over to the primary and re-enable replication.  See here for more details.

Question: I own Orion NPM, APM and IPAM, but I only want to protect NPM & APM. Can I do this?  
Answer: No, you cannot choose which Orion products on a server are protected and which aren’t. This is because many of the Orion products share Windows services, so you can’t protect one without protecting the other.

Question: How does licensing work for my Orion server?  
Answer: We license by what we call a primary product per server. Currently classified as a primary products are Orion NPM, APM and NCM. The other Orion products (IPSLA Manager, IPAM and NTA) are already covered for free once you have Orion FoE for that server.

For example, I have Orion NPM, NCM and NTA on my server. You will need an Orion Failover Engine for Two Primary Products to cover NPM and NCM and NTA coverage is free.

Let’s look at a more complex example.

Server 1: Orion NPM, NTA & IPAM  
Server 2: Orion Additional Poller   
Server 3: Orion NPM   
Server 4: Orion Enterprise Operations Console or EOC

In this example you will need the following:

Server 1: Orion Failover Engine for One Primary Product   
Server 2: Orion Failover Engine for Additional Poller    
Server 3: Orion Failover Engine for One Primary Product    
Server 4: Orion Failover Engine for EOC

If you have any other questions, please feel to PM me or contact your Sales Engineer.  We also provide many Knowledge Base article which walk through many additional topic in detail, which I highly recommend you reference.