Global Upstreams

OpenResty Edge provides “Global Upstreams” which allows defining of common upstreams that are directly referenced by several different HTTP applications without having to define them all over again in different applications.

The following section describes how to configure “Global Upstreams” in Edge Admin.

First go to the page: Global Config > Global Upstreams.

As you can see above, you will find the entry for global upstreams in the left tab.

Then click on the New upstream button to start creating a new global upstream:

Enter the upstream information:

The upstream name is used to specify the name of the upstream to be created, the protocol is either HTTP or HTTPS depending on your needs, when HTTPS is chosen, you can also configure whether SSL authentication is enabled, which is enabled by default.

The health check can be configured according to here for configuration. Next, fill in the information of the upstream server, and you can set one or more upstream servers.

If you need to change the upstream properties, you can edit them by clicking on the Edit button to the right of the corresponding record in the list:

Once you have modified the properties, you can click the Save button (if you don’t want to save, click Cancel).

If an upstream is no longer required, it can be deleted by clicking on the Delete button on the right side of the corresponding record in the list:

Note that if the upstream is still in use by another application, it cannot be deleted.

Upstream health check

The upstream health check can be used to check whether the upstream services are running properly, which helps to improve the availability and stability of the system.

In OpenResty Edge, health checks are supported for both global upstream and HTTP application upstream.

To enable it, click on the “Health Check” switch when adding or editing an upstream.

In the OpenResty Edge’s upstream health check, if always check is enabled, then the upstream will be checked for availability periodically. This is not enabled by default, and will only be checked if the request is sent to the corresponding upstream. The health check protocols currently support HTTP and TCP, for HTTP services it is more common to choose the HTTP protocol. The request method can be selected as “HEAD” or “GET”. The “HTTP Request Host” and “HTTP Request URI” will determine the destination of the health check request, as well as specify the version of the HTTP protocol to be used and set the User-Agent header. The request interval is the time between two health check requests, the default is 3 seconds, when a request is sent that exceeds the timeout, the request is deemed to have failed. The default timeout is 1 second. If the request does not time out, but the response status is not in the specified status, then the request will also be ruled as failed. When the number of consecutively failed requests exceeds the unhealthy threshold, the upstream will be judged as “unhealthy”; when the number of consecutive successful requests exceeds the healthy threshold, the upstream will be judged as healthy. The last option “Report Interval” is used to configure how often the Edge Node reports the upstream status to the Edge Admin, the default is 3 seconds.

When the upstream server status is healthy:

When the upstream server status is unhealthy:

Also, we can see how the upstream server status has changed by clicking on the details button: