Nextcloud и ONLYOFFICE: совместная работа с документами и пределы одного VPS

Десять сотрудников утром открывают рабочие файлы. Каждый берёт по три документа: договор, таблицу с расчётами и презентацию для встречи. На бумаге получается десять человек, но редактор видит совсем другую картину: тридцать вкладок, в каждой из которых идёт отдельная живая сессия. Если один и тот же договор открыли двое, это уже две вкладки, а не один «общий документ». Именно здесь и расходятся два числа, которые в разговорах об офисном сервере постоянно путают: число работников и число соединений редактора.

Вопрос, с которым приходят к связке Nextcloud и ONLYOFFICE, звучит просто: хватит ли одного VPS и выбранной редакции для совместной работы? Ответ складывается минимум из трёх частей, и каждая может оказаться самым узким местом: лицензионные условия редакции, ресурсы сервера и сетевая связность компонентов. Разберём их по очереди и в конце посмотрим, как понять, что ограничивает именно вашу команду.

Кто в этой связке что делает

В схеме участвуют три стороны, и полезно развести их роли, потому что большинство странных ошибок начинается с непонимания, кто к кому обращается.

Nextcloud хранит файлы, знает о пользователях, правах доступа и ссылках. Он не умеет сам рисовать таблицу в браузере с совместным курсором. Его задача: выдать файл, сказать редактору, кто его открывает, и принять результат обратно.

Document Server от ONLYOFFICE — это сам редактор. Он держит сессии редактирования, синхронизирует правки участников, преобразует форматы и отдаёт браузеру интерфейс. Хранилищем он при этом не является: файл живёт в Nextcloud.

Браузер сотрудника — третий участник, и о нём забывают чаще всего. Страницу с редактором он получает из Nextcloud, но сам редактор подгружает уже напрямую с Document Server. Поэтому браузер должен видеть оба адреса.

Связывает Nextcloud и Document Server коннектор. По описанию официального коннектора ONLYOFFICE для Nextcloud, он позволяет совместно редактировать документы, а Document Server и Nextcloud могут стоять как на одном сервере, так и на разных (README коннектора). Это важная оговорка для всей статьи: «на одном VPS» — допустимый вариант, но не обязательный и не всегда лучший.

Три стрелки и одна обратная

Удобнее всего представлять связку как набор направлений, по которым должен идти трафик. По документации коннектора, Document Server должен быть достижим из Nextcloud и из браузеров клиентов, а сам Document Server должен уметь отправлять POST-запросы в Nextcloud (README коннектора). Получается так:

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

Почему внешний и внутренний адрес — это не одно и то же

Когда оба сервиса стоят на одном VPS, возникает соблазн везде прописать публичные доменные имена. Иногда это работает, иногда нет: запрос с сервера на свой же публичный адрес может упереться в особенности маршрутизации, в сертификат, в правила файрвола или в то, что имя резолвится не туда. Для таких случаев в настройках коннектора предусмотрены раздельные адреса: тот, по которому редактор доступен браузеру, и тот, по которому его видит сам Nextcloud, а также адрес Nextcloud, по которому в него будет стучаться Document Server. Если на одной машине между контейнерами или процессами есть короткий внутренний путь, имеет смысл использовать его для серверных обращений, а публичные имена оставить для браузера.

Отдельно стоит JWT. Если проверка подписи включена, секрет должен совпадать и в настройках коннектора, и в Document Server, а сама проверка должна быть включена с обеих сторон (README коннектора). Типичный симптом несогласованности — редактор отказывается открывать документ или выдаёт ошибку загрузки, хотя сеть в порядке. Это полезно помнить, чтобы не искать проблему в файрволе там, где виноват расхождение в одном символе секрета.

Сколько соединений на самом деле нужно команде

Теперь вернёмся к десяти сотрудникам. В документации ONLYOFFICE по развёртыванию соединения определены как вкладки браузера с документами, открытыми на редактирование. Пример оттуда же: один документ, открытый двумя пользователями в двух вкладках, считается двумя соединениями (документация по развёртыванию). Следовательно, считать нужно не людей и не файлы, а пары «человек — вкладка с редактированием».

Вот условный пример для нашей команды из десяти человек. Числа вымышленные, они нужны только для арифметики.

