By Michael Francis
Disclaimer: This blog is not a technical deep dive on Hybrid Cloud Manager; it talks to the components of the product and the design decisions around the product. It assumes the reader has knowledge of the product and its architecture.
Recently, I have been involved with the design and deployment of Hybrid Cloud Manager for some customers. It has been a very interesting exercise to work through the design and the broader implications.
Let’s start with a brief overview of Hybrid Cloud Manager. Hybrid Cloud Manager is actually comprised of a set of virtual appliances that reside both on-premises and in vCloud Air. The product is divided into a management plane, control plane, and data plane.
- The management plane is instantiated by a plugin in the vSphere Web Client.
- The control plane is instantiated by the Hybrid Cloud Manager virtual appliance.
- The data plane is instantiated by a number of virtual appliances – Cloud Gateway, Layer 2 Concentrator, and the WAN Opto appliance.
The diagram below illustrates these components and their relationships to each other on-premises and the components in vCloud Air.
Figure 1 – Logical Architecture Hybrid Cloud Manager
The Hybrid Cloud Manager provides virtual machine migration capability, which is built on two functions: virtual machine replication[1] and Layer 2 network extension. The combination of these functions provides an organization with the ability to migrate workloads without the logistical and technical issues traditionally associated with migrations to a public cloud; specifically, the outage time to copy on-premises virtual machines to a public cloud, and virtual machine re-addressing.
During a recent engagement that involved the use of Hybrid Cloud Manager, it became very obvious that even though this functionality simplifies the migration, it does not diminish the importance of the planning and design effort prior to any migration exercises. Let me explain.
Importance of Plan and Design
When discussing a plan, I am really discussing the importance of a discovery that deeply analyses
on-premises virtual workloads. This is critical, as the Hybrid Cloud Manager creates such a seamless extension to the on-premises environment, we need to understand:
- Which workloads will be migrated
- Which networks the workloads reside on
- What compute isolation requirements exist
- How and where network access control is instantiated on-premises
Modification of a virtual network topology in Public Cloud can be a disruptive operation; just as it is in the data center. Introducing an ability to stretch layer 2 network segments into the Public Cloud and migrating out of a data center into Public Cloud increases the number of networks and the complexity of the topology of the networks in the Public Cloud. So the more planning that can be done early the less likely disruptions to services will need to occur later.
One of the constraints in the solution revolves around stretching layer 2 network segments. A Layer 2 network segment located on-premises can be ‘stretched’ to one virtual data center in vCloud Air. So we have some implications of which workloads exist on a network segment, and which vCloud Air virtual data centers will be used to host the workloads on the on-premises network segment. This obviously influences the creation of virtual data centers in vCloud Air, and the principals defined in the design, which influence when additional virtual data centers are stood up – compared with growing an existing virtual data center.
Ideally, an assessment of on-premises workloads would be performed prior to any hybrid cloud design effort. This assessment would be used to size subsequent vCloud Air virtual data centers; plus, it would discover information about the workload resource isolation that drives the need for workload separation into multiple virtual data centers. For instance, the requirement to separate test/development workloads from production workloads with a ‘hard’ partition would be one example of a requirement that would drive a virtual data center design.
During this discovery we would also identify which workloads reside on which networks, and which networks require ‘stretching’ into vCloud Air. This would surface any issues we may face due to the constraint that we can only stretch a Layer 2 segment into one virtual data center.[2] This assessment really forms the ‘planning’ effort in this discussion.
Design Effort
The design effort involves designs for vCloud Air and Hybrid Cloud Manager. I believe the network design of vCloud Air is a critical element. We need to determine whether to use:
- Dynamic routing or static routing
- Subnet design and its relationship to routing summarization
- Routing paths to the Internet
- Estimated throughputs required for any virtual routing devices
- Other virtual network services
- Egress optimization functionality from Hybrid Cloud Manager
- And finally, we need to determine where security network access points are required
The other aspect is the design of the virtual compute containers, such as virtual data centers in vCloud Air. The design for vCloud Air should define the expected virtual data center design over the lifecycle of the solution. It would define the compute resource assignment to each virtual data center initially, and over the lifecycle as anticipated growth is factored in. During the growth of use, the requirements for throughput will increase on the networking components in vCloud Air, so the design should articulate guidance around when an increase in size of virtual routing devices will need to occur.
The vCloud Air platform is an extension of the on-premises infrastructure. It is a fundamental expectation that operations teams have visibility into the health of the infrastructure, and that capacity planning of infrastructure is taking place. Similarly, there is a requirement to ensure that the vCloud Air platform and associated services are healthy and capacity managed. We should be able to answer the question, “Are my virtual data center routing devices of the right size, and is their throughput sufficient for the needs of the workloads hosted in vCloud Air?” Ideally we should have a management platform that treats vCloud Air as an extension to our on-premises infrastructure.
This topic could go much deeper, and there are many other considerations as well, such as, “Should I place some management components in vCloud Air,” or, “Should I have a virtual data center in vCloud Air specifically assigned to host these management components?”
I believe today many people take an Agile approach to their deployment of public cloud services, such as networking and virtual compute containers. But I believe if you are implementing such a hybrid interface as offered by Hybrid Cloud Manager, there is real benefit to a longer term view to the design of vCloud Air services to minimise risk if we paint ourselves into a corner in the future.
Some Thoughts on Hybrid Cloud Manager Best Practices
Before wrapping up this blog, I wanted to provide some thoughts on some of the design decisions regarding Hybrid Cloud Manager.
In a recent engagement we considered best practices for placement of appliances, and we came up with the following design decisions.
Key Takeaways
The following are the key takeaways from this discussion:
- As Hybrid Cloud Manager provides a much more seamless extension of the on-premises data center, deeper thought and consideration needs to be put into the design of the vCloud Air public cloud services.
- To effectively design vCloud Air services for Hybrid Cloud requires a deep understanding of the on-premises workloads, and how they will leverage the hybrid cloud extension.
- Network design and ongoing network access controlling operational changes need to be considered.
- Management and monitoring of the vCloud Air services acts as an extension of the data center needs to be included in the scope of a Hybrid Cloud solution.
[1] Leverages the underlying functionality of vSphere Replication; but isn’t a full vSphere Replication architecture.
[2] This constraint could be overcome; however, the solution would require configurations that would make other elements of the design sub-optimal; for example, disabling the use of egress optimization.
Michael Francis is a Principal Systems Engineer at VMware, based in Brisbane.
