|
Home > Archive > MS SQL Server Clustering > April 2005 > SQL 2000 with NLB on Windows 2003 Boxes?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
SQL 2000 with NLB on Windows 2003 Boxes?
|
|
| Dennis Burgess 2005-04-05, 8:05 pm |
| Can you have SQL with a online disk array, two servers, each mounting the
same database and then NLBed between the two?
So here are the questions:
Can you have SQL 2000 open a database file accross a network share?
Can two SQL 2000 severs open the same database file accross a network share
at the same time?
Will NLB work with the SQL 2000 ports if neccessary? Will it all work?
Dennis
| |
| Salvador 2005-04-05, 8:05 pm |
| Hi,
I am not 100% sure but in order to NLB a SQL server you need two
installation and replicate across them, don't think that two SQL can share
the same DB file...
"Dennis Burgess" wrote:
> Can you have SQL with a online disk array, two servers, each mounting the
> same database and then NLBed between the two?
>
> So here are the questions:
>
> Can you have SQL 2000 open a database file accross a network share?
> Can two SQL 2000 severs open the same database file accross a network share
> at the same time?
> Will NLB work with the SQL 2000 ports if neccessary? Will it all work?
>
> Dennis
>
>
>
>
| |
| Rodney R. Fournier [MVP] 2005-04-05, 8:05 pm |
| SQL does not support NLB. You can only mount a DB on a single machine at a
time.
SQL can't use a network share for a DB, not that I know (a SQL MVP will
correct me if I am wrong).
SQL locks a db when in use, it can't share a db file locally or across the
network.
NLB does not work with SQL 2000.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://msmvps.com/clustering - Blog
"Dennis Burgess" <admin@surdyke.com> wrote in message
news:OqhM%23pfOFHA.3928@TK2MSFTNGP09.phx.gbl...
> Can you have SQL with a online disk array, two servers, each mounting the
> same database and then NLBed between the two?
>
> So here are the questions:
>
> Can you have SQL 2000 open a database file accross a network share?
> Can two SQL 2000 severs open the same database file accross a network
> share
> at the same time?
> Will NLB work with the SQL 2000 ports if neccessary? Will it all work?
>
> Dennis
>
>
>
| |
| Geoff N. Hiten 2005-04-05, 8:05 pm |
| Comments Inline
"Dennis Burgess" <admin@surdyke.com> wrote in message
news:OqhM%23pfOFHA.3928@TK2MSFTNGP09.phx.gbl...
> Can you have SQL with a online disk array, two servers, each mounting the
> same database and then NLBed between the two?
>
> So here are the questions:
>
> Can you have SQL 2000 open a database file accross a network share?
Yes, but it is a VERY BAD idea. There is a trace flag to enable network
share access to support a very specific set of NAS boxes that are hardware
qualified for SQL Server. You should not ever, ever, ever use this to
access a database file on a Windows host server.
> Can two SQL 2000 severs open the same database file accross a network
> share
> at the same time?
No. Absolutely not. There is no sharing of database files between
servers/instances regardless of the underlying technology.
> Will NLB work with the SQL 2000 ports if neccessary? Will it all work?
Yes. NLB will work with a group of SQL servers. No, your idea for a
low-rent SQL farm will not work. SQL is a scale up, not a scale out
technology. If you have outgrown your server, buy a bigger one or tune your
application to use less SQL resources.
Geoff N. Hiten
Microsoft SQL Server MVP
>
> Dennis
>
>
>
| |
| Dennis Burgess 2005-04-05, 8:05 pm |
| Its acutally for redunancy. SQL Enterprise is Extreamly expense compaired
to standrad and the custering is the feature that I guess we need.
One guy suggested replication of the database, can that be done? The NLB
system really will work for whatever, the key is keeping the single database
consistant with accurate data accross multple SQL boxes.
IS the only recourse Enterpise Edition?
Dennis
"Geoff N. Hiten" <sqlcraftsman@gmail.com> wrote in message
news:O%23QouBgOFHA.1564@TK2MSFTNGP14.phx.gbl...
> Comments Inline
>
> "Dennis Burgess" <admin@surdyke.com> wrote in message
> news:OqhM%23pfOFHA.3928@TK2MSFTNGP09.phx.gbl...
> Yes, but it is a VERY BAD idea. There is a trace flag to enable network
> share access to support a very specific set of NAS boxes that are hardware
> qualified for SQL Server. You should not ever, ever, ever use this to
> access a database file on a Windows host server.
>
> No. Absolutely not. There is no sharing of database files between
> servers/instances regardless of the underlying technology.
>
> Yes. NLB will work with a group of SQL servers. No, your idea for a
> low-rent SQL farm will not work. SQL is a scale up, not a scale out
> technology. If you have outgrown your server, buy a bigger one or tune
> your application to use less SQL resources.
>
> Geoff N. Hiten
> Microsoft SQL Server MVP
>
>
| |
| Geoff N. Hiten 2005-04-05, 8:05 pm |
| OK, you are looking at availability solutions. Here are some quick thoughts
Replication is probably not a good idea. DDL changes don't get pushed to
the subscriber, nor do stored procedure changes. Your best option may be to
build a standby server using a home-grown or third-party log shipping
solution. It won't be a fast, automatic failover like with clustering, but
it will be considerably better than building a system from scratch.
There are also some availability features announced for SQL Server 2005 that
may get you closer to what you want without having to spring for Enterprise
Edition. That is at least something to think towards.
Most importantly, work on your procedures and personnel. The best
technology in the world won't do any good unless the guy on duty has the
proper procedures and training to use them.
Geoff N. Hiten
Microsoft SQL Server MVP
"Dennis Burgess" <admin@surdyke.com> wrote in message
news:O$OgyKgOFHA.4052@TK2MSFTNGP12.phx.gbl...
> Its acutally for redunancy. SQL Enterprise is Extreamly expense compaired
> to standrad and the custering is the feature that I guess we need.
>
> One guy suggested replication of the database, can that be done? The NLB
> system really will work for whatever, the key is keeping the single
> database consistant with accurate data accross multple SQL boxes.
>
> IS the only recourse Enterpise Edition?
>
> Dennis
>
> "Geoff N. Hiten" <sqlcraftsman@gmail.com> wrote in message
> news:O%23QouBgOFHA.1564@TK2MSFTNGP14.phx.gbl...
>
>
| |
| Dennis Burgess 2005-04-05, 8:05 pm |
| I will look into "log shipping solution" never heard of them before but hey,
I am a networker, not a database guru :)
We are really just looking for high-avialbility, if a server fails, it keeps
the database goen!
I figured 2005 would have some new features for that, but don't help us now.
I think we might just scale up and get enterpise and be done with it.
Dennis
"Geoff N. Hiten" <sqlcraftsman@gmail.com> wrote in message
news:%23RGDZUgOFHA.3356@TK2MSFTNGP12.phx.gbl...
> OK, you are looking at availability solutions. Here are some quick
> thoughts
>
> Replication is probably not a good idea. DDL changes don't get pushed to
> the subscriber, nor do stored procedure changes. Your best option may be
> to build a standby server using a home-grown or third-party log shipping
> solution. It won't be a fast, automatic failover like with clustering,
> but it will be considerably better than building a system from scratch.
>
> There are also some availability features announced for SQL Server 2005
> that may get you closer to what you want without having to spring for
> Enterprise Edition. That is at least something to think towards.
>
> Most importantly, work on your procedures and personnel. The best
> technology in the world won't do any good unless the guy on duty has the
> proper procedures and training to use them.
>
> Geoff N. Hiten
> Microsoft SQL Server MVP
>
>
> "Dennis Burgess" <admin@surdyke.com> wrote in message
> news:O$OgyKgOFHA.4052@TK2MSFTNGP12.phx.gbl...
>
>
| |
| Geoff N. Hiten 2005-04-05, 8:05 pm |
| If you want automatic failure detection with a short switchover time, then
Enterprise Clustering is the way to go. It ain't cheap, but neither is
downtime.
I cannot emphasize this enough. Be sure and get adequate training. Develop
and test your disaster procedures well before any problems. The most junior
support person at three AM should not be the person working out the
procedures while the system is down. Technology alone will not increase
your system availability.
Good luck,
Geoff N. Hiten
Microsoft SQL Server MVP
"Dennis Burgess" <admin@surdyke.com> wrote in message
news:ury%23dbgOFHA.3296@TK2MSFTNGP15.phx.gbl...
>I will look into "log shipping solution" never heard of them before but
>hey, I am a networker, not a database guru :)
>
> We are really just looking for high-avialbility, if a server fails, it
> keeps the database goen!
>
> I figured 2005 would have some new features for that, but don't help us
> now. I think we might just scale up and get enterpise and be done with it.
>
> Dennis
>
>
> "Geoff N. Hiten" <sqlcraftsman@gmail.com> wrote in message
> news:%23RGDZUgOFHA.3356@TK2MSFTNGP12.phx.gbl...
>
>
| |
| Dennis Burgess 2005-04-05, 8:05 pm |
| Well, its basically me, so its really a matter of, if a server fails, having
the second to back it up, then reconizing that something has failed also.
Dennis
"Geoff N. Hiten" <sqlcraftsman@gmail.com> wrote in message
news:ukez1igOFHA.688@TK2MSFTNGP10.phx.gbl...
> If you want automatic failure detection with a short switchover time, then
> Enterprise Clustering is the way to go. It ain't cheap, but neither is
> downtime.
>
> I cannot emphasize this enough. Be sure and get adequate training.
> Develop and test your disaster procedures well before any problems. The
> most junior support person at three AM should not be the person working
> out the procedures while the system is down. Technology alone will not
> increase your system availability.
>
> Good luck,
>
> Geoff N. Hiten
> Microsoft SQL Server MVP
>
> "Dennis Burgess" <admin@surdyke.com> wrote in message
> news:ury%23dbgOFHA.3296@TK2MSFTNGP15.phx.gbl...
>
>
| |
| aramid 2005-04-06, 7:02 am |
| NLB can be effectively used with SQL 2000 given certain conditions:
- that the databases on the NLB-enabled servers are "read-only"
relative to the application (like a web site delivering content)
- that some other database server at the back has the master copy of
these databases and where actual content updates are made (this should
normally be a SQL cluster)
- there is some form of replication (most likely transactional)
between the "main" db and the databases on the NLB-enabled machines
The others here have correctly pointed out some of the issues in this
setup, but that's the tradeoff you'll have to consider.
This setup will give you both load-balancing and redundancy. It is
quite trivial to add more "front-end" database servers if you need
more capacity. Given that initially you will have redundant data
across all your front-end db servers, you can later on consider
partitioning the data and create multiple sets of NLB-enabled
machines.
Aramid
On Tue, 5 Apr 2005 14:25:44 -0500, "Dennis Burgess"
<admin@surdyke.com> wrote:
>Well, its basically me, so its really a matter of, if a server fails, having
>the second to back it up, then reconizing that something has failed also.
>
>Dennis
>
>"Geoff N. Hiten" <sqlcraftsman@gmail.com> wrote in message
>news:ukez1igOFHA.688@TK2MSFTNGP10.phx.gbl...
>
| |
| Dennis Burgess 2005-04-06, 8:02 pm |
| The way we are looking is that we are going to end up getting enterprise and
using the clusting that is built in. The way I understand it is going to be
better speed, and preformance, plus better failover.
They are just going to have to buck up and spend the cash and do it right.
"aramid" <aramid@hotmail.com> wrote in message
news:3kr651h1dvlkm8r
u5ep0brl38efh1neoc7@
4ax.com...
> NLB can be effectively used with SQL 2000 given certain conditions:
>
> - that the databases on the NLB-enabled servers are "read-only"
> relative to the application (like a web site delivering content)
> - that some other database server at the back has the master copy of
> these databases and where actual content updates are made (this should
> normally be a SQL cluster)
> - there is some form of replication (most likely transactional)
> between the "main" db and the databases on the NLB-enabled machines
>
> The others here have correctly pointed out some of the issues in this
> setup, but that's the tradeoff you'll have to consider.
>
> This setup will give you both load-balancing and redundancy. It is
> quite trivial to add more "front-end" database servers if you need
> more capacity. Given that initially you will have redundant data
> across all your front-end db servers, you can later on consider
> partitioning the data and create multiple sets of NLB-enabled
> machines.
>
> Aramid
>
> On Tue, 5 Apr 2005 14:25:44 -0500, "Dennis Burgess"
> <admin@surdyke.com> wrote:
>
>
|
|
|
|
|