How can we help you today?
Clustering & Load Balancing MyWorkDrive Servers
MyWorkDrive supports clustering for enterprise licensees above 200 users that wish to run multiple MyWorkDrive servers with fail-over or load balancing. There are some important steps to ensure proper identification by the MyWorkDrive systems to support multiple license activation and to ensure uniqueness with our Office 365 editing features.
Clustering your MyWorkDrive servers.
Version 6 of MyWorkDrive Server introduces dedicated support for Clustered environments supporting both Load Balanced and Fail-Over. You’ll now be able to configure servers as Primary or Secondary, and your Primary server will do most all the configuration – which will automatically be picked up by the Secondary servers, removing most of the duplicate administration work previously required. A Clustering Enabled license is required. If Clustering is not available in your Admin panel, contact sales to inquire about a license upgrade. Versions prior to 6 will need to continue to manually apply settings and make configuration changes to each server individually using the exports/import feature, see below for instructions if you have not yet upgraded to Version 6.
- 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.
- Contact firstname.lastname@example.org to allow additional servers to be activated with your MyWorkDrive License key. You can then input the same key into your MyWorkDrive Servers however the cumulative usage across all servers must not exceed your subscription license count.
- Shared configuration files are stored on a Network Share UNC Path accessible to all the MyWorkDrive servers (do not use a share located on any MyWorkDrive Servers as this will create security issues reading SAML information and it will cause an outage if the MyWorkDrive Server hosting the Share is restarted). We recommend using a hidden file share.
- Each Server’s computer account must be granted NTFS and Share permissions to write to the share.
- On some versions, the primary server listens on port 8353 for sharing of locks information – Windows Firewall must be set to allow port 8353 inbound from all secondary cluster members. This is not required as of build 184.108.40.206 and later.
- Shares, server configuration, and user settings (including favorites) are now stored at the specified location. When deployed, settings are copied there from the Primary server. The Primary server denotes the server where changes can be made. Secondary servers cannot make settings changes and simply use the changes as set on the config files they have access to.
- When enabled, the Secondary server(s) has/have limited configuration settings (log level, Office 365). All configuration is done on the Primary server (client settings/limits, shares, features, etc)
- Changes made to settings on the Primary server are replicated to secondary servers as of build 220.127.116.11. To invoke an immediate replication, use the refresh button on clustering on the secondary server. Prior to build 18.104.22.168 cluster changes were pulled by the secondary servers as needed and no refresh option was available.
- Log level, log storage, and Office 365 enabling are still handled on a per-server basis.
- IIS configuration is handled on a per-server basis – port/SSL bindings, so each server will need a connection set up if you are using inbound 443 and binding an SSL.
- Use the sticky session feature (also known as session affinity) on the load balancer, which enables the load balancer to bind a user’s session to a specific instance and for persistence use client Source IP Address.
- Favorites are now stored alongside other shared configuration data and are no longer configured separately.
- An unlimited number of Secondary servers are supported.
- Servers can be run in the classic mode 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.
Server Installation / Configuration
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 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. All inbound port 8383 from all secondary Servers on Windows firewall. .
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.
To support the new 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, 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 (22.214.171.124 to 126.96.36.199), 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.
There are two known issues when deploying a clustered enviornment. Both of these are present in version 6.0 and will be addressed in version 6.1 when it becomes available.
If you upload a custom logo on the primary server, the logo will not be availble on the secondary servers. Users who login to the secondary servers will see the standard MyWorkDrive logo.
To fix this, you should manually copy the logo file “myworkdrive-corplogo.png” from C:\Wanpath\WanPath.Data\Settings on the primary server to the same location on the secondary server.
Like the logo, If you have configured SSO for your login, the SSO configuration and SSL certificates will not be correctly exchanged between the primary and secondary members. Users attempting to login to the secondary members will receieve a notice like “Error: No partner identity providers have been configured.”
The solution, like addressing the logo, is to manually copy the SSO files from the Primary to the Secondary servers.
You’ll want to copy the saml.config file and the certificates folder from C:\Wanpath\WanPath.Data\Settings\ folder on the primary server to the same location on the secondary servers.
As noted, these issues only exist in version 6.0 server and will be resolved in version 6.1
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.
Support for Co-Editing and session persistence
Microsoft SQL and PostgreSQL are supported for session and lock persistence.
A database is not required to be used with clustering. Database functionality allows sessions to move between members of the cluster and supports co-editing across members of the cluster. If a database is not desired, co-editing will only be supported for users connected to the same node, and users who’s sessions move between servers will need to re-establish a lock on a document when they save (this is automatically handled in the background).
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 the session and 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 enviornment.
- MyWorkDrive servers configured with Clustering (as described above)
- A SQL server accessiable to all cluster members
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.
- 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.
- 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.
- Login to the primary MyWorkDrive server, and in the clustering menu, toggle on “Enable Sessions and Locks”
- Enter your connection string in the Database connection String field. Your connection string should take the sytax
- Save your configuration. The MyWorkDrive server services will restart to enable the new configuration as noted in the blue message box on screen.
- 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 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.
New! 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.”
2. After seeing the green “Saved!” confirmation pop up, as the note indicates, MyWorkDrive needs to be reset. A server reboot is the easiest way.
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
As mentioned earlier, version 6 of MyWorkDrive Server includes new features for clustering. If you are running an older version of MyWorkDrive Server, clustering is accomplished manually.
- Each server must have it’s own unique device id as assigned by our software upon installation – do not clone the MyWorkDrive Servers. Setup each server separately, then install MyWorkDrive on each. They will then each be assigned a unique device id.
- Contact email@example.com to allow additional servers to be activated with your MyWorkDrive License key. You can then input the same key into your MyWorkDrive Servers however the cumulative usage across both servers must not exceed your subscription license count.
- Use the sticky session feature (also known as session affinity), which enables the load balancer to bind a user’s session to a specific instance and for persistence use client Source IP Address.
- Enable Favorites: By enabling favorites, users will see a new option in the web file manager browser client to create and delete favorites to folder paths. By default, favorites are saved to the local MWD Server. In clustered environments, favorites may also be saved to a shared hidden share on the network. For example, \\domain.com\favorites$ (each MyWorkDrive server computer account will need NTFS permissions to create and modify favorites in this hidden file share).
- Server Configurations: You may use the backup configuration under settings to backup your configuration on your Primary server in the admin panel. To restore it, use the restore settings feature on the destination server. This will restore settings such as file shares and configuration options without overwriting unique server device ids on the destination server.