openstack/openstack-manuals
Code Issues Proposed changes

Arch Design edits

Browse Source 
Improve wording and markup.

Change-Id: I930c5f7d4a23baa9898a02822fe3f7b844bccad9
Co-Authored-By: Diane Fleming <dfleming@austin.rr.com>
This commit is contained in:
Andreas Jaeger
2014-08-14 17:10:19 +02:00
parent ed25bdbf5a
commit 9388483887
4 changed files with 101 additions and 73 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml
View File

@@ -135,14 +135,14 @@
(neutron), has tremendous implications and will have
a huge impact on the architecture and design of the cloud
network infrastructure.</para>
<para>The legacy networking (nova-network) service is primarily a layer-2 networking
service which has two main modes in which it will function.
The difference between the two modes in legacy networking pertain
to whether or not legacy networking uses VLANs. When using
legacy networking in a flat network mode, all network hardware
nodes and devices throughout the cloud are connected to a
single layer-2 network segment which provides access to
application data.</para>
<para>
The legacy networking (nova-network) service is primarily a
layer-2 networking service that functions in two modes. In
legacy networking, the two modes differ in their use of VLANs.
When using legacy networking in a flat network mode, all network
hardware nodes and devices throughout the cloud are connected to
a single layer-2 network segment that provides access to
application data.</para>
<para>When the network devices in the cloud support segmentation
using VLANs, legacy networking can operate in the second mode. In
this design model, each tenant within the cloud is assigned a

47
doc/arch-design/network_focus/section_architecture_network_focus.xml
View File

@@ -52,15 +52,17 @@
is necessary to implement quality of service management
outside of OpenStack. In many of these instances, similar
solutions for traffic shaping or other network functions will
be needed.</para>
<para>Depending on the selected design, Networking itself may not
even support the required
<glossterm baseform="Layer-3 network">layer-3 network</glossterm>
functionality. If it
is necessary or advantageous to use the provider networking
mode of Networking without running the layer-3 agent, then an
external router will be required to provide layer-3
connectivity to outside systems.</para>
be needed.
</para>
<para>
Depending on the selected design, Networking itself might not
even support the required
<glossterm baseform="Layer-3 network">layer-3
network</glossterm> functionality. If you choose to use the
provider networking mode without running the layer-3 agent, you
must install an external router to provide layer-3 connectivity
to outside systems.
</para>
<para>Interaction with orchestration services is inevitable in
larger-scale deployments. The Orchestration module is capable of allocating
network resource defined in templates to map to tenant
@@ -145,12 +147,13 @@
mesh overlay network, while some network monitoring tools or
storage replication workloads will have performance issues
with throughput or excessive broadcast traffic.</para>
<para>A design decision that many overlook is a choice of layer-3
<para>Many people overlook an important design decision: The choice
of layer-3
protocols. While OpenStack was initially built with only IPv4
support, Networking now supports IPv6 and dual-stacked networks.
Note that, as of the Icehouse release, this only includes
stateless address autoconfiguration but the work is in
progress to support stateless and stateful dhcpv6 as well as
stateless address autoconfiguration but work is in
progress to support stateless and stateful DHCPv6 as well as
IPv6 floating IPs without NAT. Some workloads become possible
through the use of IPv6 and IPv6 to IPv4 reverse transition
mechanisms such as NAT64 and DNS64 or <glossterm>6to4</glossterm>,
@@ -180,16 +183,16 @@
routing table and use it to provide services such as network
path visibility to other applications or as a monitoring
tool.</para>
<para>A lesser known, but harder to diagnose issue, is that of
path Maximum Transmission Unit (MTU) failures. It is less of
an optional design consideration and more a design warning
that MTU must be at least large enough to handle normal
traffic, plus any overhead from an overlay network, and the
desired layer-3 protocol. Adding externally built tunnels will
further lessen the MTU packet size making it imperative to pay
attention to the fully calculated MTU as some systems may be
configured to ignore or drop path MTU discovery
packets.</para></section>
<para>
Path maximum transmission unit (MTU) failures are lesser known
but harder to diagnose. The MTU must be large enough to handle
normal traffic, overhead from an overlay network, and the
desired layer-3 protocol. When you add externally built tunnels,
the MTU packet size is reduced. In this case, you must pay
attention to the fully calculated MTU size because some systems
are configured to ignore or drop path MTU discovery packets.
</para>
</section>
<section xml:id="tunables">
<title>Tunable networking components</title>
<para>Consider configurable networking components related to an

25
doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml
View File

