What is the best way to keep Redis in sync?

[herrdragon]

Hello,

I am using 2.2 (may soon upgrade to 2.3) and I want to run the services physically separated. CORE in cloud and NODES in edge. What would be the best way to keep Redis in NODE in sync with Redis in CORE and vice-versa?
Lets say I add a device on s NODE, I want that device to be also in CORE. Or if I add a label to a device for a particular NODE, I want that label to in Redis in that NODE. Is this possible?

Thank you

[lenny-goodell]

If only need to run device service on NODE, then Redis only needs to be in CORE. Device services do not directly access Redis.

[herrdragon]

Hi Lenny, thank you for your reply. I see what you are saying but doesnt device service needs metadata on each NODE?. otherwise it will have to send every sensor data through the network as it comes, which will overwhelm the network. I was thinking one metadata on each NODE and a master metadata in the CORE. I there a better way?

[lenny-goodell]

Core Metadata just maintains the metadata (profile, devices and provision watchers) that device services use. Each Device service has a cache of the current metadata it needs. Once the metadata is cached during device service start-up. Core Metadata is not involved when sensor data is received from the devices and published to the EdgeX MessageBus. So there is no need to have an instance of Core Metadata on each node. Note that Core Metadata will send the device service update metadata if it changes, but that doesn't happen very often if at all. So the is no need to have separate instances of Core Metadata running on each node.

[herrdragon]

To implement edgex message bus, don't I need a redis instance on the Node? and if not, would that means a more complex network like tunnels, where the node has constant direct connection with Core? What happens in the cases where connection is not very stable? How would edgex handles to send data to Core after being offline for a while?

[lenny-goodell]

To implement edgex message bus, don't I need a redis instance on the Node?
No, you what to use the MessageBus from the Core node.

and if not, would that means a more complex network like tunnels, where the node has constant direct connection with Core?

Depends on how complex of an environment your are creating. If the Core and NODE are not on the same network, you may want to have separate EdgeX deployments on each Node. Then have the NODE deployment Export the data to the CORE using App service HTTP or MQTT export.

But only do this if CORE has some additional processing is will do. It it is just going to export to the Cloud then each NODE could do that directly.

What is the purpose of your CORE node?

What happens in the cases where connection is not very stable? How would edgex handles to send data to Core after being offline for a while?

I wouldn't. If you need more resiliency you could switch to using MQTT for the MessageBus, but that only helps with the last message published.

If you use the Node export approach, then you can use Store and Forward capability. This is what it is designed for.
https://docs.edgexfoundry.org/2.3/microservices/application/AdvancedTopics/#store-and-forward

[herrdragon]

I was thinking on a split deployment. On the edge it will be device service, and now a redis instance for store and forward. I was thinking on metadata also but now I'll moved it to the Core which sits on the cloud, where all other services will run.

[lenny-goodell]

Core which sits on the cloud, where all other services will run.

EdgeX is designed for the on premise edge, not the Cloud. We have export capability for getting the data from the edge to the cloud as I explained previously. This is not a recommend or supported deployment of EdgeX.

[herrdragon]

I am a bit confused. I got this idea from https://docs.edgexfoundry.org/2.2/ in the Deployment section. The first example that shows device service by the device, and the rest on the cloud. I interpreted wrong?

[lenny-goodell]

Sorry, that is a very old diagram from early on in the project. The top part should be removed. It is possible, but not what EdgeX is designed for. I think it was trying to show all possible deployments.

The 2nd one is the typical deployment with all services running on the same node at the edge. Optionally device services is running on other nodes at the edge.

[herrdragon]

Oh, ok, got it. This was very helpful, thank you very much. I will review the design again!

[herrdragon]

HI Lenny, so you are saying that Edgex was not designed for the cloud or to be split, correct? So if I have multiple Edgex deployed in multiple locations, is there like a Master Edgex that can get info from all instances, including status of services and things like that? Any recommendation on this? Thank you

[lenny-goodell]

EdgeX can be distributed at the edge. i.e. device services on edge node(s) where sensor(s) are and all other EdgeX service running on a central edge node. Or you can run complete EdgeX stack on each edge node.

For service status you can use one of many deployment management solutions, such as our refence Docker Compose with Portainer deployment. EdgeX doesn't dictate how it is deployed and managed.

Please remember that EdgeX is edge middleware you develop your edge solution around. It is not a complete edge solution itself.

[herrdragon]

Can you point me to where that Docker compose file is? Thanks

[lenny-goodell]

Based on your question, you have not read the EdgeX Getting Started documentation.
Please read it here: https://docs.edgexfoundry.org/2.3/getting-started/Ch-GettingStartedDockerUsers/

[herrdragon]

That is true! I have skipped many sections to get to just what I was looking for. Got it, going back to the beginning.
Thank you