Из таблицы видно главное: пять человек, редактирующих один общий документ, дают пять соединений, а не одно. Совместная работа не экономит соединения, она их умножает. Если каждый из десяти параллельно держит ещё и по две личные вкладки, счёт уходит за двадцать очень быстро, при этом никакого «наплыва пользователей» не было.

Есть и обратная сторона. Документ, открытый только на просмотр, по определению из источника не равен вкладке, открытой на редактирование, поэтому читатели без правок в этот счёт не попадают. Но в Nextcloud права и режим открытия настраиваются отдельно, и привычки команды важнее теории: если сотрудники по привычке открывают всё в режиме правки, считать придётся именно так.

Двадцать соединений: что это за цифра и чем она не является

В FAQ ONLYOFFICE для бесплатной Community-редакции указано ограничение в 20 одновременных соединений, а Enterprise идёт по коммерческой лицензии с другими условиями масштабирования (FAQ по Docs Enterprise). Вокруг этой цифры возникают два одинаково неверных толкования.

Первое: «двадцать соединений — значит, двадцать сотрудников». Мы только что увидели, что это не так. Двадцать вкладок — это, скажем, семь человек с тремя документами каждый. И наоборот, команда в сорок человек может укладываться в двадцать соединений, если редактируют одновременно не все и не постоянно.

Второе, более тонкое: «двадцать соединений — значит, сервер выдержит ровно двадцать». Это лицензионный порог редакции, а не измеренная ёмкость железа. Он говорит, сколько сессий вам разрешено, но ничего не говорит о том, сколько ваш конкретный VPS способен обслужить на практике. Тяжёлая таблица с формулами в двадцати вкладках и текстовые заметки в двадцати вкладках нагружают машину несопоставимо. Один порог — юридически-продуктовый, другой — физический, и они могут не совпадать ни в какую сторону: сервер может упереться в память раньше, чем в лимит, а может спокойно тянуть больше, чем лицензия разрешает.

Столь же осторожно нужно читать описание Enterprise. Формулировка вроде «любое число» в обзоре не означает бесконечной производительности или отсутствия договорных ограничений: она описывает модель лицензирования, а не железо. Конкретные условия коммерческого предложения нужно уточнять у поставщика, а лицензионную совместимость своей схемы интеграции нельзя вывести из краткого FAQ. Это вопрос к вендору, а не к вашему администратору.

Чем редакции отличаются кроме числа вкладок

Число соединений — самая заметная разница, но не единственная. FAQ отмечает, что редакции отличаются поддержкой и обновлениями, а также наличием мобильных веб-редакторов (FAQ по Docs Enterprise). Для команды это превращается в вопросы совсем не про цифры:

• Нужны ли сотрудникам правки с телефона прямо в браузере, а не через отдельное приложение?
• Кто будет отвечать, если после обновления Nextcloud коннектор перестал открывать документы, и есть ли у вас договорная поддержка?
• Готовы ли вы самостоятельно следить за обновлениями редактора?

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

Что на самом деле нагружает один VPS

Когда Nextcloud и Document Server делят машину, они делят процессор, память и диск. У Nextcloud свои потребители: веб-сервер, PHP, база данных, фоновые задания и работа с файлами. У Document Server свои: преобразование форматов, поддержание сессий, обработка больших таблиц и презентаций. Пик у них может совпасть: утром все заходят в Nextcloud, синхронизируют клиентов и сразу же открывают документы.

Универсальной формулы «столько-то гигабайт на пользователя» тут нет, и придумывать её было бы нечестно: потребление зависит от содержимого документов. Большая таблица с тяжёлыми формулами и текст на две страницы — это разные миры. Поэтому разумнее говорить о качественных различиях:

• Память страдает первой, если открыто много тяжёлых документов одновременно. Нехватка памяти проявляется не плавным замедлением, а внезапными обрывами и перезапусками процессов.
• Процессор нужен при открытии, конвертации и пересчёте. Пики короткие, но если они совпадают у многих, интерфейс начинает залипать.
• Диск важен для базы Nextcloud, временных файлов редактора и сохранения версий. Быстрый NVMe здесь снимает часть проблем, но не отменяет нехватку памяти.

У VPS MAATRIX линейка тарифов начинается с Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) и идёт через Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ) и Maat (8 vCPU, 16 ГБ, 240 ГБ) до Djed (16 vCPU, 32 ГБ, 320 ГБ). Эти цифры описывают ресурсы машины, а не обещание, сколько человек она потянет: ёмкость для вашей смеси документов определяется только замером. Зато они дают понятную лестницу: если измерение показало упор в память или процессор, можно оценить, на какую ступень стоит подниматься, и сравнить это с вариантом вынести редактор на отдельную машину. На публичной странице аренды VPS есть root-доступ, что важно для такой связки: понадобится настраивать сеть, сервисы и, возможно, контейнеры.

