Hi Artem,
At APS we have on the order of 40 PV gateways running on about 12
different workations providing connectivity between various subnets.
Typically we have one gateway running for each of our user beamlines
to be able to get accelerator information as well as control various
items related to a particular beamline. I like to call these gateways
"forward gateways".
To monitor the health and status of these gateways I have what I would
refer to as "reverse gateways" since the gateway statistics can be seen
from only one side. These reverse gateways are specifically set up to
allow only PVs of interest through them as well as having a CA_ADDR_LIST
with only the other machine IPs that contain PVs of interest. All other
PVs are denied through the reverse gateway to avoid loops.
Additionally I have 2 PV gateways running connecting multiple subnets
to the accelerator control subnet. In this case it is up to each CA
client to set the EPICS_CA_ADDR_LIST to point to the gateway that they
want to use.
I know of 1 place where someone is using 2 gateways for all CA clients.
The only thing that I have seen with this is that the client may get a
message about multiple servers with the same name and then default to
only 1 of them. As near as I can tell this works on the premise that
"he who answers first wins". So, in this situation you really don't know
which PVs are going through which gateway without getting a report from
the gateway. Also, I'm not sure what would happen to the client if the
particular gateway serving a PV stops .... would the client be able
to automatically get the PV from the other gateway ?? I'm not sure.
Again we are running about 40 gateways, of these about 22 or so are
forward gateways and the rest are reverse gateways; by the above
definitions. Also, we are running 2 PV nameservers in conjunction with
2 of our gateways; this helps to keep "unknown" PVs from getting through
to the accelerator subnet; like if someone forgot to make a
substitution.
I would be happy to discuss further details about configuration of
gateways but I cannot intelligently comment on the actual code
operation and implementation.
Hope this helps,
Marty
Jeff Hill wrote:
Hello Artem,
As far as I understand gateway does not have any "internal state", which
is needed to be synchronized.
The gateway maintains shadow copies of the PV's that its clients are
watching. These shadow PVs are used to propagate publish and subscribe
semantics through the gateway. As I recall it's a GW configurable option
whether gets are serviced from these cache PVs, or alternatively, if they
are to be forwarded directly to the IOCs.
In principal, the net functional impact from introducing a gateway might
only be some propagation delay between the client and the IOC. There might
also be, only for PVs that change at a very high frequency, an increased
probability for certain transitional subscription updates to be discarded.
All of this depends on how much load the gateway experiences which leads us
to another functional difference of a gateway based EPICS system; the
gateways tends to introduce bottle necks from a loading perspective. Also,
the gateway has a less robust implementation compared the rest of EPICS.
This is maybe in large part due to its being based on the "portable CA
server" which is a less commonly used component of EPICS. Nevertheless, the
gateway is used at many sites in production installations, and the gateway
is being continually refined as fringe problems are identified and fixed.
The mantis bug tracker system on the EPICS home page can be used a general
guide to the stability of the software.
I wonder, what problems could occur if we have multiple CA-servers on the
same network? Are there any CA related problems ?
In our case those CA-servers are gateways with the same configuration.
Of course setting up multiple servers (IOCs) all sharing the same network is
a very normal configuration with EPICS. However, with what I will call
bi-directional gateways, one has to be careful about introducing PV
resolution infinite loops. You might end up with what I will call
bi-directional gateways if you have a gateway granting access into subnet A
from subnet B, and also a gateway granting access into subnet B from subnet
A. In that situation you will need to be very careful to configure the
gateways so that they will ignore name resolution attempts coming from a
gateway going in the opposite direction. Of course, more complex PV
resolution looping situations are possible if there are complex CA gateway
based paths between subnets. Hopefully Ken or Ralph might have included a
brief explanation of how to avoid these situations in the gateway
documentation?
Best Regards,
Jeff
-----Original Message-----
From: Artem Kazakov [mailto:[email protected]]
Sent: Thursday, November 23, 2006 8:56 PM
To: [email protected]
Subject: CA question
Hello Jeff!
Could you please help me understand one particular thing about CA.
Here at KEK we are thinking about implementing redundant gateway.
As far as I understand gateway does not have any "internal state", which
is needed to be synchronized.
I wonder, what problems could occur if we have multiple CA-servers on the
same network? Are there any CA related problems ?
In our case those CA-servers are gateways with the same configuration.
Thanks in advance and regards,
Artem Kazakov.
- Replies:
- RE: CA gateway question Jeff Hill
- References:
- RE: CA gateway question Jeff Hill
- Navigate by Date:
- Prev:
RE: CA gateway question Jeff Hill
- Next:
EDM X-Y graph rescaling Chestnut, Ronald P.
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: CA gateway question Jeff Hill
- Next:
RE: CA gateway question Jeff Hill
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|