Copperchase: Air Traffic Control Systems

Air traffic controllers have one of the most complex and stressful jobs imaginable. In today’s busy skies, a single error in directing airplanes can potentially lead to catastrophic results.

The mission of UK software vendor Copperchase is to provide these professionals with applications that facilitate decision-making. Copperchase applications manage vital data exchanges used for aircraft operations, covering distress calls, flight safety, meteorological data, emergencies and flight regularity information.

Still, the best application is useless if a server, OS or software breaks down at a critical moment. In 2004, Copperchase decided to investigate how they could ensure availability of their critical environment.

Copperchase selected Evidian’s SafeKit high-availability software. SafeKit could be added easily to their suite and requires no specialized hardware.

• The combined solution ensures 24×7 application availability
• Two redundant application servers can be located in distinct rooms to
  protect them from disasters.
• As a result, air traffic controllers know they can trust Copperchase software, eliminating one source of stress.

In practice: Copperchase with SafeKit high-availability

When deploying its solution in an airport, Copperchase installs its application suite on standard Windows servers, without shared disks:

• Both the Copperchase applications and the SafeKit software are installed on separate Windows servers.
• The Copperchase applications use SafeKit for load balancing, automatic failover and real-time file replication with zero data lost.

Copperchase deploys a SafeKit multi-modules cluster and mixes farm and mirror modules

Phase 1: Normal status. The farm application module is running on both servers 1 and 2. Users of this application module are connected to a virtual IP address with automatic network load balancing of user’s connections between both servers.

The mirror application module runs only on server 1. Clients to this application module are automatically connected to server 1 thanks to another primary-secondary virtual IP address. SafeKit replicates on server 2, in real time over the network, the files opened by the application. Only the modifications made by the application are replicated, thereby limiting the traffic.

There are no prerequisites in terms of server organization. For example, the files may be on an internal RAID5 disk on server 1 and on a simple disk on server 2.

Thanks to the synchronous replication of write operations on both servers, no data is lost in case of failure. Therefore, any set of data committed by a transactional application is stored on the secondary server. (This possibility is not offered by products that implement asynchronous replication).

Phase 2: Switchover in case of failure. If server 1 fails, SafeKit ensures switchover to server 2 of both farm and mirror modules. Switchover timeout is equal to the failure detection timeout (30 seconds by default) plus the application restart time. (There is no timeout for returning or recovering the file system on the secondary server, as is the case with shared disk or disk replication solutions).

Phase 3: Failure recovery. When server 1 is restarted, SafeKit restart the load balancing of the farm application module.

And SafeKit re-synchronizes the files of the mirror application module. Only the files modified on server 2 when server 1    was    inactive    are    resynchronized.    Server 1    is resynchronized without stopping the mirror application module on server 2.
After this re-synchronization, the system is again highly available. The files are again in mirror mode; the only difference is that the mirror application module runs on server 2, with server 1 as backup.

If the administrator wants his or her application to rather run on server 1, he or she makes the switchover manually, with a simple mouse click, or automatically.