Integrating Infoblox IPAM with vRealize Automation - Part 3

This is the last article in my series on integrating InfoBlox with vRealize Automation.  Part 1 discussed the general setup of the integration, and specifically how the solution looked in vRealize Orchestrator.  Part 2 discussed how some of the common integration elements might be used, regardless of the IP allocation approach.  This last article is the guide to the specific IP allocation methods available, how to use them, and some guidance on which one might be right for you.

InfoBlox integration types

Method 1 – vRA allocates IP, registers in InfoBlox

In hindsight (as mentioned in Part 2), I believe this was the functionality I should have explored the first time!  It is where you allow vRealize Automation to continue to manage its own IP pools, pick addresses for VMs, use Network Profiles and all the other goodness from vRA.  However, once vRA allocates an address, it then calls out to the InfoBlox workflow to register that allocation in InfoBlox.  

This method assumes that there is a range of addresses that you can pre-assign to vRA usage, and that the ranges are matching between vRA and InfoBlox to ensure no conflicting usage of this range!

Specifically, this method picks up the following existing vRA properties that you have probably already taken care of in your vRA Network Profiles – so you don’t have to worry about them!

• VirtualMachine.IPaddress
• VirtualMachine.PrimaryDNS
• VirtualMachine.SecondaryDNS
• VirtualMachine.DNSSuffix
• VirtualMachine.SubnetMask
• VirtualMachine.Gateway
• VirtualMachine.PrimaryWins
• VirtualMachine.SecondaryWins
• VirtualMachine.DnsSearchSuffixes

Method 2 – InfoBox allocates from specified network

This is the method I initially explored, and unfortunately it had the consequence that I had to disable vRA Network Profiles for my vRA Reservation (well, I created a new reservation for blueprints using IPAM) to avoid the two IP management methods from conflicting with each other.  In particular, when Network Profiles are also present vRA assigns and manages the VM’s address from its own pool, and while InfoBlox was still invoked, that IPAM address was completely ignored.

You can specify a network is two ways.  One is to specify the network/CIDR identity of the desired network.  This is fine if you are dealing with a small number of distinct networks and the number of machines will not burst beyond that network’s limits.  To use this approach you specify the below two custom properties:

• Infoblox.IPAM.netaddr – the identity of the Infoblox Network to use, such as “172.16.50.x”
• Infoblox.IPAM.cidr – the subnet mask, such as “24”

The other way is to search for a set of networks by extended attributes.  This is possibly going to match several networks (which should be equal in purpose).  The cool thing about this method is that for very large environments, a virtual machine could need to exist in any number of adjacent network segments, or dynamic inputs such as location, environment, security level, etc.  For instance, you may be deploying into multiple 24-bit networks that are all equivalent (internal, data access layer), and you don’t know which one will be chosen because of (a) available addresses, or (b) during provisioning there might be some request input that determines network placement.

The custom properties to use for searching for networks by attributes are those below:

• Infoblox.IPAM.searchByEa – set this to “true” to use this search method
• Infoblox.IPAM.searchEa1Name – attribute name
• Infoblox.IPAM.searchEa1Value – attribute value to compare
• Infoblox.IPAM.searchEa1Comparison – comparison type, one of the following types:
• EQUAL
• EQUAL_CASE_INSENSITIVE
• GREATER_OR_EQUAL
• LESS_OR_EQUAL
• NOT_EQUAL
• REGULAR_EXPRESSION
• …  up to 10 search attributes can be specified, as below
• Infoblox.IPAM.searchEa10Name
• Infoblox.IPAM.searchEa10Value
• Infoblox.IPAM.searchEa10Comparison

Using the method of IP allocation by network, Infoblox expects to fill IP details from the DHCP options already existing in the network definition in the IPAM system.  However, the blueprint can specify “default” values for these, in case they are missing from Infoblox.  This would certainly NOT be recommended if you would be searching for networks, as different subnet ranges might be returned.  Additionally, any values found in Infoblox will override the provided values, and the blueprint values will be ignored – so it is not an override mechanism.

• Infoblox.IPAM.defaultGateway
• Infoblox.IPAM.defaultPrimaryDns
• Infoblox.IPAM.defaultSecondaryDns
• Infoblox.IPAM.defaultPrimaryWins
• Infoblox.IPAM.defaultSecondaryWins
• Infoblox.IPAM.defaultDnsSuffix
• Infoblox.IPAM.defaultDnsSearchSuffixes

Method 3 – InfoBlox allocates from specified IP range

As you might guess, this method finds an available IP address within the specified range.  This is similar to Method 2 above, but you can skip the fancy searching if you already roughly know the addressing you want for the machine.  

The unique parameters used for this method are below:

• Infoblox.IPAM.startAddress
• Infoblox.IPAM.endAddress

