Configuration Guide

The Load Balancer's task is to distribute the load of incoming traffic amongst a set of back-end worker nodes. When a request comes to the WSO2 Load Balancer, the host header is identified and the cluster domain is determined. Described below is a brief sample scenario of how to configure the WSO2 ELB.

Example Scenario

In this example, the service domain is "appserver" and the tenant Id is determined from the url. According to the URL, the tenant domain is ttt.ttt. These parameters can be extracted from the header. Using both the service domain and tenant domain, requests can be directed to the correct cluster defined in the <elb_home>\repository\conf\loadbalancer.conf file, where services with their cluster domains and tenant ranges can be configured. When the Load Balancer starts, it picks those ranges and cluster domains.

Refer to the following sample configuration for one service with two clustering domains in the <elb_home>\repository\conf\loadbalancer.conf file.

appserver {
  # multiple hosts should be separated by a comma. 
  hosts appserver.cloud-test.wso2.com;
 
  domains {
     carbon.as1.domain {
        tenant_range 1-100;
     }
     carbon.as.domain {
        tenant_range *;
     }
  }
}

The sample configuration above is for an application service with two service clusters. According to the first line, "appserver" is the main node. Host entries are specified in the lines that follow, with the the host address that maps to the application server service. If you need to add multiple service domains, add them separated by commas. The above sample has two domains with predefined tenant ranges. The cluster names as "carbon.as1.domain" is responsible for loading tenants with tenant id 1 to 100 and the one named as "carbon.as.domain" is responsible for loading all tenants except the ones belonging to the above range.

This ensures that requests are forwarded to the correct cluster based on the service domain and tenant domain. The following diagram depicts how requests are forwarded to the correct cluster.

The WSO2 ELB can be used to front cluster nodes of different WSO2 Carbon-based products. Depending on the product, the configurations can have minor changes. For more information on how to use the WSO2 ELB in worker-manager clustering, refer to section, Clustering with the Load Balancer.

Enabling Auto-Scaling

Following is a portion of <elb_home>\repository\conf\loadbalancer.conf file which demonstrates how to enable auto-scaling.

#configuration details of WSO2 Elastic Load Balancer
loadbalancer {

# minimum number of load balancer instances 
instances 1;

# whether autoscaling should be enabled or not, currently we do not support autoscaling 
enable_autoscaler true;

# End point reference of the Autoscaler Service
autoscaler_service_epr  https://10.100.3.104:9445/services/AutoscalerService/; 

# interval between two task executions in milliseconds 
autoscaler_task_interval 15000;
}

"autoscaler_task_interval" property should be fine-tuned according to your environment.

Most of the configuration options in the loadbalancer.conf file are self-explanatory with relevant code comments given for your reference as follows:

# configuration details of WSO2 Elastic Load Balancer for more info on how it works, refer to: http://blog.afkham.org/2011/09/wso2-load-balancer-how-it-works.html
# for more info on how to set it up, refer to: http://nirmalfdo.blogspot.com/2012/06/fronting-wso2-application-server-50.html
loadbalancer {

    # minimum number of load balancer instances 
    instances 1;

    # whether autoscaling should be enabled or not.
    enable_autoscaler   false;
    #please use this whenever url-mapping is used through LB.
    #size_of_cache 100;

    # End point reference of the Autoscaler Service
    autoscaler_service_epr  https://{host_address}:{https_port}/services/AutoscalerService/; 

    # interval between two task executions in milliseconds 
    autoscaler_task_interval 25000;

    # after an instance booted up, task will wait maximum till this much of time and let the server started up
    server_startup_delay 100000; #default will be 60000ms
    
    # session time out
    session_timeout 90000;
 
    # enable fail over 
    fail_over true;
}

# services' details which are fronted by this WSO2 Elastic Load Balancer
services {
    # default parameter values to be used in all services
    defaults {
        # minimum number of service instances required. WSO2 ELB will make sure that this much of instances
        # are maintained in the system all the time, of course only when autoscaling is enabled.
        min_app_instances 1;

        # maximum number of service instances that will be load balanced by this ELB.
        max_app_instances 5;

        # Please refer to the blog post http://nirmalfdo.blogspot.com/2012/07/autoscaling-algorithm-used-in-wso2.html to get to know the importance of following properties.
        queue_length_per_node 3;
        rounds_to_average 2;
        message_expiry_time 60000;
    }

    appserver {
        # multiple hosts should be separated by a comma.
        hosts appserver.cloud-test.wso2.com,as.cloud-test.wso2.com;
    #when using url mapping, url_suffix will be required. hosts should be read first before url_suffix, 
    #in order to construct the host vs url-suffix pairs, hence keep the logical order to of hosts and url_suffix as it is.                                
    #url_suffix as.wso2.com,appserver.wso2.com;
        domains {
            wso2.as1.domain {
                # for more info on Tenant aware load balancing please refer to 
                # http://sanjeewamalalgoda.blogspot.com/2012/05/tenant-aware-load-balancer.html
                tenant_range 1-100;
            }
            wso2.as2.domain {
                tenant_range 101-200;
            }
            wso2.as3.domain {
                # all tenants other than 1-200 will belong to this domain.
                tenant_range *;
            }
        }
    }

}