I moved your last question up to the top, since I suppose that's
probably key (and I should have included that info in my initial
request).
On Wed, Dec 13, 2000 at 09:50:55PM -0500, John R. Jackson wrote:
> Just what is the fibre channel buying you, or, put another way, what
> is you're really trying to accomplish? I admit to a) not knowing much
> about fibre channel and b) not being much of a fan since the couple of
> times it's been used around here it was terrible.
(first attempt at explaining my goal)
I'm building a SAN, with a fibre channel connected raid head, and I want
to have the tape library connected directly to the fabric via fibre channel
(as opposed to having the tape library connected to a host which is then
connected to the fabric) to take advantage of fibre channel speeds.
Hopefully this would allow me to back up the disks (anywhere from 1 to
5 TB) _locally_ instead of over the ether network. I'm planning on
installing NFS servers (maybe 1 for every 500 Gigs in the SAN), and
don't want to have to modify my design if I discover that I really
need 1 NFS server for every 300 Gigs instead.
Hmm. Thinking out loud now, I guess I'm wondering what amanda does
if you have a locally attached tape device on every client, and the
amanda server just instructs every client to backup to the local
device. (But the amanda server keeps the index, right?) Can amanda
do this?
(second attempt at explaining my goal)
In other words, if I have 12 machines and 3 tape drives (and the
tape drives are visible from all twelve machines), I could probably
have three scripts starting at the same time, that each rsh into 1/3 of
the NFS servers and instruct it to dump to a specific (non-rewinding) tape
device.
However, if I do that, I won't get the advantage of amanda keeping
indexes for me and managing my tapes for me, and I'd also like to have
amanda manage the tape drives as well. (If I create a poor layout, and end
up with the four smallest backup sets in one of the scripts, and the four
largest backup sets in another, my backups will take longer than if
something (like amanda) can manage my tape drives for me.)
Argh. Something else entirely just occurred to me-- if I have a 500 GB
partition, amanda still doesn't split dumps across tapes, does it?
hrm. I _could_ get my filesystem partitions down to around 150 Gigs,
but that still would require compression to be used in order for the
filesystem dump to fit on one tape.
> The --with-index-server and --with-tape-server options only deal with
> amrecover. They have nothing to do with amdump reaching out to a client
> to back it up. That's controlled from the server side in the disklist
> file, which tells the server which clients to reach out to.
Right, but I'd want each client to use the tape drives that appear to
be locally attached devices, even though something (like the amanda server)
needs to manage contention for those tapes.
> My first shot at this (after I tested the reset problem -- a **lot**)
> would be to designate one to four machines as Amanda tape servers and
> have them either cooperate on picking a drive to use or just hard
> allocate them. Each server would back itself up. Then parcel out
> the rest of the machines as clients to the servers (remembering that a
> client may only talk to one server, i.e. you cannot give a few disks on
> a machine to one server and the rest to another).
Yes, I suppose this could work too. If I went with this method, I
believe that I can use LUN mapping/masking to ensure that each tape
drive can be seen only by one machine (and thus avoid the scsi reset
problem).
Thanks for reading and helping,
-ron
