ownCloud Infinite Scale: новая архитектура вылезает боком через полгода

MAATRIX

Первые недели с ownCloud Infinite Scale обычно проходят гладко: docker compose up -d, минут пять на первый старт — и в браузере открывается новый веб-интерфейс на Vue, быстрый, без намёка на PHP под капотом. Кажется, что это тот же ownCloud, только шустрее. На деле Infinite Scale (в логах и документации — просто oCIS) не следующая версия старого продукта, а написанный с нуля сервер на Go с принципиально другой архитектурой хранения, аутентификации и обновлений. Первые месяцы разница незаметна: файлы синхронизируются, шары работают, редактор документов открывается. Дальше начинают вылезать вещи, которых не видно на этапе быстрого знакомства — архитектура, рассчитанная на масштабирование в кластере, на одной VPS ведёт себя иначе, чем PHP-монолит, который вы привыкли администрировать через occ.

Новая архитектура: из PHP-монолита в микросервисы на Go

Классический ownCloud Server (и его форк Nextcloud) — это PHP-приложение поверх Nginx/Apache + PHP-FPM + MySQL/MariaDB: файлы лежат на диске как есть, метаданные — в таблице oc_filecache. oCIS переписан целиком на Go и построен на reva — открытом фреймворке, реализующем протокол CS3, который изначально делали для проекта CS3MESH с участием CERN. Поверх reva собран набор из нескольких десятков внутренних сервисов: proxy/gateway на входе, graph (API пользователей, групп и «пространств» в духе Microsoft Graph), webdav/ocdav/ocs, storage-users/storage-shares, sharing, встроенный idp/idm, search (свой индекс на Bleve, без внешнего Elasticsearch), thumbnails, antivirus, collaboration (WOPI-коннектор для Collabora или OnlyOffice) и postprocessing, прогоняющий каждую загрузку через цепочку проверок.

По умолчанию все эти сервисы запускаются как горутины внутри одного процесса — бинарник ocis server в один клик поднимает всё сразу, поэтому первое знакомство выглядит обманчиво простым. Название «Infinite Scale» — про то, что в продакшене каждый сервис можно вынести в отдельный контейнер и масштабировать независимо, а общаются они по gRPC и через внутреннюю шину событий на NATS — например, чтобы асинхронно прогнать файл через антивирус после загрузки, не блокируя ответ клиенту.

Для администратора это значит: PHP в системе нет вообще. Не будет occ, тюнинга PHP-FPM, Composer, OPcache — вместо них десятки переменных окружения (OCIS_*, PROXY_*, GRAPH_*) и общий JWT-секрет, которым сервисы подтверждают друг другу подлинность запросов. Если вы сравниваете самостоятельно хостируемое облако в целом — начните с разбора Nextcloud против Seafile: там классическая архитектура на PHP, здесь — принципиально другой стек внутри того же продуктового семейства.

Хранилище decomposedfs: где лежат файлы и что это меняет для бэкапа

Самая заметная разница вылезает, когда вы впервые заходите на сервер по SSH и пытаетесь найти файл пользователя привычным способом. В классическом ownCloud/Nextcloud отчёт.pdf лежит в data/ivan/files/отчёт.pdf под своим именем. В oCIS хранилище по умолчанию использует драйвер decomposedfs: каждый файл и папка становится «узлом» с собственным UUID, содержимое лежит блобом в дереве вида data/spaces/<space-id>/nodes/<node-id>, а имя, права, версии и теги хранятся не в файле и не в общей таблице, а в расширенных атрибутах (xattr) самого узла на файловой системе. Пространства («spaces») — это и личное хранилище пользователя, и общие проектные диски: у каждого свой UUID, и структура каталогов на диске к читаемым именам отношения не имеет.

Отсюда три практических последствия, которые не видны, пока не понадобится что-то руками.

• ls и grep по каталогу данных больше не работают. Найти файл конкретного пользователя через find data/ -iname "отчёт*" нельзя — увидите только UUID-каталоги. Смотреть содержимое нужно через WebDAV, graph API или сам веб-интерфейс, а не глазами на файловой системе.
• Бэкап без флага -X тихо теряет метаданные. Обычная привычка — rsync -a — копирует блобы, но не переносит расширенные атрибуты, а значит после восстановления узлы окажутся без имён, прав и версий. Нужно явно:

rsync -aAX --delete /var/lib/ocis/storage/users/ /backup/ocis-storage/

