Re: Question about Veritas Cluster and filespace name
All, The TSM Backup-Archive client has support for MSCS (Windows), HACMP (AIX) and NCS (NetWare) clustering solutions. If you are using a clustering solution on one of the Intel platforms other then these listed, you will have these naming issues after a fail-over. We are looking into something similiar to what Peter is suggesting, and that is a way to logically manage a set of data on the TSM server which is sent from different client nodes. This would be beneficial for clustering as well as have other applications. We are also pursuing adding support for some of these other clustering solutions. It doesn't hurt to open requirements to Tivoli if you have a particular cluster solution that you would like to see supported. Thanks, Jim Smith TSM client development In response to: You know, there seems to be a similar issue with filespace naming with the new Netware cluster aware client. We're awaiting a server upgrade to pursue it further. Seems as it the 'getservername' API call is at the heart of this. Yes, it seems TSM is not savey of any cluster soloutions except Microsoft's. If they (TSM) would only introduce a new option in the .opt file so one could override the servername if for some reason or another one should wish to do so. It would probably solve the naming problem in most cluster sitiations. Regards Peter J.P. (Jim) Smith TSM Client Development [EMAIL PROTECTED]
Re: Question about Veritas Cluster and filespace name
You know, there seems to be a similar issue with filespace naming with the new Netware cluster aware client. We're awaiting a server upgrade to pursue it further. Seems as it the 'getservername' API call is at the heart of this. Yes, it seems TSM is not savey of any cluster soloutions except Microsoft's. If they (TSM) would only introduce a new option in the .opt file so one could override the servername if for some reason or another one should wish to do so. It would probably solve the naming problem in most cluster sitiations. Regards Peter
Re: Question about Veritas Cluster and filespace name
Yes, it seems TSM is not savey of any cluster soloutions except Microsoft's. That an HACMP. -- Joshua S. Bassi IBM Certified - AIX 4/5L, SAN, Shark Tivoli Certified Consultant -ADSM/TSM eServer Systems Expert -pSeries HACMP AIX, HACMP, Storage, TSM Consultant Cell (831) 595-3962 [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of Peter Bjoern Sent: Thursday, December 12, 2002 6:07 AM To: [EMAIL PROTECTED] Subject: Re: Question about Veritas Cluster and filespace name You know, there seems to be a similar issue with filespace naming with the new Netware cluster aware client. We're awaiting a server upgrade to pursue it further. Seems as it the 'getservername' API call is at the heart of this. Yes, it seems TSM is not savey of any cluster soloutions except Microsoft's. If they (TSM) would only introduce a new option in the .opt file so one could override the servername if for some reason or another one should wish to do so. It would probably solve the naming problem in most cluster sitiations. Regards Peter
Question about Veritas Cluster and filespace name
Hi We have a situation with a Veritas cluster installed on two Win2000 servers. The physical servers are called J2P-CLUSTER101 and J2P-CLUSTER102. There is a virtual server defined with the name WEB1. Each physical server has it's own C: drive which is backed up via a schedule that specifies 'C:' and 'systemobject' on the domain statement in the option file. The C: filespaces are given the names \\J2P-CLUSTER101\C$ and \\J2P-CLUSTER102\C$ respectively. This is all OK. There is a shared drive X: which is associated with the WEB1 resource and moves with WEB1 between the two physical servers so that it is available either on J2P-CLUSTER101 or J2P-CLUSTER102. X: is backed up from a virtual node defined in TSM called WEB1 and via a separate TSM scheduler service with an option file that specifies X: on the domain statement. If this had been a Microsoft Cluster installation, we would have specified 'CLUSTERNODE YES' in the optionfiles to make TSM name the X: filespace with the virtual clustername (WEB1) so that it would have been named \\WEB1\X$ regardless of which physical server it was backed up from. However, CLUSTERNODE does not work with a Veritas cluster, so the result is that we get two parallel filespaces named \\J2P-CLUSTER101\X$ and \\J2P-CLUSTER101\X$ because X: sometimes resides on J2P-CLUSTER101 and some times on J2P-CLUSTER102. From previous postings on this list I get the impression that there is nothing we can do to solve this, but I just want to be sure if this is true How are other people who are running Veritas clusters and TSM solving this ? This is a bad situation and one could fear (from a TSM person point of view) that it could pave the way for the introduction of Veritas backup software at the site. If CLUSTERNODE cannot easily be enhanced to support Veritas clusters as well, all we would need would be a new statement in the option file, perhaps called MACHINENAME or so, where we could specify 'MACHINENAME WEB1' in the optionfile and then have TSM use this name is the filespacing naming process. Regards Peter
Re: Question about Veritas Cluster and filespace name
Yes, i have exactly the same problem with Windows Double-Take, i would like change the way that TSM nam the the filespacing naming process. -- David Rigaudiere -+- Administration TSM + NT Paris -+- 40, rue de Courcelles -+- 4e étage -+- [EMAIL PROTECTED] -+- 01.5621.7802 |-+--- | | Peter Bjoern| | | pebjn@WMDATASDC| | | .DK| | | Sent by: ADSM: | | | Dist Stor | | | Manager| | | [EMAIL PROTECTED]| | | T.EDU | | | | | | | | | 11/12/2002 12:45| | | Please respond | | | to ADSM: Dist | | | Stor Manager | | | | |-+--- ---| | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Question about Veritas Cluster and filespace name | ---| Hi We have a situation with a Veritas cluster installed on two Win2000 servers. The physical servers are called J2P-CLUSTER101 and J2P-CLUSTER102. There is a virtual server defined with the name WEB1. Each physical server has it's own C: drive which is backed up via a schedule that specifies 'C:' and 'systemobject' on the domain statement in the option file. The C: filespaces are given the names \\J2P-CLUSTER101\C$ and \\J2P-CLUSTER102\C$ respectively. This is all OK. There is a shared drive X: which is associated with the WEB1 resource and moves with WEB1 between the two physical servers so that it is available either on J2P-CLUSTER101 or J2P-CLUSTER102. X: is backed up from a virtual node defined in TSM called WEB1 and via a separate TSM scheduler service with an option file that specifies X: on the domain statement. If this had been a Microsoft Cluster installation, we would have specified 'CLUSTERNODE YES' in the optionfiles to make TSM name the X: filespace with the virtual clustername (WEB1) so that it would have been named \\WEB1\X$ regardless of which physical server it was backed up from. However, CLUSTERNODE does not work with a Veritas cluster, so the result is that we get two parallel filespaces named \\J2P-CLUSTER101\X$ and \\J2P-CLUSTER101\X$ because X: sometimes resides on J2P-CLUSTER101 and some times on J2P-CLUSTER102. From previous postings on this list I get the impression that there is nothing we can do to solve this, but I just want to be sure if this is true How are other people who are running Veritas clusters and TSM solving this ? This is a bad situation and one could fear (from a TSM person point of view) that it could pave the way for the introduction of Veritas backup software at the site. If CLUSTERNODE cannot easily be enhanced to support Veritas clusters as well, all we would need would be a new statement in the option file, perhaps called MACHINENAME or so, where we could specify 'MACHINENAME WEB1' in the optionfile and then have TSM use this name is the filespacing naming process. Regards Peter --- This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. ABN AMRO Bank N.V. (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference. --- Le présent message (y compris tous les éléments attachés) est confidentiel et est destiné aux seules personnes qu'il vise. Si vous l'avez reçu par erreur, merci de l'indiquer à son expéditeur par retour et de procéder à sa
Re: Question about Veritas Cluster and filespace name
You know, there seems to be a similar issue with filespace naming with the new Netware cluster aware client. We're awaiting a server upgrade to pursue it further. Seems as it the 'getservername' API call is at the heart of this. David Rigaudiere wrote: Yes, i have exactly the same problem with Windows Double-Take, i would like change the way that TSM nam the the filespacing naming process. -- David Rigaudiere -+- Administration TSM + NT Paris -+- 40, rue de Courcelles -+- 4e étage -+- [EMAIL PROTECTED] -+- 01.5621.7802 |-+--- | | Peter Bjoern| | | pebjn@WMDATASDC| | | .DK| | | Sent by: ADSM: | | | Dist Stor | | | Manager| | | [EMAIL PROTECTED]| | | T.EDU | | | | | | | | | 11/12/2002 12:45| | | Please respond | | | to ADSM: Dist | | | Stor Manager | | | | |-+--- | | | |To: [EMAIL PROTECTED] | |cc: | |Subject: Question about Veritas Cluster and filespace name | | Hi We have a situation with a Veritas cluster installed on two Win2000 servers. The physical servers are called J2P-CLUSTER101 and J2P-CLUSTER102. There is a virtual server defined with the name WEB1. Each physical server has it's own C: drive which is backed up via a schedule that specifies 'C:' and 'systemobject' on the domain statement in the option file. The C: filespaces are given the names \\J2P-CLUSTER101\C$ and \\J2P-CLUSTER102\C$ respectively. This is all OK. There is a shared drive X: which is associated with the WEB1 resource and moves with WEB1 between the two physical servers so that it is available either on J2P-CLUSTER101 or J2P-CLUSTER102. X: is backed up from a virtual node defined in TSM called WEB1 and via a separate TSM scheduler service with an option file that specifies X: on the domain statement. If this had been a Microsoft Cluster installation, we would have specified 'CLUSTERNODE YES' in the optionfiles to make TSM name the X: filespace with the virtual clustername (WEB1) so that it would have been named \\WEB1\X$ regardless of which physical server it was backed up from. However, CLUSTERNODE does not work with a Veritas cluster, so the result is that we get two parallel filespaces named \\J2P-CLUSTER101\X$ and \\J2P-CLUSTER101\X$ because X: sometimes resides on J2P-CLUSTER101 and some times on J2P-CLUSTER102. From previous postings on this list I get the impression that there is nothing we can do to solve this, but I just want to be sure if this is true How are other people who are running Veritas clusters and TSM solving this ? This is a bad situation and one could fear (from a TSM person point of view) that it could pave the way for the introduction of Veritas backup software at the site. If CLUSTERNODE cannot easily be enhanced to support Veritas clusters as well, all we would need would be a new statement in the option file, perhaps called MACHINENAME or so, where we could specify 'MACHINENAME WEB1' in the optionfile and then have TSM use this name is the filespacing naming process. Regards Peter --- This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. ABN AMRO Bank N.V. (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses
