CLAYTON@xrt.upenn.EDU ("Clayton, Paul D.") (07/09/87)
Information From TSO Financial - The Saga Continues... Chapter 8 - July 8, 1987 Todd Warnock asks the following questions. If the uVAX that manages the console system can also run other things ? If the uVAX can act as the console for non-clustered machines ? What problems are there of doing either of the above ? What problems, if any, are there with the console system ? (any "GOTCHAs" ?) I have just gone through the process of researching the VCS and getting the order for ours to DEC, so I will state the conclusions that I have come to. >>If the uVAX that manages the console system can also run other things ? The MVAX can do other things up to a point. The point is somewhat fuzzy and moves around. The system we are having we not only support the VCS system but also the Ethernim, Lan Traffic Monitor (LTM) and Terminal Server Manager (TSM). It will also server as a load host for terminal servers and have the personal accounts for the about 4 people. The big problem is that the data collection done by VCS is performed in 'real time'. For a large VCS, the latest version supports up to 20+ nodes, the 'real time' portion could be substantial and thereby leave a small portion left for other things. >>If the uVAX can act as the console for non-clustered machines ? The VCS system in both the first and the new updated releases, can support both VAXClsuter and standalone systems. It makes no difference to the VCS system for data collection purposes where or what type the systems are. The consideration has to be given only when a user looks at the log files and instructs VCS to 'combine' multiple systems log files into one for cross checking purposes. Each system is date/time stamped seperately. The first version of VCS only provided fiber optic links from the systems to the MVAX to eliminate possible ground loops. The latest version of VCS will support the collection of log files from 'remote' systems that are sending back data over the Ethernet. I am planning to hook in the HSC systems, and am toying with the remote links, but only if the comm group at work can get the redundancy and failover to work correctly. >>What problems are there of doing either of the above ? The problem with remote tie ins is when the network goes down so does the console for the system. This could cause problems for the remote system if a considerable number of OPCOM messages are generated. >>What problems, if any, are there with the console system ? (any "GOTCHAs" ?) On the 85/87/88 systems, the PRO console STAYS, and is used as the boot device for the system. The VCS system ties into a port on the back of the PRO. The 7XX systems can shed their consoles. I am also planning to have the VCS MVAX on a seperate Ethernet network that has terminal servers connected to it. The reason for this is if the MAIN network goes down for any reason then the VCS system can stay up, and thereby all the systems also. I am also running two terminal connections from the TX ports that are on ALL the systems, even the 8XXX's, into terminal servers and setting the ports up so that I can 'CONNECT' to them and become a standard user. The reason for this is if the MAIN Ethernet network goes down, or there is a problem in the Ethernet controller in the system, I can still get into the system on a CRT to look around and edit files on something other then an LA120. Hope this helps... Paul D. Clayton - Manager Of Systems TSO Financial - Horsham, Pa. USA Address - CLAYTON%XRT@CIS.UPENN.EDU