> > Hi, > > 22.09.2009 21:32, Blake Dunlap wrote: > >> Hmm... that's not what I intended originally (though, as I'm not > >> working on it myself, I won't object if somebody else does it > >> differently). > >> > >> A volume that is actually written is by definition in a Location > >> with cost=0; the default would be LocationId=0. Everything else > >> does, IMO, not make sense. > >> > >> If you unload that volume, you'd mark it to be in a different > >> location. > >> > >> Arno > > > > My reasoning for the above is SDs in multiple datacenters. I > > definitely see the usefulness for locations to not be assumed to be > > local until removed. You can use this along with pools to set up > > offsite pools for other locations etc and have a nice automated > > tier system of capabilities spanning multiple sites. > > Ok, now I see what you're aiming at - my original concept doesn't > allow that easily, though. We'd need a concept of locations for SDs, > too, which wouldn't be too hard (i.e., in the SD conf, per device, we > might have an optional "Location = whatever" setting. > > A volume used by that device would then be assigned the defined > location. > > Only the cost concept needs refinement - a volume in data center A is > available at low cost there, while cost for transport to data center B > would be high... from a database PoV this is simple, though it needs a > catalog change (which is one of the starting points of this > discussion...) > > Imagine table Location: > LocationId > Name > CostId <= Changed > Enabled > > Add table Cost: > CostId <= NOT unique! > ForLocation > Cost > > Now you could have those Locations: > 1 "DC A" 1 > 2 "DC B" 2 > 3 "storage" 3 > > and Cost > 1 1 0 > 1 2 50 > 1 3 30 > 2 1 50 > 2 2 0 > 2 3 30 > 3 1 30 > 3 2 30 > 3 3 0 > > What I tried to model - and it's likely this can be done better - is > that a volume in Location 3 (called storage) can be moved at cost 30 > to DC A and DC B. A volume in DC A can be moved at cost 50 to DC B, > and so on. A bit more complex than the existing concept, but it allows > to model several paths of volumes through an organization. It would > also allow to disable paths by assigning infinite (or -1) costs... say > we never want volumes to go from DC A to DC B directly, and vice versa: > > 1 2 -1 > 2 1 -1 > > Hmm... I'll need to paint a picture :-) > > I get interested in this stuff again... > > Arno >
Well I had a long complicated example set up, but outlook decided to crash. Anyway, I would like to see the concept of an SD having a location, but not for the reasons above so much as the SDs determining what volumes could be writable in a pool instead of resorting to the method now of having different media types for every distinct device you want to have its own pool of interchangable storage volumes. The above could be done simply with extra pools and locations specifically for handling the offsite work of other areas. Theres nothing to say that a single SD could have direct access to more than one "location", and it would remove the need for a complicated site routing matrix, and the associated logic behind it. Though with a SD having a specific location, pools / mediatypes could then cross sites, and location could take over for determining what is available where. But you would then indeed need a metatable that contained all the different site interactions possible, and their relative costs. (I would make this manual however, as you run into serious scalability issues as your mesh grows) At this point, theres several directions that this could go, it just comes down to what overall conceptual design is wished for at the end, as to which option would be best. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
