Sync Between Gateway & Portal
search cancel

Sync Between Gateway & Portal

book

Article ID: 270257

calendar_today

Updated On:

Products

CA API Gateway

Issue/Introduction

All the Scheduled tasks between Portal & Gateway runs only one node from each cluster. What I wanted to know is what is the impact if those are selected to run on all the nodes instead of one ?

Also will it change the Cpu & memory usage ?

 

Environment

Release : 10.1

Resolution

This is a change we would NOT recommend.  

Options for scheduled tasks are One or All. 

Using All would mean that every node in a cluster will be attempting to perform exactly the same task at ~exactly the same time.   This shouldn’t result in any data integrity issues (duplicates) but it does have potential performance issues.

The cluster wide properties and the data is shared by all the gateways in the cluster, the CWP  property portal.applicationincrement.start  is the epoch time of last sync

ALSO

The Gateway that runs the schedule task would be the cluster master.  You can check this and get the nodeID in the SSG DB then find the gateway from the cluster_info table:

mysql> select * from cluster_master\G;

*************************** 1. row ***************************

      nodeid: 7f7533ea2a54459c9b7af7206b338663

touched_time: 1689970719455

     version: 6193344

1 row in set (0.00 sec)

 

ysql> select * from cluster_info\G;

*************************** 1. row ***************************

           nodeid: 034a660c114d4f40bba527b9a0d32b84

              mac: 00:50:56:A0:4D:E4

             name: Gateway1

          address: <GW_IP>

      esm_address: <GW_IP>

multicast_address: <MA_IP>

           uptime: 1689954498702

          avgload: 0.18

  statustimestamp: 1689970929166

*************************** 2. row ***************************

           nodeid: 7f7533ea2a54459c9b7af7206b338663

              mac: 00:50:56:A0:65:36

             name: Gateway2

          address: <GW_IP>

      esm_address: <GW_IP>

multicast_address: NULL

           uptime: 1683661008790

          avgload: 0.11

  statustimestamp: 1689970928245

2 rows in set (0.00 sec)