Skip to content

Commit

Permalink
Updated availability zone information
Browse files Browse the repository at this point in the history 
bug: #1107419

Change-Id: I915a3b8fa102d95822b9354f7e5ef28c6c861ee3
author: diane fleming
  • Loading branch information
@dian4554
dian4554 committed May 13, 2013
1 parent 812bba1 commit c0b6b6d
Show file tree
Hide file tree
Showing 3 changed files with 99 additions and 53 deletions.
2 changes: 1 addition & 1 deletion doc/src/docbkx/openstack-ops/pom.xml
View file
Expand Up @@ -26,7 +26,7 @@
<plugin>
<groupId>com.rackspace.cloud.api</groupId>
<artifactId>clouddocs-maven-plugin</artifactId>
<version>1.7.3-SNAPSHOT</version>
<version>1.8.0</version>

<executions>
<execution>
Expand Down
11 changes: 10 additions & 1 deletion doc/src/docbkx/openstack-ops/src/bk_ops_guide.xml
View file
Expand Up @@ -46,7 +46,16 @@
</abstract>
<revhistory>
<revision>
<!-- ... continue addding more revisions here as you change this document using the markup shown below... -->
<!-- ... continue adding more revisions here as you change this document using the markup shown below... -->
<date>2013-05-13</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Updated description of availability zones.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision><revision>
<date>2013-04-02</date>
<revdescription>
<itemizedlist spacing="compact">
Expand Down
139 changes: 88 additions & 51 deletions doc/src/docbkx/openstack-ops/src/ch_arch_scaling.xml
View file
Expand Up @@ -334,46 +334,83 @@
</section>
<section xml:id="availability_zones">
<title>Availability Zones and Host Aggregates</title>
<para>Both availability zones and host aggregates
partition a single nova deployment. While seeming
similar to configure, host aggregates and availability
zones differ in their intended use. The former allows
the partition of OpenStack Compute deployments into
logical groups for load balancing and instance
distribution, the latter are used to provide some form
of physical isolation and redundancy from other
availability zones (such as by using separate power
supply or network equipment). Host aggregates can be
regarded as a mechanism to further partitioning an
availability zone, i.e. into multiple groups of hosts
that share common resources like storage and network,
or have a special property such as trusted computing
hardware.</para>
<para>A common use of host aggregates is to provide
information for use with the
<code>nova-scheduler</code>. For example, limiting
specific flavours or images to a subset of
hosts.</para>
<para>Availability zones allow you to arrange sets of
either OpenStack Compute or OpenStack Block Storage
hosts into logical groups. You define the availability
zone that a given Compute or block Storage host is in
locally on each server. Availability zones are
commonly used to identify a sets of servers that have
some common attribute. For instance, if some of the
racks in your data center are on a separate power
source, you may put servers in those racks in their
own availability zone. Availability zones can also be
helpful for separating out different classes of
hardware. This is especially helpful with OpenStack
Block Storage where you may have storage servers with
different types of hard drives. When provisioning
resources, users can specify what availability zone
they would like their instance or volume to come from.
This allows cloud consumers to ensure that their
application resources are spread across multiple
disparate machines to achieve high availability in the
event of hardware failure.</para>
<para>You can use availability zones, host aggregates, or
both to partition a nova deployment. </para>
<para>Availability zones are implemented through and
configured in a similar way to host aggregates.</para>
<para>However, you use an availability zone and a host
aggregate for different reasons:</para><itemizedlist>
<listitem>
<para><emphasis role="bold">Availability
zone</emphasis>. Enables you to arrange
OpenStack Compute hosts into logical groups,
and provides a form of physical isolation and
redundancy from other availability zones, such
as by using separate power supply or network
equipment. </para>
<para>You define the availability zone in which a
specified Compute host resides locally on each
server. An availability zone is commonly used
to identify a set of servers that have a
common attribute. For instance, if some of the
racks in your data center are on a separate
power source, you can put servers in those
racks in their own availability zone.
Availability zones can also help separate
different classes of hardware. </para>
<para>When users provision resources, they can
specify from which availability zone they
would like their instance to be built. This
allows cloud consumers to ensure that their
application resources are spread across
disparate machines to achieve high
availability in the event of hardware
failure.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Host
aggregate</emphasis>. Enables you to
partition OpenStack Compute deployments into
logical groups for load balancing and instance
distribution. You can use host aggregates to
further partition an availability zone. For
example, you might use host aggregates to
partition an availability zone into groups of
hosts that either share common resources, such
as storage and network, or have a special
property, such as trusted computing
hardware.</para>
<para>A common use of host aggregates is to
provide information for use with the
nova-scheduler. For example, you might use a
host aggregate to group a set of hosts that
share specific flavors or images. </para>
</listitem></itemizedlist>
<note><para>Previously, all services had an availability zone. Currently,
only the nova-compute service has its own
availability zone. Services such as
nova-scheduler, nova-network, nova-conductor have
always spanned all availability zones.</para><para>When you run any of the following operations, the services
appear in their own internal availability zone
(CONF.internal_service_availability_zone): <itemizedlist>
<listitem>
<para>nova host-list (os-hosts) </para>
</listitem>
<listitem>
<para>euca-describe-availability-zones
verbose </para>
</listitem>
<listitem>
<para>nova-manage service list</para>
</listitem>
</itemizedlist>The internal availability zone is
hidden in euca-describe-availability_zones
(non-verbose).</para>
<para>CONF.node_availability_zone has been renamed to
CONF.default_availability_zone and is only used by
the nova-api and nova-scheduler services. </para>
<para>CONF.node_availability_zone still works but is
deprecated.</para></note>
</section>
</section>
<section xml:id="scalable_hardware">
Expand Down Expand Up @@ -403,24 +440,24 @@
at least have the same type of CPU to support instance
migration.</para>
<para>The typical hardware recommended for use with
OpenStack is "commodity". That is, very standard
"value-for-money" offerings that most hardware vendors
stock. It should be straightforward to divide your
procurement into building blocks such as "compute,"
"object storage," and "cloud controller," and request
as many of these as desired. Alternately should you be
unable to spend more, if you have existing servers,
provided they meet your performance requirements and
virtualization technology, these are quite likely to
be able to support OpenStack.</para>
OpenStack is the standard value-for-money offerings
that most hardware vendors stock. It should be
straightforward to divide your procurement into
building blocks such as "compute," "object storage,"
and "cloud controller," and request as many of these
as desired. Alternately should you be unable to spend
more, if you have existing servers, provided they meet
your performance requirements and virtualization
technology, these are quite likely to be able to
support OpenStack.</para>
</section>
<section xml:id="capacity_planning">
<title>Capacity Planning</title>
<para>OpenStack is designed to increase in size in a
straightforward manner. Taking into account the
considerations in the <emphasis role="bold"
>Scalability</emphasis> chapter — particularly on
the sizing of the cloud controller, it should be
the sizing of the cloud controller — it should be
possible to procure additional compute or object
storage nodes as needed. New nodes do not need to be
the same specification, or even vendor, as existing
Expand Down

0 comments on commit c0b6b6d

Please sign in to comment.