[Moving to list] Hi Sam,
responses inline ---------- Forwarded message ---------- From: Samuel Bercovici <samu...@radware.com> Date: Thu, Jun 27, 2013 at 1:43 PM Subject: Chalenges with highly available service VMs To: "Mark McClain (mark.mccl...@dreamhost.com)" <mark.mccl...@dreamhost.com>, "aro...@nicira.com" <aro...@nicira.com> Cc: Samuel Bercovici <samu...@radware.com>, Avishay Balderman < avish...@radware.com>, "gary.kot...@gmail.com" <gary.kot...@gmail.com>, " gkot...@redhat.com" <gkot...@redhat.com> Hi,**** ** ** As part of provisioning load balancer service VMs we have encountered the following changes.**** Our planned HA model for this release is going to use a strategy in which IP addresses are configured on the HA VM pair in the same way but only the active box is “connected” to the network and answers ARP request.**** When the 1st VM fails and after the 2nd VM detects this, it will do a GARP and will take ownership on the IP addresses.**** The assumption is the underlying L2 network can support IP to MAC discovery. **** ** *[arosen] - yup makes sense. * The challenge that we are facing is that currently each Neutron port, automatically gets “security” protection via IP tables which is intended to prevent IP spoofing. **** If the load balancer service VM gets configured with an IP (ex: VIP) this security blocks traffic to the IP until the Neutron port gets updated with this addition IP.**** In addition the IP should be allocated/marked as used in a Neutron subnet and currency AFAIK there is no means to allocate an IP address without attaching it to a Neutron port.**** I do not know how a network based on Nicira behaves as AFAIK it does not use IP tables.**** ** ** In the case of 2 machines acting as an HA pair the same IP address needs to be assigned to two Neutron ports so that the IP tables rules will be update correctly for bot. AFAIK this (IP attached to two Neutron Pots) is currently not supported.**** As I expect that get 10s-100s VIPs mapped to the same Neutron port, I am worried that having many rules in a chain will have an impact.**** ** ** Follows a few options to solve this:**** **1. **Define a Neutron port as a Neutron service port. In this case the assumption is that the VM/Port belongs to the cloud infrastructure and hence no need to specify the IP tables rules that prevents “MAC” spoofing or “IP” spoofing (which are some of the different strategies to achieve HA). Potentially add support in Nova so that when a VM marked as service VM in nova is provisioned, than the Neutron ports of this VM will be defines as Neutron service ports.**** *[arosen] - there is already an extension that does this though only the nvp plugin implements it at the time though it shouldn't be very hard to add support for it in other plugins. * https://github.com/openstack/quantum/blob/master/quantum/extensions/portsecurity.py **2. **Add support for assigning the same IP address to two Neutron ports**** [arosen] - there is a blueprint for pluggable ipam which might work for this. That said. it seems like it might also be worth while to add an extension that allows you to add/remove ip/mac address pairs to a port. ** What do you think?**** ** ** Regards,**** -Sam.**** ** **
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
