Clean up prescriptive_examples_hybrid.xml

Change-Id: Ic8fda5cd75bd587d7157beff661e8ce7eb911d55
Implements: blueprint arch-guide

doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml

@@ -6,7 +6,7 @@
   xml:id="prescriptive-examples-multi-cloud">
     <?dbhtml stop-chunking?>
     <title>Prescriptive examples</title>
-    <para>Multi-cloud environments are designed for
+    <para>Hybrid cloud environments are designed for
         these use cases:</para>
     <itemizedlist>
         <listitem>
@@ -22,26 +22,24 @@
                 diversity)</para>
         </listitem>
     </itemizedlist>
-    <para>This chapter discusses examples of environments
+    <para>This chapter provides examples of environments
         that address each of these use cases.</para>
-    <para>Company A's data center is running dangerously low on
+    <section xml:id="bursting-to-public-openstack-cloud">
-        capacity. The option of expanding the data center will not be
+    <title>Bursting to a public OpenStack cloud</title>
-        possible in the foreseeable future. In order to accommodate
+    <para>Company A's data center is running low on
+        capacity. It is not possible to expand the data center in the
+        foreseeable future. In order to accommodate
         the continuously growing need for development resources in the
-        organisation, Company A decided to use
+        organization, Company A decides to use resources in the public
-        resources in the public cloud.</para>
+        cloud.</para>
     <para>Company A has an established data
          center with a substantial amount of hardware. Migrating the
          workloads to a public cloud is not feasible.</para>
     <para>The company has an internal cloud management platform that
-        will direct requests to the appropriate cloud, depending on
+        directs requests to the appropriate cloud, depending on
-        the local capacity.</para>
+        the local capacity. This is a custom in-house application written for
-      <note>
-        <para>This is a custom in-house application written for
            this specific purpose.</para>
-      </note>
+    <para>This solution is depicted in the figure below:</para>
-    <para>This solution is described in the figure
-        below.</para>
     <mediaobject>
         <imageobject>
             <imagedata contentwidth="4in"
@@ -49,18 +47,14 @@
             />
         </imageobject>
     </mediaobject>
-    <para>This example shows two clouds, with a Cloud Management
+    <para>This example shows two clouds with a Cloud Management
-        Platform (CMP) connecting them.</para>
+        Platform (CMP) connecting them. This guide does not
-      <note>
+        discuss a specific CMP, but describes how the Orchestration and
-        <para>This guide does not attempt to
+        Telemetry services handle, manage, and control workloads.</para>
-        cover a specific CMP, but describes how the Orchestration and
-        Telemetry services handle, manage, and control workloads. This is
-        shown in the diagram above.</para>
-      </note>
     <para>The private OpenStack cloud has at least one
-        controller, and at least one compute node. It includes
+        controller and at least one compute node. It includes
-        metering provided by the Telemetry module. The Telemetry module
+        metering using the Telemetry module. The Telemetry module
-        captures the load increase, and the CMP processes the information.
+        captures the load increase and the CMP processes the information.
         If there is available capacity, the CMP uses the
         OpenStack API to call the Orchestration service. This creates
         instances on the private cloud in response to user requests.
@@ -68,19 +62,19 @@
         the CMP issues a request to the Orchestration service API of
         the public cloud. This creates the instance on the public
         cloud.</para>
-    <para>In this example, "Company A" decided
+    <para>In this example, Company A does not direct the deployments to an
-        not to direct the deployment to an external public cloud
+        external public cloud due to concerns regarding resource control,
-        over concerns regarding resource control, security, and
+        security, and increased operational expense</para>
-        increase operational expense</para>
+    </section>
 
     <section xml:id="bursting-to-public-nonopenstack-cloud">
       <title>Bursting to a public non-OpenStack cloud</title>
-    <para>The second example looks into bursting workloads from the
+    <para>The second example examines bursting workloads from the
         private cloud into a non-OpenStack public cloud using Amazon
         Web Services (AWS) to take advantage of additional capacity
-        and scale applications.</para>
+        and to scale applications.</para>
-    <para>For an OpenStack-to-AWS hybrid cloud, the architecture looks
+    <para>The following diagram demonstrates an OpenStack-to-AWS hybrid
-        similar to the figure below:</para>
+        cloud:</para>
     <mediaobject>
         <imageobject>
             <imagedata contentwidth="4in"
@@ -88,40 +82,38 @@
             />
         </imageobject>
     </mediaobject>
