How to configure the nbcc-server-aliases file for Aliases, "App Clusters", and/or clustered Master Servers.

Article:TECH69741  |  Created: 2009-01-17  |  Updated: 2014-01-13  |  Article URL http://www.symantec.com/docs/TECH69741
Article Type
Technical Solution

Product(s)

Environment

Issue



How to configure the nbcc-server-aliases file for Aliases, "App Clusters", and/or clustered Master Servers.


Solution



The nbcc-server-aliases file is used by NBCC during the collection of data to analyze the consistency of the NetBackup catalog.

This Technote describes how to configure the nbcc-server-aliases file and covers cases from simple Media Servers to cases where there are either multiple STUs for the same Media Server that specify different names for that media server, or when there are STUs for both physical and "virtual" Media Servers, where there is an STU that is "owned by" a virtual IP.

Some definitions before we begin...

While it is "legal" for multiple STUs to be created for the same Media Server where different "flavors" of names are used for that media server, it is definitely not "best practice" to do so.  But it has certainly been seen in customer environments from time to time.  This might be seen,  for example, when the STU for one robot uses the short hostname of the media server, and a second  robot on the same Media Server used the FQN, or maybe the name of a backup NIC.  

At NetBackup 5.x and earlier, when creating an STU, the field for the Media Server name was a freeform text field, so it was just a matter of entering different names for the media server when the STUs are created.

In NetBackup 6.x, all the various names of a Media Server should be formally defined in EMM as Aliases.  And, when creating an STU at NetBackup 6.x, the Media Server name must be selected from a pull-down box and the media server name must already exist.  Only the "primary" names are presented, so at NetBackup 6.x, it would not be possible to create STUs with different "flavors" of names for the same Media Server.

Both NetBackup 5.x and 6.x had the "concept" of an App Cluster, but they are treated differently because of the EMM.  At NetBackup 5.1, NetBackup didn't even KNOW about App Clusters, where at NetBackup 6.x the App Clusters have to be defined into EMM.  But the definition of an App Cluster is the same for both NetBackup 5.1 and NetBackup 6.0.  

An App Cluster is when NetBackup is involved with systems that are clustered, but where NetBackup is NOT a clustered resource.  In this configuration, it is very typical to configure an STU for each physical node of the "cluster" (since NetBackup itself is not clustered), and then to also define STUs that are owned by a "hostname" that is associated with the virtual IP of the cluster.  

When backups of the physical nodes is desired, the backup policy specifies the STU of the physical node and the base OS files are thus backed up.  It would also be typical for that policy to "exclude" any files that are involved with the clustered application.

When backups of the clustered application are performed, the backup policy then specifies the STU that is "owned" by the virtual IP.  When the backup starts, the backup will be "received" by whichever physical Media Server the cluster is currently running  on.  This will allow backups of that hostname associated with a virtual IP to be performed to local resources (tape and/or disk) directly attached to that physical media server, thus preventing network backups.

