0393934828
Follow the Documentaion conventions: https://wiki.openstack.org/wiki/Documentation/Conventions Change-Id: I16078f5bfc3c47002f43f23be83b03c1f6f938fe
927 lines
36 KiB
XML
927 lines
36 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE section [
|
|
<!ENTITY % openstack SYSTEM "openstack.ent">
|
|
%openstack;
|
|
]>
|
|
<section version="5.0" xml:id="example_architecture-neutron"
|
|
xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:ns5="http://www.w3.org/1998/Math/MathML"
|
|
xmlns:ns4="http://www.w3.org/2000/svg"
|
|
xmlns:ns3="http://www.w3.org/1999/xhtml"
|
|
xmlns:ns="http://docbook.org/ns/docbook">
|
|
<?dbhtml stop-chunking?>
|
|
|
|
<title>Example Architecture—OpenStack Networking</title>
|
|
|
|
<para>This chapter provides an example architecture using OpenStack
|
|
Networking, also known as the Neutron project, in a highly available
|
|
environment.</para>
|
|
|
|
<section xml:id="overview-neutron">
|
|
<title>Overview</title>
|
|
|
|
<para>A highly-available environment can be put into place if you require
|
|
an environment that can scale horizontally, or want your cloud to continue
|
|
to be operational in case of node failure. This example architecture has
|
|
been written based on the current default feature set of OpenStack Havana,
|
|
with an emphasis on high availability.<indexterm class="singular">
|
|
<primary>RDO (Red Hat Distributed OpenStack)</primary>
|
|
</indexterm><indexterm class="singular">
|
|
<primary>OpenStack Networking (neutron)</primary>
|
|
|
|
<secondary>component overview</secondary>
|
|
</indexterm></para>
|
|
|
|
<section xml:id="overview_components_neutron">
|
|
<title>Components</title>
|
|
|
|
<informaltable rules="all">
|
|
<col width="40%" />
|
|
|
|
<col width="60%" />
|
|
|
|
<thead>
|
|
<tr>
|
|
<th>Component</th>
|
|
|
|
<th>Details</th>
|
|
</tr>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<tr>
|
|
<td><para>OpenStack release</para></td>
|
|
|
|
<td><para>Havana</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><para>Host operating system</para></td>
|
|
|
|
<td><para>Red Hat Enterprise Linux 6.5</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><para>OpenStack package repository</para></td>
|
|
|
|
<td><para><link xlink:href="https://repos.fedorapeople.org/repos/openstack/">Red Hat
|
|
Distributed OpenStack (RDO)</link></para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><para>Hypervisor</para></td>
|
|
|
|
<td><para>KVM</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><para>Database</para></td>
|
|
|
|
<td><para>MySQL</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><para>Message queue</para></td>
|
|
|
|
<td><para>Qpid</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><para>Networking service</para></td>
|
|
|
|
<td><para>OpenStack Networking</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><para>Tenant Network Separation</para></td>
|
|
|
|
<td><para>VLAN</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><para>Image service back end</para></td>
|
|
|
|
<td><para>GlusterFS</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><para>Identity driver</para></td>
|
|
|
|
<td><para>SQL</para></td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td><para>Block Storage back end</para></td>
|
|
|
|
<td><para>GlusterFS</para></td>
|
|
</tr>
|
|
</tbody>
|
|
</informaltable>
|
|
</section>
|
|
|
|
<section xml:id="rational-neutron">
|
|
<title>Rationale</title>
|
|
|
|
<para>This example architecture has been selected based on the current
|
|
default feature set of OpenStack Havana, with an emphasis on high
|
|
availability. This architecture is currently being deployed in an
|
|
internal Red Hat OpenStack cloud and used to run hosted and shared
|
|
services, which by their nature must be highly available.<indexterm
|
|
class="singular">
|
|
<primary>OpenStack Networking (neutron)</primary>
|
|
|
|
<secondary>rationale for choice of</secondary>
|
|
</indexterm></para>
|
|
|
|
<para>This architecture's components have been selected for the
|
|
following reasons:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Red Hat Enterprise Linux</term>
|
|
|
|
<listitem>
|
|
<para>You must choose an operating system that can run on all of
|
|
the physical nodes. This example architecture is based on Red Hat
|
|
Enterprise Linux, which offers reliability, long-term support,
|
|
certified testing, and is hardened. Enterprise customers, now
|
|
moving into OpenStack usage, typically require these
|
|
advantages.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>RDO</term>
|
|
|
|
<listitem>
|
|
<para>The Red Hat Distributed OpenStack package offers an easy way
|
|
to download the most current OpenStack release that is built for
|
|
the Red Hat Enterprise Linux platform.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>KVM</term>
|
|
|
|
<listitem>
|
|
<para>KVM is the supported hypervisor of choice for Red Hat
|
|
Enterprise Linux (and included in distribution). It is feature
|
|
complete and free from licensing charges and restrictions.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>MySQL</term>
|
|
|
|
<listitem>
|
|
<para>MySQL is used as the database back end for all databases in
|
|
the OpenStack environment. MySQL is the supported database of
|
|
choice for Red Hat Enterprise Linux (and included in
|
|
distribution); the database is open source, scalable, and handles
|
|
memory well.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Qpid</term>
|
|
|
|
<listitem>
|
|
<para>Apache Qpid offers 100 percent compatibility with the
|
|
Advanced Message Queuing Protocol Standard, and its broker is
|
|
available for both C++ and Java.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>OpenStack Networking</term>
|
|
|
|
<listitem>
|
|
<para>OpenStack Networking offers sophisticated networking
|
|
functionality, including Layer 2 (L2) network segregation and
|
|
provider networks.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>VLAN</term>
|
|
|
|
<listitem>
|
|
<para>Using a virtual local area network offers broadcast control,
|
|
security, and physical layer transparency. If needed, use VXLAN to
|
|
extend your address space.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>GlusterFS</term>
|
|
|
|
<listitem>
|
|
<para>GlusterFS offers scalable storage. As your environment
|
|
grows, you can continue to add more storage nodes (instead of
|
|
being restricted, for example, by an expensive storage
|
|
array).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="detailed_description">
|
|
<title>Detailed Description</title>
|
|
|
|
<section xml:id="node_types">
|
|
<title>Node types</title>
|
|
|
|
<para>This section gives you a breakdown of the different nodes that
|
|
make up the OpenStack environment. A node is a physical machine that is
|
|
provisioned with an operating system, and running a defined software
|
|
stack on top of it. <xref linkend="node-types-table" /> provides node
|
|
descriptions and specifications.<indexterm class="singular">
|
|
<primary>OpenStack Networking (neutron)</primary>
|
|
|
|
<secondary>detailed description of</secondary>
|
|
</indexterm></para>
|
|
|
|
<table rules="all" xml:id="node-types-table">
|
|
<caption>Node types</caption>
|
|
|
|
<col width="11%" />
|
|
|
|
<col width="62%" />
|
|
|
|
<col width="27%" />
|
|
|
|
<thead>
|
|
<tr>
|
|
<th>Type</th>
|
|
|
|
<th>Description</th>
|
|
|
|
<th>Example hardware</th>
|
|
</tr>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<tr>
|
|
<td>Controller</td>
|
|
|
|
<td><para>Controller nodes are responsible for running the
|
|
management software services needed for the OpenStack environment
|
|
to function. These nodes:</para>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Provide the front door that people access as well as
|
|
the API services that all other components in the
|
|
environment talk to.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Run a number of services in a highly available
|
|
fashion, utilizing Pacemaker and HAProxy to provide a
|
|
virtual IP and load-balancing functions so all controller
|
|
nodes are being used.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Supply highly available "infrastructure" services,
|
|
such as MySQL and Qpid, that underpin all the
|
|
services.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Provide what is known as "persistent storage"
|
|
through services run on the host as well. This persistent
|
|
storage is backed onto the storage nodes for
|
|
reliability.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>See <xref linkend="node_controller-diagram"/>.</para></td>
|
|
<td><para>Model: Dell R620</para> <para>CPU: 2x Intel® Xeon® CPU
|
|
E5-2620 0 @ 2.00 GHz</para> <para>Memory: 32 GB</para> <para>Disk:
|
|
two 300 GB 10000 RPM SAS Disks</para> <para>Network: two 10G
|
|
network ports</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Compute</td>
|
|
<td><para>Compute nodes run the virtual machine instances in
|
|
OpenStack. They:</para>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Run the bare minimum of services needed to
|
|
facilitate these instances.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Use local storage on the node for the virtual
|
|
machines so that no VM migration or instance recovery at
|
|
node failure is possible.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<phrase role="keep-together">See <xref
|
|
linkend="node_compute-diagram" />.</phrase>
|
|
</para></td>
|
|
<td><para>Model: Dell R620</para> <para>CPU: 2x Intel® Xeon® CPU
|
|
E5-2650 0 @ 2.00 GHz</para> <para>Memory: 128 GB</para>
|
|
<para>Disk: two 600 GB 10000 RPM SAS Disks</para> <para>Network:
|
|
four 10G network ports (For future proofing expansion)</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Storage</td>
|
|
<td><para>Storage nodes store all the data required for the
|
|
environment, including disk images in the Image service library,
|
|
and the persistent storage volumes created by the Block Storage
|
|
service. Storage nodes use GlusterFS technology to keep the data
|
|
highly available and scalable.</para>
|
|
<para>See <xref
|
|
linkend="node_storage-diagram"/>.</para></td>
|
|
<td><para>Model: Dell R720xd</para> <para>CPU: 2x Intel® Xeon®
|
|
CPU E5-2620 0 @ 2.00 GHz</para> <para>Memory: 64 GB</para>
|
|
<para>Disk: two 500 GB 7200 RPM SAS Disks and twenty-four 600 GB 10000 RPM
|
|
SAS Disks</para> <para>Raid Controller: PERC H710P Integrated RAID
|
|
Controller, 1 GB NV Cache</para> <para>Network: two 10G network
|
|
ports</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Network</td>
|
|
<td><para>Network nodes are responsible for doing all the virtual
|
|
networking needed for people to create public or private networks
|
|
and uplink their virtual machines into external networks. Network
|
|
nodes:</para>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Form the only ingress and egress point for instances
|
|
running on top of OpenStack.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Run all of the environment's networking services,
|
|
with the exception of the networking API service (which
|
|
runs on the controller node).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>See <xref
|
|
linkend="node_network-diagram"/>.</para></td>
|
|
<td><para>Model: Dell R620</para> <para>CPU: 1x Intel® Xeon® CPU
|
|
E5-2620 0 @ 2.00 GHz</para> <para>Memory: 32 GB</para> <para>Disk:
|
|
two 300 GB 10000 RPM SAS Disks</para> <para>Network: five 10G
|
|
network ports</para></td>
|
|
</tr>
|
|
<tr>
|
|
<td>Utility</td>
|
|
<td><para>Utility nodes are used by internal administration staff
|
|
only to provide a number of basic system administration functions
|
|
needed to get the environment up and running and to maintain the
|
|
hardware, OS, and software on which it runs.</para> <para>These
|
|
nodes run services such as provisioning, configuration management,
|
|
monitoring, or GlusterFS management software. They are not
|
|
required to scale, although these machines are usually backed
|
|
up.</para></td>
|
|
<td><para>Model: Dell R620</para> <para>CPU: 2x Intel® Xeon® CPU
|
|
E5-2620 0 @ 2.00 GHz</para> <para>Memory: 32 GB</para> <para>Disk:
|
|
two 500 GB 7200 RPM SAS Disks</para> <para>Network: two 10G
|
|
network ports</para></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</section>
|
|
|
|
<section xml:id="networking_layout">
|
|
<title>Networking layout</title>
|
|
|
|
<para>The network contains all the management devices for all hardware
|
|
in the environment (for example, by including Dell iDrac7 devices for
|
|
the hardware nodes, and management interfaces for network switches). The
|
|
network is accessed by internal staff only when diagnosing or recovering
|
|
a hardware issue.</para>
|
|
|
|
<section xml:id="OS_network">
|
|
<title>OpenStack internal network</title>
|
|
|
|
<para>This network is used for OpenStack management functions and
|
|
traffic, including services needed for the provisioning of physical
|
|
nodes (<literal>pxe</literal>, <literal>tftp</literal>,
|
|
<literal>kickstart</literal>), traffic between various OpenStack node
|
|
types using OpenStack APIs and messages (for example,
|
|
<literal>nova-compute</literal> talking to <literal>keystone</literal>
|
|
or <literal>cinder-volume</literal> talking to
|
|
<literal>nova-api</literal>), and all traffic for storage data to the
|
|
storage layer underneath by the Gluster protocol. All physical nodes
|
|
have at least one network interface (typically
|
|
<literal>eth0</literal>) in this network. This network is only
|
|
accessible from other VLANs on port 22 (for <literal>ssh</literal>
|
|
access to manage machines).</para>
|
|
</section>
|
|
|
|
<?hard-pagebreak ?>
|
|
|
|
<section xml:id="public_network">
|
|
<title>Public Network</title>
|
|
|
|
<para>This network is a combination of: <itemizedlist>
|
|
<listitem>
|
|
<para>IP addresses for public-facing interfaces on the
|
|
controller nodes (which end users will access the OpenStack
|
|
services)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A range of publicly routable, IPv4 network addresses to be
|
|
used by OpenStack Networking for floating IPs. You may be
|
|
restricted in your access to IPv4 addresses; a large range of
|
|
IPv4 addresses is not necessary.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Routers for private networks created within
|
|
OpenStack.</para>
|
|
</listitem>
|
|
</itemizedlist></para>
|
|
|
|
<para>This network is connected to the controller nodes so users can
|
|
access the OpenStack interfaces, and connected to the network nodes to
|
|
provide VMs with publicly routable traffic functionality. The network
|
|
is also connected to the utility machines so that any utility services
|
|
that need to be made public (such as system monitoring) can be
|
|
accessed.</para>
|
|
</section>
|
|
|
|
<section xml:id="vm_network">
|
|
<title>VM traffic network</title>
|
|
|
|
<para>This is a closed network that is not publicly routable and is
|
|
simply used as a private, internal network for traffic between virtual
|
|
machines in OpenStack, and between the virtual machines and the
|
|
network nodes that provide l3 routes out to the public network (and
|
|
floating IPs for connections back in to the VMs). Because this is a
|
|
closed network, we are using a different address space to the others
|
|
to clearly define the separation. Only Compute and OpenStack
|
|
Networking nodes need to be connected to this network.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="node_connectivity">
|
|
<title>Node connectivity</title>
|
|
|
|
<para>The following section details how the nodes are connected to the
|
|
different networks (see <xref linkend="networking_layout" />) and what
|
|
other considerations need to take place (for example, bonding) when
|
|
connecting nodes to the networks.</para>
|
|
|
|
<section xml:id="node_connectivity-initial">
|
|
<title>Initial deployment</title>
|
|
|
|
<para>Initially, the connection setup should revolve around keeping
|
|
the connectivity simple and straightforward in order to minimize
|
|
deployment complexity and time to deploy. The deployment shown in
|
|
<xref linkend="fig1-1" /> aims to have 1 × 10G connectivity available
|
|
to all compute nodes, while still leveraging bonding on appropriate
|
|
nodes for maximum performance.</para>
|
|
|
|
<figure xml:id="fig1-1">
|
|
<title>Basic node deployment</title>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/osog_0101.png" align="center" width="6in" depth="4in"></imagedata>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
</section>
|
|
|
|
<section xml:id="node_connectivity-performance">
|
|
<title>Connectivity for maximum performance</title>
|
|
|
|
<para>If the networking performance of the basic layout is not enough,
|
|
you can move to <xref linkend="fig1-2" />, which provides 2 × 10G
|
|
network links to all instances in the environment as well as providing
|
|
more network bandwidth to the storage layer.<indexterm
|
|
class="singular">
|
|
<primary>bandwidth</primary>
|
|
|
|
<secondary>obtaining maximum performance</secondary>
|
|
</indexterm></para>
|
|
|
|
<figure xml:id="fig1-2">
|
|
<title>Performance node deployment</title>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/osog_0102.png" align="center" width="6in" depth="4in"></imagedata>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="node_diagrams">
|
|
<title>Node diagrams</title>
|
|
|
|
<para>The following diagrams (<xref linkend="node_controller-diagram" />
|
|
through <xref linkend="node_storage-diagram" />) include logical
|
|
information about the different types of nodes, indicating what services
|
|
will be running on top of them and how they interact with each other.
|
|
The diagrams also illustrate how the availability and scalability of
|
|
services are achieved.</para>
|
|
|
|
<figure xml:id="node_controller-diagram">
|
|
<title>Controller node</title>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/osog_0103.png" width="4.5in"></imagedata>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<figure xml:id="node_compute-diagram">
|
|
<title>Compute node</title>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/osog_0104.png" align="center" width="4.5in" depth="5in"></imagedata>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<figure xml:id="node_network-diagram">
|
|
<title>Network node</title>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/osog_0105.png" width="5in" depth="5in"></imagedata>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<figure xml:id="node_storage-diagram">
|
|
<title>Storage node</title>
|
|
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/osog_0106.png"></imagedata>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="software_config">
|
|
<title>Example Component Configuration</title>
|
|
|
|
<para><xref linkend="thirdparty-table" /> and <xref
|
|
linkend="openstack-config-table" /> include example configuration and
|
|
considerations for both third-party and OpenStack<indexterm
|
|
class="singular">
|
|
<primary>OpenStack Networking (neutron)</primary>
|
|
|
|
<secondary>third-party component configuration</secondary>
|
|
</indexterm> components: <table rules="all" xml:id="thirdparty-table">
|
|
<caption>Third-party component configuration</caption>
|
|
|
|
<col width="10%" />
|
|
|
|
<col width="30%" />
|
|
|
|
<col width="30%" />
|
|
|
|
<col width="30%" />
|
|
|
|
<thead>
|
|
<tr>
|
|
<th>Component</th>
|
|
|
|
<th>Tuning</th>
|
|
|
|
<th>Availability</th>
|
|
|
|
<th>Scalability</th>
|
|
</tr>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<tr>
|
|
<td>MySQL</td>
|
|
|
|
<td><literal>binlog-format = row</literal></td>
|
|
|
|
<td>Master/master replication. However, both nodes are not used at
|
|
the same time. Replication keeps all nodes as close to being up to
|
|
date as possible (although the asynchronous nature of the
|
|
replication means a fully consistent state is not possible).
|
|
Connections to the database only happen through a Pacemaker
|
|
virtual IP, ensuring that most problems that occur with
|
|
master-master replication can be avoided.</td>
|
|
|
|
<td>Not heavily considered. Once load on the MySQL server
|
|
increases enough that scalability needs to be considered, multiple
|
|
masters or a master/slave setup can be used.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Qpid</td>
|
|
|
|
<td><literal>max-connections=1000</literal>
|
|
<literal>worker-threads=20</literal>
|
|
<literal>connection-backlog=10</literal>, sasl security enabled
|
|
with SASL-BASIC authentication</td>
|
|
|
|
<td>Qpid is added as a resource to the Pacemaker software that
|
|
runs on Controller nodes where Qpid is situated. This ensures only
|
|
one Qpid instance is running at one time, and the node with the
|
|
Pacemaker virtual IP will always be the node running Qpid.</td>
|
|
|
|
<td>Not heavily considered. However, Qpid can be changed to run on
|
|
all controller nodes for scalability and availability purposes,
|
|
and removed from Pacemaker.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>HAProxy</td>
|
|
|
|
<td><literal>maxconn 3000</literal></td>
|
|
|
|
<td>HAProxy is a software layer-7 load balancer used to front door
|
|
all clustered OpenStack API components and do SSL termination.
|
|
HAProxy can be added as a resource to the Pacemaker software that
|
|
runs on the Controller nodes where HAProxy is situated. This
|
|
ensures that only one HAProxy instance is running at one time, and
|
|
the node with the Pacemaker virtual IP will always be the node
|
|
running HAProxy.</td>
|
|
|
|
<td>Not considered. HAProxy has small enough performance overheads
|
|
that a single instance should scale enough for this level of
|
|
workload. If extra scalability is needed,
|
|
<literal>keepalived</literal> or other Layer-4 load balancing can
|
|
be introduced to be placed in front of multiple copies of
|
|
HAProxy.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Memcached</td>
|
|
|
|
<td><literal>MAXCONN="8192" CACHESIZE="30457"</literal></td>
|
|
|
|
<td>Memcached is a fast in-memory key-value cache software that is
|
|
used by OpenStack components for caching data and increasing
|
|
performance. Memcached runs on all controller nodes, ensuring that
|
|
should one go down, another instance of Memcached is
|
|
available.</td>
|
|
|
|
<td>Not considered. A single instance of Memcached should be able
|
|
to scale to the desired workloads. If scalability is desired,
|
|
HAProxy can be placed in front of Memcached (in raw
|
|
<literal>tcp</literal> mode) to utilize multiple Memcached
|
|
instances for scalability. However, this might cause cache
|
|
consistency issues.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Pacemaker</td>
|
|
|
|
<td>Configured to use <phrase
|
|
role="keep-together"><literal>corosync</literal> and</phrase>
|
|
<literal>cman</literal> as a cluster communication stack/quorum
|
|
manager, and as a two-node cluster.</td>
|
|
|
|
<td><para>Pacemaker is the clustering software used to ensure the
|
|
availability of services running on the controller and network
|
|
nodes: <itemizedlist>
|
|
<listitem>
|
|
<para>Because Pacemaker is cluster software, the software
|
|
itself handles its own availability, leveraging
|
|
<literal>corosync</literal> and <literal>cman</literal>
|
|
underneath.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you use the GlusterFS native client, no virtual IP
|
|
is needed, since the client knows all about nodes after
|
|
initial connection and automatically routes around failures
|
|
on the client side.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you use the NFS or SMB adaptor, you will need a
|
|
virtual IP on which to mount the GlusterFS volumes.</para>
|
|
</listitem>
|
|
</itemizedlist> </para></td>
|
|
|
|
<td>If more nodes need to be made cluster aware, Pacemaker can
|
|
scale to 64 nodes.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>GlusterFS</td>
|
|
|
|
<td><literal>glusterfs</literal> performance profile "virt"
|
|
enabled on all volumes. Volumes are setup in two-node
|
|
replication.</td>
|
|
|
|
<td>Glusterfs is a clustered file system that is run on the
|
|
storage nodes to provide persistent scalable data storage in the
|
|
environment. Because all connections to gluster use the
|
|
<literal>gluster</literal> native mount points, the
|
|
<literal>gluster</literal> instances themselves provide
|
|
availability and failover functionality.</td>
|
|
|
|
<td>The scalability of GlusterFS storage can be achieved by adding
|
|
in more storage volumes.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table> <table rules="all" xml:id="openstack-config-table">
|
|
<caption>OpenStack component configuration</caption>
|
|
|
|
<col width="8%" />
|
|
|
|
<col width="8%" />
|
|
|
|
<col width="25%" />
|
|
|
|
<col width="29%" />
|
|
|
|
<col width="30%" />
|
|
|
|
<thead>
|
|
<tr>
|
|
<th>Component</th>
|
|
|
|
<th>Node type</th>
|
|
|
|
<th>Tuning</th>
|
|
|
|
<th>Availability</th>
|
|
|
|
<th>Scalability</th>
|
|
</tr>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<tr>
|
|
<td>Dashboard (horizon)</td>
|
|
|
|
<td>Controller</td>
|
|
|
|
<td>Configured to use Memcached as a session store,
|
|
<literal>neutron</literal> support is enabled,
|
|
<literal>can_set_mount_point = False</literal></td>
|
|
|
|
<td>The dashboard is run on all controller nodes, ensuring at least
|
|
one instance will be available in case of node failure. It also
|
|
sits behind HAProxy, which detects when the software fails and
|
|
routes requests around the failing instance.</td>
|
|
|
|
<td>The dashboard is run on all controller nodes, so scalability
|
|
can be achieved with additional controller nodes. HAProxy allows
|
|
scalability for the dashboard as more nodes are added.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Identity (keystone)</td>
|
|
|
|
<td>Controller</td>
|
|
|
|
<td>Configured to use Memcached for caching and PKI for
|
|
tokens.</td>
|
|
|
|
<td>Identity is run on all controller nodes, ensuring at least one
|
|
instance will be available in case of node failure. Identity also
|
|
sits behind HAProxy, which detects when the software fails and
|
|
routes requests around the failing instance.</td>
|
|
|
|
<td>Identity is run on all controller nodes, so scalability can be
|
|
achieved with additional controller nodes. HAProxy allows
|
|
scalability for Identity as more nodes are added.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Image service (glance)</td>
|
|
|
|
<td>Controller</td>
|
|
|
|
<td><literal>/var/lib/glance/images</literal> is a GlusterFS
|
|
native mount to a Gluster volume off the storage layer.</td>
|
|
|
|
<td>The Image service is run on all controller nodes, ensuring at
|
|
least one instance will be available in case of node failure. It
|
|
also sits behind HAProxy, which detects when the software fails
|
|
and routes requests around the failing instance.</td>
|
|
|
|
<td>The Image service is run on all controller nodes, so
|
|
scalability can be achieved with additional controller nodes.
|
|
HAProxy allows scalability for the Image service as more nodes are
|
|
added.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Compute (nova)</td>
|
|
|
|
<td>Controller, Compute</td>
|
|
|
|
<td><para>Configured to use Qpid, <phrase role="keep-together">
|
|
<literal>qpid_heartbeat = </literal>
|
|
<phrase role="keep-together"><literal>10</literal>,</phrase>
|
|
</phrase><phrase role="keep-together"> configured to
|
|
use</phrase> Memcached for caching, configured to use <phrase
|
|
role="keep-together"><literal>libvirt</literal>,</phrase>
|
|
configured to use <phrase
|
|
role="keep-together"><literal>neutron</literal>.</phrase></para>
|
|
<para>Configured <literal>nova-consoleauth</literal> to use
|
|
Memcached for session management (so that it can have multiple
|
|
copies and run in a load balancer).</para></td>
|
|
|
|
<td><para>The nova API, scheduler, objectstore, cert, consoleauth, conductor, and
|
|
vncproxy services are run on all controller nodes, ensuring at
|
|
least one instance will be available in case of node failure.
|
|
Compute is also behind HAProxy, which detects when the software
|
|
fails and routes requests around the failing instance.</para>
|
|
<para>Compute's compute and conductor services, which run on the
|
|
compute nodes, are only needed to run services on that node, so
|
|
availability of those services is coupled tightly to the nodes
|
|
that are available. As long as a compute node is up, it will
|
|
have the needed services running on top of it.</para></td>
|
|
|
|
<td>The nova API, scheduler, objectstore, cert, consoleauth,
|
|
conductor, and vncproxy services are run on all controller nodes,
|
|
so scalability can be achieved with additional controller nodes.
|
|
HAProxy allows scalability for Compute as more nodes are added.
|
|
The scalability of services running on the compute nodes (compute,
|
|
conductor) is achieved linearly by adding in more compute
|
|
nodes.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Block Storage (cinder)</td>
|
|
|
|
<td>Controller</td>
|
|
|
|
<td>Configured to use Qpid, <phrase
|
|
role="keep-together"><literal>qpid_heartbeat = </literal><phrase
|
|
role="keep-together"><literal>10</literal>,</phrase></phrase><phrase
|
|
role="keep-together"> configured to use a Gluster</phrase> volume
|
|
from the storage layer as the back end for Block Storage, using the
|
|
Gluster native client.</td>
|
|
|
|
<td>Block Storage API, scheduler, and volume services are run on all
|
|
controller nodes, ensuring at least one instance will be available
|
|
in case of node failure. Block Storage also sits behind HAProxy,
|
|
which detects if the software fails and routes requests around the
|
|
failing instance.</td>
|
|
|
|
<td>Block Storage API, scheduler and volume services are run on
|
|
all controller nodes, so scalability can be achieved with
|
|
additional controller nodes. HAProxy allows scalability for Block
|
|
Storage as more nodes are added.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>OpenStack Networking (neutron)</td>
|
|
|
|
<td>Controller, Compute, Network</td>
|
|
|
|
<td>Configured to use QPID, <phrase
|
|
role="keep-together"><literal>qpid_heartbeat =
|
|
10</literal></phrase>, kernel namespace support enabled,
|
|
<literal>tenant_network_type = vlan</literal>,
|
|
<literal>allow_overlapping_ips = true</literal>,
|
|
<literal>tenant_network_type = vlan</literal>,
|
|
<literal>bridge_uplinks = br-ex:em2</literal>,
|
|
<literal>bridge_mappings = physnet1:br-ex</literal></td>
|
|
|
|
<td><para>The OpenStack Networking service is run on all
|
|
controller nodes, ensuring at least one instance will be available
|
|
in case of node failure. It also sits behind HAProxy, which
|
|
detects if the software fails and routes requests around the
|
|
failing instance.</para> <para>OpenStack Networking's
|
|
<literal>ovs-agent</literal>,
|
|
<literal>l3-agent</literal>,
|
|
<literal>dhcp-agent</literal>, and
|
|
<literal>metadata-agent</literal> services run on the network
|
|
nodes, as <literal>lsb</literal> resources inside of Pacemaker.
|
|
This means that in the case of network node failure, services are
|
|
kept running on another node. Finally, the
|
|
<literal>ovs-agent</literal> service is also run on all compute
|
|
nodes, and in case of compute node failure, the other nodes will
|
|
continue to function using the copy of the service running on
|
|
them.</para></td>
|
|
|
|
<td>The OpenStack Networking server service is run on all
|
|
controller nodes, so scalability can be achieved with additional
|
|
controller nodes. HAProxy allows scalability for OpenStack
|
|
Networking as more nodes are added. Scalability of services
|
|
running on the network nodes is not currently supported by
|
|
OpenStack Networking, so they are not be considered. One copy of
|
|
the services should be sufficient to handle the workload.
|
|
Scalability of the <literal>ovs-agent</literal> running on compute
|
|
nodes is achieved by adding in more compute nodes as
|
|
necessary.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table></para>
|
|
</section>
|
|
</section>
|