Network with virtual server
Hi,
We have a virtual aspect/connectivity server connected on a wm-Ware network.
From that network we need to route all traffic to our client/server network.
And then we will use an rnrp-router to seperate the control network.
Is this a solution that will work?
If not what do we have to do to make it work?
We cannot connect the clients directly on the vm-ware network.
Thanks in advance!
We have a virtual aspect/connectivity server connected on a wm-Ware network.
From that network we need to route all traffic to our client/server network.
And then we will use an rnrp-router to seperate the control network.
Is this a solution that will work?
If not what do we have to do to make it work?
We cannot connect the clients directly on the vm-ware network.
Thanks in advance!
Asked 2 months ago
Answers
0
Forgot to attach the picture
Answered 2 months ago
0
Negative.
Since 800xA v5.1 released over ten years ago, RNRP is a mandatory function between 800xA servers and clients, even if only using a singular network.
RNRP does not only provide routing between a primary and secondary network (and could thus theoretically be excluded when only having singular network), RNRP also provides node-to-node status supervision which is a critical component in System 800xA.
For this to work, server and clients need to share same Layer-2 network (called RNRP area). Regular IP-routers act as network isolation devices splitting larger networks into smaller L2 subnetworks => they cannot route RNRP (while the ABB NE87x Industrial Router can).
For the clients to be able to connect to the virtualized servers, they must be fed node-to-node status information from RNRP.
Suggestions:
Since 800xA v5.1 released over ten years ago, RNRP is a mandatory function between 800xA servers and clients, even if only using a singular network.
RNRP does not only provide routing between a primary and secondary network (and could thus theoretically be excluded when only having singular network), RNRP also provides node-to-node status supervision which is a critical component in System 800xA.
For this to work, server and clients need to share same Layer-2 network (called RNRP area). Regular IP-routers act as network isolation devices splitting larger networks into smaller L2 subnetworks => they cannot route RNRP (while the ABB NE87x Industrial Router can).
For the clients to be able to connect to the virtualized servers, they must be fed node-to-node status information from RNRP.
Suggestions:
- Remove the router and join the System 800xA servers and clients via a traditional Layer 2 network.
- Replace the regular router with a NE87x and define the servers on area X and the clients on area Y (controllers on area Z).
A NE871 has three ports and can route between three RNRP areas. A NE870 has 11 ports and can route between 11 areas (or 5 redundant areas + 1 not redundant). - Create RNRP Tunnel Area between the virtual servers and clients.
A tunnel area must be terminated with a Tunnel Area Border Node on each side. Refer to the 800xA System Network Configuration User's Guide.
0
4. Use thin client technology (Remote Desktop Protocol) to connect operators and engineers to terminal servers hosting the user sessions.
Keep in mind that Remote Desktop Protocol reduces operator satisfaction by some degree. For best performance (=satisfied operators) rich clients with fast processors and graphic accelerator boards are recommended. For the very same reason, it is not recommended to virtualize terminal servers (adding yet one more layer between the HMI and the processors set to handle it). Thin clients connecting virtualized terminal servers are in the low end corner of the performance matrix.
Workplaces thrive on pure GHz, not number of processor cores; opting out on a GPU forces the main processor to also handle the graphics; a task that can take its tolls, especially when using multi high resolution monitor layouts with dense and vivid PG2 graphics.
Keep in mind that Remote Desktop Protocol reduces operator satisfaction by some degree. For best performance (=satisfied operators) rich clients with fast processors and graphic accelerator boards are recommended. For the very same reason, it is not recommended to virtualize terminal servers (adding yet one more layer between the HMI and the processors set to handle it). Thin clients connecting virtualized terminal servers are in the low end corner of the performance matrix.
Workplaces thrive on pure GHz, not number of processor cores; opting out on a GPU forces the main processor to also handle the graphics; a task that can take its tolls, especially when using multi high resolution monitor layouts with dense and vivid PG2 graphics.
Add new comment