ownCloud Architectural Guide

ownCloud Architectural Guide ownCloud provides Universal File Access through a common file access layer regardless of where the data lives – in applications, object stores, on premise storage or in the cloud. Data is kept where it is while IT is able to manage proprietary infor mation and business risk; leveraging existing data management, security and governance tools and processes. Whether in SharePoint, on a Windows network drive or in cloud storage, users have a single interface from which they can access, sync and share files on any device, anytime, from anywhere – all completely managed, secured and controlled by IT.

This paper describes the performance and scaling of the industry-standard EFSS (Enterprise File Sync Share) solution ownCloud Enterprise. ownCloud Enterprise runs on an Enterprise LAMP (Linux Apache MySQL PhP) stack on either Suse, Red Hat, CentOS or Ubuntu operating systems running PHP connecting to one of the supported databases, MySQL, PostgreSQL or Oracle.

ownCloud is a universal file access platform that is hosted in a customer’s data center, on their servers, using their storage. ownCloud delivers the visibi-lity, control and integration into complex, secure and compliant environments that IT needs while providing users the fric-tionless access to all of their files from any device. This is made possible through ownCloud’s open, modular

architecture, extreme extensi-bility and unique federated cloud sharing capabilities.

With over 8 million community and enterprise users, ownCloud is the preferred file access solution for organiza-tions across the globe. Whether looking for file sync and share, universal file access or Federa-ted Cloud Sharing, ownCloud has the solution that is right for every organization.

ownCloud Overview

This paper is intended for System Architects and Adminis-trators who are deploying ownCloud Enterprise into their IT infrastructure. It is assumed that the reader has basic understanding of IT infrastruc-ture, basic networking and routing skills, along with virtua-lization and server installation best practices. It is also assu-med that the reader has a basic understanding of the principles of ownCloud and its capabili-ties and has had at least limi-

ted hands-on experience with ownCloud Enterprise’s user interface as well as administrator interface.

Intended Audience

ownCloud Application

HTTP (Apache, nginx)

Operating System(Red Hat, CentOS, SUSE, Ubuntu)

Hypervisor(VMware, Microsoft, KVM)

Physical Host

PHP DB (MySQL, PostgreSQL, Oracle)

The core of the ownCloud solution is the ownCloud ser-ver. Unlike consumer-grade file sharing services, ownCloud‘s Enterprise solution enables IT to protect and manage files within the ownCloud environ-ment – from file storage to user / group provisioning. ownCloud monitors and logs all data access events for downstream auditing and analysis using popular tools like Splunk®.

The server provides a secure web interface through which administrators control all of ownCloud‘s resources, allowing authorized users to enable and disable features, set policies, create shares and manage users. Advanced features for enterprise directory integration and file “firewalls” give admins exceptional flexibility and con-trol. The server also manages and secures API access to own-

Cloud, while providing the internal processing engine nee-ded to deliver high perfor-mance file sharing services.

To enable a broad range of storage alternatives, ownCloud also abstracts the storage tier. As a result, ownCloud can leve-rage just about any storage protocol that can be mounted on your ownCloud server at the operating system level as

Primary Storage. ownCloud also has native connectors for object stores here, allowing us to directly access objects stores without the need for things such as fuse mounts. Other storage resources can also be mounted on the system using ownCloud Enterprise’s internal connectors, otherwise known as Secondary Storage.

Solution Architecture Overview

Primary Storage is required in all ownCloud installations. By default, ownCloud utilizes the ../ownCloud/data directory off the root of the webserver on the local partition as the default user data directory. Its presence is required by the ownCloud core application to store user-specific metadata such as thumbnails, temporary files, cache, encryption keys, versioning and trash-bin. While the ownCloud data directory can reside on the local partition of the underlying server, admi-nistrators can elect to utilize other means of Primary Storage attached / mounted to the local Linux operating system. ownCloud can utilize any files system that the local operating system can mount, such as NFS, GFS, Swift, etc , and has native connectors for object stores.

Once an administrator elects to utilize a storage mechanism other than the local partition,

the ownCloud configuration file simply needs to be pointed to the new storage location. While ownCloud can seamlessly work with the Primary Storage on the local partition, administrators will want to utilize an external Primary Storage source moun-ted to the Linux operating sys-tem to ease in storage overlap, performance, backups / snapshots and expandability concerns. Use of object stores as primary storage is done through a specific ownCloud plugin. For larger installs of ownCloud where multiple instances of the ownCloud Enterprise application servers are running behind a load balancer, external Primary Storage is a requirement as it allows access to the user sto-rage from multiple application servers that reside in the web-farm or cluster.

