Deploying Azure Load Balancer for Aptify Web or e-Business

Overview

A load balancer is a tool that can help boost the resiliency and performance of a website by routing front-end traffic to a number of backend servers. (Often called backend pools) A load balancer will direct incoming web traffic to one of the backend servers to spread out the load, thus improving performance. Should one of the backend servers be inaccessible, the load balancer will route traffic appropriately. Thus, a load balancer can improve the performance of a website but also serves as a failover redundancy option.

This guide will assist in setting up a Load Balancer in Microsoft Azure to manage traffic to the Aptify Web or e-Business websites. It is possible to use an Azure Load Balancer without the web servers and database servers being located in Azure. An Azure Load Balancer can employ as few as two backend web servers to balance but can be expanded to as many as needed for the business scenario.

This documentation will outline the path and process to set up e-Business Classic (HTTP traffic) as well as Aptify Web (HTTPS traffic) though similar methods can be followed to set up an Azure Load Balancer for any other website, such as e-Business 6.

Two important considerations when setting up load balancing:

Public Availability

The examples in this documentation will involve setting up a load balancer for both e-Business Classic and Aptify Web, assuming both websites are intended to be accessible over the public internet. It is possible to set up load balancers for a non-public website, such as if Aptify Web is only accessible on the intranet. However, the load balancer will need to be able to talk to the corresponding backend web servers.

Session Persistence (aka Sticky Sessions)

When setting up a load-balanced environment, there are multiple ways to handle user sessions. The examples in this documentation will use session persistence, also called sticky sessions as that is currently required by both Aptify Web products. Future versions of the product will eliminate this requirement and the documentation will be updated accordingly. e-Business Classic and e-Business 6 web user authentication does not require the use of sticky sessions.

Session persistence means that a user's session will remain on the specific backend web server for as long as that session exists. If a web user logs in to purchase a product from the cart, the load balancer will assign them a specific backend web server or backend pool for the login step. With session persistence, the load balancer will keep that user on that specific backend pool for as long as they are on the website.

If that backend pool fails, restarts, or is inaccessible mid-session, the load balancer will move them to another available backend pool. Since their session information was on the other server, they will be required to log in again, and anything saved in the session will be new. Anything saved in the database server (for example, Saved Cart) should behave normally.

Future versions of these products will allow for the session state to be written somewhere other than in the specific backend pool, so in the event of a user being moved to a different backend pool, that new server could grab the session state as is.

Prerequisites

This guide assumes that all the infrastructure except the Load Balancer has already been set up. You should have:

  • A database server running Aptify and/or e-Business and your CMS
  • At least two web servers running Aptify Web or e-Business connected to your Database Server
    • These web servers must be running the website using the URL that will be used by the load balancer
      • For example, if we are load balancing www.ebizsite.org both websites must be set up to use that URL in IIS, web.config, and any other location where the URL is specified
    • These web servers need to be accessible to the load balancer, but should need not be publicly accessible by themselves- this can be changed after the load balancer is confirmed working
  • A certificate for the URL/domain you intend to use with the load balancer

Set up Instructions

Adding an Application Gateway

Azure has a number of load balancing tools. In these instructions, we will be using the Application Gateway tool. This section will set up an initial HTTP or HTTPS load-balanced environment. However, almost all of the resources, rules, and other items set up in these processes can be modified after the creation of the Application Gateway, so if you make a mistake, need to add more servers to your backend pool, or need to add another routing rule, those can all be done after the initial setup as well.

In Production scenarios, it is recommended to have separate Application Gateways for different websites such as Aptify Web and e-Business. In Test/Dev scenarios, multiple websites can share a single Application Gateway if needed.

On the Azure Portal, select Create a resource

Search for Application Gateway and click Create.

Add the following information using the above screenshot as an example:

FieldValue
SubscriptionThe appropriate subscription for these environments
Resource GroupIf the webserver resources are in Azure, select the same group
Application Gateway NameA clear name for your load balancer
RegionThe appropriate region based on your Azure resources, if applicable
Tier

