Path-based load balancing – Configuring Load Balancing

Path-based load balancing

Both Azure Front Door and Application Gateway support URL path-based routing. The functionality provided by this feature enables you to split traffic based on your URL path. Traffic can be split and separated to route to different backend pools by matching your path-based rules. You may choose, for instance, to serve different content types through separate backend server pools; there could be several reasons for doing so, for instance, you may want to deliver images from a slower storage set as they are not required for instant consumption, whereas your videos may be designed for live streaming. The delivery of both these resource types requires different sets of resources and configurations; if you enabled path-based routing, you could look for the /image portion of your URL and route those to the image backend pool, likewise for your videos. This enables a much more controlled and dynamic management flow for your applications. The following diagram illustrates the splitting we discussed previously:

Figure 16.1 – URL path-based routing

As you can see from the preceding diagram, traffic is routed based on its source URL type. The conventions for this are defined relative to the root path on the server, with/representing the root. In the preceding diagram, should your website domain be contoso.com, the /images/* pattern would be the equivalent of contoso.com/ images/. The wildcard represents any character after the path as part of the search term.

Top Tip

Note that the URL pattern cannot include # or ? as its character. Each pattern must start with a / character.

Session affinity

Session affinity is the ability to retain communications between the same source and destination systems for the life of the communication window established between the systems. Thismeans if user1 passes through some load balancing service to server1, all communication from user1 to the central load-balanced service would flow directly to server1 from the user. Without this, traffic would be balanced between servers and services, meaning that the second call from the user could be routed to server2 or serverx. Enable this where session integrity is required by your applications.