I would warn, however, that this method is taking the least advantage of either vRA or Infoblox functionality.  This method assumes that the blueprint owner or the service requester somehow know more about the available IP environment that does either vRealize Automation or Infoblox.  If this is actually the case, then you still have some major network management challenges to solve!  I recommend you find a way to utilize one of the other approaches, and adapt your provisioning processes to get it right the first time…

This concludes this particular series of articles, all to do with vRealize Automation and Infoblox integration and use cases.  Hopefully you have found some value from it.  Please leave any comments or feedback!

Integrating Infoblox IPAM with vRealize Automation - Part 2

Following on from Part 1 of this blog article, I wanted to explore how to implement the InfoBlox integration into vRealize Automation blueprints.

First approach

When first learning about how to utilize the IPAM integration, I believe I actually went down the complicated route first (Method 2, in Part 3!).  I assumed I would NOT use vRA to manage and assign IP addressing at all, and would delegate this entirely to InfoBlox.  In order to do this, I had to disable the vRA Network Profile in the Reservation, whose job it would normally be to create the IP information.   This had two implications:

1. In my environment, not all VM requests were going to be IPAM integrated, so I had to create a NEW Reservation in vRA, overlapping with my existing ones, with the Network Profile disabled.  I then had to make duplicate blueprints to be associated with the new reservation.  Of course, I could have made the Reservation Policy be dynamically selected during request, but that is just another complication.
2. Now that vRA was not supplying the networking parameters to go with the IP address (subnet mask, DNS servers, DNS suffix, etc), I had to supply this is additional vRA Build Profile properties.

So, maybe don’t do it that way…!  There are two other approaches, and I’ll outline each of them in Part 3 of this series of articles.  I’ll also explain below some more details about how the provisioning options work.

But for now, I’ll explain some of the common elements across the integration methods.

Using the Build Profiles

After creating the initial Build Profile (as per Part 1), I went back into vRA and modified the Build Profile to pre-populate the static attributes that I knew I would use.

Common properties

There is one set of common properties that are used no matter which IPAM methodology you use.  There are a number of “create-something” attributes, and you need to choose exactly what type of Infoblox record you wish to create.

DNS-integrated Host record

If you specify this option, as cannot specify any of the other below types.  It is both an InfoBlox record type and a DNS record type.

• Infoblox.IPAM.createHostRecord

InfoBlox address record type

You can choose between either of the below options, depending on how you plan to use InfoBlox records.  I believe Fixed Address probably fits the use case most people think of for the automation use-case.

• Infoblox.IPAM.createFixedAddress
• Infoblox.IPAM.createReservation

DNS address record type

If you are not creating an InfoBlox/DNS host record (above), then you can either specify to create a DNS A record alone, or both the A and PTR records for the entry.  Obviously “one or both” means you don’t choose both these options!

• Infoblox.IPAM.createAddressRecord
• Infoblox.IPAM.createAddressAndPtrRecords

Additional common properties

There are a list of additional properties created in the Build Profile, most of which I have not used.  One property I did statically populate was “Infoblox.IPAM.comment” with a string such as “Record created by vRealize Automation”, so that when managing my addresses directly in InfoBlox I could quickly determine which entries are under automated management.

A quick word on one other property – “Infoblox.IPAM.vmName”.  In my view, this property is a bit redundant when using vRA, as I was already using vRA Dynamic Hostname workflows to determine a special hostname, and didn’t want to populate this separately in a new field.  In my case, I went and edited a few of the InfoBlox workflows to just pickup the vRA name.

My snippet of additional code is below, which was inserted into the “Retrieve Properties” workflow scripting elements.

vmname=vCACVmProperties.get("Infoblox.IPAM.vmName");
if(vmname=="")
{
vmname=vCACVm.virtualMachineName;
}

Property list

• Infoblox.IPAM.vmName
• Infoblox.IPAM.dnsView
• Infoblox.IPAM.networkView
• Infoblox.IPAM.comment
• Infoblox.IPAM.enableDHCP (see comments below)
• Infoblox.IPAM.aliases
• Infoblox.IPAM.defaultPortGroup

Have a look through the InfoBlox to explore some other use-cases you can try out with the DNS and Network views – as these will apply well to multi-tenanted usage, overlapping network ranges, etc.  This is something considerably beefed up in the later vNIOS 7.x version of InfoBlox which I haven’t covered in these articles.

One last word of warning – the “Infoblox.enableDHCP” property is defined automatically when you generate the Build Profiles with the provided workflow.  However, this property is never referenced in the later call-outs, and so might give you the wrong impression for this parameter that there is some DHCP-specific IP assignment.  There is not – static IP allocation and assignment is the only method implemented, at least in the version of the plug-in I have been reviewing.

That's it for this article on the common elements of integration.  Please go ahead and read Part 3 to understand the juicy details of specific integration methods, and how you might actually go about using this for your own environment!

Please let me know any comments or feedback!