At NetBackup 5.x and prior, neither the Master or Media Servers actually "knew" that the backup was being performed by an STU owned by a "virtual Media Server".  However, at NetBackup 6.x, the App Cluster must be defined into EMM (see documentation in the "Commands" manual nbemmcmd on how to configure these.  A separate App Cluster is defined for each Virtual IP that is to be the "owner" of an STU, and it is populated with all physical media servers that the Virtual IP can run on.  Once the App Clusters are configured into EMM, then, the process is very similar to the process for NetBackup 5.x.  A STU is created for each physical node, and then an STU is created for each App Cluster, and then the policies are set up the same as for 5.x.

One more note before we get started... The order of entries on each line in the nbcc-server-aliases file should be to list ALL the IP addresses then ALL of the host names.  The first host name listed becomes the "primary name" for this system.  This doesn't really affect any configuration items in the NetBackup environment, but it will control which name is reported by NBCC and subsequent processes for information dealing with any of the systems listed on that one line in the nbcc-server-aliases file.  So, if the preferred name is the FQN, put it first.  If the preferred name is the short name, put it first.

Now that we have the definitions, let's get back to NBCC and nbcc-server-aliases configuration.

An easy way to "look at" the nbcc-server-aliases file is that there should be ONLY ONE line for each physical Media Server in the environment.  Each App Cluster should be included on the line of one of the physical media servers on which it can run.  In addition, each media server name, either physical or App Cluster should be included on ONE and ONLY ONE line in the nbcc-server-aliases file.  

In the case of a clustered Master Server, there is actually only one "instance" of NetBackup to collect from and that instance just happens to be able to live on one of several physical nodes.  Using the same logic as above, we only want to collect data from the Master Server once, so there should only be one line in the nbcc-server-aliases file for the case where NetBackup is a clustered resource.  That line should list the virtual name of the Master Server first, then the names of each physical node that the master server can live on.

If there are any instances where there are clustered Media Servers (where the Media Server is ACTUALLY a clustered resource), they would also be treated the same as a clustered Master Server.  HOWEVER, we do not recommend having clustered Media Servers, so if they do exist, the more general recommendation would be to not have them at all.

So let us consider some examples.

Scenario 1:  A regular media server with no Aliases or App Clusters involved.
One line with host names of the physical media server. 
All IP addresses and both the short hostname and the FQN should be on each line
Example:
192.168.172.14  server-a.xxx.com server-a
 
Scenario 2:  A media server involved in an Active/Passive cluster
One line for each physical media server
The name associated with the virtual IP addresses should appear on one of these lines 
All IP addresses and both the short hostname and the FQN for all hostnames should be on each line  
 
Examples:
192.168.172.15 192.168.172.17 server-b.xxx.com server-b virtualip-a.xxx.com virtualip-a
192.168.172.16 serverc.xxx.com server-c
Or
192.168.172.15   server-b.xxx.com server-b
192.168.172.16 192.168.172.17  server-c.xxx.com server-c virtualip-a.xxx.com virtualip-a
 
Scenario 3:  A media server involved in an Active/Active cluster
One line for each physical media server
The name associated with each virtual IP addresses should appear on one of these lines 
All IP addresses and both the short hostname and the FQN for all hostnames should be on each line 
If the clustered application "normally" lives on a particular Media Server, it would be "nice" to put the host name associated with the virtual IP address on the line for that physical media server.  But it is not "required".
 
Examples:
192.168.172.17 192.168.172.19 serverd.xxx.com server-d virtualip-b.xxx.com virtualip-b
192.168.172.18 192.168.172.10 servere.xxx.com server-e virtualip-c.xxx.com virtualip-c
Or
192.168.172.17 192.168.172.19 192.168.172.20 server-d.xxx.com server-d virtualipb.xxx.com virtualip-b virtualipc.xxx.com virtualip-c
192.168.172.18 server-c.xxx.com server-e
 
Scenario 4:  A more complex configuration like Active/Active/Passive where there are several physical Media Servers and several host names associated with virtual IP addresses.  Assuming that the clustered applications have no "preferred home" among the various physical nodes, and over time, might live on all physical nodes in the cluster. 
For this configuration, we still need one line for each physical media server
The name associated with each virtual IP addresses should appear on one of these lines 
All IP addresses and both the short hostname and the FQN for all hostnames should be on each line 
 
 
Examples:
192.168.172.21 192.168.172.24 server-f.xxx.com server-f virtualip-d.xxx.com virtualip-d
192.168.172.22 192.168.172.25 server-g.xxx.com server-g virtualip-e.xxx.com virtualip-e
192.168.172.23 server-h.xxx.com server-h
Or
192.168.172.21 192.168.172.24 192.168.172.25 server-f.xxx.com server-f virtualip-d.xxx.com virtualip-e virtualip-e.xxx.com virtualip-e
192.168.172.22 server-g.xxx.com server-g
192.168.172.23 server-h.xxx.com server-h 
 
Scenario 5:  A media server with multiple names due to either multiple NICs and/or just multiple IP addresses
 
One line with all host names of the physical media server, listing "preferred name first" 
All IP addresses and both the short hostname and the FQN for all host names should be on each line
 
Example:
192.168.172.24  192.168.172.25 server-i.xxx.com server-I server-i-bk.xxx.com server-i-bk
Or
192.168.172.24  192.168.172.25 server-i.xxx.com server-I server-i-g.xxx.com server-i-g
 
Scenario 6:  A clustered master server with two physical nodes
 
One line with the virtual name of the master and the names of both physical nodes of the cluster, listing "virtual name of the master first" 
All IP addresses and both the short hostname and the FQN for all host names should be on one line
 
Example:
192.168.172.25 192.168.172.26 192.168.172.27  virtual-master-server-name.xxx.com virtual-master-server-name physical-master-server-node1.xxx.com physical-master-server-node1 physical-master-server-node2.xxx.com physical-master-server-node2

One "symptom" of an improperly configured nbcc-server-aliases file when running NBCCA is to look at the nbcc.txt file and note many "Dup" entries in the Media column.  Examination of the "Media Server (MediaDB)" column on the far right will show which media servers have duplicate data.  This "often" implies that those two Media Servers may be the same physical system (either an alias or an app cluster).  If you examine the nbcc-bpmedialist-l and find the same entries listed twice for these systems, that is almost positive proof that these are the same physical system and that the nbcc-server-aliases file should be updated.  The nbcc-server-aliases file on the MASTER must be updated and the data should be recollected.

Once the nbcc-server-aliases file is correctly configured, tapes written by both the physical node and other hostnames on the same line in the nbcc-server-aliases file may still be reported as inconsistencies.  But if the assign times match, it is very likely that no repairs are needed, and no repairs are SUGGESTED by NBCCA.  However, this is yet another area where the results of the NBCCA should be reviewed before applying repairs, because if it is determined that the systems are not the same, this could imply either further modification of the nbcc-server-aliases file or the generation of some manual repairs as dictated by the individual system where this is encountered.  

It is also a good idea to review the nbcc-server-aliases file after NBCC has run to look for any entries that might have been noted as CONFLICT or NO.IP.ADDRESS.FOUND.  These should be fixed and the data should be recreated.  The CONFLICT will show up when the same name appears on more than one line (remember, each name can appear on ONE AND ONLY ONE line in the nbcc-server-aliases file).  

Lines with NO.IP.ADDRESS.FOUND means that the media server name does not resolve to an IP address.  This could be a media server that has been decommissioned, a media server from a different master server where that network is not reachable, or for other reasons.   If these media servers are not physically present, but there are images and/or other entries in the data, these are OK to leave in the nbcc-server-aliases file, but if the systems do exist, then the name resolution should be checked and these entries should be fixed and new data should be collected.
 

 




Legacy ID



323252


Article URL http://www.symantec.com/docs/TECH69741


Terms of use for this information are found in Legal Notices