openstack/openstack-manuals
Code Issues Proposed changes

Merge "Removal of passive voice from chap 1, arch guide"

Browse Source
This commit is contained in:
Jenkins 2015-02-10 01:51:34 +00:00 committed by Gerrit Code Review
commit 6b4aa47f9a
1 changed files with 335 additions and 228 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -10,48 +10,71 @@
xml:id="technical-considerations-general-purpose"> xml:id="technical-considerations-general-purpose">
<?dbhtml stop-chunking?> <?dbhtml stop-chunking?>
<title>Technical considerations</title> <title>Technical considerations</title>
<para>When designing a general purpose cloud, there is an implied <para>General purpose clouds are often expected to
requirement to design for all of the base services generally include these base services:</para>
associated with providing Infrastructure-as-a-Service: <itemizedlist>
compute, network and storage. Each of these services have <listitem>
different resource requirements. As a result, it is important <para>
to make design decisions relating directly to the service Compute
currently under design, while providing a balanced </para>
infrastructure that provides for all services.</para> </listitem>
<para>When designing an OpenStack cloud as a general purpose <listitem>
cloud, the hardware selection process can be lengthy and <para>
involved due to the sheer mass of services which need to be Network
designed and the unique characteristics and requirements of </para>
each service within the cloud. Hardware designs need to be </listitem>
generated for each type of resource pool; specifically, <listitem>
compute, network, and storage. In addition to the hardware <para>
designs, which affect the resource nodes themselves, there are Storage
also a number of additional hardware decisions to be made </para>
related to network architecture and facilities planning. These </listitem>
factors play heavily into the overall architecture of an </itemizedlist>
OpenStack cloud.</para> <para>Each of these services has different resource requirements.
As a result, you must make design decisions relating directly
to the service, as well as provide a balanced infrastructure for all services.</para>
<para>Consider the unique aspects of each service that requires design since
individual characteristics and service mass can impact the hardware selection
process. Hardware designs are generated for each type of the
following resource pools:</para>
<itemizedlist>
<listitem>
<para>
Compute
</para>
</listitem>
<listitem>
<para>
Network
</para>
</listitem>
<listitem>
<para>
Storage
</para>
</listitem>
</itemizedlist>
<para>Hardware decisions are also made in relation to network architecture
and facilities planning. These factors play heavily into
the overall architecture of an OpenStack cloud.</para>
<section xml:id="designing-compute-resources-tech-considerations"> <section xml:id="designing-compute-resources-tech-considerations">
<title>Designing compute resources</title> <title>Designing compute resources</title>
<para>We recommend you design compute resources as pools of <para>When designing compute resource pools, a number of factors
resources which will be addressed on-demand. When designing can impact your design decisions.
compute resource pools, a number of factors impact your design For example, decisions related to processors, memory, and
decisions. For example, decisions related to processors, storage within each hypervisor are just one element of designing
memory, and storage within each hypervisor are just one compute resources. In addition, decide whether to provide compute
element of designing compute resources. In addition, it is resources in a single pool or in multiple pools.
necessary to decide whether compute resources will be provided We recommend the compute design allocates multiple pools of resources to
in a single pool or in multiple pools.</para> be addressed on-demand.</para>
<para>To design for the best use of available resources by <para>A compute design that allocates multiple pools of resources makes best
applications running in the cloud, we recommend you design use of application resources running in the cloud.
more than one compute resource pool. Each independent resource Each independent resource pool should be designed to provide service for specific
pool should be designed to provide service for specific flavors of instances or groupings of flavors.
flavors of instances or groupings of flavors. For the purpose Designing multiple resource pools helps to ensure that, as instances are
of this book, "instance" refers to a virtual machine and the
operating system running on the virtual machine. Designing
multiple resource pools helps to ensure that, as instances are
scheduled onto compute hypervisors, each independent node's scheduled onto compute hypervisors, each independent node's
resources will be allocated in a way that makes the most resources will be allocated to make the most efficient use of available
efficient use of available hardware. This is commonly referred hardware. This is commonly referred to as bin packing.</para>
to as bin packing.</para>
<para>Using a consistent hardware design among the nodes that are <para>Using a consistent hardware design among the nodes that are
placed within a resource pool also helps support bin packing. placed within a resource pool also helps support bin packing.
Hardware nodes selected for being a part of a compute resource Hardware nodes selected for being a part of a compute resource
@ -59,15 +82,14 @@
layout. By choosing a common hardware design, it becomes layout. By choosing a common hardware design, it becomes
easier to deploy, support and maintain those nodes throughout easier to deploy, support and maintain those nodes throughout
their life cycle in the cloud.</para> their life cycle in the cloud.</para>
<para>OpenStack provides the ability to configure overcommit <para>An <firstterm>overcommit ratio</firstterm> is the ratio of available
ratio&mdash;the ratio of virtual resources available for allocation virtual resources, compared to the available physical resources.
to physical resources present&mdash;for both CPU and memory. The OpenStack is able to configure the overcommit ratio for CPU and memory.
default CPU overcommit ratio is 16:1 and the default memory The default CPU overcommit ratio is 16:1 and the default memory
overcommit ratio is 1.5:1. Determine the tuning of the overcommit ratio is 1.5:1. Determining the tuning of the overcommit
overcommit ratios for both of these options during the design ratios for both of these options during the design phase is important
phase, as this has a direct impact on the hardware layout of as it has a direct impact on the hardware layout of your compute nodes.</para>
your compute nodes.</para> <para>For example, consider a m1.small instance uses 1
<para>As an example, consider that a m1.small instance uses 1
vCPU, 20&nbsp;GB of ephemeral storage and 2,048&nbsp;MB of RAM. When vCPU, 20&nbsp;GB of ephemeral storage and 2,048&nbsp;MB of RAM. When
designing a hardware node as a compute resource pool to designing a hardware node as a compute resource pool to
service instances, take into consideration the number of service instances, take into consideration the number of
@ -83,77 +105,97 @@
required to service operating system and service needs.</para> required to service operating system and service needs.</para>
<para>Processor selection is an extremely important consideration <para>Processor selection is an extremely important consideration
in hardware design, especially when comparing the features and in hardware design, especially when comparing the features and
performance characteristics of different processors. Some performance characteristics of different processors. Processors
newly released processors include features specific to can include features specific to virtualized compute hosts including
virtualized compute hosts including hardware assisted hardware assisted virtualization and technology related to memory paging (also
virtualization and technology related to memory paging (also known as EPT shadowing). These types of features can have a significant impact on the
known as EPT shadowing). These features have a tremendous performance of your virtual machine running in the cloud.</para>
positive impact on the performance of virtual machines running <para>It is also important to consider the compute requirements of
in the cloud.</para>
<para>In addition to the impact on actual compute services, it is
also important to consider the compute requirements of
resource nodes within the cloud. Resource nodes refer to resource nodes within the cloud. Resource nodes refer to
non-hypervisor nodes providing controller, object storage, non-hypervisor nodes providing the following in the cloud:</para>
block storage, or networking services in the cloud. The number <itemizedlist>
of processor cores and threads has a direct correlation to the <listitem>
<para>
Controller
</para>
</listitem>
<listitem>
<para>
Object storage
</para>
</listitem>
<listitem>
<para>
Block storage
</para>
</listitem>
<listitem>
<para>
Networking services
</para>
</listitem>
</itemizedlist>
<para>The number of processor cores and threads has a direct correlation to the
number of worker threads which can be run on a resource node. number of worker threads which can be run on a resource node.
It is important to ensure sufficient compute capacity and As a result, you must make design decisions relating directly to
memory is planned on resource nodes.</para> the service, as well as provide a balanced infrastructure for all services.</para>
<para>Workload profiles are unpredictable in a general purpose <para>Workload profiles are unpredictable in a general purpose
cloud, so it may be difficult to design for every specific use cloud. Additional compute resource pools can be added to the cloud
case in mind. Additional compute resource pools can be added later, reducing the stress of unpredictability. In some cases, the demand on certain
to the cloud at a later time, so this unpredictability should instance types or flavors may not justify individual
not be a problem. In some cases, the demand on certain hardware design. In either of these cases, initiate the design by
instance types or flavors may not justify an individual allocating hardware designs that are capable of servicing the most
hardware design. In either of these cases, start by providing common instances requests. If you are looking to add additional
hardware designs which will be capable of servicing the most hardware designs to the overall architecture, this can be done at
common instance requests first, looking to add additional a later time.</para>
hardware designs to the overall architecture in the form of </section>
new hardware node designs and resource pools as they become
justified at a later time.</para></section>
<section xml:id="designing-network-resources-tech-considerations"> <section xml:id="designing-network-resources-tech-considerations">
<title>Designing network resources</title> <title>Designing network resources</title>
<para>An OpenStack cloud traditionally has multiple network <para>OpenStack clouds traditionally have multiple network
segments, each of which provides access to resources within segments, each of which provides access to resources within
the cloud to both operators and tenants. In addition, the the cloud to both operators and tenants. The network services
network services themselves also require network communication themselves also require network communication paths which should
paths which should also be separated from the other networks. be separated from the other networks. When designing network services
When designing network services for a general purpose cloud, for a general purpose cloud, we recommend planning for a physical or
it is recommended to plan for either a physical or logical logical separation of network segments that will be used by operators
separation of network segments which will be used by operators and tenants. We further suggest the creation of an additional network
and tenants. It is further suggested to create an additional segment for access to internal services such as the message bus and
network segment for access to internal services such as the databse used by the various cloud services.
message bus and database used by the various cloud services. Segregating these services onto separate networks helps to protect
Segregating these services onto separate networks helps to sensitive data and protects against unauthorized access to services.</para>
protect sensitive data and also protects against unauthorized <para>Based on the requirements of instances being serviced in the cloud,
access to services.</para> the choice of network service will be the next decision that affects
<para>Based on the requirements of instances being serviced in the your design architecture.</para>
cloud, the next design choice, which will affect your design is <para>The choice between legacy networking (nova-network), as a
the choice of network service which will be used to service
instances in the cloud. The choice between legacy networking (nova-network), as a
part of OpenStack Compute, and OpenStack Networking part of OpenStack Compute, and OpenStack Networking
(neutron), has tremendous implications and will have (neutron), has a huge impact on the architecture and design of the cloud
a huge impact on the architecture and design of the cloud
network infrastructure.</para> network infrastructure.</para>
<para> <variablelist>
The legacy networking (nova-network) service is primarily a <varlistentry>
layer-2 networking service that functions in two modes. In <term>Legacy networking (nova-network)</term>
legacy networking, the two modes differ in their use of VLANs. <listitem>
When using legacy networking in a flat network mode, all network <para>The legacy networking (nova-network) service is primarily a
hardware nodes and devices throughout the cloud are connected to layer-2 networking service that functions in two modes. In
a single layer-2 network segment that provides access to legacy networking, the two modes differ in their use of VLANs.
application data.</para> When using legacy networking in a flat network mode, all network
<para>When the network devices in the cloud support segmentation hardware nodes and devices throughout the cloud are connected to
using VLANs, legacy networking can operate in the second mode. In a single layer-2 network segment that provides access to
this design model, each tenant within the cloud is assigned a application data.</para>
network subnet which is mapped to a VLAN on the physical <para>When the network devices in the cloud support segmentation
network. It is especially important to remember the maximum using VLANs, legacy networking can operate in the second mode. In
number of 4096 VLANs which can be used within a spanning tree this design model, each tenant within the cloud is assigned a
domain. These limitations place hard limits on the amount of network subnet which is mapped to a VLAN on the physical
growth possible within the data center. When designing a network. It is especially important to remember the maximum
general purpose cloud intended to support multiple tenants, it number of 4096 VLANs which can be used within a spanning tree
is especially recommended to use legacy networking with VLANs, and domain. These limitations place hard limits on the amount of
not in flat network mode.</para> growth possible within the data center. When designing a
general purpose cloud intended to support multiple tenants, we
recommend the use of legacy networking with VLANs, and
not in flat network mode.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Another consideration regarding network is the fact that <para>Another consideration regarding network is the fact that
legacy networking 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 tenants do not have control over network resources. If tenants
@ -161,18 +203,25 @@
such as network segments and subnets, it will be necessary to 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> access to instances.</para>
<para>OpenStack Networking is a first class networking <variablelist>
service that gives full control over creation of virtual <varlistentry>
network resources to tenants. This is often accomplished in <term>OpenStack Networking (neutron)</term>
the form of tunneling protocols which will establish <listitem>
encapsulated communication paths over existing network <para>OpenStack Networking (neutron) is a first class networking
infrastructure in order to segment tenant traffic. These service that gives full control over creation of virtual
methods vary depending on the specific implementation, but network resources to tenants. This is often accomplished in
some of the more common methods include tunneling over GRE, the form of tunneling protocols which will establish
encapsulating with VXLAN, and VLAN tags.</para> encapsulated communication paths over existing network
infrastructure in order to segment tenant traffic. These
methods vary depending on the specific implementation, but
some of the more common methods include tunneling over GRE,
encapsulating with VXLAN, and VLAN tags.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Initially, it is suggested to design at least three network <para>Initially, it is suggested to design at least three network
segments, the first of which will be used for access to the segments, the first of which will be used for access to the
cloud's REST APIs by tenants and operators. This is generally cloud's REST APIs by tenants and operators. This is
referred to as a public network. In most cases, the controller referred to as a public network. In most cases, the controller
nodes and swift proxies within the cloud will be the only nodes and swift proxies within the cloud will be the only
devices necessary to connect to this network segment. In some devices necessary to connect to this network segment. In some
@ -197,15 +246,19 @@
resource nodes will need to communicate on this network resource nodes will need to communicate on this network
segment, as will any network gateway services which allow segment, as will any network gateway services which allow
application data to access the physical network outside of the application data to access the physical network outside of the
cloud.</para></section> cloud.</para>
</section>
<section xml:id="designing-storage-resources-tech-considerations"> <section xml:id="designing-storage-resources-tech-considerations">
<title>Designing storage resources</title> <title>Designing storage resources</title>
<para>OpenStack has two independent storage services to consider, <para>OpenStack has two independent storage services to consider,
each with its own specific design requirements and goals. In each with its own specific design requirements and goals. In
addition to services which provide storage as their primary addition to services which provide storage as their primary
function, there are additional design considerations with function, there are additional design considerations with
regard to compute and controller nodes which will affect the regard to compute and controller nodes which will affect the
overall cloud architecture.</para></section> overall cloud architecture.</para> <!--Could there be room for more tech content here? A.S-->
</section>
<section xml:id="designing-openstack-object-storage-tech-considerations"> <section xml:id="designing-openstack-object-storage-tech-considerations">
<title>Designing OpenStack Object Storage</title> <title>Designing OpenStack Object Storage</title>
<para>When designing hardware resources for OpenStack Object <para>When designing hardware resources for OpenStack Object
@ -217,30 +270,28 @@
attached storage or an external chassis that holds a larger attached storage or an external chassis that holds a larger
number of drives, the main goal is to maximize the storage number of drives, the main goal is to maximize the storage
available in each node.</para> available in each node.</para>
<para>It is not recommended to invest in enterprise class drives <para>We do not recommended investing in enterprise class drives
for an OpenStack Object Storage cluster. The consistency and for an OpenStack Object Storage cluster. The consistency and
partition tolerance characteristics of OpenStack Object partition tolerance characteristics of OpenStack Object
Storage will ensure that data stays up to date and survives Storage will ensure that data stays up to date and survives
hardware faults without the use of any specialized data hardware faults without the use of any specialized data
replication devices.</para> replication devices.</para>
<para>A great benefit of OpenStack Object Storage is the ability <para>One of the benefits of OpenStack Object Storage is the ability
to mix and match drives by utilizing weighting within the to mix and match drives by making use of weighting within the
swift ring. When designing your swift storage cluster, it is swift ring. When designing your swift storage cluster, we
recommended to make use of the most cost effective storage recommend making use of the most cost effective storage
solution available at the time. Many server chassis on the solution available at the time. Many server chassis on the
market can hold 60 or more drives in 4U of rack space, market can hold 60 or more drives in 4U of rack space,
therefore it is recommended to maximize the amount of storage therefore we recommend maximizing the amount of storage
per rack unit at the best cost per terabyte. Furthermore, the per rack unit at the best cost per terabyte. Furthermore, we
use of RAID controllers is not recommended in an object do not recommend the use of RAID controllers in an object storage
storage node.</para> node.</para>
<para>In order to achieve this durability and availability of data <para>To achieve durability and availability of data stored as objects
stored as objects, it is important to design object storage it is important to design object storage resource pools to ensure they can
resource pools in a way that provides the suggested provide the suggested availability. Considering rack-level and zone-level
availability that the service can provide. Beyond designing at designs to accommodate the number of replicas configured to be stored in the
the hardware node level, it is important to consider Object Storage service (the defult number of replicas is three) is important
rack-level and zone-level designs to accommodate the number of when designing beyond the hardware node level. Each replica of
replicas configured to be stored in the Object Storage service
(the default number of replicas is three). Each replica of
data should exist in its own availability zone with its own data should exist in its own availability zone with its own
power, cooling, and network resources available to service power, cooling, and network resources available to service
that specific zone.</para> that specific zone.</para>
@ -248,79 +299,116 @@
of requests does not hinder the performance of the cluster. of requests does not hinder the performance of the cluster.
The object storage service is a chatty protocol, therefore The object storage service is a chatty protocol, therefore
making use of multiple processors that have higher core counts making use of multiple processors that have higher core counts
will ensure the IO requests do not inundate the server.</para></section> will ensure the IO requests do not inundate the server.</para>
</section>
<section xml:id="designing-openstack-block-storage"> <section xml:id="designing-openstack-block-storage">
<title>Designing OpenStack Block Storage</title> <title>Designing OpenStack Block Storage</title>
<para>When designing OpenStack Block Storage resource nodes, it is <para>When designing OpenStack Block Storage resource nodes, it is
helpful to understand the workloads and requirements that will helpful to understand the workloads and requirements that will
drive the use of block storage in the cloud. In a general drive the use of block storage in the cloud. We recommend designing
purpose cloud these use patterns are often unknown. It is block storage pools so that tenants can choose appropriate storage
recommended to design block storage pools so that tenants can solutions for their applications. By creating multiple storage pools of different
choose the appropriate storage solution for their
applications. By creating multiple storage pools of different
types, in conjunction with configuring an advanced storage types, in conjunction with configuring an advanced storage
scheduler for the block storage service, it is possible to scheduler for the block storage service, it is possible to
provide tenants with a large catalog of storage services with provide tenants with a large catalog of storage services with
a variety of performance levels and redundancy options.</para> a variety of performance levels and redundancy options.</para>
<para>In addition to directly attached storage populated in <para>Block storage also takes advantage of a number of enterprise storage
servers, block storage can also take advantage of a number of solutions. These are addressed via a plug-in driver developed by the
enterprise storage solutions. These are addressed via a plug-in hardware vendor. A large number of
driver developed by the hardware vendor. A large number of
enterprise storage plug-in drivers ship out-of-the-box with enterprise storage plug-in drivers ship out-of-the-box with
OpenStack Block Storage (and many more available via third OpenStack Block Storage (and many more available via third
party channels). While a general purpose cloud would likely party channels). General purpose clouds are more likely to use
use directly attached storage in the majority of block storage directly attached storage in the majority of block storage nodes,
nodes, it may also be necessary to provide additional levels deeming it necessary to provide additional levels of service to tenants
of service to tenants which can only be provided by enterprise which can only be provided by enterprise class storage solutions.</para>
class storage solutions.</para> <para>Redundancy and availability requirements impact the decision to use
<para>The determination to use a RAID controller card in block a RAID controller card in block storage nodes. The input-output per second (IOPS)
storage nodes is impacted primarily by the redundancy and demand of your application will influence whether or not you should use a RAID
availability requirements of the application. Applications controller, and which level of RAID is required.
which have a higher demand on input-output per second (IOPS) Making use of higher performing RAID volumes is suggested when
will influence both the choice to use a RAID controller and considering performance. However, where redundancy of
the level of RAID configured on the volume. Where performance block storage volumes is more important we recommend
is a consideration, it is suggested to make use of higher making use of a redundant RAID configuration such as RAID 5 or
performing RAID volumes. In contrast, where redundancy of
block storage volumes is more important it is recommended to
make use of a redundant RAID configuration such as RAID 5 or
RAID 6. Some specialized features, such as automated RAID 6. Some specialized features, such as automated
replication of block storage volumes, may require the use of replication of block storage volumes, may require the use of
third-party plug-ins and enterprise block storage solutions in third-party plug-ins and enterprise block storage solutions in
order to provide the high demand on storage. Furthermore, order to provide the high demand on storage. Furthermore,
where extreme performance is a requirement it may also be where extreme performance is a requirement it may also be
necessary to make use of high speed SSD disk drives' high necessary to make use of high speed SSD disk drives' high
performing flash storage solutions.</para></section> performing flash storage solutions.</para>
</section>
<section xml:id="software-selection-tech-considerations"> <section xml:id="software-selection-tech-considerations">
<title>Software selection</title> <title>Software selection</title>
<para>The software selection process can play a large role in the <para>The software selection process plays a large role in the
architecture of a general purpose cloud. Choice of operating architecture of a general purpose cloud. The following have
system, selection of OpenStack software components, choice of a large impact on the design of the cloud:</para>
hypervisor and selection of supplemental software will have a <itemizedlist>
large impact on the design of the cloud.</para> <listitem>
<para>
Choice of operating system
</para>
</listitem>
<listitem>
<para>
Selection of OpenStack software components
</para>
</listitem>
<listitem>
<para>
Choice of hypervisor
</para>
</listitem>
<listitem>
<para>
Selection of supplemental software
</para>
</listitem>
</itemizedlist>
<para>Operating system (OS) selection plays a large role in the <para>Operating system (OS) selection plays a large role in the
design and architecture of a cloud. There are a number of OSes design and architecture of a cloud. There are a number of OSes
which have native support for OpenStack including Ubuntu, Red which have native support for OpenStack including:</para>
Hat Enterprise Linux (RHEL), CentOS, and SUSE Linux Enterprise <itemizedlist>
Server (SLES). "Native support" in this context means that the <listitem>
distribution provides distribution-native packages by which to <para>
install OpenStack in their repositories. Note that "native Ubuntu
support" is not a constraint on the choice of OS; users are </para>
</listitem>
<listitem>
<para>
Red Hat Enterprise Linux (RHEL)
</para>
</listitem>
<listitem>
<para>
CentOS
</para>
</listitem>
<listitem>
<para>
SUSE Linux Enterprise Server (SLES)
</para>
</listitem>
</itemizedlist>
<note>
<para>Native support is not a constraint on the choice of OS; users are
free to choose just about any Linux distribution (or even free to choose just about any Linux distribution (or even
Microsoft Windows) and install OpenStack directly from source Microsoft Windows) and install OpenStack directly from source
(or compile their own packages). However, the reality is that (or compile their own packages). However, many organizations will
many organizations will prefer to install OpenStack from prefer to install OpenStack from distribution-supplied packages or
distribution-supplied packages or repositories (although using repositories (although using the distribution vendor's OpenStack
the distribution vendor's OpenStack packages might be a packages might be a requirement for support).
requirement for support).</para> </para>
</note>
<para>OS selection also directly influences hypervisor selection. <para>OS selection also directly influences hypervisor selection.
A cloud architect who selects Ubuntu, RHEL, or SLES has some A cloud architect who selects Ubuntu, RHEL, or SLES has some
flexibility in hypervisor; KVM, Xen, and LXC are supported flexibility in hypervisor; KVM, Xen, and LXC are supported
virtualization methods available under OpenStack Compute virtualization methods available under OpenStack Compute
(nova) on these Linux distributions. A cloud architect who (nova) on these Linux distributions. However, a cloud architect
selects Hyper-V, on the other hand, is limited to Windows who selects Hyper-V is limited to Windows Servers. Similarly, a
Server. Similarly, a cloud architect who selects XenServer is cloud architect who selects XenServer is limited to the CentOS-based
limited to the CentOS-based dom0 operating system provided dom0 operating system provided with XenServer.</para>
with XenServer.</para>
<para>The primary factors that play into OS-hypervisor selection <para>The primary factors that play into OS-hypervisor selection
include:</para> include:</para>
<variablelist> <variablelist>
@ -350,6 +438,7 @@
</varlistentry> </varlistentry>
</variablelist> </variablelist>
</section> </section>
<section xml:id="hypervisor-tech-considerations"> <section xml:id="hypervisor-tech-considerations">
<title>Hypervisor</title> <title>Hypervisor</title>
<para>OpenStack supports a wide variety of hypervisors, one or <para>OpenStack supports a wide variety of hypervisors, one or
@ -380,13 +469,13 @@
</itemizedlist> </itemizedlist>
<para>A complete list of supported hypervisors and their <para>A complete list of supported hypervisors and their
capabilities can be found at capabilities can be found at
<link xlink:href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix">https://wiki.openstack.org/wiki/HypervisorSupportMatrix</link>. <link xlink:href="https://wiki.openstack.org/wiki/HypervisorSupportMatrix">OpenStack Hypervisor Support Matrix</link>.
</para> </para>
<para>General purpose clouds should make use of hypervisors that <para>We recommend general purpose clouds use hypervisors that
support the most general purpose use cases, such as KVM and support the most general purpose use cases, such as KVM and
Xen. More specific hypervisors should then be chosen to Xen. More specific hypervisors should be chosen to account
account for specific functionality or a supported feature for specific functionality or a supported feature requirement.
requirement. In some cases, there may also be a mandated In some cases, there may also be a mandated
requirement to run software on a certified hypervisor requirement to run software on a certified hypervisor
including solutions from VMware, Microsoft, and Citrix.</para> including solutions from VMware, Microsoft, and Citrix.</para>
<para>The features offered through the OpenStack cloud platform <para>The features offered through the OpenStack cloud platform
@ -394,7 +483,7 @@
a general purpose cloud that predominantly supports a a general purpose cloud that predominantly supports a
Microsoft-based migration, or is managed by staff that has a Microsoft-based migration, or is managed by staff that has a
particular skill for managing certain hypervisors and particular skill for managing certain hypervisors and
operating systems, Hyper-V might be the best available choice. operating systems, Hyper-V would be the best available choice.
While the decision to use Hyper-V does not limit the ability While the decision to use Hyper-V does not limit the ability
to run alternative operating systems, be mindful of those that to run alternative operating systems, be mindful of those that
are deemed supported. Each different hypervisor also has their are deemed supported. Each different hypervisor also has their
@ -409,7 +498,9 @@
workloads to utilize software and hardware specific to their workloads to utilize software and hardware specific to their
particular requirements. This functionality can be exposed particular requirements. This functionality can be exposed
explicitly to the end user, or accessed through defined explicitly to the end user, or accessed through defined
metadata within a particular flavor of an instance.</para></section> metadata within a particular flavor of an instance.</para>
</section>
<section xml:id="openstack-components-tech-considerations"> <section xml:id="openstack-components-tech-considerations">
<title>OpenStack components</title> <title>OpenStack components</title>
<para>A general purpose OpenStack cloud design should incorporate <para>A general purpose OpenStack cloud design should incorporate
@ -445,11 +536,15 @@
<para>A general purpose cloud may also include OpenStack <para>A general purpose cloud may also include OpenStack
<glossterm>Object Storage</glossterm> (<glossterm>swift</glossterm>). <glossterm>Object Storage</glossterm> (<glossterm>swift</glossterm>).
OpenStack <glossterm>Block Storage</glossterm> OpenStack <glossterm>Block Storage</glossterm>
(<glossterm>cinder</glossterm>) may be (<glossterm>cinder</glossterm>). These may be
selected to provide persistent storage to applications and selected to provide storage to applications and
instances although, depending on the use case, this could be instances.</para>
<note>
<para>However, depending on the use case, these could be
optional.</para> optional.</para>
</note>
</section> </section>
<section xml:id="supplemental-software-tech-considerations"> <section xml:id="supplemental-software-tech-considerations">
<title>Supplemental software</title> <title>Supplemental software</title>
<para>A general purpose OpenStack deployment consists of more than <para>A general purpose OpenStack deployment consists of more than
@ -471,7 +566,7 @@
balancers to provide highly available API access and SSL balancers to provide highly available API access and SSL
termination, software solutions, for example HAProxy, can also termination, software solutions, for example HAProxy, can also
be considered. It is vital to ensure that such software be considered. It is vital to ensure that such software
implementations are also made highly available. This high implementations are also made highly available. High
availability can be achieved by using software such as availability can be achieved by using software such as
Keepalived or Pacemaker with Corosync. Pacemaker and Corosync Keepalived or Pacemaker with Corosync. Pacemaker and Corosync
can provide active-active or active-passive highly available can provide active-active or active-passive highly available
@ -481,39 +576,43 @@
infrastructure where one of those nodes may be running certain infrastructure where one of those nodes may be running certain
services in standby mode.</para> services in standby mode.</para>
<para>Memcached is a distributed memory object caching system, and <para>Memcached is a distributed memory object caching system, and
Redis is a key-value store. Both are usually deployed on Redis is a key-value store. Both are deployed on
general purpose clouds to assist in alleviating load to the general purpose clouds to assist in alleviating load to the
Identity service. The memcached service caches tokens, and due Identity service. The memcached service caches tokens, and due
to its distributed nature it can help alleviate some to its distributed nature it can help alleviate some
bottlenecks to the underlying authentication system. Using bottlenecks to the underlying authentication system. Using
memcached or Redis does not affect the overall design of your memcached or Redis does not affect the overall design of your
architecture as they tend to be deployed onto the architecture as they tend to be deployed onto the
infrastructure nodes providing the OpenStack services.</para></section> infrastructure nodes providing the OpenStack services.</para>
</section>
<section xml:id="performance-tech-considerations"> <section xml:id="performance-tech-considerations">
<title>Performance</title> <title>Performance</title>
<para>Performance of an OpenStack deployment is dependent on a <para>Performance of an OpenStack deployment is dependent on a
number of factors related to the infrastructure and controller number of factors related to the infrastructure and controller
services. The user requirements can be split into general services. The user requirements can be split into general
network performance, performance of compute resources, and network performance, performance of compute resources, and
performance of storage systems.</para></section> performance of storage systems.</para>
</section>
<section xml:id="controller-infrastructure-tech-considerations"> <section xml:id="controller-infrastructure-tech-considerations">
<title>Controller infrastructure</title> <title>Controller infrastructure</title>
<para>The Controller infrastructure nodes provide management <para>The Controller infrastructure nodes provide management
services to the end-user as well as providing services services to the end-user as well as providing services
internally for the operating of the cloud. The Controllers internally for the operating of the cloud. The Controllers
typically run message queuing services that carry system run message queuing services that carry system
messages between each service. Performance issues related to messages between each service. Performance issues related to
the message bus would lead to delays in sending that message the message bus would lead to delays in sending that message
to where it needs to go. The result of this condition would be to where it needs to go. The result of this condition would be
delays in operation functions such as spinning up and deleting delays in operation functions such as spinning up and deleting
instances, provisioning new storage volumes and managing instances, provisioning new storage volumes and managing
network resources. Such delays could adversely affect an network resources. Such delays could adversely affect an
application's ability to react to certain conditions, application’s ability to react to certain conditions,
especially when using auto-scaling features. It is important especially when using auto-scaling features. It is important
to properly design the hardware used to run the controller to properly design the hardware used to run the controller
infrastructure as outlined above in the Hardware Selection infrastructure as outlined above in the Hardware Selection
section.</para> section.</para>
<para>Performance of the controller services is not just limited <para>Performance of the controller services is not limited
to processing power, but restrictions may emerge in serving to processing power, but restrictions may emerge in serving
concurrent users. Ensure that the APIs and Horizon services concurrent users. Ensure that the APIs and Horizon services
are load tested to ensure that you are able to serve your are load tested to ensure that you are able to serve your
@ -522,11 +621,13 @@
authentication and authorization for all services, both authentication and authorization for all services, both
internally to OpenStack itself and to end-users. This service internally to OpenStack itself and to end-users. This service
can lead to a degradation of overall performance if this is can lead to a degradation of overall performance if this is
not sized appropriately.</para></section> not sized appropriately.</para>
</section>
<section xml:id="network-performance-tech-considerations"> <section xml:id="network-performance-tech-considerations">
<title>Network performance</title> <title>Network performance</title>
<para>In a general purpose OpenStack cloud, the requirements of <para>In a general purpose OpenStack cloud, the requirements of
the network help determine its performance capabilities. For the network help determine performance capabilities. For
example, small deployments may employ 1 Gigabit Ethernet (GbE) example, small deployments may employ 1 Gigabit Ethernet (GbE)
networking, whereas larger installations serving multiple networking, whereas larger installations serving multiple
departments or many users would be better architected with departments or many users would be better architected with
@ -535,7 +636,8 @@
environments that run a mix of networking capabilities. By environments that run a mix of networking capabilities. By
utilizing the different interface speeds, the users of the utilizing the different interface speeds, the users of the
OpenStack environment can choose networks that are fit for OpenStack environment can choose networks that are fit for
their purpose. For example, web application instances may run their purpose.</para>
<para>For example, web application instances may run
on a public network presented through OpenStack Networking on a public network presented through OpenStack Networking
that has 1 GbE capability, whereas the back-end database uses that has 1 GbE capability, whereas the back-end database uses
an OpenStack Networking network that has 10&nbsp;GbE capability to an OpenStack Networking network that has 10&nbsp;GbE capability to
@ -547,7 +649,9 @@
perform SSL termination if that is a requirement of your perform SSL termination if that is a requirement of your
environment. When implementing SSL offloading, it is important environment. When implementing SSL offloading, it is important
to understand the SSL offloading capabilities of the devices to understand the SSL offloading capabilities of the devices
selected.</para></section> selected.</para>
</section>
<section xml:id="compute-host-tech-considerations"> <section xml:id="compute-host-tech-considerations">
<title>Compute host</title> <title>Compute host</title>
<para>The choice of hardware specifications used in compute nodes <para>The choice of hardware specifications used in compute nodes
@ -562,12 +666,14 @@
Compute environment to avoid this scenario. For running Compute environment to avoid this scenario. For running
general purpose OpenStack environments it is possible to keep general purpose OpenStack environments it is possible to keep
to the defaults, but make sure to monitor your environment as to the defaults, but make sure to monitor your environment as
usage increases.</para></section> usage increases.</para>
</section>
<section xml:id="storage-performance-tech-considerations"> <section xml:id="storage-performance-tech-considerations">
<title>Storage performance</title> <title>Storage performance</title>
<para>When considering the performance of OpenStack Block Storage, <para>When considering performance of OpenStack Block Storage,
hardware and architecture choices are important. Block Storage hardware and architecture choice is important. Block Storage
can use enterprise back-end systems such as NetApp or EMC, use can use enterprise back-end systems such as NetApp or EMC,
scale out storage such as GlusterFS and Ceph, or simply use scale out storage such as GlusterFS and Ceph, or simply use
the capabilities of directly attached storage in the nodes the capabilities of directly attached storage in the nodes
themselves. Block Storage may be deployed so that traffic themselves. Block Storage may be deployed so that traffic
@ -577,13 +683,15 @@
dedicated interfaces on the Controller and Compute dedicated interfaces on the Controller and Compute
hosts.</para> hosts.</para>
<para>When considering performance of OpenStack Object Storage, a <para>When considering performance of OpenStack Object Storage, a
number of design choices will affect performance. A user's number of design choices will affect performance. A user’s
access to the Object Storage is through the proxy services, access to the Object Storage is through the proxy services,
which typically sit behind hardware load balancers. By the which sit behind hardware load balancers. By the
very nature of a highly resilient storage system, replication very nature of a highly resilient storage system, replication
of the data would affect performance of the overall system. In of the data would affect performance of the overall system. In
this case, 10 GbE (or better) networking is recommended this case, 10 GbE (or better) networking is recommended
throughout the storage network architecture.</para></section> throughout the storage network architecture.</para>
</section>
<section xml:id="availability-tech-considerations"> <section xml:id="availability-tech-considerations">
<title>Availability</title> <title>Availability</title>
<para>In OpenStack, the infrastructure is integral to providing <para>In OpenStack, the infrastructure is integral to providing
@ -611,16 +719,16 @@
your systems, will help determine scale out decisions.</para> your systems, will help determine scale out decisions.</para>
<para>Care must be taken when deciding network functionality. <para>Care must be taken when deciding network functionality.
Currently, OpenStack supports both the legacy networking (nova-network) Currently, OpenStack supports both the legacy networking (nova-network)
system and the newer, extensible OpenStack Networking. Both system and the newer, extensible OpenStack Networking (neutron). Both
have their pros and cons when it comes to providing highly have their pros and cons when it comes to providing highly
available access. Legacy networking, which provides networking available access. Legacy networking, which provides networking
access maintained in the OpenStack Compute code, provides a access maintained in the OpenStack Compute code, provides a
feature that removes a single point of failure when it comes feature that removes a single point of failure when it comes
to routing, and this feature is currently missing in OpenStack to routing, and this feature is currently missing in OpenStack
Networking. The effect of legacy networking's multi-host Networking. The effect of legacy networking’s multi-host
functionality restricts failure domains to the host running functionality restricts failure domains to the host running
that instance.</para> that instance.</para>
<para>On the other hand, when using OpenStack Networking, the <para>When using OpenStack Networking, the
OpenStack controller servers or separate Networking OpenStack controller servers or separate Networking
hosts handle routing. For a deployment that requires features hosts handle routing. For a deployment that requires features
available in only Networking, it is possible to available in only Networking, it is possible to
@ -632,9 +740,8 @@
Networking, and instead rely on hardware routing capabilities. Networking, and instead rely on hardware routing capabilities.
In this case, the switching infrastructure must support L3 In this case, the switching infrastructure must support L3
routing.</para> routing.</para>
<para> <para>OpenStack Networking and legacy networking
OpenStack Networking (neutron) and legacy networking both have their advantages and
(nova-network) both have their advantages and
disadvantages. They are both valid and supported options that disadvantages. They are both valid and supported options that
fit different network deployment models described in the fit different network deployment models described in the
<citetitle><link <citetitle><link
@ -661,12 +768,12 @@
may include utilizing shared file systems on enterprise may include utilizing shared file systems on enterprise
storage or OpenStack Block storage to provide a level of storage or OpenStack Block storage to provide a level of
guarantee to match service features.</para> guarantee to match service features.</para>
<para> <para>For more information on high availability in OpenStack, see the <link
For more information on high availability in OpenStack, see the <link
xlink:href="http://docs.openstack.org/high-availability-guide"><citetitle>OpenStack xlink:href="http://docs.openstack.org/high-availability-guide"><citetitle>OpenStack
High Availability Guide</citetitle></link>. High Availability Guide</citetitle></link>.
</para> </para>
</section> </section>
<section xml:id="security-tech-considerations"> <section xml:id="security-tech-considerations">
<title>Security</title> <title>Security</title>
<para>A security domain comprises users, applications, servers or <para>A security domain comprises users, applications, servers or
@ -751,7 +858,7 @@
the API services behind hardware that performs SSL termination the API services behind hardware that performs SSL termination
is strongly recommended.</para> is strongly recommended.</para>
<para> <para>
For more information on OpenStack Security, see the <link For more information OpenStack Security, see the <link
xlink:href="http://docs.openstack.org/security-guide/"><citetitle>OpenStack xlink:href="http://docs.openstack.org/security-guide/"><citetitle>OpenStack
Security Guide</citetitle></link> Security Guide</citetitle></link>
</para> </para>