EMC Syncplicity



Syncplicity is an enterprise sync and share solution from EMC which enables corporate users to collaborate from anywhere while providing corporate IT with the security and control required to comply with best practice and policy. In addition to being a service hosted by EMC, Syncplicity can be deployed as an on-premise solution integrated with storage architectures such as EMC Atmos.

The KEMP LoadMaster not only addresses the load balancing requirements defined by EMC, it can add significant value in multi-tenant environments such as service providers and enterprise deployments.

1.1Document Purpose

This document outlines how a KEMP LoadMaster can be deployed together with EMC Syncplicity. It also provides guidelines for the configuration of LoadMaster services.

1.2Intended Audience

This document is intended to be used by anyone deploying a LoadMaster in conjunction with on premise Syncplicity and by service providers deploying a multi-tenant Syncplicity service.


The reader should have sufficient knowledge of networking, the LoadMaster and Syncplicity products to implement the solution outlined.

2EMC Atmos Syncplicity Template

KEMP has developed a template containing our recommended settings for EMC Atmos Syncplicity. This template can be installed on the LoadMaster and used when creating Virtual Services. Using a template automatically populates the settings in the Virtual Services. This is quicker and easier than manually configuring each Virtual Service. If needed, changes can be made to any of the Virtual Service settings after using the template.

Download released templates from the Templates section on the KEMP documentation page: http://kemptechnologies.com/documentation/.

For more information and steps on how to import and use templates, refer to the Virtual Services and Templates, Feature Description

For steps on how to manually add and configure each of the Virtual Services, refer to the LoadMaster Configuration section of this document.


3Solution Overview


Syncplicity consists of a cloud-based orchestration layer connecting authenticated and authorized clients with their storage via a customer-specific URL.

Figure 3‑1: Topology

Based on the URL content, the LoadMaster infrastructure forwards the customer request to the customer-specific Storage Connector. The Storage Connector services the customer request by communicating with the EMC Atmos service via the LoadMaster.

While the Cloud Orchestrator is designed to deal with a single IP address (Storage Connector), the LoadMaster enables a multi-tenant environment by selecting the client’s Storage Connector based on the client-specific URL.

3.2LoadMaster Functionality Applied

The LoadMaster environment enhances the Syncplicity environment in the following ways:

  • It load balances Storage Connector hosts
  • It load balances traffic on the Atmos storage cluster
  • It simplifies scaling of Storage Connectors
  • It performs Network Address Translation (NAT) of internal addresses
  • Acts as a single point for managing and controlling digital certificates
  • Enables multi-tenancy on a single IP address by mapping the request URL to subscriber-specific Storage Connectors

4Deployment Example

To highlight the LoadMaster capabilities, the example below assumes the following:

  • On-Premise, Multi-Tenant service on the domain example.com
  • Services are provided to Customer A, Customer B and Customer C
  • Each customer has a pair of Storage Connectors deployed
  • A single certificate is used to secure communication with all customers
  • An EMC Atmos cluster provides a multi-tenant storage platform
  • For simplicity, a single LoadMaster is deployed, although in a real situation a pair of LoadMasters would be used for resilience

4.1Network Environment

C:\Users\kgaffney\Dropbox (Kemp Technologies)\documentation updates\EMC Syncplicity\Visio Diagrams\SyncplicityNetwork3.png

Figure 4‑1: Network Environment

  • The LoadMaster sits behind a NAT firewall on subnet A virtual IP of is created to service requests from the Cloud Orchestrator
  • The Storage Connector VMs are on subnet
  • Customer A connects via https://customera.example.com and has Storage Connector hosts at and
  • Customer B connects via https://customerb.example.com and has Storage Connector hosts at and
  • Customer C connects via https://customerc.example.com and has Storage Connector hosts at 172.16.105 and
  • The EMC Atmos cluster is on subnet with IP addresses of,, 10.1.103,,, and
  • The LoadMaster is configured with addresses of and to provide connectivity to the Storage Connector and the EMC Atmos storage platform

5LoadMaster Configuration

5.1Enable Subnet Originating Requests Globally

It is best practice to enable the Subnet Originating Requests option globally.

In a one-armed setup (where the Virtual Service and Real Servers are on the same network/subnet) Subnet Originating Requests is usually not needed. However, enabling Subnet Originating Requests should not affect the routing in a one-armed setup.

In a two-armed setup where the Virtual Service is on network/subnet A, for example, and the Real Servers are on network B - Subnet Originating Requests should be enabled on LoadMasters with firmware version 7.1-16 and above.

