openstack/openstack-manuals
Code Issues Proposed changes

Arch Design Edits

Browse Source 
Cleanup markup.
Improve usage of project names and their capitalization.
Use legacy networking (nova-networking) and OpenStack Networking in a
consistent way.

Change-Id: If818f00aaf06539749d4f28e8a8c5c8290e847a2
This commit is contained in:
Andreas Jaeger
2014-08-08 20:59:57 +02:00
parent 2c5a077cbe
commit 056398f678
16 changed files with 278 additions and 145 deletions
Download Patch File Download Diff File Expand all files Collapse all files

183
doc/arch-design/compute_focus/section_architecture_compute_focus.xml
View File

@@ -29,24 +29,36 @@
not otherwise intensive.</para>
<para>Compute (server) hardware must be evaluated against four opposing
dimensions:</para>
<itemizedlist>
<variablelist>
<varlistentry>
<term>Server density</term>
<listitem>
<para>Server density: A measure of how many servers can fit into a
<para>A measure of how many servers can fit into a
given measure of physical space, such as a rack unit [U].</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Resource capacity</term>
<listitem>
<para>Resource capacity: The number of CPU cores, how much RAM, or how
<para>The number of CPU cores, how much RAM, or how
much storage a given server will deliver.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Expandability</term>
<listitem>
<para>Expandability: The number of additional resources that can be
<para>The number of additional resources that can be
added to a server before it has reached its limit.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Cost</term>
<listitem>
<para>Cost: The relative purchase price of the hardware weighted
<para>The relative purchase price of the hardware weighted
against the level of design effort needed to build the system.</para>
</listitem>
</itemizedlist>
</varlistentry>
</variablelist>
<para>The dimensions need to be weighted against each other to determine the
best design for the desired purpose. For example, increasing server density
means sacrificing resource capacity or expandability. Increasing resource
@@ -112,30 +124,39 @@
<para>The following facts will strongly influence server hardware
selection for a compute-focused OpenStack design
architecture:</para>
<itemizedlist>
<variablelist>
<varlistentry>
<term>Instance density</term>
<listitem>
<para>Instance density: In this architecture instance density is
<para>In this architecture instance density is
considered lower; therefore CPU and RAM over-subscription ratios are
also lower. More hosts will be required to support the anticipated
scale due to instance density being lower, especially if the
design uses dual-socket hardware designs.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Host density</term>
<listitem>
<para>Host density: Another option to address the higher host count
<para>Another option to address the higher host count
that might be needed with dual socket designs is to use a quad
socket platform. Taking this approach will decrease host density,
which increases rack count. This configuration may
affect the network requirements, the number of power connections, and
possibly impact the cooling requirements.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Power and cooling density</term>
<listitem>
<para>Power and cooling density: The power and cooling density
<para>The power and cooling density
requirements might be lower than with blade, sled, or 1U server
designs because of lower host density (by using 2U, 3U or even 4U
server designs). For data centers with older infrastructure, this may
be a desirable feature.</para>
</listitem>
</itemizedlist>
</varlistentry>
</variablelist>
<para>Compute-focused OpenStack design architecture server hardware
selection results in a "scale up" versus "scale out" decision.
Selecting a better solution, smaller number of larger hosts, or a
@@ -148,14 +169,19 @@
storage hardware is not critical as it is not primary criteria, however
it is still important. There are a number of different factors that a
cloud architect must consider:</para>
<itemizedlist>
<variablelist>
<varlistentry>
<term>Cost</term>
<listitem>
<para>Cost: The overall cost of the solution will play a major role
<para>The overall cost of the solution will play a major role
in what storage architecture (and resulting storage hardware) is
selected.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Performance</term>
<listitem>
<para>Performance: The performance of the solution is also a big
<para>The performance of the solution is also a big
role and can be measured by observing the latency of storage I-O
requests. In a compute-focused OpenStack cloud, storage latency
can be a major consideration. In some compute-intensive
@@ -163,8 +189,11 @@
fetching data from the storage can have a significant impact on
the overall performance of the application.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Scalability</term>
<listitem>
<para>Scalability: This section will refer to the term "scalability"
<para>This section will refer to the term "scalability"
to refer to how well the storage solution performs as it is
expanded up to its maximum size. A storage solution that performs
well in small configurations but has degrading
@@ -172,15 +201,19 @@
the other hand, a solution that continues to perform well at
maximum expansion would be considered scalable.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Expandability</term>
<listitem>
<para>Expandability: Expandability refers to the overall ability of
<para>Expandability refers to the overall ability of
the solution to grow. A storage solution that expands to 50 PB is
considered more expandable than a solution that only scales to 10PB.
Note that this metric is related to, but different
from, scalability, which is a measure of the solution's
performance as it expands.</para>
</listitem>
</itemizedlist>
</varlistentry>
</variablelist>
<para>For a compute-focused OpenStack cloud, latency of storage is a
major consideration. Using solid-state disks (SSDs) to minimize
latency for instance storage and reduce CPU delays caused by waiting
@@ -204,9 +237,11 @@
<para>The following lists some of the potential impacts that may affect a
particular storage architecture, and the corresponding storage hardware,
of a compute-focused OpenStack cloud:</para>
<itemizedlist>
<variablelist>
<varlistentry>
<term>Connectivity</term>
<listitem>
<para>Connectivity: Based on the storage solution selected, ensure
<para>Based on the storage solution selected, ensure
the connectivity matches the storage solution requirements. If a
centralized storage array is selected, it is important to determine
how the hypervisors will connect to the storage array. Connectivity
@@ -214,23 +249,33 @@
characteristics will minimize latency to boost the overall
performance of the design.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Latency</term>
<listitem>
<para>Latency: Determine if the use case will have consistent or
<para>Determine if the use case will have consistent or
highly variable latency.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Throughput</term>
<listitem>
<para>Throughput: To improve overall performance, make sure that the
<para>To improve overall performance, make sure that the
storage solution throughout is optimized. While it is not likely
that a compute-focused cloud will have major data I-O to and
from storage, this is an important factor to consider.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Server Hardware</term>
<listitem>
<para>Server Hardware: If the solution uses DAS, this impacts, and
<para>If the solution uses DAS, this impacts, and
is not limited to, the server hardware choice that will ripple into
host density, instance density, power density, OS-hypervisor, and
management tools.</para>
</listitem>
</itemizedlist>
</varlistentry>
</variablelist>
<para>Where instances need to be made highly available, or they need to be
capable of migration between hosts, use of a shared storage file-system
to store instance ephemeral data should be employed to ensure that
@@ -241,13 +286,18 @@
<title>Selecting networking hardware</title>
<para>Some of the key considerations that should be included in
the selection of networking hardware include:</para>
<itemizedlist>
<variablelist>
<varlistentry>
<term>Port count</term>
<listitem>
<para>Port count: The design will require networking hardware that
<para>The design will require networking hardware that
has the requisite port count.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Port density</term>
<listitem>
<para>Port density: The network design will be affected by the
<para>The network design will be affected by the
physical space that is required to provide the requisite port count.
A switch that can provide 48 10 GbE ports in 1U has a much higher
port density than a switch that provides 24 10 GbE ports in 2U. A
@@ -258,13 +308,19 @@
expensive and should also be considered, as it is important not to
over design the network if it is not required.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Port speed</term>
<listitem>
<para>Port speed: The networking hardware must support the proposed
<para>The networking hardware must support the proposed
network speed, for example: 1 GbE, 10 GbE, or 40 GbE (or even 100
GbE).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Redundancy</term>
<listitem>
<para>Redundancy: The level of network hardware redundancy required
<para>The level of network hardware redundancy required
is influenced by the user requirements for high availability and
cost considerations. Network redundancy can be achieved by adding
redundant power supplies or paired switches. If this is a
@@ -272,14 +328,18 @@
User requirements will determine if a completely redundant network
infrastructure is required.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Power requirements</term>
<listitem>
<para>Power requirements: Ensure that the physical data center
<para>Ensure that the physical data center
provides the necessary power for the selected network hardware. This
is not an issue for top of rack (ToR) switches, but may be an issue
for spine switches in a leaf and spine fabric, or end of row (EoR)
switches.</para>
</listitem>
</itemizedlist>
</varlistentry>
</variablelist>
<para>It is important to first understand additional factors as well as
the use case because these additional factors heavily influence the
cloud network architecture. Once these key considerations have been
@@ -331,9 +391,11 @@
Control Protocol (LACP), the hypervisor needs to support it.</para>
<para>Some areas that could be impacted by the selection of OS and
hypervisor include:</para>
<itemizedlist>
<variablelist>
<varlistentry>
<term>Cost</term>
<listitem>
<para>Cost: Selecting a commercially supported hypervisor such as
<para>Selecting a commercially supported hypervisor such as
Microsoft Hyper-V will result in a different cost model rather than
chosen a community-supported open source hypervisor like Kinstance
or Xen. Even within the ranks of open source solutions, choosing
@@ -342,46 +404,64 @@
requirements might dictate a specific or commercially supported
hypervisor.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Supportability</term>
<listitem>
<para>Supportability: Depending on the selected hypervisor, the staff
<para>Depending on the selected hypervisor, the staff
should have the appropriate training and knowledge to support the
selected OS and hypervisor combination. If they do not, training
will need to be provided which could have a cost impact on the
design.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Management tools</term>
<listitem>
<para>Management tools: The management tools used for Ubuntu and
<para>The management tools used for Ubuntu and
Kinstance differ from the management tools for VMware vSphere.
Although both OS and hypervisor combinations are supported by
OpenStack, there will be very different impacts to the rest of the
design as a result of the selection of one combination versus the
other.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Scale and performance</term>
<listitem>
<para>Scale and performance: Ensure that selected OS and hypervisor
<para>Ensure that selected OS and hypervisor
combinations meet the appropriate scale and performance
requirements. The chosen architecture will need to meet the targeted
instance-host ratios with the selected OS-hypervisor
combination.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Security</term>
<listitem>
<para>Security: Ensure that the design can accommodate the regular
<para>Ensure that the design can accommodate the regular
periodic installation of application security patches while
maintaining the required workloads. The frequency of security
patches for the proposed OS - hypervisor combination will have an
impact on performance and the patch installation process could
affect maintenance windows.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Supported features</term>
<listitem>
<para>Supported features: Determine what features of OpenStack are
<para>Determine what features of OpenStack are
required. This will often determine the selection of the
OS-hypervisor combination. Certain features are only available with
specific OSs or hypervisors. For example, if certain features are
not available, the design might need to be modified to meet the user
requirements.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Interoperability</term>
<listitem>
<para>Interoperability: Consideration should be given to the ability
<para>Consideration should be given to the ability
of the selected OS-hypervisor combination to interoperate or
co-exist with other OS-hypervisors, or other software solutions in
the overall design (if required). Operational and troubleshooting
@@ -390,42 +470,43 @@
as a result, the design will need to address if the
two sets of tools need to interoperate.</para>
</listitem>
</itemizedlist>
</varlistentry>
</variablelist>
</section>
<section xml:id="openstack-components-arch">
<title>OpenStack components</title>
<para>The selection of which OpenStack components will actually be
included in the design and deployed has significant impact. There are
certain components that will always be present, (Nova and Glance, for
certain components that will always be present, (Compute and Image Service, for
example) yet there are other services that might not need to be present.
For example, a certain design may not require the Orchestration module.
Omitting Heat would not typically have a significant impact on the
overall design. However, if the architecture uses a replacement for
OpenStack Swift for its storage component, this could potentially have
OpenStack Object Storage for its storage component, this could potentially have
significant impacts on the rest of the design.</para>
<para>For a compute-focused OpenStack design architecture, the
following components would be used:</para>
<itemizedlist>
<listitem>
<para>Identity (Keystone)</para>
<para>Identity (keystone)</para>
</listitem>
<listitem>
<para>Dashboard (Horizon)</para>
<para>Dashboard (horizon)</para>
</listitem>
<listitem>
<para>Compute (Nova)</para>
<para>Compute (nova)</para>
</listitem>
<listitem>
<para>Object Storage (Swift, Ceph or a commercial solution)</para>
<para>Object Storage (swift, ceph or a commercial solution)</para>
</listitem>
<listitem>
<para>Image (Glance)</para>
<para>Image (glance)</para>
</listitem>
<listitem>
<para>Networking (Neutron)</para>
<para>Networking (neutron)</para>
</listitem>
<listitem>
<para>Orchestration (Heat)</para>
<para>Orchestration (heat)</para>
</listitem>
</itemizedlist>
<para>OpenStack Block Storage would potentially not be incorporated
@@ -494,7 +575,7 @@
example). Some other potential design impacts include:</para>
<itemizedlist>
<listitem>
<para>OS - Hypervisor combination: Ensure that the selected logging,
<para>OS-hypervisor combination: Ensure that the selected logging,
monitoring, or alerting tools support the proposed OS-hypervisor
combination.</para>
</listitem>
@@ -512,12 +593,12 @@
satisfy the availability and fault tolerance requirements of the
OpenStack services is required. OpenStack services support connecting
to any database that is supported by the sqlalchemy Python drivers,
however most common database deployments make use of mySQL or some
however most common database deployments make use of MySQL or some
variation of it. It is recommended that the database which provides
back-end service within a general purpose cloud be made highly
available using an available technology which can accomplish that
goal. Some of the more common software solutions used include Galera,
MariaDB and mySQL with multi-master replication.</para>
MariaDB and MySQL with multi-master replication.</para>
</section>
</section>
</section>