Флаг -X здесь не опция для перфекционистов, а обязательное условие того, что восстановленные данные вообще будут читаемы как файлы, а не как мешок анонимных блобов — тот же класс проблемы, что у Seafile с блочным хранилищем, только метаданные размазаны по xattr прямо на файлах.

• Требования к файловой системе. decomposedfs рассчитан на POSIX-файловую систему с полноценной и быстрой поддержкой xattr — на локальном ext4/XFS на NVMe это не заметно, а вот на сетевых шарах (NFS, некоторые CIFS-монтирования) или экзотических storage-драйверах xattr могут вести себя непредсказуемо: не пишутся, теряются или заметно замедляют загрузку. Держите каталог данных на локальном диске, а не на примонтированной сетевой шаре — проверьте это до переезда, а не после первой пропавшей версии файла.

Если вам принципиально важно объектное хранилище вместо каталога на диске, у oCIS есть альтернативный драйвер S3ng — блобы уезжают в S3-совместимое хранилище, а метаданные в xattr остаются локально; подробнее о том, как вообще устроено такое хранилище у себя, — в статье про S3-совместимое хранилище у себя.

Миграция со старого ownCloud или Nextcloud: чего не покажет документация

Здесь чаще всего и происходит первое разочарование. Формат хранения decomposedfs несовместим с классическим «файлы на диске плюс таблица oc_filecache» — прямого «поставить поверх и обновиться» не будет, это не тот переход, что между мажорными версиями Nextcloud. Официальный миграционный тулинг существует и развивается, но зрелость переноса конкретных вещей — списков шар, истории версий, прав доступа — стоит проверять на тестовом стенде с копией реальных данных, а не полагаться на документацию буквально.

Рабочий путь, которым в итоге пользуется большинство: не мигрировать бинарно, а поднять чистый oCIS рядом со старым сервером и перелить данные поверх WebDAV — тем же rclone, что и при обычном переезде между облаками:

rclone config create old-nextcloud webdav url=https://old.example.com/remote.php/dav/files/USER/ vendor=nextcloud user=USER pass=OBSCURED_PASS
rclone config create new-ocis webdav url=https://ocis.example.com/remote.php/webdav/ vendor=owncloud user=USER pass=OBSCURED_PASS
rclone copy old-nextcloud: new-ocis: --transfers 8 --checkers 16 -P

Это надёжно переносит содержимое файлов, но не переносит шары, права и историю версий автоматически — их придётся выставлять заново через graph API или руками в интерфейсе. На объёме в сотни гигабайт и десятки активных шар это отдельный проект с чек-листом, а не пять минут; общий подход к такому переезду — в статье про перенос файлового хранилища на терабайты. Для сравнения: бэкап и восстановление Nextcloud остаётся куда более предсказуемой процедурой именно потому, что там формат данных не меняется между версиями.

Второй сюрприз — с идентификацией пользователей. Быстрый старт oCIS обычно поднимают на встроенном демо-хранилище учёток. Когда через пару месяцев доходят руки подключить настоящий LDAP или Active Directory через idp/graph, выясняется, что пространства данных (spaces) жёстко привязаны к UUID пользователя из бэкенда идентификации, активного на момент создания — смена бэкенда задним числом оставляет пространства осиротевшими, и их приходится перепривязывать вручную. Правильный порядок обратный: сначала подключить постоянный источник пользователей, потом заводить реальные данные.

Экосистема приложений: чего не хватает после переезда с классики

У классического ownCloud и Nextcloud за годы накопилась большая экосистема PHP-приложений: календари и контакты по CalDAV/CardDAV, чаты, канбан-доски, десятки интеграций из маркетплейса. В oCIS этой экосистемы просто нет физически — там не на что ставить .tar.gz из старого маркетплейса, потому что PHP-рантайма в системе не существует. Расширяемость устроена иначе: новый веб-интерфейс — это Vue-приложение, которое подгружает отдельные «web-расширения», а часть привычной функциональности либо реализована отдельным микросервисом (совместное редактирование через collaboration/WOPI — концептуально то же самое, что Collabora-приложение в Nextcloud, но по-другому собранное), либо всё ещё в процессе переноса и заметно уступает тому, к чему все привыкли в зрелом Nextcloud.

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

Микросервисы в проде: что падает тихо, а что — с грохотом