Select Standard V2 if this setup is for Aptify Web. Upcoming Aptify Web product versions will support a WAF. Note, it is not recommended to pick a Basic SKU except for dev/test purposes as Microsoft does not guarantee uptime of those resources during maintenance windows.

If it is for e-Business Classic, you can select WAF however it is recommended to select Standard V2 to start, confirm functionality, then change the tier to a WAF later.

Enable AutoscalingIt is recommended to set this to Yes. See https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-autoscaling-zone-redundant for more information.
Minimum instance count0
Maximum instance countYou may set this to however many Application Gateway instances you may need. See https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-autoscaling-zone-redundant for more information.
Availability ZoneIf you have Azure resources set up across Availability Zones, select the corresponding zone. Otherwise, you can leave this as none.
HTTP2Disabled
Virtual Network

Select the Virtual Network that your Web Servers are on, or, create a new one if desired. If targeting Azure resources like Virtual Machines, App Services, or Virtual Machine Scaling Sets (VMSS), the Application Gateway must be in the same resource group, Virtual Network, and region.

Your Virtual Network and subnet can only have one Application Gateway. While it is recommended to set up Aptify Web, e-Business, and other websites with their own Application Gateways, one can serve multiple protocols. (This can be used for dev/testing purposes)

Click Next to go to Frontends.

Select an existing Public IP address for your Application Gateway, or create a new one. If creating a new one, specify the appropriate DNS name.

This will be the public IP address that your website DNS name will later be mapped to, as all web traffic should first be hitting the load balancer. Once everything has been created and is working, ensure the DNS entry for your website points to this IP address.

Adding Backend Pools

Select Next to proceed to Backends. You will need at least one backend pool to create your Application Gateway- each backend pool corresponds with a server, Virtual Machine, or other backend resource. If we are load-balancing an e-Business Classic site with two web servers behind the load balancer, we would need two backend pools.

You will need to create at least one backend pool for your Application Gateway and those pools have contain multiple resources. If those resources are not yet available, you can click Yes for Add Backend pool without targets to create the backend pool without yet specifying a target.

If you have your backend pools ready, select No and specify the backend pool target. Azure allows you to target the following:

  • IP address or FQDN- you can target an existing IP address or website domain with this, particularly if your load balance setup includes some servers on-premise, and some in other locations
  • Virtual machine
  • App Service
  • Virtual Machine Scaling Sets (VMSS)

The last 3 items require those Azure resources to be in the same Virtual Network, Region, and Resource Group as the Application Gateway. If you do not see your resource listed, you may need to either change your Application Gateway settings or move your target resource into the right region or virtual network.

If you do not see them, it may be easiest to add these backend pools without targets, make the appropriate changes to the resource, and then change the backend pool later.

Your backend pool can and should target multiple resources. You should specify all the backend web servers that will be used by this load balancer here.

You will want your one backend pool to contain all the backend servers that will be supporting the load balancer. While you can have multiple backend pools, that is usually unnecessary for this process.

You can name them after the target server name, or your own naming convention. You can add, delete, or modify these backend pools later. When you have completed this step, select Next to go to Configuration.

Adding Routing Rules

The basics of the new application gateway are set up; it has an IP address, and it knows where to target for backend pools. This step is where you define how and when to route web traffic to those backend pools. This is done by creating a series of routing rules, which connect HTTP settings, listeners, and backends. You will set each of these up in this section.

The routing rule will determine how to route traffic from your front end to the backend pools. You will define HTTP settings and listeners- these will tell the Load Balancer that traffic going to your front-end using HTTPS (port 443) should trigger your routing rule, which will push traffic to your designated backend.

Click Add a routing rule to set up a new one.

For HTTP traffic, enter the following information:

FieldValue
Rule NameA descriptive name for what this rule is doing- for example, EbizClassicTraffic, EbizHTTPStraffic, or AptifyWebTraffic
Listener Name

A descriptive name for what this rule is listening for, for example, EbizClassicListener, EbizHTTPListener, or AptifyWebListener.

