Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Status check and resource failures

Status
Not open for further replies.

talismanuk

IS-IT--Management
Nov 27, 2002
12
GB
Any ideas as to why some resources are failing with Error 1055 and 1069 periodically. ??

Actual message is " Cluster File share resource "nameofresource" has failed a status check. The error code is 71.

and "Cluster resource "nameofresource" has failed"

This is a recently "gone live" situation, and none of these errors were encountered during pilot test. Different resources are affected, with no apparent time pattern, and seemingly no bearing on the Cluster load.

many thanks in anticipation
 
What are the Event Id's

Are all the resources that fail, File Shares ?

What hardware are you using ?
 
I am having this same problem on a compaq proliant server. I recieve 1055 error code 64 and 1069 often. Usually ends with server needing rebooted
 
Hi all,
We have 2 Proliant ML 530 G2 dual processors with 1Go RAM
attached to a MSA1000 with 1 TeraBytes of disk.
Talismanuk are you found a solution to your problem posted
in Jan 6? we are having exactly the same problem ramdonly.

it's critical now, our cluster stops every day with no apparently reason

Thank you in advance for your help !

Humberto Duarte
Universite Rennes 2 France

 
Hi All,

We have 2 Dell 2650 dual processors with 1Go RAM
attached to a CX400 with 1 TeraBytes of disk.
I've exactly the same problem than DDIL. I receive 1055 error code 64 and 1069 often.
Have you finally found a solution?

Thanks in advance for your help.

Fred
 
I have the same issue here. Does any one of you use Veritas products on the Cluster?

Cheers

Ray
 
A resource the share depends on failed. In your case error 64 means ERROR_NETNAME_DELETED. I'd look at the network name resource.

When you set up a fileserver on a cluster, you should create a new group. In that group you should have an IP, a network name, disk, and share resources. The key here is that everything the share depends on should be in the same group as the share. This is called atomicity and is a best practice.

If you create a group, add a disk and a share, it will work. The problem here is that resources in one group [the share] depend on resources in another [the cluster IP and name by default]. If you fail over the cluster group, the group containing the file share will fail.

This may not be your specific issue, but should serve as a place to start troupleshooting. Look for failures of resources the share depends on, specificly the network name.

 
Hi All,

I Use veritas volume manager and the cluster have a netbackup agent. We've reinstall the cluster from scratch and after 3 days the first share failed with error code 64.

Fred
 
Anything fun in the system log? I suspect a resource failure of some sort...

Memory - 2019 or 2020
Disk - 9, 11, 15, or the infamous LDW - 50
 
The problem is here...
Nothing in cluster log.
Nothing in the event viewer before and after the share failed.
The only stuff who run during the night on this server is the backup (veritas netbackup)and the anti-virus (Sophos).
 
Backup could very well be causing you to run out of system resources, specifically PTEs. I'm not too familiar with Sophos.

Have you modifed systempages and HeapDecommitFreeBlockThreshold yet?

 
that is not an exchange cluster, and I tought this 2 keys are used only to tune the backup of exchange?
 
systempages is a memory manager setting and applies to a lot more than just exchange. Heapdecommitfreeblockthreshold is a session heap manager setting, and again, affects a lot more than just exchange.

The whole problem centers around resource useage. You can also play with page pool values like:

 
I've finally found what was my probleme.
an old version Filescreen From Wquinn (now, it's a veritas product) was installed on the cluster. After uninstallation, we didn't had any trouble.

Fred
 
Ah yes.. It belongs to Veritas now. It has always leaked like a sieve. It had a paged pool leak in several versions.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top