4
doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml
View File

@@ -101,7 +101,7 @@
<section xml:id="network-architecture">
<title>Network architecture</title>
<para>To integrate with existing CERN networking infrastructure
customizations were made to Nova Networking. This was in the
customizations were made to legacy networking (nova-network). This was in the
form of a driver to integrate with CERN's existing database
for tracking MAC and IP address assignments.</para>
<para>The driver facilitates selection of a MAC address and IP for
@@ -114,7 +114,7 @@
the addresses were assigned to.</para></section>
<section xml:id="storage-architecture">
<title>Storage architecture</title>
<para>The OpenStack image service is deployed in the API cell and
<para>The OpenStack Image Service is deployed in the API cell and
configured to expose version 1 (V1) of the API. As a result
the image registry is also required. The storage back end in
use is a 3 PB Ceph cluster.</para>

12
doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml
View File

@@ -364,13 +364,13 @@
components:</para>
<itemizedlist>
<listitem>
<para>OpenStack Compute (Nova)</para>
<para>OpenStack Compute (nova)</para>
</listitem>
<listitem>
<para>OpenStack Image Service (Glance)</para>
<para>OpenStack Image Service (glance)</para>
</listitem>
<listitem>
<para>OpenStack Identity Service (Keystone)</para>
<para>OpenStack Identity (keystone)</para>
</listitem>
</itemizedlist>
<para>Also consider several specialized components:</para>
@@ -401,15 +401,15 @@
<link xlink:href="http://docs.openstack.org/openstack-ops/content/logging_monitoring.html">http://docs.openstack.org/openstack-ops/content/logging_monitoring.html</link></para>
<itemizedlist>
<listitem>
<para>OpenStack Block Storage (Cinder)</para>
<para>OpenStack Block Storage (cinder)</para>
</listitem>
</itemizedlist>
<para>Due to the burst-able nature of the workloads and the
applications and instances that will be used for batch
processing, this cloud will utilize mainly memory or CPU, so
the need for add-on storage to each instance is not a likely
requirement. This does not mean the OpenStack Block Storage
service (cinder) will not be used in the infrastructure, but
requirement. This does not mean that OpenStack Block Storage
(cinder) will not be used in the infrastructure, but
typically it will not be used as a central component.</para>
<itemizedlist>
<listitem>

