Disk IO Redundancy in CitectSCADA

 

 

 

Technical Paper

 

 

 

Presented by:

 

Sara Falamaki

 

 

Abstract

This paper presents details on Disk IO Redundancy in CitectSCADA. Redundant IO servers ensure that you can swiftly take one of your servers down for maintenance without interrupting operations.

 

 

Contacts

support@citect.com

 

 

 

 

 

Contents

Introduction
Setting up Disk Redundancy
Disk Redundancy Behaviour
How and when data is written to the disk images at runtime
Tips for Debugging Redundant Disk IO Servers

 

 

 

 

 

 

 


Introduction

 

Having redundant IO servers means that you can swiftly take one of your servers down for maintenance without interrupting operations. Upon shutting down the primary server, Citect automatically reverts all clients to the standby server, continuing operations. When the standby server is bought up again, the clients reconnect to it after it has copied the disk image from the standby server.

 

 


Setting up Disk Redundancy

 

To have redundant Disk IO servers, you should configure two IO Servers in your project using the Express Communication Wizard. Each of these has one unit which refers to the file in which DiskPLC data is stored.

 

 

After you’ve set up your IO servers and devices your units.dbf file should look something like the following:

 

 

SERVER

NAME

NUMBER

ADDR

PROTOCOL

PORT

MODE

PROTOCOLID

IOServer1

DISK_P

1

[DATA]:primary.CDK,Z:\standby.CDK

GENERIC

DISKDRV

Primary

GENERIC

IOServer2

DISK_S

1

[DATA]:standby.CDK,Z:\primary.CDK

GENERIC

DISKDRV

StandbyWrite

GENERIC

 

 

The most important field here is the address field. In the primary server (IOServer1) the local file is the primary.CDK disk image, and on the standby, the local file is the standby disk image. In this setup, the disk image location on the remote computer has been mapped to drive Z. Make sure that this location is writable by both computers, neglecting to do so will cause redundancy to not work.

 

 

It’s extremely important to NOT put a space between the paths to your two devices. If you do, you WILL get unexpected behaviour and your setup will not work correctly. Upon finding a space after the comma, Citect substitutes it for the path to your project’s USER directory, resulting in an invalid disk image path.

 

 

Make sure that you set the MODE field as per the above example.

 

 


Disk Redundancy Behaviour

 

In this document a redundant IO Server is set up with a single display client.

 

 

In the normal mode of operation, the connections in the server looks like the following diagram:

 

 

 

 

In Citect, redundant disk IO Servers maintain a copy of the disk image (device) locally, and keep both primary and standby copies updated. If the primary server goes down, the standby server takes over, and keeps the standby disk updated.

 

 

When the primary is running, the display client only communicates to it, and the Primary server sends the standby server the changes. At run time, each server only writes to its local disk image.

 

 

 

 

When the Primary is shut down, it broadcasts this to the rest of the network and as a result the display client connects to the standby server instead. The following diagram illustrates this:

 

When the primary server is bought back up again, it first checks the Standby file, and if it’s newer, copies it over. The clients then re-attach to the primary server, and the situation in the first diagram is restored.

 

 

Note that if the network connection to the primary IO Server is lost, or it crashes, control will be reverted to the standby IO Server after the [LAN]timeout period expires and the number of retries defined in [LAN]retries have happened. Depending on why the primary server became inaccessible, and how it was reconnected, the behaviour after this point may be undesirable. For example, if the primary server falls off the network, the display client connects to the standby server after giving up on reattaching to the primary, and the primary then comes back up, as the network issue is resolved, it might not broadcast its availability (it hasn’t realised anything bad has happened!), and the display client might remain connected to the standby server.

 

 

 


How and when data is written to the disk images at runtime

 

In order to maximise efficiency, data is cached in memory before being flushed to disk after a set period. This period is specified by the [DiskDrv]UpdateTime Citect.ini parameter and defaults to 5 seconds.

 

 

It is worth noting however, that disk writes are done only when the disk PLC receives a write request. If there is no write request, disk data wont be flushed. This is why no data may be written to the disk image file for times longer than that specified by UpdateTime.

 

 

A known issue with IOServer redundancy is if the primary server goes down, tag values are changed, and the primary server comes back up again all in less time than that specified in [DiskDrv]UpdateTime. In this case changes made in that period will be lost. To minimise the chance of this occurring decrease the value of [DiskDrive]UpdateTime. This will however effect CPU utilisation.

 

 

 



Tips for Debugging Redundant Disk IO Servers

 

If redundancy isn’t working as expected, there’s a number of ways to check if data is being transmitted and written to disk images. Some tools that can help you are:

 

 

  1. Filemon: Available from sysinternals lets you monitor file access by processes as they run. Run filemon on both primary and standby server, and monitor accesses, reads and writes to disk image files. Make sure the paths Citect is using to find the files are correct, and make sure there are no permission errors. You can also gain a better understanding of the sequence of events that take place when reading and writing tags, and switching from primary to secondary servers and vice-versa.
  2. The Citect kernel window: if you type page table tran in the main kernel shell, you can view the connections to various other Citect servers running on your system, and the number of sent and received packets. Use this window to rule out any connection problems and to monitor switchovers. When a display client connects to a server, you should see lots of packets sent and received. There shouldn’t be any change in the number of sent and received packets between the display client and the standby server when the primary server is running.
  3. Ethereal: Available from www.ethereal.com/ ethereal allows you to view packets transmitted between the different hosts. This can be helpful when debugging networking issues, or maintaining logs.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Disclaimer

 

Disclaimer of All Warranties 
SCHNEIDER ELECTRIC (AUSTRALIA) PTY LTD DISCLAIMS ANY AND ALL WARRANTIES WITH RESPECT TO SCHNEIDER ELECTRIC (AUSTRALIA) PTY LTD PRODUCTS AND THE RELATED DOCUMENTATION, WHETHER EXPRESS OR IMPLIED, INCLUDING SPECIFICALLY THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A GENERAL OR PARTICULAR PURPOSE. CITECTSCADA AND THE RELATED DOCUMENTATION ARE PROVIDED "AS IS," AND YOUR COMPANY UNDERSTANDS THAT IT ASSUMES ALL RISKS OF THEIR USE, QUALITY, AND PERFORMANCE.

Disclaimer of Liability 
YOUR COMPANY AGREES AND ACKNOWLEDGES THAT SCHNEIDER ELECTRIC (AUSTRALIA) PTY LTD SHALL HAVE NO LIABILITY WHATSOEVER TO YOUR COMPANY FOR ANY PROBLEMS IN OR CAUSED BY SCHNEIDER ELECTRIC (AUSTRALIA) PTY LTD PRODUCTS OR THE RELATED DOCUMENTATION, WHETHER DIRECT, INDIRECT, INCIDENTAL, SPECIAL, OR CONSEQUENTIAL (INCLUDING LOSS OF PROFITS).

 

 

 

 

 

 

 

 

 

 

 

 

 

Attachments