A little prep goes a long way: thoughts on basic services for a home lab

badcable

Image credit: http://imgur.com/gallery/HYO11dd/new

What’s the saying? “If you find yourself in a hole, the first step is to stop digging.” Sage advice, assuming you follow it, and I’m guilty of not following my own advice.

As I continue to build my lab up, I am finding it increasingly difficult to scale. I am already up to nine VMs and it’s becoming a challenge to manage all of the different DNS names and IPs. Part of the problem is that my router, an ASUS RT-AC68U, is acting as both a DNS and a DHCP server for everything, lab and home network included. While it has worked very well for me as a standard home router and has provided excellent 802.11ac coverage, it is not really well equipped to do things like record editing and manual forward/reverse lookup changes.

In the back of my mind, I knew that this problem was a ticking time bomb. Sooner or later, the inability for me to edit DNS settings before creating it was going to rear its ugly head, and sure enough, today was the day it decided to do so.

I managed to successfully install EMC Avamar Virtual Edition on my lab (hooray! also, I’ll post about this soon!) and I am preparing to do image-level, proxy-driven backups of a couple of VMs. The problem that I am encountering, however, is that Avamar isn’t recognizing the DNS names of the proxy that I am attempting to create as there are no A records to reference, and it won’t let me fix the problem after installation as it will just uninstall the proxy at the first sign of trouble. Clearly, this just won’t do.

The short-term fix, which I will be working on deploying soon, is to deploy a system that acts as a DNS server for my lab. Thankfully I have a ton of different options to do this.

  1. Linux is an obvious choice. DNS is not exactly a high-stress service that requires a lot of power, so it may make sense to deploy a standard CentOS 7 server from a template, load up the dns server, and point all new lab clients to that server for future use. aboutdebian.com has an excellent writeup on the matter.
  2. There’s another, perhaps more interesting option: pfSense. pfSense is a FreeBSD-based open source firewall/router that a lot of home labbers like to throw around as a good services OS. Again, this would be a low-impact VM, and I don’t mind using something outside of Linux if it makes sense and is purpose-built.

I’ll likely deploy this either tomorrow or over the weekend, but for now, here are my thoughts for future lab builds to make life a little easier:

  1. Start with a plan. It doesn’t have to be a great plan and it can just be a sheet of notebook paper that you quickly sketched out, but don’t just deploy ESXi, throw VMs on top of it, and hope for the best. Have some sort of hierarchy. Will you be using a separate subnet outside of your home network? Will you be deploying VLANs? What will you do for separate physical devices, such as routers, hosts, etc.?
  2. Use Excel or Google Docs to keep track of your VM name, DNS name, IP settings, and so forth. Again, this doesn’t need to be fancy, but you’ll thank yourself down the line. It’ll make troubleshooting and merely expanding your lab so much easier in the future.
  3. If you have access to Visio, use that to diagram your lab as it grows. A visual representation of your lab will go hand in hand with your spreadsheet in both troubleshooting and expanding.
  4. If your lab is going to grow beyond a few VMs (and environments like mine are pretty much guaranteed to do so!), spend time deploying service VMs. DHCP and DNS should absolutely be part of this, and if you are planning on doing anything with Active Directory, plan on doing that as well.
    1. By extension, that means you should also plan on deploying app servers such as SQL as well, if you forsee the need for them!

 

For my next post, I’ll spend a little time on deploying pfSense and reviewing DNS, and then we’ll talk about Avamar Virtual Edition and why it’s absolutely awesome.

 

-ajs