2
doc/arch-design/generalpurpose/section_architecture_general_purpose.xml
View File

@@ -732,7 +732,7 @@
required. As an example, a certain design might not need
Orchestration. Omitting Orchestration would not have a significant
impact on the overall design of a cloud; however, if the
architecture uses a replacement for OpenStack Swift for its
architecture uses a replacement for OpenStack Object Storage for its
storage component, it could potentially have significant
impacts on the rest of the design.</para>
<para>The exclusion of certain OpenStack components might also

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

@@ -130,21 +130,21 @@
<para>Based on the requirements of instances being serviced in the
cloud, the next design choice which will affect your design is
the choice of network service which will be used to service
instances in the cloud. The choice between nova-network, as a
part of OpenStack Compute Service, and Neutron, the OpenStack
Networking Service, has tremendous implications and will have
instances in the cloud. The choice between legacy networking (nova-network), as a
part of OpenStack Compute Service, and OpenStack Networking
(neutron), has tremendous implications and will have
a huge impact on the architecture and design of the cloud
network infrastructure.</para>
<para>The nova-network service is primarily a layer 2 networking
<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 nova-network pertain
to whether or not nova-network uses VLANs. When using
nova-network in a flat network mode, all network hardware
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>When the network devices in the cloud support segmentation
using VLANs, nova-network can operate in the second mode. In
using VLANs, legacy networking can operate in the second mode. In
this design model, each tenant within the cloud is assigned a
network subnet which is mapped to a VLAN on the physical
network. It is especially important to remember the maximum
@@ -152,16 +152,16 @@
domain. These limitations place hard limits on the amount of
growth possible within the data center. When designing a
general purpose cloud intended to support multiple tenants, it
is especially recommended to use nova-network with VLANs, and
is especially recommended to use legacy networking with VLANs, and
not in flat network mode.</para>
<para>Another consideration regarding network is the fact that
nova-network is entirely managed by the cloud operator;
legacy networking is entirely managed by the cloud operator;
tenants do not have control over network resources. If tenants
require the ability to manage and create network resources
such as network segments and subnets, it will be necessary to
install the OpenStack Networking Service to provide network
install the OpenStack Networking service to provide network
access to instances.</para>
<para>The OpenStack Networking Service is a first class networking
<para>OpenStack Networking is a first class networking
service that gives full control over creation of virtual
network resources to tenants. This is often accomplished in
the form of tunneling protocols which will establish
@@ -316,7 +316,7 @@
A cloud architect who selects Ubuntu or RHEL has some
flexibility in hypervisor; KVM, Xen, and LXC are supported
virtualization methods available under OpenStack Compute
(Nova) on these Linux distributions. A cloud architect who
(nova) on these Linux distributions. A cloud architect who
selects Hyper-V, on the other hand, is limited to Windows
Server. Similarly, a cloud architect who selects XenServer is
limited to the CentOS-based dom0 operating system provided
@@ -427,7 +427,7 @@
</listitem>
</itemizedlist>
<para>A general purpose cloud may also include OpenStack Object
Storage (Swift). OpenStack Block Storage (Cinder) may be
Storage (swift). OpenStack Block Storage (cinder) may be
selected to provide persistent storage to applications and
instances although, depending on the use case, this could be
optional.</para></section>
@@ -591,34 +591,36 @@
server utilization and response times, as well as load testing
your systems, will help determine scale out decisions.</para>
<para>Care must be taken when deciding network functionality.
Currently, OpenStack supports both the legacy Nova-network
Currently, OpenStack supports both the legacy networking (nova-network)
system and the newer, extensible OpenStack Networking. Both
have their pros and cons when it comes to providing highly
available access. Nova-network, which provides networking
available access. Legacy networking, which provides networking
access maintained in the OpenStack Compute code, provides a
feature that removes a single point of failure when it comes
to routing, and this feature is currently missing in OpenStack
Networking. The effect of Nova network’s Multi-Host
Networking. The effect of legacy networking’s multi-host
functionality restricts failure domains to the host running
that instance.</para>
<para>On the other hand, when using OpenStack Networking, the
OpenStack controller servers or separate OpenStack Networking
OpenStack controller servers or separate Networking
hosts handle routing. For a deployment that requires features
available in only OpenStack Networking, it is possible to
available in only Networking, it is possible to
remove this restriction by using third party software that
helps maintain highly available L3 routes. Doing so allows for
common APIs to control network hardware, or to provide complex
multi-tier web applications in a secure manner. It is also
possible to completely remove routing from OpenStack
possible to completely remove routing from
Networking, and instead rely on hardware routing capabilities.
In this case, the switching infrastructure must support L3
routing.</para>
<para>OpenStack Networking (neutron) and nova-network both have their
advantages and disadvantages. They are both valid and supported
options that fit different network deployment models described in
the <citetitle><link
xlink:href="http://docs.openstack.org/openstack-ops/content/network_design.html#network_deployment_options"
>OpenStack Operations Guide</link></citetitle>.</para>
<para>
OpenStack Networking (neutron) and legacy networking
(nova-network) both have their advantages and
disadvantages. They are both valid and supported options that
fit different network deployment models described in the
<citetitle><link
xlink:href="http://docs.openstack.org/openstack-ops/content/network_design.html#network_deployment_options"
>OpenStack Operations Guide</link></citetitle>.</para>
<para>Ensure your deployment has adequate back-up capabilities. As
an example, in a deployment that has two infrastructure
controller nodes, the design should include controller

