Suggested Cluster ID?

If the system is already part of a cluster, the cluster ID is retrieved. See http://support.veritas.com/docs/269200
If it's not part of a cluster, I don't know. Maybe it just suggests 0.

Are you looking to create a new cluster, or join an existing one? Or just asking out of interest?

originally, the cluster IDs and nodes were stored in a file on the PDC. Then when you started an install it would pick the next number. This file became an issue because it was not replicated anywhere, so if the PDC were down and a BDC became PDC, it would start with 0 again. Then came the new DC forests making the file invalid.

The only real problem is when you have heartbeats travelling over cabling that is shared with other clusters. Then you can have duplicate cluster ids that would have duplicate node numbers.

So manage them yourself, or don't let them send heartbeats on public networks.

Thank you for the quick responses.

Unfortunately, reconfiguring network is now probably not an option at this point. Do you know if the VCSPDC.conf file is still used with 4.3 or 5.0? I see that the file can be used on Windows 2000 AD domains but I see not information on Windows 2003 AD domains.

Thanks again.

I don't think conf file works now. Possible it still does. It creates problems when doing multiple simultaneous installs because the file is locked during install.

I've got a cluster running on a Win2k3 domain, and never had to deal with any of this!
Rob, I'm intrigued as to what you're trying to do.

The VCSPDC.conf file is not used, to my knowledge.
I would suggest that the customers keep a list of which clusterID is used for which cluster, and keep that file under change control if nothing else is available.

As has been said in the past, if you don't have shared heartbeat networks, then this really isn't a problem.

We have 60+ Veritas clusters to manage and many more to come. What I am attempting to do is get my hands around a cluster ID management process that is more proactive or automated. The VCSPDC.conf file, if it is actually used in conjunction with the VCW, may be able to help prevent a new cluster from coming online with a conflicting ID of an existing cluster.

I agree that network port management (around the HBs) is the best practice method to prevent conflicts coupled with a change management process. However, restricting the network ports may not be an option at this point, so I was searching for automated, alternative to managing 60+ cluster IDs in a spreadsheet, which is already in progress and recently failed us.

Thank you all for the answers and suggestions. If there are others, please send them on, especially any hands-on knowledge of the VCSPDC.conf file working on 4.3 or 5.0. :)

I would recommend you submit a request that would either provide a management tool for cluster IDs, or my favorite, unique cluster IDs generated by the VCS software upon install, somewhat like the Disk Group IDs generated by SFW.

Here are 2 articles that may be helpful to the subject of the vcspdc.conf file:

This article describes how to create the vcspdc.conf file:
http://seer.entsupport.symantec.com/docs/265630.htm

This article describes how the vcspdc.conf file works with Windows 2000 domains and Clusters running on Windows 2000:
http://seer.entsupport.symantec.com/docs/246174.htm