Jump to content

Recommended Posts

Posted

Here is our theory...point out my obvious mistakes please...

 

1. Create two new servers and add to existing cluster for File Services and DHCP

2. Create a temp DC3 for luck

3. Remove clustering from DC1 (remove DC from cluster) and demote

4. Rebuild DC1 as new server and promote

5. DC1 FSMO

6. Demote DC2

7. Rebuild DC2 and promote

 

If the theory is right we will end up with 3 DC server, one of which will be temp DC3.

We will have two servers running as file servers/dhcp in cluster

 

All sound good in my head...probably not though :)

Posted (edited)
This is true, provided that the server is brought back online before the lease expires. If the leases expire before the server comes back presumably the machines will indeed throw their IPs away and seek a new one? Or will they realise they can't get a response and just hold on to the IP?

 

They hold onto it until next reboot usually.

 

I can't agree or disagree with this, I see no actual reason that clustering file services and the DHCP disk would break DC replication other than Microsoft says so?...

 

What effects can the clustering possible have on the DC functions of the servers?! For all intensive purposes they are separate entities, their only link is in the fact that if C1 goes down while holding DHCP and, let's say the file service "Staff Share" then C2 will detect the failure and load it's instance of Staff Share and the DHCP disk, in the process keeping the DHCP leases and status and allowing reconnects back to Staff Share, including the ability (it would seem anyway) to resume existing file operations such as copies/deletes etc...

 

I don't see how that simple migration can affect the DC functions at all, I understand the fact that if the server is overwhelmed it can fail to respond to the quorum sensing which can then trigger a failover but our servers are not that heavily loaded, if that became an issue in the future then naturally we can look at it.

 

Domain controllers 'chat' to each other replicating changes. This goes on all the time and there are mechanisms in place to ensure that old changes don't override new ones. If one of your DCs fails, the existing one(s) will continue operating and the changes still occur. Once the failed machine re-appears it catches up. This is all done so that you have the high availability of the AD services.

 

By introducing the clustering, you introduce the ability for the changes not to replicate properly because of the way that clustering handles networking... adding and removing nodes as things fail and re-appear. This then confuses the updates and your DCs get out of sync. This is probably what has happened to you. Some roles (e.g. Hyper-V) are cluster aware and, in fact, depend upon the clustering service to provide high availability. Active Directory is not one of these roles.

 

As I said before, this isn't any form of "I am better than you" it's just that I don't understand why people follow the status quo as I just don't understand the potential pitfalls. I am more than happy to redesign the backend if I can understand why I am doing it.

 

The set up is not the status quo... the reason that everyone does it this way is because this is the way to set things up. Would you buy a piece of flat pack furniture and then assemble it the opposite way to how the manufacturer tells you to?

 

Anyway, if you are in doubt of whether my recommendation works, our 40 DCs globally in 17 sites seem pretty happy.

 

Here is our theory...point out my obvious mistakes please...

 

1. Create two new servers and add to existing cluster for File Services and DHCP

2. Create a temp DC3 for luck

3. Remove clustering from DC1 (remove DC from cluster) and demote

4. Rebuild DC1 as new server and promote

5. DC1 FSMO

6. Demote DC2

7. Rebuild DC2 and promote

 

If the theory is right we will end up with 3 DC server, one of which will be temp DC3.

We will have two servers running as file servers/dhcp in cluster

 

All sound good in my head...probably not though :)

 

Just build a VM for file services and connect to the LUN on your SAN to pick up the files. Then follow what I said above - you need to follow what I said to make sure AD is fixed... the files will still be sat there on your SAN but you need AD replication to work.

Edited by Ric_
  • Thanks 2
Posted (edited)
They hold onto it until next reboot usually.

 

 

 

Domain controllers 'chat' to each other replicating changes. This goes on all the time and there are mechanisms in place to ensure that old changes don't override new ones. If one of your DCs fails, the existing one(s) will continue operating and the changes still occur. Once the failed machine re-appears it catches up. This is all done so that you have the high availability of the AD services.

By introducing the clustering, you introduce the ability for the changes not to replicate properly because of the way that clustering handles networking... adding and removing nodes as things fail and re-appear. This then confuses the updates and your DCs get out of sync. This is probably what has happened to you. Some roles (e.g. Hyper-V) are cluster aware and, in fact, depend upon the clustering service to provide high availability. Active Directory is not one of these roles.

 

 

 

The set up is not the status quo... the reason that everyone does it this way is because this is the way to set things up. Would you buy a piece of flat pack furniture and then assemble it the opposite way to how the manufacturer tells you to?

 

Anyway, if you are in doubt of whether my recommendation works, our 40 DCs globally in 17 sites seem pretty happy.

 

That's what I needed to know! Now it (almost) makes sense, it's still bad design from microsoft but now I understand why clustering isn't a great option so thanks for that. The thing is, Microsoft don't always make the best software so it makes sense they don't always provide the best instructions either...

 

I have no doubt whatsoever of your indelible competence but one solution does not always fit all and so far in my experience a tailored solution is ALWAYS better than a generic solution that follows one set of instructions.

Edited by shadowx
Posted

