+1 .It is good to have LVS support for Stratos, so world like to contribute to this.
Will create a new branch from master branch and work on that branch since features are freeze for 4.1.0 release.After 4.1.0 release we can merge those changes to the master branch. Thanks, Gayan On Thu, May 7, 2015 at 9:45 PM, Chamila De Alwis <chami...@wso2.com> wrote: > Hi Sajith, > > Yes, I missed the scenario where the load balancer runs standalone. An > extension would be the best approach then. > On May 4, 2015 2:41 PM, "Sajith Kariyawasam" <saj...@wso2.com> wrote: > >> Hi Chamila, >> >> Thanks for the suggestion. But If we use a cartridge agent plugin, then >> load balancers must be run as cartridges. IMO If we implement as a load >> balancer extension, then that could be used when the LB is running as a >> cartridge as well as stand alone mode, interchangeably. ? >> >> Thanks, >> Sajith >> >> On Mon, May 4, 2015 at 11:02 AM, Chamila De Alwis <chami...@wso2.com> >> wrote: >> >>> Hi Sajith, >>> >>> +1 for providing this support. AFAIU can't we use a Cartridge Agent >>> plugin to reconfigure the load balancers as well? >>> On May 4, 2015 9:38 AM, "Sajith Kariyawasam" <saj...@wso2.com> wrote: >>> >>>> Hi Devs, >>>> >>>> I would like to propose LVS load balancer support for Stratos. >>>> >>>> In a normal working setup as mentioned in [1], two load balancers (each >>>> running ipvsadm and keepalived) are paired, one master and one slave. >>>> Keepalived is configured per pair using vrrp allows the automatic failover >>>> to let the slave become master if load balancing dies on the master. >>>> There are N real servers each running the real service located behind >>>> the load balancer. With Stratos in place, the real servers are orchestrated >>>> and monitored by Stratos and whenever an extra real server gets added to >>>> the cluster of real servers (because of scaling up) the load balancers need >>>> to get updated by Stratos to include the new real server in the load >>>> balancing decisions. In the same way, if a real server becomes unavailable >>>> (scaled down), the load balancers need to get updated by Stratos to remove >>>> the now unavailable server from the load balancing decisions. >>>> >>>> This requires load balancer configuration to be updated accordingly to >>>> reflect new real server (member) IP s, and this can be implemented by >>>> extending Stratos load balancer extension API. This "plugin" will be >>>> listenning to the "Topology" topic of Message broker and will update the >>>> LVS load balancer configuration (both master and slave if present) >>>> accordingly, either when extra real servers added up in a scale-up or when >>>> extra real servers removed in scale-down. >>>> >>>> In each of real server, the required configuration (bringing up dummy >>>> interface) can be done via puppet or via a cartridge agent module. For that >>>> the virtual ip address needs to be passed in the payload when the real >>>> server is booting up. >>>> >>>> [1] >>>> http://blackbird.si/loadbalancing-failover-with-ipvs-and-keepalived/ >>>> >>>> >>>> Thanks, >>>> Sajith >>>> >>> >> -- Gayan Gunarathne Technical Lead WSO2 Inc. (http://wso2.com) email : gay...@wso2.com | mobile : +94 766819985
