Re: Issues creating a new failover cluster on the same server
- From: "Anthony Thomas" <ALThomas@xxxxxxxxx>
- Date: Wed, 7 Feb 2007 19:47:05 -0600
In addition to Geoff's comments, I do have some remarks regarding your
comments.
CHSSQ04 Group
Drives: E, G, K, S, Z
G:\Microsoft SQL Server\MSSQL.1
and
CHNSQL04 Cluster Group
Drives: H and F
H:\Microsoft SQL Server\MSSQL.2
You host the database files, logs, etc. on a shared drive, but not the
binaries, they are installed on the local node drives for each cluster
member. What drives are the binaries installed on?
Later:
We are not sharing drives for each cluster group and instance, they have
their own drives, and this means that CHNSQL04 can not see drives that
are
used by CHSSQL04 and visa versa.
Whenever resources are running on one of the nodes, then all resources for
each network name are available on that node. So, if you have the Cluster
Group, the MS DTC Group, and each of the SQL Server Instance Groups running
on the same node, then you will see all of the resources if you connect to
the Node name, the Cluster name, the MS DTC name, the SQL Instance 1 name,
and the SQL Instance 2 name, including any network shares.
The point about clustering network shares is that those shares come online
and offline along with the resource group. So, if the group is on node 1,
then so are the shares and not visible from node 2. If you move group
resources to node 2, then the resources go offline on node 1 and come online
on node 2.
This configuration does nothing about securing what each instance will
"see."
Lastly, for the browser service, it runs on each node and translates
Instance Names to Port Numbers to connect to. It is not clustered, and runs
as an individual server service on every node of the cluster, just like the
Cluster service, Event Log, Server and Workstation, IPSec, or whatever other
stand alone application being hosted. So, on each cluster node, the browser
service needs to be installed on a local drive and its associated log file
located there as well. It cannot exist on any of the Cluster Resource Group
drives.
Everyone here is more than happy to help you work through this; however,
please read through the documentation provided in the links from my first
reply. It seems to me that you have a basic misunderstanding about what
clustering is, and it is affecting your installation decisions
inappropriately.
The simplest way I can describe it is thusly. If you installed SS to a
stand-alone server, hopefully, you would install the binaries to one drive,
your data files on a dedicated second drive, transaction logs to a third,
and perhaps dedicate the database backups to a 4th and the tempdb to a 5th.
Now, you want have a cold standby. You would install the binaries to a
second server, hopefully in a similar location, but you would be relying on
the SAN guys to be able to move your volumes for your database files, logs,
backups, tempdb, etc., and present them to this second server in the event
of a disaster. If you imported those drives and then lettered them the same
as they were on the first server, then you should be able to turn the
services on without any problem.
Clustering adds more complexity to this solution, but in essence does
exactly this, but automatically, and unlike the scenario above where the two
server names would be different, the cluster presents a virtual server name
and IP address to the public that does not change when resources run on one
server or the other; so, except for the offline and online sequence, remains
transparent to the end users.
However, what is required is to have the binaries on local drives of each
node. The services have to be installed on each node; it is just that only
one server at a time is actually running that service for those items that
have been added as a cluster resource. All other server service must be
online on all cluster nodes.
I hope this helps.
Sincerely,
Anthony Thomas
--
"Dan" <Dan@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:C082F024-7E12-4F4D-A822-4E93503D0DD4@xxxxxxxxxxxxxxxx
Anthony,setup.
To answer some of the items you have pointed out we have the following
the
We have two nodes
Chssq04a - active
Chssq04p - passive
For clarification: there are two groups with the prefixes: CHS and CHN
We have two cluster groups; chnsq04 group is the new cluster and where the
new sql instance is being installed. Both SQL instances are installed on
active node, CHSSQ04A.thus
CHSSQ04 Group
Assigned nodes: Chssq04a and Chssq04p
CHNSQ04 Group
Assigned nodes: Chssq04a and Chssq04p
Each virtual instance is unique with its own disks, ip, network name, and
instance name.
CHSSQ04 Group
Drives: E, G, K, S, Z
Two file shares
SQL IP address (10.0.50.48)
SQL Network Name (vssql04)
SQL Server (CHSNextgen)
SQL server agent (CHSNextgen)
SQL Server Fulltext (CHSNextgen)
SQL 2005 is installed for this instance at
G:\Microsoft SQL Server\MSSQL.1
CHNSQL04 Cluster Group
Drives: H and F
The setup then created the following:
SQL IP address (10.0.50.68)
SQL Network name (chnvssql04)
SQL Server (CHNNextgen)
SQL server agent (CHNNextgen)
SQL Server Fulltext (CHNNextgen)
SQL 2005 is installed for this instance at
H:\Microsoft SQL Server\MSSQL.2
We are not sharing drives for each cluster group and instance, they have
their own drives, and this means that CHNSQL04 can not see drives that are
used by CHSSQL04 and visa versa.
What I think your going to tell me is that I can not have two SQL Cluster
groups on the same node because the SQL Browser is not cluster aware and
can not see both clusters running at the same time. This is why I can not
start my second cluster group and instance.
.
- Follow-Ups:
- References:
- Prev by Date: Re: AntiVirus Software for SQL Cluster Servers
- Next by Date: Re: AntiVirus Software for SQL Cluster Servers
- Previous by thread: Re: Issues creating a new failover cluster on the same server
- Next by thread: Re: Issues creating a new failover cluster on the same server
- Index(es):
Relevant Pages
|
