diff --git a/doc/src/docbkx/openstack-ops/pom.xml b/doc/src/docbkx/openstack-ops/pom.xml index 6e4d00f7397..f8be5526c3b 100644 --- a/doc/src/docbkx/openstack-ops/pom.xml +++ b/doc/src/docbkx/openstack-ops/pom.xml @@ -26,7 +26,7 @@ com.rackspace.cloud.api clouddocs-maven-plugin - 1.7.3-SNAPSHOT + 1.8.0 diff --git a/doc/src/docbkx/openstack-ops/src/bk_ops_guide.xml b/doc/src/docbkx/openstack-ops/src/bk_ops_guide.xml index 8dd1f736b8a..f2bfbb92c47 100644 --- a/doc/src/docbkx/openstack-ops/src/bk_ops_guide.xml +++ b/doc/src/docbkx/openstack-ops/src/bk_ops_guide.xml @@ -46,7 +46,16 @@ - + + 2013-05-13 + + + + Updated description of availability zones. + + + + 2013-04-02 diff --git a/doc/src/docbkx/openstack-ops/src/ch_arch_scaling.xml b/doc/src/docbkx/openstack-ops/src/ch_arch_scaling.xml index b590002922e..516ae2b3fcc 100644 --- a/doc/src/docbkx/openstack-ops/src/ch_arch_scaling.xml +++ b/doc/src/docbkx/openstack-ops/src/ch_arch_scaling.xml @@ -334,46 +334,83 @@
Availability Zones and Host Aggregates - 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. - A common use of host aggregates is to provide - information for use with the - nova-scheduler. For example, limiting - specific flavours or images to a subset of - hosts. - 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. + You can use availability zones, host aggregates, or + both to partition a nova deployment. + Availability zones are implemented through and + configured in a similar way to host aggregates. + However, you use an availability zone and a host + aggregate for different reasons: + + Availability + zone. 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. + 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. + 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. + + + Host + aggregate. 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. + 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. + + 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.When you run any of the following operations, the services + appear in their own internal availability zone + (CONF.internal_service_availability_zone): + + nova host-list (os-hosts) + + + euca-describe-availability-zones + verbose + + + nova-manage service list + + The internal availability zone is + hidden in euca-describe-availability_zones + (non-verbose). + CONF.node_availability_zone has been renamed to + CONF.default_availability_zone and is only used by + the nova-api and nova-scheduler services. + CONF.node_availability_zone still works but is + deprecated.
@@ -403,16 +440,16 @@ at least have the same type of CPU to support instance migration. 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. + 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.
Capacity Planning @@ -420,7 +457,7 @@ straightforward manner. Taking into account the considerations in the Scalability 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