2

This question kind of got me thinking about fault tolerance in DHCP, so I did a little digging in my current environment and discovered that we only have 1 DHCP server per major site in our company with no redundancy. All of our DHCP servers are virtual with VMWare high availability and regular backups using Quantum VMPro, so in the event of almost any catastrophic crash of our DHCP servers we can still recover inside of an hour.

This would lead me to think that a redundant DHCP server for failover is, well, redundant. But most of my prior experience is in the small business sector where this kind of situation just never comes up. Big business is very different.

Most of our file servers are in the same configuration, except for the few remaining physical server clusters that haven't gotten caught in our virtualization efforts yet.

So in a virtual environment, what are the decision points for adding server redundancy? Examples: When would I add a virtual DHCP standby server? Or create a virtual failover cluster for file servers? I understand that this is probably difficult to answer without enumerating the specific needs of an organization, but I think it's possible to describe a few example situations that would help an SA to be prepared before the need arises.

I'm strictly concerned about fault tolerance and failover - load balancing in this context is totally unrelated.

  • 1
    If you have the resources, you should always have a standby. While all sorts of redundancy may keep that single VM up even with a hardware failure, what do you do when you need to reboot that VM? – yoonix Apr 18 '14 at 22:21
  • 1
    If it takes VMware HA an hour to failover to another host you've got bigger problems. If you're using VMware HA then for DHCP I don't personally see the need for anything else. As for other applications and services it depends on what type of recovery you need to plan for. Is failing over the service or application enough or do you need to prevent data loss as well? – joeqwerty Apr 18 '14 at 22:33
  • @yoonix I've only been at this company about 8 months, but so far if any server needs to go down we schedule a maintenance outage during off hours or send out an emergency maintenance notice. Generally the need to reboot a production server during business hours is VERY rare, I've only seen one of those emergency maintenance notices. "Always have a standby" means lots of additional OS licenses for (in the case of DHCP) servers that do nothing 99.999% of the time. So I'm not exactly keen to accept "Always" as an answer ;) – Thomas Apr 19 '14 at 3:07
  • @joeqwerty The 1 hour recovery is the maximum recovery window for a worst case scenario; I was fairly clear on that point. And I'm specifically asking for "what type of recovery" I should plan for in different situations, I was also clear on that point as well. So your comment just essentially asked my own question back at me. Answer: I am familiar with a couple different kinds of recovery scenarios, but not everything, and I don't know what I don't know, so why don't you tell me what type of recovery I need to plan for? – Thomas Apr 19 '14 at 3:14
  • @Thomas: Lots of OS licenses? I really suggest you look @ Datacenter licenses for your high-density-windows-vm-hosts. You get UNLIMITED guest OS'es there. – MichelZ Apr 19 '14 at 7:28
1

As always in life - and especially in IT, the answer is "it depends".

On that very specific use case you have, with a virtualized environment, VMware HA - it does not really need a standby then - , but still DHCP as a very "light" service, my suggestion is to just spin up DHCP on another VM (or even another existing VM), and have them in a DHCP Failover configuration if you have 2012+, or have them in a "Split Scope" configuration.

Refer to Understand and Deploy DHCP Failover on TechNet

For the other examples (e.g. FileServer Cluster etc), you need to evaluate some of the following:

  • How critical is the service
  • What does it cost the business if the service is down
  • What does it cost IT to keep the service redundant
  • How easy is it to deploy redundancy
  • What maintenance costs are associated with keeping it redundant (manpower)
  • Are your other redundancy measures (e.g. VMware HA) already "good enough"
  • I seem to be having trouble getting my question across clearly. I know the answers to your "evalutation" questions, but knowing those answers doesn't tell me if I should implement failover or not. Assuming that the "default" is not to implement failover, what would my answers have to be in order to change my mind and start building secondary servers? – Thomas Apr 20 '14 at 1:49
  • 1
    The answer is: As soon as it costs the business a shitload of money if the service is down... – MichelZ Apr 20 '14 at 6:43
0

The question you have to ask here is: What is the time limit for getting DHCP up and running again?

If it will take too long in the current setup, you should set up a failover cluster.

But: Do you really mistrust vmware ha?

What scenario do you want to cover?

  • What if the error involves something not fixable by HA? (e.g. VM corruption on the storage) – MichelZ Apr 19 '14 at 19:35
  • @MichelZ in that case DHCP would be your smallest sorrow, don't you think? – Nils Apr 19 '14 at 20:14
  • Not if only the DHCP machine was affected. You know... murphy's law :D – MichelZ Apr 19 '14 at 20:15
  • @Nils I think "what scenarios do I want to cover" is what I'm trying to ask. Under what scenarios would I want to set up a second VM for failover? And it doesn't have to be DHCP or file servers, though those are probably the most likely choices after domain controllers (which should always have a failover). – Thomas Apr 20 '14 at 1:41
  • @Thomas You want to recover within one hour while on site. Give it a test then: Can you recover your server within an hour - if no: going for a hot standby is your way. – Nils Apr 21 '14 at 10:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.