Nextcloud для двух офисов: как выбрать страну сервера по замерам из обеих сетей

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

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

Сначала договориться, что такое «работает быстро»

Слова «тормозит» и «летает» у разных людей означают разное. Бухгалтер жалуется, когда папка с тремя сотнями небольших сканов открывается с паузой. Дизайнер недоволен, когда гигабайтный архив выгружается дольше обеденного перерыва. Руководитель замечает только, что ссылка клиенту открылась не сразу. Это три разные нагрузки, и они по-разному реагируют на расстояние и пропускную способность.

Выпишите типовые операции каждого офиса и разделите их на три класса:

• Много мелких файлов. Здесь важна задержка: каждое обращение — отдельный круг туда и обратно, и сто файлов умножают даже небольшую паузу.
• Крупная загрузка на сервер. Здесь важна исходящая скорость офиса и то, как сервер принимает данные и где держит их временно.
• Скачивание. Здесь важна входящая скорость офиса и исходящая скорость сервера. Это две разные величины, и их легко перепутать.

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

Две стороны одного канала

Частая ошибка — говорить «у офиса канал 300 мегабит» и считать вопрос закрытым. У канала есть направления. Когда сотрудник качает файл с сервера, ограничивают входящий канал офиса и исходящий канал сервера; побеждает меньший из них, а ещё вмешивается маршрут между ними. Когда сотрудник загружает файл, всё зеркально: исходящая скорость офиса, входящая скорость сервера. У многих офисных тарифов исходящая скорость заметно ниже входящей, и именно она определяет, как быстро уезжают большие архивы.

Отсюда практическое следствие: две площадки с одинаковой «скоростью порта» могут вести себя по-разному для одного и того же офиса. Решает не заявленное число, а то, что реально проходит по пути между конкретной сетью и конкретным сервером. Ping показывает только время отклика на крошечный пакет. Он ничего не говорит о том, как маршрут держит устойчивый поток гигабайта. Сервер с хорошим ping может отдавать файл медленнее, чем сервер подальше, если на пути есть узкое место или нестабильный стык между провайдерами. Поэтому ping полезен как один столбец в таблице, но не как вердикт.

Матрица замеров: пустая, чтобы заполнить самим

Чтобы не спорить, составьте таблицу и заполняйте её одинаково для каждого офиса и каждой кандидатной площадки. Ниже заготовка. В ней намеренно нет чисел: любые значения, которые мы бы вписали, были бы выдумкой, а у вашей сети они будут своими.

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

Несколько правил, которые делают таблицу честной:

• Время суток — рабочее. Замер в семь утра, когда офис пуст, описывает чужую жизнь. Нужны часы, когда люди реально пользуются сетью: утро, середина дня, конец дня.
• Одинаковые файлы. Одни и те же наборы на всех площадках и из всех офисов, иначе сравнение теряет смысл.
• Каждую операцию повторите хотя бы несколько раз и запишите разброс, а не лучший результат. Если один прогон занял вдвое больше другого, это важная информация о стабильности, а не шум.
• Условия — отдельный столбец. Wi-Fi или кабель, шли ли параллельно видеозвонки, обновлялись ли чьи-то компьютеры. Без этого результат нельзя интерпретировать.

Не усреднять боль

Вот место, где решение чаще всего портится. Допустим, из офиса А крупный файл уходит быстро, а из офиса Б — мучительно долго. Сложите, поделите на два — и получится «нормально». Но у людей в офисе Б нормально не будет: они каждый день будут ждать, и им безразлично, что коллеги в другом городе довольны. Среднее скрывает именно ту сторону, ради которой стоит разбирать вопрос.

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

Прикинуть время загрузки с запасом

Чтобы понять, укладывается ли операция в порог, полезна простая оценка. Размер данных делите на полезную скорость, а не на скорость из рекламы тарифа. Полезная скорость — та, которую вы реально увидели в замере, с поправкой на то, что часть пропускной способности съедают заголовки, повторные передачи и параллельный трафик других людей.

Условный пример. Пакет макетов весит 6 ГБ. Если в замере из офиса Б устойчиво получилось около 20 мегабит в секунду на отправку, это примерно 2,5 мегабайта в секунду, и 6 ГБ потребуют порядка сорока минут. Если скорость провалится вдвое в разгар дня, будет почти полтора часа. Заложите запас: считайте не по лучшему результату, а по худшему из повторов. Это именно оценка с запасом, а не обещание; реальная картина зависит от сети в конкретный день.

Эта арифметика заодно показывает, что иногда проблема не в сервере. Если исходящий канал офиса — 20 мегабит, то никакая страна не превратит выгрузку 6 ГБ в пятиминутную операцию. Тогда честный вывод звучит так: упираемся в канал офиса, и выбор площадки на это почти не влияет. Тратить силы на сравнение стран в такой ситуации бессмысленно — полезнее поговорить с провайдером офиса или пересмотреть сам процесс.

Когда работают все сразу

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

Документация Nextcloud в разделе о настройке производительности советует начинать с выяснения, какой процесс или диск создаёт нагрузку, и обращать внимание на оперативную память и swap (Nextcloud: Server tuning). Это хороший порядок действий и для наших замеров: если параллельная загрузка замедлилась, сначала смотрите, что делает сервер в этот момент, и только потом винит расстояние. Страница при этом не обещает, сколько пользователей выдержит конкретный сервер: настройки подбираются под конкретную установку, поэтому «ёмкость» нужно мерить, а не вычитывать из таблицы.