Распределённая архитектура меняет саму природу отказов. В классическом монолите падение PHP-FPM обычно кладёт весь сайт разом — неприятно, зато сразу заметно. В oCIS падение одного из десятка процессов чаще не роняет систему целиком, а тихо выключает одну функцию: упал search — поиск перестаёт находить что-либо, но файлы синхронизируются как ни в чём не бывало; упал thumbnails — вместо превью иконки-заглушки; упал notifications — письма о новых шарах перестают уходить. Обнаруживают это обычно не по алерту, а по жалобе пользователя недели через две.

Ещё три источника тихих поломок стоит держать в голове.

• Рассинхронизация общего секрета между сервисами. Внутренние вызовы в oCIS подписываются общим JWT-ключом (OCIS_JWT_SECRET или аналогичная переменная); если при пересборке docker-compose часть контейнеров подхватила новое значение из .env, а часть осталась на старом образе, получаются загадочные 401 Unauthorized между сервисами — лечится только синхронным пересозданием всех контейнеров с одинаковыми переменными.
• Конвейер постобработки загрузок. Каждая загрузка проходит через postprocessing, который через события в NATS прогоняет файл по шагам: контрольная сумма, антивирус (через ICAP до ClamAV, если включён), индексация. Если один из шагов недоступен, загрузка зависает в промежуточном статусе вместо понятной ошибки — симптом «файл вроде загрузился, но открывается не сразу», и проверять в первую очередь стоит здоровье postprocessing и антивирусного бэкенда, а не сеть или диск.
• Дрейф переменных окружения между версиями. Новый релиз иногда добавляет обязательную переменную, которой не было в старом .env; сервис либо падает при старте с понятной ошибкой, либо — хуже — стартует с дефолтом не по ожиданиям (например, демо-режим аутентификации там, где стоял боевой LDAP). Перед обновлением сверяйте changelog и diff .env с актуальным docker-compose.yml, а не просто меняйте тег образа.

Эксплуатация: бэкап, обновления и мониторинг в мире из десятка процессов

Бэкап. Полный набор для восстановления — это три части: каталог данных с блобами и узлами (только с сохранением xattr, rsync -aAX), конфигурация и переменные окружения (.env, docker-compose.yml, примонтированные конфиги сервисов) и встроенные хранилища состояния отдельных сервисов — в отличие от классики, где почти всё держит одна MySQL/MariaDB, в oCIS состояние по умолчанию размазано по нескольким встраиваемым key-value хранилищам. Единого «сделайте один dump и вы восстановлены» здесь нет — проверяйте, какие тома примонтированы для каждого сервиса, и включайте в бэкап все, а не только «основной» том данных.

Обновления. Проект развивается быстро, и в отличие от Nextcloud с его предсказуемыми мажорами и запретом перепрыгивать через версию, у oCIS такой формализованной политики пока нет — тем важнее не обновлять продакшен сменой тега latest вслепую, а фиксировать конкретную версию образа, читать changelog и проверять обновление сначала на копии. Снапшот VPS перед обновлением здесь оправдан не меньше, чем перед любым апгрейдом с непрозрачной миграцией состояния.

Мониторинг. Раз сервисов много, полагаться на «сайт открывается — значит всё в порядке» не получится: сайт может открываться при упавшем search или notifications. Разумный минимум — health-проверки на уровне каждого контейнера (docker compose ps покажет unhealthy) плюс агрегация логов в одно место, потому что грепать журнал десятка процессов по очереди при инциденте — не вариант:

docker compose logs -f --tail=200 proxy gateway storage-users search postprocessing
docker compose ps --format "table {{.Name}}\t{{.Status}}"

Что заказать в MAATRIX под ownCloud Infinite Scale

Готового автоустановщика для oCIS в каталоге apps.maatrix.io пока нет — разворачивайте официальный docker-compose.yml на чистой Ubuntu 24.04. Ключевое требование к серверу — не мощность, а тип диска: под каталог данных нужен локальный NVMe с нормальной поддержкой xattr, сетевые тома для decomposedfs принципиально не берите (причины — в разделе про хранилище выше).

Десяток независимых Go-процессов сами по себе легче, чем PHP-FPM с тем же числом воркеров, но расход памяти растёт с числом включённых сервисов, а не линейно от числа пользователей — закладывайте запас под набор функций, а не только под нагрузку.

Локация — Лондон. Логика та же, что для любого файлового облака с синхронизацией по WebDAV: каждая операция — отдельный обмен клиент-сервер, и задержка канала прямо влияет на скорость синхронизации папок с большим числом файлов. Для аудитории строго в России, где данные обязаны оставаться в стране по 152-ФЗ, берите российскую локацию. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT, без необходимости в иностранной карте.

Частые вопросы