Note: this name cannot be changed when created

Frontend IPThe IP address you plan to listen for this rule on, it should be the same public IP you selected previously for your Application Gateway.
Protocol

Select whether this is an HTTP or HTTPS rule. e-Business Classic may use HTTP, whereas Aptify Web, e-Business 6, and most sites should be using HTTPS.

If there are HTTP and HTTPS URLs for e-Business Classic, you will want two routing rules, one for HTTP, one for HTTPS.

PortThis will default to Port 80 for HTTP traffic, and 443 for HTTPS traffic. If your backend sites use different ports, change this value.
Listener typeIf you are only hosting one website behind this Application Gateway, leave it set to Basic. If you are setting up multiple, change it to multi-site.
Error Page URLYou can select Yes here to optionally specify URLs to redirect to for 502 Bad Gateway and 403 Forbidden HTTP error codes


For HTTPS traffic, selecting the HTTPS protocol will open up a few more fields. You will need to either upload the SSL certificate for the Load Balancer, or if you have a certificate in Azure's Key Vault, select it. Enter in the password for the certificate. This should be the valid, signed certificate for the website/domain URL for this Load Balancer- it may be the same certificate used by the backend IIS web servers, depending on your setup.

When completed with the Listener sections, click Backend targets tab.

Your target type will likely be the backend pool that you have previously set up. Leave the target type set to backend pool, and pick your backend pool as the target.

Under HTTP settings, you will likely need to create a new one. Click Add New.

Add an HTTP setting

HTTP settings will connect HTTP traffic to your listener and routing rule. Enter in the following information for an HTTP (non-secure) website:

FieldValue
HTTP settings nameName for this setting, something like EbizClassicHTTPTraffic, or EbizClassicSecureTraffic if using HTTPS.
Backend protocolHTTP if setting up for non-secure traffic. HTTPS information is located further below.
Backend portThis will default to Port 80 for HTTP traffic, and 443 for HTTPS traffic. If your backend sites use different ports, change this value.
Cookie-based affinitySelect Enable if using Aptify Web. For e-Business Classic and e-Business 6, it is not required. This will turn on "Session Persistence" aka Sticky Sessions as described in the Overview section
Affinity cookie nameThe name of the sticky session cookie to save in the user's browser. You can enter whatever you would like here.
Connection drainingThis can be set to disable by default.
Request time-out (seconds)

This is the number of seconds that the Load Balancer will attempt to contact the backend pools before giving a connection timeout error.

This can be left as the 20s default or can be changed based on your site's specific settings.

Override backend pathYou can leave this blank

Override with new host name

The correct option here depends on what constitutes your backend pools.

Do Not Override:

If your backend pools are all VMs running IIS, where the host name on each environment is specified in the IIS bindings, leave this set to No. Each IIS website will need the hostname in the binding for this to work.

Override:

Services like Azure App Service do not have a place to define host name. If App Services are part of your backend pools, you will want to select yes to override the host name.

Select Override with the specific domain name and enter in your website domain name. This will force all traffic to use that same common domain name.

This can also be used if you have a mix of VMs and App Services as your backend pool. In that case, you will want to override with a common domain name, and in the VM IIS Website binding, leave the host name blank.

You can also follow this method if you plan to introduce App Services but only have VMs initially. In this case, you would just leave each IIS Binding hostname blank and override with a common domain name.


If this HTTP setting is for an HTTPS/secure website like Aptify Web, e-Business 6, or many e-Business Classic sites, you will want to set the backend protocol to HTTPS. That will open a new box where you can select between using a well-known CA certificate. You should select Yes, assuming your certificate has been signed by a well-known CA authority. If you select No, you have the option to upload a different certificate.

At this point, you will have a routing rule connecting a listener to your backend targets, using the information specified in the HTTP settings section.

Click Add to add your Routing Rule, Listener, and HTTP setting. You should have one resource in the Frontends, Routing Rules, and Backend pools sections.

Upon creation of the Application Gateway, you will now have a Load Balancer using the front IP address you selected, which is distributing either HTTP or HTTPS traffic to your backend pools. Your routing rules also have specified that the Load Balancer should keep users on the same backend if possible.

