Store screen captures on fault-tolerant shared storage rather than in the database
Screen captures are the largest single data type a Syteca deployment produces. In a small deployment, storing them directly in the SQL database alongside session metadata is workable. In a medium or large deployment, database-resident screen captures cause two problems at once. The database grows fast and demands aggressive cleanup schedules. Video-format screen captures pushed through the database engine also cost query performance for reads that should be cheap. Moving screen captures to shared storage separates the two workloads. The database holds only session metadata, alerts, and configuration. Screen captures live on a shared storage volume that can be sized and scaled independently. Add Microsoft Failover Clustering and Storage Replica on top, and the storage layer becomes fault-tolerant: if one storage node fails, the cluster fails over to the surviving node without interrupting Client recording.Use shared storage High Availability when your deployment has any of the following characteristics:
- Medium or large scale, where database growth from screen captures becomes a maintenance burden.
- A tolerance-for-storage-failure requirement that a single storage node cannot meet.
- Multiple data center facilities where storage replication between sites is already part of the infrastructure story.
- Compliance retention requirements that would otherwise force expensive database growth.
The deployment scheme
Shared storage in HA mode uses Microsoft Failover Clustering with Storage Replica, in a configuration called Stretch Cluster Replication. The cluster consists of at least two nodes, and each node has its own storage endpoint. Storage Replica keeps the two endpoints synchronized; if one node fails, the cluster fails over to the other without exposing that failure to the Application Server or Client agents writing screen captures.
Shared storage HA deployment scheme with two failover cluster nodes and Storage Replica keeping their storage endpoints synchronized.
Stretch Cluster Replication is a configuration option of the broader Storage Replica technology. It is the configuration most suitable for hosting Syteca screen captures across two data center facilities. The original Microsoft documentation for Stretch Cluster Replication covers the underlying Windows Server feature in depth.
Prerequisites
Before starting the deployment, verify that the following infrastructure and Windows Server editions are in place.Network
An Active Directory domain, and a domain account with administrator permissions on the machines that will host the failover cluster nodes.Failover cluster nodes
At least two servers running one of the following Windows Server editions:The Datacenter edition is required for Storage Replica. Standard editions of Windows Server do not include Storage Replica and cannot be used for the cluster nodes.
Storage
At least two storage endpoints for use with the iSCSI Target feature. Other storage types exist and are compatible with Storage Replica, but only iSCSI is covered in this deployment guide. The storage layout has strict requirements:- Each storage endpoint is available to only one of the cluster nodes (asymmetric storage).
- Each storage endpoint allows the creation of at least two iSCSI virtual disks: one for data and one for logs.
- All physical data disks have the same sector size across the deployment.
- All physical log disks have the same sector size across the deployment.
- iSCSI virtual disks deployed on Windows Server require two network interfaces on the storage host.
- iSCSI virtual disks cannot be located on the same drive as the Windows operating system folder.
The deployment process
Deployment of shared storage in High Availability mode is done in four stages, performed in order. Each stage builds on the previous one; skipping ahead breaks the deployment.The deployment process
Deploying shared storage high availability has four stages: creating iSCSI virtual disks, deploying a failover cluster, adding that storage to the cluster, and configuring replication between storage endpoints.Stage 1: Create and configure iSCSI virtual disks
iSCSI virtual disks are created on Windows Server. Each storage endpoint connects to exactly one cluster node, forming a storage-node pair — repeat these steps for every pair.1
Install the iSCSI Target Server role
On the storage endpoint server, open Server Manager > Add Roles and Features. On Select server roles, expand File and Storage Services > File and iSCSI Services, select iSCSI Target Server, and complete the wizard.
2
Create the data disk
In Server Manager > File and Storage Services > iSCSI, start the New iSCSI Virtual Disk Wizard. Select the disk to store data on, name the virtual disk, set its size and type, leave New iSCSI target selected, name the target, and under Access Servers add the server that will become a failover cluster node. Complete the wizard.
3
Create the log disk
Repeat virtual disk creation for a second disk (to store logs), this time selecting Existing iSCSI target to reuse the target created above.
4
Install Multipath I/O on the cluster node
On the server that will become a failover cluster node, open Server Manager > Add Roles and Features, and on Select features select Multipath I/O. Restart the server after installation.
5
Enable iSCSI device support in MPIO
Open Administrative Tools > MPIO, select Discover Multi-Paths, select Add support for iSCSI devices, and click Add. Restart the server again.
6
Discover and connect to the iSCSI target
Open Administrative Tools > iSCSI Initiator (confirm starting the service if prompted). On the Discovery tab, click Discover Portal and enter the storage endpoint’s IP address or DNS name.
If the target isn’t reachable, confirm a firewall exception for port 3260 exists on the storage endpoint.
7
Connect with multi-path enabled
On the Targets tab, select Connect, select Enable multi-path, click Advanced, and select one of the storage endpoint’s IP addresses. Then open Properties > Add session, select Enable multi-path again, click Advanced, and select the second IP address.
8
Initialize the disks
Open Disk Management (
diskmgmt.msc). For each new disk: bring it Online, Initialize it with the GPT partition style, and create a new volume on its unallocated space.Stage 2: Deploy a failover cluster
See Microsoft’s Failover Clustering overview for full background. You need a domain user account with administrator permissions on every node, plus Create Computer Objects permission in the domain OU the servers belong to.
1
Install Failover Clustering on every node
On each server that will be a cluster node, open Server Manager > Add Roles and Features. Select the File Server role (under File and Storage Services > File and iSCSI Services), and on Select Features select both Failover Clustering and Storage Replica. Repeat for every node.
2
Validate the configuration
On one node, open Server Manager > Tools > Failover Cluster Manager, select Validate Configuration, enter the name of every server to add as a node, and run all tests. Review and resolve any warnings or failures before continuing.
3
Create the cluster
In Failover Cluster Manager, select Create Cluster, enter the same server names, and on Access Point for Administering the Cluster enter a cluster name and IP address. Complete the wizard.
Create the cluster only once, from any one of the nodes. Manage it afterward from any node by connecting to the cluster name or IP address in Failover Cluster Manager.
Stage 3: Add storage to the cluster and configure the file server role
1
Create a File Share Witness
On a cluster node, run PowerShell as administrator:Any network file share reachable by all nodes works — this improves storage reliability.
2
Add the iSCSI disks to the cluster
Run:Confirm the disks appear under Failover Cluster Manager’s Storage > Disks.
3
Create a File Server role
In Failover Cluster Manager, right-click Roles, select Configure Role, choose File Server, leave File Server for general use selected, enter a Client Access Point name, and select one disk as initial storage.
4
Create a File Share
Under Roles, right-click the new role and select Add File Share. Leave SMB Share – Quick selected, name the share where screen captures will be stored (note the Remote path to share value for later Application Server configuration), and optionally restrict permissions.
Stage 4: Configure storage replication
1
Enable replication on the source disk
In Failover Cluster Manager, select Storage > Disks, right-click the disk assigned to the File Server role, and select Replication > Enable.
2
Select the destination and log disks
In the Configure Storage Replica wizard, select the destination data disk, then the source log disk, then the destination log disk.
3
Choose the seeding and replication mode
Leave Overwrite destination volume selected on Seeded Disk, and select Asynchronous Replication on Replication Mode. Review and click Finish.
After a storage endpoint failure, the endpoint or its paired cluster node may need a reboot to bring the affected disks back online.
Related
Deployment architecture
Overall Syteca deployment architecture, including where shared storage fits.
High availability
High Availability and disaster recovery concepts across the whole deployment.
System requirements
Sizing guidance for Application Servers that will write to shared storage.
Application Server advanced settings
Application Server configuration options, including where the shared storage path is defined.