Kemp Support, how can we help?

The latest application delivery knowledge and expertise at your fingertips.

EMC Syncplicity

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 create Virtual Services (VSs) because it automatically populates the settings. You can use the template to easily create the required VSs with the recommended settings. For some workloads, additional manual steps may be required such as assigning a certificate or applying port following, these steps are covered in the document, if needed.

You can remove templates after use and this will not affect deployed services. If needed, you can make changes to any of the VS settings after using the template.

Download released templates from the following page: LoadMaster Templates.

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.

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. 

Topology.png

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

Network Environment.png

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

Customer B connects via https://customerb.example.com and has Storage Connector hosts at 172.16.10.3 and 172.16.10.4

Customer C connects via https://customerc.example.com and has Storage Connector hosts at 172.16.105 and 172.16.10.6

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.

Enable Subnet Originating Requests Globally v.2.png

When Subnet Originating Requests is enabled, the Real Server sees traffic originating from 10.20.20.21 (LoadMaster eth1 address) and responds correctly in most scenarios.

With Subnet Originating Requests disabled, the Real Server sees traffic originating from 10.0.0.15 (LoadMaster Virtual Service address on eth0) and responds to eth0 which could cause asymmetric routing.

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 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 User Interface (UI), go to System Configuration > Miscellaneous Options > Network Options.

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

Virtual Service for Syncplicity.png

2. Configure the Virtual Service using the recommended settings as listed in the Virtual Service Settings section.

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

Virtual Service for Syncplicity_1.png

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.

 

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

HEAD

 

 

 

5.3 Content Rules

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

Content Rules.png

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.

Content Rules_1.png

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

Virtual Service for Storage.png

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

Virtual Service for Storage_1.png

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

Configuration Summary.png

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

References

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

Last Updated Date

This document was last updated on 10 March 2022.


Was this article helpful?
0 out of 0 found this helpful

Comments