| The first two concepts are what we call Domain Distribution. The third
concept is called Entity Distribution. We are weighting these now with
respect to how important they are compared to other features and
requests asked for by customers as well as third party vendors. You
should let Gail know that these are important to you.
One other distribution concept that we are evaluating is the
Client/Server PM which essentially splits the Iconic Map in half, the
display portion runs as a client and the Notification/Color management
portion runs "forever" in the background as a server. Furthermore, you
can "Groupware" the Server portion by letting your "friends" attach to
it as clients. (Don't ask us for any more detail, because we probably
cannot provide any.)
It would be valuable to know what priority you (and other internal
users) would give to these three distribution concepts.
-Matt.
|
| re: .1 - Lets be a little realisitc - in the EMA GD - copyright 1989 - page 6-8
section 6.4 'With a set of correctly configured director components
, a computer sytsem can act as a standalone directory or interact
with other distributed directors' ... then that is explained with picutues
for the next 5 pages.
I know that an architecutre does not pormise product, but we have been
selling or trying to sell this sutff for 3 years and distibution is a basic function necessary
to managene anything more than a moderate sized network.
My immediate problem is how to scale MCC to manage a 1400 location
(2500+ end systems) WAN, with management
backup capablitily from two data centers. The systems (DECsytem 5000/240)
aren't large enough to do what is necessary for this type of network.
We will have to divide fault, and accounting/capacity planning at least, as well
as isolate by loations. I need a reliable way to keep the databases (MIRs)
in synch. I can live with just opening certain domains on differetn
workstations if I know that the databases are in synch.
The truly distributed director-director and fm-director functionality
would be nice. But we need something now.
My recomendations are
1) synchronize mir's so that an entity registered on one MCC system will get propogted
2) alarm notification as specified in .0
> an alarm on one mcc system can be sent to other MCC systems
> automatically, ie. without having to use mcc_evc_send, etc.
3) Easy ways to divide out fault, config, and accounting management across
multiple UNIX MCC's.
4) ALPHA-OSF support
... regards,
scott
|
| We are in the final stages of a proposal to a prime contractor. The "System"
will consist of a little over ONE-THOUSAND THREE-HUNDRED AlphaAXP workstations
and servers, FIVE Gigaswitches, between 70 and 90 TERABYETS of data storage, and
3 to 5 MASPAR systems
.
The "Customer" would like to run OSF and use Polycenter xxx tools to manage the
whole thing. Considering the uptime requirements, virtually everything
(including network management) needs to be distributed and redundant.
Distributed element management and synchronized "MIRS" seem necessary.
Regards,
Glen R.
|