cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kris Sterckx <kris.ster...@nuagenetworks.net>
Subject Re: [DISCUSS] Request for comments : VPC Inline LoadBalancer (new plugin)
Date Sun, 10 Apr 2016 20:26:02 GMT
Hi all


Thanks for reviewing the FS. Based on the received comments I clarified
further in the FS that the Vpc Inline LB appliance solution is based on the
Internal LB appliance solution, only now extended with secondary IP's and
static NAT to Public IP.

I also corrected the "management" nic to "control" nic. The text really
meant eth1, i.e the link-local nic on KVM.

Pls find the updated text :

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61340894

Architecture and Design description

We will introduce a new CloudStack network plugin “VpcInlineLbVm” which is
based on the Internal LoadBalancer plugin and which just like the Internal
LB plugin is implementing load balancing based on at-run-time deployed
appliances based on the VR (Router VM) template (which defaults to the
System VM template), but the LB solution now extended with static NAT to
secondary IP's.

The VPC Inline LB appliance therefore is a regular System VM, exactly the
same as the Internal LB appliance today. Meaning it has 1 guest nic and 1
control (link-local / management) nic.

With the new proposed VpcInlineLbVm set as the Public LB provider of a VPC,
when a Public IP is acquired for this VPC and LB rules are configured on
this public IP, a VPC Inline LB appliance is deployed if not yet existing,
and an additional guest IP is allocated and set as secondary IP on the
appliance guest nic, upon which static NAT is configured from the Public IP
to the secondary guest IP.  (See below outline for the detailed algorithm.)

*In summary*, the VPC Inline LB appliance is reusing the Internal LB
appliance but its solution now extended with Static NAT from Public IP's to
secondary (load balanced) IP's at the LB appliance guest nic.


Hi Ilya,

Let me know pls whether that clarifies and brings new light to the
questions asked.

Can you pls indicate, given the suggested approach of reusing the appliance
mechanism already used for Internal LB, whether this addresses the concern
or, when it doesn't, pls further clarify the issue seen in this approach.

Thanks!


Hi Sanjeev, to your 1st question:

Will this LB appliance be placed between guest vm's and the Nuage VSP
provider(Nuage VSP and lb appliance will have one nic in guest network)?

> Please note that the LB appliance is a standard System VM, having 1 nic
in Guest network and 1 nic in Control. There is as such no relation between
this Appliance and the Nuage VSP.

In the case where Nuage VSP is the Connectivity provider, the appliance has
a guest nic in a Nuage VSP managed (VXLAN) network, like all guest VM's
would have. But that is dependent on the provider selection.

In the specific case of Nuage VSP, publicly load balanced traffic will
indeed flow as : (pls read-on to your 2nd question also) :
    -> incoming traffic on Public IP  (Nuage VSP managed)
    -> .. being Static NAT'ted to Secondary IP on Vpc Inline LB VM
 (NAT'ting is Nuage VSP managed)
    -> .. being load balanced to real-server guest VM IP's  (Vpc Inline LB
VM appliance managed)
    -> .. reaching the real-server guest VM IP

To your 2nd question:

Is there any specific reason for traffic filtering on lb appliance instead
of Nuage VSP ? If we configure firewall rules for LB services on the Nuage
VSP instead of the inline lb appliance (iptable rules  for lb traffic),
traffic can be filtered on the Nuage VSP before Natting?

> Please note that the generic Static NAT delegation is applicable : the
realization of the Static NAT rules being set up, depends on the Static NAT
provider in the VPC offering. In case Nuage VSP is the provider for Static
NAT (which it would be in the case of a Nuage SDN backed deployment), the
NAT’ting is effectively done by the Nuage VSP.  If anyone else is the
provider, than this provider is being delegated to.

Thanks!


Let me know whether this overall clarifies.

Pls don't hesitate to ask and further questions.


Best regards,


Kris Sterckx



On 25 March 2016 at 07:08, Sanjeev Neelarapu <
sanjeev.neelarapu@accelerite.com> wrote:

> Hi Nick Livens,
>
> I have gone through the FS and following are my review comments:
>
> 1. Will this LB appliance be placed between guest vms and the Nuage VSP
> provider(Nuage VSP and lb appliance will have one nic in guest network)?
> 2. Is there any specific reason for traffic filtering on lb appliance
> instead of Nuage VPS ? If we configure firewall rules for LB services on
> the Nuage VSP instead of the inline lb appliance (iptable rules  for lb
> traffic), traffic can be filtered on the Nuage VSP before Natting?
>
> Best Regards,
> Sanjeev N
> Chief Product Engineer, Accelerite
> Off: +91 40 6722 9368 | EMail: sanjeev.neelarapu@accelerite.com
>
>
> -----Original Message-----
> From: ilya [mailto:ilya.mailing.lists@gmail.com]
> Sent: Thursday, March 24, 2016 10:16 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Request for comments : VPC Inline LoadBalancer (new
> plugin)
>
> Hi Nick,
>
> Being fan of SDN, I gave this proposal a thorough read.
>
> I do have only 1 comment - that you can perhaps can use to reconsider:
>
> "Each appliance will have 2 nics, one for management, and one in the guest
> network. "
>
> In general, 2 nics - one going to management and one going to guest - is
> looked very negatively upon by internal InfoSec team. This implementation
> will make an LB non-compliant from SOX or PCI perspective.
>
> Proposed alternate solution:
> Deploy a VM with 2 NICs but put them both on the same guest network (I
> believe the support 2 NICs on the *same* guest network has already been
> submitted upstream). 1 NIC for MGMT and 1 NIC for GUEST.
>
> Using SDNs ability to restrict communication flow (openvswitch or what
> not), only allow specific connections from CloudStack MS to Inline LB on
> MGMT NIC. You will need to block all external GUEST communication to MGMT
> NIC and only make it talk to CloudStack MS on specific ports.
>
> This approach should preserve the internal compliance and wont raise any
> red flags.
>
> Perhaps reach out to a client who requested this feature and ask what they
> think, maybe they have not thought this through.
>
> Regards
> ilya
>
> PS: If we were to entertain the idea of InLine LB, we would most likely
> ask for approach mentioned above.
>
>
>
>
> On 3/24/16 1:18 AM, Nick LIVENS wrote:
> > Hi all,
> >
> > I'd like to propose a new plugin called the "VPC Inline LB" plugin.
> > The design document can be found at :
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61340
> > 894
> >
> > Looking forward to hear your reviews / thoughts.
> >
> > Thanks!
> >
> > Kind regards,
> > Nick Livens
> >
>
>
>
> DISCLAIMER
> ==========
> This e-mail may contain privileged and confidential information which is
> the property of Accelerite, a Persistent Systems business. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Accelerite, a Persistent Systems business does not accept any
> liability for virus infected mails.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message