Clustering your MyWorkDrive servers

MyWorkDrive supports clustering for enterprise licensees above 200 users that wish to run multiple MyWorkDrive servers with fail-over or load balancing, Active-Active and Active-Passive.

Clustering Enabled Features

There are three key features which require special attention when deploying in a clustered envioronment with multiple MyWorkDrive Servers.

Office Online Editing

If you are using multiple MyWorkDrive servers and wish to enable Office Online Editing , you must enable a sessions and locks database so the cluster member servers are aware of open and locked office documents and are able to share co-edit links across nodes. Failure to enable a sessions and locks database when enabling Office Online Editing will result in users experiencing locked files, often unexpectedly, and being unable to co-edit reliably.

Public Share Links

If you enable Public Share Links in a multi-node cluster, you must enable a session and locks database so links created by users are available on all servers. Without a session and locks database, the Public Share Links will be created locally on the MyWorkDrive server the user is connected to at the time, and link recipients will not be able to open them unless their session is also directed at the same node.

Favorites

If you enable the MyWorkDrive Favorites feature in a multi-node cluster, you must enable shared configuration files on an smb path, so that favorites created by users are available on all servers. Without the shared configuration files, favorites will be saved locally on each member server and the users will only have access to what is saved on each node individually.

Shared Configuration Files

Shared configuration files may optionally be stored on a Network Share UNC Path accessible to all the MyWorkDrive servers. Sharing configuration files is not a requirement and may introduce a single point of failure. You must be able to adjust permissions using active directory user and computer objects on the share.

• Clustering of configuration files is only supported with Active Directory identity on domain joined servers.  Entra ID Identity without domain joined servers is not supported at this time.  Clustering without configuration files and manually maintaining the config between servers is the recommended method for clustering in Entra ID Identity mode.
• If a shared configuration file path is used, it is not advised to use a share located on any of the MyWorkDrive cluster member servers, as this will cause an outage if the MyWorkDrive Server hosting the Share is restarted. We recommend using a hidden file share if clustering configuration files.
• Each Server's computer account must be granted NTFS and Share permissions to read and write to the shared configuration file path (modify, they do not need full control).
• Users who will administer the cluster members must have modify permission to the shared configuration file path (ie, grant Domain Admins Modify permissions, they do not need full control).  Administration functions like editing configuration, sharing diagnostic logging, upgrading/installing will fail if administering users do not have permission to the cluster configuration file path (functions performed by a logged in Admin user are done under the user context)
• Servers are defined as Primary and Secondary. The Primary server has the ability to update settings on the configruation files. Secondary servers cannot make settings changes and simply use the changes as set on the config files they have access to. A secondary server can be promoted to be the primary server if the primary server is removed from the cluster.
• When enabled, the Secondary server(s) have limited configuration settings (log level, Office 365).  All configuration is done on the Primary server (client settings/limits, shares, features, etc)
• Secondary servers read the shared configuration periodically and cache it locally for performance. To invoke an immediate replication, use the refresh button on clustering on the secondary server.
• Settings for Log level and log storage, as well as the Office 365 configuration are still managed locally on secondary servers.

Load Balancing

The clustering feature does not include a front-end load balancer. It is assumed the customer will have a prefered load balancing solution in their enviornment. Clustering manages communication between the servers for co-editing of office documents, file locks, public share links and user favorites.

Session Persistence must be configured on the load balancer. IP is the most common session peresisstence used. MyWorkDrive also suports Cookie session affinity, should IP not be suitable.

Some load balancers which are known to work with MyWorkDrive include

• Azure Application Gateway
• Kemp LoadMaster
• Netscaler/ADC
• F5 Big-IP
• HAProxy
• Nginx
• Traefik

Other Important Considerations

• SSL Certificates and port binding in IIS configuration are handled on a per-server basis, so each server will need a connection set up for communication with the load balancer to service connections.
• The number of secondary servers which can be deployed is only limited by the available activations on the customer's license. There is no technical limit.

Running Multiple MyWorkDrive servers without shared configuration files

