Introduction to the CA XOsoft Architecture

Here we offer a little bit more in-depth discussion of how the replication aspect of CA XOsoft Replication and CA XOsoft High Availability work. As a point of reference, you may want to also review these sections of our website:

Fundamental Concepts of the CA XOsoft Architecture

There are three key concepts around which the CA XOsoft architecture is built: master servers, replica servers, and scenarios.

Master and Replica Servers

CA XOsoft Replication and CA XOsoft High Availability (formerly CA XOsoft WANSyncHA) works in an active-passive configuration: there is always one application or file server where clients may actively change data and one or more secondary servers that only receive changes to the data. This active server is called the master server and the set of machines that only receive changes are called replica servers.

The terms active and passive can have slightly different meanings, depending on the specific kind of application server being protected, but the key point is that the data on a replica server cannot be changed in any way except through changes replicated from the master server.

For a file server, the distinction is straightforward: clients may both read and write files on the master server, but are restricted to read-only access replica servers. For this reason, CA XOsoft Content Distribution (formerly CA XOsoft WANSyncCD) is an effective solution for distributing all kinds of reference data across an enterprise or to distributed external sites, from sales materials, product price lists and policy documents to multimedia presentations.

In the case of database applications, including Oracle, Microsoft SQL Server, and Microsoft Exchange, any usage of the application (including simply starting it up) causes the underlying database data to be modified. For this kind of application, the replica servers must be truly passive: running the application on any server except the master is simply not allowed, unless failover has occurred or the application is being tested using the CA XOsoft Assured Recovery technology.

At any given time, then, end users are working on the master server, using the application there or accessing and changing files. These changes are captured in real time and transferred, or replicated, to one or more replica servers so that all the replica servers contain an exact copy of the data on the master. As the data on the master changes, the sets of data on all the replicas change in exactly the same way, byte for byte. Unless specifically configured otherwise, changes are replicated as they occur, not after the file has been closed. This distinguishes CA XOsoft Replication from some products that transfer entire files, or transfer changes only after a file is closed, or transfer changes only on a scheduled basis.

Scenarios

The scenario is the fundamental basis for managing the operation of the system. A scenario is simply a structure that describes:

A CA XOsoft Replication scenario always includes at least one master and one replica, but it may also include one master and an entire hierarchy of replicas either chained or configured in a tree structure. In addition, multiple independent scenarios may run on a single server, although in most cases the files and directories included in different scenarios must be disjoint.

The Three Components of the CA XOsoft Replication System

Every capability of CA XOsoft Replication, CA XOsoft High Availability and CA XOsoft Assured Recovery is realized through the three fundamental components of the CA XOsoft Replication system: XOFS, the CA XOsoft Engine, and the CA XOsoft Replication Manager.

XOFS — Capturing Changes on the Production Server

The first component is CA XOsoft's file system filter driver, XOFS. This is the part of the system that runs on the master server and captures changes occurring in any of the root directories as they happen. These changes are then passed to the CA XOsoft engine for further handling. XOFS does not run on the replica system as part of normal replication, although it is involved in CA XOsoft Assured Recovery.

The CA XOsoft Engine — The Heart of the System

The CA XOsoft engine runs as a Windows service or Unix daemon on every machine that participates in a scenario. On the master, it accepts the data that has been captured by XOFS and sends it to any replica servers registered as directly linked to the master in that scenario. On the replica, the engine receives the data from the master or from an upstream replica, prepares rewind journals if configured to do so, and applies the changes to the local copy of the data. If additional replicas are registered downstream, it also passes on a copy of the file system operations.

The CA XOsoft engine is also the component responsible for monitoring the operation of the scenario, monitoring the individual servers involved, carrying out failover or failback operations, and reporting. It is the agent that communicates directly with any management applications to support administration of the system.

The CA XOsoft Replication Manager — Controlling the System

Finally, there are a number of management applications that are used by administrators to monitor and manage servers participating in CA XOsoft Replication scenarios, as well as to create and configure those scenarios. These applications include the CA XOsoft Replication Manager GUI, a read-only web-browser-based GUI, and a command-line interface. CA XOsoft Replication managers can run on any Windows machine that has TCP/IP access to the servers being managed, and a single manager can work with all the scenarios running across an entire enterprise.

Next topic: The Architecture of Replication