Overview
A major international Internet Service Provider (ISP) offers email services, internet access, and other functions to millions of global customers. Several million of these customers may be logged in at any one time. Maintaining continuity of service to its customers is a mandatory requirement for the ISP.
Its rapid growth has led to capacity strains in its IT infrastructure. One such issue recently occurred in its login subsystem. When a customer logged in, his login request was sent to the ISP’s Login Request Complex, where his user profile was accessed and validated and his session established. Though comprising a large farm of redundant servers running many instances of Sybase on Linux, this login subsystem had reached the limits of its capacity. Further additions to capacity were going to be very expensive.
The ISP therefore decided to architect and build an entirely new login subsystem. It performed a series of functionality, performance, and load volume torture tests using many of the major commercially available database engines, including Sybase, Oracle, and HP NonStop's SQL/MP. The tests were run under the configuration and tuning guidance of each vendor. As the load was scaled up to the ISP's load levels, one of the competitors could not complete the tests, while another limped along under full load, unable to complete queries within the desired SLA. The clear winner was NonStop's SQL/MP, running on the HP Integrity NonStop hardware in an active/active configuration - it completed all tests satisfactorily. Not only would the single-system image presented by the active/active system make the Login Request Complex significantly more manageable, but the rapid failover time offered by the active/active system (seconds) would also ensure that the loss of a node would not be noticed by the users that it was servicing at the time of failure. Furthermore, if capacity were added in the future, only the capacity needed would be purchased, rather than twice the capacity as required by the redundant Linux/Sybase arrays.
The problem then became how to migrate from the old Login Request Complex to the new NonStop system without impacting the ISP’s customers. The goal was to perform an online migration of the application with zero (or minimal) application downtime, often referred to as Zero Downtime Migration, or ZDM. By the judicious use of the Shadowbase data replication engine from Gravic, Inc., the ISP was able to gracefully migrate all of its customers over a period of time to the new NonStop system with no interruption in service.
Please click here for the rest of the case study.
Reprinted from the "Availability Digest," 2008.