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!
No comments:
Post a Comment