5. Logical Infrastructure
5.1. Deployment overview
The elements of the application architecture can be deployed in various ways. The appropriate infrastructure depends on:
• Pre-existing infrastructure: IIS servers or Databases servers
1. Security constraints
2. Business continuity and disaster recovery plan, based on application business criticality.
3. Production, Pre-production, Training, or Developments environments requirements.
4. Number of concurrent users.
The required infrastructure can go from a single server to a farm of servers.
Type | Recommend for | Comment | |
|---|---|---|---|
1 | Single Laptop | For single user or developer | For local usage |
2 | Single Server | Small deployment | For limited concurrent users with no specific IT policy constraints |
3.1 | Two Server | Medium deployment | To leverage existing IIS server |
3.2 | Two Server | Medium deployment | To leverage existing SQL server |
4 | Three Servers | Medium deployment | Most commonly seen deployment |
5 | Clusters/farms | Large Deployment | To meet the most demanding constraints |
The “Recommend for” is driven by the number of concurrent users.
Depending on customer constraints, you may need to go to number 4 or 5 deployment types to meet BCP/DRP or security constraints.
5.2. Deployment type: decision tree
Depending on your context, you may choose one or the other deployment type. This decision tree can help you decide the best option to select:
For your information, the most seen deployment, regardless of the decision tree, is the one including 3 servers. In this context customers:
• Leverage existing IIS servers to address the routing of the HTTP request
• Leverage existing SQL server to create the needed database.
• Create a dedicated server for HAS
5.3. Scaling the infrastructure
When demand for HOPEX application is increasing and you need to expand its accessibility, storage, and availability levels, you can scale vertically and horizontally.
• Scaling Vertically: to improve performance, you improve existing servers by adding more CPU, RAM and disk space.
• Scaling Horizontally: to manage fail over, manage loads of concurrent users, or improve performance, you add additional servers.
The decision to scale horizontally vs. vertically depends on several factors.
If you have followed the sizing instructions for each server (CPU+RAM) described below, the Vertical scaling will have limited impact and we recommend you scale Horizontally.
Scaling Horizontally is called Cluster deployment: please refer to the dedicated chapter “Cluster deployment” for further information.
5.4. Cluster deployment
Clustering is used for availability, scalability, and load balancing at HOPEX Application server deployment. This technique consists in using multiple servers of similar type. The HAS Servers of the cluster can be managed by the HAS console.
Servers can be added at three levels:
• For the web server: for multiple IIS instances placed behind a load balancer.
• For HAS Server: for multiple servers to manage front and back-end roles.
• For Database Server: in an active/passive mode.
5.4.1. HAS server - Node role
When creating a logical cluster, each node must define its role. The same node can implement several roles:
• Front-End: All modules of type Front-End will be run on this server.
• Back-End: All modules of type Back-End will be run on this server.
• Job: Back-End Jobs will run on this server. Particularly useful to separate heavy treatment to avoid interacting with user currently connected.
5.4.2. Scaling HAS Server
The first step is to scale the HAS Server to gain:
• Availably: ensure that there is always a server up and running
• Scalability: ensure there is enough physical resource to meet concurrent users' demand.
In this scenario you can add one, two, three… servers dedicated to HAS Server. Each server must have a set of node roles. Servers can be exclusively defined on a role or share multiple roles.
We recommend in scalability context:
• One server dedicated for Jobs
• All other servers to play both Front-End and Back-End roles
The high-level overview of such deployment can be represented by the following schema:
In cluster deployment HAS behaves as a logical cluster where:
• An “HAS” database contains configuration settings across nodes of the cluster.
• An internal load balancing mechanism ensures proper use of Back-End or Jobs Node.
• A cluster manager synchronizes modules versions across nodes.
5.4.3. Advanced availability cluster architecture
If you want to ensure each layer has high availability, then you need to duplicate all servers.
The overall architecture of such advanced scaling is described below. This schema is applicable regardless the number of chosen servers:
