A popular question that pops up is about best practices to deploy and integrate Infoblox in the public cloud, whether it be Amazon Web Services (AWS) or Microsoft Azure.
Before embarking on the cloud deployment journey, there are a few questions you should ask yourself:
- Is this an entirely new deployment, or will this be part of an existing Infoblox Grid™?
- Will there be any connectivity requirements/limitations between VPC’s and on-premises?
- Do you require API access/object delegation through appliances other than the Grid Master?
- What levels of fault tolerance are you striving for?
- Where will appliances be distributed?
- What is the expected load during peak times?
New Versus Existing Deployments
When deploying Infoblox in the cloud, networking requirements will vary depending on the extent of integration with an on-premises Infoblox solution. When launching an Infoblox appliance in the cloud and which will be integrated with an existing on-premises Infoblox Grid, you will need to verify that connectivity is open between the new appliance’s location and your existing Grid Master (along with any Grid Master Candidates).
For a new deployment, you will need to decide where you want your Grid Master to be located. In larger deployments, it should be isolated to some degree to restrict access to only trusted connections and any Grid members. Refer to https://www.infoblox.com/products/ddi-public-hybrid-cloud/ for more information regarding Infoblox appliances for the cloud.
Infoblox NIOS™ software uses UDP ports 2114 and 1194 to build the VPN tunnel used for Grid communications. Firewall/security group rules should also be updated to allow any other ports that may be required, such as TCP and UDP 53 (for DNS). A common deployment practice is to employ a ‘shared services’ VPC / vNet, where you deploy your Infoblox appliances in this VPC / vNet, along with any other servers, and then establish connectivity to this shared servers VPC / vNet and other VPC’s / vNet’s using VPC / vNet peering.
Details regarding port usage with Infoblox can be found in the Infoblox Administrators Guide, as well as the Infoblox community: https://community.infoblox.com/t5/DNS-DHCP-IPAM/Ports-need-to-be-opened-in-firewall-between-grid-mas…
API Access / Automation
In environments that perform a large number of operations via the API or orchestration tools, a common best practice is to deploy a CP (Cloud Platform) appliance. With a CP appliance, objects can be delegated to them and API calls can be sent to the CP appliance instead of the Grid Master, giving you better control over security. Being able to deploy multiple CP appliances also enables you to distribute API access multiple locations and closer to your administrators.
Information regarding deployment of Infoblox CP appliances can be found at https://www.infoblox.com/wp-content/uploads/infoblox-deployment-guide-infoblox-cloud-platform-and-cl….
Fault Tolerance and Redundancy
An important aspect to consider when deploying Infoblox in the cloud is to figure out how to maintain survivability in the event of a localized failure. One common recommendation is to deploy across multiple platforms and regions with Infoblox appliances placed as close to critical access points as possible. Diversifying in such a way gives you an extra layer of redundancy in the event of a failure of any one platform. While rare, this does happen.
For AWS, deploy your Infoblox appliances in as many different Availability Zones and/or regions as possible. For Azure, associate any Infoblox appliances deployed within the same Resource Group in a single Availability Set. Doing so will minimize your exposure should any localized failures occur, and reduces the chance that multiple appliances can go offline at the same time for any maintenance operations that may take place.
Refer to https://www.infoblox.com/solutions/cloud-computing/ for more information regarding Infoblox solutions for the cloud.
Applications and Use Cases
It is important to look at the types of applications and use cases the Infoblox appliances will be expected to support in the cloud. You will want local survivability with an appliance deployed within the same region (or even the same VPC/vNet) for any mission-critical applications. This will enable continued operations in the event of failures in other areas.
Groups that heavily utilize scripts and manage services with Infoblox using the API or need to be able to manage their own DDI will want a CP appliance deployed locally. Environments that require load balancing capabilities will benefit from an Infoblox appliance with DNS Traffic Control enabled. And clients that access the Internet will experience a safer working environment with DNS Firewall protections and administrators will appreciate the ability to receive reports and alerts about any suspicious activities that are detected.
Information regarding the Infoblox products referenced here can be found at https://www.infoblox.com/products/.
Peak Activity and Expected Load
Lastly, be sure to look at the types of load that your Infoblox appliances will be expected to handle. Busier environments might require additional appliances to support expected activities. Don’t forget to keep your busiest times in mind, such as during the critical holidays for many businesses or where you might anticipate an influx of new visitors for something such as a new product launch, to enrollment periods for schools and health care. Also keep any potential future expansions in mind as well. With this information, you will be able to identify the number and types of appliances that you will require.
For details regarding the different Infoblox appliances that are available, refer to https://www.infoblox.com/products/infoblox-appliances/.
Built for Your Success to Become a Cloud-Centric Company
Answering each of these questions is a critical first step to completing a successful deployment, serving as an outline to refer to and will be the foundation for constructing a detailed design. As questions invariably arise during the design drafting process, the answers collected here will function as a helpful reference for what to use and where, and help prepare you for any gotchas that you may need to watch out for. And most importantly, this will also help avoid a common cause for unexpected issues that pop up during the implementation phase of your deployment: forgetting something.