Jessica Tomechak created CLOUDSTACK-235:
-------------------------------------------
Summary: Network rate can be set in 2 places. Clarify docs on how
this works.
Key: CLOUDSTACK-235
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-235
Project: CloudStack
Issue Type: Improvement
Components: Doc
Affects Versions: 4.0.0
Reporter: Jessica Tomechak
Priority: Minor
Fix For: 4.1.0
What is the purpose of the two Network Rates. There is one in Compute Offerings
and one in Network Offerings. How does each apply in basic & advanced
networking? (Michael Simos)
(Kirk Kosinski:)
With vSphere, the actual limits vary depending on:
1. Where they are configured (compute and/or network offering) 2. The
network type (shared or isolated) 3. The traffic direction (ingress or
egress)
I'd assume that a basic zone would work like a shared network in an
advanced zone, but if not, add that to the list above. However, it
may function differently in XenServer, so hypervisor might also need
to be on the list (and even if XenServer and vSphere function the
same, KVM doesn't support limits at all). Also, it is probably different in
vSphere with Nexus 1000V since (I think) ingress traffic can be limited (a
regular dvSwitch can limit ingress/egress, and I think the Nexus 1000V is
considered a dvSwitch... but I only tested with regular vSwitches, which can
only limit egress)... so...vSwitch type may need to be on that list.
Network Rate can be configured on either the Network
Offering or Compute Offering, on both of them simultaneously, or on
neither of them. The resulting behavior in vSphere is complicated. However, I
will try to explain.
The Network Rate for a Network Offering used by a particular network
in CloudStack will be used for the traffic shaping policy of a port
group for that network (i.e. a particular subnet/VLAN on the actual network).
Virtual routers for that network will connect to this port group, and by
default instances in that network will connect to this port group.
However, if an instance is deployed with a Compute Offering with a
Network Rate, this rate will be used for the traffic shaping policy of
another port group for the network, and instances using the offering will be
connected to this port group instead.
Traffic shaping on standard port groups in vSphere only applies to
egress traffic and the net effect depends on the type of network in
CloudStack. For shared networks, ingress traffic is unlimited as far
as CloudStack is concerned, and egress traffic is limited to the rate
that applies to the port group used by the instance (if any). If the
Compute Offering has a Network Rate configured, this rate will apply
to egress traffic, otherwise the Network Rate of the Network Offering will
apply. For isolated networks, the Network Rate for the Network Offering (if
any) will effectively apply to ingress traffic (since it applies to egress
traffic from the virtual router to the instance), and egress traffic is limited
to the rate that applies to the port group used by the instance (if any),
similar to shared networks.
So for example:
Network Rate of Network Offering = 10 Mb/s
Network Rate of Compute Offering = 200 Mb/s
In a shared network, ingress traffic will not be limited as far as
CloudStack is concerned, while egress traffic will be limited to 200 Mb/s. In
an isolated network, ingress traffic will be limited to 10 Mb/s and egress to
200 Mb/s.
(Kirk Kosinski)
See: http://docs.cloudstack.org/Knowledge_Base/Network_Throttling. We have
confirmed the current code behaves as documented here (Murali Reddy)
It is different in vSphere with Nexus 1000V since ingress traffic can be
limited, as well as egress traffic. (Sateesh Chodapuneedi)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
