openstack/openstack-manuals
Code Issues Proposed changes

Architecture Design Guide - Specialized Chapter edits

Browse Source 
Small scale edits to the examples appearing in the specialized
chapter. Correct typos.

Change-Id: I08d80b5268beafcae5fa4ea7120839c341ce3481
Implements: blueprint arch-guide
This commit is contained in:
RobiJoe 2015-08-14 15:24:41 +10:00 committed by Joseph Robinson
parent edd448785b
commit 1c76ef3f4a
3 changed files with 29 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/arch-design/specialized/section_desktop_as_a_service_specialized.xml
View File

@ -39,18 +39,18 @@
</section>
<section xml:id="broker">
<title>Broker</title>
<para>The connection broker is a central component of the
architecture that determines which remote desktop host the user
connects to. The broker is often a
full-blown management product enabling the automated
<para>The connection broker determines which remote desktop host
users can access. Medium and large scale environments require a broker
since its service represents a central component of the architecture.
The broker is a complete management product, and enables automated
deployment and provisioning of remote desktop hosts.</para>
</section>
<section xml:id="possible-solutions">
<title>Possible solutions</title>
<para>
There are a number of commercial products currently available that
provide such a broker solution but nothing that is native to
the OpenStack project. Not providing a broker is also
provide a broker solution. However, no native OpenStack projects
provide broker services. Not providing a broker is also
an option, but managing this manually would not suffice for a
large scale, enterprise solution.
</para>

14
doc/arch-design/specialized/section_hardware_specialized.xml
View File

@ -7,7 +7,7 @@
<?dbhtml stop-chunking?>
<title>Specialized hardware</title>
<para>Certain workloads require specialized hardware devices that
are either difficult to virtualize or impossible to share.
have significant virtualization or sharing challenges.
Applications such as load balancers, highly parallel brute
force computing, and direct to wire networking may need
capabilities that basic OpenStack components do not
@ -18,7 +18,7 @@
improve performance or provide capabilities that are not
virtual CPU, RAM, network, or storage. These can be a shared
resource, such as a cryptography processor, or a dedicated
resource, such as a Graphics Processing Unit. OpenStack can
resource, such as a Graphics Processing Unit (GPU). OpenStack can
provide some of these, while others may need extra
work.</para>
</section>
@ -26,14 +26,14 @@
<title>Solutions</title>
<para>To provide cryptography offloading to a set of
instances, you can use Image service configuration
options to assign the cryptography chip to a device node in
the guest. The <citetitle>OpenStack Command Line
options. For example, assign the cryptography chip to a
device node in the guest. The <citetitle>OpenStack Command Line
Reference</citetitle> contains further information on
configuring this solution in the chapter <link
xlink:href="http://docs.openstack.org/cli-reference/content/chapter_cli-glance-property.html">
Image service property keys</link>, but it allows all
guests using the configured images to access the hypervisor
cryptography device.</para>
Image service property keys</link>. A challenge, however, is this
option allows all guests using the configured images
to access the hypervisor cryptography device.</para>
<para>If you require direct access to a specific device, PCI
pass-through enables you to dedicate the device to a single
instance per hypervisor. You must define a flavor that

31
doc/arch-design/specialized/section_openstack_on_openstack_specialized.xml
View File

@ -10,31 +10,32 @@
xml:id="arch-guide-openstack-on-openstack">
<?dbhtml stop-chunking?>
<title>OpenStack on OpenStack</title>
<para>In some cases it is necessary to run OpenStack nested on top
of another OpenStack cloud. This scenario enables you to manage
and provision complete OpenStack cloud environments on
instances running on hypervisors and servers that the underlying
OpenStack cloud controls. Public cloud providers can use
this technique to manage the upgrade and
maintenance process on complete OpenStack-based clouds.
<para>In some cases, users may run OpenStack nested on top
of another OpenStack cloud. This scenario describes how to
manage and provision complete OpenStack environments on instances
supported by hypervisors and servers, which an underlying OpenStack
environment controls.</para>
<para>Public cloud providers can use this technique to manage the
upgrade and maintenance process on complete OpenStack environments.
Developers and those testing OpenStack can also use this
guidance to provision their own OpenStack environments on
technique to provision their own OpenStack environments on
available OpenStack Compute resources, whether public or
private.</para>
<section xml:id="challenges-for-nested-cloud">
<title>Challenges</title>
<para>The network aspect of deploying a nested cloud is the most
complicated aspect of this architecture. You must expose VLANs
to the physical ports on which the underlying cloud runs,
as the bare metal cloud owns all the
hardware, but you must also expose them to the nested
to the physical ports on which the underlying cloud runs because
the bare metal cloud owns all the
hardware. You must also expose them to the nested
levels as well. Alternatively, you can use the network overlay
technologies on the OpenStack cloud running on OpenStack to provide
the required software defined networking for the deployment.</para>
technologies on the OpenStack environment running on the host
OpenStack environment to provide the required software defined
networking for the deployment.</para>
</section>
<section xml:id="hypervisor-nested-cloud">
<title>Hypervisor</title>
<para>A key question to address in this scenario is which
<para>In this example architecture, consider which
approach you should take to provide a nested
hypervisor in OpenStack. This decision influences which
operating systems you use for the deployment of the nested
@ -44,7 +45,7 @@
<title>Possible solutions: deployment</title>
<para>Deployment of a full stack can be challenging but you can mitigate
this difficulty by creating a Heat template to deploy the
entire stack or a configuration management system. After creating
entire stack, or a configuration management system. After creating
the Heat template, you can automate the deployment of additional stacks.</para>
<para>The OpenStack-on-OpenStack project (<glossterm>TripleO</glossterm>)
addresses this issue. Currently, however, the project does