How to configure Observer Reporting Server Redundancy

You can enable Observer Reporting Server Redundancy so that should your primary Observer Reporting Server lose power or connectivity, the failover Observer Reporting Server becomes active. This is part two of a two part procedure.

Prerequisite(s):

Network Load Balancing configured. See How to configure the failover cluster in Windows.

All Observer Reporting Server configurations complete, except ORS Redundancy. Most Observer Reporting Server settings from the primary system automatically transfer to the failover system after the redundancy feature is completed.

1.	On the primary Observer Reporting Server system, choose Options > Program Settings > General tab and select “Enable ORS redundancy.” Click OK. This adds the ORS Redundancy tab to the user interface. The Enable ORS redundancy option is only available if NLB has been installed and configured.

2.	On the ORS Redundancy tab, click the Make this the Primary ORS button. This sets this Observer Reporting Server system to be the primary Observer Reporting Server.

3.	Click the Edit button and provide the following:

The IP address of the management interface on the other Observer Reporting Server system, not the NLB interface

How many days should be synchronized (0-365)

The local Windows user name, which must have administrative privileges, and password under which NLB is running

4.	On the failover Observer Reporting Server system, complete step 1 and step 3. Do not complete step 2.

The Observer Reporting Server redundancy feature is now configured. It may take several minutes (10 or 60 based on your settings) before the failover Observer Reporting Server is synchronized.

To ensure that your failover process is working, you should test it from time to time to verify it functions as expected. For production servers, you would want to test at a slow time, such as on a weekend, late at night, or holiday. To minimize any risk to the system itself, shut down any programs or processes that are not essential to the failover test.

Understanding NLB failover and Observer Reporting Server redundancy fields

The table provides greater detail about each of the fields on the Observer Reporting Server Redundancy tab. It also answers common questions such as what is synchronized and what happens when the primary Observer Reporting Server goes offline.

Table 1. Observer Reporting Server redundancy fields

NLB heartbeat	The NLB heartbeat between all systems in the cluster is constant, but failure is determined when there is no response received within five seconds. This is part NLB, not Observer Reporting Server.
Observer Reporting Server heartbeat	The primary Observer Reporting Server sends a health request periodically to confirm the failover Observer Reporting Server is available. If the failover Observer Reporting Server does not respond, the primary Observer Reporting Server logs the event and disables failover services until the problem is resolved. If the failover Observer Reporting Server detects that the primary Observer Reporting Server has failed, then it initiates an NLB failover and the failover Observer Reporting Server becomes active.
Observer Reporting Server synchronization	The Observer Reporting Server settings is synchronized every 10 minutes. This is configurable to 60 minutes by changing the value on the Schedules > Data Transfer tab. The Observer Reporting Server trending data is checked at the same rate but only data from yesterday and prior is synchronized. This is because files from today are actively being updated, whereas yesterday’s files are not. Should the primary Observer Reporting Server failover before today’s data has been synchronized with the failover Observer Reporting Server, the failover Observer Reporting Server will request the data from the data sources directly. Today and yesterday are relative terms based on UTC, not your local time.
Synchronize Now	A manual way to initiate a transfer of the latest Observer Reporting Server settings from the primary Observer Reporting Server to the failover Observer Reporting Server. The Observer Reporting Server trending data that is synchronized is from yesterday (based on midnight UTC) and prior. It does not get trending data from today.
Get Data Range	Enabled only on the failover Observer Reporting Server. Allows you to choose a date range from which to transfer data. It does not transfer Observer Reporting Server settings.
Make this the primary Observer Reporting Server	Enabled only on the failover Observer Reporting Server. Makes the failover Observer Reporting Server become the primary Observer Reporting Server after a negotiation, when possible. This option can be used to switch roles so that the primary Observer Reporting Server can be taken down for maintenance.
Edit	Allows you to set IP address of the management interface on the other Observer Reporting Server system, not the NLB interface; how many days of data should be synchronized (0-365 days); and the Windows user name and password under which NLB is running. The user account must have administrative privileges and is required if Observer Reporting Server is running as a Windows service.
What is synchronized	All data and settings, except: Whether you want Observer Reporting Server to run as a Windows service. The Observer Reporting Server name and security settings (from Options > Program Settings ). If you use security settings, you must manually duplicate the encryption key or NIMS options on the failover Observer Reporting Server. The security settings of the failover Observer Reporting Server will be used should it become active. If the failover Observer Reporting Server’ security settings do not match those of the primary, Observer Reporting Server will not be able to get any data from its data sources or provide reports. Licensing. You must have a separate license for each Observer Reporting Server system.
What happens when the primary Observer Reporting Server comes back online	When the failover Observer Reporting Server determines that the primary Observer Reporting Server is unavailable, it becomes the primary Observer Reporting Server. The system that used to be the primary Observer Reporting Server becomes the failover Observer Reporting Server and it stays the failover Observer Reporting Server even after it comes back online. Even though the failover Observer Reporting Server has become the primary Observer Reporting Server, minimal changes should be made to its configuration.
Shut down order	To prevent the failover Observer Reporting Server from becoming the primary Observer Reporting Server, shut down the systems in the following order: failover system first, then the primary system. Start them in the reverse order (primary first, then failover). This prevents NLB from switching their priority settings. Whenever the systems are shut down and restarted, you should verify that each has its correct role (primary/secondary), and that they are connected and synchronizing.
Logging	Observer Reporting Server logs all redundancy actions in the Observer Reporting Server event log. When performing certain manual actions, check the Observer Reporting Server log to confirm they have completed.