Multi-tier Network

OpenResty Edge can be used to construct and manage large-scale gateway clusters,

By default, Edge gateway nodes directly communicate with the origin,

The「Multi-tier Network」function is also provided to facilitate to build a tree back-to-origin network using existing Edge gateway.

To use a multi-tier network, you first need to create the back-to-origin strategy in it,

「Global Config」=>「Multi-tier Network」contains a list of all strategies. First, click New Policy

Each back-to-origin strategy in the multi-tier network needs a unique name to be distinguished from others,

for instance, input source in China, and it means that the strategy applies to scenarios where the origin is located within China.

Then, in the gateway cluster network topology, the origin sits on the left side, while a list of names of all gateway clusters is on the right side,

Yes, the back-to-origin topology in the multi-tier network is based on gateway cluster, and each cluster generally corresponding to one IDC colocation,

in the initial situation, all gateway clusters mean going back to the origin directly.

You can drag gateway clusters to modify the network topology, for example, if you drag「Tokyo」above「HongKong」,「Tokyo」will be moved behind「HongKong」,

meaning that under this strategy, the back-to-origin request from「Tokyo」will first be sent to「HongKong」, before it goes back to the real origin via「HongKong」.

You can also drag the「Backup」above「Tokyo」to the upper side of「Beijing」so that the backup of「Tokyo」will be connected to「Beijing」,

when the connection from「Tokyo」to「HongKong」fails, 「Tokyo」will try to send the back-to-origin request again to「Beijing」,

if the connection fails again,「Tokyo」will still try to send a request directly to the real origin.

If no backup is configured, it will also try to send a request directly to the real origin.

Following the same line of thought, you can also configure「NewYork」as going back to the origin via「HongKong」.

Click to save and return back to the Strategy List page where you can click on the name of strategies to continue to modify their names.

With multi-tier network strategy, you can select one to use in the Reverse Proxy Rule of an application.

In the above example, if a request arrives at the「NewYork」gateway node, it will go back to the「Source」origin via「HongKong」,

if a request gets to the「Beijing」gateway node, it will go back to the「Source」origin directly.

Also, keep in mind that different applications may use the same multi-tier network strategy and different rules of the same application may use different network strategies.

「Multi-tier Network」has the following advantages:

• Improve the connectivity from Edge gateway nodes to origin

For instance, we build a global CDN network by using OpenResty Edge to offer end users nearby access,

but there is only one origin. In this case, the network between Edge gateway nodes on the edge and the origin may be very complicated,

in the above example, the network between「NewYork」and the origin may be unstable, so our setting is making「NewYork」first go to「HongKong」and then go back to the origin via「HongKong」,

of course, we assume that the network from「NewYork」to「HongKong」performs better than usual routes,

in general, routes between different colocations of the same cloud host manufacturer will be specially maintained, so they can be considered better than normal routes

• Increase overall cache hit rate in Edge

A back-to-origin request can be cached when passing the middle node, if cache is enabled simultaneously,

in the above example, the back-to-origin request of going from「NewYork」to「HongKong」can be cached by using caching resources on「HongKong」,

and if「HongKong」can also directly serve end users, caching can be done for requests from both end users and「NewYork」.

• Reduce computing resource usage by WAF

WAF is a process featuring high CPU usage, so if cache and WAF are enabled at the same time,

with the multi-tier network model, we will execute the WAF match check process at the last tier of the network,

for the purpose of fully using edge cache to reduce WAF execution times and decreasing overall CPU computational resource usage.