openstack/openstack-manuals
Code Issues Proposed changes

Arch Design edits

Browse Source 
Many minor edits:
Improve markup, follow conventions, add glossary items, fix
capitalization,...

Change-Id: I85693ef2d2c617327c707d13ffd5f05b4d97d1d7
This commit is contained in:
Andreas Jaeger 2014-08-13 19:51:21 +02:00
parent a65403c009
commit 0043fb7a7c
8 changed files with 59 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -60,7 +60,8 @@
launches a public cloud instance.</para>
<para>There are commercially available options, such as
Rightscale, and open source options, such as ManageIQ
(http://manageiq.org/), but there is no single CMP that can
(<link xlink:href="http://manageiq.org/">http://manageiq.org</link>),
but there is no single CMP that can
address all needs in all scenarios. Whereas most of the
sections of this book talk about the aspects of OpenStack, an
architect needs to consider when designing an OpenStack

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

@ -442,7 +442,7 @@
<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
patches for the proposed OS-hypervisor combination will have an
impact on performance and the patch installation process could
affect maintenance windows.</para>
</listitem>

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

@ -376,7 +376,8 @@
<para>Also consider several specialized components:</para>
<itemizedlist>
<listitem>
<para>Orchestration module (heat)</para>
<para><glossterm>Orchestration</glossterm> module
(<glossterm>heat</glossterm>)</para>
</listitem>
</itemizedlist>
<para>It is safe to assume that, given the nature of the

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

@ -730,7 +730,8 @@
certain components that will always be present, (Compute and
Image Service, for example) there are other services that may not be
required. As an example, a certain design might not need
Orchestration. Omitting Orchestration would not have a significant
<glossterm>Orchestration</glossterm>. Omitting
Orchestration would not have a significant
impact on the overall design of a cloud; however, if the
architecture uses a replacement for OpenStack Object Storage for its
storage component, it could potentially have significant

4
doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml
View File

@ -89,7 +89,9 @@
<para>There is also a potential to leverage the Orchestration and
Telemetry modules to provide an auto-scaling,
orchestrated web application environment. Defining the web
applications in Heat Orchestration Templates (HOT) would
applications in <glossterm
baseform="Heat Orchestration Template (HOT)">Heat Orchestration Templates (HOT)</glossterm>
would
negate the reliance on the scripted Puppet solution currently
employed.</para>
<para>OpenStack Networking can be used to control hardware load

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

@ -131,7 +131,7 @@
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 legacy networking (nova-network), as a
part of OpenStack Compute Service, and OpenStack Networking
part of OpenStack Compute, and OpenStack Networking
(neutron), has tremendous implications and will have
a huge impact on the architecture and design of the cloud
network infrastructure.</para>
@ -313,7 +313,7 @@
the distribution vendor's OpenStack packages might be a
requirement for support).</para>
<para>OS selection also directly influences hypervisor selection.
A cloud architect who selects Ubuntu or RHEL has some
A cloud architect who selects Ubuntu, RHEL, or SLES 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
@ -321,25 +321,35 @@
Server. Similarly, a cloud architect who selects XenServer is
limited to the CentOS-based dom0 operating system provided
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>
<itemizedlist>
<variablelist>
<varlistentry>
<term>User requirements</term>
<listitem>
<para>User requirements: The selection of OS/hypervisor
<para>The selection of OS-hypervisor
combination first and foremost needs to support the
user requirements.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Support</term>
<listitem>
<para>Support: The selected OS/hypervisor combination
<para>The selected OS-hypervisor combination
needs to be supported by OpenStack.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Interoperability</term>
<listitem>
<para>Interoperability: The OS/hypervisor needs to be
<para>The OS-hypervisor needs to be
interoperable with other features and services in the
OpenStack design in order to meet the user
requirements.</para>
</listitem>
</itemizedlist></section>
</varlistentry>
</variablelist>
</section>
<section xml:id="hypervisor-tech-considerations">
<title>Hypervisor</title>
<para>OpenStack supports a wide variety of hypervisors, one or
@ -347,7 +357,7 @@
include:</para>
<itemizedlist>
<listitem>
<para>KVM (and Qemu)</para>
<para>KVM (and QEMU)</para>
</listitem>
<listitem>
<para>XCP/XenServer</para>
@ -408,29 +418,38 @@
in a general purpose cloud are:</para>
<itemizedlist>
<listitem>
<para>OpenStack Compute (nova)</para>
<para>OpenStack <glossterm>Compute</glossterm>
(<glossterm>nova</glossterm>)</para>
</listitem>
<listitem>
<para>OpenStack Networking (neutron)</para>
<para>OpenStack <glossterm>Networking</glossterm>
(<glossterm>neutron</glossterm>)</para>
</listitem>
<listitem>
<para>OpenStack Image Service (glance)</para>
<para>OpenStack <glossterm>Image Service</glossterm>
(<glossterm>glance</glossterm>)</para>
</listitem>
<listitem>
<para>OpenStack Identity (keystone)</para>
<para>OpenStack <glossterm>Identity</glossterm>
(<glossterm>keystone</glossterm>)</para>
</listitem>
<listitem>
<para>OpenStack dashboard (horizon)</para>
<para>OpenStack <glossterm>dashboard</glossterm>
(<glossterm>horizon</glossterm>)</para>
</listitem>
<listitem>
<para>Telemetry module (ceilometer)</para>
<para><glossterm>Telemetry</glossterm> module
(<glossterm>ceilometer</glossterm>)</para>
</listitem>
</itemizedlist>
<para>A general purpose cloud may also include OpenStack Object
Storage (swift). OpenStack Block Storage (cinder) may be
<para>A general purpose cloud may also include OpenStack
<glossterm>Object Storage</glossterm> (<glossterm>swift</glossterm>).
OpenStack <glossterm>Block Storage</glossterm>
(<glossterm>cinder</glossterm>) may be
selected to provide persistent storage to applications and
instances although, depending on the use case, this could be
optional.</para></section>
optional.</para>
</section>
<section xml:id="supplemental-software-tech-considerations">
<title>Supplemental software</title>
<para>A general purpose OpenStack deployment consists of more than
@ -455,7 +474,7 @@
implementations are also made highly available. This high
availability can be achieved by using software such as
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
configuration depending on the specific service in the
OpenStack environment. Using this software can affect the
design as it assumes at least a 2-node controller

5
doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml
View File

@ -7,12 +7,13 @@
<?dbhtml stop-chunking?>
<title>User requirements</title>
<para>The general purpose cloud is built following the
Infrastructure-as-a-Service (IaaS) model; as a platform best
<glossterm baseform="IaaS">Infrastructure-as-a-Service (IaaS)</glossterm>
model; as a platform best
suited for use cases with simple requirements. The general
purpose cloud user requirements themselves are typically not
complex. However, it is still important to capture them even
if the project has minimum business and technical requirements
such as a Proof of Concept (PoC) or a small lab
such as a proof of concept (PoC) or a small lab
platform.</para>
<para>These user considerations are written from the perspective
of the organization that is building the cloud, not from the

3
doc/arch-design/introduction/section_how_this_book_is_organized.xml
View File

@ -7,7 +7,8 @@
<title>How this book is organized</title>
<para>This book has been organized into various chapters that help
define the use cases associated with making architectural
choices related to an OpenStack cloud installation. Each
choices related to an <glossterm>OpenStack</glossterm> cloud
installation. Each
chapter is intended to stand alone to encourage individual
chapter readability, however each chapter is designed to
contain useful information that may be applicable in