| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
A customer I work with on mcc(RISC/ULTRIX) is planning how they are going to
configure systems to manage their telecom network later this year. The
plans at the moment are to have two systems at each regional site, one
running TeMIP/mcc for management, and the other mcc for performance
management/monitoring. They are looking at failover capabilities and
Watchdog for ULTRIX in particular. Given that failover can be managed
by Watchdog (separate issue really) is it possible to run two completely
separate MCC implementations on one system ? This would run purely as a
failover scenario when one of the two system has crashed, in normal
operation each system would run it's own implementation. Disks etc.
wuld be switched across to the other system, so data would still be
available. Is it just a case of setting environemnt variables etc. to
look at different MIR's/namespaces and running it or is there much more
involved ? Also, would this be a supported config ?
As a follow-on, if this can be done, what effect would an mcc_kill
have, would it kill both mcc implementations or just the one which that
user had been running ? I get the sneaky suspicion it would be both !?
FWIW, I reckon this may be possible and may give it a bash on a local
system next week. Any advice and guidance or general reactions would be
more than welcome.
Regards,
Euan
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 4392.1 | Might be possible | TOOK::MINTZ | Erik Mintz | Fri Jan 15 1993 07:29 | 12 |
It is possible to run two compies of DECmcc on a system, although the ability was designed mostly for development and testing. How much isolation do you need between the two system? That is can they share anything (executables, repository files, configuration?) mcc_kill by default kills only management modules running under the same UID as the process issuing the command. So modules started by a different user are unaffected. "mcc_kill ALL" kills all management modules, but may only be issued by root. -- Erik | |||||
| 4392.2 | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Fri Jan 15 1993 08:05 | 24 | |
You need to define "totally separate copies of MCC" better. As Erik
mentioned, all distinct UIDs get seperate copies of all management
modules run for them anyway, so in some sense you are getting a
separate copies of executables.
Separate copies of read-only data (directories /usr/mcc/mcc_system
and /usr/mcc/mmexe) would be required only if the two MCCs are
different versions.
Per-user read-write data such as map files can be separated by having
distinct users of the two versions, as above.
Per-domain read-write data such as historical repositories can be
separated by ensuring that users of the two versions do not share
domains.
Per-system read-write data, such as the instance and alarm rule
repositories can be directed to different directories via environmental
variables but be warned that not a lot of use has been made of the
product in this mode.
For planning information, in the future we intend to more carefully
define what "an instance of MCC" means so that things like what you
want to do are much more straightforward....
| |||||
| 4392.3 | Lots of things to watch out for. | FARMS::LYONS | Ahh, but fortunately, I have the key to escape reality. | Fri Jan 15 1993 12:09 | 15 |
The current MCC demo package does exactly this, only on VMS. Setting up the same type of environment on Ultrix cant be very difficult. We thought about building the DEMO package for Ultrix, but never got the time to actually put the kit together. It was not an Issue of how to do this, only one of building the Ultrix installation files. You can choose to seperate data on many different splits, the demo package had complete seperate repositories, but shared all of the ICON, Dictionary, Command procedures, etc. The only complaint was that it took twice the system resources, and hence was very slow. If you are thinking of doing this on ultrix, Plan for LOTS of swapspace (like 300 meg), and lots of memory on the system (like 128 meg). Also, there are a number of system resources that MCC makes demands on (e.g. SEM*, max_nofiles, etc.) that you may have to bump up. | |||||
| 4392.4 | An afterthought | FARMS::LYONS | Ahh, but fortunately, I have the key to escape reality. | Fri Jan 15 1993 12:10 | 5 |
Event Processing could get real interesting. Maybe someone for MCC land could think about the sharing of event sources in this type of environment. The Demo package used the data collector, so that was no big deal. | |||||