Right now my site uses HOST names, but with our new servers' I'm going
100% DNS.  I've tested this in ONE case right now and it has worked
100%.  It is how I am going to configure all my new backup servers and
clients.  We've got about 120 clients, 40 of so have high-speed
"backend" 1GB Nics.
 
1 - Add a "connection specific" DNS Suffix to the "Backend" (Backup
Network) connection.  That is backup.company.com.  Make sure you have
PRT (reverse DNS) records for these IPS, especially for the Media
servers.
 
2 - Configure your media servers to query DNS in a specific order
STARTING with backup.company.com followed by company.com
site.company.com etc...
 
When your media server looks up a client it will query
client.backup.company.com, and use that IP if returned.  If that query
DOES NOT return a valid IP it will continue querying company.com etc
until it finds a valid HOST entry in DNS.  I've tested this in ONE case
with our current setup and it seems to work GREAT.  It alleviates me
adding -backup entries to my client configs, adding host file entries to
direct traffic and generally is the "cleanest" way I can come up with to
configure multiple backup networks.  You could just implement step
number 1 and then use client.backup.company.com in your policies, but
we're not using FQDNs right now so I'm avoiding them like the plague.
 
The only problem I can see with this method is verifying that the backup
policy uses the backend connection.  I.E. if the DNS query of
client.backup.company.com fails then it will continue the DNS queries
and fine the client.company.com DNS entry and try backing up over the
"front end."  That's not a huge problem for me right now, because my DNS
is rock steady and backing up over the backend isn't exactly mission
critical, but to be extra careful you could add the "required interface"
option to your clients which is an extra step, but should make this
bullet-proof.
 
-Jonathan

________________________________

From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Hillman,
Eric
Sent: Wednesday, September 27, 2006 2:38 PM
To: veritas-bu at mailman.eng.auburn.edu
Subject: [Veritas-bu] Client Hostnames



We have public and backup networks.  All clients have a public network
which is typically 100Mb and some clients (larger clients) have a backup
network which is typically GbE.  This seems to be pretty typical in
larger organizations.  

Given the above scenarios, my question is... in Netbackup what do you
name your clients with backup nic's?  

Option #1: Add a dns entry of the client name with a "-backup" suffix
and assign it's backup ip.  Do the same with the Master/Media server and
add their -backup hostnames as additional servers from within the
netbackup client software

Option #2: Instead of using dns, simply add the -backup hostname client
alias to the local hosts file on the Netbackup Master/Media servers and
assign the backup ip.  Do the same with the Master/Media server and add
their -backup hostnames as additional servers from within the netbackup
client software

Option #3: Simply override the actual client's hostname IP with it's
backup ip by adding it to the local hosts file on the Netbackup
Master/Media server.  Do the same with the Master/Media server in the
client's hosts file and leave the non -backup hostnames as servers in
the netbackup client software.  This alternate method would overwrite
the DNS record of the actual client and Master/Media hostnames with the
hosts backup IP.  

Also, is it best practice to use FQDN's, or no? 

Thanks 
-Eric 


THE INFORMATION CONTAINED IN THIS MESSAGE AND ANY ATTACHMENT MAY BE
PRIVILEGED, CONFIDENTIAL, PROPRIETARY OR OTHERWISE PROTECTED FROM
DISCLOSURE. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you
have received this message in error, please notify us immediately by
replying to the message and permanently delete it from your computer and
destroy any printout thereof.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20060927/7a5c6ebd/attachment.html