1 Introduction

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.1 Document 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.2 Intended 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.

1.3 Prerequisites

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

2 Template

KEMP has developed a template containing our recommended settings for this workload. You can install this template to help when creating Virtual Services, as it automatically populates the settings. 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.

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

For steps on how to manually add and configure each of the Virtual Services using the recommended settings, refer to the steps in this document.

3 Solution Overview

3.1 Topology

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

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.2 LoadMaster 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

4 Deployment 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.1 Network Environment

The LoadMaster sits behind a NAT firewall on subnet 192.168.83.0/24. A virtual IP of 192.168.83.200 is created to service requests from the Cloud Orchestrator

The Storage Connector VMs are on subnet 172.16.10.0/24

Customer A connects via https://customera.example.com and has Storage Connector hosts at 172.16.10.1 and 172.16.10.2

The EMC Atmos cluster is on subnet 10.1.1.0/24 with IP addresses of 10.1.1.101, 10.1.1.102, 10.1.103, 10.1.1.104, 10.1.1.105, and 10.1.1.106

The LoadMaster is configured with addresses of 10.1.1.200 and 172.16.10.200 to provide connectivity to the Storage Connector and the EMC Atmos storage platform

5 LoadMaster Configuration

5.1 Enable 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 not the Virtual Service address.

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.

1. In the main menu of the LoadMaster Web User Interface (WUI), go to System Configuration > Miscellaneous Options > Network Options.

2. Tick the Subnet Originating Requests check box.

5.2 Virtual Service for Syncplicity Cloud to Storage Connectors

For our example, a Virtual Service needs to be created on 192.168.83.200 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.

3. For each customer, create a SubVS and add Real Servers for their Storage Connector servers.

The Storage Connection host is on port 9000.

4. Add any Real Servers, as needed.

5.2.1 Virtual 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.

Section

Option

Value

Comment

Standard Options

Transparency

Enabled

Persistence Method

None

Scheduling Method

round robin

SSL Properties

SSL Acceleration

Enabled

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.

5.4 Virtual 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.

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 10.1.1.0/24 in this example).

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.

6 Configuration: Summary

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