Conference azur::mcc

    Bruno, I need a better definition of distributed MCC than you have
    given. Could you respond with a description of what you mean.
    
    We in MCC have many different views of distribution. There is the
    distribution achieved by having multiple users working from independent
    workstations using set host to a central management station. This
    exists today. There is multiple users all having their own copy
    of MCC on their workstation all using common domains definitions, etc.
    This also exists today. There is the classic view of multiple
    instances of MCC in a hierarchal arrangement sharing data via
    data links. Some of this exists today and some of it doesn't. It
    depends upon the configuration. Another view is to have the AMs
    distributed to different geographically dispersed processors. This
    has not been implemented yet. The most general view is to have all
    MMs distributed to different geograhically dispersed processors.
    This does not exist yet. DECmcc is currently working on distributing
    AMs. It is at the prototyping stage only.
    
    Please provide more details on how you propose to have the
    approximately
    18 systems interact. What files do you expect them to share and what
    files will be maintained seperately by each and how do you propose
    to do the file sharing (ie. with file servers). Then maybe we can
    take a crack at it from a theoretical perspective.
    
    I looked at your 3 options. I have significant experience (before
    DEC) with management systems which use 9600 baud links for both
    management and shared management interaction. I have a strong 
    prejudice that 9600 is totally inadequate for shared management
    interaction except for the most trivial kind. With any reasonable
    set of monitored devices, the event stream alone can use multiple
    9600 baud links. I believe your 56k baud link to be the lower
    boundary for what should be considered reasonable.
    
    wally matthews
    

Re: .1

>I have a strong prejudice that 9600 is totally inadequate for shared
management
>interaction except for the most trivial kind.

That depends upon whether you can "concentrate" the information
exchanged with the remote director.  Applying that old principle of
"distributed processing", i.e. doing as much computation as possible at
a place as close as possible to the source of the data, it makes sense
to gather and process/concentrate the event stream on a director that
is on the same LAN, or otherwise close to, a set of managed entities. 

This raises the question of whether such concentration can be done by a
local system without much interaction with the remote (central)
director, e.g. looking up configuration information or synchronizing
state information.

Note that I use the term "concentrate" instead of "correlate" because I
still haven't seen a definition.  I have an intuitive notion that it
accomplishes data reduction, but I'd sure like to understand the
theoretical issues involved.

	- Andy

Wally,

although you already know part of the context of my question, we will fully
explain it for the benefit of everyone else.

Here in Rome, we are delivering a NMP (Network Management Planning) consulting
service to SIP (the Italian telephone company); as a result of the service, we
will recommend solutions for managing (at system and network level, not at
application level) their Digital systems and peripheral devices used, in turn,
to manage the components of the Italian public telephone and various data
networks.

The Requirement Analysis phase will soon be completed; we will then define and
evaluate various solution scenarios from a technical, organizational and
economic point of view. As a matter of fact, our customer does not have
specific functional requirements and expects us to help him define what
functions should be implemented (most Digital systems in SIP are new and not
yet in full operation); for now we can assume that the customer's requirements
are the "typical" requirements of a "typical" Digital configuration. What is
specific about our customer is the particular quantity and distribution of the
Digital systems, and the way they are or could be interconnected.

Infact, we have two levels of distribution:

-- national level (3 building complexes in Rome)
-- regional level (2 building complexes in each of 18 regions)

There are 110 "systems" distributed over the 18 regions, and 20 in the
headquarters.

The typical "system" includes:

-- a dedicated Ethernet LAN
-- 2 VAX hosts (in a cluster)
-- 0 to 2 VAXstations
-- 1 to 10 terminal servers
-- 1 DEMSA (X25 router and/or SNA Gateway) or ISDN router
-- a number of non Digital devices seen as Ethernet stations (0 to 20)
-- 0 to 15 PCs with Pathworks on Ethernet
-- (total number of Ethernet stations: 10 to 100)
-- 10 to 120 communication ports (on either terminal servers, VAXes or DEMSAs,
   including synchronous and asynchronous, with and without modem control)
-- 10 to 200 remote links to other systems (including X25, SNA, asynchronous,
   ISDN)
-- (possibly) 1 LAN Bridge or TransLAN to link the dedicated LAN to other LAN
   segments in the same urban area

Some of these are or could be interconnected in different ways, such as:

-- X25 public network (accessed at 9600 bps)
-- leased lines (9600 to 64k bps)
-- common LAN (through a LAN bridge or TransLAN)

We would like to use DECmcc as the platform for our solutions for obvious
reasons, not to mention the fact that our customer wishes so (in fact he is
considering using DECmcc, at a later stage, to manage non Digital entities,
which will possibly lead to the develpoment of custom DECmcc modules; however
this aspect is not covered by the present consultancy).

The first solution scenario we are considering is one where we would have:

-- one DECmcc in each region plus one at the headquarters (total of 19 units)
   to manage the Digital systems located in the relevant urban area (one or more
   buildings in each area); we can call these DECmcc's "regional DECmcc"

