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 host header is https://appserver.cloud-test.wso2.com/t/ttt.ttt/carbon/admin/login.jsp, 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.
# configuration details of WSO2 Elastic Load Balancer
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
}
# 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 *;
}
}
}
esb {
# multiple hosts should be separated by a comma.
hosts esb.cloud-test.wso2.com;
#url_suffix esb.wso2.com;
domains {
wso2.esb.domain {
tenant_range *;
}
}
}
governance {
hosts governance.cloud-test.wso2.com;
#url_suffix governance.wso2.com;
domains {
wso2.governance1.domain {
tenant_range 1-100;
}
wso2.governance2.domain {
tenant_range 101-200;
}
wso2.governance3.domain {
tenant_range *;
}
}
}
identity {
hosts identity.cloud-test.wso2.com;
#url_suffix identity.wso2.com;
domains {
wso2.identity1.domain {
tenant_range 1-100;
}
wso2.identity2.domain {
tenant_range 101-200;
}
wso2.identity3.domain {
tenant_range *;
}
}
}
}