OSS - Web HA - Websites without crashes during Cybers

Focus on your business, we help you maintain the technological operation without interruptions...

With OSS HA Web, your company will have everything you need to make your corporate site work smoothly at Cyber Day or Cyber Monday events,

CHILEOFFSHORE provides an architecture that is already working in many successful sites, such as La Polar or Internal Revenue Service. In this way you will no longer have to resort to "Waiting Rooms" and / or warning screens in case of error. This service provides all the necessary hardware, such as servers, communication equipment and the necessary advice so that your site remains operational, without falls and with good performance.

According to our experience, one of the most common problems is: There is no capacity for horizontal growth.

In general, this occurs in architectures with 2 servers, a Web server and another server for Database, or in architectures composed of a single server, which contain both the Web site and the Database.

Diagram 1 - Typical development architectures

This type of architecture is right for an informational site, but if your company needs to make high-volume sales and offers during the Cybers, these two architectures are not enough to meet this goal.

The first architecture (left) was used in the first version of the SII Internet Income Tax Return at the end of the year 90 and was completely out of service as soon as the Income Tax return began in a massive way..

The architecture on the right is in use in many current sites, it was even the architecture of one of our clients, the one that worked with many difficulties during the Cybers..

The solution to the previous problem is to have an architecture that allows you to grow horizontally.

Diagram 2 - Architecture that solves the saturation of the presentation layer but moves the problem to the data layer.

This architecture can solve page construction saturation problems, in other words, presentation layer problems. Depending on how your company's site is built, this architecture can work smoothly if your site's pages don't require many database queries. But if your site is built in such a way that each page requires querying the database, this architecture is not going to work properly. In summary, this architecture solves the presentation layer saturation problem, but moves the problem to the data layer.

There are several reasons that can cause database overrun:

[A] "Stadium Entrance Gate" effect: When there is a football match between two major teams, there will be a lot of people who want to enter the stadium. Therefore, a small gate can cause the "bottleneck" effect where everyone wants to enter at once but few succeed. This effect can occur in a database environment that does not have adequate control. When a system is for internal use of a company, the number of users is limited. But when you have an application open to the public web, you can not estimate how many users are going to connect and there will be a drop in the peak moments of the Cybers.


Diagram 3 - Saturation of People in an Uncontrolled Entrance ("bottleneck" effect)

[B] Repetition of operations that are not necessary..Many sites have queries to the database directly, that is, every time they go to the database they require: connect, authenticate, perform operations such as select/update/delete/insert and close connection to the database. In all these operations the actions of connection, authentication (which are quite expensive from the point of view of the database) and closing of connections are not necessary and can be saved. These extra operations are not visible when your company's site is operating with a limited number of users, but once you enter a Cyber it could quickly fail.

Diagram 4 - Classic database operations

[C] Static pages that are not static: this includes content that is supposed to be static (that never or very rarely changes) but in reality, changes quite a bit. Example, catalog of products that according to the existence of stock is displayed or not shown. In this type of catalog, there are page layouts, that for each navigation, the program will go to consult the balance of the product to the DB and then make the decision whether to show the product. It sounds reasonable enough from a business standpoint but depending on how it's implemented it's going to make a big difference. If for each navigation of each Internet user the DB will go to know the balance of each product of a catalog type page, a great demand will be generated towards the DB. One of the possible solutions is to implement a "Push" technique that implies that the DB "publishes" the balance on a regular basis on each web server, in this way it is possible to avoid massive access to the DB.

Diagram 5 - About the accesses to show catalog to Internet users

[D] Static page but abusing the database: there are developers who "abuse" the amount of use towards the database. A real example, when an Internet user authenticates against the company site, a token is generated that is a unique identification that records authentication. There are programs that validate this token every time the user changes pages while browsing the site, this does not make any sense. The correct way to use a token is when the user performs operations of the type of query or update data, only in those cases the token must be validated against the database.

Create an intermediate layer such as middleware, an ESB (Enterprise Service Bus) such as CHILEOFFSHORE's ApiEMBSwitch, switch, etc. This layer is responsible for, in case of a site of high demand, contain, control and segment traffic from the browsers of Internet users.

Diagram 6 - Correct Architecture

