Introduction

The Halcyon Enterprise Console software currently does not have any High Availability (HA) capability. For customers who are using VMWare or HyperV, a more controllable solution would be to use the snapshot/cloning options within the Virtual Machine software to provide a near-instantaneous backup/recovery method.

This “How to…” discusses the option of setting up your Halcyon Enterprise Console to have a Warm Standby console. This would, in the event of a disaster at the primary site, require you to manually switch over to the backup site. This should take no more than a few minutes.

This is not a step-by-step set of instructions and assumes a working knowledge of Halcyon products.

It is not possible to cover all customers’ enterprise configurations. Customers may not have backup IBMi’s at another site, they may not have other servers available as backups at their backup site. So an element of common sense is required when interpreting this guidance for your site.

If required, HelpSystems professional services can be engaged to help design and implement a solution to suit your needs.

There is an assumption made that the two systems will be in two different physical datacentres.

Customers may also have:

  • HelpSystems Halcyon IBMi Software suites.
  • HelpSystems Halcyon agents for Windows, AIX, Linux or VIOS.
  • Both of the above

There are separate sections for each of these scenarios.

IBMi software is intelligent, if an alert is closed on the IBMi, it will also be closed on any console that the alert was sent to.

Windows, AIX, Linux and VIOS software is a simple agent. You cannot manage alerts on the native OS, they must all be managed from the Enterprise Console. Subsequently if alerts are sent to both primary and backup consoles, they must be closed on both manually.

However, an alert that has originated from a non-IBMi system and sent to the primary console can be forwarded to a backup console. Using this method, we can then close it on either console and it will be closed on the other.

Requirements for the Halcyon Enterprise Consoles

  • Two Physical or Virtual Servers.
  • Ideally running the same Windows OS version.
  • TCP port 15000 open bi-directionally between the two consoles.
  • The ability to “ping” between the two consoles (This is not a necessity, but enables each console to monitor the other consoles existence)
  • Enterprise Console Server installed (same version on each Server).
  • If monitoring non-IBMi systems, Network Server Suite (NSS) is also required.

Configuration of primary server (SYSTEM A)

  • Ensure the Backup Server (SYSTEM B) is listed in the device manager for the primary server.
  • Configure the ping monitor in Enterprise Server Options to check on SYSTEM B.
  • Ensure that each Console Server Options Rule that is active has an action to forward the alert to the backup console.
  • Configuration of backup server (SYSTEM B)
  • Ensure the Primary Server (SYSTEM A) is listed in the device manager for the backup server.
  • Configure the ping monitor in Enterprise Server Options to check on SYSTEM A.

Configuration of IBMi Software

  • Each Enterprise Console should be defined as a remote location.
  • Your rules and/or action schedules must have two actions, one to send to each Enterprise Console separately.
  • If either Enterprise Console is down, it does not matter as the alert will still go to the other console.

IBMi Operations

Normal operations dictate that any alert is sent to both Enterprise Consoles.

If the alert is closed on either Enterprise Console or the IBMi, it is closed everywhere.

In the event of losing either the primary or backup console, the IBMi’s will still send to the other console and normal operations can continue without intervention.

Configuration of other OS agents

  • The CCM rules on the primary server should have an action defined to send the alert to the default console only.
  • The default console is set as SYSTEM A in the CCM options on the Primary Enterprise Console Server.

  • The default console is set as SYSTEM B in the CCM options on the Backup Enterprise Console Server.
  • Therefore, no matter where we save the CCM rules from (SYSTEM A or SYSTEMB) any alerts raised will always be sent to the appropriate default system.

Other OS Operations

  • If we change an address book entry on the primary CCM console we should also change the entry on the backup CCM console.
  • Whichever server you make changes on within Device Manager, you must always “reload devices” on the Enterprise Consoles to ensure it picks up the changes.
  • If we change a device in Device Manager on the primary CCM console we should either;
    • Make that same change in Device Manager on the backup CCM.
    • Export the devices on the primary server and then import them into the backup server.
  • If we change a CCM rule on the primary CCM console we should either;
    • Make that same change on the backup CCM.
    • Export the templates on the primary server and then import them into the backup server.
  • Normal operations have the primary console as the CCM console.
  • In the event of losing the primary Enterprise Console:
    1. Immediately login to the Backup Enterprise Console server.
    2. Open the CCM console.
    3. Select all the relevant templates and apply then to the relevant machines.
    4. Click “Save settings”.
    5. The other OS machines are now sending alerts direct to the backup Enterprise Console Server, no alerts will go to the primary Enterprise Console Server (as it is broken at this time).
  • To revert back to normal operation at the primary site:
    1. Login to the Primary Enterprise Console Server.
    2. Open the CCM console.
    3. Select all the relevant templates and apply then to the relevant machines.
    4. Click “Save settings”.
    5. The machines are now sending alerts to SDC, which will be forwarded to the Backup Enterprise Console Server.

Still have questions? We can help. Submit a case to Technical Support.

Last Modified On: May 29, 2020