-    <para>Company B states that the
+    <para>Company B states that its developers are already using AWS and
-        developers were already using AWS and did not want to change
+        do not want to change to a different provider.</para>
-        the cloud provider.</para>
+    <para>If the CMP is capable of connecting to an external
-    <para>If the CMP is capable of connecting an external
+        cloud provider with an appropriate API, the workflow process
-        cloud provider with the appropriate API, the workflow process
+        remains the same as the previous scenario. The actions the
-        will remain the same as the previous scenario. The actions the
+        CMP takes, such as monitoring loads and creating new instances,
-        CMP takes such as monitoring loads, and creating new instances,
+        stay the same. However, the CMP performs actions in the
-        stay the same. However, the CMP will perform actions in the
         public cloud using applicable API calls.</para>
     <para>If the public cloud is AWS, the CMP would use the
         EC2 API to create a new instance and assign an Elastic IP.
-        That IP can then be added to HAProxy in the private cloud.
+        It can then add that IP to HAProxy in the private cloud.
         The CMP can also reference AWS-specific
         tools such as CloudWatch and CloudFormation.</para>
     <para>Several open source tool kits for building CMPs are
-        available and can handle this kind of translation. This includes
+        available and can handle this kind of translation. Examples include
         ManageIQ, jClouds, and JumpGate.</para>
     </section>
 
     <section xml:id="high-availability-disaster-recovery">
-      <title>High availability/disaster recovery</title>
+      <title>High availability and disaster recovery</title>
     <para>Company C requires their local data center
         to be able to recover from failure. Some of the
         workloads currently in use are running on their private
         OpenStack cloud. Protecting the data involves Block Storage,
-        Object Storage, and a database. The architecture is designed
+        Object Storage, and a database. The architecture
-        to support the failure of large components of the system, yet
+        supports the failure of large components of the system while
-        ensuring that the system will continue to deliver services.
+        ensuring that the system continues to deliver services.
         While the services remain available to users, the failed
         components are restored in the background based on standard
-        best practice DR policies. To achieve the objectives, data is
+        best practice data replication policies. To achieve these objectives,
-        replicated to a second cloud, in a geographically distant
+        Company C replicates data to a second cloud in a geographically distant
-        location. The logical diagram of the system is described in
+        location. The following diagram describes this system:</para>
-        the figure below:</para>
     <mediaobject>
         <imageobject>
             <imagedata contentwidth="4in"
@@ -133,24 +125,24 @@
         with a CMP. The source cloud,
         OpenStack Cloud 1, includes a controller and at least one
         instance running MySQL. It also includes at least one Block
-        Storage volume and one Object Storage volume. This is so that the data
+        Storage volume and one Object Storage volume. This means that data
         is available to the users at all times. The details of the
         method for protecting each of these sources of data
         differs.</para>
     <para>Object Storage relies on the replication capabilities of
-        the Object Storage provider. OpenStack Object Storage is
+        the Object Storage provider. Company C enables OpenStack Object Storage
-        enabled so that it creates geographically separated replicas
+        so that it creates geographically separated replicas
-        that take advantage of this feature. It is configured so that
+        that take advantage of this feature. The company configures storage
-        at least one replica exists in each cloud. In order to make
+        so that at least one replica exists in each cloud. In order to make
-        this work, a single array spanning both clouds is configured
+        this work, the company configures a single array spanning both clouds
-        with OpenStack Identity. Using Federated Identity, it talks
+        with OpenStack Identity. Using Federated Identity, the array talks
         to both clouds, communicating with OpenStack Object Storage
         through the Swift proxy.</para>
     <para>For Block Storage, the replication is a little more
         difficult, and involves tools outside of OpenStack itself. The
         OpenStack Block Storage volume is not set as the drive itself
-        but as a logical object that points to a physical back end. The
+        but as a logical object that points to a physical back end. Disaster
-        disaster recovery is configured for Block Storage for
+        recovery is configured for Block Storage for
         synchronous backup for the highest level of data protection,
         but asynchronous backup could have been set as an alternative
         that is not as latency sensitive. For asynchronous backup, the
@@ -163,21 +155,19 @@
     </para>
     <para>The synchronous backups create an identical volume in both
         clouds and chooses the appropriate flavor so that each cloud
-        has an identical back end. This was done by creating volumes
+        has an identical back end. This is done by creating volumes
-        through the CMP. The CMP knows to create identical
+        through the CMP. After this is configured, a solution
-        volumes in both clouds. Once this is configured, a solution,
+        involving DRDB synchronizes the physical drives.</para>
-        involving DRDB, is used to synchronize the actual physical
-        drives.</para>
     <para>The database component is backed up using synchronous
         backups. MySQL does not support geographically diverse
         replication, so disaster recovery is provided by replicating
         the file itself. As it is not possible to use Object Storage
         as the back end of a database like MySQL, Swift replication
-        was not an option. It was decided not to store the data on
+        is not an option. Company C decides not to store the data on
         another geo-tiered storage system, such as Ceph, as Block
         Storage. This would have given another layer of protection.
         Another option would have been to store the database on an
-        OpenStack Block Storage volume and backing it up just as any
+        OpenStack Block Storage volume and backing it up like any
         other Block Storage.</para>
     </section>
 </section>