Migrate to HPE NonStop for Higher Availability

Copy link to clipboard
Email link
Print

Figure 1 — Original Architecture

Situation

A large Japanese e-commerce company provides 24×7 shopping on a high-volume Java* cell phone application hosted by a four-node Oracle RAC in a Linux cluster (Figure 1). Oracle was used for the authorization system of a new digital money service with 300 tables.

Problem

Scalability: An influx of new customers and their high volume of transactions created an Oracle RAC bottleneck. Users periodically experienced unacceptable wait times as a result.
Availability: 90% of the end users experienced a system outage at least once per year.
Recovery times: 25% of the end users experienced an outage lasting 10 hours or more. In some cases, the outage lasted more than 24 hours.

More Backstory

The company performed several proof-of-concepts (POCs). The previously used alternatives posed significant migration challenges.
The company approached Hewlett Packard Enterprise (HPE) for alternatives.
HPE introduced the NonStop X NS7 using the SQL/MX database.
The company performed an extensive POC: Java app requirements tested on the NS7 with SQL/MX, proving the NonStop could satisfy the customer’s scalability, availability, and recovery time requirements.
The company decided to switch the application and database to the NonStop solution.
The company needed a zero downtime migration (ZDM) approach.
1. Since e-commerce is 24×7, the company’s end users could not experience an outage.
2. There were no resources remaining on the Oracle RAC cluster to run additional processes.
3. The customer demanded a safe, tested, and risk-free cut-over sequence, proving the solution was “known-working” before the actual cut-over occurred.

HPE decided to use HPE Shadowbase software to satisfy the ZDM requirements, and enlisted Gravic to assist.

Solution

HPE Integrity NonStop X NS7s with SQL/MX
HPE Shadowbase Zero Downtime Migration
RDF for disaster recovery on the NonStop systems (the decision to use RDF pre-dated its status change to mature, when HPE Shadowbase software was subsequently selected by HPE as its strategic go-forward replication solution)
SQLWays from Ispirer (for schema, SQL statements, stored procedures, and initial load support)

In the original architecture, the provider used a custom tool to perform monthly batch backups from the production to the Cold DR system.

To Facilitate the Migration

A. It started capturing the production database changes with HPE Shadowbase software to an interim staging database.

B. It performed its normal monthly backup from the old production environment to the Cold DR site.

C. It used Ispirer for the initial load of the data from the Cold DR site to the new production environment.

D. It then started HPE Shadowbase replication of the change data from the staging database to the new production environment.

E. For subsequent synchronization of the data between the systems, the customer relied on HPE Shadowbase Log Source for Oracle to continue to read the Oracle logs from the old production environment to push the database change data to the staging database server. It then replayed the changes from there to the new production environment.

F. During the project, HPE Shadowbase software was installed on the old production environment (to capture the database changes), the intermediate Linux staging database server (to store and forward the database changes), and the new NonStop production environment (to apply the database changes into the new production database).

Note: When it came time to redeploy the payments application on NonStop X, HPE worked with the customer to convert all SQL statements using SQLWays from Ispirer – a company that specializes in providing tools to better facilitate database migrations converting database schema (DDL), data and server-side business logic from Oracle.

According to HPE, “After completing the data replication, the customer migrated the online application from old Oracle systems to new NonStop SQL in 15 minutes.”

Original Architecture

Step 1: Set up the NS7s and Staging Database

Step 2: Copy the Production Database Changes to the Staging Database

Step 3: Export the Data from the COLD DR System and Load the Data into the New Production Database

Step 4: Copy the Change Data from the Staging Database to the New Production Database for Synchronization

Step 5: Migrate the Users to the New Production System, Preserving the Old Environment (in Case of Fail-back)

Final Architecture

Outcomes

Figure 2 — Final Architecture

The company achieved a reliable and scalable e-commerce application (Figure 2).
Risk-free cut-over: HPE NonStop was thoroughly tested and verified, proving reliability and scalability of the new enterprise database before the migration process. The migration process provided minimal application downtime that the users did not notice, and no risk since the new environment was verified before the migration.
The company can concentrate on business development, new features, and functions instead of constantly reacting to system scaling and availability issues.
HPE attained a new customer reference account for migrating to NonStop from another platform, especially where the resulting implementation takes full advantage of NonStop SQL/MX.

HPE Shadowbase Products of Interest

HPE Shadowbase Basic Replication Software 1-8 core or 9+ core (WSA49V6T1/T2)
HPE NonStop Shadowbase Basic Replication Software (BE441AC/QSA49V6)