Skip to main content
Skip table of contents

Choosing an Architecture for HA & DR Requirements

This section covers the following topics:

Understanding your Business Continuity Requirements

The ability of a business to resist downtime and to continue its functioning and operations normally with zero or minimum interruption is known as business continuity. The main goal is to provide zero downtime and 100% uptime. It also considers how to keep the business as a whole operating.

To achieve business continuity, a collection of services of the system environment is needed, including the software, hardware, and documentation of relevant procedures, their implementation, and regular practice. The business continuity solution must address the data, the operational environment, the applications, the application-hosting environment, and the end-user interface. All must be available to deliver a good, complete business continuity solution.

Business continuity includes High Availability (HA) and Disaster Recovery (DR). HA focuses on eliminating Single Point of Failure (SPoF) by providing a fully automated failover to a backup system. DR preserves the continuity of service after a disruptive event such as a fire or earthquake. The purpose of DR is to restore access to technological assets like data and applications. It aims to restore as much as possible in the minimum amount of time.

Availability is expressed as a percentage of uptime. The following table shows the downtime that will be allowed for a particular percentage of availability:

Availability %

Downtime in Minutes

Downtime per Year

90

52,560.00

36.5 days

99

5,256.00

4 days

99.9

525.6

8.8 hours

99.99

52.56

53 minutes

99.999

5.26

5.3 minutes

99.9999

0.53

32 seconds

Understanding Scalability requirements

Scalability refers to the ability of an application or a system to handle a massive volume of workload or expand in response to an increased demand for database access, processing, networking, or other system resources. A scalable system can handle increasing requests without adversely affecting response time and throughput. The web application is said to be scalable if, by adding more hardware resources, the application can linearly take more requests than before. There are two ways of achieving this.

  • Vertical Scaling

  • Horizontal Scaling

Vertical Scaling

The growth of computational power within one operating environment is called vertical scaling. Vertical scaling refers to adding more computing resources (CPU/RAM/DISK) to your server as on-demand. One of the most common examples of Virtual Scaling is buying expensive hardware and using it as a Virtual Machine hypervisor (VMWare ESX). However, even after using virtualization, whenever an improved performance is targeted, the risk for downtimes with it is much higher than horizontal scaling.

Horizontal Scaling

Scaling horizontally refers to adding more physical machines to your server or database. It is about adding more nodes in the cluster, reducing the responsibilities of each member node, and providing additional endpoints for client connections. Organizations prefer to scale horizontally to increase I/O concurrency and reduce the load on existing nodes.

Component wise high availability & scalability options

The below table provides high-level scalability techniques for each component. Consider talking to a professional services team to discuss scalability requirements for your deployment.

Components

Failover / Load Balancing

Vertical Scalability

Horizontal Scalability

Sectona Web Access

  • Windows Clustering

  • External Load Balancer

  • Internal Load Balancing

  • Supported

  • 1+1 for internal failover

  • 1+n for external load-balanced

Vault

  • Internal Replication & Failover

  • MS SQL Cluster

  • MS SQL Always-On

  • Supported

  • Not Applicable

Session Proxy & Web Proxy

  • Supported via multiple proxy configuration

  • Supported

  • 1+1 for failover

Jump Host

  • Supported via multiple Jump Host configurations (supported up to 32 Jump Host servers)

  • Supported

  • Supported via multiple Jump Host configurations (supported up to 32 Jump Host servers)

RDP Direct Proxy

  • Supported via multiple proxy configuration

  • Supported

  • 1+1 for failover

SSH Direct Proxy

  • Supported via multiple proxy configuration

  • Supported

  • 1+1 for failover

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.