What we do · Data and web
High-availability platform builds
We design and build complete platforms (edge, application, database, cache, streaming and analytics) so that any single host, any single storage array or any single chassis can fail and every service keeps running. Then we prove it, tier by tier, before you go live.
What it is
A whole platform engineered as one system, rather than a collection of servers that happen to talk to each other. We work from your workload's real shape: how much it reads and writes, how it grows, what must never stop. We deliver it on our OLVM private cloud, on bare metal, or on OpenShift (OKD), in Digital Realty Athens, Amsterdam or Toronto.
How we build it
Sized to the workload. Hosts are chosen for the job: single socket where the workload is bound by memory and I/O, memory populated for full bandwidth. VMs never get more cores than one CPU socket has, because a VM spanning sockets pays a remote memory penalty on every access and often runs slower than a smaller one.
Every quorum tier is three, and spread. Database, cache, coordination, streaming and load balancer tiers each run three members with hard anti-affinity, one per host. Each member's data disk sits on a different storage array. Losing a host costs one replica; losing an array costs one replica; quorum holds either way.
Proven components for each job:
- Transactional data on Percona XtraDB Cluster, with ProxySQL routing and a floating address.
- Analytics on ClickHouse, replicated three ways with dedicated Keeper coordination nodes.
- Cache on Valkey with Sentinel failover.
- Streaming on Redpanda, with a replication factor of three.
- Edge on HAProxy with keepalived in a criss-cross VRRP layout, both addresses active.
- Application tier stateless and horizontally scalable.
On OpenShift. We build OKD and OpenShift on bare metal with a three node control plane on independent servers and Rook-Ceph for shared storage, so web content lives on replicated storage rather than a single NFS server. Ceph monitor quorum is sized so two simultaneous host failures leave storage intact. Galera databases run as StatefulSets with anti-affinity across chassis and a PodDisruptionBudget, so platform updates and rolling reboots can never break database quorum. Load balancer addresses come from MetalLB on real VLANs.
Tested, then verified by someone else. Every tier is failover tested before handover: we stop the writer, the cache primary, an edge, a host. The build is then verified from a different machine than the one that built it, against the live platform rather than the build notes.
What it protects you from
- A platform where one database, one cache or one analytics node is a single point of failure.
- A storage array or a blade chassis taking the whole platform with it.
- Kubernetes rolling updates breaking database quorum.
- VMs sized across NUMA boundaries that cost more and run slower.
- Finding out how failover behaves for the first time during a real failure.
In practice
An analytics platform built for failure. For a customer's analytics business we built six tiers across separate hosts and separate all-flash arrays: ClickHouse with dedicated Keepers, Percona XtraDB Cluster with ProxySQL and keepalived, Valkey with Sentinel, Redpanda, a dual address HAProxy edge and a stateless application tier. At handover we measured the edge failing over in about five seconds in each direction, cache promotion in about seven seconds, and writer loss absorbed by ProxySQL with the application still writing.
OpenShift on bare metal, ready for production. Before an OKD or OpenShift platform takes customer workloads, a pre-production review checks storage quorum against two simultaneous host failures and puts PodDisruptionBudgets in place for each tenant's workloads before the first node maintenance is ever scheduled.
Why EuroVPS
- We design failure domains across hosts, arrays and chassis, not just "two of everything".
- Every tier is failover tested and the timings handed to you.
- One team owns the hardware, the storage, the network and the platform.
- NUMA aware sizing as a house rule.
- PodDisruptionBudgets and anti-affinity are our standard on Kubernetes from the first build, not something added later.
FAQ
Virtual machines or OpenShift? It depends on your team and your application. Traditional stacks run beautifully on VMs; teams already shipping containers gain most from OpenShift. We help you decide.
Can you build to our own reference architecture? Yes. We review it against our failure domain rules and suggest changes where a single failure could still take a tier down.
Who operates the platform after handover? We can operate all of it, the infrastructure only, or hand it to your team with documentation and support.
How long does a build take? A complete multi-tier platform typically takes weeks rather than days, most of it spent on design decisions and testing.
Do you test with our application? Yes. Failover tests run with your application connected, so the results reflect what your users would see.
Building something that has to stay up? Talk to an engineer.
Your next infrastructure partner
Let’s look at
your setup.
Tell us what you run today and what needs to improve. An engineer will review your brief and help you plan the next step.
+357 222 32280
who will look after your infrastructure.
Let’s start with your setup.
A little context helps us start the right conversation.