Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
A reliable Corosync–Pacemaker cluster has four essential layers: Corosync membership and quorum, Pacemaker resource management, tested fencing (STONITH), and service-specific resource agents. Build and test those layers in that order. A virtual IP and a web service are useful examples, but the same design applies to databases, file services, and custom applications when their data-replication model is designed separately.
What Corosync and Pacemaker each do
Corosync and Pacemaker are complementary, not interchangeable. Corosync supplies the communication and membership layer: nodes exchange cluster messages, determine which members are visible, and calculate quorum. Pacemaker consumes that membership information and decides where resources should run, when they should start or stop, and how to recover after a node or service failure.
Recommended Free Tools
- Corosync: cluster communication, membership, quorum, and transport configuration.
- Pacemaker: resource placement, failure recovery, ordering, colocation, and location decisions.
- Resource agents: service-specific start, stop, monitor, and (where supported) promote/demote operations. They are commonly supplied through the OCF resource-agents project or by a distribution.
- Fence agents: integrations that power off or isolate an unresponsive node through a BMC/IPMI controller, switched PDU, cloud fencing API, or another platform mechanism.
Pacemaker is a high-availability resource manager that uses Corosync messaging and membership to detect and recover from node and resource failures. It can manage anything that can be reliably scripted, but it cannot make an application’s data safe by itself. Stateful software still needs shared storage or a correctly designed replication mechanism.
Choose the topology before installing anything
Write down the failure model, node roles, storage design, and quorum plan before running cluster commands. Pacemaker can run an active/passive service, an N+1 arrangement in which spare capacity takes over, or a more specialized placement pattern. The cluster layer does not choose whether your application uses synchronous replication, asynchronous replication, or shared storage.
#1 Best Overall
- 12th Intel Alder Lake N95 Processor – The GMKtec G3 S Mini PC is powered by the 12th Gen Intel N95 processor with 4 cores, 4 threads, 6MB cache and a burst frequency up to 3.4GHz. Compared with N100/N5105/N5100/N5095, the N95 delivers up to 36% overall performance improvement. Perfect for routine tasks, office work, and home entertainment, this compact mini desktop is more convenient than traditional bulky PCs.
- 8GB RAM & 256GB SSD Storage – Pre-installed with 8GB DDR4 memory and a fast 256GB M.2 2242 SSD, the G3 S mini desktop offers quicker startup, smoother multitasking, and faster file transfers. Enjoy seamless performance whether you’re working on multiple applications, browsing, or streaming content.
- Rich Interfaces & Connectivity – The G3 S mini computer comes equipped with USB 3.2 (up to 10Gbps), dual HDMI 2.0 (4K@60Hz), and a 3.5mm audio jack. With support for WiFi 5, Bluetooth 5.0, and Gigabit Ethernet (RJ45 1000MbE), it connects easily with monitors, projectors, printers, office equipment, and other peripherals, making it versatile for both home and business use.
- Dual 4K Display Support – Featuring upgraded Intel UHD Graphics (up to 1000MHz), the G3 S supports 4K video playback and AV1 decoding for a smooth viewing experience. With dual HDMI outputs, you can connect two 4K@60Hz displays simultaneously, enabling efficient multitasking for work and entertainment.
- GMKTEC WARRANTY - GMKtec offers a 3-year limited warranty (1 year replacement + 2 years parts replacement) for each mini PC, starting from the date of the purchase effective on all sales starting Oct. 2026. All defects due to design and workmanship are covered. With a professional after sales team always ready to attend to your needs, you can simply relax and enjoy your mini PC
| Design decision | Questions to answer | Operational consequence |
|---|---|---|
| Node count and quorum | How many votes exist, and what happens when a node or network path is lost? | More than half of the votes is normally required. A partition without quorum should not continue writing. |
| Fencing method | Can each node be independently powered off or isolated when it is unresponsive? | Fencing must not depend solely on the failed node or the same network path that may be partitioned. |
| Data placement | Will the service use shared storage, block-level replication, database replication, or another method? | Pacemaker moves service control; it does not replicate application data. |
| Placement model | Is the service active on one node, spread across several nodes, or backed by N+1 spare capacity? | Location, colocation, and ordering constraints encode the intended behavior. |
| Network transport | Are cluster links isolated or redundant, and which Corosync transport does the distribution support? | Transport and firewall settings affect membership stability and recovery behavior. |
| Lifecycle and operations | Will the operating-system release, Pacemaker, Corosync, and agents receive security updates for the service lifetime? | Use a supported distribution and rehearse upgrades and failover before production. |
A two-node cluster deserves special treatment. Losing either node also removes a majority, so a surviving node may lose quorum even though it is healthy. Plan an independent arbitration mechanism, such as a Corosync qdevice hosted by a third system, where appropriate. Watchdog-based SBD can provide self-fencing without shared storage, but a two-node watchdog design still needs external quorum according to ClusterLabs guidance.
Prepare every node
Give nodes stable identity and time
Assign each node a permanent hostname and address, ensure forward and reverse name resolution where your distribution expects it, and synchronize clocks with the site’s time service. Avoid changing hostnames or addresses after cluster creation. Use separate, dependable paths for management, application traffic, and cluster traffic when the environment allows it.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesInstall the complete software set
Install Corosync, Pacemaker, the pcs command-line tool (or the crm shell if that is your operational standard), resource agents, and fence agents on every intended member. Package names and versions vary by distribution; the following are representative commands from ClusterLabs documentation:
| Distribution family | Representative installation command |
|---|---|
| Fedora | dnf install -y corosync pacemaker pcs |
| RHEL-compatible systems | yum install -y corosync pacemaker pcs |
| openSUSE | zypper install corosync pacemaker |
| Debian-compatible systems | apt-get install pacemaker corosync |
Add the packages named resource-agents and fence-agents, or their distribution-equivalent packages. Without them, the daemons may run while the cluster lacks the service and fencing integrations needed for a usable deployment.
Open only the required traffic
Permit the cluster-management traffic used by pcs, Corosync traffic on the interfaces and ports selected by your distribution, and the management path to each fencing device. The Ubuntu pcs reference documents knet, UDP/UDPU transports, quorum options, startup, waiting, and authentication-key synchronization; follow the syntax shipped with your release rather than copying options from a different version.
Create the cluster with pcs
The exact service names and authentication defaults differ among distributions, but the workflow is consistent. Perform these commands with administrative privileges and substitute your real node names and addresses.
- Start and enable the pcs daemon on every node. Use your distribution’s service manager to enable and start
pcsd. Confirm that the daemon is listening on its management interface before continuing. - Authenticate the nodes. From the node you are using as the administrative entry point, authenticate the intended members with the
pcs host authcommand and the credentials configured forpcsd. Authentication distributes the keys needed for cluster administration; it does not yet create the Corosync membership. - Define the cluster. Run
pcs cluster setupwith a cluster name and the complete node list. Include the transport and ring/interface options required by your distribution. Verify that every hostname resolves to the address you intend for Corosync. - Enable and start cluster services. Enable the cluster stack at boot and start it on all members using
pcs cluster enable --allandpcs cluster start --all, or the equivalent commands documented for your release. - Wait for membership. Use
pcs cluster wait_for_startupwhen available, then inspectpcs status. Do not create production resources until all intended nodes appear and quorum is healthy.
At this stage, check the Corosync transport, node addresses, firewall rules, and authentication keys. A cluster that intermittently loses membership is not ready for service resources; adding constraints will not repair an unstable communication layer.
Configure and test fencing before applications
Fencing, also called STONITH (Shoot The Other Node In The Head), prevents a node that is presumed failed from continuing to access shared resources. Pacemaker must be able to isolate that node before allowing another node to take over a resource whose concurrent use could corrupt data.
Rank #2
- High-Performance NAS with Powerful Procesor: Intel Core 5 320 is ideal for small offices, & More. You can enjoy smooth performance and seamless collaboration, while making use of advanced features like Docker and virtual machines. It works semalessly across every device inluding Windows, macOS, Linux, iOS, Android or Google services and so on.
- Better Way to Store Than External Drives: NAS offers centralized storage, automatic backups, remote access, and a wide range of RAID options for easy data recovery even if a drive fails. Massive Storage Capacity: Never worry about storage limits again. With up 144TB capacity, you can store 50 million 1MB photos or 98K 1.5GB movies，5 million 30MB songs! *Hard Drives not included.
- Secure Private Cloud: Retain 100% data ownership with advanced encryption to protect your files. Flexible permission management makes it easy to protect your privacy when collaborating with others.
- AI-Powered Photo Album: Automatically organizes your photos by recognizing faces, scenes, objects, and locations. It can also instantly remove duplicates, freeing up storage space and saving you time.
- User-Friendly App: Simple setup and easy file-sharing on Windows, macOS, Android, iOS, web browsers, and smart TVs, giving you secure access from any device.
Select an independent fence agent
Choose an agent that matches the actual platform: a BMC or IPMI controller for physical servers, a switched PDU, a cloud provider’s fencing API, or another supported mechanism. Record the credentials, management addresses, and permitted actions. The agent must be able to fence each assigned node even when that node’s operating system and cluster services are unavailable.
Define the fence device
Use pcs stonith create with the fence agent’s exact resource-agent name and parameters. Parameters differ by vendor, so obtain the syntax from the installed agent metadata (for example, with pcs stonith describe <agent-name>) and your platform documentation. Assign explicit node mappings when the device controls more than one server.
Prove that fencing works
- Confirm that the fence agent can query the device and identify every target node.
- Run a controlled fence operation against a non-production node or during a maintenance window.
- Verify that the target actually powers off or becomes unable to access protected storage and networks.
- Inspect fencing history and
pcs statusfrom the surviving node. - Restore the fenced node, check its filesystems and application state, and only then allow it to rejoin.
Never disable fencing simply to make a resource start. If the cluster cannot prove that an old owner is isolated, allowing a new owner to write can produce split-brain corruption.
Set quorum deliberately, especially with two nodes
Quorum normally requires more than half of the cluster’s votes. For example, in a six-node cluster, at least four votes are needed. Red Hat documents that Pacemaker stops all resources by default when the cluster loses quorum. This default is a safety behavior: a partitioned group must not continue writing as though it were the whole cluster.
Use a third vote for a two-node design
In a two-node arrangement, losing the inter-node link can leave both nodes believing the other is absent. An independent qdevice or another supported arbitration design gives the cluster a tie-breaker. Keep the arbitrator outside the failure domain of both primary nodes when practical; placing it on the same host or network equipment defeats its purpose.
Understand SBD and watchdog fencing
SBD can use watchdog-based self-fencing and, in some designs, shared storage. ClusterLabs notes that a two-node watchdog arrangement needs external quorum such as Corosync qdevice with a third node. Treat watchdog configuration, timeout values, and hardware support as production safety settings, not as optional tuning.
Check quorum before enabling resources
Use pcs quorum status and pcs status to verify expected votes, membership, and quorum state. If quorum is unexpectedly lost, stop and repair communication or arbitration rather than overriding the policy. Any exception to the default resource-stop behavior must be justified by a documented failure model and tested for data-safety consequences.
Create a virtual IP and service resource
The following pattern illustrates a floating address followed by a web service. Replace the addresses, interface assumptions, and agent names with values supported by your distribution. The example assumes that the service is installed identically on each node and that its data is already replicated or available through shared storage.
Rank #3
- Built for Local AI Development: AMD Ryzen AI Halo is designed for local AI development and inference, featuring 128GB unified memory and support for up to 200B parameter models to build and run intensive AI workloads locally.
- 128GB Unified Memory: Features 128GB LPDDR5x unified memory at 8000 MT/s with 256 GB/s memory bandwidth, providing a shared memory pool across the CPU, GPU, and NPU to support larger AI models.
- AMD Ryzen AI Max+ 395 Processor: Features 16 cores, 32 threads, and Zen 5 architecture, paired with AMD Radeon 8060S integrated graphics featuring 40 RDNA 3.5 compute units and an AMD XDNA 2 NPU with up to 50 TOPS.
- Linux AI Developer Platform: Purpose-built for Linux-based AI development with full AMD ROCm software support and preloaded tools, models, and workflows optimized for local AI development.
- Compact, Connected Design: Includes a 2TB M.2 SSD, 10GbE LAN, Wi-Fi 7, Bluetooth 5.4, USB-C connectivity, and HDMI 2.1b.
Add the resources
pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.0.2.50 cidr_netmask=24 op monitor interval=30s
pcs resource create WebSite ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf op monitor interval=30sThe first command creates a monitored virtual IP resource. The second uses an Apache resource agent; use the agent supplied for your actual service and inspect its parameters before creating it. A monitor operation tells Pacemaker how to detect a failed service. Choose an interval that provides useful detection without creating unnecessary load.
Encode startup and placement dependencies
pcs constraint order ClusterIP then WebSite
pcs constraint colocation add WebSite with ClusterIP INFINITYThe ordering constraint starts the address before the service and reverses that order during a controlled stop. The infinite colocation rule keeps the service on the node that owns the address. Add location rules when one node is preferred or prohibited, for example to keep a workload away from a node with insufficient capacity. Inspect the resulting rules with pcs constraint config.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Start and observe the resources
pcs resource enable ClusterIP WebSite
pcs status
pcs resource status ClusterIP
pcs resource status WebSiteConfirm that the virtual address is present on exactly the intended node, that the service monitor is reporting success, and that clients can connect through the floating address. A resource shown as started is not proof that the application is healthy; validate the application protocol from a client as well.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Model more complex services with constraints
Ordering constraints
Use ordering when one action must precede another: mount storage before starting a database, start a database before a dependent API, or stop consumers before unmounting storage. Prefer mandatory ordering for safety-critical dependencies; avoid creating a long chain unless every link is necessary, because one failed prerequisite can hold the entire chain.
Colocation constraints
Colocation expresses where resources should run together. A dependent application and its local filesystem or virtual IP commonly use an infinite score. For replicated databases, colocation may need to follow the promoted primary role rather than merely matching a node; use the resource agent’s documented master/promoted semantics.
Location rules
Location preferences can keep a workload on its normal node while permitting failover elsewhere. Prohibitions can reserve a node for another service or avoid known hardware limitations. Review the effective scores after adding multiple rules; an unexpected placement often comes from a higher-scoring rule rather than a failed resource.
Validate failover instead of assuming it
Failover tests belong in a maintenance window with an application owner watching the service. Record the expected owner, fencing result, outage symptoms, and recovery time for each test; no universal failover-time figure applies across distributions, hardware, transports, and workloads.
- Baseline health: capture
pcs status, quorum status, node membership, active constraints, and fencing history while all nodes are healthy. - Service failure test: stop the managed service outside Pacemaker or deliberately make its monitor fail. Confirm that Pacemaker detects the failure and restarts or relocates it according to policy.
- Node failure test: fence or power off the active node through the approved test procedure. Confirm that the surviving node obtains quorum, fencing completes, and resources start only after isolation.
- Client validation: connect through the virtual IP or application endpoint, perform a write/read transaction appropriate to the service, and verify that data remains consistent.
- Return test: repair the failed node, let it rejoin, and verify whether the configured location rules keep resources on the current owner or move them back intentionally.
- Document recovery: save status output, fencing events, logs, and operator actions. Turn successful steps into a runbook and record unsafe or ambiguous behavior as a defect.
Use pcs status, pcs quorum status, pcs stonith history, resource-agent monitor operations, and constraint listings during every exercise. Documentation examples commonly show quorum, node membership, a fence resource, a virtual IP, a service, and their constraints together; your output should make those relationships visible.
Troubleshoot the failures that matter most
Nodes do not appear as members
- Check hostname resolution and that each node uses the intended Corosync address.
- Verify firewall rules and transport settings, including whether the configuration expects
knet, UDP, or UDPU. - Confirm synchronized time and that authentication keys were distributed to every node.
- Inspect Corosync logs for interface, encryption, or token-timeout errors before changing quorum policy.
The cluster has no quorum
- Use quorum status to determine which votes are visible.
- Repair the failed communication path or bring back the missing member; do not force resources online merely to bypass the stop-on-no-quorum safety behavior.
- For two nodes, verify that the planned qdevice or other arbitrator is reachable and counted as designed.
Fencing fails or times out
- Test the fence agent manually with the same credentials and target mapping used by Pacemaker.
- Check out-of-band network reachability, power-controller permissions, and unique node identifiers.
- Increase a timeout only after confirming that the device is reachable; a larger timeout does not fix incorrect credentials or an unreachable controller.
- Keep resources stopped until the cluster can isolate the suspected node reliably.
A resource will not start or keeps moving
- Run the resource agent’s monitor operation and inspect its logs for missing files, permissions, ports, or configuration errors.
- List constraints and failure history; a negative location score or an unmet ordering prerequisite may be intentional.
- After correcting the cause, clear the recorded failure with the appropriate
pcs resource cleanupcommand, then observe one complete monitor cycle.
The service starts but clients cannot connect
- Confirm that the virtual IP is assigned to the node shown by Pacemaker and that the interface announces it correctly.
- Check host and network firewalls, routing, DNS or ARP behavior, and the service’s listen address.
- Test the application through the managed endpoint, not only through localhost on the active node.
Production checklist
- Supported operating-system release and matching Corosync, Pacemaker, agent, and fencing packages on every node.
- Stable names, addresses, time synchronization, documented interfaces, and tested firewall rules.
- Independent fencing that has successfully powered off or isolated every target node.
- Quorum policy reviewed for the actual vote count, with arbitration designed for two-node failure scenarios.
- Explicit storage or application-replication design for every stateful service.
- Resource monitors, ordering, colocation, and location constraints that match real dependencies.
- Controlled tests for service failure, node loss, fencing, client access, data consistency, and node return.
- A runbook containing status commands, fencing procedures, maintenance mode steps, escalation contacts, and rollback actions.
What a safe design looks like
A dependable deployment is not defined by a clever pcs command sequence. It is a system in which Corosync can maintain an accurate membership view, Pacemaker has enough quorum to make decisions, fencing can isolate a failed member independently, and resource agents accurately represent application health. Once those foundations are proven, virtual IPs and service resources can fail over predictably. Without them, an apparently active service may still be exposed to split-brain, stale ownership, or data corruption.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