Secondary Storage is an optio-nal, but particularly robust component of ownCloud Enter-prise that will allow organiza-tions to utilize their existing data infrastructure. This not only facilitates flexibility in design, it also allows administ-rators to utilize existing data silos and ACL (Access Control Lists), minimizing the need for redundant storage devices, as version 8.2 of ownCloud Enterprise supports Amazon S3, Dropbox, Google Drive, OpenStack Object Store, FTP, SFTP, SMB / CIFS, SharePoint, Windows server shares and WebDAV. The diversity of the various compatible Secondary Storage along with the Primary Storage aspect of ownCloud Enterprise, gives businesses an easily customizable solution that can integrate data from a number of sources. Think of

ownCloud Enterprise as a switch or router for your current existing data silos, allowing seamless integration and pre-senting the end-user with an intuitive yet simple interface to multiple data sources. For example, administrators may want to utilize existing Windows Server network shares of a department already in place, minimizing data red-undancy and preserving ACLs. In this case, ownCloud Enter-prise, through the use of the Windows Network Drive (WND), could connect to an existing Windows Share “\\server-name\engineering” and allow users to securely access data while at work, home or on the road and collaborate with

Primary Storage Secondary Storage

2

internal colleagues or remotely with contractors. With ownCloud Enterprise’s WND connector, administrators have the capability to integrate with existing SSO solutions in place, LDAP, Active Directory or SAML 2.0 compliant two-part authen-tication thus preserving current ACLs in place on existing Windows Server shares.

As with all Secondary Storage within ownCloud, such connec-tions, once configured, are stored in the ownCloud Enter-prise database. This helps faci-litate horizontal scaling by avo-iding numerous configuration steps as well any changes or additions to Secondary Storage are effective immediately and available across an ownCloud Enterprise cluster.

Vertical scaling is accomplis-hed by increasing system resources, like adding more memory and processing power. Horizontal scaling, on the other hand, is accomplished by adding more servers to an exis-ting cluster. Let’s talk about exactly what that means. Given the nature of ownCloud and PHP’s out-of-the-box single threaded application design, ownCloud (as with most web-based PHP applications) per-forms / scales best in a cluste-red, or scaled-out environment. For this discussion, a cluster is simply a group of ownCloud servers. A load balancer distri-butes the workload between the ownCloud Enterprise ser-vers in a cluster. At any point, a ownCloud Enterprise App ser-ver can be added to the existing cluster to handle more requests from users accessing your ownCloud Enterprise instance; this is horizontal scaling. This

can be accomplished through the stateless operation of the ownCloud code.

While horizontal scaling is usu-ally the most reliable and effici-ent method of scalability, it's not as trivial as vertical scaling. ownCloud Enterprise stores most of the configuration data in the database, so scaling out horizontally is extremely easy. Administrators normally install and successfully configure a single ownCloud virtual-server instance. Once that virtual- server is confirmed and tested, it is cloned using tools provi-ded the underlying hypervisor, powered back up on the exis-ting host or a separate host depending customer environ-ment (a separate host provides minimal redundancy). Once the new virtual-server is running, a new IP address is given and the load balancer is configured with it.

The load balancer has a single responsibility: deciding which ownCloud Enterprise server from the cluster will receive a request from an end-user. It behaves like a reverse proxy, making the process seamless to the end-user. Least connec-tions and round robin are the two most common type of load balancer algorithms used in an ownCloud Enterprise solution. A load balancer with least con-nections combined with sticky sessions affords one of the sim-plest and most common types of load balancing in an ownCloud Enterprise solution. With least connections / sticky sessions the load balancer directs an initial end-user to the server with the least current connections and continues to send the user to the same server simplifying session management .

There are standard and enter-prise grade appliances from companies such as F5, A10, Kemp etc. that are very fast and reliable and can also be setup in a N+1 environment, ensuring even higher availability. If a business is utilizing such enter-prise grade load-balancers they can and should be utilized in front of an ownCloud cluster, reducing deployment costs, setup, maintenance and complications. Open Source HA Proxy is also a very popular and affordable option. Open Source HAProxy sits on top of a standard Linux based OS virtual-machine and can be easily configured, deployed and installed in an ownCloud Enterprise cluster. For High Availability solutions, HAProxy can be configured in a N+1 envi-ronment utilizing a heartbeat mechanism between two physi-cally diverse HAProxys, ensu-ring uptime.

Horizontal versus Vertical sizing

3

ownCloud Enterprise traffic is based on user sessions and leverages PHP to store user session variables. Therefore when implementing an ownCloud Enterprise cluster behind a load balancer, session management and persistence must be taken into considera-tion. There are two fundamen-tally different ways to do ses-sion management in supporting an ownCloud cluster. One is local session management on the application servers com-bined with utilizing sticky / per-sistent sessions on the load balancer. The other is a centra-lized session management tool on the ownCloud Enterprise application virtual-servers. Business drivers will determine which session management solution is best, based on needs and after careful consi-deration of the pros and cons of each. For most business needs, local session management on the ownCloud Enterprise

virtual-machine with the load balancer utilizing sticky / per-sistent sessions will suffice. If business needs dictate other-wise, Memcached or Redis solutions are fully supported by ownCloud and accommodate session management across multiple App servers in the cluster.

