11-18-2015 08:18 AM
Seeking guidance on the best way to use Infoblox within the context of DR testing using VMware SRM. Currently, all Infoblox instances within the envirorment are physical devices. We need to test DR recovery plans by recovering VMs at the DR site within isolated networks, where an AD VM will be located in order to provide authentication services within the isolation. What is the best way to proceed in order to have an infoblox presence within this isolated network? With AD, we are taking a clone of an AD VM prior to each test, however with physical Infoblox, this is not an option......
11-19-2015 10:53 AM
Fortunately Infoblox has a built-in real-time DR mechanism with Grid replication and the Master/Master Candidate configuration that allows replication of all data to an Infoblox member appliance for DR purposes. This makes DR testing and DR scenarios easier to account for!
For your scenario it appears that you will be leveraging virtual machines which you can also leverage as Infoblox provides virtual appliance equivalents for VMware and other hypervisors.
Before I go further into what I would suggest as a base guideline, I do recommend that you touch base with your Infoblox account team's systems engineer as they could likely recommend the best approach with additional knowledge of your infrastructure and architecture.
That being said, what I have found that works well for a DR scenario is to leverage a virtual appliance that is equivalent in spec to your existing Grid Master. You then have the following two choices:
1. Join the VM virtual appliance to your existing production Grid as a Master Candidate. This will automatically sync all of the data to the virtual member. You can then move this VM to your isolated network and promote it to master where you can then make any necessary data and/or services changes. For example, you could enable DNS/DHCP on the DR member for testing if required. Simply reset the virtual appliance's database or delete the VM completely when the testing is complete.
2. Deply the virtual appliance into the DR environment and then restore a Grid backup from the production Grid into the VM in your DR environment. This will provide you with essentially the same scenario as above along with data as recent as the last backup.
How do you obtain a VM image/license? You can procure one through your account team for longer term use or for temporary testing with a limited lifetime you can actually download a VM image from the Support site and spin it up with temporary licensing that will run for up to 60 days.
12-22-2015 12:05 AM
One of solutions could be to use the Infoblox NIOS Virtual appliance and use the Grid architecture approach and with this the data will be replicated to the NIOS appliance on the DR site.
11-03-2017 12:53 PM
It depends on how connectivity is gong to work between your production data center and your DR site, along with exactly what you are trying to test. Assuming that there is connectivity between the two and you want to maintain survivability of your Grid, what is generally done is that you will deploy an Infoblox appliance (we have virtual appliances available for multiple cloud platforms, including VMware) in the DR site and enable it as a Grid Master Candidate (GMC).
The entire Grid database is replicated to Grid members enabled as a GMC so in a DR scenario, you would simply SSH to the GMC and run the "set promote_master" command. This will promote the GMC to take over as the Grid Master (GM), and it will send out notifications to all Grid members informing them of that. The GUI would then be accessed through the newly promoted GM and you can manage your Grid accordingly. This is what the previous replies in this thread are pointing to.
Part of your DR planning would most likely also include service survivability, which I am assuming is probably your more pressing concern. As you mention Master Master between two production data centers, I would guess the DNS service. Infoblox allows you to assign multiple Grid members as a Grid primary as part of our multi-master functionality so for your DR plan for DNS, you would assign your Infoblox server deployed in your DR site as a Grid Primary for all appropriate zones. This is a fairly simple setup to put in place when assigning Name Server Groups to your zones and then configuring your name server assignments in the Name Server Groups instead of individually at each zone.
If you are not already using Name Server Groups, you can update your existing zones fairly easily by exporting all existing zones in Infoblox CSV Import format, updating the CSV file to use the Name Server Group for your zones and then import the updated file back in (being sure to use the Override option). I would remove all unnecessary columns from the CSV so that you can make sure that no unnecessary changes are made, and to also speed up the process quite a bit as the CSV import process is fairly slow by itself and cutting down data that doesn't need to be parsed through will help quite a bit.
Here is an example showing how the format of the CSV should be structured when running the import to update your zones:
If you are looking for survivability for DHCP, that can be a bit more challenging. Ideally, you would setup DHCP Failover between servers where if one goes down, the other would be located in a different location and in theory, would not be impacted by whatever outaged caused the other to become unavailable. DHCP Failover only works between two servers so if you are using this already between your two production data centers and want your DR server to take over, you would need to update all zones to use the DR server instead.
The reasignment can be done fairly easily via CSV export/import or the API so you could have for instance two CSV files, one for regular production and one for DR and then after promoting your DR server to the GM role, run the CSV Import process (using the Override option) to update your networks and ranges to switch them to your DR server and then when you want to revert back, run the CSV Import again to override the assignment and switch everything back to your production servers. You would just need to make sure to restart services after making any of these changes so that they will take effect.
Here is an example of the syntax that you would use to switch to a Failover Association:
And here is an example to assign ranges to a specific Grid member:
Note: You may want to assign your DR server at the network level for all of your networks so that you don't have to worry about that during your DR testing/execution, otherwise you would need to make sure to include that as part of your DR cutover process as well:
Hopefully this gives you what you are looking for here.
11-06-2017 02:00 AM
The simplest solution is to set up a grid master candidate as others have said.
However, if for some reason this is not possible (maybe the D/R network is isolated) then you could simply take a backup from the live grid master and load it onto the D/R grid master. If the D/R network uses a different addressing scheme (i.e. if it does not mirror production) then you will need to make some changes to the grid, such as changing the IP address of the primary DNS master and DHCP servers etc. You could do this manually or write a script to automate it.
PCN (UK) Ltd
All opinions expressed are my own and not representative of PCN Inc./PCN (UK) Ltd. E&OE