Guidelines and best practices for High Availability and Fault Tolerance for an OpenEdge Application. 
Best practices for High Availability OE application.
High Availability and Fault Tolerance for an OpenEdge Application. 
Guildelines for OpenEdge Application High Availability

This is a general guidelines and best practices for PASOE, although server configuration, settings and properties differ based on the specific use case and server architecture used by the customer.

High Availability and Fault Tolerance for an OpenEdge Application.
Having a highly available and fault tolerant application using OpenEdge is matter of having several components in the architecture, having the ability to scale according to changing requirements and loads, and having replicated sets of components when parts of the application crashes. This type of replication of components and scaling abilities works best in a cloud or virtual environment where these tools are common and well supported. But this can be achieved on internal hardware with more work. 
There are several required components:

• Load Balancer – not an OpenEdge product, always 3rd party
  • including a component health check
  • including a scaling features
• Progress Application Server for OpenEdge (a.k.a. PASOE)
• OpenEdge Database Replication (and possibly Replication Plus)
• Monitoring System – can be OpenEdge Management or a 3rd party tool

This document is meant to explain the necessary components, why and how they should be used, it may vary from different architectures for high available and fault tolerant application.

Load Balancer
The full featured load balancer is a required part of any highly available and fault tolerant environment. This is not an OpenEdge product, so finding the correct load balancer with the needed features will be crucial. For testing, we used Amazon’s Web Services (AWS), the Elastic Load Balancer (ELB), with AutoScaling abilities.
There are several load balancer features that can be used:

• Forwarding client requests to multiple PASOE instances
• Load Balancer Health Check
• AutoScaling of load balanced instances

Please see the document 24X7-HighAvailabitily.docx for more detailed content for the the topics below.

PASOE Instances
PASOE was designed specifically for running on the web, in a Cloud, and being highly available. PASOE instances are self-contained, easy to deploy, and accessible via HTTP. This means PASOE is perfect for working in load balanced architectures. PASOE instances can run just one or different applications. This allows for a single or multi-application to use all the machine’s resources. This would protect against other applications from negatively affecting the performance of  the PASOE instance.

A single PASOE instance can host many applications. This allows for easier deployment and management while still giving separate PROPATHs, database connections parameters, and security configurations. Because of PASOE being self-contained, creating instances and upgrading with a load balancer is very easy to manage.
This can also help with database failure and rollover to a replication database. Again, having PASOE instance ready to deploy with the new database connection parameters and cycling out the old would make a very quick and easy to manage recovery process.

Connecting to Databases via Network (and not shared memory)
Allows the database to continue running even if any client disconnects while still holding a latch or resource in the database. 
This also allows for quickly scaling up PASOE instances without having to create a larger database machine to handle the extra processing.
Removes other applications and processes from the database machine so they don’t adversely affect the performance of the database.
Note: moving to 12.2 should increase the network performance to the database.

Database with Replication
Using Database replication is the best way to make the application highly available and fault tolerant. If for any reason the production database, database machine, or network becomes unavailable the transition to the replicated database can be quickly done.
If running multiple copies of replicated target databases, if the source goes down, a target will transition to source and there will still be a target database.
If  Replication Plus is on, the target database can be used as READ-ONLY databases, taking that work off of the source database.

Monitoring
To have a truly highly available and fault-tolerant application, monitoring is key and should be done constantly with a system of alerts if problems may be imminent. Monitoring the Application environment allows possible problems to be checked before they happen, otherwise, administrators can only react to clients complaining of problems and outages, instead of being proactive. Monitoring includes the machines in the application architecture.  Machines should be monitored for performance and health (CPU, Memory, SWAP, Disk space, Disk I/O) and errors in system logs. The network should be monitored for collisions and other performance issues, not just from the outside but between machines internally.

PASOE instances should be monitored for errors, memory leaks, and performance. There is a multitude of monitoring values for PASOE using REST API or JMX beans. New in PASOE 12.0 the HealthScanner can monitor as whole PASOE instance health and works with a load balancer’s health check.
Database should be monitored for performance, replication performance, and overall health. Logs should be monitored for errors and warnings.

OpenEdge Management can monitor, alert, and trend almost every facet of your application architecture. OpenEdge Management can easily be extended to do even more monitoring and take corrective action when an alert occurs:

Access the Management Console documentation on Progress Documentation HUB:
https://docs.progress.com/bundle/openedge-management-introduction-122/page/Access-the-Management-Console.html
​​​​​​​
HealthScanner documentation on Progress Documentation HUB:
https://docs.progress.com/bundle/pas-for-openedge-management/page/Use-the-OpenEdge-HealthScanner.html

Summary
In summary, it takes many components to obtain true high availability and fault tolerance. Monitoring the application is vital. As is having the plan to replace defective components without downtime. The process of upgrading your application should be considered. Lastly, there are many features in OpenEdge that will help high availability and more in the future, this document did not cover these features.