2
doc/arch-design/hybrid/section_tech_considerations_hybrid.xml
View File

@@ -296,7 +296,7 @@
</listitem>
<listitem>
<para>Networking: Whether OpenStack Networking (neutron)
or nova-network is used, the network is one place
or legacy networking (nova-network) is used, the network is one place
where integration capabilities need to be understood
in order to connect between clouds.</para>
</listitem>

4
doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml
View File

@@ -108,10 +108,10 @@
</listitem>
<listitem>
<para>OpenStack Controller services running, Networking,
Horizon, Cinder and Nova compute running locally in
dashboard, Block Storage and Compute running locally in
each of the three regions. The other services,
Identity, Orchestration, Telemetry, Image Service and
Block Storage will be
Object Storage will be
installed centrally&mdash;with nodes in each of the region
providing a redundant OpenStack Controller plane
throughout the globe.</para>

2
doc/arch-design/multi_site/section_tech_considerations_multi_site.xml
View File

@@ -51,7 +51,7 @@
external overlay manager or controller be used to map these
overlays together. It is necessary to ensure the amount of
possible IDs between the zones are identical. Note that, as of
the Icehouse release, Neutron was not capable of managing
the Icehouse release, OpenStack Networking was not capable of managing
tunnel IDs across installations. This means that if one site
runs out of IDs, but other does not, that tenant's network
will be unable to reach the other site.</para>

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

