Load balancer requirements

Configuration requirements for the load balancer used with a Granta MI cluster.

System reliability and tolerance to individual MI application host machine failures is achieved by running several instances of MI, allowing the system as a whole to survive a failure of a single MI host.

This arrangement requires an HTTP load balancer, whose task is to route client requests to one of these MI hosts. Ansys does not prescribe a particular load balancer. It should be possible to set up any reasonably featured load balancer, provided it fulfills the basic requirements set out below. Therefore, detailed instructions as to how to configure individual load balancer products are not provided here.

On request, Ansys can provide more detailed instructions on how Microsoft’s Application Request Routing (ARR), a simple load balancer implementation that comes with IIS, was configured for our internal testing.

As a best practice, ensure that the load balancer you choose:

  • Supports SSL Bridging, meaning that it is able to perform encryption and decryption of data transported via HTTPS.
  • Supports client affinity or session affinity (sticky sessions). This is required to enable MI Viewer session requests to be handled correctly.
  • Supports path-based routing. This is required to allow MI Data Flow to be hosted on one node only.
  • Has timeout set to 3 minutes (180 seconds).
  • Has a valid SSL certificate for MI Server to connect.

We have tested with the following load balancers:

  • Microsoft Application Request Routing (ARR)
  • NGINX Open Source
    NGINX Plus may be more suitable for customer deployments where additional capabilities including active health checks and integration with Granta MI Windows Authentication are required. See https://www.f5.com/products/nginx/nginx-plus/compare-models for more information.