Server redundancy

[tauhien]

Some queries on system redundancy.

In zenOn, we can have dual redundant servers, 1 server as Main, the other 1 as Standby. In normal operation, the Main server will be responsible in polling the PLC. Does the Standby also polls the PLC at the same time? Or does it work like a client to the Main server?

[herberto]

Please check out following thread: http://www.copadata.com/forums/showthread.php?t=82

Imo there is a good description how Server and StandbyServer are acting.

Regards,
Herbert

[tauhien]

Thanks Herbert,

So, if i understand correctly, from the link given, in normal operation, the PLC should expect polling from both servers, Main and Standby.
For Main, in operation, it will serves all clients as well as the Standby server in terms of archives, HMI data display etc. This means all data for HMI, trending, reports etc, come from Main.
However for Standby, it's process driver will still poll the PLC, and the data is stored in a buffer. The buffer is being kept for the duration of NET_TIMEOUTMSEC. When Standby detects that Main is down, the data in this buffer will be used to fill the archive (in Standby server).

Question: During a 'failover' from Standby to Main, what happened to the clients? Are there any files being synchronized between Standby servers and clients?

[markclemens]

Normally, the clients will only connect to the server. Actually, the standby server refuses connections from clients, when the server is available.

The clients also continuously check whether the server is available. When they find that the server is unavailable, the clients will automatically connnect to the standby server. As the standby server also detected the server breakdown, it is now in the process of becoming the active server (filling the archives with values from the buffer, generating alarms etc.) and in this process also accepting client connections.

The client will, once the standby server becomes the active server, automatically synchronize with the standby server. Normally this does not involve many files being transfered, as clients get their data (archives, alarms, CEL, etc.) from the active server and by default do not keep it local.

[janlyndon]

In relation to active server/standby operation and clients, how we are going to test that the process is working and to measure the time delay in which the standby can fully take-over and the client can connect to the active sever? Actually, i am developing a FAT procedure for redundancy testing for the SCADA project (Zenon EE) that we are about to execute. Can any body give me a hint on the proper redundant test procedure which our client will be witnessing for acceptance? Do you have any published documents for redundancy test?
Also i would like to take this oppurtunity if you also have idea for Sustained performance testing (SPT) procedure of SCADA system. This will be performed after commissioning where we are going to demonstrate the reliability and availability of Zenon SCADA system under actual scenario.

Thanks in advace.

[markclemens]

Of course possible test scenarios depend a lot on your actual network configuration, your hardware configration and your zenon configuration (how many projects, which drivers are being used, which modules are being used, whether or not a webserver is being used, (either standalone or also redundant). Also in which depth you want or need to test. Tests for zenon redundancy can be quite simple, but also can get very comprehensive.

If you have a server with a dual network card setup for pairing, you would be testing the network card redundancy when you unplug one network cable. Or the redundant network switch when you power off one switch.

If you have a server with a dual redundant power supply, you would be testing the power supply redundancy when you unplug one power cable.

As for testing the zenon redundancy, there are many different scenarios you can test. It all depends on what is required for the FAT by the customer.

One very simple test scenario, with just a minimum of checks could be:

power-off the server, check to see if the standby server recognizes the server failure, and starts up as the current server. In this process check your event log messages, check the PLC communication, check the archives in the historian, check if the client recognizes the server failure and automatically connects to the standby-server as a server, power on the server again, check if the server tries to connect to the standby server, check if the standby server correctly switches back after the server has taken over again, check data synchronisation for the time that the server was not running, check if the client automatically reconnects to the server.

If you need to develop a comprehensive test, it may be a good idea to book a workshop with a COPA-DATA consultant, to get in-depth knowledge about the workings of the zenon redundancy. How the communication works, which timeouts there are, how the driver communication works to guarantee a redundancy switch without data loss, etc. etc.