diff --git a/doc/arch-design/hybrid/section_architecture_hybrid.xml b/doc/arch-design/hybrid/section_architecture_hybrid.xml index fdc1faded7..60a523f694 100644 --- a/doc/arch-design/hybrid/section_architecture_hybrid.xml +++ b/doc/arch-design/hybrid/section_architecture_hybrid.xml @@ -16,8 +16,8 @@ the need to create workarounds and processes to fill identified gaps. Note the evaluation of the monitoring and orchestration APIs available on each cloud platform and the - relative levels of support for them in the chosen Cloud - Management Platform. + relative levels of support for them in the chosen cloud + management platform. There are conversion tools such as virt-v2v - (http://libguestfs.org/virt-v2v/) and virt-edit - (http://libguestfs.org/virt-edit.1.html) that can be used in - those scenarios but they are often not suitable beyond very - basic cloud instance specifications. An alternative is to - build a thin operating system image as the base for new - instances. This facilitates rapid creation of cloud instances - using cloud orchestration or configuration management tools, - driven by the CMP, for more specific templating. Another more - expensive option is to use a commercial image migration tool. - The issue of image portability is not just for a one time - migration. If the intention is to use the multiple cloud for - disaster recovery, application diversity or high availability, - the images and instances are likely to be moved between the - different cloud platforms regularly. + + (http://libguestfs.org/virt-v2) + and virt-edit (http://libguestfs.org/virt-edit.1.html) + that can be used in those scenarios but they are often not + suitable beyond very basic cloud instance specifications. An + alternative is to build a thin operating system image as the + base for new instances. This facilitates rapid creation of + cloud instances using cloud orchestration or configuration + management tools, driven by the CMP, for more specific + templating. Another more expensive option is to use a + commercial image migration tool. The issue of image + portability is not just for a one time migration. If the + intention is to use the multiple cloud for disaster recovery, + application diversity or high availability, the images and + instances are likely to be moved between the different cloud + platforms regularly.
Upper-layer services Many clouds offer complementary services over and above the @@ -116,7 +120,7 @@ multiple cloud architectures. It could be an important factor to assess when choosing a CMP and cloud provider. Considerations are: functionality, security, scalability and - High availability (HA). Verification and ongoing testing of + high availability (HA). Verification and ongoing testing of the critical features of the cloud endpoint used by the architecture are important tasks. @@ -142,8 +146,8 @@ High availability (HA) implementations vary in functionality and design. Examples of some common - methods are Active-Hot-Standby, Active-Passive and - Active-Active. High availability and a test framework + methods are active-hot-standby, active-passive and + active-active. High availability and a test framework need to be developed to insure that the functionality and limitations are well understood. diff --git a/doc/arch-design/hybrid/section_operational_considerations_hybrid.xml b/doc/arch-design/hybrid/section_operational_considerations_hybrid.xml index e5556ba6d0..ca1b64e7a4 100644 --- a/doc/arch-design/hybrid/section_operational_considerations_hybrid.xml +++ b/doc/arch-design/hybrid/section_operational_considerations_hybrid.xml @@ -70,8 +70,8 @@ in one of the cloud solutions in use to support the new functionality.
- Network Operation Center (NOC) - When planning the Network Operation Center for a hybrid + Network Operation Center + When planning the Network Operation Center (NOC) for a hybrid cloud environment, it is important to recognize where control over each piece of infrastructure resides. If a significant portion of the cloud is on externally managed systems, be diff --git a/doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml b/doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml index b1fe9de381..a2316f997b 100644 --- a/doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml +++ b/doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml @@ -18,7 +18,7 @@ non-OpenStack clouds - High Availability across clouds (for technical + High availability across clouds (for technical diversity) @@ -84,7 +84,7 @@ /> - In this scenario CompanyA has an additional requirement in + In this scenario company A has an additional requirement in that the developers were already using AWS for some of their work and did not want to change the cloud provider. Primarily due to excessive overhead with network firewall rules that @@ -152,10 +152,12 @@ 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 - Cinder API makes it possible to export the data and also the + Block Storage API makes it possible to export the data and also the metadata of a particular volume, so that it can be moved and replicated elsewhere. More information can be found here: - https://blueprints.launchpad.net/cinder/+spec/cinder-backup-volume-metadata-support. + https://blueprints.launchpad.net/cinder/+spec/cinder-backup-volume-metadata-support. + 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 diff --git a/doc/arch-design/hybrid/section_tech_considerations_hybrid.xml b/doc/arch-design/hybrid/section_tech_considerations_hybrid.xml index 55d201c887..e0066f7c21 100644 --- a/doc/arch-design/hybrid/section_tech_considerations_hybrid.xml +++ b/doc/arch-design/hybrid/section_tech_considerations_hybrid.xml @@ -1,4 +1,8 @@ + +%openstack; +]>
Oversubscription is a method to emulate more capacity than they may physically be present. For example, a physical - hypervisor node with 32 gigabytes of RAM may host 24 - instances, each provisioned with 2 gigabytes of RAM. As long + hypervisor node with 32 GB RAM may host 24 + instances, each provisioned with 2 GB RAM. As long as all 24 of them are not concurrently utilizing 2 full gigabytes, this arrangement is a non-issue. However, some hosts take oversubscription to extremes and, as a result, @@ -161,7 +165,7 @@ parameters, user names, and passwords. In deployments behind an organization's firewall, this domain is considered trusted. In a public cloud model which could be part of an architecture, - this would have to be assessed with the Public Cloud provider + this would have to be assessed with the public cloud provider to understand the controls in place. The data security domain is concerned primarily with information pertaining to the storage services within @@ -216,8 +220,12 @@ cloud may not do the same in another. Be sure to know the security requirements of every cloud that handles the organization's data or workloads. - More information on OpenStack Security can be found at - http://docs.openstack.org/security-guide/
+ More information on OpenStack Security can be found in the + OpenStack + Security Guide. + +
Utilization When it comes to utilization, it is important that the CMP @@ -279,7 +287,7 @@ considered: - OpenStack Compute (Nova): Regardless of deployment + OpenStack Compute (nova): Regardless of deployment location, hypervisor choice has a direct effect on how difficult it is to integrate with one or more additional clouds. For example, integrating a Hyper-V @@ -287,18 +295,18 @@ compatibility issues than if KVM is used. - Networking: Whether OpenStack Networking (Neutron) - or Nova-network is used, the network is one place + Networking: Whether OpenStack Networking (neutron) + or nova-network is used, the network is one place where integration capabilities need to be understood in order to connect between clouds. - Telemetry module (Ceilometer): Use of Telemetery + Telemetry module (ceilometer): Use of Telemetery depends, in large part, on what the other parts of the cloud are using. - Orchestration module (Heat): Similarly, Orchestration can + Orchestration module (heat): Similarly, Orchestration can be a valuable tool in orchestrating tasks a CMP decides are necessary in an OpenStack-based cloud. diff --git a/doc/arch-design/hybrid/section_user_requirements_hybrid.xml b/doc/arch-design/hybrid/section_user_requirements_hybrid.xml index cce0ee8f62..e55936965f 100644 --- a/doc/arch-design/hybrid/section_user_requirements_hybrid.xml +++ b/doc/arch-design/hybrid/section_user_requirements_hybrid.xml @@ -14,9 +14,11 @@ risks. Business considerations to make when designing a hybrid cloud deployment include: - + + + Cost - Cost: A hybrid cloud architecture involves multiple + A hybrid cloud architecture involves multiple vendors and technical architectures. These architectures may be more expensive to deploy and maintain. Operational costs can be higher because of @@ -26,8 +28,11 @@ virtue of using a cloud brokerage tool to deploy the workloads to the most cost effective platform. + + + Revenue opportunity - Revenue opportunity: Revenue opportunities vary + Revenue opportunities vary greatly based on the intent and use case of the cloud. If it is being built as a commercial customer-facing product, consider the drivers for building it over @@ -36,8 +41,11 @@ customers, thus enhancing the revenue opportunity. + + + Time to market - Time to Market: One of the most common reasons to + One of the most common reasons to use cloud platforms is to speed the time to market of a new product or application. A business requirement to use multiple cloud platforms may be because there @@ -46,23 +54,30 @@ migrating components and refactoring to a single platform. + + + Business or technical diversity - Business or technical diversity: Organizations + Organizations already leveraging cloud-based services may wish to embrace business diversity and utilize a hybrid cloud design to spread their workloads across multiple cloud providers so that no application is hosted in a single cloud provider. + + + Application momentum - Application momentum: A business with existing + A business with existing applications that are already in production on multiple cloud environments may find that it is more cost effective to integrate the applications on multiple cloud platforms rather than migrate them to a single platform. - + +
Legal requirements Many jurisdictions have legislative and regulatory @@ -91,12 +106,14 @@ Examples of such legal frameworks include the data - protection framework of the European Union - (http://ec.europa.eu/justice/data-protection/) and the - requirements of the Financial Industry Regulatory Authority - (http://www.finra.org/Industry/Regulation/FINRARules/) in the - United States. Consult a local regulatory body for more - information.
+ protection framework of the European Union (http://ec.europa.eu/justice/data-protection/) + and the requirements of the Financial Industry Regulatory + Authority (http://www.finra.org/Industry/Regulation/FINRARules/) + in the United States. Consult a local regulatory body for more + information. +
Workload considerations Defining what the word "workload" means in the context of a @@ -246,8 +263,8 @@ High availability implementations vary in functionality and design. Examples of some common - methods are Active-Hot-Standby, Active-Passive and - Active-Active. High availability and a test framework + methods are active-hot-standby, active-passive and + active-active. High availability and a test framework needs to be developed to insure that the functionality and limitations are well understood. @@ -269,9 +286,11 @@ could remain operational. Risks that will be heightened by using a hybrid cloud architecture include: - + + + Provider availability or implementation details - Provider availability or implementation details: + This can range from the company going out of business to the company changing how it delivers its services. Cloud architectures are inherently designed to be @@ -279,8 +298,11 @@ both perceived to be rock solid and ever flexible at the same time. + + + Differing SLAs - Differing SLAs: Users of hybrid cloud environments + Users of hybrid cloud environments potentially encounter some losses through differences in service level agreements. A hybrid cloud design needs to accommodate the different SLAs provided by @@ -288,8 +310,11 @@ address the actual enforceability of the providers' SLAs. + + + Security levels - Security levels: Securing multiple cloud + Securing multiple cloud environments is more complex than securing a single cloud environment. Concerns need to be addressed at, but not limited to, the application, network, and @@ -300,8 +325,11 @@ uses a relatively simple model that relies on user privilege combined with firewalls. + + + Provider API changes - Provider API changes: APIs are crucial in a hybrid + APIs are crucial in a hybrid cloud environment. As a consumer of a provider's cloud services, an organization will rarely have any control over provider changes to APIs. Cloud services that @@ -315,5 +343,7 @@ common and basic APIs to minimize potential conflicts. -
+ + +