Для сервера СКУД под «Орион Про» Болид или Sigur сравнивают конкретные версии ПО, ОС и СУБД, интеграции и резервирование. На объекте с 500 сотрудниками и 30 точками прохода важны не только количество дверей, но и пики событий, отчеты и обмен с 1С:ЗУП. Реестровые записи и необходимые документы проверяют для выбранного состава решения, а конфигурацию подтверждают испытанием.
Что делает сервер СКУД и когда выделяют отдельные ресурсы
СКУД объединяет центральную базу, контроллеры точек прохода, рабочие места и интеграции. Сервер обеспечивает управление, мониторинг, отчеты и обновление прав. Решение о проходе может принимать автономный контроллер по локальным правилам. Поэтому отказ серверного ПО, контроллера, сети и питания имеет разные последствия.
Решение о выделенных ресурсах принимают по нагрузке, доступности и требованиям защиты.
- Пиковую нагрузку определяют по одновременным проходам, числу событий на операцию, отчетам и интеграциям. Проверяют задержку записи, построения отчетов и обновления прав. Общего интервала в одну-три секунды на точку для всех объектов нет.
- При отказе сервера могут стать недоступны мониторинг, изменение прав и онлайн-интеграции. Автономные контроллеры продолжают пропуск по локальным правилам при сохранении питания и исправности точки. Сценарии, требующие онлайн-решения, проверяют отдельно.
- СКУД обрабатывает ПДн, поэтому оператор определяет меры защиты по статье 19 закона №152-ФЗ с учетом угроз. Сегментацию сети и выделенный сервер выбирают по модели угроз и требованиям системы. Закон сам по себе не задает единую физическую архитектуру для любой СКУД.
Сервер под СКУД в такой конфигурации становится инфраструктурным элементом, а не просто еще одной программой на файловом сервере.
Требования Болид и Sigur к серверу — конкретика
Болид «Орион Про»: выбор релиза и стека
Для «Орион Про» сначала выбирают релиз. Версия 2.0 поддерживает Astra Linux 1.8 и Windows, а также PostgreSQL и Postgres Pro по документации Болид. Регистрация кроссплатформенного продукта относится к третьему кварталу 2025 года. К октябрю 2026 в каталоге есть 2.0.1. Ее ОС, СУБД и порядок обновления сверяют с руководством. Поддержку прежних выпусков нельзя автоматически переносить на новые.
В филиальной схеме определяют расположение центрального сервера, БД и удаленных АРМ, а также передачу данных по WAN. Удаленное рабочее место не означает отдельную базу в филиале. Проверяют задержки, восстановление связи и то, какие функции сохраняются при недоступности центра.
Sigur: варианты ОС и СУБД
Sigur поддерживает варианты с MariaDB, PostgreSQL и Postgres Pro. В руководстве для серверной части на Linux предусмотрен выбор внешней MariaDB или PostgreSQL. Допустимые версии ОС и СУБД сверяют для выбранного выпуска. Меньшую потребность в CPU или памяти по сравнению с Болид нельзя обещать без теста одинакового профиля.
Для проекта с требованиями к отечественному ПО проверяют реестровые записи и совместимость всех компонентов. Подходящие ОС и СУБД помогают собрать стек, но не доказывают соответствие всей системы требованиям закупки или КИИ.
Параметр | Болид Орион Про | Sigur |
|---|---|---|
Платформа | По релизу: Windows или Astra Linux, СУБД по руководству | Связка ОС и MariaDB/PostgreSQL/Postgres Pro по версии |
Процессор | По пиковым событиям, отчетам и интеграциям | По пиковым событиям, отчетам и интеграциям |
Оперативная память | По активной БД и нагрузочному тесту | По активной БД и нагрузочному тесту |
Хранение | ОС и рабочая БД, резервные копии отдельно | ОС и рабочая БД, фото/видео и копии отдельно |
Исходный профиль объекта | 500 сотрудников, 30 точек, пики и размер записей измеряют | Тот же профиль для сопоставимого теста |
Сравнение проводят на одинаковых событиях, отчетах и интеграциях. Выбор зависит от поддерживаемого выпуска, нужных функций, эксплуатации и восстановления. Linux уже есть у обеих платформ, поэтому противопоставление «Болид — Windows, Sigur — импортозамещение» устарело.
Как рассчитать конфигурацию под свой парк
Методология подбора конфигурации простая и держится на четырех шагах.
- Количество точек задает масштаб, а серверную нагрузку определяют пиковые события, отчеты, синхронизация и интеграции. Разделение БД и приложения выбирают по поддерживаемой архитектуре и испытаниям. Проверяют начало смены, массовое обновление прав и построение отчетов одновременно с записью событий.
- Срок хранения задают по цели обработки, применимым нормам и регламенту оператора. 152-ФЗ не устанавливает общий минимум три года для журналов СКУД. Объем считают как число событий × измеренный размер записи плюс индексы и служебные данные. В условном примере 2–3 млн записей по 200–500 байт дают 0,4–1,5 ГБ сырых данных. Фото, журналы БД и копии добавляют отдельно, а полный размер проверяют на пилоте.
- Резервирование БД и приложения проектируют отдельно. Возможность применения SQL Server AG или репликации PostgreSQL подтверждают для релиза СКУД. Проверяют адрес подключения, лицензии, восстановление сервисов и связь контроллеров. Репликация БД сама по себе не является горячим резервом всей системы.
- Для обмена с 1С:ЗУП, видео и уведомлениями измеряют частоту, объем, пики и требования к задержке. Ресурсы проверяют совместным тестом всех функций. Фиксированную надбавку 20–30% к CPU и сети без сценария измерения не используют.
Отдельно стоит сценарий интеграции СКУД с видеонаблюдением на одном сервере или в связке: конфигурация в этом случае подбирается с учетом обеих систем, и на сайте есть типовые сборки для интеграции СКУД с сервером видеонаблюдения.
Выбор СКУД-платформы под конкретный парк точек прохода в итоге упирается не в абстрактный рейтинг платформ, а в эти четыре параметра, посчитанные для своего объекта.
Отказоустойчивость и резервирование
Как задать и проверить требования к восстановлению СКУД
Для критичного объекта задают допустимую потерю данных и время восстановления централизованных функций. Испытывают отказ основного сервера, переключение приложения и связь с контроллерами. Отдельно проверяют, сохраняется ли локальный проход и какие онлайн-сценарии недоступны. Зеркальная БД не гарантирует переключение всей системы за 5–30 секунд.
Автономность проверяют по модели контроллера: локальные права, емкость журнала, поведение при переполнении и резерв питания. Общего таймера 24–48 часов нет. Определяют функции, которым нужен сервер, и порядок выгрузки накопленных событий после восстановления связи.
У согласованной HA-схемы проверяют приложение, лицензии, переподключение и компоненты согласования. Для Patroni нужны DCS и корректное управление отказами. Сеть рассчитывают по обмену и репликации, а RPO/RTO подтверждают тестом, включая отказ сети и изоляцию узла. Сам порт 10 GbE не гарантирует время восстановления.
Отдельно — питание: серверы СКУД держат на ИБП с корректным автоматическим завершением работы, а для объектов с долгими отключениями сети добавляют генератор.
Типичные ошибки при подборе
Набор ошибок повторяется от проекта к проекту.
- ОС выбрана без проверки релиза «Орион Про»: матрица старого выпуска перенесена на новый без подтверждения.
- Медленная БД задерживает серверную обработку событий и отчеты. Время физического прохода проверяют отдельно с учетом автономности и онлайн-интеграций.
- Сетевой доступ и права не ограничены по модели угроз. Проверяют сегментацию, аутентификацию, доступ операторов и права БД.
- Отсутствие тестового восстановления копии: бэкапы формально делаются, а при отказе выясняется, что файлы битые.
- Резервирование централизованных функций не предусмотрено. Последствия для проходов определяют по контроллерам и зависимостям сценариев.
- Неправильный расчет мощности процессора при интеграции с видеонаблюдением: верификация по фото добавляет нагрузку, которую часто забывают учесть.
- Забытый регламент обновления ПО. Критичные патчи не ставятся, накапливаются уязвимости.
- Отсутствие журналирования действий операторов. При инциденте невозможно восстановить, кто и когда менял права доступа.
Заключение
«Орион Про» и Sigur сравнивают по выбранным версиям, ОС и СУБД, интеграциям, автономности контроллеров и поддерживаемому резервированию. Одинаковый профиль объекта и испытания дают основу конфигурации. Реестровая запись и сертификат относятся к конкретному продукту и не заменяют проверку всей системы.
Если нужен сервер под СКУД с учетом резервирования, требований 152-ФЗ и числа точек прохода, подберем конфигурацию под конкретную платформу, Болид или Sigur, и под масштаб объекта.