> ## Documentation Index
> Fetch the complete documentation index at: https://syteca.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Shared Storage High Availability

> Deploy shared storage in High Availability mode for Syteca screen captures using Microsoft Failover Clustering and Storage Replica. Recommended for medium and large deployments.

## 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.

<Info>
  **Use shared storage High Availability when your deployment has any of the following characteristics:**

  1. Medium or large scale, where database growth from screen captures becomes a maintenance burden.
  2. A tolerance-for-storage-failure requirement that a single storage node cannot meet.
  3. Multiple data center facilities where storage replication between sites is already part of the infrastructure story.
  4. Compliance retention requirements that would otherwise force expensive database growth.

  For smaller deployments with modest Client counts and short retention windows, database storage of screen captures is simpler and adequate.
</Info>

<Warning>
  **NOT AVAILABLE IN SAAS.** Shared storage HA is a self-hosted infrastructure pattern configured against the Syteca on-premises deployment.
</Warning>

## 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.

<Frame caption="Shared storage HA deployment scheme with two failover cluster nodes and Storage Replica keeping their storage endpoints synchronized.">
  <img src="https://mintcdn.com/syteca/0FlD-vkHsBA1azVX/images/administration/deployment/shared-storage-ha-scheme.png?fit=max&auto=format&n=0FlD-vkHsBA1azVX&q=85&s=f287eb9aa57e9d0d1b3a984f69e50cb9" alt="Two-node Microsoft Failover Cluster with Storage Replica providing shared storage for Syteca screen captures" width="677" height="526" data-path="images/administration/deployment/shared-storage-ha-scheme.png" />
</Frame>

<Note>
  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](https://docs.microsoft.com/en-us/windows-server/storage/storage-replica/stretch-cluster-replication-using-shared-storage) covers the underlying Windows Server feature in depth.
</Note>

## 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:

| Windows Server edition                                  | Notes                                                |
| ------------------------------------------------------- | ---------------------------------------------------- |
| **Windows Server 2022 Datacenter Edition**              | Latest and recommended.                              |
| **Windows Server 2019 Datacenter Edition**              | Supported.                                           |
| **Windows Server 2016 Datacenter Edition version 1709** | Supported. Earlier 2016 editions are not sufficient. |

<Note>
  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.
</Note>

### 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:

1. Each storage endpoint is available to only one of the cluster nodes (asymmetric storage).
2. Each storage endpoint allows the creation of at least two iSCSI virtual disks: one for data and one for logs.
3. All physical data disks have the same sector size across the deployment.
4. All physical log disks have the same sector size across the deployment.
5. iSCSI virtual disks deployed on Windows Server require two network interfaces on the storage host.
6. 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.

| Stage                                                                         | What the stage does                                                                                                                      |
| ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **1. Create and configure iSCSI virtual disks**                               | Provision iSCSI targets and virtual disks on the storage endpoints. Format and prepare disks for both data and log storage.              |
| **2. Deploy a failover cluster**                                              | Install the Microsoft Failover Clustering feature on the cluster nodes. Configure the cluster with quorum and network settings.          |
| **3. Add storage to the failover cluster and configure the File Server role** | Add the iSCSI virtual disks as cluster shared storage. Configure the file server role that Syteca will target for screen capture writes. |
| **4. Configure Storage Replication**                                          | Enable and configure Storage Replica in Stretch Cluster Replication mode to keep the storage endpoints synchronized.                     |

## The deployment process

<Warning>
  **NOT AVAILABLE IN SAAS.**
</Warning>

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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.

    <Note>
      If the target isn't reachable, confirm a firewall exception for port 3260 exists on the storage endpoint.
    </Note>
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

### Stage 2: Deploy a failover cluster

<Note>
  See Microsoft's [Failover Clustering overview](https://docs.microsoft.com/en-us/windows-server/failover-clustering/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.
</Note>

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.

    <Note>
      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.
    </Note>
  </Step>
</Steps>

### Stage 3: Add storage to the cluster and configure the file server role

<Steps>
  <Step title="Create a File Share Witness">
    On a cluster node, run PowerShell as administrator:

    ```powershell theme={"system"}
    Set-ClusterQuorum -FileShareWitness \\someserver\someshare
    ```

    Any network file share reachable by all nodes works — this improves storage reliability.
  </Step>

  <Step title="Add the iSCSI disks to the cluster">
    Run:

    ```powershell theme={"system"}
    Get-ClusterAvailableDisk -All | Add-ClusterDisk
    ```

    Confirm the disks appear under Failover Cluster Manager's **Storage > Disks**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

### Stage 4: Configure storage replication

<Steps>
  <Step title="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**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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**.
  </Step>
</Steps>

Once complete, all four disks show as online, with **Source** (read/write) and **Destination** (replication target) roles visible in Failover Cluster Manager. Check ongoing status on the **Replication** tab, and test failover using **Simulate Failure** on the current source disk.

<Note>
  After a storage endpoint failure, the endpoint or its paired cluster node may need a reboot to bring the affected disks back online.
</Note>

When all four stages are complete and a failure occurs on the currently active storage, the Failover Cluster Manager automatically switches the Syteca Application Server's storage connection to the second storage endpoint. All data that had been written to the primary endpoint has already been replicated to the secondary endpoint, so no screen captures are lost during the failover.

## Related

<CardGroup cols={2}>
  <Card title="Deployment architecture" icon="network" href="/docs/administration/deployment/architecture">
    Overall Syteca deployment architecture, including where shared storage fits.
  </Card>

  <Card title="High availability" icon="shield-check" href="/docs/administration/deployment/high-availability">
    High Availability and disaster recovery concepts across the whole deployment.
  </Card>

  <Card title="System requirements" icon="server" href="/docs/get-started/system-requirements">
    Sizing guidance for Application Servers that will write to shared storage.
  </Card>

  <Card title="Application Server advanced settings" icon="settings" href="/docs/administration/deployment/server-advanced-settings">
    Application Server configuration options, including where the shared storage path is defined.
  </Card>
</CardGroup>