Skip to content
English
Sign in
Contact us
  • There are no suggestions because the search field is empty.

Configuring an External Load Balancer for a SAFR Cluster

When deploying SAFR in a cluster of 3 or more servers, its important to use an external load balancer in order to leverage the full benefits of a SAFR Cluster.  While its possible to use software load balancing available in the SAFR Primary server, a failure of the primary will result in a failure of the system until traffic is either routed to the node that is elected as the new primary server or the primary server is restored.

This article provides guidance on setting up an external load balancer for a SAFR cluster and implementing healthchecks.  It assumes the reader is familiar with and has a hardware or virtual load balancer.

There are several ports that need to be load balanced against for each node in the backend SAFR server cluster that will be setup.  Each service has both an HTTP and HTTPS listener.
 
Most of the services use /version as the healthcheck URL except for 8085/Virga, which uses /health.

  • webconsole
    • Public endpoints:
    • ALB listeners:
      • HTTPS listener on port 443
      • HTTPS listener on port 8091 (optional)
    • Target group:
      • Name: webconsole
      • Target type: instance
      • Backend protocol: HTTP
      • Backend target port: 8090
    • Health check:
      • Protocol: HTTP
      • Port: traffic-port, meaning 8090
      • Path: /signin
      • Success code: 200
  • covi
    • Public endpoint:
      • https://safrplatform.adminml.com:8081
    • ALB listener:
      • HTTPS listener on port 8081
    • Target group:
      • Name: covi
      • Target type: instance
      • Backend protocol: HTTP
      • Backend target port: 8080
    • Health check:
      • Protocol: HTTP
      • Port: traffic-port, meaning 8080
      • Path: /version
      • Success code: 200
  • events
    • Public endpoint:
      • https://safrplatform.adminml.com:8083
    • ALB listener:
      • HTTPS listener on port 8083
    • Target group:
      • Name: events
      • Target type: instance
      • Backend protocol: HTTP
      • Backend target port: 8082
    • Health check:
      • Protocol: HTTP
      • Port: traffic-port, meaning 8082
      • Path: /version
      • Success code: 200
  • virga
    • Public endpoint:
      • https://safrplatform.adminml.com:8085
    • ALB listener:
      • HTTPS listener on port 8085
    • Target group:
      • Name: virga
      • Target type: instance
      • Backend protocol: HTTP
      • Backend target port: 8084
    • Health check:
      • Protocol: HTTP
      • Port: traffic-port, meaning 8084
      • Path: /health
      • Success code: 200
  • cvos
    • Public endpoint:
      • https://safrplatform.adminml.com:8087
    • ALB listener:
      • HTTPS listener on port 8087
    • Target group:
      • Name: cvos
      • Target type: instance
      • Backend protocol: HTTP
      • Backend target port: 8086
    • Health check:
      • Protocol: HTTP
      • Port: traffic-port, meaning 8086
      • Path: /version
      • Success code: 200

We’re assuming that the load balancer be HTTPS on the ports listed above and will terminate the HTTPS session on the load balancer and host the SSL certificate.  You can then load balance the request to the backend servers over either HTTP or HTTPS ports.
 
Round robin or least connection traffic routing is fine, and stickiness/affinity for clients is not required.
 
The backend servers HTTPS ports by default host a self-signed certificate, or you can use your own certificate.