The case for a CPA: the disaster recovery solution covers all systems, applications, and data

Software Magazine, Spring, 2002 by Jim Johnson

TRADITIONAL DISASTER RECOVERY PLANS cannot keep up with the speed of doing business in today's world. A 24-hour recovery time from a disaster would be enough to put many companies out of business. According to the participants in Standish Group's latest focus groups, most say their disaster recovery strategy is woefully inadequate, out-of-date, and provides for minimal coverage. This coverage basically includes having their legacy applications run on their mainframe or proprietary systems--very few disaster recovery plans go much deeper into the application suite. Because of the need to operate 24/7, corporations are moving away from disaster recovery to replicated data and processing. But this falls short as well. Instead, what is needed is an architectural approach to the problem: Continuous Processing Architecture (CPA).

CPA is a complete high-availability and disaster recovery solution. When fully implemented, it covers all systems, applications, and data. This contrasts with the single-system solution offered today. The CPA concept is simple to implement and maintain. CPA offers two major features: instant failure recovery and storage.

Today, most organizations employ two systems. One is the system of record; the other is a passive backup in case of failure. The backup system normally has a data mirror of the primary system. If a disaster occurs, the backup system is brought up. It takes anywhere from four to 48 hours to bring the backup installation to full operation. The other method is to back up storage on tape media, which takes much longer.

There are four types of CPA: Live-Live, Application Segmentation, Database Segmentation, and Functional Segmentation. All four CPA types work on an event-based theory.

Live-Live

All applications and data are synchronized. When an update occurs on any available resources, it is automatically propagated to all other resources that back up that type of event in real time. For example, an order is entered on System A, which has a database for orders, inventory, and accounts receivable. System A updates its database and sends a duplicate transaction to System B, which has the orders and inventory database, and to System C, which has the database for accounts receivable. Systems A, B, and C are updated almost at the same time.

If System A fails, Systems B and C carry on and send transactions to a queue for processing when System A is back online. At no time does the business process stop. A user could also update from System B or C. All resources are active or live.

There are several issues concerning Live-Live CPA. First, the transmission delays can cause the backup process to go out of synch. Therefore, in a disaster some records could be lost. Also, a person can be updating a record on System B while another person is updating the same record on System A. This can cause an inconsistent database. A Live-Live CPA approach requires frequent database reorganization.

Another problem is record deadlocks where a user cannot update a record. A more gnarly issue is a phenomenon known as a "Deadly Embrace." Here, two resource users have locked on a resource that the other needs to complete the task, but neither gives up the resource.

Conflict resolution software is needed to overcome the deficiencies in Live-Live processing.

Application Segmentation

Here, applications are split over multiple resources. Databases are linked to the application. For example, the order processing applications and the order database are on System A, while the backup database is on System B. The inventory application is on System B with the primary database. The backup database is on System A. When a user updates the order database it is done through System A. System A then sends a duplicate transaction to System B to update its order database. When a user updates the inventory it is done on System B. System B then sends a duplicate record to System A.

This works fairly well if the database can be segmented along application lines. However, if the order processing application needs to update the inventory database, conflicts arise. Conflict resolution and synchronous software are required.

Database Segmentation

Using this approach, the database is split along logical lines, In the case of the order database, it may be split into two by customer names A to K on System A and M to Z on System B. When a user updates the order on the A-to-K database it is done through System A. System A then sends a duplicate transaction to System B to update its A-to-K segment of the order database. The reverse is true for M to Z. In these methods, the order database is kept up-to-date. In ease of disaster on either System A or B, the other takes over.

This also works fairly well if the database is segmented along logical lines. However, just like application segmentation, if the order processing application needs to update the inventory database, conflicts will arise. It is nearly impossible to logically segment two databases in one application. Conflict resolution and synchronous software are required.