U2 Replication: An Overview of our Scalable and Robust High Availability Solution
Ten years ago the necessity for a true 24x7x365 environment was regarded as the exclusive right of high-end enterprise-level systems and applications. Since that time, the industry and customer requirements have moved forward, and we have all come to rely on such systems in our day-to-day lives. Consequently many of our customers' applications developed on Rocket Software's UniVerse are now required to deliver this level of availability. Prior to the release of UniVerse v11.1 this would have been achieved using a combination of hardware-assisted replication and the Transaction Logging capabilities of UniVerse.
With UniVerse v11.1, Rocket has dramatically increased UniVerse's ability to provide a highly-scalable, robust 24x7x365 environment.
How Is This Achieved in UniVerse v11.1?
11.1 includes U2 Replication, which is based upon the proven field-tested UniData Replication. The transaction logging capabilities of UniVerse can be used to complement U2 Replication, but is not a mandatory requirement for deployment.
What is U2 Replication?
U2 Replication provides an automated, scalable, robust method of delivering read-only copies of UniVerse files and their transactions from one data server to other servers, and also allows the propagation of various account level operations such as compilation and cataloguing of programs, and the creation and deletion of files between the data servers.
Available on Windows and UNIX platforms, it can operate in Real-Time, Immediate, or Deferred modes. U2 Replication also gives users the added ability to set up a standby / failover and failback relationship between servers and supports "Cross Platform" Replication, meaning that publishing and subscribing systems do not need to be on the same platform.
U2 Replication supports both account-level and file-level replication. Account-level replication is a configuration style that allows you to simply replicate all data files defined in the VOC file of a UniVerse account, and file-level replication is a configuration style where the data files to be replicated in the VOC file of a UniVerse account are individually declared.
Where Can We Use U2 Replication?
U2 Replication's primary use is as a mechanism to provide a robust, scalable Disaster Recovery (DR) / High Availability solution, and can also be used for offloading an inquiry workload. For example, it gives users the ability to have a dedicated reporting system taking the potential resource-heavy user reports away from the production system, allowing more resources for time-critical response screens.
U2 Replication can also be used for distributing data to regional centers for local processing. For example, the user can move data to regional centers for processing by that center, and you could also have the regional center publish its results back to the central server as well.
What Are Some of the Concepts Involved?
A system on which data is maintained and distributed to other systems is referred to as the publisher, and a system that receives data from a publisher is referred to as the subscriber.
Multiple subscribers can be associated with a single publisher and vice versa. U2 Replication is publisher driven; that is, the publisher pushes transactions to the subscriber.
A Replication Group is based on an account and is used to define the configuration style of that account. Each group is defined as an account-level or file-level replication and has its own set of tuneable resources. These include:
- The number of writing processes on the subscriber
- The size of the memory structures used
- The publishing and subscribing systems
- The replication mode
- The action to be taken if an error is encountered
An account can have one account-level group defined, but it may also have several file-level groups defined for it, as well. This allows for a highly scalable and tuneable configuration in terms of performance.
Account-level replication is an inclusive configuration that allows the exclusion of files. U2 Replication provides two methods of declaring files which you do not either need or want to be replicated. These can be declared on a group basis or as a general declaration to be excluded from all groups.
By default, the files on a subscribing system are read-only. This could become problematic if the subscribing server was to be used as a reporting server as, when logging in, applications may attempt to update their own logging files. In order to allow for this, files can be marked as writable on the subscriber by exception. Any updates on these files on the subscriber are not sent back to the publisher.
U2 Replication introduces new processes, memory structures and associated architectural changes in UniVerse v11.1. An overview of the U2 Replication architecture is shown in figure 1, which explains how a single replication group running normally is processed in UniVerse 11.1.
Fig. 1
The yellow boxes represent physical processes, the boxes in dark blue are memory structures, the files in light blue are physical files, and the boxes in salmon are a tool or command line interface.
How Do I Monitor U2 Replication?
Rocket is aware that many of our users will look to deploy U2 Replication with their application into their customer sites where there is little or no UniVerse DBA presence. In order to support this situation, there are several controls built into U2 Replication to aid deployment and monitoring.
U2 Replication has a "heartbeat" and an "exception action script" mechanism. When the system is idle, a "heartbeat" packet is sent approximately every four seconds between the publisher and the subscriber. If the "heartbeat"' goes unacknowledged, then replication is suspended and the 'exception action script' is sent. The "exception action script" could be used to email notification of the suspension and take a recovery action automatically. Each replication group is also configurable to take advantage of this script when an error is encountered.
To allow for an easy visual check on the status of U2 Replication there is a GUI Replication Monitor (fig. 2), which is based on a traffic-light system in order to make it very easy to understand.
Fig. 2
During normal operation the 'Sync Status' moves from green to yellow and the 'Replication Status' should remain green. It will move to yellow as a result of a DBA-initiated activity, such as suspending a replication group, and move to the red in the event of an error. This allows for an easy visual check of the overall status.
What Else Has Rocket Provided to Aid and Complement 24x7x365 in UniVerse v11.1?
UniVerse v11.1 now provides the ability to a rebuild an index while the file is in use, adding to the ability to a resize a file while it is in use. This eliminates lengthy downtime for these routine file maintenance procedures.
Along with U2 Replication Rocket also introduced External Database Access (EDA) to UniVerse v11.1. EDA can be used in conjunction with U2 Replication to transform your replicated data and consolidate it into an external data source such as SQL Server, DB2 or Oracle for use in reporting and business intelligence.
Summary
With the introduction of U2 Replication and complimenting features UniVerse v11.1 now offers a scalable, robust, feature-rich environment for a 24x7x365 operation for any size of business, with the addition of real-time interoperability with other databases.