In this architecture, the presentation layer programs are responsible for building the pages of the site and preventing access to the database directly: They will do it through the ESB. Although in principle they do not see the benefits directly, most IT people end up accepting that ESB is the best architecture for them, because ESB separates layers in a clear way, so programmers who are responsible for building pages no longer must worry about how data is extracted from their company's database or from a service of another company. especially when extracting data from other companies. If your company is already an Enterprise-level company that has different areas, such as marketing, sales, accounting, finance, IT (IT), etc., it is no longer recommended that IT developers handle all topics. Each programmer has a certain profile in which he performs best. For example, Juan Pérez is good at building user interface, Cecilia Gonzalez is good at handling data and with a lot of database experience. Therefore, it is time to consider separating them and specializing them in the different layers. This improves overall IT performance.

ESB-SOA can be implemented 100% in SOA style - Service Oriented Architecture, services capable of answering requirements at the business level. For example, suppose a service called "EvalCredit", which evaluates the possibility of granting credit to a potential client, dependent employee type, for this it is required to know their employment situation (Previred service in Chile) and financial behavior (data provided by Equifax or Santiago Chamber of Commerce), therefore, this SOA service (EvalCredit) will be responsible for calling Previred and then calling Equifax, if this call fails, try calling the Chamber of Commerce. In this way, the EvalCredit service, by encapsulating all calls and error handling, makes them transparent to the presentation layer programs. A real example of EMBSiwtch/EMBIntegrator, is that one of the implemented services performs 60 steps that include internal calls to the company's IT system as well as calls to several external companies to deliver the result.

ESB-LocalCaché, there are certain types of services, especially services related to external providers, that are paid. This implies that your company must pay information providers such as Equifax, Previred, etc. by number of calls. Therefore, we must avoid unnecessary calls to save expenses. In certain cases, the result of some services does not change their result very often, therefore, the result of a call 10 minutes ago must be valid for a call in the current time for the same client. In this sense, ESBLocalCaché comes into action, recording the results of the calls. As an example, if calls to EvalCredit are detected for the same client, ESBLocalCaché will return the same result without making repeated calls to external companies.

In real computer life, you see programmers who "abuse" calls, simply copy-paste a block of code that makes calls, incorporating them into many different programs without considering the "over- expenditure" of company resources.

ESB allows you to control database overload. First, an ESB such as ApiEMBSwitch from CHILEOFFSHORE, has access control to databases with connection-pool implementation. This means that the extra database operations mentioned above will be eliminated:

Diagram 7 - Database Access with Connections Pool

Once the ESB system is lifted, a few predefined connections to different databases are opened, which it keeps open. In addition, a predefined number of "services" are assigned that are unique to meet a specific database need, therefore, for each data requirement, each "service" of the ESB obtains a connection from a specific database and performs an operation and then returns the connection to the connection-pool. This eliminates 3 unnecessary steps that are: connect to the database, authenticate, and close the connection. In addition, access management is improved, as in the example of "Entrance Gate of a Stadium", equivalent to putting a few stadium employees to control access in parallel and thus allow the public to enter in a controlled manner.

An ESB such as ApiEMBSwitch HA from CHILEOFFSHORE, has the ability to grow horizontally, which implies that it can easily increase the number of servers and thus increase the processing capacity without limit.

An ESB like ApiEMBSwitch HA from CHILEOFFSHORE, as the name implies, has fault tolerance. That is, if one of the ApiEMBSwitch HA servers fails, another will take complete control and thus ensure 100% uptime for your company. CHILEOFFSHORE has achieved 100% uptime of ApiEMBSwitch HA in the facilities of our clients.

CHILEOFFSHORE offers different architectures.

[A] Quick fix named "WEBHA1011 Architecture."
If the architecture of your current website is one of the two shown in diagram 1, which implies having one or two servers to meet all the needs of the Internet, both for page construction and for the management of dynamic data and also does not have enough time to make big changes to face the next Cyber, CHILEOFFSHORE proposes the "Architecture that solves saturation of presentation layer, but transfers it to the data layer" (Diagram 2).

With this alternative, depending on how your current site is built, there is a high possibility that your company does not need to make big changes and thus be able to better face the next Cyber. At CHILEOFFSHORE we help you change the architecture to:

Diagram 8 – Architecture WEBHA1011 - Balanced site with a few changes.

With this architecture, you can achieve horizontal growth without limit of the presentation layer, but you could saturate the database server depending on the way the pages of the site are built. This architecture includes at least one load balancing server, and you can optionally add another balancing server to tolerate failures automatically. Moreover, 2 or more servers for the presentation layer, allows you to grow in ability to respond to Internet browsing during the Cyber. Optionally, depending on how your current website is built, you should consider how to power the database server(s). CHILEOFFSHORE can help your company by bringing more powerful servers with very competitive prices.