ownCloud Enterprise, by design, does not store user session in the database. If ownCloud Enterprise has used the database, then session management across a cluster would not be an issue as the database would be a common storage point. Careful conside-ration was put into the design of user session storage within ownCloud. In order to enable ownCloud to scale beyond one half million users, ownCloud chose to implement in RAM session storage for speed and performance.

ownCloud Enterprise can utilize ClamAV for virus detection. Special consideration should be given when business needs dictate ownCloud to utilize this in-transit AVS solution due to increased CPU, RAM and disk utilization. In all but the smal-lest installations, it is recom-mended that the ClamAV appli-cation be hosted on a separate virtual-machine instance. While this paper is not intended to cover installing and configuring ClamAV, administrators will need to determine the best approach in installing, configu-

ring and implementing ClamAV in their ownCloud environment. Once such configuration of the ClamAV virtual-server is com-pleted, simply notify ownCloud of the location of the ClamAV server in the ownCloud web- portal admin page. While an ownCloud solution utilizing in-transit ClamAV virus scanning is not intended to replace a company’s current at-rest AVS solution, it does afford a second layer of early detection which could minimize impact by eliminating issues downstream.

Some operations that an ownCloud Enterprise server executes take more time to complete, such as expensive calculations or communication with a remote storage server. Other operations are much faster – but are needed many, many times per second. To improve performance and reduce the load on the system caused by CPU / RAM intensive or frequently needed work, ownCloud Enterprise can cache the result of these operations. Since ownCloud 8.1, caching has become an explicit setting.

Caching is used in PHP to store compiled versions of the scripts so they don’t need to be recom-piled on every request. This is called opcaching and has been

included and enabled by default in PHP since the 5.5 release. On PHP 5.4, the oldest currently supported PHP release which works with ownCloud, it is highly recom-mended to install an opcache.

Memory caching, on the other hand, is used directly by web applications like ownCloud. It helps ownCloud avoid slow database queries or file system checks by retrieving a result from a memory cache, either on the local machine or distribu-ted on a cluster of servers. The result is a trade-off of memory usage for improved perfor-mance. As the memory usage of these caches is typically small, it is generally worth the effort to set them up.

User Session Management and Persistence in an ownCloud Enterprise Cluster AVS integration

PHP Caching

4

At its core, ownCloud Enter-prise is a PHP web application running on top of Apache or nginx-based HTTP / web ser-vers, running on the customer's choice of supported Linux plat-forms. There is no advantage or disadvantage to running ownCloud on any of the suppor-ted Linux operating systems or Apache. In the case of selecting an OS for use with ownCloud, businesses will utilize what company policy dictates or leverage existing in-house knowledge to select the base OS. The ownCloud Enterprise PHP application manages every aspect of ownCloud Enterprise, from user management to plug-ins, file sharing and storage. Attached to the PHP application is a database where ownCloud

Enterprise stores user informa-tion, user-shared file details, plug-in application states, and the ownCloud file cache. ownCloud accesses the data-base through an abstraction layer, enabling support for Oracle, MySQL, and Post-greSQL. Complete webserver logging is provided via web-server logs, and user and system logs are provided in a separate ownCloud Enterprise log, or can be directed to a sys-log file. Deploying, scaling, and maintaining ownCloud Enter-prise is similar in fashion to any other LAMP based web applica-tion and follows basic rules, practices and design principles commonly found the in the industry.

As with any HTTP-based LAMP deployment, ownCloud’s deployment scenarios are simi-lar in configuration and resour-ces. With ownCloud, the num-ber of users (both total and concurrent), number of files attached / accessible to the ownCloud instance, available bandwidth, storage IOPs and CPU speed are all considera-tions when sizing your environ-ment for production status. Due to the many variables that are possible for each business and their solution, there is no right “one size fits all” deploy-ment specification. Administra-tors will need to monitor, test, and possibly stress-test their particular deployment before a full production roll out based on their utilization needs and

hardware involved. We will explore a few example deploy-ments to give a better under-standing of how ownCloud is deployed and right-sized, allowing administrators a base guideline to designing the ownCloud Enterprise solution that best fits their business needs.

Server Architecture Server sizing

Company ACompany A is a 200-person company at one location with about 170 users identified as needing access to ownCloud Enterprise. Business need dic-tates that only Primary Storage is required and estimates about 11,000 files totaling 90GB will need to be stored on the Pri-mary Storage of ownCloud Enterprise. Company A has only one IT Administrator, Jane, on staff who has slight experience with Ubuntu and MySQL, thus Ubuntu is selected as the underlying operating system and Jane will utilize MySQL as the database provider. Company A currently is using virtualized technology based

on VMware’ ESXi hypervisor which resides on relatively cur-rent physical hosts of reasona-ble speed (RAM / CPU / Disk).

