First of all, sorry for my ignorance if it appears that I
don't completely understand it well...

I'm currently looking deeper into NLB and SQL Server 2000
and the combination of both.

If I understand the principle correctly, you set up an X
number of computers and configure NLB. Then you install on
these X computers SQL Server 2000 using a shared data
resource (ex. drive Q: pointing to the shared data
resource, whetever it may be but accessible from all X
computers).

Users connect to the database using the virtual IP address
where NLB comes in action to determine which host of the X
computers will handle the request.

Is this basic gridline correct or am I loosing my grip on
this subject? Note that it is the basic overview here, not
the details yet... Just to make sure that I'm on the right
track.

Comments, suggestion, links, etc. are very welcome
ofcourse.

Thanks in advance.

Marty.

Typically, you would use NLB for your app servers - not SQL Server. If you
need to use scale-out technology for SQL Server, you would install SQL
Server on a number of servers and build distributed partitioned views.


--
Tom

---------------------------------------------------------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql


"Marty" <marty (AT) pandora (DOT) be> wrote

First of all, sorry for my ignorance if it appears that I
don't completely understand it well...

I'm currently looking deeper into NLB and SQL Server 2000
and the combination of both.

If I understand the principle correctly, you set up an X
number of computers and configure NLB. Then you install on
these X computers SQL Server 2000 using a shared data
resource (ex. drive Q: pointing to the shared data
resource, whetever it may be but accessible from all X
computers).

Users connect to the database using the virtual IP address
where NLB comes in action to determine which host of the X
computers will handle the request.

Is this basic gridline correct or am I loosing my grip on
this subject? Note that it is the basic overview here, not
the details yet... Just to make sure that I'm on the right
track.

Comments, suggestion, links, etc. are very welcome
ofcourse.

Thanks in advance.

Marty.

The only problem with that design is that SQL cannot share disk resources
between instances. Each SQL instance must have full and complete control
over the underlying storage. In a cluster situation where a disk resource
is connected to multiple systems, the cluster software arbitrates ownership
so that only one system at a time owns and controls the disk resource.

--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com




"Marty" <marty (AT) pandora (DOT) be> wrote

In case your app is using SQL behind the scenes and the
load is heavy, does it not seem usefull to install
multiple instances of SQL on the nodes using a shared
resource for the data files so that all instances of SQL
access and use the same data files?

Marty

SQL Server cannot share data files. It is a powerful DBMS and can handle
most loads on a single server.

--
Tom

---------------------------------------------------------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql


"Marty" <marty (AT) pandora (DOT) be> wrote

In case your app is using SQL behind the scenes and the
load is heavy, does it not seem usefull to install
multiple instances of SQL on the nodes using a shared
resource for the data files so that all instances of SQL
access and use the same data files?

Marty

"Marty" <marty (AT) pandora (DOT) be> wrote

In general, in order to share access to disk you need a clustered file
system. Otherwise, if both servers will try to write to the same disk
corruption will occur.
More specifically, SQL server is a shared nothing database so the only
way to "load balance" the server is to use DPV.



Tomer Meshorer
Database Engineer
Polyserve (http://www.polyserve.com/sql)
tmeshorer (AT) polyserve (DOT) com

SQL Server is not meant to be used with NLB; it cannot
share data files. To "load balance" SQL Server, you can
partition your data, or use data dependent routing within
your application to tell it what SQL Server instance to
use. SQL Server scales up well, and can scale out, but
you need to build it into your data model or your
application.

That said, if you have read-only SQL Server data (not
write-based data), you can use NLB. It's really the only
pure situation where NLB is applicable, since each SQL
Server instance is independent of each other. A good
example where it is used commonly is catalog data for e-
commerce websites.

Wow,
Looks like you have gotten some great responses here.
I just wanted to sum them all up for you:

1> You can't share data files or disks with SQL (Even multiple instances on
the same machine).
2> If you have read only data you can have independent NLB SQL Instances,
but if you are writing data you will need to use DPV.
3> If you are concerned about the load your app will take to the sql
server, consider breaking out read-only data and writable data to different
instances of SQL. Break out reporting data, etc. as well.
4> Another thing to consider is have you adequately performance-tuned your
application and how it's using your databases? Perhaps some of the load
can be alleviated by doing some performance tuning.

Hope that helps!
Donna Lambert
Microsoft SQL Server Support Professional