It looks ok. But we have some places where we need a little more in one virtual. Second thing. It would be nice to not have a limitation in lb and automatic scaling via Heat.
Regards Dominik 18 sie 2015 23:33 "Rudra Rugge" <[email protected]> napisał(a): > Please see the following for some LBaaS performance benchmarking. Most of > the changes have been incorporated in the current mainline: > > http://www.symantec.com/connect/blogs/lbaas-performance-benchmarking > > > > Rudra > > > > ------------------------------ > *From:* Dominik Mostowiec <[email protected]> > *Sent:* Tuesday, August 18, 2015 1:09 PM > *To:* Rudra Rugge > *Cc:* Piotr P; [email protected] > *Subject:* Re: [opencontrail-dev] Active-active loadbalancer > > > We are searching for scalable and distributed LB solution which can > achieve much more traffic than one haproxy process can. > Yes, it possible to put many active-standby LBs behind DNS but i don't > know if it is a good sution. > > Regards > Dominik > 18 sie 2015 21:34 "Rudra Rugge" <[email protected]> napisał(a): > >> LVS seems like an L4-NAT based loadbalancer. It does not provide proxy >> based load balancing as per my understanding. >> >> >> Could you describe more on what you are looking to do and why the current >> scheme does not fit. >> >> >> Regards, >> >> Rudra >> >> >> >> ------------------------------ >> *From:* Dominik Mostowiec <[email protected]> >> *Sent:* Tuesday, August 18, 2015 12:24 PM >> *To:* Rudra Rugge >> *Cc:* [email protected]; Piotr P >> *Subject:* Re: [opencontrail-dev] Active-active loadbalancer >> >> >> Is it possible for now to use another lb solution like lvs with >> connection state syncing in active-active mode in contrail? >> >> Regards >> Dominik >> 18 sie 2015 20:11 "Rudra Rugge" <[email protected]> napisał(a): >> >>> This has more implications on session distribution - least connection, >>> roundrobin, source-ip etc will not work properly in this solution and hence >>> we have not supported it. Without all the TCP and LB state sync as part of >>> a cluster its still not a perfect solution. >>> >>> >>> Rudra >>> >>> ------------------------------ >>> *From:* Dev <[email protected]> on behalf of Rudra >>> Rugge <[email protected]> >>> *Sent:* Tuesday, August 18, 2015 10:27 AM >>> *To:* Piotr P; [email protected] >>> *Subject:* Re: [opencontrail-dev] Active-active loadbalancer >>> >>> >>> This is something we are exploring as part of our next effort. >>> >>> >>> Thanks, >>> >>> Rudra >>> >>> >>> ------------------------------ >>> *From:* Dev <[email protected]> on behalf of Piotr P < >>> [email protected]> >>> *Sent:* Tuesday, August 18, 2015 10:17 AM >>> *To:* [email protected] >>> *Subject:* Re: [opencontrail-dev] Active-active loadbalancer >>> >>> >>> Hi, >>> >>> Let me ask one more question regarding load balancer because this is >>> interesting topic. >>> >>> From what I’ve seen both instances have the same IP and MAC Adresses for >>> both interfaces (Righ, Left). Normally separate instances of haproxy could >>> have different addresses on the side of the backend Network. They will do >>> checks individually. and probably could scale >2 instances. >>> >>> Is it possible even theoretically that we could do that by only change IP >>> and MAC on the Backend Network Side ? In my mind we need only ECMP only for >>> VIP Address, In Backend each instance could have unique mac and IP address. >>> >>> Do you see this as possible scenario at all ? >>> >>> >>> Kind Regards >>> >>> Piotr Pieprzycki >>> >>> >>> >>> This configuration can cause asymmetric routing. Response for request going >>> from LB1 to a backend server could come back to LB2. LB2 does not have any >>> state for this response and hence will drop the packet. Without syncing all >>> the >>> TCP state it can lead to unpredictable results. To sync all state clustering >>> support is needed. >>> >>> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org >>> >>>
_______________________________________________ Dev mailing list [email protected] http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