To deploy ownCloud Enterprise, Jane will create two virtual machines in their environment. One “APP” virtual-server with 2 vCPUs (2 vCPUs per host core) 3GB RAM and 150GB of disk space (30GB for the operating system and 120GB for user data, allowing for growth) and one “SQL” virtual-server, with 2 vCPUs, 3GB RAM and 20GB of disk space. On both virtual ser-vers she will install the latest stable version of a headless Ubuntu operating system. Installing headless servers

(i.e. minimal OS install without a GUI desktop) should be practi-ced with any web based appli-cation server. This not only minimizes hardware provision requirements (CPU, RAM and disk), but also reduces comple-xities and insecurities as well as ensuring uptime.

On the App virtual machine, Apache, and PHP along with any required dependencies will be installed utilizing normal practices for installing applica-tions on a Linux server. Then the ownCloud Enterprise appli-cation is installed. Likewise, MySQL will be installed on the SQL virtual-server and configu-red following ownCloud Enterprise’s instructions. Jane configures PHP to consume a maximum of 512MB and selects APCu as her PHP caching device and allocates 256MB to it.

Seeing that Company A requi-res public facing access to their ownCloud environment, the App virtual-server will be provi-ded with a public IP address (either by use of NAT at the firewall / router or assigned directly to the virtual-server) and set DNS entries respec-tively for the FQDN (Fully Quali-

Implementation Examples

Role vCPU RAM PHP PHP-Cache

OS / App

/data

App 2 3GB 512MB 256MB 30GB 120GB

SQL 2 3GB 20GB

5

fied Domain Name) assigned. Company A’s firewall will be configured to allow the App ser-ver to be in the DMZ and will open TCP port 443 and port 80 access to the App server. As with any ownCloud installation, the SQL virtual-server does not need public IP access, so Jane assigns a private IP address (i.e. 10.10.64.128) and ensures that the App virtual-server can correctly communicate with the SQL virtual-server over TCP / UDP port MySQL (3306).

Jane installs the company's SSL certificates within Apache and confirms they are correctly ins-talled, accessing the server with her web-browser. Jane also configures Apache to redirect all requests to the webserver on HTTP (port 80) to HTTPS (port 443) for the best experi-ence with her end-users. She then points her web-browser to https://owncloud.a.com and configures the initial ownCloud web interface with the required information.

All client interfacing (Browser, Desktop Sync Client, Mobile Apps and WebDAV) to the ownCloud application is accom-plished over HTTPS. No other

ports need to be exposed to the internet. While access to the ownCloud server can be accom-plished over HTTP (port 80), given today’s CPU speed com-bined with security concerns, this is not recommended. Admi-nistrators should forward HTTP (port 80) to HTTPS (port 443) either at the firewall / router level or utilize Apache / nginx to forward port 80 for the best user experience.

Company A uses Microsoft Active Directory (AD) for user authentication. Once configu-red, administrators will select individual AD users or by AD groups, allowing access to the ownCloud application. Once correctly configured, Jane confirms correct setup by successfully logging into the ownCloud web application utilizing her existing AD credentials.

ownCloud utilizes two forms of user authentication, both exter-nal (LDAP, Active Directory and SAML 2.0 via Shibboleth), and an internal to ownCloud Enter-prise user (stored in database). Both external and internal authentication can exist simul-taneously. For example, a busi-

ness can integrate ownCloud with Active Directory to allow authentication for their current employees’ access, and at the same time can utilize ownCloud Enterprise’s internal user authentication mechanism for outside contractors’ access. Contractors that do not have an AD account but require access to files located on the ownCloud server shares and the ownCloud environment can get them.

Company A has a third-party onsite backup solution. Jane will install the subsequent Linux agent provided by the third-party vendor onto both the App and SQL virtual-machi-nes and configure them to back up both the user /data direc-tory and MySQL database. She will also make snapshots (as a

form of backup) of the virtual-machines, as per IT policy, utilizing VSphere. Once Jane ensures the ownCloud installa-tion is operating correctly and secure, she deploys to a small subset of “power-users” within company Company A, for initial testing and feedback. Once ini-tial testing is complete and feedback is satisfactory, she deploys the ownCloud Desktop Sync Client, ownCloud Mobile application as required. After training users on the use of ownCloud, she will monitor the server and environment as she would any other web application.

Company BCompany B is a 450-person Engineering company with approximately 400 users cur-rently approved to have access to the ownCloud Enterprise environment. Company B is gro-wing rapidly so they want to implement without creating any bottlenecks with their growth. Company B has three different locations, utilizing a hub and spoke IT design with good bandwidth between each.

Company B has extensive exis-ting Windows Server shares to integrate into the ownCloud Enterprise environment and is not looking to utilize ownCloud Enterprise’s Primary Storage extensively. Throughout the Windows Server shares across multiple servers, there are 110,000 files consuming 1.2TB of storage. Company B has an admini strator who is familiar with CentOS and MySQL. To deploy ownCloud Enterprise,

