openstack-manuals/doc/arch-design/source/hybrid-architecture.rst

Architecture

Map out the dependencies of the expected workloads and the cloud infrastructures required to support them to architect a solution for the broadest compatibility between cloud platforms, minimizing the need to create workarounds and processes to fill identified gaps.

For your chosen cloud management platform, note the relative levels of support for both monitoring and orchestration.

Image portability

The majority of cloud workloads currently run on instances using hypervisor technologies. The challenge is that each of these hypervisors uses an image format that may not be compatible with the others. When possible, standardize on a single hypervisor and instance image format. This may not be possible when using externally-managed public clouds.

Conversion tools exist to address image format compatibility. Examples include virt-p2v/virt-v2v and virt-edit. These tools cannot serve beyond basic cloud instance specifications.

Alternatively, 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 for more specific templating. Remember if you intend to use portable images for disaster recovery, application diversity, or high availability, your users could move the images and instances between cloud platforms regularly.

Upper-layer services

Many clouds offer complementary services beyond the basic compute, network, and storage components. These additional services often simplify the deployment and management of applications on a cloud platform.

When moving workloads from the source to the destination cloud platforms, consider that the destination cloud platform may not have comparable services. Implement workloads in a different way or by using a different technology.

For example, moving an application that uses a NoSQL database service such as MongoDB could cause difficulties in maintaining the application between the platforms.

There are a number of options that are appropriate for the hybrid cloud use case:

• Implementing a baseline of upper-layer services across all of the cloud platforms. For platforms that do not support a given service, create a service on top of that platform and apply it to the workloads as they are launched on that cloud.

• For example, through the Database service for OpenStack (trove), OpenStack supports MySQL as a service but not NoSQL databases in production. To move from or run alongside AWS, a NoSQL workload must use an automation tool, such as the Orchestration service (heat), to recreate the NoSQL database on top of OpenStack.

• Deploying a Platform-as-a-Service (PaaS) technology that abstracts the upper-layer services from the underlying cloud platform. The unit of application deployment and migration is the PaaS. It leverages the services of the PaaS and only consumes the base infrastructure services of the cloud platform.

• Using automation tools to create the required upper-layer services that are portable across all cloud platforms.

  For example, instead of using database services that are inherent in the cloud platforms, launch cloud instances and deploy the databases on those instances using scripts or configuration and application deployment tools.

Network services

Network services functionality is a critical component of multiple cloud architectures. It is an important factor to assess when choosing a CMP and cloud provider. Considerations include:

• Functionality
• Security
• Scalability
• High availability (HA)

Verify and test critical cloud endpoint features.

• After selecting the network functionality framework, you must confirm the functionality is compatible. This ensures testing and functionality persists during and after upgrades.

  Note

  Diverse cloud platforms may de-synchronize over time if you do not maintain their mutual compatibility. This is a particular issue with APIs.

• Scalability across multiple cloud providers determines your choice of underlying network framework. It is important to have the network API functions presented and to verify that the desired functionality persists across all chosen cloud endpoint.

• High availability implementations vary in functionality and design. Examples of some common methods are active-hot-standby, active-passive, and active-active. Develop your high availability implementation and a test framework to understand the functionality and limitations of the environment.

• It is imperative to address security considerations. For example, addressing how data is secured between client and endpoint and any traffic that traverses the multiple clouds. Business and regulatory requirements dictate what security approach to take. For more information, see the Security requirements <security> chapter.

Data

Traditionally, replication has been the best method of protecting object store implementations. A variety of replication methods exist in storage architectures, for example synchronous and asynchronous mirroring. Most object stores and back-end storage systems implement methods for replication at the storage subsystem layer. Object stores also tailor replication techniques to fit a cloud's requirements.

Organizations must find the right balance between data integrity and data availability. Replication strategy may also influence disaster recovery methods.

Replication across different racks, data centers, and geographical regions increases focus on determining and ensuring data locality. The ability to guarantee data is accessed from the nearest or fastest storage can be necessary for applications to perform well.

Note

When running embedded object store methods, ensure that you do not instigate extra data replication as this can cause performance issues.