Hello, we have two questions relating to enabling gRPC on a DMS;
- Is there any benefit for enabling gRPC between DMAs if there are no firewalls between them?
- Please can you publish a configuration example for Redirects to existing physical i/ps that are pointing at the VIP (Virtual i/p), assuming that this is this required in the circumstance of a DMA cluster with multiple DMA pairs. The example that is available from the 10.3.2 release notes just shows the configuration for a single pair of DMAs - Ref: https://docs.dataminer.services/release-notes/General/General_Feature_Release_10.3/General_Feature_Release_10.3.2.html#client-server-communication-grpc-instead-of-net-remoting-id_34797-id_34983
REF: 'DMS.xml' example copied from above release notes for single DMA pair...for an example DMA with IP 10.4.2.93:
<DMS errorTime="30000" synchronized="true" xmlns="http://www.skyline.be/config/dms">
<Cluster name="pluto" synchronize="" timestamp="2022-12-13 12:48:29"/>
<DMA ip="10.4.2.93" timestamp="" contacted_once="" lostContact=""/>
<DMA ip="10.4.2.92" timestamp="2023-01-03 23:38:42" contacted_once="TRUE" lostContact="2023-01-06 01:02:00" id="69" uri=""/>
<Redirects>
<Redirect to="10.4.2.92" via="https://10.4.2.92/APIGateway" user="MyUser" pwd="MyPassword"/>
</Redirects>
</DMS>
Hi Paul,
1. In this scenario I would say there is currently no immediate benefit, and as you can see in my response on point 2 there is quite some configuration work. It could be useful to wait until the gRPC connection becomes the default and no extra configuration is needed.
The main benefit for clients is that there only needs to be one port opened on the firewall (443) and that clients don't need to accept incoming connections for eventing (or fallback to polling) as there are only outgoing HTTPS connections.
2. Every agent needs a <Redirect> configuration towards every other agent, as well as to its failover buddy. For an example with 2 agents A and B, each consisting of a failover pair, the configuration would look like this:
A: VIP 10.0.0.100 with physical IPs 10.0.0.101 (A1) and 10.0.0.102 (A2)
B: VIP 10.0.0.200 with physical IPs 10.0.0.201 (B1) and 10.0.0.202 (B2)
A1: redirect for 10.0.0.102 and 10.0.0.200
A2: redirect for 10.0.0.101 and 10.0.0.200
B1: redirect for 10.0.0.100 and 10.0.0.202
B2: redirect for 10.0.0.100 and 10.0.0.201