Company B administrators will initially create three virtual-machines in their environment.

One “APP” virtual-server with 2 vCPUs (2 vCPUs per host core) 3GB RAM and 30GB of disk

space, one “SQL” virtual-ser-ver, with 2 vCPUs, 4GB RAM and 40GB of disk space and one “LB” (load Balancer) with 1 vCPU, 1GB RAM and 15GB disk space. They will install the latest stable version of a head-

Role vCPU RAM PHP PHP-Cache

OS / App

/data

LB 1 1 15

App (2) 2 3GB 512MB 512MB 30GB 10GB

SQL 2 3GB 40GB

6

less CentOS operating system on all of their virtual servers. The SAN administrator will create a 10GB NFS partition on the company's SAN, allowing the Linux administrator to mount the NFS to each ownCloud Enterprise App server utilizing the FStab moun-ting scheme. This NFS mount will accommodate ownCloud Enterprise’s /data directory. Even though Company B will use Windows Server shares uti-lizing ownCloud Enterprise’s WND app for their data storage, the /data directory is still requi-red for proper operation. In this case, 25MB per user (plus over-head) was used to calculate the size of the NFS mount. While ownCloud will utilize this

user /data directory for meta-data such as thumbnails, versioning, and trash-bin, it is recommended that the ownCloud quota feature be implemented and set at 25MB per user. With a quota specified, ownCloud will ensure that the user directory will comply with the induced quota by maintai-ning the individual users trash-bin and versioning directories (oldest out). Company B has no current load balancer in place so HAProxy was chosen for speed, perfor-mance and budgeting concerns and will be installed on the appropriate virtual machine. Once installed, HAProxy will be configured to point to the IP

addresses assigned to the two ownCloud Enterprise App vir-tual-servers utilizing the Least Connection format (with Round Robin being an option) and Sti-cky Sessions enabled.

Installation of the application server will consist of installing Apache, PHP, APCu for PHP caching and ownCloud Enter-prise. Once this App virtual-server is fully configured (ownCloud setting, PHP set-tings, Apache configuration and SSL certificates etc.), tes-ted and proven, it will be cloned using tools provided within the underlying hypervi-sor, IP address re-configured accordingly and powered up into the cluster. MySQL is ins-talled and configured accordin-gly on the SQL virtual-machine.

While the two App virtual-ser-vers can be installed on sepa-rate physical hosts this does not provide a true HA (High Availa-bility) solution given that the SQL and Load Balancer are sin-gular. Tools such as VMware HA and DRS can be called upon to reduce outage times. If a true, more hardened, HA solution is required, please see next sam-ple solution.

HA, or High Availability solu-tions refer to solutions with automated fail-over and reco-very, while FT or Fault Tolerant ones ensure zero downtime.

Company B has opted to utilize existing Windows 2012 server shares due to the extensive ACLs in place along with the desire not to have data reside in two places (data overlap). ownCloud Enterprise administ-rators will configure the Win-dows Network Drive app of ownCloud Enterprise to point to each specific existing Windows share. Company B has decided to share not only the users exis-ting home directory, but speci-fic department shares as well.

Since Company B has also inte-grated ownCloud Enterprise into their existing Microsoft AD, Company B can also leverage ownCloud Enterprise’s ability to use the users login credenti-als. Using the login credentials allows ownCloud to honor exis-ting Windows ACLs. ownCloud Enterprise end-users will see only what their AD login creden-tials allow.

Once the initial install is com-pleted, tested, verified and the company mandated testing is completed, the IT manager will deploy to a small test group compromising of IT staff and other power-users. During this test period, systems will be monitored and gauged for effectiveness. Once the IT staff is satisfied with the results, they will deploy the desktop sync clients, mobile apps and train the employees in groups

7

of 100 with a three day lapse in between the next group of 100. During each segmented deploy-ment, IT staff is monitoring the ownCloud Enterprise systems and making any minor changes if required.

Initial deployment in an ownCloud Enterprise solution is normally when you see the most load or stress, due to the num-ber of new users and new sync requests. In this case, the IT Manager decided to segment the deployment to relieve any stresses that might have slowed

the systems and provided new ownCloud Enterprise users with the best possible experience with the new solution. The other option that the IT Manager had at his disposal was to increase the number of App servers or even add an additional MySQL server to handle the initial

deployment of all 400 users at once. Once the initial deploy-ment is completed, monitoring the systems would ensure admi-nistrators the timely removal of the additional servers deployed during initial deployment.

Company CCompany C is a growing finan-cial institution with approxi-mately 1100 employees, with 800 employees requiring to have access to the ownCloud Enterprise solution. Due to the nature and timeliness of the financial transactions, they need a Fault Tolerant (FT) solution. Business drivers dictate the need for a 99.999% uptime (“5 nines”) solution for the ownCloud Enterprise envi-ronment. They have a single data center / hub with multiple locations / spokes throughout all four time zones in the conti-nental US. Within this data cen-ter, they utilize two hypervisor vCenters for redundancy and Company C plans to leverage these for ownCloud Enterprise redundancy. Due to the number of possible concurrent users utilizing the ownCloud service,Company C plans to utilize two ownCloud Enterprise web appli-cation virtual-servers for each vCenter (four ownCloud Enter-prise App servers total due to redundancy). They have no current Windows shares that would be useful for their end-users so they elect to use ownCloud Enterprise’s Primary