-- one DECmcc at the headquarters, for a higher level management of all the
   systems and the other DECmcc's; we can call this DECmcc "national DECmcc"

Each regional DECmcc should be connected with the national DECmcc; we have no
constraint, for now, as to the type of link or network to be used; it could be
one of the following: 

-- X25 public network (accessed at 9600 bps)
-- leased lines (9600 to 64k bps)
-- common LAN or MAN (through a LAN bridge or TransLAN) only for systems
   located in the same urban area

We can assume that the regional DECmcc will provide all the functions to
manage the "local" environment in a comprehensive manner and independently of
the national DECmcc.

As to the national DECmcc, this should be used (inasmuch as feasible) for:

-- replacing the function of a regional DECmcc (when the latter is not manned):
   possibly with the same iconic presentation interface, otherwise we could
   use the Forms or Command Line interface after having accessed the remote
   DECmcc via SET HOST, but of course it would not be as nice)
-- collecting regional performance data, and producing consolidated performance
   reports at national level (systems and lines availability, line utilisation
   and error rate, CPU utilization and error rate, memory errors, disk
   occupancy and errors)
-- receiving a selection of the alarms generated by the regional DECmcc (to make
   sure that problems are solved within a given amount of time; otherwise
   special alarms would be generated by the national DECmcc)
-- issuing alarms when any DECmcc becomes unavailable or saturated

We think that one way of achieving the above could be to interconnect the
access modules resident in the regional DECmccs with the presentation (and
possibly functional) modules resident in the national DECmcc (what you have
called "distributed AMs"). Otherwise we could possibly develop custom software
to obtain a similar result.

This is the context to which our question in *.o applies.

Besides what you have already said in *.1, we would appreciate any additional
comments and/or suggestions, from anybody.

Thanks for your interest in our problem; we think it may be of interest for many
other prospects, and would like to know if there is anybody else working on
similar contexts.

Best regards,

Bruno Cancellieri and Massimo Sforza

Re: .3:

>... we could use the Forms or Command Line interface after having accessed
>the remote DECmcc via SET HOST, but of course it would not be as nice)

In the North Central US, we regularly demonstrate DECmcc using a
Chicago-based system from remote offices across Easynet using X. 
You'll need at least 56 Kbps of bandwidth to make this practical.

	- Andy

Thank you Andy,

in fact I hadn't thought of doing SET HOST from an X-window terminal (a VT1300
or a terminal window of the national DECmcc, in conjunction with the
SET/DISPLAY command). This could be a good temporary solution until the
director to director dialogue functionality is released.

If the performance is acceptable (using a 64 kbps link) this would fulfill
the requirement of "taking over" the regional DECmccs (one at a time) from a
central site, for trouble shooting or reconfiguration purposes.

However, it would not fulfill the alarm filtering and forwording requirement
(from the regional DECmcc's to the central one).

Can anybody suggest a way of achieving the alarm filtering/forwarding function
before it is officially released as part of one of the next DECmcc releases?

By the way, can anyone give me a realistic date for such possible release?

Ciao
bruno

RE.3

>-- replacing the function of a regional DECmcc (when the latter is not manned):
>   possibly with the same iconic presentation interface, otherwise we could
>   use the Forms or Command Line interface after having accessed the remote
>   DECmcc via SET HOST, but of course it would not be as nice)

SET DISPLAY /CREATE /NODE=nodename works fine when the two nodes are connected
by Ethernet. If you use 64Kbps lines instead your bandwidth is down by a 
factor of 150 or so. Check carfully what your response time will be. 

ANDY - Can you give us some figures? (i.e. how long it takes to open a domain
       with its background map? How long it take to do SHOW something?)

>-- collecting regional performance data, and producing consolidated performance
>   reports at national level (systems and lines availability, line utilisation
>   and error rate, CPU utilization and error rate, memory errors, disk
>   occupancy and errors)

Reports - DECmcc is not very strong in producing reports (understatement). 
Look for better tools for reports.

CPU utilization, memory errors, disk occupancy - To my knowledge DECmcc
does not look at this information. You must develop new Access Module for
this.

>-- receiving a selection of the alarms generated by the regional DECmcc (to make
>   sure that problems are solved within a given amount of time; otherwise
>   special alarms would be generated by the national DECmcc)
>-- issuing alarms when any DECmcc becomes unavailable or saturated
>

May be you can achieve this in the following manner:
1. Create alarm rules in the regional DECmcc.
2. When alarm rule fires it sends mail to the NATIONAL system.
3. The mail is used as a basis for tracking the status of the problems.
There is a note in this file discussing "Trouble Ticketing". They mention
a third party product called "TARGET->HOTLINE" which can create trouble
tickets based on mail messages. 

