diff --git a/doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml b/doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml index 56f75ac335..a0d62c9e62 100644 --- a/doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml +++ b/doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml @@ -6,7 +6,7 @@ xml:id="prescriptive-examples-multi-cloud"> Prescriptive examples - Multi-cloud environments are designed for + Hybrid cloud environments are designed for these use cases: @@ -22,26 +22,24 @@ diversity) - This chapter discusses examples of environments + This chapter provides examples of environments that address each of these use cases. - Company A's data center is running dangerously low on - capacity. The option of expanding the data center will not be - possible in the foreseeable future. In order to accommodate +
+ Bursting to a public OpenStack cloud + 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 - resources in the public cloud. + organization, Company A decides to use resources in the public + cloud. Company A has an established data center with a substantial amount of hardware. Migrating the workloads to a public cloud is not feasible. The company has an internal cloud management platform that - will direct requests to the appropriate cloud, depending on - the local capacity. - - This is a custom in-house application written for + directs requests to the appropriate cloud, depending on + the local capacity. This is a custom in-house application written for this specific purpose. - - This solution is described in the figure - below. + This solution is depicted in the figure below: - This example shows two clouds, with a Cloud Management - Platform (CMP) connecting them. - - This guide does not attempt to - cover a specific CMP, but describes how the Orchestration and - Telemetry services handle, manage, and control workloads. This is - shown in the diagram above. - + This example shows two clouds with a Cloud Management + Platform (CMP) connecting them. This guide does not + discuss a specific CMP, but describes how the Orchestration and + Telemetry services handle, manage, and control workloads. The private OpenStack cloud has at least one - controller, and at least one compute node. It includes - metering provided by the Telemetry module. The Telemetry module - captures the load increase, and the CMP processes the information. + controller and at least one compute node. It includes + metering using the Telemetry module. The Telemetry module + 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. - In this example, "Company A" decided - not to direct the deployment to an external public cloud - over concerns regarding resource control, security, and - increase operational expense + In this example, Company A does not direct the deployments to an + external public cloud due to concerns regarding resource control, + security, and increased operational expense +
Bursting to a public non-OpenStack cloud - The second example looks into bursting workloads from the + 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. - For an OpenStack-to-AWS hybrid cloud, the architecture looks - similar to the figure below: + and to scale applications. + The following diagram demonstrates an OpenStack-to-AWS hybrid + cloud: - Company B states that the - developers were already using AWS and did not want to change - the cloud provider. - If the CMP is capable of connecting an external - cloud provider with the appropriate API, the workflow process - will remain the same as the previous scenario. The actions the - CMP takes such as monitoring loads, and creating new instances, - stay the same. However, the CMP will perform actions in the + Company B states that its developers are already using AWS and + do not want to change to a different provider. + If the CMP is capable of connecting to an external + cloud provider with an appropriate API, the workflow process + remains the same as the previous scenario. The actions the + CMP takes, such as monitoring loads and creating new instances, + stay the same. However, the CMP performs actions in the public cloud using applicable API calls. 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. 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.
- High availability/disaster recovery + High availability and disaster recovery 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 - to support the failure of large components of the system, yet - ensuring that the system will continue to deliver services. + Object Storage, and a database. The architecture + supports the failure of large components of the system while + 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 - replicated to a second cloud, in a geographically distant - location. The logical diagram of the system is described in - the figure below: + best practice data replication policies. To achieve these objectives, + Company C replicates data to a second cloud in a geographically distant + location. The following diagram describes this system: Object Storage relies on the replication capabilities of - the Object Storage provider. OpenStack Object Storage is - enabled so that it creates geographically separated replicas - that take advantage of this feature. It is configured so that - at least one replica exists in each cloud. In order to make - this work, a single array spanning both clouds is configured - with OpenStack Identity. Using Federated Identity, it talks + the Object Storage provider. Company C enables OpenStack Object Storage + so that it creates geographically separated replicas + that take advantage of this feature. The company configures storage + so that at least one replica exists in each cloud. In order to make + this work, the company configures a single array spanning both clouds + with OpenStack Identity. Using Federated Identity, the array talks to both clouds, communicating with OpenStack Object Storage through the Swift proxy. 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 - disaster recovery is configured for Block Storage for + but as a logical object that points to a physical back end. Disaster + 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 @@ 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 - through the CMP. The CMP knows to create identical - volumes in both clouds. Once this is configured, a solution, - involving DRDB, is used to synchronize the actual physical - drives. + has an identical back end. This is done by creating volumes + through the CMP. After this is configured, a solution + involving DRDB synchronizes the physical drives. 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.