Storage as the default storage.Company C already has a subs-tantial investment in an exis-ting highly redundant SAN, so they will create an NFS mount point for the ownCloud /data directory. After speaking to management and considering all business drivers, they have elected to allocate 5GB of disk

space for each ownCloud user and the SAN admin creates a 4.7TB NFS mount point on their company's SAN. Company C has standardized on Red Hat as their primary Linux operating system and due to in-house expertise, selected PostgreSQL as the database software.

Initially they will create 3 virtual machines; one each for the Load Balancer, APP and MySQL. The Linux Administrator will install HAProxy on the Load Balancer virtual-machine, ownCloud Enterprise on the

App server and MySQL on the SQL virtual-machine. The Linux Administrator will also mount the NFS created by the SAN administrator and modify own-Cloud Enterprise’s config.php to point to the new /data direc-tory. Company C has also elec-ted to install Redis on the App virtual-machine for file-locking and Redis for both file locking and Redis with 1GB of RAM for improved PHP caching perfor-mance. Once Company C has all three virtual-machines (load balancer, App and SQL) in place, it will begin its testing.

Role vCPU RAM PHP PHP-Cache

OS / App

/data

LB (2) 1 1 15

App (4) 2 4GB 1GB 1GB 30GB 4.7TB

SQL (2) 2 4GB 60GB

8

Once satisfied with the perfor-mance, it will "clone" the single app instance and bring up a second app virtual-machine and configure both it and update the Load Balancer accordingly. Again testing takes place. Once fully tested, IT administrators will replicate the solution (Load Balancer,

two App , and SQL virtual-machines) onto a separate vCenter for redundancy. A heartbeat will be setup bet-ween the two load balancers, with one set to active and the other to passive. A Master / Slave Relationship will be esta-blished between the two Post-greSQL virtual-machines.

While a Master / Master relati-onship of the SQL servers would allow a faster recovery time and uptime for the ownCloud solu-tion, Company C felt that the added complexity and limit in IT staffing might make the Master / Master relationship too com-plicated. While a manual inter-vention will have to take place

with the Master / Slave relation-ship of the SQL servers in the event of a fail-over, they weig-hed the pros and cons and felt a Master / Slave relationship would best meet their needs and resources.

Company DCompany D is a global retail company with multiple loca-tions throughout Europe and Asia. They have two diverse data centers that house their entire IT infrastructure, one in France and the other in Japan, with each serving numerous offices in their respective region. While the business spans continents, the data required between numerous offices is common in nature and required at all locations, requi-ring a form of data replication. With 21,000 ownCloud users and growing, spread out across Europe and Asia, Company D wants to implement an ownCloud Enterprise solution that is not only geo diverse but redundant between continents. They have concluded they will need at least 12TB of Primary Storage space to house their estimated 1.2mil flies and for normal day-to-day operations with room for growth.

Company D will create two geo-graphically diverse ownCloud

Enterprise clusters, one at each data center (France and Japan). ownCloud Enterprise’s Primary Storage is determined to be the best solution for their primary collaboration needs. It is deter-mined that end-users will require access to their indivi-dual existing Windows home directories already in place. Company D has extensively uti-lized GlusterFS in the past and selected this as the Primary Storage for their ownCloud Enterprise solution. They will utilize GlusterFS’s native block-level distributed replication to replicate ownCloud Enterprise’s Primary Storage between both data centers. Company D will utilize Window Server’s Distri-buted File System (DFS) to accommodate replication of the end-user’s /home directories between the two data centers.

Company D has existing enter-prise grade F5 load balancers already in place at both the data center level and global level and will utilize such for their ownCloud Enterprise solu-

tion. At the global load balan-cer, they will distribute their cli-ent requests based on both GeoIP (remote users / home office etc ) as well as office IP subnet with a failover sequence to the sister data center if the assigned data center goes dark. Company D determined that end-user sessions need the ultimate uptime and cannot withstand and interruption if one of the application servers has a failure or disruption. Within each data center, they will configure their existing third party load balancers to utilize an algorithm based on the load of the underlying own-Cloud Enterprise virtual-machi-nes (i.e. virtual-machine with the least load on it will receive the request). They will also depend on F5’s health monitors for the ownCloud Enterprise App virtual-machines and con-figure such accordingly. After initial testing, Company D determined that the load balan-cers are better performers at SSL encryption, thus they will terminate the SSL connection at the load balancer and com-municate to the ownCloud Enterprise App cluster over HTTP (port 80). Outbound traf-fic from the cluster will be enc-rypted at the load balancer. They will also introduce priority

