Powering up a highly virtualized infrastructure can sometimes be an interesting experience. Interesting in that “crossing-the-fingers” sort of way. Maybe it’s an outdated run book, or an automated power-on of particular VMs that didn’t occur as planned. Sometimes it is nothing more than a lack of patience between each power-on/initialization step. Whatever the case, if it is a production environment, there is at least a modest amount of anxiety that goes along with this task. How often does this even happen? For those who have extended power outages, far too often.
One element that can affect power-up scenarios is availability of DNS. A funny thing happens though when everything is virtualized. Equipment that powers the infrastructure may need DNS, but DNS is inside of the infrastructure that needs to be powered up. A simple way around this circular referencing problem is to have another backup DNS server that supplements your normal DNS infrastructure. This backup DNS server acts as a slave to the server having authoritative control for that DNS zone, and would handle at minimum recursive DNS queries for critical infrastructure equipment, and vSphere hosts. While all production systems would use your normal primary and secondary DNS, this backup DNS server could be used as the secondary name server a few key components:
- vSphere hosts
- Server and enclosure Management for IPMI or similar side-band needs
- Monitoring nodes
- SAN components (optional)
- Switchgear (optional)
vSphere certainly isn’t as picky as it once was when it comes to DNS. Thank goodness. But guaranteeing immediate availability of name resolution will help your environment during these planned, or unplanned power-up scenarios. Those that do not have to deal with this often have at least one physical Domain Controller with integrated DNS in place. That option is fine for many organizations, and certainly accomplishes more than just availability of name resolution. AD design is a pretty big subject all by itself, and way beyond the scope of this post. But running a spare physical AD server isn’t my favorite option for a number of different reasons, especially for smaller organizations. Some folks way smarter than me might disagree with my position. Here are a few reasons why it isn’t my preferred option.
- One may be limited in Windows licensing
- There might be limited availability of physical enterprise grade servers.
- One may have no clue as to if, or how a physical AD server might fit into their DR strategy.
As time marches on, I also have a feeling that this approach will be falling out of favor anyway. During a breakout session for optimizing virtualized AD infrastructures at the 2012 VMWorld, it was interesting to hear that the VMware Mothership still has some physical AD servers running the PDCe role. However, they were actively in the process of eliminating this final, physical element, and building recommendations around doing so. And lets face it, a physical DC doesn’t align with the vision of elastic, virtualized datacenters anyway.
To make DNS immediately available during these power-up scenarios, the prevailing method in the “Keep it Simple Stupid” category has been running a separate physical DNS server. Either a Windows member server with a DNS role, or a Linux server with BIND. But it is a physical server, and us virtualization nuts hate that sort of thing. But wait! …There is one more option. Use your Synology NAS as an emergency backup DNS server. The intention of this is not to supplant your normal DNS infrastructure. it’s simply to help a few critical pieces of equipment start up.
The latest version of Synology’s DSM (4.1) comes with a beta version of a DNS package. It is pretty straight forward, but I will walk you through the steps of setting it up anyway.
1. Verify that your Windows DNS servers allow to transfer to the IP address of the NAS. Jump into the Windows Server DNS MMC snap in, highlight the zone you want to setup a zone transfer to, and click properties. Add or verify that the settings allow a zone transfer to the new slave server
2. In the Synology DSM, open the Package Center, and install DNS package.
3. Enable Synology DSM Firewall to allow for DNS traffic. In the Synology DSM, open the Control Panel > Firewall. Highlight the interface desired, and click Create. Choose “Select from a built in list of applications” and choose “DNS Server” Save the rule, and exit out of the Firewall application.
4. Open up “DNS Server” from the Synology launch menu.
5. Click on “Zones” and click Create > Slave Zone. Choose a “Forward Zone” type, and select the desired domain name, and Master DNS server
6. Verify the population of recourse records by selecting the new zone, clicking Edit > Resource Records.
7. If you want, or need to have this forward DNS requests, enable the forwarders checkbox. (In my Home Lab, I enable this. In my production environment, I do not)
8. Complete the configuration, and test with a client using this IP address only for DNS, simply to verify that it is operating correctly. Then, go back and tighten up some of the security mechanisms as you see fit. Once that is completed, jump back into your ESXi hosts (and any other equipment) and configure your secondary DNS to use this server.
In my case, I had my Synology NAS to try this out in my home lab, as well as newly deployed unit at work (serving the primary purpose of a Veeam backup target). In both cases, it has worked exactly as expected, and allowed me to junk an old server at work running BIND.
If the NAS lived on an isolated storage network that wasn’t routable, then this option wouldn’t work, but if you have one living on a routable network somewhere, then it’s a great option. The arrangement simplifies the number of components in the infrastructure while insuring service availability.
Even if you have multiple internal zones, you may want to have this slave server only handling your primary zone. No need to make it more complicated than it needs to be. You also may choose to set up the respective reverse lookup zone as a slave. Possible, but not necessary for this purpose.
There you have it. Nothing ground breaking, but a simple way to make a more resilient environment during power-up scenarios.
Helpful Links:
VMWorld 2012. Virtualizing Active Directory Best Practices (APP-BCA1373). (Accessible by VMWorld attendees only)
http://www.vmworld.com/community/sessions/2012/
vmpete.com 