Raspberry Pis are just one of many single board ARM computers available that can easily run linux. ARM processors are widely used in used in industry for many control purposes. IOW, this proof-of-concept is the perfect prototype showing anyone who uses SBCs how to build out a fault-tolerant fail-over system regardless of their choice in micro-controller. Very cool
Just to make sure I understand the concept: This is a failover for the Modbus-automation in node-red. So it would always operate anything Modbus and nodered-related. Any external data-communication would need some additions adjustments, right? Like communicating with the fail-safe cluster via MQTT would make this the single-point-of-failure, right? I am just asking, because I wanted to create a similar system for node-red instances but could not really get around MQTT as single-point-of-failure. Except setting up two isolated wireless networks with their own MQTT and node-red instance and then if the secondary network would detect a failure on the first, it would completely shut down the raspberry providing the wireless-lan-1 so all tasmota devices would switch over to their secondary wireless and connect to the backup node-red. So, this video is great and it was a good find to give me new ideas, (Sadly for other projects, not my current problem.) =)
This example uses UDP broadcast for inter-node communication, so no broker as a single point of failure. Of course you could easily change this to use MQTT with redundancy if desired.
I see SD cards in your PIs, how can you disconnect them from power without proper shutdown so often without crashing the file system? I had often problems with crashed file systems on my PIs SD cards, what is the secret behind it? I am thinking of using a USB SSD drive. What is your opinion?
He was disconnecting the network from the broker nodes. Power is an intereting on. Better might be to battery backup the nodes. A medium SLA gell cell should last 15 to 20 minutes, enough to ride out most outages, with some luck.
No, please don’t do this, that’s not a real HA. I am currently opening a new blog exactly about this topic. If you want to see an unfinished draft how to do HA with (for example) NodeRed *right*, please have a look at how2control.jimdo.com/2019/01/09/set-up-suse-hawk-high-availability-and-nodered-service-on-raspberry-pi-2-3/ Be aware that you need a shared storage (NFS) and a switch with multicast snooping support. I soon will finish the article, so please stay tuned. If you have questions please ask me.
Good question: Most swarms that I've seen rely on an MQTT broker. This makes it super easy to work with, but if then the broker (or internet connection if cloud based) is a single point of failure. You could implement redundant brokers, but then the system gets complicated. I thought about implementing the broker in NodeRED (mosca), but for now this design simply uses UDP broadcast messages for communication. It works really well in my opinion!
@@WagoKurt very nice approach! At the moment I have a set up with a docker swarm of node red instances. It is not nearly as quick as your solution. And mine have still spof's like the NFS share and I have only one master mode at the moment. I think I will try this setup for my more critical operations!
Great information here Kurt. I would appreciate it if you slowed down the presentation a wee bit :) I end up rewinding multiple times. Thanks!
Great stuff, I highly appreciate your videos. Thank you so much Kurt!
Great video, new sub, thanks!
Does anyone know if regulations allow you to put something like a raspberry pi on your breaker board in belgium ?
It is all interesting staff but how applicable it to industrial solutions? I mean, so you suggest that it is time to use pi as CPU in real world?
Raspberry Pis are just one of many single board ARM computers available that can easily run linux. ARM processors are widely used in used in industry for many control purposes. IOW, this proof-of-concept is the perfect prototype showing anyone who uses SBCs how to build out a fault-tolerant fail-over system regardless of their choice in micro-controller. Very cool
Just to make sure I understand the concept:
This is a failover for the Modbus-automation in node-red. So it would always operate anything Modbus and nodered-related. Any external data-communication would need some additions adjustments, right? Like communicating with the fail-safe cluster via MQTT would make this the single-point-of-failure, right?
I am just asking, because I wanted to create a similar system for node-red instances but could not really get around MQTT as single-point-of-failure. Except setting up two isolated wireless networks with their own MQTT and node-red instance and then if the secondary network would detect a failure on the first, it would completely shut down the raspberry providing the wireless-lan-1 so all tasmota devices would switch over to their secondary wireless and connect to the backup node-red.
So, this video is great and it was a good find to give me new ideas, (Sadly for other projects, not my current problem.) =)
This example uses UDP broadcast for inter-node communication, so no broker as a single point of failure. Of course you could easily change this to use MQTT with redundancy if desired.
Nice prototype Thank you
So what was all of this doing
I see SD cards in your PIs, how can you disconnect them from power without proper shutdown so often without crashing the file system? I had often problems with crashed file systems on my PIs SD cards, what is the secret behind it? I am thinking of using a USB SSD drive. What is your opinion?
You can set the filesystem "only-read". But when you want to change something you need to remount it as writable. We do this at work.
He was disconnecting the network from the broker nodes. Power is an intereting on. Better might be to battery backup the nodes. A medium SLA gell cell should last 15 to 20 minutes, enough to ride out most outages, with some luck.
Can I connect a wagon modbus rtu to this setup? If so how?
No, please don’t do this, that’s not a real HA.
I am currently opening a new blog exactly about this topic. If you want to see an unfinished draft how to do HA with (for example) NodeRed *right*, please have a look at how2control.jimdo.com/2019/01/09/set-up-suse-hawk-high-availability-and-nodered-service-on-raspberry-pi-2-3/
Be aware that you need a shared storage (NFS) and a switch with multicast snooping support. I soon will finish the article, so please stay tuned. If you have questions please ask me.
Do you prefer this setup vs swarm?
Good question: Most swarms that I've seen rely on an MQTT broker. This makes it super easy to work with, but if then the broker (or internet connection if cloud based) is a single point of failure. You could implement redundant brokers, but then the system gets complicated. I thought about implementing the broker in NodeRED (mosca), but for now this design simply uses UDP broadcast messages for communication. It works really well in my opinion!
Was gonna ask the same question ! .
@@WagoKurt very nice approach! At the moment I have a set up with a docker swarm of node red instances. It is not nearly as quick as your solution. And mine have still spof's like the NFS share and I have only one master mode at the moment. I think I will try this setup for my more critical operations!
Great video, could you point me in the direction of the aftermarket POE hat for the PI?