Best practice for SQL cluster and domains

john

Splendid
Aug 25, 2003
3,819
0
22,780
Archived from groups: microsoft.public.sqlserver.clustering,microsoft.public.win2000.active_directory,microsoft.public.win2000.advanced_server,microsoft.public.windows.server.clustering (More info?)

Hi All,

We have a critical 24x7 SQL cluster (W2K), which is a member of an NT 4
domain. As hardware is getting old, and NT4 domain is going to disappear in
the near future, the cluster has to be re-newed. There is also a trusted
Active Directory domain, which holds about all user accounts and groups.
These accounts and groups have been assigned appropriate rights to SQL and
application generated reports.

What makes this a bit more difficult, is that the company is also going to
split, as is network and AD. The split will take place within few months,
but the new AD (where the users finally will be located) is expected to be
in place and fully functional within one year. However, the new cluster
should be up and running within two months. The cluster will be built on
Windows server 2003 Enterprise.

What I should do, is to provide best scenario for implementing new cluster,
so that it minimizes work when AD domains in question change.

As far as I am concerned, if you change a cluster domain membership, you
need to rebuild the whole cluster. This is not what we want to do. We are
prepared to re-assign all appropriate user right and roles as users' domain
changes.

I see following scenarios:
1. join new cluster to present AD domain
2. install new cluster nodes as domain controllers for new "domainlet" or
domain and create trust relationships as needed
3. install separate domain controllers, and join cluster to this domain,
create trust relationships as needed
4. something else?

In scenario 1 I see most work; rebuilding the whole cluster within a year or
so. About scenarios 2 and 3 I'd like to have comments, especially about
using domainlets
(http://www.microsoft.com/windows2000/techinfo/administration/cluster/domain
lets.asp). Or, there might be a lot better option, which I have not come to
think about.

Please share your opinions and comments,

John
 
G

Guest

Guest
Archived from groups: microsoft.public.sqlserver.clustering,microsoft.public.win2000.active_directory,microsoft.public.win2000.advanced_server,microsoft.public.windows.server.clustering (More info?)

Great questions.

I like option 1, have you read http://support.microsoft.com/?id=319016, no
need to rebuild the cluster and start all over. Pretty easy actually.
Have you read http://support.microsoft.com/?id=298570, so option 2 is not
looking good.
Option 3 will work, but I hate extra trusts, if I can avoid them.

Go with number 1, that is what I would do :)

Cheers,

Rod

MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://msmvps.com/clustering - Blog

"John" <someone@microsoft.com> wrote in message
news:41f50ef2@usenet01.boi.hp.com...
> Hi All,
>
> We have a critical 24x7 SQL cluster (W2K), which is a member of an NT 4
> domain. As hardware is getting old, and NT4 domain is going to disappear
> in
> the near future, the cluster has to be re-newed. There is also a trusted
> Active Directory domain, which holds about all user accounts and groups.
> These accounts and groups have been assigned appropriate rights to SQL and
> application generated reports.
>
> What makes this a bit more difficult, is that the company is also going to
> split, as is network and AD. The split will take place within few months,
> but the new AD (where the users finally will be located) is expected to be
> in place and fully functional within one year. However, the new cluster
> should be up and running within two months. The cluster will be built on
> Windows server 2003 Enterprise.
>
> What I should do, is to provide best scenario for implementing new
> cluster,
> so that it minimizes work when AD domains in question change.
>
> As far as I am concerned, if you change a cluster domain membership, you
> need to rebuild the whole cluster. This is not what we want to do. We are
> prepared to re-assign all appropriate user right and roles as users'
> domain
> changes.
>
> I see following scenarios:
> 1. join new cluster to present AD domain
> 2. install new cluster nodes as domain controllers for new "domainlet" or
> domain and create trust relationships as needed
> 3. install separate domain controllers, and join cluster to this domain,
> create trust relationships as needed
> 4. something else?
>
> In scenario 1 I see most work; rebuilding the whole cluster within a year
> or
> so. About scenarios 2 and 3 I'd like to have comments, especially about
> using domainlets
> (http://www.microsoft.com/windows2000/techinfo/administration/cluster/domain
> lets.asp). Or, there might be a lot better option, which I have not come
> to
> think about.
>
> Please share your opinions and comments,
>
> John
>
>
 

john

Splendid
Aug 25, 2003
3,819
0
22,780
Archived from groups: microsoft.public.sqlserver.clustering,microsoft.public.win2000.active_directory,microsoft.public.win2000.advanced_server,microsoft.public.windows.server.clustering (More info?)

Rod,

thanks really, this was great information. I'll investigate the options
again in the light of your recent information, the scenario 1 looks now
actually quite good. If you have something to add, please do not hesitate to
share it :)

Cheers, John

"Rodney R. Fournier [MVP]" <rod@die.spam.die.nw-america.com> wrote in
message news:%23z6TlkjAFHA.3592@TK2MSFTNGP11.phx.gbl...
> Great questions.
>
> I like option 1, have you read http://support.microsoft.com/?id=319016, no
> need to rebuild the cluster and start all over. Pretty easy actually.
> Have you read http://support.microsoft.com/?id=298570, so option 2 is not
> looking good.
> Option 3 will work, but I hate extra trusts, if I can avoid them.
>
> Go with number 1, that is what I would do :)
>
> Cheers,
>
> Rod
>
> MVP - Windows Server - Clustering
> http://www.nw-america.com - Clustering
> http://msmvps.com/clustering - Blog
>
> "John" <someone@microsoft.com> wrote in message
> news:41f50ef2@usenet01.boi.hp.com...
> > Hi All,
> >
> > We have a critical 24x7 SQL cluster (W2K), which is a member of an NT 4
> > domain. As hardware is getting old, and NT4 domain is going to disappear
> > in
> > the near future, the cluster has to be re-newed. There is also a trusted
> > Active Directory domain, which holds about all user accounts and groups.
> > These accounts and groups have been assigned appropriate rights to SQL
and
> > application generated reports.
> >
> > What makes this a bit more difficult, is that the company is also going
to
> > split, as is network and AD. The split will take place within few
months,
> > but the new AD (where the users finally will be located) is expected to
be
> > in place and fully functional within one year. However, the new cluster
> > should be up and running within two months. The cluster will be built on
> > Windows server 2003 Enterprise.
> >
> > What I should do, is to provide best scenario for implementing new
> > cluster,
> > so that it minimizes work when AD domains in question change.
> >
> > As far as I am concerned, if you change a cluster domain membership, you
> > need to rebuild the whole cluster. This is not what we want to do. We
are
> > prepared to re-assign all appropriate user right and roles as users'
> > domain
> > changes.
> >
> > I see following scenarios:
> > 1. join new cluster to present AD domain
> > 2. install new cluster nodes as domain controllers for new "domainlet"
or
> > domain and create trust relationships as needed
> > 3. install separate domain controllers, and join cluster to this domain,
> > create trust relationships as needed
> > 4. something else?
> >
> > In scenario 1 I see most work; rebuilding the whole cluster within a
year
> > or
> > so. About scenarios 2 and 3 I'd like to have comments, especially about
> > using domainlets
> >
(http://www.microsoft.com/windows2000/techinfo/administration/cluster/domain
> > lets.asp). Or, there might be a lot better option, which I have not come
> > to
> > think about.
> >
> > Please share your opinions and comments,
> >
> > John
> >
> >
>
>