@@ -24,10 +24,10 @@
ensure that the load balancer can communicate with the
application's HTTP servers without requiring the consumption
of a public IP address.</para>
<para>Since sessions must remain until closing, the routing and
<para>Because sessions persist until they are closed, the routing and
switching architecture is designed for high availability.
Switches are meshed to each hypervisor and to each other, and
also provide an MLAG implementation to ensure layer-2
Switches are meshed to each hypervisor and each other, and
also provide an MLAG implementation to ensure that layer-2
connectivity does not fail. Routers are configured with VRRP
and fully meshed with switches to ensure layer-3 connectivity.
Since GRE is used as an overlay network, Networking is installed
@@ -91,13 +91,18 @@
direct server return. This aids in address planning and
utilization at scale since only the virtual IP (VIP) must be
public.</para></section>
<section xml:id="overlay-networks"><title>Overlay networks</title>
<para>OpenStack Networking using the Open vSwitch GRE tunnel mode
was included in the design to provide overlay functionality.
In this case, the layer-3 external routers will be in a pair
with VRRP and switches should be paired with an implementation
of MLAG running to ensure that there is no loss of
connectivity with the upstream routing infrastructure.</para></section>
<section xml:id="overlay-networks">
<title>Overlay networks</title>
<para>
The overlay functionality design includes OpenStack Networking
in Open vSwitch GRE tunnel mode.
In this case, the layer-3 external routers are paired with
VRRP and switches should be paired with an implementation of
MLAG running to ensure that you do not lose connectivity with
the upstream routing infrastructure.
</para>
</section>
<section xml:id="performance-tuning">
<title>Performance tuning</title>
<para>Network level tuning for this workload is minimal.

86
doc/arch-design/network_focus/section_tech_considerations_network_focus.xml
View File

@@ -6,33 +6,34 @@
xml:id="technical-considerations-network-focus">
<?dbhtml stop-chunking?>
<title>Technical considerations</title>
<para>Designing an OpenStack network architecture involves a
combination of layer-2 and layer-3 considerations. Layer-2
<para>When you design an OpenStack network architecture, you must
consider layer-2 and layer-3 issues. Layer-2
decisions involve those made at the data-link layer, such as
the decision to use Ethernet versus Token Ring. Layer 3
involve those made about the protocol layer and the point at
which IP comes into the picture. As an example, a completely
the decision to use Ethernet versus Token Ring. Layer-3 decisions
involve those made about the protocol layer and the point when
IP comes into the picture. As an example, a completely
internal OpenStack network can exist at layer 2 and ignore
layer 3 however, in order for any traffic to go outside of
that cloud, to another network, or to the Internet, a layer-3
router or switch must be involved.</para>
<para>The past few years have seen two competing trends in
networking. There has been a trend towards building data
center network architectures based on layer-2 networking and
simultaneously another network architecture approach is to
treat the cloud environment essentially as a miniature version
of the Internet. This represents a radically different
approach to the network architecture from what is currently
installed in the staging environment because the Internet is
based entirely on layer-3 routing rather than layer-2
switching.</para>
<para>In the data center context, there are advantages of
designing the network on layer-2 protocols rather than layer
3. In spite of the difficulties of using a bridge to perform
the network role of a router, many vendors, customers, and
service providers are attracted to the idea of using Ethernet
in as many parts of their networks as possible. The benefits
of selecting a layer-2 design are:</para>
<para>
The past few years have seen two competing trends in
networking. One trend leans towards building data center network
architectures based on layer-2 networking. Another trend treats
the cloud environment essentially as a miniature version of the
Internet. This approach is radically different from the network
architecture approach that is used in the staging environment:
the Internet is based entirely on layer-3 routing rather than
layer-2 switching.
</para>
<para>
A network designed on layer-2 protocols has advantages over one
designed on layer-3 protocols. In spite of the difficulties of
using a bridge to perform the network role of a router, many
vendors, customers, and service providers choose to use Ethernet
in as many parts of their networks as possible. The benefits of
selecting a layer-2 design are:
</para>
<itemizedlist>
<listitem>
<para>Ethernet frames contain all the essentials for
@@ -67,17 +68,36 @@
destination can be done in the form of Ethernet frames, more
of the benefits of Ethernet can be realized on the network.
Though it is not a substitute for IP networking, networking at
layer 2 can be a powerful adjunct to IP networking.</para>
<para>The basic reasoning behind using layer-2 Ethernet over layer-3
IP networks is the speed, the reduced overhead of the IP
hierarchy, and the lack of requirement to keep track of IP
address configuration as systems are moved around. Whereas the
simplicity of layer-2 protocols might work well in a data
center with hundreds of physical machines, cloud data centers
have the additional burden of needing to keep track of all
virtual machine addresses and networks. In these data centers,
it is not uncommon for one physical node to support 30-40
instances.</para>
layer 2 can be a powerful adjunct to IP networking.
</para>
<para>
Layer-2 Ethernet usage has these advantages over layer-3 IP
network usage:
</para>
<itemizedlist>
<listitem>
<para>
Speed
</para>
</listitem>
<listitem>
<para>
Reduced overhead of the IP hierarchy.
</para>
</listitem>
<listitem>
<para>
No need to keep track of address configuration as systems
are moved around. Whereas the simplicity of layer-2
protocols might work well in a data center with hundreds
of physical machines, cloud data centers have the
additional burden of needing to keep track of all virtual
machine addresses and networks. In these data centers, it
is not uncommon for one physical node to support 30-40
instances.
</para>
</listitem>
</itemizedlist>
<important>
<para>
Networking at the frame level says nothing