Knowledge · Guides and glossary

Knowledge: high availability, Proxmox and choosing a provider

In brief

The managed-cluster.net knowledge hub collects our high availability and Proxmox guides: an availability calculator, split brain, quorum and fencing, Proxmox vs VMware, and a checklist for choosing a hosting provider. The glossary explains 18 terms, from quorum to the data processing agreement, in one or two sentences each and links to the page that covers the topic in depth.

Written for IT leads, architects, security officers and procurement teams: vendor statements, RFCs and legal provisions with primary sources, and a visible review date on every page.

Browse the guides Go to the glossary

Guides

High availability and Proxmox guides for planning and procurement

The four articles in the managed-cluster.net knowledge hub answer the first questions in planning a high availability platform: How much downtime does an availability figure allow? Why does a cluster need three nodes? Is Proxmox VE an alternative to VMware? What should a hosting provider for critical systems be able to prove? Each lists its sources and a review date.

Guide · Calculator

Availability calculator: downtime per year

Calculator and table showing how much downtime 99.9%, 99.95% or 99.99% availability allows per year, month and week, and what a percentage leaves open without a measuring point, a measuring period and a rule for maintenance windows.

Guide · Cluster basics

Split brain in clusters: quorum & fencing

Why a Proxmox cluster needs at least three nodes, how quorum and fencing prevent split brain, and when two nodes with an external quorum device are enough.

Comparison · Platform choice

Proxmox vs VMware compared

Proxmox VE and VMware vSphere side by side: licensing, high availability, distributed storage, day-to-day operations and the effort of switching, with a source for every row.

Guide · Checklist

Managed hosting provider checklist

Due diligence questions for procurement and security teams: location and law, contract, DPA, certifications, backups, failover tests, documentation and exit. Vendor-neutral and ready to print.

Glossary

High availability and Proxmox glossary: 18 terms explained

The managed-cluster.net glossary covers the terms that keep coming up in architecture reviews, proposals and contracts for high availability Proxmox clusters, each in one or two sentences. Where an entry describes how we work, it says so explicitly. Every term links to the page that covers the topic in depth.

Clusters and failover

Quorum: The majority of votes in a cluster (by default, Proxmox VE gives each node one vote): only nodes that can communicate with each other and together hold this majority may change the cluster state; without quorum, Proxmox VE switches to read-only mode (source 1). With three nodes, our standard, two keep the majority after a failure.; How the quorum majority works
Fencing: Isolating a failed or cut-off node: the cluster makes sure the node has really stopped working before its services start elsewhere. This way, no virtual machine runs twice (source 2).; Fencing in a Proxmox cluster
Split brain: A state in which parts of a cluster keep running independently after a network fault and claim the same resources, such as two instances of one VM writing to the same data. Quorum and fencing prevent this.; How split brain happens
Corosync: The cluster engine the nodes of a Proxmox VE cluster use to communicate and form quorum (source 1). When a node fails, Corosync detects the failure, and the remaining nodes keep quorum as long as they hold the majority of votes.; Reference architecture with three nodes
HA Manager: The Proxmox VE service that monitors virtual machines and containers configured for high availability and, after a node failure and fencing, automatically restarts them on another node (source 2). Services running on several nodes behind the load balancer remain available.; What happens during a failover, step by step
Live migration: Moving a running virtual machine to another node without shutting it down. We use live migration to clear a node before updates or maintenance work.; What a managed Proxmox cluster includes
Rolling update: Updating a cluster node by node while your systems keep running: one node is updated and checked before the others follow, and we roll back if problems occur. Exceptions such as a major database upgrade are announced in advance and scheduled in a window you choose.; Rolling updates in patch management
N+1: Sizing with one unit in reserve: N components carry the planned load, and one more absorbs the failure of any one of them. We size the nodes of our clusters on this principle.; Redundancy design during cluster setup
Floating IP: An IP address that moves to another system automatically when the active one fails, so clients keep reaching the service at the same address. Our redundant load balancers share a floating IP.; Redundancy at every layer of an HA cluster