When Subnet Originating Requests is enabled, the LoadMaster will route traffic so that the Real Server will see traffic arriving from the LoadMaster interface that is in that network/subnet.

When Subnet Originating Requests is enabled globally, it is automatically enabled on all Virtual Services. If the Subnet Originating Requests option is disabled globally, you can choose whether or not to enable Subnet Originating Requests on a per-Virtual Service basis.

To enable Subnet Originating Requests globally, follow the steps below:

  1. In the main menu of the LoadMaster WUI, go to System Configuration > Miscellaneous Options > Network Options.

Figure 5‑1: Subnet Originating Requests

  1. Tick the Subnet Originating Requests check box.

5.2Virtual Service for Syncplicity Cloud to Storage Connectors

For our example, a Virtual Service needs to be created on which redirects requests to the customer-specific Sub-Virtual Service (SubVS) based on the requestor URL. To do this, follow the steps below in the LoadMaster Web User Interface (WUI):

  1. Create a Virtual Service on the LoadMaster which responds to requests on port 443 coming from the Syncplicity Cloud.

Figure 3: Virtual Service parameters

  1. Configure the Virtual Service using the recommended settings as listed in Section 5.2.1.
  2. For each customer, create a SubVS and add Real Servers for their Storage Connector servers.

Figure 4: SubVS - Basic Properties

The Storage Connection host is on port 9000.

  1. Add any Real Servers, as needed.

5.2.1Virtual Service Settings

The following, are KEMP recommended settings for a Syncplicity Virtual Service. All other options remain as per the default configuration. However, changes can be made to any settings, as needed based on your environment.





Standard Options




Persistence Method



Scheduling Method

round robin


SSL Properties

SSL Acceleration


A wildcard certificate allows secure connections to be established with a request URL in the format of *.example.com. With this approach, a single certificate secures traffic for all clients in a multi-tenant environment.


Cipher Set

Best Practices

For further information on cipher sets, please refer to the SSL Accelerated Services, Feature Description.


Real Servers

Real Server Check Parameters

HTTP Protocol

These settings are used to define the URL to use for checking the availability of a Real Server.


HTTP Method



Figure 5‑2: Virtual Service Settings

5.3Content Rules

Content rules allow traffic be redirected based on criteria, including the URL requested by the client.

Figure 7: Content Matching Rules

In our example, the LoadMaster is configured with a content rule for each customer so requests to the customer-specific URL are redirected to the customer-specific Storage Controller pair.

Figure 5‑3: SubVSs - Adding Appropriate Rules

In the SubVS section of the Virtual Service properties page, add the appropriate content matching rule for each customer.

For more information on content rules in general, please refer to the Content Rules, Feature Description.

5.4Virtual Service for Storage Connector to Atmos

The Storage Connector nodes communicate with the Atmos storage backend via port 80. The Atmos storage environment consists of multiple nodes and any of which are capable of servicing requests from Storage Connectors. EMC suggests using a round robin algorithm on a load balancer. This results in even distribution of service requests across the Atmos nodes. The health of the Atmos environment can be tested using PING or by requesting the /rest page from the Atmos node.

Figure 5‑4: Virtual Service

A Virtual Service should be created on the LoadMaster interface which is connected to the particular Storage Connector subnet. This Virtual Service should accept HTTP requests on port 80 and balance them, using round robin, to the Atmos nodes (the six IP addresses on in this example).

Figure 5‑5: Real Servers Section

Atmos nodes are added as Real Servers with the server check set to ICMP Ping or HTTP Protocol. Using HTTP as the check protocol gives a view of the Atmos REST service status while PING only checks the host network status.

Figure 5‑6: Real Servers

6Configuration: Summary

Figure 11: Virtual Services

Syncplicity clients connect via the Syncplicity orchestration cloud to the Virtual IP [1] on the LoadMaster which is listening on port 443.

Based on the request URL, the connection [2] is forwarded to the customer’s Connection Server pair on port 9000 [3].

The Connection Server makes a REST request on port 80 to the Atmos Virtual IP [4] which balances the request to one of the available Atmos nodes [5].


Unless otherwise specified, the following documents can be found at http://kemptechnologies.com/documentation.

Content Rules, Feature Description Virtual Services and Templates, Feature Description SSL Accelerated Services, Feature Description

Document History



Reason for Change



May 2015

Initial draft

First draft of document



Oct 2015

Release updates

Updates for 7.1-30 release



Dec 2015

Release updates

Updates for 7.1-32 release



Jan 2016

Minor changes




May 2016

Release updates

Updated for 7.1-34 release



Aug 2016

Minor changes

Enhancements made



Was this article helpful?

0 out of 0 found this helpful