openstack/openstack-manuals
Code Issues Proposed changes

First overview and cleanup of network focused chapter

Browse Source 
This is a removal of out of date information from the guide
as well as removing the sections being moved into common

Change-Id: I4dc89ddaaf6d0e2338852d37fecf61a6eeb73a30
Implements: blueprint arch-guide
This commit is contained in:
Graeme Gillies 2015-08-13 14:05:58 +10:00
parent d9ef521591
commit b8024e511b
3 changed files with 8 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
doc/arch-design/ch_network_focus.xml
View File

@ -37,8 +37,7 @@
<listitem>
<para>Use this cloud to provide network service functions built to
support the delivery of back-end network services such as DNS,
NTP, or SNMP. A company can use these services for internal
network management.</para>
NTP, or SNMP.</para>
</listitem>
</varlistentry>
<varlistentry>

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

@ -31,19 +31,12 @@
functions that it cannot provide. For many of these, you may require
external systems or equipment to fill in the functional gaps. Hardware
load balancers are an example of equipment that may be necessary to
distribute workloads or offload certain functions. As of the Icehouse
release, dynamic routing is currently in its infancy within OpenStack and
you may require an external device or a specialized service instance
within OpenStack to implement it. OpenStack Networking provides a
tunneling feature, however it is constrained to a Networking-managed
region. If the need arises to extend a tunnel beyond the OpenStack region
to either another region or an external system, implement the tunnel
itself outside OpenStack or use a tunnel management system to map the
tunnel or overlay to an external tunnel. OpenStack does not currently
provide quotas for network resources. Where network quotas are required,
implement quality of service management outside of OpenStack. In many of
these instances, similar solutions for traffic shaping or other network
functions are needed.
distribute workloads or offload certain functions. OpenStack Networking
provides a tunneling feature, however it is constrained to a
Networking-managed region. If the need arises to extend a tunnel beyond
the OpenStack region to either another region or an external system,
implement the tunnel itself outside OpenStack or use a tunnel management
system to map the tunnel or overlay to an external tunnel.
</para>
<para>
Depending on the selected design, Networking itself might not
@ -125,10 +118,7 @@
<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.
As of the Icehouse release, this only includes stateless
address auto configuration but work is in progress to support stateless
and stateful DHCPv6 as well as IPv6 floating IPs without NAT. Some
workloads are possible through the use of IPv6 and IPv6 to IPv4
Some workloads are possible through the use of IPv6 and IPv6 to IPv4
reverse transition mechanisms such as NAT64 and DNS64 or
<glossterm>6to4</glossterm>.
This alters the requirements for any address plan as single-stacked and

61
doc/arch-design/network_focus/section_user_requirements_network_focus.xml
View File

@ -21,44 +21,7 @@
for the end-user, as well as productivity and economic loss.
</para>
</listitem>
<listitem>
<para>Regulatory requirements: Consider regulatory
requirements about the physical location of data as it traverses
the network. In addition, maintain network segregation of private
data flows while ensuring an encrypted network between cloud
locations where required. Regulatory requirements for encryption
and protection of data in flight affect network architectures as
the data moves through various networks.</para>
</listitem>
</itemizedlist>
<para>Many jurisdictions have legislative and regulatory requirements
governing the storage and management of data in cloud environments.
Common areas of regulation include:</para>
<itemizedlist>
<listitem>
<para>Data retention policies ensuring storage of persistent data
and records management to meet data archival requirements.</para>
</listitem>
<listitem>
<para>Data ownership policies governing the possession and
responsibility for data.</para>
</listitem>
<listitem>
<para>Data sovereignty policies governing the storage of data in
foreign countries or otherwise separate jurisdictions.</para>
</listitem>
<listitem>
<para>Data compliance policies govern where information can and
cannot reside in certain locations.</para>
</listitem>
</itemizedlist>
<para>Examples of such legal frameworks include the data protection
framework of the European Union
(<link xlink:href="http://ec.europa.eu/justice/data-protection/">http://ec.europa.eu/justice/data-protection/</link>)
and the requirements of the Financial Industry Regulatory Authority
(<link xlink:href="http://www.finra.org/Industry/Regulation/FINRARules">http://www.finra.org/Industry/Regulation/FINRARules</link>)
in the United States. Consult a local regulatory body for more
information.</para>
<section xml:id="high-availability-issues-network-focus">
<title>High availability issues</title>
<para>Depending on the application and use case, network-intensive
@ -138,28 +101,4 @@
</varlistentry>
</variablelist>
</section>
<section xml:id="security-network-focus"><title>Security</title>
<para>Users often overlook or add security after a design implementation.
Consider security implications and requirements before designing the
physical and logical network topologies. Make sure that the networks are
properly segregated and traffic flows are going to the correct
destinations without crossing through locations that are undesirable.
Consider the following example factors:</para>
<itemizedlist>
<listitem>
<para>Firewalls</para>
</listitem>
<listitem>
<para>Overlay interconnects for joining separated tenant networks</para>
</listitem>
<listitem>
<para>Routing through or avoiding specific networks</para>
</listitem>
</itemizedlist>
<para>How networks attach to hypervisors can expose security
vulnerabilities. To mitigate against exploiting hypervisor breakouts,
separate networks from other systems and schedule instances for the
network onto dedicated compute nodes. This prevents attackers
from having access to the networks from a compromised instance.</para>
</section>
</section>