The cloud that lives down the hall.
The edge devices contextualize your plant data and stream it out through a secure tunnel. This is the other end of that tunnel: three Dell PowerEdge servers in a rack you own, running Red Hat OpenShift. Kafka takes the ingest, MSSQL keeps the transactions, ClickHouse answers the billion-row questions, and every service runs as replicas spread across all three machines. Lose a server and the platform shrugs. It hosts your VMs, your private VPN, and your zero-trust access while it's at it.
Three servers that behave like one platform.
A compact Red Hat OpenShift cluster on three Dell PowerEdge rack servers: the control plane is spread across all three for quorum, and every workload runs as multiple replicas with anti-affinity rules that keep them on separate machines. High availability is the architecture, and it applies to everything the cluster hosts, from Kafka brokers to the Windows VM nobody wants to touch.
Two database engines, because the questions differ.
"Which operator signed off order 550123?" is a row question: it wants a transactional engine with locks, constraints, and an audit trail. "What was the p95 cycle time on every filler across three years?" is a column question: it wants to scan billions of rows in seconds. The cluster runs an engine for each, with Kafka feeding both from the same edge stream. What gets asked of them is the Analytics story; this page is about keeping the engines fast and alive.
Transactional: MSSQL
Orders, genealogy, e-signatures, and confirmations live in SQL Server, where a write either commits or never happened. An Always On availability group keeps synchronized replicas on separate nodes, so a server failure fails the database over in seconds with zero lost transactions.
Always On AG · RPO 0Analytics: ClickHouse
Every telemetry point from every plant lands in a replicated columnstore built for exactly this: billions of rows, 10:1 compression, and aggregate queries that come back in seconds. Year-over-year OEE across all sites is a query, and it runs while ingest continues at full rate.
columnstore · billions of rowsKafka in between
Edge payloads land on Kafka first: a durable, replayable buffer with three brokers, one per node, and every partition replicated three ways. MSSQL, ClickHouse, dashboards, and any future consumer subscribe independently. Add a system next year and replay history into it from day one.
3 brokers · RF=3 · replayStorage matched to the workload
Databases and brokers claim replicated block volumes for low-latency IOPS. Shared recipes, reports, and file drops mount NFS. The data lake, backups, and cold archive go to S3-compatible object storage. Each application asks for a tier by name and the cluster provisions it.
block · NFS · S3 objectEvery core, spindle, and packet has a chart.
The cluster measures itself the way it measures the plant. CPU, RAM, disk throughput, IOPS, and network utilization are scraped per pod, per volume, and per node, so "the platform feels slow" resolves to a named workload on a named server in about a minute. Capacity planning runs on trends rather than guesses.
Metrics with names on them
CPU throttling, memory pressure, restarts, and network throughput are tracked per workload: the ClickHouse merge that eats six cores, the VM that leaked eight gigabytes, the ingest pod saturating a NIC. You see which tenant, which pod, which node, with history.
cpu · ram · net · per podThe disk truth
Databases feel storage latency before anything else does, so every persistent volume reports IOPS, MB/s, and p99 latency continuously. A noisy neighbor shows up as a chart, storage growth becomes a forecast, and the next drive purchase happens months before it's urgent.
IOPS · MB/s · p99 latencyPaged before you notice
Alert rules watch the same metrics: consumer lag rising, a volume trending toward full, a certificate near expiry, a replica count below spec. We carry the pager for the platform, and most incidents are fixed before the morning shift would have met them.
alert → page → fixedThe rest of plant IT moves in, too.
Every plant carries workloads that will never be containers: a Windows historian, a license server, an engineering workstation image. OpenShift Virtualization runs them as first-class VMs on the same three servers, with the same replication, storage, and monitoring. The network core rides along: the tunnels, the VPN, and the zero-trust policy that decides who reaches any of it.
VMs beside containers
Traditional VM workloads run under OpenShift Virtualization with live migration: when a node drains for patching, the Windows historian moves to another server while it keeps running. One platform to operate, whatever decade the workload was born in.
KubeVirt · live migrationCloudflare Tunnel, hosted here
The cluster runs redundant tunnel connectors, so every edge site's stream terminates on hardware you own and every published app reaches its users through outbound-only connections. The rack has the same internet exposure as the plants feeding it: none.
cloudflared ×2 · zero inboundPrivate VPN for engineering
Controls engineers get a WireGuard-based VPN, served from the cluster, for the work that needs a real network path: online PLC edits, SCADA development, drive commissioning. Short-lived access, per-user keys, every session logged.
WireGuard · per-user keysZero-trust access to it all
Grafana, dashboards, and admin consoles are published per app, behind SSO and MFA, with policy by identity: quality sees quality, maintenance sees maintenance, and the auditor's access expires Friday. Every request is authenticated; the network location proves nothing.
per-app policy · SSO · MFAWe pull a power cord before we hand you the keys.
High availability is a claim until a server actually dies. So during commissioning we kill node-02 at the power strip, on purpose, with your team watching the dashboards. Here is what that looks like:
The rack is the delivery mechanism. What you're actually buying is a place where plant IT workloads can live properly:
- A landing zone that's ready before the projects are. MES, historians, dashboards, and the next integration deploy onto shared, highly available infrastructure with storage and monitoring already in place.
- Availability by architecture. Replicas spread across three servers, quorum-based control, and N+1 capacity mean a hardware failure is an event in a log, and the weekend stays quiet.
- Engines matched to the questions. MSSQL holds the transactional record, ClickHouse serves the billion-row analytics, and Kafka feeds both from the same contextualized edge stream.
- Numbers on everything. CPU, RAM, IOPS, disk throughput, and network utilization per workload, with alerting and capacity forecasts, watched by the people who built it.
- Data that stays on your concrete. Cloud-grade architecture with on-premises custody: your rack, your walls, your compliance story, reachable only through tunnels, VPN, and zero-trust policy you control.
Ready for a data center that fits in one rack?
Tell us what should land on it: how many edge sites, which databases, which VMs refuse to die. We'll spec the servers, the cluster, and the storage, and stand it up beside your plants.
Start a conversation