Solution Overview

This solution has the liberty of flexibility, scalability and can be seamlessly bridges real-world, virtual and wireless payment channels to enable banks to add their online payment system very easily with a minimum effort. It is designed with a Multi Channel Architecture approach which means that it can be interfaced to different kind of delivery channels, different types of legacy systems, different types of local networks and different types of local and international card associations.

Infrastructure

Network Architecture

SOPG network architecture with disaster recovery (DR) site based on the business and technical requirements. DNS has chosen the “Active and Passive”  architecture. Overall, there will be 3 different sites, making up the entire SOPG disaster recovery design. Savar will be the production SOPG site, Banani 1 will be the DR site and Banani 2 will be the content manage (CM) site. The primary SOPG server will be in Savar. The backup SOPG server will also be in Savar, while the DR SOPG server is in Banani 1. All three SOPG servers will have Oracle database installed and running in their individual server internal hard disk. The IST database on the primary SOPG will be replicated to the backup and DR SOPG databases, using Oracle replication. At the DR site, there is also a test SOPG server, with its standalone database. The primary HSM will be connected to the primary SOPG. The secondary HSM is connected to the DR SOPG. In order for these SOPG serve to switch over to the backup/DR sites to continue processing transactions, some files would need to be shared among them. NFS server will be used for this purpose, to share those directories. There will be 2 NFS servers, a primary and a secondary NFS server will be mirrored to the secondary NFS server. The production, backup and DR SOPG will be connected to the NFS server.

Banani 2 will have the content manager (CM) and will be the primary point connected to the member banks. CM will be the key hardware to determine the primary SOPG server is down and automatically re-route transactions to the secondary SOPG (DR). All three sites will be connected through Fiber and will have backup lines of another fiber or microwave link in ring concept. Backup CM will be in Savar and member bank will have a separate connection with this too for fault tolerance.

 

High Availability

High availability is implemented to reduce the downtime during failure of the system. It provides system availability and continuous business operations in the event of a primary system failure. It provides continuity and recoverability by means of a configuration that includes two mirrored systems, one primary and one backup.

SOPG system will be installed locally on both the primary server as well as the secondary server. The applications are installed on the local hard disks of the servers. During the normal operations, SOPG are running concurrently on both the primary server and the secondary server. In order to ensure data integrity during failover, data will be replicated across the servers. Data replication allows the secondary system to control the master database after failover by maintaining database synchronization across the systems. Oracle is configured to provide data replication functionality.

As you know, failover is the transition from normal processing on the primary system to temporary processing on a mirror image of the primary system. The transition is temporary in that the original configuration is normally restored after the failure is repaired. An effective failover is the transparent transfer of message processing from the primary system to the secondary system. An objective for failover requires that, after a failure on the primary system, one of the systems acquire processing control in such a way that members are not aware of either the failure or the recovery. In the event of system failure, the failover process is initiated. Current processing on the primary server is swapped over to the secondary server. For a rapid recovery, SOPG has to be running concurrently on both the primary and secondary server. During failover, both applications are already running and need not be restarted, thus reducing the downtime.