Just build a VM for file services and connect to the LUN on your SAN to pick up the files. Then follow what I said above - you need to follow what I said to make sure AD is fixed... the files will still be sat there on your SAN but you need AD replication to work.

 

The SAN and files are currently set up for a clustered solution...would one virtual server be able to use them LUNs or would we need to re-create them...

 

If we create one virtual file services server we would not be able to cover software failure or is best to not worry about that for file services?

 

thanks

Posted
The SAN and files are currently set up for a clustered solution...would one virtual server be able to use them LUNs or would we need to re-create them...

 

If we create one virtual file services server we would not be able to cover software failure or is best to not worry about that for file services?

 

Assuming that this is a 'normal' set up, the LUN used by the cluster is just the same as any other LUN, except 2 hosts can connect. The fileserver role is cluster aware so that works out which node should be writing and when.

 

If you virtualise your file server, it will move between your hosts in case of hardware/software failure there. In the less likely event of software failure on the fileserver, just recover it from a snapshot or VM backup and re-join to the domain (the server will hold no data as it will use the software initiator to connect back to the data on a SAN).

 

The main point of failure is your disk array... using the VM method, you could lose a host and a storage controller in each SAN and it will all still work. If you lose your disks in either SAN, you are screwed.

  • Thanks 1
Posted
Assuming that this is a 'normal' set up, the LUN used by the cluster is just the same as any other LUN, except 2 hosts can connect. The fileserver role is cluster aware so that works out which node should be writing and when.

 

If you virtualise your file server, it will move between your hosts in case of hardware/software failure there. In the less likely event of software failure on the fileserver, just recover it from a snapshot or VM backup and re-join to the domain (the server will hold no data as it will use the software initiator to connect back to the data on a SAN).

 

The main point of failure is your disk array... using the VM method, you could lose a host and a storage controller in each SAN and it will all still work. If you lose your disks in either SAN, you are screwed.

 

Thank you...

 

Now can I ask, what would we gain from using VM rather than using hardware to cluster File Services?

 

If we use a VM for file services, as you suggest it can be recovered by a snapshot but during that time I would assume the file access will be unavailable to anyone...if we use hardware to cluster it then surely we have a little more redundancy for failure and keeping the data available to stop the moans, not that staff moan of course, just an example :)

 

Sorry to keep going over the same point, I just want to get this moving...

 

The aim is to end with DCs being on their own as recommended :)

Posted
Thank you...

 

Now can I ask, what would we gain from using VM rather than using hardware to cluster File Services?

 

If we use a VM for file services, as you suggest it can be recovered by a snapshot but during that time I would assume the file access will be unavailable to anyone...if we use hardware to cluster it then surely we have a little more redundancy for failure and keeping the data available to stop the moans, not that staff moan of course, just an example :)

 

Sorry to keep going over the same point, I just want to get this moving...

 

The aim is to end with DCs being on their own as recommended :)

 

By the sounds of it, you don't have enough hardware to have your 2 physical DCs and create separate clustered fileservers. This option gets you up and running quickly although probably sacrifices a little performance.

 

It is highly unlikely that the minimal Windows install for a VM will corrupt its OS in such a way that it stops functioning but if it does, a VM snapshot will take maybe 1 minute to restore and another minute to rejoin to the domain and reboot.

  • Thanks 1
Posted (edited)
By the sounds of it, you don't have enough hardware to have your 2 physical DCs and create separate clustered fileservers. This option gets you up and running quickly although probably sacrifices a little performance.

 

It is highly unlikely that the minimal Windows install for a VM will corrupt its OS in such a way that it stops functioning but if it does, a VM snapshot will take maybe 1 minute to restore and another minute to rejoin to the domain and reboot.

 

Just to clarify, the mighty @Ric_ has provided some sound advice there, but he does mean just one snapshot of the original server build. You may or may not know this, snapshots can be harmful to a virtual env. It can cause performance issues if you store multiple snapshots or store them over a long period of time.

 

Good luck guys! :)

Edited by Ric_
  • Thanks 1
Posted

Thank you both...you have had great input

 

money is always an issue with us but I do have some old HP Proliant DL380 G5 generation that I could make a temp server on until we get the funding or we have enough storage on our VM san to house it

 

We have gotta get a move on I guess...I really appreciate the thoughts/comments and advice from you all...just ignore shadowx, he is young ;) he is good really just not so keen on MS/Apple/Blackberry/Olympics or anything that is not Linux really :D

 

Its not a quick or impossible job but the jobs from it could be interesting, one I can think of is having to alter all our backups that we have housed externally anyway

 

I am sure we will post updates/questions for you to follow up on...I look forward to then

 

Thanks once more

Posted

In his defense, I am a Linux fan to :)

 

I was hoping I would get some rep for apologizing for him :p

 

Right I am gonna kick him into getting some of the old hardware out...we will let you know how its all going I'm sure :)

Posted
Just use the G5s as your DCs (or at least one of them... they don't have to match).

 

Yeah, we have plenty of G5s in service here...

 

They are a few years old but I think that would be the quickest/best option right now and I will see in September if I can get funding for new kit

Posted

I might have to Bash a few heads together to get some sense outta you lot!

 

And yet no-one got my "location" reference.... either it's not funny or you guys are slow ;)

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...