wp-mail-logging
domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init
action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/html/wp-includes/functions.php on line 6114broken-link-checker
domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init
action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/html/wp-includes/functions.php on line 6114health-check
domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init
action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/html/wp-includes/functions.php on line 6114updraftplus
domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init
action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/html/wp-includes/functions.php on line 6114wp-extended-search
domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init
action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/html/wp-includes/functions.php on line 6114rocket
domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init
action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /var/www/html/wp-includes/functions.php on line 6114<\/p>\n The Tu Berlin was one of the first universities to provide its own file sync and share solution, already evaluating ownCloud back in 2011. They provided cloud storage within the DFN cloud research program, servicing 16 member research and higher education institutions today. Their service has over 22.000 active users at the TU Berlin, with more at the other organizations and storage for the TU Berlin itself is well over 70 TB, with students allowed a maximum of 20 GB data and staff members up to 100 GB.<\/p>\n The TU Berlin uses load balancers spreading user requests between 4 application servers which run a NGINX\/MySQL\/PHP 5.6 stack on CentOS 7.3. Data can be found on a GPFS-based storage and a Galera MySQL cluster while LDAP and Kerberos handle authentication and all of it runs in LXD containers managed with OpenStack.<\/p>\n After Nextcloud won a tender for providing a new file sync and share solution, TU Berlin decided to migrate to Nextcloud 11 which promised significant scalability, security and feature improvements.<\/a> The team is also interested in exploring Nextcloud Global Scale<\/a> in the future, for scaling up their DFN cloud service and decreasing the total cost of ownership.<\/p>\n The migration was planned during the course of three weeks and executed in one week, fitting the update window set between the result of the tender and end of the old contract. A test environment built from a copy of production was used to prepare. As part of the migration to Nextcloud 11, the TU Berlin decided to move to NGINX from Apache, which was made possible thanks to the native SAML support in Nextcloud.<\/p>\n The migration process itself was ready in time and worked exactly as planned. The TU Berlin did not need any stand-by support from Nextcloud.<\/p>\n Overall, the migration was like a typical upgrade.<\/p><\/blockquote>\n Before Nextcloud 11 was deployed, the TU Berlin faced scaling issues with heavy peak load on the database cluster during working hours. The migration resulted in peak load decreasing by over 38% while off-peak times even show a 49% lower stress on the servers. Thanks to this improvement users experience a snappier experience and faster syncing while the TU Berlin can now grow further without significant investment.<\/p>\n
\nLast week, we announced<\/a> that 9 German education and research organizations moved from ownCloud to Nextcloud together with the TU Berlin. Today we’ve published a case study on our website<\/a> which details the migration of the TU Berlin and the results achieved, including 50% lower base and 38% lower peak database loads. The end result was faster service to users at lower cost.<\/p>\nTU Berlin’s ownCloud-Nextcloud infrastructure<\/h2>\n
Migration<\/h2>\n
Results<\/h2>\n