Заодно в документации отмечено, что для высокой конкуренции рекомендованы MariaDB/MySQL/PostgreSQL вместо SQLite, а подробное DEBUG-логирование может ухудшать производительность. Для тестов это важно по двум причинам. Во-первых, не сравнивайте площадки, настроенные по-разному: если на одной включён отладочный режим, а на другой нет, вы измерите режим, а не страну. Во-вторых, тестовая установка должна быть в той же конфигурации, что и будущая рабочая, иначе результаты не перенесутся.

Временное место: невидимая часть загрузки

Крупные файлы редко ложатся на диск сразу и целиком там, где им положено лежать. Согласно документации по загрузке больших файлов, ограничения зависят от способа передачи, веб-сервера, PHP и временного хранилища; sync-клиент передаёт файлы частями, и лимиты вроде upload_max_filesize и post_max_size могут не применяться к WebDAV PUT и chunked-загрузкам так же, как к обычной веб-форме (Nextcloud: Uploading big files). Практический смысл такой: тест через браузер и тест через десктопный клиент могут дать разные результаты, и нужно проверять тот способ, которым люди действительно работают.

Там же сказано, что временное место нужно учитывать для параллельных загрузок, а не только для одного максимального файла. Для двух офисов это ключевое. Если в одиннадцать утра из обоих офисов одновременно уходят по несколько больших пакетов, временное пространство нужно под сумму, а не под самый крупный файл. Грубая прикидка: число одновременных крупных загрузок умножьте на размер типичного крупного файла и добавьте запас. Если у вас пять человек одновременно отправляют по 6 ГБ, это порядка 30 ГБ только временных данных, и это поверх того, что уже лежит в хранилище. Диск, который «вроде бы большой», может оказаться тесным именно в час пик.

Это же связывает выбор площадки с выбором ресурсов VPS. Размер NVMe-диска нужно считать как сумму трёх вещей: постоянные данные, рост на ближайшее время и временный запас под параллельные загрузки. Памяти и ядер должно хватать на веб-сервер, PHP и базу под вашей реальной одновременной нагрузкой. Какой именно из тарифов линейки Ba, Uab, Heka, Maat или Djed подойдёт, покажет параллельный замер, а не число в названии: заявленные ресурсы не равны обещанию ёмкости.

Куда поставить пробные серверы

Сравнение стран имеет смысл, только если можно быстро поднять кандидатов и одинаково их проверить. В публичном предложении MAATRIX перечислены UK, US, RU и FR; предлагаются VPS на NVMe с AMD EPYC и root-доступом, оплата картой РФ и через СБП, создание VPS автоматически через пару минут после оплаты. В каталоге указаны также Nextcloud с установкой, но точное наличие образа и версию ОС стоит проверить в форме заказа: доступность может отличаться. Подробности — на странице аренды VPS MAATRIX.

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

Что делать с внешними ссылками

В Nextcloud файлами делятся не только внутри компании. Документация по шарингу описывает публичные ссылки и общий доступ для пользователей и групп; набор опций зависит от настроек администратора (Nextcloud: File sharing). Для двух офисов это влияет на выбор площадки через клиента: человек, которому вы отправили ссылку на макет, качает файл со своей стороны, и его путь до сервера — ещё одна строка в матрице. Если основная часть внешних получателей находится в одной стране, добавьте в таблицу замер хотя бы из одной такой сети.

Для обратной ситуации — когда клиенты присылают материалы — есть file drop: он разрешает загружать файлы в папку, не показывая уже лежащее там содержимое. Это удобно для приёма документов, и этот сценарий тоже стоит проверить: загрузка идёт из чужой сети, которую вы не контролируете, поэтому запас по времени тут особенно важен.

Публичную ссылку можно защитить паролем и задать срок; по истечении срока share отключается. Опция hide download лишь скрывает элементы интерфейса и усложняет скачивание, но не является полноценной защитой, так что полагаться на неё как на гарантию не стоит. И ещё одна деталь, важная при двух офисах: раздел «Others with access» показывает доступ, полученный через родительскую общую папку, поэтому права нельзя оценивать по одному объекту. Когда структура папок у двух офисов пересекается, проверяйте права по цепочке родителей, иначе в общем сервере окажется доступ, которого никто не планировал.

Общий сервер или ожидания от «локального»

Когда замеры собраны, остаётся самый неприятный вопрос: что мы получаем и чем платим. Общий сервер даёт единое место для файлов, один набор прав и понятную точку ответственности. Взамен один из офисов почти наверняка будет ближе или лучше связан с сервером, чем другой. Нужно заранее решить, насколько вторая сторона готова мириться с разницей, и записать это как порог, а не оставлять на ощущения.

Полезно проговорить с каждым офисом три вещи.

• Что сравнивается. Люди привыкли к файловому серверу в своей локальной сети, где копирование идёт со скоростью гигабита. Облачный сервер по определению так не умеет; честнее сравнивать не с локальной сетью, а с тем, что люди делают сейчас для обмена между офисами: почтой, мессенджерами, флешками.
• Какие операции критичны. Если у одного офиса критична выгрузка тяжёлых файлов, а у другого — быстрое открытие папок, площадка может быть выбрана под первую, а вторая будет решаться настройкой и кэшированием, как предусматривает документация по тюнингу, при условии, что нужные компоненты установлены.
• Что делать, если порог не выдерживается. Варианты — другая площадка, пересмотр процесса (например, выгружать тяжёлое ночью), улучшение канала офиса. Решение лучше принимать заранее, пока оно не стало спором.

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

Проверка, которая закрывает вопрос

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

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