Below is a sample guide for setting up an A10 load balancer in Layer 7 mode to load-balance two Cloudmersive Private Cloud nodes. This configuration includes an HTTP/HTTPS health check for the path /virus/status on each node, verifying both the presence of the text “Online” and the HTTP status code 200. Adjust IP addresses, ports, names, and other parameters as needed for your environment.

Overview

In this guide, we will configure:

1. Two backend servers (Cloudmersive Private Cloud nodes).
2. A Layer 7 health monitor that checks GET /virus/status for:
   • HTTP 200 OK
   • Body containing the text "Online"
3. A service group that uses the health monitor and includes the two servers.
4. A virtual server (VIP) to provide a single endpoint for traffic, which then distributes requests to the healthy nodes.

Prerequisites

1. A10 load balancer
2. Administrator access to the A10 load balancer CLI or web interface.
3. IP addresses (or hostnames) for:
   • The two Cloudmersive Private Cloud nodes
   • The Virtual IP address (VIP) for client traffic
4. Port information:
   • Ensure you know which port your Cloudmersive Private Cloud service is listening on (commonly 443 for HTTPS or 80 for HTTP).
5. SSL certificates and keys (if you are configuring HTTPS/SSL offload or re-encryption).
6. Network routing and firewall rules in place to allow traffic from the load balancer to each Cloudmersive Private Cloud node.

Configuring Servers (Nodes)

In A10 ACOS terminology, “server” objects represent the real servers in the backend. For this example, we’ll assume:

• Node 1 at IP 10.0.0.101
• Node 2 at IP 10.0.0.102
• Listening on port 443 (HTTPS)

If your environment uses HTTP (port 80), adjust accordingly.

Sample CLI Configuration

! Create server object for the first node
slb server cloudmersive-node1 10.0.0.101
  port 443 tcp
    health-check HM-CLOUDMERSIVE
    exit
  exit

! Create server object for the second node
slb server cloudmersive-node2 10.0.0.102
  port 443 tcp
    health-check HM-CLOUDMERSIVE
    exit
  exit

In the above snippet:

• cloudmersive-node1 and cloudmersive-node2 are labels you can customize.
• 10.0.0.101 and 10.0.0.102 are the IP addresses of the Cloudmersive nodes.
• port 443 tcp defines that these servers are listening on TCP port 443.
• health-check HM-CLOUDMERSIVE associates the servers with a health monitor named HM-CLOUDMERSIVE (we will define this monitor in the next step).

Creating the Health Monitor

We will create an HTTP/HTTPS health monitor that sends a GET request to /virus/status and verifies:

1. HTTP status code 200
2. Response body contains “Online”

If your Cloudmersive nodes use HTTPS, you should configure an HTTPS health check. If they use HTTP, you can configure an HTTP health check. Below is an example for HTTPS.

Sample CLI Configuration

health monitor HM-CLOUDMERSIVE
  retry 3
  interval 5
  timeout 5
  method https
    port 443   ! Adjust if using a nonstandard port
    url GET /virus/status
    expect response-code 200
    expect disable-down
    expect text "Online"
    exit
  exit

• retry 3 attempts the health check three times before marking the node down.
• interval 5 means the load balancer checks the node every 5 seconds.
• timeout 5 sets how long the load balancer waits for a response before the check fails.
• method https ensures we use HTTPS. Use method http if it is HTTP.
• url GET /virus/status is the path Cloudmersive Private Cloud exposes for status checks.
• expect response-code 200 ensures we only consider the node healthy if it returns HTTP 200.
• expect text "Online" ensures the response body contains the text "Online".

Note: If your Cloudmersive Private Cloud is HTTP only, replace method https with method http. You may also need to remove or change any SSL template references.

Creating the Service Group

A service group is a collection of servers that will receive traffic. We’ll associate it with the health monitor and load-balancing parameters.

Sample CLI Configuration

slb service-group SG-CLOUDMERSIVE tcp
  method least-connection
  member cloudmersive-node1 443
  member cloudmersive-node2 443
  exit