Servers can clustered without enabling the shared configuartion files option, manually maintaining the configuration files if you so choose, or if you want to maintain an existing configuration while you plan a migration to the new Cluster configuration. 

Some customers may prefer to avoid using a shared configuration path to avoid granting permissions to the share, or to avoid a share as a single point of failure. This is a fully supported deployment model. In that case, export and importing the configuration file can be used to ensure configuration parity between nodes.

A database can be deployed to support co-editing and public share links without enabling a shared configuration path.

If using multiple servers in a cluster without sharing configuration files, it is advisable to disable the favorites feature to avoid user confusion regarding inconsistency of favorites saved across nodes.

Server Installation / Configuration

Each server must have its own unique device id as assigned by our software upon installation - do not clone the MyWorkDrive Servers.  Setup each server separately, then configure clustering settings in the Clustering menu in server admin.  Cloning my MyWorkDrive will cause all servers with the cloned hardware ID to be unlicensed by the licensing service and users will not be able to login.

Primary Server

Install and configure MyWorkDrive on your Primary server.
Make sure you have a license that supports clustering (will appear in the menu, contact sales if you do not see "Clustering" as a top level item alongside Settings, Enterprise, Logs, etc).
Enable Clustering from the menu.
Is using a shared configuration file path, Set the server as Primary
Specify a UNC path for the share location (we recommend using a hidden share). ie \server\share$ Save your configuration. 

Your Primary server's current configuration will be placed on the specified UNC Path. Future changes to settings on the Primary server will update the configuration files stored on the UNC Path.

Secondary Server

To support the Cluster feature, we've enabled skip on the wizard to simplify the process for the Secondary server.
Install your Secondary server.
Apply the clustering enabled license.
Skip the wizard.
On the cluster tab, if enabling a shared cluster settings path do NOT specify it as a Primary server (only one Primary server is supported per environment), simply enter the same UNC path as the Primary server, ie \server\share$

The Secondary server will now use the same settings as the Primary server for most things except for those noted above (Office Online, Log level, etc).  Settings on the Settings and Enterprise tabs in server admin which are managed by the Primary server are shown, but changes are not permitted on the Secondary server.

Deploying in an existing environment

If you already have a MyWorkDrive server and want to deploy a cluster with a Secondary server, or you already have a cluster and want to upgrade to the Version 6 clustering features, the process is straightforward. Enable Clustering on the Primary server and specify the UNC path to store the configuration files.  This will copy the existing configuration to the new shared location. Enable Clustering on the Secondary server and specify the UNC path to the shared configuration files (the same path used on the Primary server).  The Secondary server will switch to using the Cluster configuration files.  A copy of the then-current configuration will be retained locally on the server, but will not be updated.  The cluster configuration is stored exclusively on the shared location.

Upgrading servers in a Cluster

It is not necessary to disable clustering on the servers in MyWorkDrive to update them. Cluster servers can be individually upgraded. If you are upgrading within the same version, ie, version 7.1.1.33 to 7.1.1.35, clustering servers can be updated individually without taking the cluster offline unless otherwise noted in the release notes.
If you are updating between versions of MyWorkDrive (ie 6.0 to 6.1), we recommend taking all nodes of the cluster offline and upgrading all of them. Start by upgrading the primary server. Starting with the primary server ensures any schema changes in the configuration files are completed successfully.

Note that if you are using a share configuration file path, the user conducting the upgrade must have modify permissions to the shared configuration file path to upgrade the servers. Upgrading the servers by a user who does not have administration rights to the share configuration path is likely to result in corrupt configuration files

Session Handling

User sessions exist only on the server where they originally authenticate. MyWorkDrive does not support sessions moving between servers/nodes within a cluster. We require Session persistent to be enabled on the load balancer.

The detailed information about the user’s session is held exclusively in memory on the MyWorkDrive server as a protective/security measure, to ensure it cannot be captured and misused. The information recorded in the session database is only a reference.

Session persistence can be maintained either by IP Address or Cookie (Cookie requires MyWorkDrive client/server 7.0.1 or later)