[B] Complete Solution requiring modifications ("Architecture: WEBHA1012")
WEBHA1012 is designed for sites that are already on Cyber, but have "Wait", "Oops";, etc. screens. These types of sites are very likely to present saturation problems in the data layer, which is not easy to overcome and / or require major computer "surgery".

In this case, CHILEOFFSHORE proposes the WEBHA1012 solution which is an almost perfect architecture and segmentation of the data layer.

Diagram 9 - WEBHA1012 Architecture - Balanced Site with ESB and Multiple Data Centers

In this architecture, your company's site can be hosted in different data centers and thus improve site uptime. In addition, with the help of ESB (ApiEMBSwitch of CHILEOFFSHORE), the capacity of the data layer can be increased. To implement this almost perfect architecture, it requires: web servers for the presentation layer and equipment to perform load balancing of these servers, servers to host the ApiEMBSwitch HA and load balancing equipment of these, to distribute data layer load, and optionally new servers for database.

With this architecture and with the help of an ESB, your company can already grow in the data layer. Especially data segmentation requires almost no application change.

[C] Customized Solution for Your Company ("WEBHA1021 Architecture")
This alternative is for those cases where a special treatment is required for your company. CHILEOFFSHORE proposes a study on the current situation of your company's website and then propose the best solution.

✓ Architecture design flaw 1 - Presentation layer saturation.
✓ Architecture design flaw 2 - Data layer saturation
✓ Solution

Depending on the needs of your company, CHILEOFFSHORE provides several alternatives to solve your performance problems in Cyber events:

Alternative 1: Monthly equipment rental.
CHILEOFFSHORE delivers in lease mode the necessary equipment for the implementation of the architecture, this includes servers and communication equipment. This lease considers the upgrade of OS and servers, if necessary.

  • One or two active/standby load balancing servers (with two servers), HP Proliant DL360 G5 or G7, 2x4 8 Cores, 16GB RAM, 4x72 GB Raid 5
  • Two or more web page servers hosting Apache HTTPD or NGINX, HP Proliant DL360 G5 or G7, 2x4 8 cores, 4x8 32 GB RAM, 4x146 GB HDD Raid 5
  • One or more servers for Database, which can be HP Proliant DL580 G5, 4x6 24 cores, 128GB, 16x146 1.8TB HDD Raid 5, PostgreSQL, MySQL, Oracle.

    Alternative 2. Full service with Data Center (DC) housing in CHILEOFFSHORE, this includes:

  • 100Mbps Internet link (by GTD).
  • Cisco 2900 series communications equipment.
  • Two servers to perform load balancing, active / standby, Linux CentOS 6.9, HPProliant DL360 server, minimum 8 Cores, 16GB memory, 180GB HDD.
  • Servers to place both static and dynamic site content, Linux CentOS 6.9, minimum 2 servers. Server detail is defined according to the need of each client.
  • Servers for B.D. which can be MySQL, Postgresql, Oracle, etc. Minimum one server. Server detail is defined according to the need of each client.
  • Optionally one or two servers to host ESB (ApiEMBSwitch of CHILEOFFSHORE).
  • Optionally one or two servers to perform load balancing of the ESB (ApiEMBSwitch of CHILEOFFSHORE).
  • Optionally licenses and services associated with the ESB (ApiEMBSwitch of CHILEOFFSHORE).
  • Infrastructure to host these computers.
  • Architectural consultancy.
  • Site operation monitoring service.

    Full service with third-party Data Center (DC) housing such as SONDA, Entel, or DC of your company, in this case CHILEOFFSHORE provides:

  • Two servers to perform load balancing, active / standby, Linux CentOS.
  • Servers to place both static and dynamic site content, Linux CentOS, minimum 2 servers.
  • Servers for B.D. which can be MySQL, Postgresql, Oracle, etc. Minimum one server. Server detail is defined according to the need of each client.
  • Optionally one or two servers to host ESB (ApiEMBSwitch of CHILEOFFSHORE).
  • Optionally one or two servers to perform load balancing of the ESB (ApiEMBSwitch of CHILEOFFSHORE).
  • Optionally licenses and services associated with the ESB (ApiEMBSwitch of CHILEOFFSHORE).
  • Infrastructure to host these computers.
  • Architectural consultancy.
  • Site operation monitoring service.