Load balancing Microsoft IIS
Microsoft Internet Information Services (IIS) is a high performance, flexible web server created by Microsoft for use with Windows. In order for web sites to remain available, IT managers will need to configure IIS server load balancing. Loadbalancer.org supports Microsoft IIS with all common load balancing methods, incorporating numerous modifications and customisations to suit your requirements and can be deployed physically, virtually or in the cloud. Whatever your preference, we’ll ensure that your deployment is suited for your environment.
Example HTTPS deployment illustrating SSL termination, WAF traffic inspection and SSL re-encryption.
Protocols and load balancing methods for Microsoft IIS
|Protocol||Port||Load balancing methods|
|HTTP||80||Layer 7 SNAT (Recommended) Using Reverse Proxy mode is the easiest and most flexible load balancing method, offering advanced URL switching, cookie insertion and WAF capabilities.
Layer 4 DR Direct Routing has the advantage of being fully transparent and seriously fast but requires solving the arp problem.
Layer 4 NAT Traditional NAT mode gives easy to implement fast and transparent load balancing but usually requires a two-arm configuration (two subnets).
|HTTPS||443||All load balancing methods can be easily configured for SSL Pass-through.
This has the advantage of being fast, secure and easy to maintain. Identical SSL certificates will need to exist on each of your backend servers for pass-through security.
SSL Termination or off-loading must be used when advanced Layer 7 functionality such as cookies or URL switching is required. You can also implement SNI if you have multiple domain certificates one one public IP address. Optional re-encryption is also available between the load balancer and IIS.
|FTP||20,21||All load balancing methods can be easily configured for FTP. However the original design of FTP did not work well with firewalls so it was modified to add a special PASV (Passive) mode. If you are load balancing FTP we recommend that you configure PASV on the FTP server, or use Layer 4 NAT mode which handles the issue automatically.|
|SFTP||21||All load balancing methods can be easily configured for SFTP.|
Offering performance without limitations, the best-value hardware load balancer on the market supports any environment. Licensed for unlimited throughput, bandwidth and features, upgrading is seamless if your requirements change down the line.
How do we get the client source IP address in our web server logs?
There are several ways to answer this question with a load balancer.
- Layer 4 DR/NAT (HTTP & HTTPS): These load balancing modes are source IP address transparent by default.
- Layer 7 (HTTP): The insertion of XFF headers can be enabled for HTTP traffic. Then change the behavior in your webserver to log the XFF header.
- Layer 7 (HTTPS): You must additionally terminate the SSL and enable Proxy Protocol support. Then you can insert the XFF header to the unencrypted HTTP traffic and modify your webserver to log the XFF header.
*If all else fails then Layer 7 with two-arm TPROXY is fully transparent
My application can’t do persistence/session affinity, how can the load balancer help?
When applications are not ‘state aware’ this could result in issues with traffic mixing between hosts during the same session. Persistence can be added by the load balancer, meaning continuity can be maintained and ensure the client remains connected to the same real server.
- Layer 4: Source IP address.
- Layer 7: HTTP Cookie.
- Layer 7: Application Cookie.
- Layer 7: SSL Session ID.
- Layer 7: Source IP.
- Layer 7: HTTP Cookie and Source IP.
- Layer 7: X-Forwarded-For and Source IP (Recommended for WAF).
I have to run a legacy application which cannot support the required cipher list required by my security team. Can you help with that?
If an application cannot support a required SSL cipher list (i.e. legacy application), creating an SSL Termination VIP on the load balancer could help. This also provides a single place to manage security settings and SSL certificates. (SSL Termination is not normally advised unless explicitly necessary as it can affect scalability.)