VDI и Revit Server в одном дата-центре — почему это важно
Команда переходит на облако: берут VDI у одного провайдера, Revit Server — у другого. Или оставляют Revit Server в офисе и подключаются к нему через VPN с облачного рабочего места. Кажется логичным — оба в сети, интернет быстрый, должно работать.
Не работает. Точнее — работает, но медленно. Модели открываются по 20-40 минут, синхронизация тянется, команда злится. И никто не может объяснить почему: канал широкий, железо мощное, а тормоза есть.
Причина почти всегда одна — расстояние между VDI и Revit Server. Не в километрах, а в миллисекундах.
Как данные двигаются при работе с Revit Server
Чтобы понять почему пинг важнее скорости канала, нужно разобраться как Revit вообще общается с сервером.
При открытии модели и при синхронизации Revit не скачивает файл целиком как браузер скачивает PDF. Он делает сотни последовательных небольших запросов: запросил блок данных → получил ответ → запросил следующий → получил ответ → и так далее.
Ключевое слово — последовательных. Revit не отправляет все запросы сразу, он ждёт ответа на каждый прежде чем отправить следующий. Это архитектурная особенность протокола Revit Server.
Из этого следует важный вывод: скорость работы с Revit Server определяется не шириной канала, а временем отклика — пингом. Гигабитный канал с пингом 80 мс будет работать хуже чем 50-мегабитный канал с пингом 3 мс.
Почему пинг важнее скорости канала — считаем на цифрах
Посчитаем на конкретном примере. При синхронизации средней модели Revit делает порядка 500 последовательных запросов к серверу. Каждый запрос ждёт ответа.
| Пинг | Расчёт (500 запросов) | Итоговое время |
|---|---|---|
| 3 мс | 500 × 3 мс | 1,5 секунды |
| 30 мс | 500 × 30 мс | 15 секунд |
| 80 мс | 500 × 80 мс | 40 секунд |
| 120 мс | 500 × 120 мс | 60 секунд |
При пинге 3 мс синхронизация занимает полторы секунды. При пинге 80 мс — те же 500 запросов растягиваются на 40 секунд. При этом ни ширина канала, ни мощность железа ничего не изменят — запросы всё равно идут последовательно и каждый ждёт своей очереди.
Именно это ощущают пользователи как «тормоза» — не нехватку мощности, а ожидание между операциями.
Что происходит когда VDI и Revit Server в разных местах
Рассмотрим типичный сценарий: VDI арендован в облаке, Revit Server стоит в офисе или у другого провайдера.
Путь каждого запроса выглядит так:
- Пользователь работает на VDI в дата-центре А
- Revit на VDI отправляет запрос к Revit Server
- Запрос уходит из дата-центра А в публичный интернет
- Проходит через несколько промежуточных узлов
- Достигает дата-центра Б или офиса, где стоит Revit Server
- Ответ идёт обратно тем же путём
Каждый такой круговой маршрут занимает 20-80 мс в зависимости от расстояния, маршрута и загруженности сети. При 500 последовательных запросах это минуты ожидания на каждую синхронизацию.
Плюс публичный интернет нестабилен: потери пакетов, джиттер, временные перегрузки узлов. Это добавляет к задержкам непредсказуемые паузы.
Что происходит когда VDI и Revit Server в одном месте
Когда оба компонента — VDI-рабочее место и Revit Server — развёрнуты на одном физическом сервере или в соседних стойках одного дата-центра, путь запроса принципиально другой:
- Revit на VDI отправляет запрос к Revit Server
- Запрос идёт по внутренней сети дата-центра
- Никакого выхода в интернет — только локальная сеть
- Пинг 1-3 мс, стабильный, без потерь
Синхронизация при таком пинге ощущается как работа с локальным файлом — Revit отвечает мгновенно, операции не подвисают.
Именно это мы имеем в виду когда говорим «пинг менее 3 мс». Это не маркетинговая цифра — это физическое расстояние между VDI и Revit Server, измеренное в миллисекундах. Достигается только при размещении на одном железе или в одной серверной стойке.
Реальные цифры по трём сценариям
Для модели размером 250 МБ при работе команды из 5 человек:
| Сценарий | Пинг | Открытие 150 МБ | Синхронизация |
|---|---|---|---|
| VPN до офисного сервера | 60–120 мс | 35–50 мин | 5–10 мин |
| VDI + RS в разных ДЦ | 20–50 мс | 10–20 мин | 2–4 мин |
| VDI + RS в одном ДЦ | 1–3 мс | 3–7 мин | 30–60 сек |
Важно: цифры приведены для типичных условий и зависят от структуры модели, количества рабочих наборов и активности команды. Но соотношение между сценариями остаётся примерно одинаковым.
Почему это непросто повторить самому
Кажется, можно просто взять VDI и Revit Server у одного провайдера — и они окажутся рядом. На практике это не гарантия.
- «Один провайдер» не значит «одна стойка». Крупные облачные провайдеры размещают серверы в разных дата-центрах, на разных площадках. VDI может быть в Москве, Revit Server — в Петербурге. Формально один провайдер, фактически — десятки миллисекунд между ними.
- Виртуализация добавляет слои. Если оба компонента запущены как виртуальные машины на разном физическом железе — пинг между ними выше чем кажется. Нужно явно уточнять: на одном физическом хосте?
- Гиперконвергентная архитектура. Оптимальный сценарий — когда VDI и Revit Server запускаются как виртуальные машины на одном физическом сервере. Тогда трафик между ними вообще не выходит за пределы гипервизора — пинг меньше 1 мс.
Именно так устроена наша инфраструктура: при заказе VDI от двух рабочих мест Revit Server разворачивается на том же физическом железе. Не «в том же дата-центре» — на том же сервере.
Когда это особенно критично
Разница между сценариями ощущается сильнее при:
- Тяжёлых сводных моделях. 300 МБ и выше — количество запросов при открытии и синхронизации растёт пропорционально. При пинге 80 мс открытие такой модели может занять час.
- Большой команде. 5 и более человек синхронизируются одновременно — нагрузка на канал между VDI и сервером умножается на количество участников.
- Частой синхронизации. Если команда синхронизируется каждый час — при высоком пинге это 8 пятиминутных ожиданий в день на человека. Сорок минут простоя ежедневно.
- Работе с Accelerator. Если часть команды работает через Revit Server Accelerator — Accelerator тоже должен быть физически близко к основному серверу, иначе выигрыша не будет.
Итог
Скорость работы с Revit Server зависит не от ширины канала, а от пинга. Пинг зависит от расстояния между VDI и сервером — в метрах и в миллисекундах. Единственный способ получить пинг менее 3 мс — разместить оба компонента на одном физическом железе.
Всё остальное — компромисс.
При аренде от двух рабочих мест VDI — Revit Server на том же железе бесплатно.Напишите нам в Telegram @revitserver или на info@revitserver.ru — подберём конфигурацию под вашу команду.