Is clustering a good solution for this?

We recently built a Windows 2003 server with an iSCSI storage array for
keeping backups on. We also just moved from a workgroup to a domain on
our network, and plan to keep all the user profiles on this new server.
We also built an identical server at another site, which we are using as
a backup.

We've looked at different ways of keeping both servers synchronized.
We're currently trying out a program called SyncBack, and we have also
looked at much more expensive ways of doing it.

We've also been looking into clustering, and wonder if that might be the
best solution, since it's already built into Windows and would
apparently provide hot failover for the user profiles.

What are the pros and cons of using clustering for this? Any
recommendations or comments would be very helpful.

Thanks,
Trevor

Clustering does not provide any sort of data replication between nodes. You
would need some form of shared storage that is common to both nodes. Since
you've mentioned that the other node would be at a separate site, you're
looking at a "multi-site" cluster...based on your quick description, I think
this is not an option for your budget.

You might consider looking into Double-take from NSI software or some other
IP replication software to accomplish this.

Regards,
John

Visit my blog: http://msmvps.com/blogs/jtoner

"Trevor Holyoak" <> wrote in message
news:gkqham$qni$...
> We recently built a Windows 2003 server with an iSCSI storage array for
> keeping backups on. We also just moved from a workgroup to a domain on
> our network, and plan to keep all the user profiles on this new server.
> We also built an identical server at another site, which we are using as
> a backup.
>
> We've looked at different ways of keeping both servers synchronized.
> We're currently trying out a program called SyncBack, and we have also
> looked at much more expensive ways of doing it.
>
> We've also been looking into clustering, and wonder if that might be the
> best solution, since it's already built into Windows and would
> apparently provide hot failover for the user profiles.
>
> What are the pros and cons of using clustering for this? Any
> recommendations or comments would be very helpful.
>
> Thanks,
> Trevor

You could also look at DFS/DFSR to see if those technologies address your
specific needs. This might be your best solution, depending on your budget,
the amount and type of data you want to replicate, etc.

--
Ryan Sokolowski
MVP - Clustering
MCT, MCITP x3, MCTS x8, MCSE x2, CCNA, CCDA, BCFP


"John Toner [MVP]" <> wrote in message
news:...
> Clustering does not provide any sort of data replication between nodes.
> You
> would need some form of shared storage that is common to both nodes. Since
> you've mentioned that the other node would be at a separate site, you're
> looking at a "multi-site" cluster...based on your quick description, I
> think
> this is not an option for your budget.
>
> You might consider looking into Double-take from NSI software or some
> other
> IP replication software to accomplish this.
>
> Regards,
> John
>
> Visit my blog: http://msmvps.com/blogs/jtoner
>
> "Trevor Holyoak" <> wrote in message
> news:gkqham$qni$...
>> We recently built a Windows 2003 server with an iSCSI storage array for
>> keeping backups on. We also just moved from a workgroup to a domain on
>> our network, and plan to keep all the user profiles on this new server.
>> We also built an identical server at another site, which we are using as
>> a backup.
>>
>> We've looked at different ways of keeping both servers synchronized.
>> We're currently trying out a program called SyncBack, and we have also
>> looked at much more expensive ways of doing it.
>>
>> We've also been looking into clustering, and wonder if that might be the
>> best solution, since it's already built into Windows and would
>> apparently provide hot failover for the user profiles.
>>
>> What are the pros and cons of using clustering for this? Any
>> recommendations or comments would be very helpful.
>>
>> Thanks,
>> Trevor
>
>

Thanks. From the research we've done, we thought that a Majority Node
Set Quorum would do data replication between nodes, but now I see that
it would require at least 3 nodes, so it looks like your assessment that
a replication solution would be better is correct.

Thanks,
Trevor

John Toner [MVP] wrote:
> Clustering does not provide any sort of data replication between nodes. You
> would need some form of shared storage that is common to both nodes. Since
> you've mentioned that the other node would be at a separate site, you're
> looking at a "multi-site" cluster...based on your quick description, I think
> this is not an option for your budget.
>
> You might consider looking into Double-take from NSI software or some other
> IP replication software to accomplish this.
>
> Regards,
> John
>
> Visit my blog: http://msmvps.com/blogs/jtoner
>
> "Trevor Holyoak" <> wrote in message
> news:gkqham$qni$...
>> We recently built a Windows 2003 server with an iSCSI storage array for
>> keeping backups on. We also just moved from a workgroup to a domain on
>> our network, and plan to keep all the user profiles on this new server.
>> We also built an identical server at another site, which we are using as
>> a backup.
>>
>> We've looked at different ways of keeping both servers synchronized.
>> We're currently trying out a program called SyncBack, and we have also
>> looked at much more expensive ways of doing it.
>>
>> We've also been looking into clustering, and wonder if that might be the
>> best solution, since it's already built into Windows and would
>> apparently provide hot failover for the user profiles.
>>
>> What are the pros and cons of using clustering for this? Any
>> recommendations or comments would be very helpful.
>>
>> Thanks,
>> Trevor
>
>

Thanks. I will look into DFS Replication. I just read a description of
it and it does indeed sound like it might be what we're looking for.

Thanks,
Trevor

Ryan Sokolowski [MVP] wrote:
> You could also look at DFS/DFSR to see if those technologies address
> your specific needs. This might be your best solution, depending on your
> budget, the amount and type of data you want to replicate, etc.
>

> Thanks. From the research we've done, we thought that a Majority Node
> Set Quorum would do data replication between nodes,

Yes, but only for the Quorum data, not User or Application data

Rgds,
edwin.



> but now I see that
> it would require at least 3 nodes, so it looks like your assessment that
> a replication solution would be better is correct.
>
> Thanks,
> Trevor
>
> John Toner [MVP] wrote:
> > Clustering does not provide any sort of data replication between nodes.
You
> > would need some form of shared storage that is common to both nodes.
Since
> > you've mentioned that the other node would be at a separate site, you're
> > looking at a "multi-site" cluster...based on your quick description, I
think
> > this is not an option for your budget.
> >
> > You might consider looking into Double-take from NSI software or some
other
> > IP replication software to accomplish this.
> >
> > Regards,
> > John
> >
> > Visit my blog: http://msmvps.com/blogs/jtoner
> >
> > "Trevor Holyoak" <> wrote in message
> > news:gkqham$qni$...
> >> We recently built a Windows 2003 server with an iSCSI storage array for
> >> keeping backups on. We also just moved from a workgroup to a domain on
> >> our network, and plan to keep all the user profiles on this new server.
> >> We also built an identical server at another site, which we are using
as
> >> a backup.
> >>
> >> We've looked at different ways of keeping both servers synchronized.
> >> We're currently trying out a program called SyncBack, and we have also
> >> looked at much more expensive ways of doing it.
> >>
> >> We've also been looking into clustering, and wonder if that might be
the
> >> best solution, since it's already built into Windows and would
> >> apparently provide hot failover for the user profiles.
> >>
> >> What are the pros and cons of using clustering for this? Any
> >> recommendations or comments would be very helpful.
> >>
> >> Thanks,
> >> Trevor
> >
> >