Измеряем свою смесь, а не усреднённого пользователя

Прежде чем решать, объединять ли компоненты на одной машине, стоит провести небольшой эксперимент на реальных материалах. Идея в том, чтобы воспроизвести не абстрактную нагрузку, а свой рабочий день.

1. Соберите типичный набор файлов. Возьмите самые тяжёлые документы, с которыми реально работает команда: крупные таблицы, презентации с картинками, длинные тексты с правками. Один лёгкий документ ничего не покажет.
2. Посчитайте вкладки. Выясните у людей, сколько файлов они держат открытыми на редактирование одновременно в обычный день и в пиковый. Это ваш настоящий счёт соединений.
3. Воспроизведите пик. Попросите нескольких коллег одновременно открыть свои наборы и поработать в них десять-пятнадцать минут. Включите в сценарий момент общего редактирования одного файла несколькими людьми.
4. Наблюдайте за машиной. Пока идёт сессия, смотрите на использование памяти, процессора и обращения к диску. Отдельно отметьте, не появилось ли подкачки в своп и не перезапускались ли процессы.
5. Проверьте сохранение. Внесите правки, закройте вкладки, откройте файл заново. Это проверит ту самую обратную стрелку, которую не видно, пока не дойдёт до записи.

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

Когда редактор стоит вынести

Document Server на одном сервере с Nextcloud — вполне рабочая схема для небольшой команды. Но есть признаки, что пора разделять роли:

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

Важно трезво понимать, что даёт разделение. Вторая машина разгружает ресурсы, но не отменяет четыре направления соединений: теперь они пересекают сеть между серверами, и внутренние и внешние адреса придётся настраивать особенно аккуратно. Две отдельные арендованные машины сами по себе не дают отказоустойчивости приложению: если упал Document Server, документы по-прежнему не откроются.

Если вы только планируете поднимать Nextcloud, базовую установку описывает материал о том, как установить и настроить Nextcloud на VPS. В публичном каталоге MAATRIX упоминается Nextcloud с установкой, но точное наличие образа и операционной системы нужно смотреть в форме заказа.

Перед сменой схемы: что сохранить

Любая перестройка, будь то перенос редактора или смена редакции, затрагивает данные Nextcloud, поэтому сначала нужна копия. По документации Nextcloud, в резервную копию входят каталоги config, custom apps при их наличии, data и theme, а также база данных. Во время работ рекомендуется включать режим обслуживания, который блокирует сессии и новые входы, чтобы данные не разошлись между собой. Копии советуют хранить за пределами окружения Nextcloud (руководство Nextcloud по резервному копированию). Для нашей темы это означает простое: перед любым экспериментом с редактором снимите копию и держите её не на той же машине.

Что ограничит вашу команду раньше всего

Сведём всё к трём вопросам, на которые можно ответить цифрами и наблюдениями, а не ощущениями.

Упирается ли команда в редакцию? Посчитайте реальные редактирующие вкладки в пиковый час. Если их регулярно больше двадцати или нужны возможности, которых нет в Community, разговор идёт о лицензии и поддержке, а мощность сервера тут вторична. Даже тогда условия Enterprise придётся уточнять у вендора, не принимая «любое число» за гарантию производительности.

Упирается ли команда в ресурсы? Если лимит редакции ещё далеко, а память и процессор исчерпываются на вашей смеси тяжёлых документов, лечится это ступенью тарифа выше или отдельным сервером для редактора. Решение принимается по замеру, а не по среднему пользователю.

Упирается ли команда в связность? Если документ открывается, но не сохраняется, или редактор грузится не у всех, сначала проверьте четыре направления, внешние и внутренние адреса и согласованность JWT. Здесь ни мощная машина, ни платная лицензия не помогут.

Десять сотрудников с тремя документами каждый — это тридцать вкладок, и уже по ним видно, насколько разные вещи прячутся за словом «пользователи». Если честно посчитать вкладки, сделать пробный пик и проверить обратный путь, ответ на вопрос о достаточности одного VPS получится конкретным: для вашей команды, вашей редакции и вашего набора документов.