Joe Poyzer

Specializing in networking, systems, cloud, and automation.

📌 Overview

This lab covers building a two-node Windows Server 2025 failover cluster in a workgroup (non-domain) configuration, backed by iSCSI shared storage hosted on a Linux LIO target. The goal was to understand what actually has to be true at the storage and networking layer for Windows clustering to work — not just follow a guide end to end, but hit real failures and fix them.

Environment:

  • 2x Windows Server 2025 VMs (workgroup, not domain-joined)
  • Shared storage: iSCSI target on Linux, using LIO (Linux-IO Target)
  • Quorum: Disk witness, backed by the same iSCSI storage
  • Host: Cisco UCS C220 M3, running Proxmox VE

🗄️ Storage Design

Before any cluster configuration, the underlying physical storage on the UCS host needed to be laid out correctly across 8 available drive bays:

  • RAID 1 (2x HDD) — OS/boot volume
  • RAID 10 (4x SSD) — active VM storage, chosen for rebuild characteristics (mirrors, not parity recalculation) and better random I/O under cluster workloads
  • RAID 1 (2x HDD) — cold storage and backups

🔧 Objectives

  • Deploy a two-node workgroup failover cluster on Windows Server 2025
  • Configure iSCSI shared storage using a Linux-based target
  • Select and configure appropriate cluster quorum
  • Pass cluster validation, including SCSI-3 Persistent Reservation checks
  • Bring the cluster online with functional shared storage

⚖️ Quorum Design

Since this was a workgroup cluster (no Active Directory), quorum configuration required extra attention. A disk witness was used, backed by a small LUN on the iSCSI target — the right call for a single-site cluster with shared storage already available. A cloud witness would be the better fit for a multi-site cluster without shared storage, which wasn't the case here.

🚧 The SCSI-3 Persistent Reservation Problem

Windows failover clustering requires the shared disk to pass SCSI-3 Persistent Reservation (PR) validation — a mechanism that lets both cluster nodes coordinate access to the shared disk and prevents split-brain scenarios where both nodes think they own the disk simultaneously.

Cluster validation kept failing at this exact check. The shared iSCSI LUN was visible to both nodes, but the PR handshake wasn't completing.

Root cause: the issue was on the Linux iSCSI target side, in the Target Portal Group (TPG) attributes:

  • generate_node_acls needed to be enabled, so the target would properly authenticate the initiators (the Windows nodes) rather than rejecting the reservation request outright
  • auth_attr_enforcing needed to be disabled, since strict authentication enforcement was interfering with how the cluster nodes negotiated the SCSI-3 reservation

Once both settings were corrected on the LIO target, cluster validation passed cleanly and the cluster came online with fully functional shared storage.

📈 Results

  • Cluster validation passed cleanly after correcting the iSCSI target's TPG attributes
  • Two-node failover cluster came online with fully functional shared storage
  • Disk witness quorum confirmed healthy
  • Storage I/O stabilized after replacing the SMR drive and failing SSD

📝 Notes / Lessons Learned

  • SCSI-3 PR validation issues are almost always a storage-side configuration problem, not a Windows problem — when clustering fails at this step, the fix usually lives in the iSCSI target's authentication and ACL settings
  • RAID level choice should be driven by workload, not just redundancy needs — RAID 10 for active cluster/VM storage was the right call specifically because of its rebuild behavior and random I/O performance
  • Quorum design should match cluster topology — a disk witness made sense here because this was a single-site cluster with shared storage already in place