At my organization, users have started to use the virtual address
created when SQL Server is installed on a failover cluster for non-SQL
uses.

I have always created an cluster IP resource in addition to the SQL
cluster IP resource for non-SQL access to the server (like for mapping
drives).

What is the impact on SQL Server if people use the SQL virtual IP for
non-SQL related access to the cluster?

Is there a best practice that dictates that a separate IP should be
provided for non-SQL access?

Mark (google (AT) markginsburg (DOT) com) writes:
Since I'm into clustering myself, I relayed the question to my MVP mates.
Here are two responses I recevied:

There is no different impact to SQL Between using the SQL name/ip or a
different name/ip in the same resource group. All it is in either
case is a socket connection to the server on one ip or another.

And response to this comment was:

The impact is this: if they add it to the SQL group, make it a
dependency of the SQL resource, and it goes down, it can potentially
take SQL down.

So never add anything to the SQL group for non-SQL access if you care
about HA.




--
Erland Sommarskog, SQL Server MVP, esquel (AT) sommarskog (DOT) se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx

On Jul 25, 4:57*am, Erland Sommarskog <esq... (AT) sommarskog (DOT) se> wrote:

If I understand correctly, there would be no difference between using
the SQL IP vs. a generic IP for non-SQL related network traffic.
Thanks.

It occurred to me that creating additional IP/Network name resources,
but not putting them in the resource group with the SQL Server
resources as was mentioned, would have negative consequences as well.
For example, if you need to perform administrative work on SQL Server
and are connected to the server using the SQL's IP, then if you take
the SQL resources offline, you will become disconnected. Or, If
instead you connect using the IP in Core Resources, you may connect to
the passive cluster node and will not have direct access to the disks
and other resources used by the DB. So, I'm back to creating my own
general purpose IP/Network name resource and putting it in the same
group with the SQL Server resources.