Netbackup machine name or FQDN

This type of query has been answered before, for example here: https://www-secure.symantec.com/connect/forums/netbackup-installed-fqdn-or-simple-name. That was for BYO master server (not Appliance) but all the concerns are the same.

Having DNS resolve to both reduces issues you might run into, but then makes the strictness of using FQDN weaker.

Whichever you choose, whether using either FQDN or simple name, I would go for consistency.

 

Hi Tomer

I'm sorry but the above does not really answer my questions as it suggests both can be used.

I'm qualifying what has been used by Netbackup currently?

At the time of setup FQDN was configured.

machine name or FQDN as both are present.

Further to the the appliance is multihomed

one nic for management

remaining nics as a bonding

not forgeting 1 nic  for IPMI

therefore

setup would be

Tom.be.junos.com for backup traffic ip 10.52.233.92

Tom.junos.com for management ie java console ip 10.5.3.54

Netbackup creates machine name Tom

search order would is

junos.com   be.junos.com

DNS has records for

Tom.be.junos.com 10.52.233.92

Tom.junos.com 10.5.2.54

Now if Netbackup uses the FQDN for the backup traffic not a problem cigar time

Now if Netbackup uses the machine name Tom we have a problem

Tom appends to first

junos.com  problems be backup traffic will try and travel through the management nic

To make things more difficult

You can not ammend the search order ie take junos.com  as the front end nic on the client server also needs to use the search order as well as the backup nic.

What is the resolution and what name is been used???????????????

 

 

 

 

Hi Tomer
the above does not really provide any answers.

Reason As follows

Netbackup has already been setup with FQDN

However FQDN and machinename are present as explained above

Therefore what is been used by Netbackup? I need to qualify this and explain to Management and technical teams.

Ok let me explain a little bit further

1 nic has been used for management

other nics have been bonded to for backup traffic

tom.junos.com is used for management with ip 10.54.233.92

tom.be.junos.com is used by the bond for backup traffic ip 10.5.3.64

not to mention IPMI

DNS has a record for each.

Now the search order on the client server is

junos.com
be.junos.com

The search order is used by the client front end nic as well as the backup nic

Therefore if Netbackup is going to use the machine name TOM it will append it to junos.com first
Therefore traffic will divert via management nic which would be a serious problem.

So what is the solution?????

ok you mention "Having DNS resolve to both reduces issues you might run into, but then makes the strictness of using FQDN weaker"

how is this setup? details please?????

plus verify if netbackup will use the machine name or FQDN

As you can see if netbackup is using the machinename there are serious problems

I look forward to your response.

 

 

Tomer

from my understanding when setup Netbackup with FQDN it creates its own machinename what u need to do setup the connection with via using the alias name command. On the appliance u notice after completion off the install Netbackup will create a host file entry with short name. . Therefore I believe in essence netbackup uses the shortname as well the FQDN.  Therefore the problem lies at the client server end and the various search orders. I requested that the network team create a cname for short name and IP for backup Network. The network team do not want do as they say DNS is designed for short names unless Symantec suggest this. I have logged a call with with support with the Indian team however the first line team don't really understand the issue completely and refuse to pass over to the back line team. 

If search order and incorrect NIC are used, have looking into the Preferred Network setting? (for example described here: http://www.symantec.com/docs/HOWTO60779, and also referenced here with a specific problem and solution, which may not match your issue, but may also help explain some of the NetBackup behavior: http://www.symantec.com/docs/TECH197087)

Let me know if I'm misunderstanding the issue.

NavGee

It can use either short or FQDN as log as both resolve

If your DNS is setup correctly then there should be no problems (so ensure DNS resolves short and FQDN)

Generally names used within NetBackup tend to be short names as it just makes life easier and there is never a domain dependancy should the domain name have to change at any point in the future

So make sure DNS is all good and use short names everywhere

Hope this helps

 

Hi Mark this is the solution to the problem, however I do appricate your input as always. However the indian Symatec support team fail to understand problem. Please refer to the technote.

http://www.symantec.com/business/support/index?page=content&id=TECH179320

 

and it applies to appliances with code 2.5.3

 

 

Regards

 

 

 

 

 

I intend on applying the technote to resolve clientside deduplication failures with error 83.  I believe this will resolve the problem.

 

 

Regards

 

 

 

I am with you now - handy tech note - but it does apply to issues of client side de-dupe having issues It implies that as long as DNS can resolve both the short and FQDN there shouldn't really be an issue ... and also that it can be the appliance itself not resolving both I have never experienced such an issue but my process for configuring an appliance involves setting its proposed IP address against its short and FQDN in its own hosts file before i even start the appliances configuration.

Mark

all non client side deduplication backups work fine, all client side dedup backups fail due the reason explained in the Technote.  With large cloud based confgiurations different  name are used for different network interfaces for different functions that come with a BaaS model.  With reference to configuring an appliance during the installation in my experience if use a FQDN the installation will create a short name it self and create a entry in the host file for the short name with the IP used for the FDQN so you don't really have to create it manually. With reference to short name and FQDN names this can be resolved via alias names via the emm command. As the technotes explains and from my own understranding the its the PDDE that truncate the FQDN to short name.  The reslution is explained in the technote.  However here is senerio.

eth01 on the appliance for management  ie java  the FQDN strawberries.gardens.com ip 10.20.92.54

bond0 on the appliance for backup traffic FQDN of strawberries.be.gardens.com 10.5.90.52

Netbackup will create shortname strawberries

Therefore you will need to create an alias via nbemm for  strawberries to strawberries.be.com . As strawberries.be.com is routeable and backup traffic will travel the correct path.

So you need Java Console functionality therefore you create an alias name strawberries.com to shortname strawberries.  This will allow java to work and be able to browse the master server properties.

Create host file entry with FQDN and shortname to the IP for the backup traffic. (customer is not to happy with this)

AS DNS can only resolve FQDN

DNS search order for short name  strawberries is

garden.com,   be.garden.com

Configure you clients to use FQDN of appliance for backup traffic all backup work correctly to using media server deduplication.

When you using client side deduplication (design requirement) all backups fail with error 83.

I believe this is down to the client side deduplication using the short name which is not routable rather than FQDN, This has been confirmed by  Symantec Technote.

Therefore implemented the following

Create host file entry with FQDN and shortname to the IP for the backup traffic.

Would like to implement the recommeded change in the Technote.

After implementing Create host file entry with FQDN and shortname to the IP for the backup traffic.

some client side deduplication backups works others now fail with error 87.

 

Beginning to think this could be down to something else came across this

WorkerThreads value (line 52  - 5% of the way down the file).

The default is 64 but but should be 128 thinking might apply this when possible.