Solution Design Template - Amazon S3s3-ap-southeast-2.amazonaws.com/wh1.thewebconsole.com/wh/4398/... · latency, user bandwidth and concurrent sessions) ... Avoka Transaction Manager

Avoka Transact

Reference Architectures Version 4.0

Avoka Transact Architecture Reference V4.0

© 2014 Avoka Technologies Pty Ltd. Page 2 of 7

COPYRIGHT NOTICE

Copyright © 2014 - Avoka Technologies Pty Ltd.

All Rights Reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, or mechanical,

including photocopying, recording, taping, or information storage and retrieval systems - without the written permission of the publisher.

Products that are referred to in this document may be either trademarks and/or registered trademarks of

the respective owners. The publisher and the author make no claim to these trademarks.

While every precaution has been taken in the preparation of this document, the publisher and the author assume no responsibility for errors or omissions, or for damages resulting from the use of information contained in this document or from the use of programs and source code that may accompany it. In no event shall the publisher and the author be liable for any loss of profit or any other commercial damage

caused or alleged to have been caused directly or indirectly by this document.



Avoka Transact Reference Architectures

Avoka Transact supports the creation of highly available and performant solutions deployed onto on-

premise infrastructure.

This document provides Avoka Transact Reference Architectures for High Availability (HA) solutions.

Single Data Center HA Reference Architecture

The Single Data Center High Availability Reference Architecture is illustrated in the diagram below. This

deployment model has two Transact Server nodes providing a high performance and fault tolerance.

Avoka Transact uses an essentially stateless scale-out architecture enabling:

fault tolerance fail over between Transact server nodes

schedule maintenance without service interruption

scale out performance by adding additional Transact server nodes

With Avoka Transacts’ stateless architecture the only information stored in the servers memory is the

user’s authenticated session. All transaction state is stored in a high availability SQL database.



Failure Modes

Loss of Transact Server Node

If an Avoka Transact server node fails, the Load Balancer will simply redirect the user requests to the

alternative Transact server node. If the user’s transaction requires authenticated, they will be asked to

login again but other than that they will continue their transaction seamlessly.

Transaction Performance

On recommended infrastructure 2 Avoka Transact server nodes can support 50K transactions per hour (1).

Dual Data Center HA Reference Architecture

The Dual Data Center High Availability Reference Architecture is illustrated in the diagram below. This

deployment model has two active data centers each with two active Transact Server nodes.

This architecture will ensure service continuity even in the event of losing one data centers.

In this deployment architecture a Load Balancer in front of the Data Center A and Data Center B will

balance traffic between the data centers. In this architecture the front Load Balancer will need to support

sticky sessions.



Failure Modes

Loss of Data Center

If one Data Centers goes offline the front Load Balancer will direct traffic to the other Data Center.

Loss of Transact Server Node

If one of the Avoka Transact server nodes fails the Data Center Load Balancer will direct the traffic to the

other Avoka Transact server node in that Data Center.

Loss of Primary Database Server

If the Primary Database Server fails, the Secondary Database will be elected to become the Primary and

Transact Servers nodes will continue to function using the new Primary Database server.

Please note to support this deployment model requires low latency connections between the two data

centers to ensure high performance, and should include redundant networks. This deployment

architecture generally also requires a third monitoring site to mediate the election of the new Primary

Database server in the event of a failure.

Transaction Performance

On recommended infrastructure 4 Avoka Transact server nodes can support 100K transactions per hour (1).

Avoka Transact Deployment Requirements

To support these High Availability deployment architectures Avoka Transact requires:

Load Balancing Switch with sticky session support (JSESSIONID cookies)

VMware Host servers (or physical servers with CentOS 6 or Microsoft Server 2008R2-2012) for

the Avoka Transact server nodes

Virtualized Avoka Transact server nodes are deployed in separate availability ‘zones’ to

minimize single points of failure, i.e. separate physical servers, separate power supplies, etc.

SQL database with high availability support (Oracle 11g, Microsoft SQL Server 2008-2012,

Oracle MySQL 5.1-5.5)



Avoka Transact Server Node Requirements

The server requirements Avoka Transact nodes include:

Processors Intel Xeon Processors (8 Cores) with 2.4 GHz or greater clock speed

Memory 12 GB of RAM

Storage 100 GB of disk storage

Performance Caveats

(1) Performance estimates are based on:

system load testing and real world experience,

Avoka Transact deployed on the servers meeting the specified requirements,

standard Avoka Transact server configuration,

transaction using a medium size 6 page HTML form, with landing page and confirmation page

transaction flow,

transaction includes rendering a PDF receipt document,

use of a Content Distribution Network (CDN) to serve static content, and

transaction throughput not being limited by network constraints or SQL database performance.

Please note system performance will vary significantly depending upon the type of user load (network

latency, user bandwidth and concurrent sessions) and the size of the form and content rendered.

If the form transaction does not require a PDF receipt to be rendered then transaction throughput will be

substantially higher (in excess 2X).

Use of a CDN to serve cacheable static content improves transaction throughput by approximately 20 to

30%. Avoka Transact supports the Akamai, Amazon CloudFront and CacheFly CDNs.



Alternative Web Server Deployment Model

Some organizations security policies may require Apache Web Servers to be deployed onto separate

servers from the Avoka Transact server nodes.

While this is not our recommended deployment model Avoka Transact fully supports this architecture.

Please be aware this deployment model incurs additional cost and effort to commission and maintain.

Further Information

If you want to know more about Avoka Transact solution architectures, please contact sales and they can

organize a discussion with a Client Services Engineer.

Please also see the following documents for further information:

Avoka Transact Platform Support

Avoka Transaction Manager Installation Guide

Documents

Solution Design Template - Amazon S3s3-ap-southeast-2.amazonaws.com/wh1.thewebconsole.com/wh/4398/... · latency, user bandwidth and concurrent sessions) ... Avoka Transaction Manager