Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

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.

Code Block
#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:
Code Block
languagehtml/xml
# 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    *;
            }
        }
    }

    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    *;
            }
        }
    }
    
}