(Failover Cluster) Domain Controller의 역할

🧠 TL;DR Summary:

✅ A Domain Controller (DC) is required for:

• Cluster formation and authentication
• Name resolution (via DNS)
• Accessing domain-joined resources (e.g., SMB)
• Cluster-aware updates, GPOs, and live migration authentication

However, once the cluster is already formed, certain operations (like S2D and CSV access) can continue without the DC — but with reduced functionality and higher risk.

---

🔍 1. Domain Controller's Role in Failover Clustering

Function	Role of Domain Controller
Cluster Creation	Required — nodes must authenticate with the domain to form/join the cluster.
Cluster Startup	Required — during initial boot, cluster service authenticates via the domain.
Quorum Witness Access (File Share)	Must resolve and authenticate to access file share quorum.
Cluster Name Object (CNO)	Stored in Active Directory. Requires DC to register and update.
Live Migration	Uses Kerberos authentication → requires DC & DNS.
DNS Resolution	All cluster nodes resolve cluster name, witness, and partners through DNS.
Hyper-V Authorization	Uses AD credentials for remote management, permissions, and constrained delegation.

 

💡 Without a reachable DC, some features will hang or fail (especially Live Migration, witness arbitration, or remote cluster management).

---

📦 2. Domain Controller's Role in S2D and CSV

Feature	Dependency on DC
Storage Spaces Direct (S2D)	❌ No direct dependency once initialized.
Cluster Shared Volumes (CSV)	❌ CSV redirection and IO can still function without AD.
Cluster Health Service	✅ Requires AD for some telemetry/reporting features.
Cluster-Aware Updating (CAU)	✅ Requires domain credentials & GPOs.

 

✅ Good news: S2D & CSV can keep running for a time without AD, assuming cluster membership is intact.

❗ But if the cluster service restarts on a node, or if Live Migration or authentication is needed — the absence of a DC causes issues.

---

🚫 What Fails Without a DC

Component	What Fails Without DC
Cluster Name Resolution	Cluster name (CNO) might not register; clients can't connect.
File Share Witness	Unreachable — quorum may be lost.
Live Migration	Kerberos fails — migration errors occur.
Cluster Join/Restart	Nodes can't rejoin cluster if DC is unreachable during boot.
Hyper-V Replica / SMB	May fail due to auth issues.
Remote Management	MMC, DMC, PowerShell remoting may fail (depends on delegation/auth).

 

---

✅ Best Practices

1. Always have at least 2 DCs — preferably one outside the cluster (e.g., physical, VM on another host, or cloud-hosted).
2. Ensure DC/DNS is reachable via multiple cluster networks.
3. Use cloud witness (Azure) or file share witness outside the cluster — don't place the witness on a clustered VM.
4. Avoid putting all your DCs as VMs on the same S2D cluster — major SPOF risk.

---

🔄 Bonus: If Your DC is on the Same Cluster...

• Boot order becomes critical.
• Cluster might hang on start if:
  • The DC VM isn't online.
  • DNS isn't reachable.
  • Kerberos fails.

👉 Workaround: Set one cluster node to delay booting cluster service until DC is up, or configure DC to start on all nodes (not ideal).

---

🧪 Want to Test It?

• Try simulating a DC outage and observe:
  • Can nodes stay in the cluster?
  • Can you migrate VMs?
  • Can you connect from Failover Cluster Manager?