Block volumes (RBD) for virtual machines and containers.
Ceph support — Red Hat certified
Distributed storage that never stops
We design and run Ceph clusters, and step in when they stop working. We are Red Hat certified.
What we work with
What Ceph is
A storage system that spreads data across many machines rather than keeping it on one appliance. When a disk or a whole node fails, the data stays available and the system repairs itself. It grows by adding machines, without stopping.
- Type
- Distributed storage, no single point of failure
- Block
- RBD — disks for virtual machines and containers
- File
- CephFS — shared filesystem, mountable from several machines
- Object
- RGW — object storage compatible with S3 and Swift
- Growth
- Nodes added live, without downtime
- Redundancy
- Replication or erasure coding, configurable
- Integration
- Native in Proxmox VE, and on standalone clusters
- Licence
- LGPL — free software
One storage system, many ways in
Ceph presents itself to vSphere over iSCSI or NFS: the storage changes, the hypervisor stays.
Amazon S3
Compatible with S3 and Swift: object storage on premise, with the data staying in house.
Kubernetes
Persistent storage over CSI, surviving a pod or a node restarting.
Object Lock
Immutable copies ransomware cannot encrypt, not even with administrator credentials. It works with Veeam.
CephFS
A filesystem that mounts from several machines at once, with no NFS server as a bottleneck.
Snapshots
Point-in-time copies of volumes and filesystems, and clones that start from them.
Remote replication
The data sits in more than one site at once: if one goes, it is already elsewhere.
Archives
From a few TB to tens of petabytes, adding nodes live without stopping anything.
Commodity hardware
Runs on ordinary machines, including servers the manufacturer no longer supports.
How it can be built
Hyper-converged
The same machines do virtualization and storage, inside a single Proxmox VE cluster. Less hardware to buy, to power and to manage.
Dedicated cluster
Ceph on its own machines, separate from compute, bare metal included. Needed when storage has to grow on its own terms, serve several clusters, or take loads that would disturb the virtual machines.
With a SAN interface
When the systems that will use the storage speak iSCSI, SMB or NFS — Windows servers, appliances expecting a conventional SAN — there is PetaSAN, which we partner with. It is Ceph: same engine, same distributed data, with the protocols those systems already speak on top.
How we deploy it
Bare metal
Ceph on its own machines, with no virtualization layer in between: the choice when storage has to carry heavy loads or grow on its own terms.
Proxmox VE
Native integration: compute and storage in the same cluster, managed from the same interface.
PetaSAN
A distribution with its own interface, for teams who want Ceph ready to use without giving up control of what runs underneath.
What we can do for you
Contact usEmergency
Cluster down or degraded, right now.
- Direct work on the cluster
- Including installations built by others
- A report on what happened
Ongoing support
Anyone running a cluster in production who wants someone to look after it.
- Version upgrades
- Disk replacement and rebalancing
- Expansion with new nodes
- Periodic health checks
Project
A cluster to size and deploy.
- Sizing
- Deployment
- Failure testing before production
- Training for whoever will run it
We do not publish a rate card because it depends on how many nodes you have and what you need: we quote after looking at the situation, not before.
We train the people who run the cluster
See the courseCourses built around whoever administers Ceph day to day: how to read its state, what to do when a disk fails, when to call for help and when not to. At our place, at yours, or remotely.
Clusters we did not install
Contact usIt is the most common case. You do not have to explain how it was built or why: that part is on us. We are often called in on clusters put together by someone who has since moved on.
Is your storage down right now?
Go to emergencyQuestions we get
What kind of work do you do on Ceph?
Design and sizing, deployment, routine maintenance — version upgrades, disk replacement, data rebalancing, expansion with new nodes — recovery of degraded clusters, emergency work, and training for whoever runs the cluster day to day.
Do you handle version upgrades too?
Yes, and it is the part of the job where mistakes are most common: an upgrade has to be done in the right order — monitors, managers, OSDs, then the gateways — and on a cluster in production it is worth rehearsing first. Clients on ongoing support do not think about it: we plan it for them.
Do you work on clusters installed by someone else?
Yes, and it is the common case. You do not have to explain how it was put together or why: we need access, the output of ceph -s, the version, and how the network is arranged. From there we tell you what we see, and you decide. We are often called in on clusters built by someone who has since moved on.
Can you migrate existing storage onto Ceph?
Yes. It is done with the service running, moving the data a piece at a time: virtual machines keep working while the transfer goes on. Any downtime is limited to the final switch-over, and it is agreed with you.
How many nodes do we need to start?
Three is the minimum for the cluster to survive losing a node without stopping. You can start there and add more when you need them, with nothing to rebuild. Below three nodes Ceph makes no sense, and we will say so rather than sell it anyway.
Does it need special hardware?
There is no approved hardware list: Ceph runs on standard equipment, and you are not tied to one supplier. There are characteristics that do matter, though — a dedicated, fast network and disks built to run continuously — because those are what decide whether the cluster performs day to day. It is not about the brand, it is about how it is built: we check that with you before you buy anything.
What happens if a node fails?
Nothing you have to do straight away. The data sits on several nodes, so virtual machines carry on working and the cluster rebuilds the missing copies by itself. The node gets replaced in your own time, not in the middle of the night. If I/O has stopped instead, the cluster is not rebuilding: that is an emergency.