Deployment scenarios · No single server to lose
A hub that survives a server failure.
On Kubernetes the hub runs as two copies, the message server as a three-node cluster and the databases with replicas. When one server fails, the others keep serving, and no message on its way is lost.
- Where
- A Kubernetes cluster in your data centre or plant server room
- Install
- The shipped manifests for the application and its databases
- Fits
- Plants where the data platform is part of production
The layout
Where everything sits.
- Proxus
- Your systems
- Reads machines
- Values, buffered by the sender
What you install
- The application
- Two hub replicas behind an ingress with sticky sessions, a three-node message cluster, one pod per gateway, and disruption budgets that keep the copies on different nodes.
- The databases
- A three-instance configuration database and a two-replica historian with its own three-node coordinator.
- Your platform
- Spreading the nodes over racks, power and storage is part of your cluster design.
How it connects
- Users
- Through the ingress, to whichever hub copy is serving them.
- Machines
- Read by the gateway pods, so the cluster nodes need a route to the machines’ network.
- Your systems
- Receive deliveries as in any other layout.
When something fails
- A hub copy fails
- The other copy keeps serving. Users of the failed one are moved over and may have to sign in again.
- A message server node fails
- No message is lost: every stream is kept on all three nodes.
- A database instance fails
- A replica of the configuration database is promoted; the other historian replica answers.
- A gateway pod fails
- Kubernetes restarts it. Its machines are not read in the meantime.
The limits
- Gateways
- Each gateway is one pod. High availability for a gateway means a fast restart, not a second copy.
- Gateways on other networks
- The shipped manifests run the gateways inside the cluster. For gateways on plant networks outside it, talk to us about your topology.
- Operations
- Kubernetes, its storage and its upgrades are run by your team.
Other layouts
Layouts combine. These are the other six.
- Single server The hub and its built-in gateway on one machine next to the machines.
- Hub and edge gateways Edge Gateways next to the machines, one hub for the plant.
- Hub in the DMZ or the cloud The hub where IT wants it; gateways on the control network connect out to it.
- Many sites, one hub Gateways at every plant, one central hub with one namespace for the group.
- Air-gapped Installed from a package, licensed offline, no path to the internet.
- Siemens Industrial Edge Installed from Industrial Edge Management, running on one Industrial Edge Device.
Next step
Place it on your own plant.
Bring a sketch of your networks and the machines you want to connect. An engineer places the hub and the gateways on it with you, with the firewall rules your IT team will ask for.
-
Scoping call
Equipment, protocols, sites and the systems the data has to reach.
-
Technical walkthrough
A working demo against a scenario that resembles your plant, not a generic tour.
-
Pilot plan
A defined first line or site, with the deployment and security questions answered up front.
-
Roll-out
The same templates bring the next lines and sites online.