Shadowbase Solutions and HPE Pathway Domains

shadowbase-solutions-and-hp-pathway-domains-perfect-togetherHPE NonStop Pathway is an application framework that is a mainstay of today’s mission-critical OLTP systems. It supports a requester (client) – server model, and delivers application scalability by distributing requester workloads across dynamic pools of application server processes (serverclasses) that in turn are spread across multiple HPE NonStop server CPUs. It also offers high levels of application availability by monitoring and automatically restarting server processes in the event of failure.

The Pathway model delivers excellent application availability for a single HPE NonStop server, providing local fault tolerance. But this model still necessitates application outages for certain planned system maintenance activities, and it offers no protection against unplanned system outages.

These limitations are addressed by Pathway domains (PDs), which allow the serverclasses to be distributed across multiple NonStop server systems. This capability improves application scalability and availability, protecting against some server failures. However, even though application availability is improved by Pathway domains, if the database being used by those applications becomes unavailable, then the application is still down.

Providing continued data availability depends upon having at least two nodes, each being capable of hosting the application database. As an application makes changes (inserts, updates, and deletes) to its local database (the source database), those changes are sent immediately over a communication channel to the target system, where they are applied to the target database, keeping the databases synchronized. The target database typically resides on another independent node that may be hundreds or even thousands of miles away. If the server with the database fails, then applications can continue to run using the surviving database. This is the role played by Shadowbase data replication, which provides all the capabilities necessary to keep multiple database copies synchronized, ensuring current data remains available in the event of any outage circumstance, planned or unplanned.

The combination of Shadowbase data replication and Pathway domains across nodes offers a powerful business continuity architecture to meet the requirements of continuous application and data availability. Working together they provide geographically dispersed application and database services. The data is made available on other nodes by Shadowbase data replication, and the application services are made available on other nodes by Pathway domains. When a node outage occurs (for whatever reason), Pathway domains automatically detects it and switches all user request traffic to the surviving node(s). They can continue processing because the data on those nodes has been synchronized with the failed node by Shadowbase data replication. Thus, all the necessary components (applications and data) are in place to maintain business services with minimal downtime. In summary, Pathway domains and Shadowbase data replication are perfect for each other – together they provide scalability and protection from any single failure for both your application services as well as your application database.

Support for Multiple Business Continuity Architectures

Pathway domains and Shadowbase data replication can be used together to great advantage in many business continuity architectures.

Active/Passive and Sizzling-Hot-Takeover (SZT) Systems

Shadowbase Active/Passive and Sizzling-Hot-Takeover (SZT) Systems

Figure 1 — Pathway Domains in A/P and SZT Modes

In this model (shown in Figure 1), a Pathway domain is configured across both the active and passive nodes, with servers up and running on both nodes (with the local database open for read/write access), users are connected to both nodes, Pathway requesters are running on both nodes, but all server requests are routed by Pathway (ACS) to servers on the active node. When an outage occurs (planned or unplanned), ACS automatically detects this and begins routing all requests to servers on the passive node, with no reconfiguration or operator intervention required. Since Shadowbase replication has been keeping the active and passive databases synchronized, servers on the passive (now active) node can operate correctly using current data.

Also, the Shadowbase configuration allows the servers on the passive node to have the local database already open for read/write access, so there is no need for the servers to either be started, or switched from read-only to read/write access at takeover, which further reduces takeover times. The only difference between normal active/passive and SZT architectures is that in the former, Shadowbase architecture is configured for uni-directional replication, and in the latter, for bi-directional replication, which facilitates re-synchronizing the databases when the down system is recovered.

The benefits of this architecture are:

  • Half of the users see no outage at all; the other half are easily switched over
  • The passive application is already up and running and processing transactions
    • A known-working system minimizes risk, equaling no failover faults
  • Passive servers have the local database already open read/write, so no need to switch from r/o on takeover
  • Result is reduced takeover times (better RTO)
  • Passive system capacity better utilized for processing real work

 Active/Active Systems

Active/Active Systems Pathway Domains

Figure 2 — Pathway Domains in A/A Mode

This configuration (shown in Figure 2), differs from active/passive in that the Pathway domain weighting parameter is set to allow servers on both nodes to process transactions. The Shadowbase architecture is configured for bi-directional replication, thereby keeping both databases synchronized with changes made on either system. Data collisions may occur which will be detected and automatically resolved by Shadowbase replication (via customized processing). When an outage occurs (planned or unplanned), as for the active/passive case, ACS will automatically detect it and begin routing all requests to servers on the remaining node(s), with no reconfiguration or operator intervention required.

The benefits of this architecture include all of the benefits of active/passive plus also:

  • Lower RPO since only half the in-flight transactions are affected (versus 100% for active/passive and SZT)
  • Even more confidence in the serviceability of the backup system since it is running the entire application (including server components and database updates)
  • No latency issues with long-distance PATHSENDs or Network TMF transactions (the entire transaction can be processed locally)
  • More system headroom (scalability) to handle peak loads
  • Each active/active system has lower average utilization
  • More balanced workload distribution

Zero Downtime Migration (ZDM) and Maintaining Business Continuity Protection

The use of Pathway domains and Shadowbase data replication to avoid planned outages is as equally applicable at avoiding unplanned outages. During system maintenance or a disruptive application or database upgrade, the online workload is routed by ACS from the downed system to another system in the domain to maintain business services while the maintenance is carried out. While performing system maintenance, a common requirement is not to have business continuity protection compromised in the meantime. In a two-node architecture, while one system is offline for maintenance, a failure of the other system will bring business services to a halt, which is unacceptable for many applications.

Datacenter Network Routing for Bi

Figure 3 — Planned Downtime while Maintaining BC Protection

Companies increasingly are deploying multi-node configurations to meet this need. In such configurations, multiple systems are capable of taking over the business services located in different data centers. In a Pathway domain, there can be up to four such data centers (see Figure 3). Shadowbase bi-directional replication is used to keep all of the active databases synchronized. By having four available systems distributed across multiple data centers, planned or unplanned downtime of a system or an entire data center will always leave two systems available, thereby maintaining continued business continuity protection.

Related Solutions:
Related White Paper:
Related Article:
Related Solution Brief:
Related Information: