In our monitoring and control systems we typically use the PAC Project Pro Redundant Network option to connect multiple SNAP-PAC-R1 I/O racks and at least one SNAP-PAC-S2 controller. Normally we link most /all of our PAC Display Pro tags to this -S2 controller. (Our PAC-Display HMI computers also use redundant ethernet.)
We would now like to also make some of our local data available over the internet and to mobile devices using Groov View. Has anyone tried connecting a single Groov-AR1-Base Edge appliance to a redundant Opto22 LAN and have it act as a WAN web server? What is the best way to do this?
What would happen if we used two Groov-AR1-Base Edge appliances (one for each redundant network)?
Hi Brad,
I think I see where you are headed with this and its exactly what the groov AR1 and EPIC PR1 were built to do with their independent network ports.
This image is from the Networking Opto22 Products guide (it needs some love and we are slowing reworking this whole guide, but it still serves a job)⌠I think this is what you are wanting to do?
Put the web server (groov View) on the office - and thus available over the Internet - network but keep your controls network locked away.
One question is how do you want to access the groov View? Port forward from your router to the hostname of the groov AR1 or perhaps even more secure, over VPN.
The groov AR1 will fit in with either. The guide covers the ins and outs of both options.
As for using two AR1s, also not a problem, the challenge is how to load share the two web servers when both networks are up and how to fail over when one network goes down. There are devices out there that can do it. I would be talking to your IT guys (unless you are your IT guy - so you would be talking to yourself⌠) for guidance in that matter. The important thing they need to know is that groov View on the AR1 runs on a pretty standard web server. Secure port 443 should get you there.
Is that the sort of thing you were looking to do?
Feel free to post a drawing of a high level over view if I have misunderstood.
Yes, the second diagram almost exactly represents what we want to be able to do but the âredâ network would also be connected to the internet so that we could use VPN to access the data remotely as well. The problem is our âblueâ network is not one network but two (PAC Project Pro redundant) networks on two subnets - in this example they might be something like 172.168.0.xxx and 172.168.1.xxx.
The questions this this brings up for me are:
What happens if we mix redundant (PAC-S2, PAC-R1s) and non-redundant (Groov) Opto 22 devices on this network? In other words, if we only have a Groov AR1 on one network of the âblueâ networks, will the other âPACâ nodes recognize this and automatically communicate with the Groov AR1 on this network (make it the active network between the âGroovâ and âPACâ nodes) even if the other network is the active network between some of these other âPACâ nodes?
Will the above still work if we put a Groov AR1 on both networks?
Has anyone come up with a elegant way to provide web access to both LAN / âPACâ networks that automatically switches / arbitrates between the two networks or a particular node on the two networks? My weak understanding of the capabilities of bridges/gateways/routers is an issue here. Do some of these have the capability to ping nodes on two network ports and switch over to forwarding from one network to the other if the node disappears from one? Hopefully Iâve explained that in a way that makes sense. (In other words, both redundant / blue / PAC networks would be plugged into this special bridge/gateway/router which would arbitrate between the two and forward information (with the same output IP address / subnet either way) on a third port to a Groov AR1.)
You are not really mixing redundant and non-redundant products as each network is carrying all the traffic regardless of the other networks state.
In other words, the IP data is free flowing on each network. You can put a groov AR1 on network #1 or network #2 and it will see all the tag data regardless of which network you chose to put it on.
There is nothing to switch, detect or automate. IP traffic is IP traffic and all the I/O point data is on both networks equally. In other words one network is not active while the other inactive, both are fully active at the same time.
If you put two AR1s in the mix you will be fine. The pointless thing to do would be to put an AR1 on both network legs. While nothing bad would happen, you donât have a third network port on the AR1 to connect with your office/Internet network so there would be no way to view your groov View screens outside of the two control networks. (Yes, you could try and use Wifi as the third network and have it join your office Wifi, but Wifi in this application is hard to recommend due to its lack of reliability).
Also putting two AR1s in the mix would then bring about the need for a hardware load balancer (linked in my previous reply). Or you could simply hit one AR1 host name and if groov View shows a bunch of broken tags you would know that that network is down and you need to hit the host name of the other AR1.
Yes, this is the job of the hardware load ballancer. It detects (PING and other ways) which network and hosts are up and switches to the active one. They are expensive devices, but you might check out Mikrotik and Ubiquity. They have some smart features built into their products and are priced right.
Yes that diagram is exactly what Iâm referring to.
Thanks for the answers to 1. and 2.: That is how I thought it would work but it is good to have it confirmed. It sounds as if option 2. (with 2 Groov AR1s) is the easiest and likely least expense way to still maintain some level of redundancy on the WAN / Groov View side but as you say, you would have to manually navigate from one Groov AR1âs âweb addressâ to the other if one internal LAN went down (which isnât terribly user friendly - but also would be a pretty rare event).
In regard to 3, I will have to do more research on hardware load balancers and see what is available and I have also sent a query to our IT guy to see if he has any ideas. It sounds as if the cost / complexity of doing this may not be worth it (versus options 1 and 2).
