GeoSCADA HMI & Hyperconverge Infrastructure

[masons]

I would like to know if Geoscada SCADA HMI in a triple redundant Configuration can function well in a hyperconverge infrastructure, utilising software defined storage across three nodes (servers) and features like live migration & storage replica.

[sbeadle]

An interesting question. Alarm bells ring on 'software defined storage', because slow disk performance has significant effects on SCADA. Also 'live migration' - redundant SCADA pairs need continuous communication, otherwise they may change state unintentionally (e.g. Standby to Main) if they lose comms. As ever, it's all about timing.

[AdamWoodlandToo · Accepted solution]

It is probably more a philosophical can you vs should you. This is my personal opinion, I'm sure others may disagree and that's ok!

Can the product do it? Possibly, but I've never tried it. As Steve mentions above there are some hurdles, also licences might be an issue, you'd need to make sure server IPs don't change/clash, you'll probably need to tweak some timeouts and you'd be fighting against the application-level synchronisation doing what it needs to to keep servers in sync and things running to maintain the integrity of the data (typically data loss is a "bad thing" and has legal or regulatory impacts for customers). Bound to be lots of other things you'd find during the exhaustive testing that would be required.

Should you? That really comes down to the business. Invariably when the system was originally stood up there would have been defined business and functional requirements. Those would have been operationally focused to ensure the critical parts of the business function through the existence of the system. Assuming it is an existing system you're planning on converting, then the system would have been designed to comply with those requirements. Any time you change the fundamentals of the system you're going have to make sure those requirements are still met.

I half joke that the primary metric of the state of any SCADA system is how happy operators are (OX = Operator Experience). If they're happy then you know the plant/whatever (layer 1 and lower) is behaving correctly and the SCADA system (layer 2) is providing them the functionality they need to keep that happening. Operators rarely care about layers 3 upwards. The moment they are not happy it is a good indication that what is usually the most critical part of any business is not good (depends on the business of course, but usually the business makes their cash off whatever the SCADA is doing, so if the whatever is not happening there is no business).

Take for example opening up a Word/Excel doc from a file server. Usually files would be opened in a second or two depending on size, but let say one day it takes 30 second... we've all be there... but does it matter? Probably not. In SCADA even once it does. Your operators are used to how the system works and you've usually got someone operating the system 24/7, if one day mimics go from taking 1-2 seconds to open to say 3-4 seconds it will be noticed and there often will be a problem (1 to 2 seconds is commonly the contract requirement for mimic opening times). It will potentially halve their effectiveness as they click through mimics checking things, these operators are experts in what they do and will know quickly from a mimic if there are any issues so can move on quickly.

So when the system is architected this requirement is considered. If you move to HCI, can you keep to that requirement all the time? Even those rare occasions will likely cause a problem.

This is probably a long winded version of "technically you might be able to do this by working through the issues, but I think your biggest hurdle will be the change management side and if you can't make your business critical users happy you might have burnt a lot of cash for no gain".

You mention triple-standby so I'm assuming this is a significant system.

(Also, why is mon$y banned here? Having to use cash...)