Introduction

This is the second post in a multi-part series covering the SovLabs IPAM modules from a solutions design point of view. In this post, we will be integrating the SovLabs Property Toolkit in with our IPAM module and the SovLabs Template Engine. By leveraging these solutions, our customers are able to dynamically apply IPAM configurations at the time of resource provisioning using a data-driven approach. These more advanced use cases will utilize  metadata (think custom properties in vRealize Automation) directly from the request for a resource and use the metadata to dynamically select the IPAM configuration applied to the resource. All of the use cases we will cover have been seen during proof of concept engagements with real-world customers. 

Both posts will have the same basic requirements: 

  1. Minimize the amount of configuration overhead
  2. Simplify the process to add new networks in to the environment
  3. Minimize the amount of user input required for each configuration 

Sid Smith has already put together a really in depth look at the property toolkit in these posts: part 1, part 2, part 3; so I will not be covering the Property Toolkit in depth. 

 

Why the Property Toolkit?

In our earlier post we were able to address the use case presented by creating an IPAM profile for each network use case in our environment and then dynamically apply the network using the SovLabs_IPAMProfile_nic# custom property with the SovLabs Template Engine. This approach works great for smaller environments, but when networks start to grow in an environment my personal opinion is that using Property Toolkit property groups is far simpler than creating a new profile for each configuration. 

One of the features of the Property Toolkit is that it allows for dynamic application of vRA property groups during provisioning. While we will be leveraging that feature during this post, I first want to highlight why I prefer to take this approach in most of the large environments I encounter: 

  1. The creation of Property Groups can be easily scripted using the vRA REST API
  2. Property Groups can easily be copied to create a new property group for another IPAM configuration.
  3. Using a single IPAM profile allows for the sharing of information between profiles (DNS servers, DNS suffix, etc.)

 

Dynamically Select a Network Using Business Logic

For this post, we are going to cover Sample Use Case 3 from the first post in this series, but let’s approach it from a different angle. In this use case, the customer has separate tiers for web, app, and database servers. Each of those tiers has a respective network for each environment, and each datacenter has a representative network for each use case. The following diagram shows what this looks like. 

IPAM Design Deep-Dive - Part 2 - Property Toolkit Advanced Configurations 1

In the last post, we approached this use case by creating an IPAM profile for every single network. In this post, we will only be creating a single IPAM profile, and then creating a property group for each network purpose. When I create the property groups, I will be naming them intelligently enough so that I can use the property group name as a means of dynamically driving machines to the appropriate network. Take note below that each of the property groups are prepended with SVL_IPAM_. The SVL_ portion is used to denote that these are Property Toolkit property groups, and the IPAM_ portion of the name allows us to organize our property groups when searching for them in the property dictionary. Since the property groups are alphabetically organized by default, all of our SVL_IPAM_ groups will be grouped together, making the overall management of our solution a bit easier. Here is what this solution looks like. 

IPAM Design Deep-Dive - Part 2 - Property Toolkit Advanced Configurations 2

 

Create the IPAM Profile

The first step in implementing this solution is to create a templated IPAM profile. First, we’ll navigate to Catalog > Add IPAM Profile

IPAM Design Deep-Dive - Part 2 - Property Toolkit Advanced Configurations 3

At first, we set up the IPAM profile just like any other profile, we give it a label, select an IPAM type, select an IPAM host, and then the NIC number that we want this profile to apply to. Where the profile starts to become dynamic is when we use template engine language when entering the Subnets, Gateways, and Network Names. In this example, I will be referencing properties called ipamSubnet, ipamGateway, and ipamNetwork. 

IPAM Design Deep-Dive - Part 2 - Property Toolkit Advanced Configurations 4

For the remainder of the IPAM configuration I am going to leave it fairly static in nature as all of the remaining configurations are shared in my environment. 

IPAM Design Deep-Dive - Part 2 - Property Toolkit Advanced Configurations 5

 

Create the Property Groups

Now that we have created an IPAM profile, we need to create property groups that contain the three properties referenced in the IPAM Profile: ipamSubnet, ipamGateway, and ipamNetwork. The ipamSubnet property needs to be in the format of network/CIDR (x.x.x.x/x), ipamGateway needs to be the gateway for the subnet, and ipamNetwork must match exactly (case sensitive) the name of the virtual port group used for the backing network in vCenter. 

IPAM Design Deep-Dive - Part 2 - Property Toolkit Advanced Configurations 6

Once you have created the first property group the creation of additional property groups is easier because you can copy a property group. To copy a property group, simply highlight the property group and select Copy from the top menu. 

IPAM Design Deep-Dive - Part 2 - Property Toolkit Advanced Configurations 7

When copying a property group all of the information from the original property group can be easily manipulated to update the network settings to reflect the new network. 

IPAM Design Deep-Dive - Part 2 - Property Toolkit Advanced Configurations 8

 

Add the IPAM Profile to the Blueprint

Once all of the property groups have been created we are ready to start working with our blueprint. For all of the SovLabs configurations, we typically create a Property Group when a new configuration is created so that you can easily apply that configuration to any blueprint in your environment. In this case, that’s all we’re going to do is apply the property group for our defaultIPAMConfig to our blueprint.

IPAM Design Deep-Dive - Part 2 - Property Toolkit Advanced Configurations 9

 

Add the Property Groups to the Blueprint 

Now we use the SovLabs_CreateProperties_ method for adding our SVL_IPAM group dynamically to our blueprint. The reason we chose this method is that it allowed us to useTemplate Engine syntax to derive the resulting Property Toolkit property group name. The value for this property is a JSON string with name and value specified for the new property to be created.

IPAM Design Deep-Dive - Part 2 - Property Toolkit Advanced Configurations 10

When someone submits the request we can then take the two parameters that we know from the request (Environment and Tier) as well as the parameter that we know about the environment (dcName was configured on our Cluster Compute Resource in the first post) to decide what IPAM profile will be applied to the machine. 

IPAM Design Deep-Dive - Part 2 - Property Toolkit Advanced Configurations 11

When the Property Toolkit runs, in our sample, it will create a new property on the machine with a name of SVL_IPAM, and a value of SVL_IPAM_DC1ProdApp. The Property Toolkit will then search for any properties on our machine that are prepended with SVL_ (this tells it that we are trying to apply a Property Toolkit property group) and then search for the property group that matches the value of that field and apply it to our machine. In our example, the Property Toolkit will see that there is a property on our machine with the name of SVL_IPAM, and then it will find the SVL_IPAM_DC1ProdApp property group and apply it to our machine. The IPAM configuration will then read the appropriate network to be applied and request an IP address from the range specified in our property group. 

 

Summary

The approach taken in this post is not restricted to just this generic use case, but can be expanded to include any number of requirements and business logic within your environment. In the next post in this series, we will be looking at another advanced sample use case where each business group owns their own individual networks and requires the ability to be able to select the networks during the request.

Recommended Reading