IBM Tivoli Netcool/OMNIbus V7.2.1 IEA IBM Tivoli Netcool/OMNIbus V7.2.1 IEA Creating a failover ObjectServer Hello, and welcome to the OMNIbus IBM Education Assistance module Creating a failover ObjectServer. Guidelines for creating a failover ObjectServer Guidelines for creating a failover ObjectServer The basic architecture for a failover pair consists of: A primary and backup ObjectServer A virtually defined ObjectServer (not shown in diagram) A bidirectional gateway and a Client entity configurations Guidelines for creating a failover ObjectServer Guidelines for creating a failover ObjectServer The following actions are required to create the failover architecture: Create the backup ObjectServer Migrate the configuration from the primary to the backup ObjectServer Define interface file entities Set values within ObjectServer’s property files Create a bidirectional gateway between the primary and backup ObjectServers Modify client entities properties to point to the virtual ObjectServer Enable process control for gateway and ObjectServers The actions required to create the failover architecture are as follows: Create the backup ObjectServer Migrate the configuration from the primary to the backup ObjectServer Define interface file entities Set values within ObjectServer’s property files Create a bidirectional gateway between the primary and backup ObjectServers Modify client entities properties to point to the virtual ObjectServer Enable process control for gateway and ObjectServers The first two actions The first two actions The first two actions in setting up a failover architecture are creating a backup ObjectServer and migrating the primary ObjectServer configuration to the backup ObjectServer. These actions are addressed in the following IBM Education Assistance modules: IBM Tivoli Netcool/OMNIbus V7.2.1 Configuration Creating and starting an ObjectServer IBM Tivoli Netcool/OMNIbus V7.2.1 Configuration Using the nco_confpack utility Before continuing, you must create your BACKUP ObjectServer and migrate your PRIMARY ObjectServer configuration into the BACKUP ObjectServer. The first two actions in setting up a failover architecture are creating a backup ObjectServer and migrating the primary’s ObjectServer configuration to the backup ObjectServer. These actions are addressed in the following IBM Education Assistance modules: IBM Tivoli Netcool/OMNIbus V7.2.1 Configuration Creating and starting an ObjectServer IBM Tivoli Netcool/OMNIbus V7.2.1 ConfigurationUsing the nco_confpack utility Before continuing, you must create your BACKUP ObjectServer and migrate your PRIMARY ObjectServer configuration into the BACKUP ObjectServer. Follow the processes outlined in the two IBM Education Assistance modules. Define interface file entities Define interface file entities You must define your VIRTUAL ObjectServer and Failover gateway within the interface file. Your PRIMARY and BACKUP ObjectServers should already be defined. Launch the nco_xigen GUI using the following commands: cd $OMNIHOME/bin ./nco_xigen & Your OMNIbus interface GUI will open. You must define your VIRTUAL ObjectServer and Failover gateway within the interface file. Your PRIMARY and BACKUP ObjectServers should already be defined. Launch the nco_xigen GUI using the following commands: Change directories to $OMNIHOME/bin ./nco_xigen & Your OMNIbus interface GUI will open. Define interface file entities: virtual ObjectServer Define interface file entities: virtual ObjectServer To define your VIRTUAL ObjectServer entry within the OMNIbus interface file, first enter a name for your VIRTUAL ObjectServer. To define your VIRTUAL ObjectServer entry within the OMNIbus interface file, first enter a name for your VIRTUAL ObjectServer. Define interface file entities: virtual ObjectServer Define interface file entities: virtual ObjectServer Next, enter the port number and host information. Use the same values as your PRIMARY ObjectServer’s port and host. Click ADD and then click APPLY. Next, enter the port number and host information. Use the same values as your PRIMARY ObjectServer’s port and host. Click ADD and then click APPLY. Define interface file entities: virtual ObjectServer Define interface file entities: virtual ObjectServer After you have added the VIRTUAL ObjectServer, click the newly created VIRTUAL ObjectServer name. After you have added the VIRTUAL ObjectServer, click the name of the newly created VIRTUAL ObjectServer. Define interface file entities: virtual ObjectServer Define interface file entities: virtual ObjectServer In the port identifier, change the port number from the previously entered primary port number to the same port number as your BACKUP ObjectServer’s listening port. Additionally, change the host identifier from the primary’s host to the BACKUP ObjectServer’s host name. In the port identifier, change the port number from the previously entered primary port number to the same port number as your BACKUP ObjectServer’s listening port. Additionally, change the host identifier from the primary’s host to the BACKUP ObjectServer’s host name. Define interface file entities: virtual ObjectServer Define interface file entities: virtual ObjectServer Click ADD and APPLY. You will see your newly created BACKUP ObjectServer instance below your VIRTUAL ObjectServer identifier. Click ADD and APPLY. Observe your newly created BACKUP ObjectServer instance below your VIRTUAL ObjectServer identifier. Define interface file entities: bidirectional gateway Define interface file entities: bidirectional gateway Define a bidirectional gateway within your nco_xigen interface. As a general guideline, create your bidirectional gateway within or near your BACKUP ObjectServer host. The gateway requires a unique port number within the selected host. A gateway’s default port value is 4300. The naming convention you use in this GUI must be carried over to the naming convention you will use to create the gateway’s property file. For example, if you name the bidirectional gateway FAIL_GATE, you must use that name in the creation of your related bidirectional gateway file, discussed later. Define a bidirectional gateway within your nco_xigen interface. As a general guideline, create your bidirectional gateway within or near your BACKUP ObjectServer host. The gateway requires a unique port number within the selected host. A gateway’s default port value is 4300. The naming convention you use in this GUI must be carried over to the naming convention you will use to create the gateway’s property file. For example, if you name the bidirectional gateway FAIL_GATE, you must use that name in the creation of your related bidirectional gateway file, discussed later. ObjectServer property values ObjectServer property values The only required ObjectServer property value change is within the BACKUP ObjectServer’s property file. Navigate to the $OMNIHOME/etc directory and open the BACKUP.props file for editing. After you open the file, edit the value of BackupObjectServer from FALSE to TRUE. Use the following commands: cd $OMNIHOME/etc vi BACKUP.props Then change FALSE to TRUE: BackupObjectServer: FALSE BackupObjectserver: TRUE The only required ObjectServer property value change is within the BACKUP ObjectServer’s property file. Navigate to the $OMNIHOME.etc directory and open the BACKUP.props file for editing. After you open the file, edit the value of BackupObjectServer from FALSE to TRUE. Use the following commands: change directories to $OMNIHOME/etc and use vi to edit the BACKUP.props file. Bidirectional gateway creation Bidirectional gateway creation A key component in the failover and failback architecture is the bidirectional gateway. To create the gateway configuration, follow these steps: On the BACKUP ObjectServer’s computer (nethost), create the directory $NCHOME/omnibus/gates/FAIL_GATE. Copy all of the files in $NCHOME/omnibus/gates/objserv_bi to the $NCHOME/omnibus/gates/FAIL_GATE directory. Rename the $NCHOME/omnibus/gates/FAIL_GATE/objserv_bi.map file to FAIL_GATE.map. Edit the FAIL_GATE.map file. The fields and field order in the mapping must match the alerts.status table exactly in the PRIMARY and BACKUP ObjectServers. A key component in the failover and failback architecture is the bidirectional gateway. To create the gateway configuration, follow these steps: On the backup computer, create the directory $NCHOME/omnibus/gates/FAIL_GATE. Copy all of the files in $NCHOME/omnibus/gates/objserv_bi to the $NCHOME/omnibus/gates/FAIL_GATE directory. Rename the objserv_bi.map file to FAIL_GATE.map. Edit the FAIL_GATE.map file. The fields and field order in the mapping must match the alerts.status table exactly in the primary and backup ObjectServers. Bidirectional gateway creation Bidirectional gateway creation Observe the following example of field mappings between the PRIMARY and BACKUP ObjectServers. CREATE MAPPING StatusMap ( 'Identifier' = '@Identifier' ON INSERT ONLY, 'Node' = '@Node' ON INSERT ONLY, 'NodeAlias' = '@NodeAlias' ON INSERT ONLY, ... ... 'CustomerID' = '@CustomerID' ON INSERT ONLY, 'CustomerContact' = '@CustomerContact' ON INSERT ONLY, 'ReferenceCode' = '@ReferenceCode' ON INSERT ONLY, 'ServerName' = '@ServerName' ON INSERT ONLY, 'ServerSerial' = '@ServerSerial' ON INSERT ONLY Observe the following example of standard field and custom field mappings between the PRIMARY and BACKUP ObjectServers. Custom fields are in bold font. Bidirectional gateway creation Bidirectional gateway creation Rename the $NCHOME/omnibus/gates/FAIL_GATE/objserv_bi.props file to FAIL_GATE.props. Edit the entries in the FAIL_GATE.props file as seen in the following slide. Rename the $NCHOME/omnibus/gates/FAIL_GATE/objserv_bi.props file to FAIL_GATE.props. Edit the entries in the FAIL_GATE.props file as seen in the following slide. Common gateway properties Properties Common gateway properties: Gate.MapFile : '$OMNIHOME/etc/BI_GATE.map' Gate.StartupCmdFile : '$OMNIHOME/etc/BI_GATE.startup.cmd' Bidirectional ObjectServer gateway properties: Gate.ObjectServerA.Server : 'PRIMARY' Gate.ObjectServerA.StatusTableName : 'alerts.status' Gate.ObjectServerA.JournalTableName : 'alerts.journal' Gate.ObjectServerA.DetailsTableName : 'alerts.details' Gate.ObjectServerA.TblReplicateDefFile : '$OMNIHOME/etc/BI_GATE.objectservera.tblrep.def' Gate.ObjectServerA.Description : 'BI_GATEA' Gate.ObjectServerB.Server : 'SECONDARY' Gate.ObjectServerB.StatusTableName : 'alerts.status' Gate.ObjectServerB.DetailsTableName : 'alerts.details' Gate.ObjectServerB.JournalTableName : 'alerts.journal' Gate.ObjectServerB.TblReplicateDefFile :'$OMNIHOME/etc/BI_GATE.objectserverb.tblrep.def' Gate.ObjectServerB.Description : 'BI_GATEB' Gate.Resync.Enable : TRUE Gate.Resync.Type : ‘NORMAL’ Gate.Resync.Master : '' Use these values as a general guideline. You must define the Gate.ObjectServerA.Server with your PRIMARY ObjectServer definition used in the interface file. You must also define the Gate.ObjectServerB.Server as your previously created BACKUP ObjectServer. Bidirectional gateway creation: enable failback Bidirectional gateway creation: enable failback To enable failback, in the gateway properties file you must set the Gate.ObjectServerA.Failback property to TRUE (if ObjectServer A has a backup ObjectServer) and Gate.ObjectServerB.Failback property to TRUE (if ObjectServer B has a backup ObjectServer). When the primary ObjectServer has been detected again, the gateway automatically fails back to the primary ObjectServer. To specify the frequency with which the gateway polls the failed ObjectServer, set Gate.ObjectServerA.FailbackTimeout and Gate.ObjectServerB.FailbackTimeout. To enable failback, in the gateway properties file, you must set the Gate.ObjectServerA.Failback property to TRUE (if ObjectServer A has a backup ObjectServer) and Gate.ObjectServerB.Failback property to TRUE (if ObjectServer B has a backup ObjectServer). When the primary ObjectServer has been detected again, the gateway automatically fails back to the primary ObjectServer. To specify the frequency with which the gateway polls the failed ObjectServer, set Gate.ObjectServerA.FailbackTimeout and Gate.ObjectServerB.FailbackTimeout. Bidirectional gateway creation Bidirectional gateway creation The FAIL_GATE gateway can have a number of other properties set. The property values presented reflect a minimum set of values to make the gateway functional. Refer to the IBM Netcool/OMNIbus Probe and Gateway Guide (SC23-6387) for further details and to enable security parameters. The FAIL_GATE gateway can have a number of other properties set. The property values presented reflect a minimum set of values to make the gateway functional. Refer to the IBM Netcool/OMNIbus Probe and Gateway Guide (SC23-6387) for further details and to enable security parameters. Client property values Client property values A client is any entity that connects to an ObjectServer. The entity value changes presented next will reflect values within unidirectional gateways, probes, and desktops. A client is any entity that connects to an ObjectServer. The entity value changes presented next will reflect values within unidirectional gateways, probes, and desktops. Configuring client processes for failover Configuring client processes for failover All client processes can now connect to the virtual pair. For desktops, select the VIRTUAL server from the ObjectServer list. Gateways will have the Reader or Writer connection properties set as VIRTUAL where necessary. The most common values are: Gate.Reader.Server : ‘VIRTUAL’ Gate.Reader.Username : ‘root’ Gate.Reader.Password : ‘’ Probes must be configured in the .props file: Server : ‘PRIMARY’ ServerBackup : ‘BACKUP’ NetworkTimeout : integer value less than PollServer value PollServer : integer value AutoSAF : 1 Note: The FAIL_GATE bidirectional gateway must reference the real ObjectServers. All client processes can now connect to the virtual pair. For desktops, select the VIRTUAL server from the ObjectServer list. Gateways will have the Reader or Writer connection properties set as VIRTUAL where necessary. The most common values are: The Reader.Server The Reader.Username and The Reader.Password Probes must be configured in the .props file. You must set the Server, ServerBackup, NetworkTimeout, PollServer, and Auto store and forward values. Note that the FAIL_GATE bidirectional gateway must reference the real ObjectServers. Client property values Client property values Probes rules files might differ due to the specific nature of the different probes. However, if you point the probe away from the PRIMARY ObjectServer and to the VIRTUAL ObjectServer identifier, failover will also resolve the probes focus during a failover event. Note: The interface file on each separate host, where probes may reside, must have the definitions for the PRIMARY, BACKUP, and VIRTUAL ObjectServers. Probes rules files might differ due to the specific nature of the different probes. However, if you point the probe away from the PRIMARY ObjectServer and to the VIRTUAL ObjectServer identifier, failover will also resolve the probes focus during a failover event. Note: The interface file on each separate host, where probes may reside, must have the definitions for the PRIMARY, BACKUP, and VIRTUAL ObjectServers. Define failover in process control Define failover in process control To define the BACKUP ObjectServer and failover gateway in process control, you can use the steps outlined in the IBM Education Assistance module OMNIbus 7.2.1 Automation, process automation to launch external actions. To define the BACKUP ObjectServer and failover gateway in process control, you can use the steps outlined in the IBM Education Assistance module OMNIbus 7.2.1 Automation, process automation to launch external actions. Define failover in process control Define failover in process control You must include the following entry in the nco_pa.conf file to enable the bidirectional gateway. You must include the following entry in the nco_pa.conf file to enable the bidirectional gateway. Your definition in the nco_service can differ, depending upon your particular implementation. You might define the gateway processes to start during automation initiation. The final steps The final steps To complete the failover architecture, you must: Ensure that both the PRIMARY and BACKUP ObjectServers are operational Ensure that the FAIL_GATE gateway is operational Ensure that process control is operational in your architecture In the Netcool Foundation Administration GUI, navigate to the running process control GUI and verify that all elements are active. To test functionality, in your development environment, bring down the PRIMARY ObjectServer and ensure that your desktop, probes, and unidirectional gateways switch over to the BACKUP ObjectServer. To complete the failover architecture, you must: Ensure that both the PRIMARY and BACKUP ObjectServers are operational Ensure that the FAIL_GATE gateway is operational Ensure that process control is operational in your architecture In the Netcool Foundation Administration GUI, navigate to the running process control GUI and verify that all elements are active. This process is also described in the IBM Education Assistance module under Automation. To test functionality, in your development environment, bring down the PRIMARY ObjectServer and ensure that your desktop, probes, and unidirectional gateways switch over to the BACKUP ObjectServer. Training roadmap for Tivoli Netcool/OMNIbus Training roadmap for Tivoli Netcool/OMNIbus http://www.ibm.com/software/tivoli/education/edu_prd.html For further training, refer to the following link: http://www.ibm.com/software/tivoli/education/edu_prd.html Trademarks This concludes this module.