Re: [foxboro] AIM* collector failure
- From: Terry Doucet <doucet427@xxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Mon, 22 Mar 2010 21:01:27 -0400
Matt,
When part of a system is powered down, it is always a good idea to run a
CHECKPOINT on all CP's after the power is restored (before process is
re-started). This ensures that all peer connections are formed. If the cables
or switches are disconnected then you can run the tool to reconnect the device
monitor in usr\fox\cs.
Terry
> Subject: [foxboro] AIM* collector failure
> Date: Mon, 22 Mar 2010 17:47:18 -0600
> From: Matt.Gunter@xxxxxxx
> To: foxboro@xxxxxxxxxxxxx
>
> Please bear with me while I describe this scenario...
>
>
> 1) We are running AIM* (3.3.1) off platform.
>
> 2) We are running I/A 7.1.5 (all Solaris boxes).
>
> 3) We took four pair of redundant CPs off line. This included
> taking them "off line" in the System Monitor (probably an unnecessary
> step), then cutting power to them.
>
> 4) After completing the needed facility work, we restored power.
> All CPs came up "on line."
>
> 5) We thought everything was OK but determined some days later that
> no data from one of the CP pairs was being collected by AIM*. This
> particular pair was in a rack with two other pair, the data for which
> was collecting just fine.
>
>
>
> Restoring data collection was a simple matter of rebooting the redundant
> CPs. This means that we did not have to restart either the remote, or
> local collectors. Fortunately we had not been processing using those
> CPs, but the lack of data could otherwise have been a disaster. As a
> result, our method of powering up a CP (for any reason) will have to
> include determining if its data is successfully being collected. Seems
> pretty simple until the time we forget - which, of course, could be "the
> disaster."
>
>
>
> We are currently cooking up an method to continuously test to see data
> from all CPs are successfully being collected and that the AIM* server
> is actually alive. I just wondered if anyone else has seen this
> behavior, what the cause might be, and what can be/has been done to
> prevent it - maybe we can put our cookbooks away.
>
>
>
> Thanks to all!
>
>
>
> Matt
>
> ATK Space Systems
>
>
>
>
>
>
> _______________________________________________________________________
> 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
>
_________________________________________________________________
Stay in touch.
http://go.microsoft.com/?linkid?12959
_______________________________________________________________________
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:
