QuTS hero h6.0 Beta - High Availability Limitations and Improvement Recommendations
Active-Passive HA Limitations in Complex Network Topologies
QNAP QuTS hero h6.0 Beta introduces High Availability (HA) functionality, which is a significant step toward enterprise-level solutions, I use in real live active-standby and Active-Active solutions. However, the current implementation is effective only within a single network segment, which creates substantial limitations in modern IT infrastructures, this is my opinion.
The Problem: VLAN and Network Segmentation
Scenario 1: VLAN Segmentation
In enterprise environments, it’s common practice to organize infrastructure with VLAN segmentation or different network locations.
-
Heartbeat connection through VLAN routing is unreliable, but it can be used in large systems
-
Network latency and packet loss can trigger false-positive failover
-
Network loops or spanning-tree can interrupt communication
Scenario 2: Split-Brain with Dual-Passive
Critical case - Both nodes become Passive:
Initial state:
[Active Node A - VLAN 10] ←→ [Standby Node B - VLAN 20]
Network issue (VLAN routing problem)
Active A: "I didn't lose heartbeat from B, but B doesn't respond"
Result:
-
BOTH nodes are in Passive mode
-
Neither serves clients
-
Complete service outage
-
Data not synchronized (no Active node making changes)
-
Manual administrator intervention required
Scenario 3: Split-Brain with Dual-Active
Even more critical case - Both nodes become Active:
[Active Node A - VLAN 10] ←→ [Passive Node B - VLAN 20]
Network issue (VLAN routing problem)
Clients write data to Node A and Node B
Result:
-
Data divergence - two incompatible data versions
-
Data corruption risks when connection is restored
-
Guaranteed data loss in one of the versions
Why the Current Architecture is Limited
1. Lack of Quorum Witness Mechanism
-
Witness determines which node can become Active
-
Node without quorum CANNOT become Active
-
Prevents split-brain situations
QuTS hero h6.0: Witness functionality appears to be unavailable.
2. Strict Local Network Requirement
The HA system is designed for a dedicated heartbeat connection through a direct Ethernet cable at QNAP, which:
-
Works great in a single network segment and same physical space
-
Doesn’t work through VLAN routing
-
Doesn’t work for geographically distributed nodes
-
Doesn’t work in complex network topologies
Real Use Cases That Don’t Work
Problem: Heartbeat through VLAN trunk is unreliable.
What will be nice to see QuTS hero
1. Client-Selectable HA Mode:
HA Configuration Wizard:
┌─────────────────────────────────────────┐
│ Select High Availability Mode: │
│ │
│ ○ Active-Passive │
│ ○ Active-Active │
└─────────────────────────────────────────┘
2. Quorum Witness Support
┌─────────────────────────────────────────┐
│ Configure Quorum Witness: │
│ │
│ Witness Type: │
│ ○ Third NAS example QCenter │
│ ○ Cloud (myQNAPcloud) │
└─────────────────────────────────────────┘
3. Active-Active Architecture Option
Advantages:
-
Both nodes actively serve clients
-
Better resource utilization
-
Higher overall performance
-
Smooth failover
Optimal Features (Should-Have):
Active-Active Mode:
-
Cluster filesystem support
-
Load balancing integration
Advanced Monitoring:
-
Real-time cluster health dashboard
-
Predictive failure analysis
-
Automated failover testing
Conclusion
QuTS hero h6.0 Beta Active-Passive HA is a good start, but:
Current limitations:
-
Works only in simple network topologies
-
No Active-Active option
-
Not suitable for complex enterprise environments in different places
What is needed:
-
Client choice: Active-Passive OR Active-Active
-
Network flexibility: VLAN and multi-site support
In my case, “High Availability Cluster” would be a better offering if the client could choose between active-passive or active-active systems, depending on specific infrastructure requirements, network topology, availability objectives, as well as the client’s resource capabilities.