activation at the load balancer lever in conjunction with their hypervisor to increase or decre-ase the size or number of vir-tual-machines within each clus-ter as load demands.

While the ownCloud Enterprise virtual-machine can receive and decrypt HTTPS through either Apache or nginx, Company D felt that the best use of resour-ces would dictate the load balancer offload SSL encryption / decryption. Since the load balancer is public facing and in the DMZ, but the cluster sits on private LAN outside of the DMZ and in a physically secure SSAE-16 data center, HTTP (unencryp-ted) communications to the cluster is more than secure. This also frees up resources on each individual App server and utili-zes the dedicated processers and algorithms within the load balancer.

Since Company D is using a load-based algorithm, they will put a Redis cluster in place to deal with session states. They will follow the recommended sizing documentation provided by Redis to properly size the cluster.

Role vCPU RAM PHP PHP-Cache

OS / App

/data

App (8) 2 4GB 1GB 1GB 30GB 12TB

Proxy (4) 1 1GB 15GB

SQL (4) 4 8GB 70GB

9

While Company D could have forgone the Redis cluster, much discussion was had internally regarding redundancy and end-user experience. A normal load balanced cluster implementa-tion with sticky / persistent ses-sions raised two concerns. Firstly, if the App virtual-machine had a failure, either hardware, software or required scheduled maintenance, a sti-cky / persistent session based solution (without global session management) would require the user to be dispatched to a diffe-rent server, thus losing the saved session data and requi-ring the end-user to login again. Also with sticky / persis-tent session based solutions, there is a possibility that certain servers with in the App cluster

will become saturated and under-perform due to the per-sistent algorithm not allowing the session moving to a less uti-lized App server. Given these two scenarios, they felt it would worthwhile to provide a better overall user experience by utili-zing the least load algorithm along with the Redis cluster.

Company D has significant in-house MySQL Cluster experi-ence and expertise. They deci-ded to create a dual Master / Slave cluster with a SQL proxy redundant cluster, distributing read / write requests between individual MySQL nodes. While there are many ways to imple-ment a replicated / redundant SQL solution (i.e. MySql Clus-ter, MariaDB Galera, Oracle Gol-

denGate, etc) this paper will not cover these in detail due to the complexities involved, and would defer to the respective documentation for each parti-cular vendor.

Company D will deploy their ownCloud Enterprise environ-ment as previously discussed. They inform both the Load Balancer team and SQL DBA team of their requirements and configuration needs. They will pay special attention to their install and configuration of the ownCloud Enterprise App vir-tual-machine as it will be a baseline for future machines in the cluster. Company D has chosen to utilize Apache as their web-server. They will ins-tall and configure Apache, PHP,

Redis, F5 health monitors and the ownCloud Enterprise appli-cation on their standardized RHEL headless operating sys-tem. They will also configure the 12TB NFS mount to each App server through the use of the FStab. Additionally they will configure the Redis confi-guration parameters within ownCloud Enterprise to point to the Redis cluster.

Company D has a mandated corporate policy that all sys-tems sitting in the DMZ receive a thorough penetration test (pen-test) both from the inter-nal security team and by a third party external vendor. As expected, they will work through the normal PHP, Nginx and OS related network issues

10

that the pen-test alerts them to, and will work with the ownCloud Enterprise deploy-ment personnel to work through / understand any issues related to ownCloud Enterprise reported by both pen-tests. Normally pen-tests directed towards ownCloud Enterprise virtual-servers reveal issues with the underly-ing server, including the OS, web server and PHP.

While these are common issues with simple remedies (i.e. out-dated PHP and / or related dependencies, outdated ciphers in the SSL portion of the web-server, etc.) some might arise from the actual ownCloud Enter-prise App itself. In this case the ownCloud deployment team is there to assist customers with resolutions or explanations of any false positives.

After they have fully configured and tested the initial ownCloud Enterprise virtual-machine, and

resolved any outstanding issues with the security team and the pen-test, Company D will stress test the initial App virtual-machine using a third party application (i.e. Apache JMeter, WebLOAD, LoadRunner, etc.) to ensure that the virtual-machine is performing as expected. Any inconsistencies or under-performing returns will be dealt with accordingly. Once completed, they will use the underlying hypervisor to template and clone the ownCloud Enterprise App vir-tual-machine according to their design plan. They will once again add the virtual-machines to the ownCloud cluster at each data-center and configure the appropriate items for both the load balancers, SQL resource pool and Redis cluster. Once the final solution is in place, they will stress test both data centers separately and accor-ding to proposed designed load. After any changes or remedies required by the

global stress test, Company D will implement a thorough and relentless fail-over test sequence (i.e. pull the plug) to test all systems and redun-dancies put in place.