• SG-CLOUDMERSIVE is the name of the service group.
• tcp is the protocol type. (You can also specify http if you are doing Layer 7 HTTP load balancing with advanced policies.)
• method least-connection is the load balancing method; options include round-robin, least-connection, etc.
• member cloudmersive-node1 443 and member cloudmersive-node2 443 add the two servers on port 443.

Because we attached the health monitor on each server definition, the service group will automatically use that monitor.

Creating the Virtual Server (VIP)

Finally, create the Virtual Server that client traffic will hit. You will direct your DNS records or clients to this VIP address instead of hitting the nodes directly.

Sample CLI Configuration

slb virtual-server VS-CLOUDMERSIVE 10.0.0.200
  port 443 https
    name "cloudmersive-service"
    service-group SG-CLOUDMERSIVE
    !
    ! If you are doing SSL Offload or SSL bridging, you would specify an SSL template:
    ! template client-ssl YOUR_CLIENT_SSL_TEMPLATE
    !
    exit
  exit

• VS-CLOUDMERSIVE is the virtual server’s name.
• 10.0.0.200 is the VIP where clients connect.
• port 443 https indicates an HTTPS service on port 443.
• service-group SG-CLOUDMERSIVE associates the new VIP port with the service group of the two Cloudmersive nodes.

Note: If you only need a TCP pass-through, you could replace port 443 https with port 443 tcp. However, for true Layer 7 (HTTP/HTTPS) functionality—such as inserting headers, reading cookies, or advanced content switching—ensure you select http or https appropriately and apply relevant SSL templates.

Verifying the Configuration

1. Check the status of servers:

   show slb server
   

   You should see both cloudmersive-node1 and cloudmersive-node2 as “UP” if they respond with HTTP 200 and the text “Online.”

2. Check the status of the service group:

   show slb service-group
   

   It should show members as “UP” as well.

3. Test from a client:

   • Point your browser or any HTTP client (e.g., curl https://10.0.0.200) to the VIP.
   • Requests should be distributed to each Cloudmersive node according to the configured load-balancing method.

Troubleshooting Tips

• If servers show as DOWN:
  • Confirm the URL /virus/status is valid on your Cloudmersive Private Cloud nodes and returns the expected response.
  • Verify firewall rules are allowing traffic from the A10 ADC to your nodes.
  • Check that the ports are correct (HTTP vs. HTTPS).
  • Make sure SSL certificates and keys are valid if using SSL offload or re-encryption.
• If response code is not 200:
  • Confirm the health check is configured to send the correct request method and path (e.g., GET /virus/status).
• Use Logs:
  • The A10 device logs can help pinpoint whether the server is responding with the correct status code or content.

Example Full Configuration (Combined)

Below is an example minimal combined configuration snippet for reference. Adjust IPs, names, and ports as needed:

!
! Server Definitions
!
slb server cloudmersive-node1 10.0.0.101
  port 443 tcp
    health-check HM-CLOUDMERSIVE
    exit
  exit

slb server cloudmersive-node2 10.0.0.102
  port 443 tcp
    health-check HM-CLOUDMERSIVE
    exit
  exit

!
! Health Monitor
!
health monitor HM-CLOUDMERSIVE
  retry 3
  interval 5
  timeout 5
  method https
    port 443
    url GET /virus/status
    expect response-code 200
    expect disable-down
    expect text "Online"
    exit
  exit

!
! Service Group
!
slb service-group SG-CLOUDMERSIVE tcp
  method least-connection
  member cloudmersive-node1 443
  member cloudmersive-node2 443
  exit

!
! Virtual Server
!
slb virtual-server VS-CLOUDMERSIVE 10.0.0.200
  port 443 https
    service-group SG-CLOUDMERSIVE
    exit
  exit
!

Once this configuration is applied and saved, the A10 load balancer will monitor both Cloudmersive nodes on /virus/status. Any node failing to return 200 or “Online” will be taken out of rotation automatically.