Support for Co-Editing

Microsoft SQL, Microsoft SQL Express, Azure SQL, and PostgreSQL are supported for the sessions and locks database.

A database is not required to be used with clustering, however, is required if you wish to use Office Online Editing or Public Share Links.

Co-Editing can be enabled without clustering configuration files.

Microsoft SQL

As of MyWorkDrive server 6.3, MyWorkDrive offers improvements to clustering to permit co-editing of Office documents in Office Online across servers. Previous versions required co-editors to be using the same server. Version 6.3 permits you to enable co-editing across MyWorkDrive cluster members.

This enhancement requires the information about open locks and active sessions to be stored in a SQL database (on a SQL server). This permits all of the MyWorkDrive server members in your cluster to share lock file information. When this feature is not enabled, each server keeps its own local table of active sessions and locks, which is not shared with other servers in the environment.

Prerequisites

• MyWorkDrive servers configured with Clustering (as described above)
• A SQL server accessiable to all cluster members

Configuration

You are advised to make these changes during a maintenance window or when server utilization would otherwise be low, as enabling this setting will disconnect any active users.

1. Create a database on your SQL server for the MyWorkDrive lock and session data.  You do not need to create any tables, the configuration will create the required tables.
2. Create a user in SQL and assign it to the database you created in step 1. Grant the appropriate access rights to the user, the user will need to be able to create tables and add/delete data from those tables.
3. Login to the primary MyWorkDrive server, and in the clustering menu, toggle on "Enable Sessions and Locks"
4. Enter your connection string in the Database connection String field.  Your connection string should take the sytax Server=mySQLServer;Database=database_name;User Id=dbuser;Password=password;
5. Save your configuration. The MyWorkDrive server services will restart to enable the new configuration as noted in the blue message box on screen.
6. Edit the other MyWorkDrive servers in the cluster and enable the Sessions and Locks feature and apply the appropriate connection string to each of them.

When enabled, session information is no longer stored locally on disk, and is stored in the tables created on the database you defined.

There is no need to manage this database, entries are automatically added and removed as needed by the connected MyWorkDrive servers.

PostgreSQL

As of MyWorkDrive version 6.4, PostgreSQL is supported as an alternative database to Microsoft SQL.

We have tested both Windows and Linux using the default port of 5432. This guide assumes that you have a pre-existing instance of PostgreSQL.

If you need to setup PostgreSQL, we have an overview of how we've done it in our lab, here

To enter the connection string into MyWorkDrive: 1. Navigate to the “Clustering” menu, “Enable Clustering” (if it isn’t already), Enable Sessions and Locks” (if it isn’t already), select the “PostgreSql” radio option, then enter your connection string in the field provided; lastly, select “Save.”

1. After seeing the green “Saved!” confirmation pop up, as the note indicates, MyWorkDrive needs to be reset. A server reboot is the easiest way.

Serverless SQL on Azure

The session and locks database is small, requiring few resources. Please start with a minimum of 0.5 and maximum of 4 vCores on a General Purpose CPU. Perform some load testing. If there is an issue with load, you may need to increase the maximum. If the startup connection is slow, you may need to increase the minimum (try 1, then 2, and so on).

SQL Database for Improved Performance

As noted on our Server Sizing and Server setup guides, in scenarios with higher utilization or lower MyWorkDrive server performance, the use of a dedicated database for Sessions and Locks may improve performance and reduce errors related to connection timeouts over the default file-based sqlite configuration on individual servers.

Using a dedicated SQL database can be achieved by enabling clustering and setting a SQL server for sessions and locks. The clustering of configuration files nor the user of multiple MyWorkDrive servers is required to run a database for sessions and locks. MS SQL and PostgreSQL are supported in this configuration as well.

Inbound Traffic Configuration Examples

Sample Azure Load Balancer Setup Article Sample Kemp Load Balancer with settings tested and approved by MyWorkDrive Support with Source IP Address Persistence Create VIP Service in Kemp