@@ -31,7 +31,7 @@
transaction locks at very high rates. This also has an impact
on the network performance.</para>
<para>Some network dependencies are going to be external to
OpenStack. While Neutron is capable of providing network
OpenStack. While OpenStack Networking is capable of providing network
ports, IP addresses, some level of routing, and overlay
networks, there are some other functions that it cannot
provide. For many of these, external systems or equipment may
@@ -41,8 +41,8 @@
as of the icehouse release, dynamic routing is currently in
its infancy within OpenStack and may need to be implemented
either by an external device or a specialized service instance
within OpenStack. Tunneling is a feature provided by Neutron,
however it is constrained to a Neutron-managed region. If the
within OpenStack. Tunneling is a feature provided by OpenStack Networking,
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, it is necessary
to implement the tunnel itself outside OpenStack or by using a
@@ -53,12 +53,12 @@
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, Neutron itself may not
<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 Neutron without running the layer 3 agent, then an
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>
<para>Interaction with orchestration services is inevitable in
@@ -86,14 +86,14 @@
easier to automate the infrastructure to apply the target IP
to a new instance rather than reconfigure legacy or external
systems for each new instance.</para>
<para>NAT for floating IPs managed by Neutron will reside within
<para>NAT for floating IPs managed by Networking will reside within
the hypervisor but there are also versions of NAT that may be
running elsewhere. If there is a shortage of IPv4 addresses
there are two common methods to mitigate this externally to
OpenStack. The first is to run a load balancer either within
OpenStack as an instance, or use an external load balancing
solution. In the internal scenario, load balancing software,
such as HAproxy, can be managed with Neutron's
such as HAproxy, can be managed with Networking's
Load-Balancer-as-a-Service (LBaaS). This is specifically to
manage the
Virtual IP (VIP) while a dual-homed connection from the
@@ -118,8 +118,9 @@
and which networking model is deployed. Some examples of this
are the use of Link aggregation (LAG) or Hot Standby Router
Protocol (HSRP). There are also the considerations of whether
to deploy Neutron or Nova-network and which plug-in to select
for Neutron. If using an external system, Neutron will need to
to deploy OpenStack Networking or legacy networking (nova-network)
and which plug-in to select
for OpenStack Networking. If using an external system, Networking will need to
be configured to run
<glossterm baseform="Layer-2 network">layer 2</glossterm>
with a provider network
@@ -146,7 +147,7 @@
with throughput or excessive broadcast traffic.</para>
<para>A design decision that many overlook is a choice of layer 3
protocols. While OpenStack was initially built with only IPv4
support, Neutron now supports IPv6 and dual-stacked networks.
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

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

