cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Weingärtner <rafaelweingart...@gmail.com>
Subject Re: CloudStack Advanced networking doubt
Date Tue, 28 Feb 2017 19:18:13 GMT
Sorry Dag, I probably did not express myself clearly. I knew that ACS had
nothing to do with it. I wanted only to check the underlying structure
requirements, so the scenario I described would work.


Thanks for your explanation, I now understood it ;)

On Tue, Feb 28, 2017 at 2:09 PM, Simon Weller <sweller@ena.com> wrote:

> So, it's actually a higher level than that. Each vlan is a broadcast
> domain (it's a virtual LAN). Managed switches support the ability of
> tagging (or trunking depending on the vendor) various sets of vlans to
> physical ports. When you need a vlan to be sent to a different switch and
> you want to keep the vlan tags, you tag the port with the vlan and it gets
> transported to the connected switch. This can introduce network loops
> (broadcast storms), so spanning tree serves to shut down redundant paths to
> protect the switch fabric from experiencing loops. Each vlan operates as
> you articulated below, but each switch can handle many virtual lans (vlans).
>
>
> Within a cloudstack zone, each host within that zone (regardless of
> cluster or pod) needs access to every vlan provisioned as an isolated
> network, or vpc. This requires the network to support the transport of
> vlans across all switches providing connectivity to the zone so that all
> VMs within the isolated network can see each other.
>
> ________________________________
> From: Rafael Weingärtner <rafaelweingartner@gmail.com>
> Sent: Tuesday, February 28, 2017 12:58 PM
> To: users@cloudstack.apache.org
> Subject: Re: CloudStack Advanced networking doubt
>
> Ok, let’s see if I understood what we are doing.
>
> Within a switch domain, we send packets using the mac address of network
> interface cards. The switch has a table matching mac addresses to ports
> they are being used in; therefore, it can efficiently execute the
> forwarding. When you say that we expect broadcast domain across a zone, you
> mean that switches of this zone are exchanging information regarding the
> mac address of the network interfaces they "know". Is that it?
>
> If there is a packet (Frame) that is addressed to a mac address to a
> network interface that is not within a domain of a switch, this switch may
> forward this packet to another switch that “knows” the interface that has
> the destination mac address. is that what you guys mean by "expecting
> broadcast domain across a zone"?
>
> On Tue, Feb 28, 2017 at 1:45 PM, Simon Weller <sweller@ena.com> wrote:
>
> > Rafael,
> >
> >
> > ACS expects the same layer 2 broadcast domain across all pods in a zone.
> > So your switches have to trunk all vlans. This can get really nasty for
> > larger typologies (due to vlan limits and spanning tree), hence why
> > technologies like vxlan, stt and gre were invented.
> >
> >
> > - Si
> >
> > ________________________________
> > From: Rafael Weingärtner <rafaelweingartner@gmail.com>
> > Sent: Tuesday, February 28, 2017 12:41 PM
> > To: users@cloudstack.apache.org
> > Subject: Re: CloudStack Advanced networking doubt
> >
> > Great, thanks for the explanation Dag.
> > So, for two VMs that are on the same virtual network, but different PODs
> > (consequently in a different layer -2 domain switch) how does ACS handle
> in
> > this situation?
> >
> >
> > On Tue, Feb 28, 2017 at 1:36 PM, Dag Sonstebo <
> Dag.Sonstebo@shapeblue.com>
> > wrote:
> >
> > > Hi Rafael,
> > >
> > > in the confines of that zone yes. All switches serving one zone need to
> > > trunk the same VLANs, no matter how you configure your PODs or
> clusters.
> > >
> > > Regards,
> > > Dag Sonstebo
> > > Cloud Architect
> > > ShapeBlue
> > >
> > > On 28/02/2017, 18:31, "Rafael Weingärtner" <
> rafaelweingartner@gmail.com>
> > > wrote:
> > >
> > >     You mean, once a user allocates a VLAN’s (let’s say tag 1), in all
> of
> > > the
> > >     switches this VLAN tag is reserved?
> > >
> > >     On Tue, Feb 28, 2017 at 12:48 PM, Dag Sonstebo <
> > > Dag.Sonstebo@shapeblue.com>
> > >     wrote:
> > >
> > >     > Hi Rafael,
> > >     >
> > >     > Keep in mind for an advanced zone the broadcast domain for VLANs
> is
> > > the
> > >     > zone rather than the POD, i.e. VMs in the new POD would use the
> > same
> > > VLANs
> > >     > as the previous VMs in the original POD.
> > >     >
> > >     > Regards,
> > >     > Dag Sonstebo
> > >     > Cloud Architect
> > >     > ShapeBlue
> > >     >
> > >     > On 28/02/2017, 16:16, "Rafael Weingärtner" <
> > > rafaelweingartner@gmail.com>
> > >     > wrote:
> > >     >
> > >     >     Hi folks,
> > >     >     I was checking some information regarding ACS advanced
> > networking
> > >     >     deployment mode, and I ran into this figure [1]. This made me
> > > wonder,
> > >     > what
> > >     >     would happen with the following scenario.
> > >     >
> > >     >     Let`s say I have a similar scenario as the one depicted in
> > > figure [1],
> > >     > a
> > >     >     set of pods with a set of clusters that have a set of hosts.
> > > Each host
> > >     > in a
> > >     >     pod is linked directly using a Layer-2 switch. Let’s assume
> > > there exist
> > >     >     network/aggregation layers that are configured properly and
> > > provide
> > >     > access
> > >     >     to VMs in the cloud using the public IP net. Let’s also
> assume
> > > that the
> > >     >     public IP net is 1.1.1.0/24; the management and storage
> > > networks are
> > >     > on
> > >     >     isolated networks and are properly set up (Assume also that
> we
> > > are
> > >     > using
> > >     >     the advanced networking mode).
> > >     >
> > >     >     Now, I create a guest network 2.2.2.0/24. When I deploy a
> user
> > > VM,
> > >     > ACS will
> > >     >     deploy a VR (let’s call x) with an IP (1.1.1.1) in the public
> > > net, and
> > >     >     other on the guest network (2.2.2.1). Then, this VR(x) will
> > > execute the
> > >     >     firewalling/forwarding for my newly created user VM.
> > >     >
> > >     >     Let’s now imagine that I keep deploying user VMs to a point
> in
> > > which
> > >     > the
> > >     >     POD gets full. The next VM I create ACS will have to deploy
> in
> > > other
> > >     > PODs
> > >     >     of the environment. Because this new user VM will be in a
> > > different
> > >     > POD,
> > >     >     the communication with other user VMs is not straightforward
> > > anymore
> > >     > (not a
> > >     >     matter of using the same VLAN and net). What will ACS do to
> > link
> > > users
> > >     > VMs
> > >     >     that are on the same virtual network, but deployed in
> different
> > > PODs?
> > >     >
> > >     >     Will it deploy other VR(y) with an IP (let's say 1.1.1.2) on
> > the
> > > new
> > >     > POD
> > >     >     and create a route between VR(x) and VR(y) using the public
> > > network, so
> > >     >     that the communication for VMs in network 2.2.2.0/24 is
> > > transparent?
> > >     >
> > >     >     http://docs.cloudstack.apache.org/projects/cloudstack-
> > >     > administration/en/4.8/_images/network-setup-zone.png
> > >     >
> > >     >     --
> > >     >     Rafael Weingärtner
> > >     >
> > >     >
> > >     >
> > >     > Dag.Sonstebo@shapeblue.com
> > >     > www.shapeblue.com<http://www.shapeblue.com>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > www.shapeblue.com<http://www.shapeblue.com>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > Introduction Upgrading CloudStack can sometimes be a little daunting -
> but
> > as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
> >
> >
> >
> > >     > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > >     > @shapeblue
> > >     >
> > >     >
> > >     >
> > >     >
> > >
> > >
> > >     --
> > >     Rafael Weingärtner
> > >
> > >
> > >
> > > Dag.Sonstebo@shapeblue.com
> > > www.shapeblue.com<http://www.shapeblue.com>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > www.shapeblue.com<http://www.shapeblue.com>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > Introduction Upgrading CloudStack can sometimes be a little daunting -
> but
> > as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
> >
> >
> >
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Rafael Weingärtner
> >
>
>
>
> --
> Rafael Weingärtner
>



-- 
Rafael Weingärtner

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