• Set VIP Lan IP Address
• Install SSL Certificate
• Persistence Options: Source IP Address
• Enable SSL Acceleration and Enable Reencrypt
• Add Backend MyWorkDrive Real Server Lan IP's

Disabling a Cluster

If you disable clustering, the servers will revert to the last known local configuration.  In the case of a Secondary server, that may not be current or there may not be any at all if it was deployed specifically as a Secondary cluster member. Should you want to revert to individual MyWorkDrive servers, use the export feature on the Primary server to capture the current cluster configuration to apply to Secondary servers after removing them from the cluster.

Troubleshooting

Solutions to common problems you may encounter with MyWorkDrive servers using clustering features.

Users report receiving messages their session has expired frequently

As described above in the session handling section, user sessions are stored in memory on the MyWorkDrive node where the user originally authenticates. For security, user sessions are not shared between MyWorkDrive servers.

If a user's connection is passed to a different MyWorkDrive server, the user will receive a response from the server that they do not have a valid session, which the client will treat as expired, prompting the user to reauthenticate

The common cause for this is a failure by the load balancer to correctly maintain persistence for the session. It is imperative that session persistence be enabled on the load balancer when using MyWorkDrive. IP session persistence is most common. MyWorkDrive also supports cookie session persistence in all clients.
Enable Session persistence on load balancers with MyWorkDrive servers.

Reports of files locked or in use by another user

If you enable Office Online Editing without also enabling a Sessions and Locks database, information about locked files and co-editing sharing links will only be stored on the server where the file is opened, and that information will not be available to users on other servers. This will result in users who expect to be able to co-edit files together in office online to be unable to (unless, by chance, they are siged in to the same MyWorkDrive server).
If you wish to enable Office Online Editing on a multi-node cluster, you must also enable a sessions and locks database.

Public Share Link recipients report errors accessing links

When using the Public Share Links feature in a cluster, a Sessions and Locks DB must be configured to share public share link data between cluster nodes. Without a Sessions and Locks database configured, Public Share Links will be locally stored on the cluster member they are created on and not available to all MyWorkDrive servers.
Do not enable Public Share Links on multi node clusters unless a Sessions and Locks database is configured.

Errors maintaining/upgrading cluster members

When using a share clustering configuration file path, failing to correctly grant MyWorkDrive server computer accounts and administrators who are managing/upgrading the MyWorkDrive server(s) modify rights to the shared cluster Configuration Files path will result in errors occurring when attempting to upgrade and manage MyWorkDrive servers. Configuration data may be corrupted and nodes may be left in an unstable state when attempting to make changes, conduct upgrades or retrieve diagnostic data.
Grant all administrators and all MyWorkDrive computer accounts modify rights to the shared cluster configuration file path, if used.

Secondary cluster members intermittently go offline

The most common cause of secondary cluster members going offline is an inability to access the shared clustering configuration file path. If the SMB path where the shared cluster configuration files are stored becomes unavailable, the primary server will go offline. The Primary server requires continuous access to the configuration file path.  Secondary servers will go offline at their next configuration file refresh.
Do not store configuration files on a file server which is subject to intermittent access, load or backup constraints, or is rebooted outside of maintenance windows.

Issues with Favorites

Users may report a variety of errors with favorites when multiple MyWorkDrive servers are deployed. They all revolve around the favorites list for the user.

Problems like:

• Favorites I saved do not always show in the list
• The list of favorites changes from login to login
• Favorites I have deleted continue to appear sometimes
• Favorites I have edited are different from login to login
• I get errors attempting to save favorites

The cause of all of these issues is the lack of a properly configured favorites with Clustering. The use of Favorites with multiple servers requires the configuration of a shared cluster config file path, because the favorites for each user are saved as files on the settings path. These files must be available to all servers via a shared cluster config path. Additionally, to properly maintain the cluster configuration settings files, the member servers computer accounts must have modify permissions to the shared cluster config file path. Failure to grant the member servers modify rights will result in errors reported to the user when adding/changing/deleting files.
Configure a shared cluster config file path for your cluster if you wish to use favorites; or disable favorites in settings of the Admin console.