@@ -30,7 +30,7 @@
also provide an MLAG implementation to ensure 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, Neutron is installed
Since GRE is used as an overlay network, Networking is installed
and configured to use the Open vSwitch agent in GRE tunnel
mode. This ensures all devices can reach all other devices and
that tenant networks can be created for private addressing

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

@@ -310,18 +310,18 @@
<para>There are numerous topics to consider when designing a
network-focused OpenStack cloud.</para>
<section xml:id="openstack-networking-versus-nova-network">
<title>OpenStack Networking versus Nova network
<title>OpenStack Networking versus legacy networking (nova-network)
considerations</title>
<para>Selecting the type of networking technology to implement
depends on many factors. OpenStack Networking (Neutron) and
Nova Network both have their advantages and disadvantages.
depends on many factors. OpenStack Networking (neutron) and
legacy networking (nova-network) both have their advantages and disadvantages.
They are both valid and supported options that fit different
use cases as described in the following table.</para>
<informaltable rules="all">
<col width="40%" />
<col width="60%" />
<thead>
<tr><th>Nova Network</th>
<tr><th>Legacy networking (nova-network)</th>
<th>OpenStack Networking</th></tr>
</thead>
<tbody>
@@ -395,9 +395,9 @@
fixes long standing issues in the IPv4 protocol, and will
become an essential for network focused applications in the
future.</para>
<para>Neutron supports IPv6 when configured to take advantage of
<para>OpenStack Networking supports IPv6 when configured to take advantage of
the feature. To enable it, simply create an IPv6 subnet in
OpenStack Neutron and use IPv6 prefixes when creating security
Networking and use IPv6 prefixes when creating security
groups.</para></section>
<section xml:id="asymmetric-links">
<title>Asymmetric links</title>
@@ -426,14 +426,14 @@
designed to properly direct connections to those specific
locations. Use a multi-site installation for these situations,
where appropriate.</para>
<para>OpenStack networking can be implemented in two separate
ways. The legacy nova-network provides a flat DHCP network
<para>Networking can be implemented in two separate
ways. The legacy networking (nova-network) provides a flat DHCP network
with a single broadcast domain. This implementation does not
support tenant isolation networks or advanced plug-ins, but it
is currently the only way to implement a distributed layer 3
agent using the multi_host configuration. Neutron is the
official current implementation of OpenStack Networking. It
provides a pluggable architecture that supports a large
agent using the multi_host configuration.
OpenStack Networking (neutron) is the official networking implementation
and provides a pluggable architecture that supports a large
variety of network methods. Some of these include a layer 2
only provider network model, external device plug-ins, or even
OpenFlow controllers.</para>

