Переезд с OneDrive на Nextcloud: можно ли сделать полноценную замену облачному диску на базе открытого ПО

Чтобы сделать корпоративное файловое хранилище на базе Nextcloud, мы интегрировали платформу в нашу экосистему отказоустойчивых сервисов. Так, балансировщики нагрузки, базы данных, серверы приложений были кластеризованы и распределены на 3 площадки, чтобы в каждом ЦОДе был один узел кластера (кроме СУБД с метаданными и балансировщика — для них были запущены два активных сервера и один арбитр на третьей площадке).

Если вы работали с Nextcloud, то знаете, что сам он не особо поддерживает кластеризацию. Поэтому каталог с файлами Nextcloud синхронизируется между площадками уже нашими инструментами. Но зато встраивание Nextcloud в обкатанную схему кластеризации, которая много лет работает для других проектов, позволило нам добиться масштабирования как горизонтального, так и вертикального.

Серверы работают в Failover-конфигурации. Для кластеризации СУБД используется Galera. В результате любые работы на ЦОДах в 99% случаях не затрагивают сервис, и он работает без даунтайма. Получается сервис, подобный OneDrive.

Кстати, распределять трафик на балансировщики можно по мере необходимости. Но пока такой задачи у клиентов не возникало. При необходимости мы сделаем.

Метаданные мы храним в MariaDB — это СУБД, которую рекомендует разработчик Nextcloud. Кластеризация MariaDB работает на базе Galera. Это ПО хорошо себя зарекомендовало. Мы его используем в более высоконагруженных инсталляциях, в том числе в сфере e-com, так что нет никаких сомнений, что Galera справится с кластеризацией СУБД для Nextcloud.

Кеширование реализовано на Redis, который также рекомендует разработчик Nextcloud. И это отличный выбор, потому что все остальное работает очень медленно, включая как memcached-схему, так и работу вообще без кеша. В кластере Redis хранится исключительно кеш (то есть Sentinel нам не нужен). Поскольку поддержка Redis зашита нативно, Nextcloud легко распределяет ключи. Производительность платформы оказывается в 10 раз выше, чем без сервиса кеширования. И это очень важно, потому что без кеша больше чем 300 пользователей не смогут нормально работать в Nextcloud — им будет не хватать пропускной способности сервиса.

Поиск по логам работает на базе Filebit и elasticsearch. Для их сбора и дальнейшей систематизации используется весь стандартный ELK стек, включая kibana.

Доступ ко всей инфраструктуре имеет только служба сопровождения, остальные пользователи могут обращаться только к открытым портам сервиса Nextcloud — а это только порт 443. Также на короткий промежуток времени открывается порт 80 для обновления сертификата.

Есть инстансы Nextcloud, которые недоступны снаружи. Они работают только внутри контура заказчика, что обеспечивает максимальную защиту данных. В этом случае мы используем механизмы облака K2 Cloud, чтобы обеспечить разграничение прав доступа.

Что касается кодовой базы, возникает необходимость использовать только актуальное ПО. Все пакеты обновляются до безопасных версий. Если какой-то пакет устаревает и становится уязвимым, мы, получаем уведомления об этом и обновляем его. Для этого используется сканер уязвимости, работающий в режиме алертинга.

Давайте обсудим самое интересное — наши доработки. Клиенты, как правило, приходят с тем, что было. Они могут использовать решения OneDrive, Samba — то, что бекапится штатными средствами. Наш Nextcloud работает на базе S3 с тремя зонами доступности, так что он гарантирует сохранность данных сам по себе. Но иногда бывают такие сценарии, при которых пользователям нужно откатиться к предыдущим версиям файлов. И тут возникает задача бекапа, потому что сам себя бэкапить Nextcloud не умеет. Мы решили добавить эту фичу, и чтобы из резервной копии можно было восстановиться, нужно было настроить бэкап хранилища вместе с СУБД.

Чтобы что-то забэкапить, нужно собрать все данные и положить их в файловую систему. Наш плагин решает следующую задачу: он выгружает файлы из S3, обогащает их метаданными и раскладывает в ФС — пользователь/папка/файл.

Далее все это нужно поддерживать в актуальном состоянии, учитывая огромные объемы. У нас есть пользователи, хранящие по 40-60 Тб. Это тот объем, который невозможно загрузить за 1 день из S3 и куда-то сложить.

Поэтому плагин хранит информацию, кто и что сделал: кто загрузил, кто редактировал, кто удалил. Мы обогащаем образ изменениями, не перекачивая все еще раз.

А дальше работает любое агентское решение: у кого-то из заказчиков есть уже свои продукты категории РК, к которым они уже привыкли. Иногда мы делаем сервис резервного копирования сами. В любом случае после обработки мы снова складываем резервную копию в другое S3 хранилище, но уже с учетом дедупликации, сроков хранения и других нюансов, которые могут быть индивидуальными для каждого заказчика.

Еще одна доработка, которая оказалась востребованной — плагин расширенной статистики хранилища. Сам Nextcloud может дать статистику, но в ограниченном формате. Он показывает только общую утилизацию хранилища и не дает данных в разрезе пользователей. Наша доработка позволяет эту статистику отображать, выгружать в csv, а также автоматически отправлять на почту. В итоге вы можете понять, сколько и кем использовано места. По каждому пользователю видно, кто сколько занял места своими личными каталогами, сколько отнимает в групповых папках. Можно посмотреть, сколько занимают версии документов.

Nextcloud может делать публичные ссылки. Это аналог шеринга через Яндекс.Диск, GoogleDrive и так далее. Однако иногда нужно поделиться файлами только внутри компании. Для этого существуют защищенные ссылки: они доступны только тем, кто авторизовался на конкретном сервисе Nextcloud.

Нужно учитывать, что Nextcloud выпускает несколько мажорных релизов в год. Минорные идут практически каждый месяц. Мы стараемся поддерживать совместимость с большинством версий. Но при этом при каждом новом релизе что-то во внутренней логике меняется. Это необходимо учитывать.

Мы дорабатываем каждый раз наши плагины, чтобы они работали с новейшим релизом Nextcloud. Не делать этого нельзя, потому что люди не желают сидеть на старых версиях — им хочется новых возможностей. К тому же просто небезопасно выставлять в открытый интернет Nextcloud двухлетней давности — его могут взломать.

Многие доработки реализуются буквально за несколько часов. Если приходится править что-то серьезное, то в наших интересах сделать так, чтобы исправление попадало в основную ветку Nextcloud. Для этого недостаточно просто зайти в Git и сделать pull-request. Пока изменения войдут в следующую версию Nextcloud, могут пройти месяцы.

Благодаря проведенной работе мы сегодня располагаем готовым сервисом, который позволяет реально заменить облачный диск для хранения файлов и совместной работы. Он включает OneDrive, GoogleDrive и другие сервисы, ставшие недоступными в России или оказавшиеся в зоне риска с точки зрения стабильности и конфиденциальности.

На базе Nextcloud, который уже врос корнями в наше облако, можно вместе работать с документами за счет интеграции с офисными пакетами (сейчас поддерживаются MS Office, OnlyOffice и так далее). Все это работает на корпоративном уровне, то есть поддерживаются тысячи пользователей и десятки терабайт данных. Для реализации такого сервиса локально у себя потребуется немало человеческих ресурсов. У нас только над постоянным патчингом и поддержкой облачного хранилища непрерывно работают 13 специалистов. То есть пройти этот путь вполне можно, но только если у вас есть 10-20 свободных, недозагруженных спецов.