Hi, Thanks for this discussion, Your answares were very helpfull. If we want to try to configure service instances with different mac/ip address per service instance (on backend side), what we should do? Can You give us some tips?
-- Regards Dominik 2015-08-18 23:58 GMT+02:00 Dominik Mostowiec <[email protected]>: > 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 >>>> > -- Pozdrawiam Dominik _______________________________________________ Dev mailing list [email protected] http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
