ok, so slow (10/100) clients will be backed up over the main network, so
they will not have a 10.1.2 NIC, that part's easy.
the policy lists the production hostname of the client, and the client
has the production network (10.1.1) hostnames of the master/media
servers.
with the clients connected to both networks, you will need two
hostnames. a hostname for the frontside (production) connection, and a
second hostname for the backup connection.
your backup policies will need to list the "backup" network hostname,
otherwise the backup request will go over the production network. The
bp.conf of the clients should only have the backup network hostnames of
the master/media servers.....that way they will ignore (fail status 59)
any attempted backup request that comes from the 10.1.1 interface of the
backup servers.
you will also have to make sure that each client has its netmasks and
routes configured properly to avoid asymetrical routing, where data
comes in one NIC, and the reply goes out via the other.
would be a good idea to make sure the 10.1.1 and 10.1.2 networks do not
converge at a switch/router, all servers and clients attached to both
networks have routing disabled, and none of the routers on your network
have a route from 10.1.1 to 10.1.2
If a server has multiple connections to a given subnet, you'll want
either something like Sun's IP Multipath, to ensure that outbound
traffic is load balanced over the multiple NICs..... or trunking, to
turn the multiple NICs into one virtual....otherwise, you'll probably
see one interface being used much more than the other....cuz remember,
your incoming data will be coming back on the same interface that the
outgoing backup request went out on.....so you outgoing data needs to
load balance...(spread backup jobs over the two NICs.)
IP Multipathing is very easy to set up, and doesn't require a license or
PS, which I believe is required by Sun for trunking.
Paul
--
-----Original Message-----
From: Martin, Jonathan (Contractor)
[mailto:JMARTI05 at intersil.com]
Sent: September 11, 2006 4:24 PM
To: Paul Keating; veritas-bu at mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Multiple-Nics
More bandwidth on the same subnet. But to some point to keep
data off routers. I've got a dedicated 10/100/1000 Cisco 3750 at my
disposal, so I'm going to "max" it out, by passing bottlenecks
associated with the rest of the infrastructure's multiple switches
connected via (slow) 2Gb fiber connections. I can't run 45 1Gb backups
across 3 x 1Gb connected media servers, so I'm going to (at least) run 2
Gigabit nics per Media Server if not more. I was thinking more along
the lines of 8 or 9, but I'm using dual nics and I don't think I can
trunk 3 nics from two different manufacturers (integrated vs,
expansion.) Further, I'm not convinces that trunking is actually going
to give me faster backups.
My NBU Domain will look more like...
10.1.1.x Master 10.1.2.x, 10.1.2.x
10.1.1.x Media 10.1.2.x, 10.1.2.x
10.1.1.x Media 10.1.2.x, 10.1.2.x
Most clients will simply be slower 10/100 connected to the
10.1.1.x. However anything with 50+GB of data will be on BOTH the
10.1.1.x AND the 10.1.2.x. Right now nothing has more than one nic in
the "backend" (10.1.2.x for this example.) Which server writes where is
heavily controlled by hosts files, which is a method I intend to
improve. Hrm...
-Jonathan
_____
From: Paul Keating [mailto:pkeating at bank-banque-canada.ca]
Sent: Monday, September 11, 2006 3:58 PM
To: Martin, Jonathan (Contractor);
veritas-bu at mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] Multiple-Nics
servers should talk to each other via the "main" interfaces,
hopefully, if your networks and routing are configured properly.
ie, if your STU specifies "backup2" as the media server, then
the master will talk to it via the interface named "media2"
How the master server decides which of its interfaces to talk
out of is more complicated if there are more than one interface on a
given subnet, and they're not trunked....could cause some "unexpected
issues".
the clients will talk back to whatever interface a connection is
requested from.
f'rinstance.....backup1 has 4 interfaces....
for example:
backup1 (IP1) - 192.168.1.10/24
backup1-neta (IP2) 192.168.2.10/24
backup1-netb (IP3) 192.168.3.10/24
backup1-netc (IP4) 192.168.4.10/24
A backup of a client is attempted, and that client has an IP of
192.168.3.16
The media server will select the interface connected to the
proper subnet which is "backup1-netb" and "talk out that interface to
the client.
The client will see an incoming connection from 192.168.3.10,
perform a reverse DNS lookup and determine the name to be
"backup1-netb". It will check it's bp.conf file for that name....if it
doesn't find it, the job will fail with a status 59, if it DOES find it,
it will start to transmit backup data back to 192.168.3.10.
Even if the media server has multiple interfaces on a subnet, it
will pick one to use, and talk to the client via that interface, the
client will still reply back to the interface that queried it.
couple questions for you.....what is the purpose of the extra
connections? to have a foot on multiple VLANs to keep backup traffic off
of routers? so each interface is a difference subnet? in which case you
really want to make sure you have routing disabled on the media
servers......or just for more bandwidth on a given subnet? in which case
you should probably be using some sort of trunking/multipathing/teaming,
etc.
Paul
--
-----Original Message-----
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Martin,
Jonathan (Contractor)
Sent: September 11, 2006 3:43 PM
To: veritas-bu at mailman.eng.auburn.edu
Subject: [Veritas-bu] Multiple-Nics
Ok... so three new media servers with 4 nics each are
headed my way in the next few weeks. That's 12 interfaces I've got to
worry about! According to the NBU Performance Planning & Tuning Guide I
should create DNS entries for each interface, and add all interfaces to
each server's bp.conf (or registry in windows.) I'm going to get all
these values setup and ready to go before the hardware even arrives.
backup1 (IP1)
backup1-neta (IP2)
backup1-netb (IP3)
backup1-netc (IP4)
backup2 (IP1)
backup2-neta (IP2)
backup2-netb (IP3)
backup2-netc (IP4)
backup3 (IP1)
backup3-neta (IP2)
backup3-netb (IP3)
backup3-netc (IP4)
So the servers will all talk to each other across the
various nics (by looking up the server name) but how do clients know
which IP to use? Many of those IPs are going to be on a non-routed
"backend" network, which several clients will not have access to. How
does the Master / Media server know which nic to use to communicate with
the client? Further, how do I tell my jobs which IP to use?! For
example, if I have 6 nics on 3 servers in the "back end" will NBU
automatically local balance between them? Perhaps I should enable
teaming? Any input on how this done properly would be appreciated.
Unfortunately the HOSTS file lookup method we use now is unacceptable
(and dumb) so I'll have to make this work properly.
-Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20060912/9f24c1c6/attachment-0001.html
-------------- next part --------------
====================================================================================
La version fran?aise suit le texte anglais.
------------------------------------------------------------------------------------
This email may contain privileged and/or confidential information, and the Bank
of
Canada does not waive any related rights. Any distribution, use, or copying of
this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately
from
your system and notify the sender promptly by email that you have done so.
------------------------------------------------------------------------------------
Le pr?sent courriel peut contenir de l'information privil?gi?e ou
confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute
diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires d?sign?s est interdite Si vous
recevez
ce courriel par erreur, veuillez le supprimer imm?diatement et envoyer sans
d?lai ?
l'exp?diteur un message ?lectronique pour l'aviser que vous avez ?limin? de
votre
ordinateur toute copie du courriel re?u.
|
