Re: [foxboro] Remove autostart of legacy servers?
- From: Kevin FitzGerrell <fitzgerrell@xxxxxxxxxxxxxxx>
- To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 21 Mar 2006 09:52:35 +1200 (NZST)
Hi Dave,
Thanks for the response!
> "While this configuration follows the guidelines in the AIM* manuals,
> system
> definition doesn't support this type of configuration."
>
> The above statement is correct, however you can create a 70 series
> station in the system configuration, define the station with IP and
> historian, but do not attach it to the node. This allows complete
> configuration of the historian instance to be used and seen by the
> utilities in system definition to configure the historian access. System
> Definition will complain because the station is not monitored and on the
> node, but all other features work as normal. The remote collector server
> could be configured in this method.
>
I did look at doing this but still had problems with the workstations and AWs
not pointing to the legacy server. What I've done in sysdef is put AHIST6
(FoxHistory for Solaris) on P101AW value puhs01. All system monitors have
puhs01 as their Historian Database Name. After committing the workstations I've
gone through and adjusted /etc/histln, /etc/histnls and /etc/histlocs to contain
"puhs01", "puhs01", "puhs01 P101AW" on all the stations so the workstations can
find the legacy server.
> "I may be completely off-base about the windu registry. One of the
> Foxboro
> engineers who worked on my CAR originally mentioned that that was where
> the
> legacy server startup arguments were saved."
>
> The above statement is also correct, but the windu only points to the
> files ipname_for_r_servers and the TZ_for_r_servers which are created
> when a start_server RFH <IP or IPNAME> is run manually and the TZ
> argument is used. IF TZ is not used as an argument, then disregard the
> TZ_for_r_servers. AIM historian should only attempt to start the servers
> if something is starting the AIM historian. /usr/fox/bin/fox_apps.dat
> would have an entry AIMHISTORIAN which is the go_AIMHISTORIAN script in
> UNIX and in Windows would be AIMSTAR. For remote collections (histsend
> and histreceive) only require AIMAPI. AIMHISTORIAN does not need to be
> running on any workstation other than the workstation that hosts the
> historian server. Only one ipchisti can be running against any historian
> instance. The device monitor controls this as this process has access to
> the OM.
>
That's interesting. When I install the remote collector on the 4 AWs, the
install script puts both AIMAPI and AIMHISTORIAN scripts in. Both are run.
When histstart is run by the AIMHISTORIAN script it starts fetchdog, and on
P101AW and P401AW it also starts ipchisti and the legacy servers.
ipname_for_r_servers exists on P101AW, but not on P401AW.
> Questons:
> When the P4AW01 is rebooted and is running the servers is the process
> ipchisti also running?
Yes. I kill ipchisti and fetchdog after this workstation reboots.
> How is it that you have 7 segments connected without LAN interfaces?
I've got NCNIs in each segment connected to switches with a V7.1 blade
workstation. This is a supported configuration. Previously this system had 4
nodes, CLANs and NBE/FONBEs.
> Have you "dumped" the device monitor to determine where it thinks the
> historian server should be running?
> /opt/fox/bin/tools/glof -p DEV_MONITOR - list hex strings with MAC
> address of device monitor hosting station
> /opt/fox/bin/tools/fist <wokstation letterbug> - list MAC address for
> the defined workstation
> When you have determined the workstation running the device monitor:
> /usr/fox/cs/dmrecon d - creates the current device monitor
> configuration in a .cfg file
I've dumped the device monitor but see no references at all to the historian.
I'm looking in cs_dm.current. I also checked cs_devmon.cfg with bpatch and
don't see any historian reference there.
> Are there any workstations or peripherals failed?
> Have you searched the other workstations to see if others are running
> ipchisti?
No other stations are running ipchisti, although as noted all the 4 remote
collectors are running fetchdog (at least until I kill it on P401AW).
Where does fetchdog get it's list of processes to restart?
>
> The device monitor would only allow one ipchisti process instance to run
> against a single historian instance name. Perhaps there is a naming
> convention incorrect somewhere in regards to this particular workstation
> in relation the historian instance.
>
> In the historian configuration as defined for the remote collector,
> which workstation is defined to make the remote connection? There should
> be a configuration for both the local and remote machines.
Could be. Where should I be looking at this configuration?
Regards,
Kevin FitzGerrell
Carter Holt Harvey, Ltd.
+64 27 460 9994
> ----- Original Message -----
> From: Kevin FitzGerrell<mailto:fitzgerrell@xxxxxxxxxxxxxxx>
> To: Dave Hicks<mailto:hicks_dave@xxxxxxx>
> Sent: Sunday, March 19, 2006 9:58 PM
> Subject: Re: [foxboro] Remove autostart of legacy servers?
>
>
> Dave,
>
> We've got a large network with 4 AWs in different plant areas.
>
> We have an AIM* historian off-platform on a server class machine
> running W2K
> Server Edition. We run one historian instance, puhs01, with a 30,000
> tag
> license (May be 20,000 tags -- we have two other networks and a total
> of 52,000
> tags licensed).
>
> Each of the 4 AWs has a remote collector for puhs01. This way if one
> plant area
> is down for shut/maintenance, and the AW is offline (backups, etc...)
> the
> historian is not affected for other plant areas.
>
> Because there can be only one legacy server for a historian, we had to
> pick an
> AW to put it on. The one we picked initially turned out to be a bad
> choice
> (P401AW), so we re-assigned the legacy server function to a different
> AW
> (P101AW). We work extra hard to keep P101AW up, it being the CSA host.
> The
> challange has been to get the legacy servers to not start on P401AW
> when it's
> rebooted.
>
> While this configuration follows the guidelines in the AIM* manuals,
> system
> definition doesn't support this type of configuration. We've set up
> the
> following files on all AWs:
> histln:
> puhs01
>
> histlns:
> puhs01
>
> histlocs:
> puhs01 P101AW
>
> The WPs have an empty histln file and the histlns and hostlocs are the
> same as
> the AWs.
>
> I may be completely off-base about the windu registry. One of the
> Foxboro
> engineers who worked on my CAR originally mentioned that that was where
> the
> legacy server startup arguments were saved.
>
> The manual (B0193YM_E) notes (Page 157) "The legacy servers preserve
> the
> arguments supplied to the start_server script for the next automatic
> startup.
> The histstart program restarts the servers using the same parameters
> that were
> used when the servers were started manually."
>
> What I had hoped was to find where the auto-start functionality and
> parameters
> were saved, and remove them.
>
> So, ASCII art:
>
> Win2K server
> puhs01 instance
> |
> --------------------------
> | | | |
> P101AW P201AW P301AW P401AW
> AW51E AW51E AW51E AW51E
>
> This system has 7 segments, each with NCNI pair, connecting to V7.1
> fibre
> switches. Four of the segments have an AW, the other three are control
> stations
> only. The system has one Blade workstation at 7.1 running as NFD
> master. Each
> AW51E hosts 3-8 control stations, and is associated with 3-4 WPs. Total
> of 44
> stations (control, comms and workstations) on the network.
>
> I'm open to suggestions on the configuration if there are problems with
> what
> we've set up. We're going merge this network with our other two
> networks over
> the next year under an I/A V8.1 layer (currently we pass data between
> networks
> over INI15 links), and will probably be looking at merging the
> historians too.
>
> Regards,
>
> Kevin FitzGerrell
> Carter Holt Harvey, Ltd.
> +64 27 460 9994
>
>
> Quoting Dave Hicks <hicks_dave@xxxxxxx<mailto:hicks_dave@xxxxxxx>>:
>
> > Kevin,
> >
> > A little confused about what you are attempting to do.
> >
> > If the remote collector is not the server, which workstation is
> serving
> > alarms, alarm history, messages, etc?
> >
> > Please provide a topology of workstations involved and which
> > workstations are active historians and which workstations are the
> > historian servers.
> >
> > When any of the historians are started up the I/A looks at the
> > /etc/histlocs, /etc/histlns, and /etc/histln to determine where the
> > servers should start. If a remote collector it would check for the
> files
> > listed below. The system definition or system configuration would
> have
> > to be modified to point to these particular workstations for
> historian
> > access. I am not sure as to the role /opt/windu would play in this
> > structure other than to provide the client connection services to
> which
> > ever workstation has made a graphical request. There are several
> pieces
> > involved in the historian access including the device monitor, which
> > potentially could be locking a certain workstation to a certain
> > historian and allow access to the ipchisti for that particular
> > historian. This sounds very much like a system configuration issue,
> so
> > if you would provide more detail, we can narrow it down.
>
>
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
