A Technical Whitepaper for Self-Hosted Environments

1. The Web Tier: Load-Balanced IIS

To prevent a single IIS server from becoming a bottleneck or a single point of failure, SpiraPlan should be deployed across multiple web nodes.

Load Balancer Redundancy

A single load balancer (LB) is a risk. We recommend an Active-Passive HA Pair using a Virtual IP (VIP).

• The Mechanism: A VIP is shared between two LB instances (e.g., F5 Big-IP, Kemp, or HAProxy). If the primary LB fails, the VIP migrates to the secondary in milliseconds.

• Health Probes: The LB must be configured to "ping" the SpiraPlan Services/Default.aspx page. If a node fails the health check, it is automatically removed from the rotation.

• Session Persistence: SpiraPlan by default requires "Sticky Sessions" (Source IP or Cookie-based affinity). This ensures a user’s session stays on the same IIS node for the duration of their task.

2. The Database Tier: SQL Server Options

SpiraPlan relies heavily on SQL Server. Customers can choose between two primary clustering models depending on their infrastructure and recovery time objectives (RTO).

Option A: Failover Cluster Instances (FCI)

FCI provides protection for the entire SQL Instance using shared storage (SAN).

• How it Works: SQL Server is installed on a Windows Server Failover Cluster (WSFC). If Node A fails, the SQL services start on Node B and mount the same shared drive.

• Pros: Simple licensing (standard edition often suffices); handles all logins and Agent jobs automatically.

• Cons: Shared storage is a single point of failure unless the SAN itself is redundant; failover takes 30–60 seconds as services must restart.

Option B: Always On Availability Groups (AG)

AG provides protection at the database level using local storage and data replication.

• How it Works: Data is synchronized between Node A and Node B in real-time. An Availability Group Listener provides a single connection point for IIS.

• Pros: Rapid failover (usually <10 seconds); no shared storage required; secondary nodes can be used for read-only reporting.

• Cons: Requires SQL Server Enterprise Edition (for more than one DB); requires manual synchronization of SQL Logins and Agent Jobs across nodes.

3. Comparison Matrix for Decision Makers

4. Implementation Best Practices for SpiraPlan

Connection Strings

For Always On AG deployments, the IIS web.config connection string must be updated to point to the Listener Name. To ensure fast recovery across subnets, include:

MultiSubnetFailover=True

Distributed Attachments

By default, SpiraPlan saves attachments to a local file system. In an HA environment, you must redirect these to a redundant UNC path (e.g., a clustered File Server or high-availability NAS) so all IIS nodes can access the same files.

External Session State

While "Sticky Sessions" work for simple load balancing, for true resilience, consider using a Redis or SQL-backed Session State. This allows a user to stay logged in even if the specific IIS node they were connected to disappears. SpiraPlan does support database-backed sessions. Please contact our support team for details on how to enable and configure this.

Conclusion

The choice between FCI and Always On AG often comes down to your existing storage infrastructure and SQL Server licensing. For most SpiraPlan customers, an N+1 IIS Tier combined with SQL Always On provides the most robust, modern, and performant environment for enterprise ALM.