4
doc/arch-design/specialized/section_multi_hypervisor_specialized.xml
View File

@@ -66,10 +66,10 @@
hypervisors.</para>
<para>In this case, network connectivity is provided by OpenStack
Networking with the VMware NSX plug-in driver configured.
Alternatively, the system could use nova-network, which is
Alternatively, the system could use legacy networking (nova-network), which is
supported by both hypervisors used in this design, but has
limitations. Specifically, security groups are not supported
on vSphere with nova-network. With VMware NSX as part of the
on vSphere with legacy networking. With VMware NSX as part of the
design, however, when a user launches an instance within
either of the host aggregates, the instances are attached to
appropriate network overlay-based logical networks as defined

6
doc/arch-design/storage_focus/section_architecture_storage_focus.xml
View File

@@ -512,7 +512,7 @@
<title>OpenStack components</title>
<para>The selection of OpenStack components has a significant
direct impact on the overall design. While there are certain
components that will always be present, (Nova and Glance, for
components that will always be present, (Compute and Image Service, for
example) there are other services that may not need to be
present. As an example, a certain design may not require
the Orchestration module. Omitting Orchestration would not typically have a
@@ -521,7 +521,7 @@
storage component, this could potentially have significant
impacts on the rest of the design.</para>
<para>A storage-focused design might require the ability to use
Orchestration to launch instances with Cinder volumes to perform
Orchestration to launch instances with Block Storage volumes to perform
storage-intensive processing.</para>
<para>For a storage-focused OpenStack design architecture, the
following components would typically be used:</para>
@@ -546,7 +546,7 @@
<para>OpenStack Image Service (glance)</para>
</listitem>
<listitem>
<para>OpenStack Networking (neutron) or nova-network</para>
<para>OpenStack Networking (neutron) or legacy networking (nova-network)</para>
</listitem>
</itemizedlist>
<para>The exclusion of certain OpenStack components may limit or

2
doc/arch-design/storage_focus/section_operational_considerations_storage_focus.xml
View File

@@ -160,7 +160,7 @@
additional layer of load balancing to provide access to
back-end database services responsible for servicing and
storing the state of block storage volumes. Designing a highly
available database solution to store the Cinder databases is
available database solution to store the Block Storage databases is
also recommended. A number of highly available database
solutions such as Galera and MariaDB can be leveraged to help
keep database services online to provide uninterrupted access

40
doc/arch-design/storage_focus/section_tech_considerations_storage_focus.xml
View File

@@ -9,11 +9,13 @@
<para>Some of the key technical considerations that are critical
to a storage focused OpenStack design architecture
include:</para>
<itemizedlist>
<variablelist>
<varlistentry>
<term>Input-output requirements</term>
<listitem>
<para>I-O requirements: I-O performance requirements need
<para>Input-Output performance requirements need
to be researched and modeled before deciding on a
final storage framework. Running benchmarks for I-O
final storage framework. Running benchmarks for Input-Output
performance will help provide a baseline for expected
performance levels. If these tests include details,
for example, object size in an object storage system
@@ -27,8 +29,11 @@
scoping and gaining a deeper understanding of an
organization's needs.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Scale</term>
<listitem>
<para>Scale: The scale of the storage solution in a
<para>The scale of the storage solution in a
storage focused OpenStack architecture design is
driven both by initial requirements, including
<glossterm>IOPS</glossterm>,
@@ -40,8 +45,11 @@
for new technologies and methods to be implemented as
they become available.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Security</term>
<listitem>
<para>Security: Security design around data has multiple
<para>Security design around data has multiple
points of focus that vary depending on SLAs, legal
requirements, industry regulations, and certifications
needed for systems or people. HIPPA, ISO9000, and SOX
@@ -49,18 +57,24 @@
data. Levels of access control can be important for
certain organizations.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>OpenStack compatibility</term>
<listitem>
<para>OpenStack compatibility: Interoperability and
<para>Interoperability and
integration with OpenStack can be paramount in
deciding on a storage hardware and storage management
platform. Interoperability and integration includes
factors such as OpenStack Cinder interoperability,
OpenStack Swift compatibility, and hypervisor
factors such as OpenStack Block Storage interoperability,
OpenStack Object Storage compatibility, and hypervisor
compatibility (which affects the ability to use
storage for ephemeral instance storage).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Storage management</term>
<listitem>
<para>Storage management: A range of storage
<para>A range of storage
management-related considerations must be addressed in
the design of a storage focused OpenStack cloud. These
considerations include, but are not limited to, backup
@@ -70,8 +84,11 @@
strategy, data placement, and workflow
automation.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Data grids</term>
<listitem>
<para>Data Grids: Data grids can be helpful in
<para>Data grids can be helpful in
deterministically answering questions around data
valuation. A fundamental challenge of today’s
information sciences is determining which data is
@@ -82,7 +99,8 @@
business-unit revenue with other metadata values to
deliver actionable information about data.</para>
</listitem>
</itemizedlist>
</varlistentry>
</variablelist>
<para>Strive to build a flexible design that is based on a
industry standard core. One way of accomplishing this might be
through the use of different back ends serving different use

63
doc/arch-design/storage_focus/section_user_requirements_storage_focus.xml
View File

@@ -11,9 +11,11 @@
patterns, and data structures. A balance between cost and user
requirements dictate what methods and technologies will be
used in a cloud architecture.</para>
<itemizedlist>
<variablelist>
<varlistentry>
<term>Cost</term>
<listitem>
<para>Cost: The user pays only for the storage they
<para>The user pays only for the storage they
actually use. This limit typically reflects average
user consumption during a month. This does not mean
that cloud storage is less expensive, only that it
@@ -23,41 +25,57 @@
up-front purchase of a large amount of storage that
goes underutilized.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Legal requirements</term>
<listitem>
<para>Legal requirements: Multiple jurisdictions have
<para>Multiple jurisdictions have
legislative and regulatory requirements governing the
storage and management of data in cloud environments.
Common areas of regulation include data retention
policies and data ownership policies.</para>
</listitem>
</itemizedlist>
</varlistentry>
</variablelist>
<section xml:id="legal-requirements-storage-focus">
<title>Legal requirements</title>
<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>
<variablelist>
<varlistentry>
<term>Data retention</term>
<listitem>
<para>Data retention: Policies ensuring storage of
<para>Policies ensuring storage of
persistent data and records management to meet data
archival requirements.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Data ownership</term>
<listitem>
<para>Data ownership: Policies governing the possession
<para>Policies governing the possession
and responsibility for data.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Data sovereignty</term>
<listitem>
<para>Data sovereignty: Policies governing the storage of
<para>Policies governing the storage of
data in foreign countries or otherwise separate
jurisdictions.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Data compliance</term>
<listitem>
<para>Data compliance: Policies governing types of
<para>Policies governing types of
information that are required to reside in certain
locations due to regular issues and cannot reside in
other locations for the same reason.</para>
</listitem>
</itemizedlist>
</varlistentry>
</variablelist>
<para>
Examples of such legal frameworks include the <link
xlink:href="http://ec.europa.eu/justice/data-protection/">data
@@ -72,29 +90,42 @@
<title>Technical requirements</title>
<para>The following are some technical requirements that could be
incorporated into the architecture design.</para>
<itemizedlist>
<variablelist>
<varlistentry>
<term>Storage proximity</term>
<listitem>
<para>Storage Proximity: In order to provide high
<para>In order to provide high
performance or large amounts of storage space the
design may have to accommodate storage that is each of
the hypervisors or served from a central storage
device.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Performance</term>
<listitem>
<para>Performance: To boost performance the organization
<para>To boost performance the organization
may want to make use of different technologies to
cache disk activity.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Availability</term>
<listitem>
<para>Availability: Specific requirements regarding
<para>Specific requirements regarding
availability will influence the technology used to
store and protect data. These requirements will be
influence the cost and solution that will be
implemented.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Security</term>
<listitem>
<para>Security: Data will need to be protected both in
<para>Data will need to be protected both in
transit and at rest.</para>
</listitem>
</itemizedlist></section>
</varlistentry>
</variablelist>
</section>
</section>