Proxmox VE Clustering and Shared Storage

Before creating a cluster, assess node dependencies, network paths and data placement. Separate centralized administration from surviving a failure. Include the capacity needed when one server is taken out of service.

In practice: Identify components whose failure can affect several nodes simultaneously.

Understand cluster-member communication and configuration distribution. Quorum protects cluster decision-making; it does not vote on whether an application is running. Assess loss of quorum against node state and communication paths.

In practice: Read cluster status and distinguish membership, configuration and guest-availability issues.

Design for management traffic, cluster communication, guest migration and storage traffic. Consider latency and concurrent transfers as well as addressing. Check whether supposedly redundant paths depend on the same component.

In practice: Assess a simulated link failure and the resulting availability of each traffic type.

Compare approaches to shared data and their relationship to migration. Distinguish storage configuration visible in cluster management from actual disk accessibility on the target node. Consider differences between file and block backends.

In practice: Verify the prerequisites for moving a guest between two nodes.

Distinguish the roles of MON, MGR and OSD services and understand storage running alongside virtualization on the same servers. Plan disk capacity, CPU, memory and networking for both normal operation and recovery after a failure.

In practice: Read a Ceph health overview and relate each service to its purpose.

Distinguish RBD block devices from file access through CephFS. Explore the relationship between pools, data placement and resilience. Assess disk and node maintenance against remaining capacity and recovery status.

In practice: Determine what to check before planned storage maintenance using a sample cluster state.

Assess a guest move against CPU compatibility, disk access, networking and locally attached devices. Evaluate VMs and containers separately: do not assume the same migration process or uninterrupted operation for every workload.

In practice: Prepare a migration preflight checklist and verify the service on the destination node.

Understand replication-job scheduling, monitoring and its relationship to guest migration. A replica is not necessarily an up-to-the-moment copy: after a failure, recovery depends on the last successful transfer.

In practice: Assess a delayed replica and identify the data state that can be expected during recovery.

Relate HA resources to node and data availability. Understand why the same workload must not start simultaneously on isolated nodes. Distinguish restarting a guest after failure from the availability of the application inside it.

In practice: Walk through HA decisions and check the prerequisites for safe workload recovery.

Assess node, network and storage faults separately. Observe service availability and data state as well as the cluster response. Restored connectivity does not necessarily mean that storage recovery has completed.

In practice: Record a sample incident, expected behaviour and the conditions for concluding the intervention.

Explore a small cluster with an external quorum vote. A QDevice assists quorum decisions; it adds neither compute capacity nor another copy of data. Consider the independence of its location and its connectivity.

In practice: Assess what happens when a node, interconnect or external vote becomes unavailable.

Understand how the web interface relates to the REST API and CLI tools. Separate authentication, authorization, task submission and result verification in automation. Focus diagnostics on the specific failing layer.

In practice: Design restricted automation access and a check that verifies the result of its request.