Company D will also utilize ownCloud Enterprise’s Logging app, to give insight on each user and file and the associa-ted movements of each, not only for internal use but for government mandated compli-ance. They have standardized on Splunk for their log file management and will configure Splunk to monitor and converge their ownCloud Enterprise log files.

Once Company D is fully confi-dent in both the user load stress testing and fail-over tes-ting, they will implement their deployment plan. Initially they will select an initial deployment of 100 power-users and deploy their ownCloud Enterprise own-Branded desktop application

and phone / tablet apps, utili-zing their Windows based deployment packages and mobile management applica-tions respectively. They will conduct feedback analysis of the initial deployment; will monitor systems in place for performance concerns. Once satisfied with the initial deploy-ment and any necessary recon-figurations, they will stage 7 separate deployments of 3000 users each, thus reducing ini-tial load on the infrastructure. They have devised a short internal 30 minute web-based training session to introduce and train each of the 3000 users at the beginning of each deployment stage. Company D will actively monitor the entire solution during each stage of deployment and make any necessary adjustments. Once the last deployment is made, they will call their solution a success and end-users will be readily collaborating in an intu-itive and secure environment.

Big Corporate Conglomerate (BCC)BCC is a large 15,000 employee company with many diverse business units (i.e. Retail, government contracting, ban-king, etc.). From a business standpoint, these divisions operate independently with minimal need to communicate with other divisions, and some modest requirement to commu-nicate with their corporate headquarters. After careful review off the business needs within BCC and developing a solution for an Enterprise File Sync and Share, they have settled on utilizing ownCloud

Enterprise for their needs. Within BCC, the need to colla-borate between divisions is minimal. Of particular interest was the capability of BCC not only to create individual / sepa-rate ownCloud Enterprise solu-tions for each division, but also to utilize ownCloud Enterprise’s Federated Cloud sharing to accommodate the lesser need of collaborating amongst divisi-ons. Headquarters also has a vital need to securely receive finincial reports, marketing documents as well as other files securely and seemlesely from each division.

With Federated Cloud, users at one division of BCC can colla-borate with users at another division while each divisional ownCloud Enterprise server maintains its respective secu-rity and governance protocols and does not require BCC to replicate uneeded data across diverse business entities. ownCloud Federation gives

diverse users the flexibility and transparency to securely and easily share files between divi-sions without IT administrator involvement. BCC users are no longer confined to a single shared folder or servers within their respective divisions. Federated sharing with ownCloud Enterprise also gives BCC the ability for administra-

11

tors to mount comonly used data through the use of the External Storage App. This, combined with the ability for end-users to individually share files and folders with other divi-sion users, will provide BCC the collorabation it needs across different division silos. BCC has a corporate security policy that requries the use of two part authentication for all users. BCC selected ownCloud Enter-prise to accomplish these. BCC will install the ownCloud Enter-prise Shibboleth app and ins-

tall and configure mod_shib along with Apache on their Cen-tOS 7.1 enviroment. BCC will configure both the /etc/apa-che2/conf.d/shib.conf and the /var/www/html/ownc-loud/config/config.php on each ownCloud App virtual machine. Once configured, BCC will test each server to ensure proper configuration and performance.

To deploy the Federated ownCloud Enterprise solution company wide, BCC will treat

each diverse division unit as a separate solution as far as the ownCloud Enterprise solution is concerned. Given the diffe-rent technologies in place for each division, BCC IT Managers will customize each solution to connect to the resources within each division, but attempt to keep common practices within each enviroment (i.e Linux OS, WWW Server, Load balancer, SQL server, etc.) as required. BCC can use the samples provi-ded here as a baseline for each divisional deployment.

12

ownCloud, Inc.57 Bedford StreetSuite 102Lexington, MA 02420United States

www.owncloud.com/contactphone: +1 (877) 394-2030

ownCloud GmbHSchloßäckerstr. 26a90443 NürnbergGermany

www.owncloud.com/de/kontaktphone: +49 911 14888690

www.owncloud.com

@ownCloudfacebook.com/owncloudgplus.is/owncloudlinkedin.com/company/owncloud

Copyright 2016 ownCloud All Rights Reserved. ownCloud and the ownCloud Logo are registered trade-marks of ownCloud, Inc.in the Uni-ted States and/or other countries.

ownCloud is the leading open sourced Universal File Access solution with more than 8M users and supported not only by ownCloud.com, but also by one of the top open source communities with over 1000 contributors. ownCloud is open by nature and designed to integrate with a company’s existing infrastructure, management and security tools. A comprehensive set of APIs and native integrations enable anytime, anywhere

access to all your data, where-ver it resides – in applications, object stores, on premise sto-rage or in the cloud. ownCloud is designed to scale to meet any company’s goals and requi-rements both today and into the future. For more informa-tion on how ownCloud can help your company provide Univer-sal File Access to any device, anytime, anywhere, while lea-ving IT in complete control, visit ownCloud.com.

Conclusion

Whi

tepa

per A

rchi

tect

ural

Gui

de E

NG 16

0503