Tweet This: Tweet
Share on LinkedIn:
By Steve Kaplan, Kovarus, SDDC & Cloud Management
In my previous post, I covered abstraction concepts and how VMware vRealize Automation Cloud (the artist formerly known as Cloud Automation Services) provided a streamlined platform for the multi-cloud world we all find ourselves living in now. While I was able to cover most of the relevant constructs that make this possible, there were a few things that got left on the editing floor that can complete the circle in highlighting how IaaS capabilities have really been overhauled.
A quick programming note / update that I should make right now: Since the previous post, VMware vRealize Automation 8.0 (vRA) was released on October 17th, 2019. This is big news because 8.0 is based entirely on vRA Cloud, so all capabilities exposed to the SaaS platform will eventually make their way to the on-premises release! All that said, everything in both this and the previous post apply, regardless of your choice of form factor.
For those familiar with how vRA, prior to Cloud Assembly, used reservations to bind resources together, I’ll try and walk through how these capabilities are different, what those changes mean, and what the operational impact is to operators.
Let’s start by defining what a network profile is in Cloud Assembly. A network profile is a logical grouping of networks and associated settings that are available for a cloud account. Think of a network profile as a collection of workload-specific network characteristics that can be rationalized and abstracted utilizing tags to define those characteristics to make allocation a more dynamic process. They can be as granular and prescriptive as required to support a very specific application and/or use case, or as broad as being a general policy for a cloud account.
As a refresher, network profiles had previously served as a very simple IP Address Manager (IPAM) to dispense IPs or integrate with another IPAM such as Infoblox in a framework and as a way to constrain which reservations could be allocated by specifying the network profile in the blueprint. The association between the profile and the vSphere port group was made in the compute reservation, where you could then go and add some of the other network considerations for on-demand network characteristics (like which DLR to use for routed on-demand networks). These relationships were mostly 1:1, and because reservations were tied back to business groups, ongoing sustainment of these configuration details could get cumbersome if more than one business group was associated with a compute resource.
Let’s break that down into a few screenshots and explore!
The previous image is from the summary page of a network profile in our vRA Cloud instance, and as you can see it’s tied to a cloud account that was named NSX-V Environment. I want to highlight three things here:
- The profile is defined at the Cloud Account, which is an important distinction between Cloud Assembly and the way things used to be. As I noted above, these associations used to be tied to one compute resource and one business group. Now, in this new world order, the network constructs are completely decoupled from the users consuming, and all of the associated networks in that account are fair game to be used. This is a huge change that addresses some of the ugliest pain points for implementations with complex networking requirements that needs to be adaptable and flexible.
- The capability tag provides somewhere to define additional characteristics to selected networks in the profile, and any tags applied at the profile level automatically propagate and are considered part of the individual networks’ capabilities if that network profile is selected as part of the allocation process.
- While I used a vSphere example for both the example and screenshots, this applies to any supported cloud account.
Let’s move to the next section of network profiles I want to highlight: network assignment. The above screenshot is intended to highlight the aggregation of networks. As visualized, I have two port groups defined here, but with the capability tag of category:demo, as I did in the capability tags applied to the network profile. Imagine a scenario where you built a three-tier application that needs to be distributed against multiple networks based on functionality. You could easily define a capability tag at the network profile level that functions to distinguish the application itself, then provide more discrete tags at the network levels for things like a web, app, and database tiers that get consumed. In the blueprint, you’d set two tag constraints on the defined networks: one for the application tag to get into the correct network profile, and a second that gets used to specify the role.
Putting aside the operational aspects of decoupling, which are immense, the big impact here is that we are now able to define these constructs across multiple cloud accounts, so when building cloud agnostic blueprints,we are able to define all of this as policy, then let the cloud agnostic resources in the blueprint determine the best place to allocate resources from using other capability tags in tandem. This alone should significantly reduce blueprint sprawl for those scenarios where network placement needs to be dynamic.
You can find more information about using and managing network profiles at VMware’s own documentation, which is actually pretty good!
Another place we see massive improvements in functionality available right out of the box is with storage policies. I’m going to stick with the vSphere example here to highlight some things that, for vSphere environments, is a pretty important set of improvements, but rest assured that much has been improved for public cloud providers, as well.
What are storage policies, you’re asking? Well, put simply, storage profiles allow you to define characteristics for consumption of storage within a region within a cloud account; very similar to network profiles. Storage profiles in the pre-Cloud Assembly days largely had many of the same struggles that network profiles did: they were tied to reservations, which made ongoing management clumsy and unsustainable at scale if a change had to be made. Like their network brethren, storage policies are now completely decoupled from everything except the cloud zone and offers a ton more in the way of features aligned to the type of cloud account in question.
The difference, in my opinion, is that storage is a more ephemeral resource to be consumed in public clouds due to there being no upfront capital expenditure, or a very concrete resource on the backend that operators have to think about. When we look at on-premises infrastructure, the cost is usually a heavy upfront cost with a big box sitting in the data center. That capitalization is why I’d like to focus my time here on the vSphere side of the house, as the use case I’ll walk through here is common enough in either a traditional three-tier or hyper-converged infrastructure deployment.
So, let’s break down the previous screenshot and think through what the implications of this are in a very simple yet effective way. Let’s take a simple 8-node vSAN cluster and let’s say, for this specific environment, we have defined four storage policies on the vCenter for this cluster:
- Bronze: RAID-5, FTT=1
- Silver: RAID-6, FTT=1
- Gold: RAID-1, FTT=1
- Platinum: RAID-1, FTT=2
Since Storage Policy-Based Management (SPBM) is defined as a global resource in vCenter, we simply specify the SPBM policy to use for the cloud account (optionally a specific datastore if the need to get more granular arises), set the relevant values for things like shares and IOPS, then set capability tags for the profile itself. For this example, we’d specify the storage tier associated with the policy in question as the capability tag. Then, when defining storage characteristics in the blueprint, they can either be hard coded, or provided as an input for the requester to select the appropriate tier they want to use for their deployment.
Operationally speaking, while this may be less than ideal because we can’t define SPBM policy and have it applied on the fly by Cloud Assembly, this still represents a marked improvement compared to the legacy IaaS capabilities, where most of these capabilities didn’t even live natively inside of the product, and we had to rely on vRealize Orchestrator workflows to extend and provide this sort of integration.
You can find more information about using and managing network profiles at VMware’s Document Page.
I’ve spent a lot of time to this point talking about how network and storage profiles are decoupled from reservations and all of the great things that means… but I haven’t really talked about reservations and how this aspect has shifted under Cloud Assembly. The good news is that this has been markedly streamlined to reduce the pain. Cloud Assembly has introduced a whole new concept called projects, which are something of a mix of fabric groups, business groups and reservations. I say that because the project governs and associates few things that are important:
- What cloud zones (not to be confused with regions!) are available
- Constraints for network, storage, and extensibility
- What integrations are available; these are going to be things like an Active Directory domain or a GitHub repo for blueprints
- Who has access to these resources
- Any tags or custom properties that should be added to resources provisioned for the project
- Blueprints, while shareable, have to be associated with a project as a baseline
Obviously, that’s a lot of ground to cover, and some has been covered in other places in this and the previous post, so I’m going to largely focus on the first two, as they’re the most relevant for talking about infrastructure abstraction.
Let’s look at the first box I have highlighted in red. In the past, if we wanted to associate a business group with a compute resource, whether that be an availability zone in Amazon Web Services (AWS) or a vSphere cluster, that was a series of 1:1 mappings giving that business group access to the resource. Personally, the thought of having to manage those relationships at scale always left me wanting to grind my teeth and throw up my arms in frustration. In contrast, when you define the project, you now go and say “here’s all the regions available to this project,” which has already reduced the scale issues substantially since now your cloud zone is reusable across multiple projects, as appropriate, but it’s a now a 1-to-many relationship. That already cuts down a lot of the operational pain.
The second box, highlighted in blue, is also a very interesting area and something that I don’t think was, easily at least, doable prior. As part of defining the characteristics of the project, an operator can explicitly define constraints for both network and storage resources. Where does this sort of thing become applicable? I’ll throw out a scenario:
Let’s say a project is defined to support application provisioning for a specific subset that require a higher level of security due to the nature of the data available for access; for this example, let’s say any resources need to be on a network that has been accredited for PCI compliance and the underlying storage must be encrypted. By defining capability tags for PCI and encryption and applying them to the relevant network and storage profiles, and then setting them as constraints on the project as a hard requirement, you can enforce these policies for applications provisioned as part of this project without having to define it within each blueprint.
The question may arise as to why defining at the blueprint wouldn’t be preferable to ensure that, and the answer is that there isn’t anything stopping it being set at both or either levels, but there are scenarios I’ve encountered where sometimes an application is constrained based on the underlying data being placed in it. If you have a generic pattern in use, or would like the blueprint itself to be usable by multiple projects that have different constraints, this is an excellent way to remove dependencies that may be more situationally applicable and reduces flexibility associated with having to set it in the blueprint.
You can find more information about using and managing network profiles at VMware’s document page.
So that wraps up this session of Cloud Wars! I hope this entry was as useful for you reading it as it’s been for me writing this, thinking through how we’ve done some of this previously and how much easier so many of those endeavors would have been under this way of operating. For anybody who’s had to live the life of managing reservations and the wonky means of reservation policies required to ensure consistent provisioning to the right compute target, this is going to feel like a breath of fresh air!
Looking to learn more about modernizing and automating IT? We created the Kovarus Proven Solutions Center (KPSC) to let you see what’s possible and learn how we can help you succeed. To learn more about the KPSC go to the KPSC page.
Also, follow Kovarus on LinkedIn for technology updates from our experts along with updates on Kovarus news and events.