Журнал "Системы Безопасности" № 5‘2024

С И С Т Е М Ы К О Н Т Р О Л Я И У П Р А В Л Е Н И Я Д О С Т У П О М 88 СПЕЦПРОЕКТ ПРОгРаММНыЕ КОМПлЕКСы Для СКУД И ИСБ систем до огромных географически распреде- ленных холдингов. Когда нагрузка увеличива- ется, выделяются ресурсы и запускаются серви- сы, чтобы поддерживать высокую производи- тельность и снижать время отклика системы. Важен выбор правильной базы данных, которая позволит масштабироваться. Отличный при- мер – PostgreSQL, которую мы используем для решения задач наших клиентов (масштабиро- вание на объектах до 1 млн человек). Из допол- нительных плюсов – у этого решения есть офи- циальная в России версия, прошедшая множе- ство сертификаций. Эта БД может работать с большими объемами данных и поддерживать высокую нагрузку, что делает ее подходящим выбором для систем управления СКУД и ИСБ. Алексей Лагойко, КомплИТех Существует проблема, которую стоит обсуждать открыто. Большинство российских решений для СКУД и ИСБ не приспособлены для построения многофилиальных систем. Почему крупные корпоративные заказчики в России так ценили зарубежные СКУД и ИСБ? Давайте ответим на этот вопрос откровенно, отбросив экономический аспект и сосредото- чившись на технической составляющей. Такие компании, как LENEL, APOLLO, NEDAP, Bosch и Honeywell, предлагали масштабируемые реше- ния, которые позволяли создавать многоуровне- вые и многоранговые СКУД и ИСБ (с объектовы- ми и региональными уровнями и централизаци- ей), а также легко расширять их по горизонтали и вертикали. Зарубежные системы выдерживали нагрузку при объединении сотен или тысяч объ- ектов в единую систему со сквозным управлени- ем на всех уровнях, чего многие отечественные производители не могли предложить. Пример из практики: наблюдал внедрение оте- чественной СКУД на территориально распреде- ленном объекте. Возникла проблема с часовы- ми поясами. Можно ли говорить о масштаби- руемости, если ПО не поддерживает коррект- ную работу с часовыми поясами и не сводит события из разных регионов в единую базу? В зарубежных системах таких трудностей не существовало. Кроме того, российские СКУД традиционно работали по принципу "сервер – объект": карты доступа, выданные сотрудникам на одном объ- екте, не функционируют на другом, требуется выпуск дополнительной карты. Наиболее прогрессивные отечественные про- изводители уже осознали описанную проблему и занимаются ее решением. Аркадий Созданов, МПК "СОАР" Наиболее приемлемая топология при масшта- бировании ПО от малой системы до системы крупного географически распределенного хол- динга является создание собственной вычисли- тельной сети с виртуальной "машиной" СКУД на центральном сервере головного офиса. При необходимости функции управления СКУД делегируются в разные города на собственные компьютеры контроля СКУД. Вячеслав Петин, АРМО-Системы На начальном этапе осуществляется выбор подходящей для данного объекта архитекту- ры. Принимается решение, будет это система локальная или территориально распределен- ная. При разработке ПО для упрощения даль- нейшего масштабирования отдельных ком- понентов системы используется микросер- висная архитектура. Далее по необходимости система наращивается за счет добавления ресурсов в сервер и/или добавления новых серверов. Андрей Артюшкин, СБ Инжиниринг В своих проектах мы всегда используем реше- ния, которые позволяют без ущерба масшта- бировать систему практически до бесконеч- ности. Минусом таких решений является более высокая цена "входного билета", но это компенсируется снижением затрат на экс- плуатацию и возможностью различных апгрейдов и интеграций в будущем. Что каса- ется распределенных объектов, то достаточно давно существуют программные комплексы, позволяющие решить задачи с объединением серверов на разных удаленных объектах. Для примера, существует система, которая мас- штабируется на протяжении более 25 лет и уже имеет в своем составе более 300 уда- ленных объектов. Алексей Гинце, ААМ Системз 1. Малая изолированная система. В этом случае все модули комплекса (сервер БД, ядро, функ- циональные модули, драйверы оборудования и управляющая консоль) устанавливаются на одном компьютере. К этому же компьютеру подключается и оборудование всех подсистем безопасности. Компьютер должен обладать достаточной вычислительной мощностью и объемом памяти для функционирования всех этих модулей, а также дисковым пространством для хранения базы данных системы. Данная конфигурация хорошо подходит для построе- ния СКУД небольшого масштаба. 2. Централизованная многопользовательская система. В данном случае все служебные моду- ли комплекса (ядро, драйверы оборудования и логики) функционируют на одном компью- тере – центральном сервере, а запуск управ- ляющей консоли возможен не только на дан- ном компьютере, но и на других машинах сети. В такой системе центральный сервер должен обладать вычислительной мощностью, объе- мом памяти и дисковым пространством еще большими, чем в случае применения одно- пользовательской системы. Однако в данной схеме появляется возможность задействовать не очень мощные компьютеры в качестве кли- ентских рабочих станций. Достоинства очевид- ны: простота установки, обслуживания и конт- роля линий связи, так как все оборудование подключено к одному компьютеру. В такой системе легко контролировать состояние функ- циональных модулей и драйверов оборудова- ния, так как все они функционируют на одной машине. Недостатки в значительной степени повторяют предыдущий вариант. Для распре- деленной системы главным отрицательным фактором будет тот же – необходимость под- ключения всего управляемого оборудования к одному компьютеру (серверу), особенно в случае большой территориальной распреде- ленности оборудования. Конфигурация хоро- шо подходит для построения СКУД среднего размера. 3. Крупная распределенная система. Сервер управления базой данных системы и ядро работают на центральном сервере, а драйверы оборудования и логики распределены по всей сети. Запуск управляющих консолей возможен на любом компьютере сети, что делает управ- ление более гибким. Необходимость распре- деления по сети драйверов оборудования и логики связана в основном с тем, что объект распределенный и часть оборудования может находиться достаточно далеко от центрального сервера. Поскольку часть модулей вынесена с централь- ного сервера системы на другие компьютеры, нагрузка на центральный сервер снижается. Применение такой архитектуры выгодно при наличии большой территории с распределен- ным по ней управляющим оборудованием. В этом случае нет необходимости прокладывать коммуникации из всех точек к центральному серверу. Достаточно подключить аппаратуру к ближайшему компьютеру сети и запустить на этом компьютере обслуживающий драйвер. При этом требования к мощности данного ком- пьютера остаются относительно скромными. Надо отметить, что в случае распределенного запуска программных модулей встает задача контроля их состояния. Для облегчения работы в ПК должны быть встроены специальные сред- ства, позволяющие администратору со своего рабочего места контролировать работу модулей на других компьютерах, запускать или останав- ливать их. Данный вариант развертывания под- ходит для построения СКУД и ИСБ крупных объектов, имеющих территории с большим количеством отдельно стоящих зданий и соору- жений. 4. Многофилиальная система. Может объеди- нять в сеть региональные офисы крупной ком- пании, а также множество небольших отделе- ний, подключенных, в свою очередь, к регио- нальному центру. Такая система должна обес- печивать ряд важных функций – автоматиче- скую синхронизацию базы данных сотрудников между объектами, мониторинг из центрального офиса всех удаленных филиалов, построение отчетов учета рабочего времени сотрудников октябрь – ноябрь 2024 www.secuteck.ru Д ля объединения различных по назначению систем в интегрирован- ную систему безопасности используется ПО верхнего уровня. Для под- ключения СКУД разных вендоров в единую систему также использу- ется верхнеуровневый софт. В результате мы получаем мультифунк- циональное, мультивендорное решение, что является одним из направ- лений развития рынка СКУД в России.