Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1044
  • Last Modified:

Quorum Cluster Possible owners - need to remove but getting an error message

I have a W2K3 ENT 64-bit Cluster for SQL 2K5. I added two new nodes to the cluster and removed the older nodes from the SQL cluster. They are however still nodes in the MS Cluster. When I attempt to remove the older systems as possible owners of the Q: physical drive, I get the following message "An error occurred attempting to remove node <servername> as a possible owner of the Disk Q resource. This operation cannot be performed on the cluster resource as it is the quorum resource. You may not bring the resource offline or modify its possible owner list. Error ID 5068 (000013cc)."

I need to make this happen and then evict the nodes from the MS Cluster service.

Any help you can offer will be greatly appreciated.
0
gwsedlock
Asked:
gwsedlock
  • 10
  • 10
1 Solution
 
gwsedlockAuthor Commented:
A follow-up to this is what would be the implications of merely evicting the nodes without makign the resource changes? The current owner is one of the new servers. The passive node in the cluster is also a new server. Can I simply evict the older nodes without problems?

Thanks again!
0
 
Jim P.Commented:
The Q: drive is typically the quorum drive for all nodes in the cluster. Unless you have created a new quorum drive then you will need to have one or both of the new nodes become an owner of the quorum drive. Then you should be able to knock off the older nodes.
0
 
gwsedlockAuthor Commented:
Thanks for the comment.

Both of the new nodes are shown as being possible owners with one of the new nodes actually being listed as the current owner. Unfortunately, I am still unable to remove the older nodes as possible owners and receive the same error as listed in the initial post. Anything else I might try?

Thanks!
0
Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

 
Jim P.Commented:
Have you removed all the old nodes as possible owners from all the things like Q: drive and MSDTC?
0
 
gwsedlockAuthor Commented:
It is the Q drive resource where I am having issues. I have checked and double-checked all of the other resources and none have the old nodes as possible owners. When I go to remove them from the Physical Drive Resource Q: I get the error message.

0
 
Jim P.Commented:
And you have Moved the Cluster Group off the old node(s) to the new nodes?

0
 
gwsedlockAuthor Commented:
If I understand the question correctly, yes. I have ensured that all of the groups and resources are set to have one of the new nodes as the OWNER.

Also, by running cluster.exe group I have confirmed that the new node is running the CLUSTER GROUP, DTC and SQL Groups. (Yes, the nodes have been removed from the Virtual SQL Server Cluster as well. I have also ensured that the old nodes are no longer targets for the NAS iSCSI LUNs.

Thanks
0
 
Jim P.Commented:
I know these are dumb questions. I don't have a large amount of experience with clusters.

On the dead nodes can you go in and offline/delete the disks in disk management?
0
 
gwsedlockAuthor Commented:
I just checked one of the old nodes and in Disk Management, the Q drive is not shown; therefore, I am unable to delete this.

Since Q is a NAS drive and not local and the old nodes are not connected to the NAS resources, this drive won't show in the Disk Management. It does show though on the current Active Node (one of the two new nodes.)

I appreciate all your help, even if you do have limited cluster experience. Questioning is always a good thing because it may jostle an idea or at least will help eliminate a number of possible items, bringing a solution ever closer.
0
 
Jim P.Commented:
Could the drive signatures be off between the new nodes and in the cluster, and the old ones. And since they are, it isn't recognizing the old nodes are nolonger connected to the Q: and quorum drive?

>> Questioning is always a good thing because it may jostle an idea

Thanks. I've run into other askers that don't understand that we don't see the the sceens and read their minds.
0
 
gwsedlockAuthor Commented:
I'm relatively new to clusters myself so it is possible the disk sigs. in the Cluster.log file are off. Is it possible to reset them and then remove them from the resource? I don't know what step I took in removing the old nodes from the SQL cluster that could have possibly caused the difference. Everything seemed to be straight-forward in that process.

If there is a discrepancy it isn't so bad that the cluster fails to start since we are fine with the SQL connections. Once we moved the old nodes out of the SQL component and brought the new nodes in, we did test fail-over and all was fine.

I've been in IT for about 12 years and have done some phone support in the past so I know the "fun" of trying to read minds :-)
0
 
gwsedlockAuthor Commented:
I just checked the HKLM\Cluster\resources for the Q and do not see a multi-strink for Possible Owners. I can find it for the other physical disk resources. I'm not sure if this is the problem or not.

I could possibly add the key with the possible owners but certainly don't want to bring the cluster down either.

Any idea?
0
 
Jim P.Commented:
The disk sigs get corrupted very easily. We have two clusters with 2 nodes each.

We had our SAN controller drop during production several days ago and they would only come up on one node each at a time until we played with the signatures and got them back into sync.

I work with a guy that is our guru on the server side of clustering. I'm the DBA. I know roughly what to look for on the server side, but not the nitty gritty.
0
 
Jim P.Commented:
>> I could possibly add the key with the possible owners

Do you have a downtime window? And I don't think it takes effect until you flop it.

You may want to see if you can add and then deletel them again.
0
 
gwsedlockAuthor Commented:
We would have to request a window. Before I do that I'd like to do some more research on the REG changes first. I did compare the HKLM\Cluster on the current new nodes with the old nodes and the key for the Q resource does not have Possible owners on any one of them. So, I'm not sure this is the correct area to consider.

>>You may want to see if you can add and then deletel them again.>>

If by this you mean add them back to the SQL cluster, this would not be possible since version levels with SQL is off (and reverts to RTM sans SPs.) Also, we are using SQL 2K5 STD which means one only two nodes in the cluster. We were performing a rolling hardware upgrade.
0
 
Jim P.Commented:
>> If by this you mean add them back to the SQL cluster

You should be able to add the nodes to the cluster with out adding them to the SQL.

But anyway I was thinking about the signatures.

Can you pull the Event logs from the servers and see what the errors are there.

As I understand it, there is also a separate cluster log that resides on the Q: as a text file.
0
 
gwsedlockAuthor Commented:
I have not removed the nodes from the MSCS yet, only from the SQL Cluster. I'm wondering if I would be able to remove the old nodes from the cluster without any issues and have that process remove them as possible owners.

As for the Event log, there are no entries in the SYSTEM or APPLICATION log files (I cleared the log files to be sure to capture any error when attempting to remove the nodes from the Q Resource.) The quolog.log doesn't show any errors either.
0
 
Jim P.Commented:
>> I'm wondering if I would be able to remove the old nodes from the cluster ...

I'm thinking that would probably work.

Go to cluster admin

Find the node --> Active Resources
If it is only the Custer Group
Do a Pause Node
Then try an Evict Node.

You should probably be good.
0
 
gwsedlockAuthor Commented:
I would think that given all that we covered as options to complete this process, this is likely the answer. I'll have to run it by the others to set a plan of attack.

Thanks for all your help!
0
 
Jim P.Commented:
Glad to be of assistance. May all your days get brighter and brighter.
0

Featured Post

Transaction-level recovery for Oracle database

Veeam Explore for Oracle delivers low RTOs and RPOs with agentless transaction log backup and transaction-level recovery of Oracle databases. You can restore the database to a precise point in time, even to a specific transaction.

  • 10
  • 10
Tackle projects and never again get stuck behind a technical roadblock.
Join Now