Peretz Gur-El

    When considering distributed management, the MSU model should be taken
    into account.  It's an example of a different style of distribution,
    but now has several years of experience. That experience should be looked 
    at to see what works and what doesn't.  MSU was designed to operate as 
    a remote management system, for the Colorado Springs support facility to 
    be able to manage customer's IP (and now DECnet-IV, bridge/fddi, and
    terminal server) network.  The MSU 'registration daemon' or kernel, 
    goes at the customer site, and Colorado Springs connects in via the remote 
    map feature (many map users can access the 'reg-d').  Thru use of mostly 
    the distributed database features (Ingress-net) - the status of network
    devices is updated to the remote map.  The link is typically a slow
    9.6KBS SLIP link so no X-window applications can be expected to run
    over that link.  The Colorado Spring map application has the same look
    and feel of a local MSU (except some 'launched' applications don't work).  
    There are also distributed polling daemons, allowing the actual polling
    of SNMP and DECnet-IV devices to occur on a remote LAN, and then use
    the INGRESS-NET features to report availability changes or polled data
    back to the central registration daemon.  
    
    I'm sure there are problems, but those using it in CS know what they
    need.  Lack of distribution is the primary reason given by the service 
    folks for not adopting MCC/ULTRIX V1.2 as their FY93 business solution.
    Whatever MCC does for Distribution doesn't have to emulate MSU, but
    should solve the business problem that Colorado Springs is trying to 
    solve.  Many customers see the same problem, in trying to manage remote
    LANs by placing tools there and accessing them via bandwidth efficient
    means.
    
    bill

Distribution of directors (and entities) is obviously an important issue. 
You can learn more about the architectural direction the EMA Architecture 
group is developing by reading the V2 Director Model draft (which covers 
distributed dispatch of operations) and by reading the Overview of Events
and Notifications White Paper (which covers distribution of notifications, 
i.e. event reports).

I think everything asked for so far in this topic is covered in those papers
although it might take a little effort to see exactly how :-).

		Mark

    Concerning SIP customer, do you have requirements to monitor their
    systems in the area of CPU, peripherals, applications...?
    This can be achieved by DCM (Data Center Monitor) on VMS or Ultrix
    nodes and soon on SunOS.
    It can complement DECmcc and we may consider developping an access
    module to DCM thus providing a comprehensive monitoring of both Network
    and Systems problems from DECmcc.
    

    >CPU utilisation, memory problems, disk occupancy
    
    You do not need to develop anything to perform that. Use instead DCM : Data Center
    Monitor. It is DCM purpose to monitor events at system level, process
    level, network level (reachability), external level (user-defined
    procedures).
    DCM can monitor both VMS and Ultrix systems and will work soon on SunOS.
    Now if you need DCM to be integrated under DECmcc please contact us:
    
    

    What is needed is the ability to access the system/application type
    info from mcc - so alarming, historian, etc can be accomplished.
    
    bill

 > What is needed is the ability to access the system/application type
 >  info from mcc - so alarming, historian, etc can be accomplished.

We will start working on this issue next month and consider doing a prototype 
to understand the feasability
    

Thanks Laurent,

in fact I wanted to ask this audience whether there is any kind of integration
between DECmcc and DCM now or planned (or whether a "system" managemnt AM for
DECmcc is being developed and when is going to be released). 

I also know of ENOP, which provides (among other things) system mgt alarming on
an iconic map; an ENOP AM should be available by now.

Any suggestion as to the best strategy is welcome. The alternative strategies
can be summarized as follows:

-- use DCM as it is now, without integrating it with DECmcc (until the system
   mgt AM is released)                                       
-- develop a DCM AM
-- use ENOP as it is now, without integrating it with DECmcc (until the system
   mgt AM is released)                                       
-- use ENOP with the DECmcc/ENOP AM

Ciao
bruno

Bruno,

ENOP AM has been in FT since September. The FT is limited to a selected number
of customers. 

What ENOP AM offers you is the ability to manage thru DECmcc the entity Member
(i.e. Computer System), with its lines, interfaces, disks, tapes,queues and any 
user-defined device called MEP (Monitoring Entry Point) you want to add to it.
That means you can define very quickly agents (monitoring only) for your 
entities and have them being managed by DECmcc

Whether you want to propose ENOP alone or DECmcc + ENOP AM depends on the
functions you need and the strategy you want to follow.  
    
Best regards,

Marc.

I'm not sure how this note got here, but system management is obviously
important. 

The long term strategy is to make our operating systems be EMA entities,
(children of the node entity) implemented on the common agent which is
built into every operating system. When that's done, you won't need 
anything but the plain old Phase V AM (which comes for free) to do
system management of those nodes. We also recommend that applications
that have to be managed should build a common agent MOM so they
can be managed in the same way

This is well under way for VMS and OSF/1
operating systems. So if you have any entities, attributes, actions, or events
that you think ought to be supported by the operating system (beyond the
obvious stuff like disks and tapes and printers and queues and jobs and ...)
you probably ought to let the people in the O/S know. In the EMA Architecture 
group, Owen Tallman and I have been watching the various entities and O/Ss.

Mark