CitectScada 2018 R2 Clustering Scenarios

Hello,

I am hoping to get some assistance with clustering. I am trying to do some testing before fully deciding if and or how to cluster our system. We have a large alarm database and I have been told that putting our "SOE" events in their own cluster would be beneficial. 

I have done some testing and created a new cluster and added the SOE alarm records to the new cluster. The issue I have now is that the SOE digital alarm records are based on variable tags that I need to keep in the original cluster. 

Am I able to have a digital alarm in a different cluster than the variable tag its triggered off of? 

Hoping to get any help or advice possible.

Thanks,

Steve

  • Hi ,

    It is possible to link a digital alarm in ClusterX to a variable tag in ClusterY. No problem. Basically the alarm server in ClusterX will subscribe to the Variable Tag in ClusterY.

    When running the computer setup wizard, just ensure that each Server Process is connected to the relevant clusters. This is controlled by the Citect.ini parameter:
    [<ServerType>.<ClusterName>.<ServerName>]
    Clusters=<ClusterName1>,<ClusterName2>,...

    With regards to setting up a dedicated cluster, just to handle alarm (and SOE) processing, it depends. If your system size is quite large, it will start to make sense to split things up across clusters. It is usually best to keep logical areas of a system contained within their own Cluster (where possible). But it is also possible to share data across clusters. I guess it is really flexible and just depends on what will work best for you in terms of configuration and management.

    In my experience, I have found the sweet spot for the total number of alarms is 50,000 per cluster.

    Since the SOE is stored in a ClearSCADA database, there are some parameters which can be tuned to adjust the file granularity and performance of the DB. It is best to engage AVEVA Support to get help doing this. It will depend on the number of alarm tags, the rate of change, and a few other factors.

    Kind regards
    Olivier
  • Thanks for the information! I will have to update the ini file with those additions. We have roughly 90,000 alarm tags. One of the challenges is that any clients that have more than 4 monitors really start to struggle with performance. We have had to make other changes just to ensure the clients do not get overwhelmed.

    We are still on the fence with how to improve performance for these clients. As mentioned one suggestion from support was that the clients will have difficulty updating alarms with an alarm database that large and clustering is an option to reduce it . We have seen a direct correlation between alarm server performance and multi-monitor client performance. Any suggestions beyond clustering or do you believe clustering would help performance for multi-monitor clients?

    Thanks again!
    Steve
  • Interesting found about the correlation between alarm server and multi-monitor. I had the same feeling, but not sure.
    We use multimonitors with last alarms displayed in all of the pages.
    May be if we change the template to just request and show the last alarms in one of the pages and not in all of them whould help the performance of the client and also of the alarm server.
    Just an idea,as you mention the multimonitor. I don't know how the client handles the requests to the alarm server, if it joins all the requests of all the pages or if it duplicates (or quadruplicates) the requests.
    I didn't test it, if you you can test it, let us kow the results. I'm interested.

    Regards
    Nuno Ventura