Click Next to go to Tags. Add Tags to the Application Gateway per your organization's policy.

Click Next to go to Review and Create, and if all settings pass validation, click Create. It may take some time for Azure to create your Application Gateway.

Testing Your Application Gateway

Once your Application Gateway has deployed, you can test simply by going to the IP address of your load balancer. If you do not know this, you can find your Application Gateway resource in the Azure portal, and check the Frontend public IP address specified in the Overview section of your resource.

Navigate to that URL from any machine.

If the Load Balancer is set up properly and the backend pools are healthy, your site should load. You can verify session persistence is working properly by clicking the Site certificate in your browser. If your website is HTTPS and properly setup, it will look like this:


If your certificate is invalid or you are connecting to an HTTP website, it may look like this.


Select the Cookies section. If you expand the Cookies section, you should see the name of the "Affinity Cookie Name" you set up in the Add an HTTP setting section.

If connecting to the site and basic functionality is confirmed working via IP Address, try connecting using the DNS name. If the DNS mapping is pointed to the Load Balancer's IP address and the certificates are all valid, it should work.

Modifying Your Application Gateway & Common Troubleshooting Tools

Almost all of the Rules, Backend Pools, and Listeners associated with your Application Gateway can be added, deleted, or modified after the initial creation, simply by navigating to your new Application Gateway resource. This is the same location that can be useful for troubleshooting. A basic overview of the resource page is contained below as well as some common areas to look in case of troubleshooting.

Your Application Gateway resource contains a variety of useful information and resources. On the main page of the resource, it will show basic settings and data on website traffic.

On the left-hand column under the Settings & Monitoring sections, some of the most useful tools are:

Settings:

  • Configuration- allows you to change autoscaling behavior, the tier of Application Gateway, and number of instances
  • Web Application Firewall- If you changed your Application Gateway in the Configuration section to use a WAF, this tab will have settings and details specific to that firewall
  • Backend pools- this will display the backend pool(s) associated with this Application Gateway, as well as the number of backend targets and number of Rules associated with this backend
    • You can click into this backend pool to modify backend targets (add, remove, or charge target web servers)
    • Clicking into the backend pools will also link you to all associated rules with this backend
  • HTTP settings- this links to any HTTP settings associated with this Application Gateway. You can add new ones if needed, or fix existing ones that may not be working, for instance, if you need to turn on Affinity Cookies (session persistence) or change the HTTPS certificates
  • Frontend IP configurations- this links to any public or private IP address resources connected to this Application Gateway. You can add/remove these as needed, verify if the IP address has a DNS name attached, etc. It will also list how many Listeners are attached to these IP addresses
  • Listeners- this links to any listeners attached to this Application Gateway and associated rules
  • Rules- this links to any routing attached to this Application Gateway and associated listeners
  • Health Probes- a default health probe should be created with the Application Gateway, however, you can add or modify additional ones on this tab. See this page for more details: https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-probe-overview

Monitoring:

  • Metrics- this tab allows you to view a wide variety of metrics related to your Application Gateway, such as Backend Connection Time, Bytes Sent/Received, and more
  • Diagnostic Settings & Logs allow you to set up data to a collection for your Application Gateway, to assist in monitoring, troubleshooting, and more
  • Insights- this tab can give you the detailed information in a GUI format about your Application Gateway and backend pools- items such as failed requests, latency, current capacity, and throughput
  • Backend Health-if one or more of your backends is not working, this tab contains HTTP response information between the Application Gateway and the backend pools. It will tell you if your backend pools are healthy, and if not, what the status code the Application Gateway receives. 
    • This can be particularly helpful if the website works when connecting directly to the webserver but not via the Application Gateway, and/or if one backend server works fine, but the others do not
    • This can also highlight errors in HTTPS certificates and settings between the Application Gateway and backend server
  • Connection troubleshoot- this allows you to manually test connecting to one of your backend pools directly from the Azure resource
Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.