On Wednesday 29 April 2009 11:58:15 James Harper wrote:
> > > Kern, is it possible to have more than one Storage Daemon running on
>
> a
>
> > > machine ?
> >
> > Yes, you can have as many as you want -- you just have to assign them
> > different ports. In general it is not necessary to have multiple
>
> storage
>
> > daemons on a single machine because a storage daemon can handle
>
> multiple
>
> > devices.
>
> On that subject, I have just set up 1 'device' per client so that I can
> run the different clients in parallel while having one media file per
> client. It works really really well and makes a huge difference to the
> run time of the backup. The one annoying feature of that is that 'status
> storage' command now prompts me to select one of 10 different Storages,
> but in the end they all just give me the same information as they are
> all the same sd.
What you are doing might be much easier using the disk-changer script with
multiple drives. As long as a Client has volumes in a unique Pool, each
client will have a different volume.
You might even be able to do the same thing with a "pure virtual" autochanger,
but I don't use that configuration much, and I think the documentation is
rather sketchy. The advantage of the pure virtual autochanger is that all
the Volumes would have the same name as seen in the catalog rather than
simply slot names.
>
> Have you ever considered separating the 'Storage' and the 'Device' out
> in the director config? The configuration would then look something
> like:
No, it is unlikely something that we will do because it violates the
separation of functionality principal. However, there is a Feature Request
to limit the number of simultaneous jobs per Device, which I think is a nice
idea. We have been working on ways to improve the information that the Dir
has about the Storage daemon devices so that more intelligent decisions can
be made.
>
> Storage {
> Name = name_of_server
> Address = hostname/IP address
> SDPort = 9103
> Password = shh_its_a_secret
> Maximum Concurrent Jobs = 7
> }
>
> Device {
> Name = name_of_device
> Storage = name_of_server
> Device = name_of_device_on_sd
> Media Type = media_type
> Maximum Concurrent Jobs = 1
> }
>
> Maximum Concurrent Jobs would be specified with a server and a device
> maximum, which would both be honoured by the director. Almost everything
> that mentions a 'Storage' would need to be changed to 'Device', although
> perhaps a 'Storage' would just be a synonym for 'Device' for backwards
> compatibility...
>
> How much pain would be involved in such a change? Am I the only one who
> finds the existing implementation annoying? (if so, I'll either submit a
> patch or never mention it again :)
I do admit that Storage might better have been called Device in the Director,
but I don't think that is the problem here.
I'm not considering such a change, so answering the above doesn't make much
sense. That said, I am always open to suggestion to ideas that simplify, add
new functionality, ... but that do not complicate or duplicate tasks done in
another daemon or result from not fully or correctly using the current
features.
We do need some better concept of what a Storage is in the Director --
currently it is not adequate, particularly concerning multiple autochangers
and MediaTypes and autochanger drive read/write characteristics so I am open
for suggestions.
Regards,
Kern
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
