Shadowbase’s Business Continuity options comprise various architectures from the traditional unidirectional disaster recovery solution to full bidirectional implementations. In the unidirectional environment an active primary node is feeding a stand-by, or passive, backup system.
The bidirectional architecture allows the application to be active on all nodes in the network, processing user requests, thereby leveraging the processing capacity of each node for real application work. When building active/active systems, data collisions are an important consideration (i.e., the updating of the same data on two systems at the same time). Shadowbase can identify these data collisions, and in many cases be configured to automatically resolve them.
Support for zero-downtime system, site, application, and database migrations increases the availability of the application to the user community by totally eliminating “planned outages” of the application for upgrades.
Key business continuity characteristics of Shadowbase include:
- Dramatically improves application availability by increasing the “sparing” of major system components, such as the database. Since availability is usually expressed as a number of 9’s, as in 3 nines meaning an application is available 99.9% of the time, replicating the system/application with Shadowbase will double the number of nines - to six nines, or 99.9999% available, in this case. In availability theory, this is because replicating the system/application increases the number of “spares” in the system and decreases the number of “failure modes”. (View: Breaking the Availability Barrier for more information)
- Elimination of planned application outages when using Zero Downtime Migrations.
- Improves your Recovery Point Objective (RPO). Shadowbase’s process-to-process architecture allows for latencies under a second in asynchronous mode, thereby reducing the amount of data loss when the primary system is lost.
- Improves your Recovery Time Objective (RTO). Shadowbase allows system planners to configure for a number of High Availability configurations. These configurations include the classic disaster recovery architecture (active primary feeding a passive standby system), the “sizzling hot takeover” architecture (active primary feeding a hot standby that has all applications running), and a variety of active-active architectures that allow the application to be running and processing user requests on all systems simultaneously.
