Gladinet Cloud EFSS for Large Enterprises

OpenStack is used more and more by enterprises and service providers for the File-Sync-and-Share (EFSS) solution. A normal process is that the enterprise will start with a proof-of-concept with small number of users, figure out all the limitations and then move on to a bigger implementation such as make it ready for hundreds of thousands of employees to use in a production environment.

In OpenStack Swift, there is a small technical detail that affects scalability, which is the number-of-objects-per-container. Basically per-object upload latency will increase considerably once the number reach a certain point. From the OpenStack Swift community, the best practice is to keep number-of-objects-per-container to be just under one million.

In this article, we will lead you through the path from small POC to big all-employee deployment, with Gladinet Cloud Enterprise and OpenStack Swift, with this technical limitation in mind.

POC

In Proof-of-Concept stage, typically the users are focused on functionality. Ease of use is one of the important factor. In this stage, Gladinet Cloud Enterprise has built-in web portal management console that allows mapping of a root folder to an OpenStack Swift container. and all the users’ home directories are created inside this container. It is very easy to get started and easy for enterprises to check everything out in POC stage.

API Interface

In the late POC stage, before a production POC or start of production environment, we will start discussion with the API interface and user provision process. Normally for enterprises, they already have their own service-provision portal. So the topic of discussion is usually how to provision users using their own provision-portal, instead of the Gladinet Cloud Enterprise’s management console.

At this stage, the discussion of OpenStack Swift’s one-million-object limitation comes in naturally.

The enterprises all have Active Directory and all need Active Directory integration for the users.  At this stage, we will introduce the Gladinet User Management API and the corresponding PowerShell Module.

As shown in the picture below. The ImportAdUserByUPNEx is used to integrate the enterprise’s service provision portal with the Gladinet Cloud Enterprise.

This function allows the definition of per-user storage configuration (StorageConfigure parameter). We recommend using the Active Directory user’s SID (Unique Identifier) as the container name. So every AD user will have a distinct container to work with for the per-user file sync and share solution based on OpenStack Swift.

PowerShell Module is also available for this. As shown in the picture below.

So basically for small number of users, Gladinet Cloud Enterprise’s user-provision portal is good. For large number of users, using API to integrate and assign containers on a per-user basis.

Production Deployment

In the production deployment, there are also discussion about separate SQL Server out of the Gladinet Cloud Enterprise layer. Most of the big enterprise we are working with all have volume licenses for Windows Operating System for the Gladinet Cloud Enterprise nodes and for the SQL Server. In some cases, they also have dedicated teams for Database and dedicated teams for Server provision. At this stage, the database teams and the server teams will be involved to move the POC into production.

Summary

As a summary, Gladinet Cloud Enterprise is deployed successfully for very big organizations and periodically we will share our experience on how to make it scale. For more information, please visit Gladinet’s OpenStack Swift related solution page .