Storage, recovery and sites

Ceph: Distributed, self-healing storage with no central component that all access has to pass through; data is spread across the disks of all nodes (source 3). In the Essentials and Business packages, Ceph keeps every block in three copies on different nodes and restores the target redundancy on its own after a failure.; Managed Ceph clusters
ZFS replication: Replication based on ZFS: Proxmox VE copies a VM's data to another node at configurable intervals, so changes since the last run can be lost if a node fails (source 4). We use it in more compact, individually designed setups.; Ceph or ZFS compared
RTO (recovery time objective): The maximum time a system may be down after a failure. We determine the RTO during the initial assessment and set it together with you in the operations contract.; Defining RTO and RPO
RPO (recovery point objective): The maximum data loss you can accept, measured as a span of time before the failure. It determines how often data must be backed up or replicated and, like the RTO, is set in the operations contract.; How replication and backups shape your RPO
Geo-redundancy: Spreading systems, data or backups across physically separate data centers so that an event at one site does not hit every copy. Our second site, NBG01 in Nuremberg, holds backup copies outside the primary site FRA01 and serves as the second location for multi-site deployments.; Our second site NBG01

Network and contracts

Autonomous system (AS): As defined in RFC 1930, a connected group of IP prefixes with a single, clearly defined routing policy, run by one or more network operators (source 5). The network underneath your clusters is Cube-Hosting's AS47263.; What your own AS is good for
BGP (Border Gateway Protocol): The routing protocol between autonomous systems, used to exchange network reachability information (source 6). AS47263 peers over BGP at internet exchanges including ERA-IX Frankfurt, NL-ix and frankonIX.; Network AS47263 with its own BGP
Looking glass: A public interface that lets outsiders query a network's routing view. The prefixes and peerings of AS47263 are publicly documented on bgp.tools.; AS47263 at a glance, with links to verify
Data processing agreement (DPA, German: AV-Vertrag): The contract under Art. 28 GDPR: when a service provider processes personal data on behalf of your company, the GDPR requires a contract or other legal act for this (source 7). With us, the DPA is part of the contract documents under German law, and we process and store your cluster data exclusively in Germany.; Data processing agreement and data protection

Sources

Proxmox Server Solutions GmbH: Proxmox VE Administration Guide, chapter “Cluster Manager”. pve.proxmox.com, retrieved October 9, 2026.
Proxmox Server Solutions GmbH: Proxmox VE Administration Guide, chapter “High Availability”, section “Fencing”. pve.proxmox.com, retrieved October 9, 2026.
Ceph project (Ceph authors and contributors): Ceph documentation, “Architecture” (Tentacle release). docs.ceph.com, retrieved October 9, 2026.
Proxmox Server Solutions GmbH: Proxmox VE Administration Guide, chapter “Storage Replication”. pve.proxmox.com, retrieved October 9, 2026.
IETF: RFC 1930, Guidelines for creation, selection, and registration of an Autonomous System (AS), March 1996. rfc-editor.org, retrieved October 9, 2026.
IETF: RFC 4271, A Border Gateway Protocol 4 (BGP-4), January 2006. rfc-editor.org, retrieved October 9, 2026.
Regulation (EU) 2016/679 (General Data Protection Regulation), Art. 28 “Processor”, Official Journal of the European Union. eur-lex.europa.eu, retrieved October 9, 2026.

Glossary as of October 2026. Vendor statements, RFCs and legal provisions are marked with their source.

Next step

From the glossary to your own cluster architecture

Already know the availability target, RTO and RPO your application needs, or want to work them out? Describe your application and load profile. After the initial assessment, you receive a written design with an architecture diagram, a component list and a fixed price for setup and operations.

Request a project Explore managed Proxmox clusters