| > Will (DDs) mean that a "common" MIR will be used?
> or,
> Will it be more like any Director will be able to access
> any MIR?
I think we need to distinguish different parts of the MIR, cos there
are different answers for each:
Class data - initially this will still be stored on a per-system
basis, though some day in the future we may find a way to
store the information network-wide, yet still perform well
enough to make it usable by management modules
Instance data - this will still be stored using a Naming Service
(DNS or CDS initially). This is to ensure that there is a
common global view of the entities used by all directors.
[There are those that seem to think that a local MIR will
suffice - horsefeathers. If the configuration is large
enough to warrant distributed directors, then a real Name
Service is indicated!]
Historical data - this will still be stored on a per-domain basis.
However, we plan to arrange that the data will be accessible
from any MCC. Thus for all intents and purposes, the data
will appear to be globally available - you just need to know
the domain.
> Will a Director on some platform be able to cause a Management
> Module on some other platform to carry out a directive?
> or,
> Will this Director cause a Director on some other platform to
> have one of its MMs perform the directive?
The difference between the two cases is too subtle for me to
understand. However, if you look at the SRM (if you dare :-}) you'll
find a description of what we are doing in chapter 2. In the current
implementation, when one management module requests a service from
another management module, those modules need to reside on the same
machine. All that we are doing in v2 is to allow the MMs to reside on
different machines - and of course, we'll have to do the necessary
additional magic to ensure that the MMs know how to find each other :-)
> As an example, would I be able to configure my 4 platforms
> such that each one would be collecting historical data on
> individual groups of entities. Then at some interval export
> this data from each platform to a central platform for generating
> reports from the Rdb/SQL file(s).
Unless I'm missing something, you can do this today with v1.1.
You can use the historian on multiple MCC's each storing data into
their own Historical data store. Then later on you can export from
each MCC's store into a single relational database.
Now what you *will* be able to do with distributed MCC, is initiate the
exporting requests from a single machine.
> If Distributed Directors will mean something like this, then
> I'm not sure that the advantages of DECmcc using a namespace
> weigh a heavily.
I don't understand this comment. Perhaps in light of the above
information you could restate your concern?
Colin
|