партнерский раздел
ФорумЭксплуатацияКонфигурация АРМ Орион Про (Единая операторная)

Эксплуатация » Конфигурация АРМ Орион Про (Единая операторная)

Здравствуйте уважаемые коллеги, 
Помомогите пожалуйста, может кто встречал в проактике. Встал вопрос по делу Конфигурация АРМ Орион ПРО пожарной сигнализации у Единого операторного. То есть стоит задача объединить 30 Автономно функционирующий АРМ Орион ПРО в одну. И так, мы запустили 30 АРМ Орион ПРО пожарной сигнализации соответственно на 30 отдельно стоящие объекты. Объекты расположены на расстоянии друг от друга 3-4 км. и сводится в операторную с помощью ВОЛС через преобразователь С2000-Ethernet.
В практике мы не встречали подобные ситуации, вот и возникли некоторые вопросы и решили подробно разузнать. И у Болида нет конкретных информации, рекомендации, вебинары насчет этого.
И так вопросы:
1) Какие компоненты АРМ Орион ПРО необходимо установить на Компьютер Единого оператора,
2) Какие лицензии продукта необходимо,
3) И не будет ли конфликтовать АРМ Орион Про операторного с АРМ Орион Про на объекте

Почему такое решение, Заказчик желает управлять системой ПС удаленно с операторного так же и местно через АРМ.
Уважаемые коллеги если возможно распешите пожалуйста пошагово.  

10 дней 14 часов назад

avatar
Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

6 ответов

Само ПО "ОрионПро" предусматривает объединение распределённых подсистем в единый комплекс (смотрите буклеты).
Объединение возможно несколькими путями:
1. если на каждом из 30-ти объектов установлен ПКУ С2000М, то объединить их на аппаратном уровне, а АРМ будет только один. При этом управление будет как локальное (ПКУ, БКИ и т.д.), так и дистанционное через АРМ.
2. если у Вас 30 именно АРМ ОриоПро, то объединить на уровне ПО. Т.е. на объектах ядро опроса+монитор (другие модули по желанию), а у единого оператора сервер+монитор+АБД.
3. комбинированный вариант - одно ядро опроса+сервер+АБД и мониторы на каждом из объектов, при этом пульты объединяются аппаратно.

10 дней 12 часов назад

avatar
Константин спасибо за оперативный ответ. По требованию Заказчика вариант 1 отпадает, дело в том что мониторинг и управление должно быть как дистанционно так и локально через АРМ. 
Вариант 3, ну здесь если на объектах только мониторы, то отпадает вариант управление, это и есть не хорошо.
А вот вариант 2 кажется самый раз, но так же управление системой под вопросом.

Абдусадыков Ерлан 10 дней 11 часов назад

так монитор это и есть возможность управления, а не только мониторинга ;)

сейчас у вас на каждом объекте локально получается: центральный сервер ориона - для базы, ядро опроса - для опроса приборов, АБД - для редактирования базы, монитор ОЗ - для мониторинга и управления.
При объединении под Единым диспетчером по второму варианту. На сервере будет: ЦСО - для одной общей базы (или слияние всех существующих, или заново создавать), АБД - для редактирования базы, монитор ОЗ - для мониторинга и управления. На локальных: ядро опроса - для опроса приборов, монитор ОЗ - для мониторинга и управления, возможно АБД - если требуется редактировать базу и локально тоже.
При третьем варианте, ядро опроса перемещается на сервер и меняется исполнение ядра, т.к. уже ему надо будет опрашивать приборы на всех объектах.
Главная засада в том, что делать с лицензиями, объединит ли Болид их в один ключ или же что-то придётся докупать.

Волков Андрей 10 дней 10 часов назад

Спасибо Андрей, всё предельно хорошо объяснили. Насчет лицензии нам подсказали представители Болида что надо докупить ключ на 30 монитор, а остальное можное и по одному.

Абдусадыков Ерлан 10 дней 8 часов назад

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

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

Волков Андрей 10 дней 2 часа назад

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Основной проблемой будет объединить 30 отдельных лицензий в одну, ну и все 30 БД в одну базу.

10 дней 9 часов назад

avatar
Алексей вы имеете введу лицензии на 30 монитор? Как я уже говорил нам подсказали что надо купить ключ на 30 монитор. Но насколько это верно наверно надо это выяснять официально у самого Болида.
Насчет 30 БД, будем пробовать слияние всех БД но как я и понял в этом тоже есть свои нюансы, ну как говорится будем посмотреть. )
Будут проблемы, ну придется тогда всё еще раз прописывать )

Абдусадыков Ерлан 10 дней 7 часов назад

У Вас сейчас 30 систем, значит 30 ключей "сервер" + 30 ключей "ОЗ". Вам нужно будет объединить лицензии, чтобы осталось 1 "сервер" и 30 "ОЗ".

Кечаев Алексей Борисович 10 дней 1 час назад

Алексей, все верно у нас сейчас 30 ключей "сервер" + 30 ключей "ОЗ". Алексей вы имеете введу использовать 1 ключ "сервер" из 30-ти на операторную, ну останется 29 лишние. А на "ОЗ" оставить 30 на своих местах. 

Абдусадыков Ерлан 9 дней 22 часа назад

имеете введу использовать 1 ключ "сервер" из 30-ти на операторную, ну останется 29 лишние

имеется ввиду лицензии 30 серверов перенести в одну

Коркунов Александр Сергеевич 9 дней 21 час назад

Да, в данном случае 30 ключей будут не нужны. Если будут вопросы, пишите. Мне уже приходилось заниматься объединением лицензий.

Кечаев Алексей Борисович 9 дней 21 час назад

Алексей спасибо за предложение. А как можно с вами свзаться для более оперативности например e-mail или по телефону.

Абдусадыков Ерлан 9 дней 20 часов назад

Отправил ЛС

Кечаев Алексей Борисович 9 дней 19 часов назад

Мне уже приходилось заниматься объединением лицензий

и каков процесс? болид без проблем это делает? цена вопроса? получается же, что те же 30 серверов на одном ключе не нужны - работает то только один, но цена сервера больше цены монитора и просто так выкидывать лишние сервера никто не захочет.

Волков Андрей 9 дней 19 часов назад

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Для удалёного управления можно использовать. Программу TeamViewer. Очень удобная программа!

10 дней 7 часов назад

avatar
Александр это шутка??? Видимо вы не работали Заказчиками! и системой Охранно- Пожарной сигнализации. Такие ПО лучше советовать системным администраторам.

Абдусадыков Ерлан 10 дней 5 часов назад

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Небольшое дополнение по созданию большой системы - слияние нескольких баз.
В такой конфигурации встает вопрос отказоустойчивости. У ОрионПро есть программная реализация "Резервного сервера", когда при отказе основного происходит переключение на резервный. Решение на основе резервирования MS SQL сервера и сервера приложений - Центральный сервер Орион (ЦСО). Теоретически - должно работать, на практике я бы его не советовал, по крайней мере без наличия реально продвинутого sql-администратора.
В принципе, если модуль "Оперативная задача" на локальном объекте запущена на одном компьютере, то есть на одном компьютере запущено и "Ядро опроса" и "Монитор ОЗ", тогда в принципе это должно работать и в случае пропаданания связи между Оперативной задачей и ЦСО, локальный "Монитор ОЗ" будет показывать и управлять приборами, которые подключены к локальному "Ядру опроса". На практике чаще всего в момент нарушения связи между Оперативной задачей и ЦСО происходит отказ (ошибка) Оболочки (shell.exe), без которой локальная машина работать не будет. Проблема именно в Оболочке, потому, что Монитор и Ядро даже на локальном компьютере общаются только через неё.
Но в пожарке не так много событий, поэтому такой сценарий вполне реализуем - при восстановлении связи все события из ОЗ должный прогрузиться в ЦСО.
И на этом этапе снова возникает затык, так как при одновременном подключении к ЦСО сразу всех локальных объектов закончатся количество подключений и количество рабочих потоков, фактически это DDoS-атака... и сервак не устоит.
В 1.20.3 уже есть механизм блокировок, который позволит отклонять превышение подключений, пока не будет завершён обмен. Сейчас начинаем его тестировать, очень надеемся, что заработает.
Я бы попробовал но только на новой версии.

9 дней 19 часов назад

avatar
Для реализации резервирования сервера придётся покупать MS SQL Server, а это уже может быть дороже самого Ориона.

Кечаев Алексей Борисович 9 дней 16 часов назад

Локальное управление сохранится в любом случае.
Ведь сейчас в центре вообще нет никакого управления удалёнными подсистемами, и ничего, объект живёт как-то.
Так что при выключении мониторингового центра всего лишь произойдёт откат к нынешнему состоянию.
-------
Номера разделов в подсистемах переписывать придётся. Жуть.

Андрей, Ростов на Дону 9 дней 14 часов назад

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

В случае потери связи с сервером, т.е. с БД, локальное управление сохранится только с пульта С2000М, а на локальном мониторе управления не будет.
 

Кечаев Алексей Борисович 9 дней 10 часов назад

Локальное управление ("Оперативная задача" при пропадании связи с "ЦСО") будет работать работать = управлять и показывать состояние, но только того оборудования, которое подключено к его локальным портам, при условии, что Оболочка не зависнет.
Оперативная задача имеет локальную копию данных - свой кэш, с которым она работате до восстановления связи.

Заварзин Сергей Петрович 8 дней 22 часа назад

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Номера разделов переписывать придётся и это для большой системы большая проблема - ограничение всего в 10000 разделов в версии 1.20.2 не перепрыгнешь... из разговора с разработчиками припоминаю, что это ограничение связано не с Орионом, а именно с пультом (у него максимум 9999).
 

8 дней 21 час назад

avatar
Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Тоже объединял около 20 объектов. Проблем с объединением в принципе нет. Но я бы рекомендовал платный SQL, с функцией репликации. 
Единственное неудобство это огромное количество разделов. Для этого была реализована фунция ссылок и графически выведено на экран по адресам зданий. Орионы про нужно будет подводить под единую версию Орион Про. Если 1.20., может выйти затратно!

8 дней 16 часов назад

avatar
А зачем репликация? SQL сервер во всей этой системе представляется достаточно надёжным звеном.

Андрей, Ростов на Дону 3 дня 12 часов назад

SQL может быть, а вот сам компьютер может "умереть" в любой момент. А пожарка должна у вас функционировать 24\7. А запасной компьютер в новогоднюю ночь вы вряд ли где найдете!

Nazarkin Sergey 3 дня 10 часов назад

а вот сам компьютер может "умереть" в любой момент. А пожарка должна у вас функционировать 24\7.

Работоспособность АРМ на работоспособность пожарки не влияет, так как пожаркой, по сути, должен "рулить" объектовый ПКУ.

Бушнов Олег Игоревич 1 день 16 часов назад

А где я говорил, что за работоспособность ПС должен отвечать сервер?
Я говорю о том, что Заказчик хочет увидеть именно то, что ему напели в уши манагеры и т.д. А если у Вас компьютер "издохнет"!? А БД у вас нет и никто её не делал. А Заказчик хочет что бы восстановили работоспособность уже завтра, т.к. у него орагнизован круглосуочный пост охраны для этого, а это нифига не работает и он платит за "безделье" своих охранников. И ваш директор выгоняет вас, или другого сотрудника вашей фирмы, на рабту 1 января с наказом исправить все сегодня же??? И вы, как бешенный сайгак, мчитесь на объект, а там ....
А вот если у вас еще один сервер с функцией репликации вы можете очень спокойно, не дергаясь, отгуляв праздничные дни, найти другую железяку, накатить Орион и все останутся довольны. А уж если у вас каждый из компов будет резервным, ну тут уж совсем праздник!

Nazarkin Sergey 1 день 9 часов назад

Осталось озвучить стоимость всего этого счастья, чтобы Заказчик сказал: "Это лишнее".

Кечаев Алексей Борисович 1 день 1 час назад

А где я говорил, что за работоспособность ПС должен отвечать сервер?

Нет?
А пожарка должна у вас функционировать 24\7.

Значит мне показалось? Просто выражайтесь точнее - мухи отдельно, котлеты отдельно.
Я говорю о том, что Заказчик хочет увидеть именно то, что ему напели в уши манагеры и т.д.

Вот поэтому наша задача, как обслуживающих организаций, предельно ясно донести до Заказчика именно корректную информацию, а не то что там "манагеры напели".
А если у Вас компьютер "издохнет"!?

А запасной компьютер в новогоднюю ночь вы вряд ли где найдете!

Так и отношение с Заказчиком надо построить таким образом, что этот самый "запасной компьютер" должен у него иметься.
А БД у вас нет и никто её не делал.

Если АРМ на обслуживании, то и резервные копии должны делаться регулярно. Как минимум вручную после внесения изменений в конфигурацию. И храниться, разумеется, отдельно. Сдох комп, достали резервный и вкатили туда свой бэкап.
А вот если у вас еще один сервер с функцией репликации вы можете очень спокойно, не дергаясь, отгуляв праздничные дни, найти другую железяку, накатить Орион и все останутся довольны. А уж если у вас каждый из компов будет резервным, ну тут уж совсем праздник!

Это дает нам сохранность БД и ее "горячее" резервирование при падении основного сервера с БД. А что делать если сдохнет сервер с "Ядром", куда непосредственно приборы системы подключены? Репликация БД нам тут уже не поможет и все равно потребуется идти на объект.

Если поразмыслить, то для достижения большей отказоустойчивости Ядро должно жить в отдельной ОС на виртуальной машине. Для отслеживания работоспособности ВМ и ОС внутри нее есть масса инструментов, в том числе с автоматическим развертыванием из резервной копии в случае сбоя. Для состыковки Ядра с приборами нам поможет С2000-Ethernet, чтобы избавиться от привязки приборов системы к физической машине. Вот тут-то репликация БД нас и выручит. Но без резервирования именно Ядра - это почти бессмысленно...

Бушнов Олег Игоревич 18 часов 7 минут назад

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

Добавить ответ

Для добавления сообщений на форуме вам необходимо зарегистрироваться и указать мобильный телефон в своем профиле (зачем?)

ПОКАЗАН

818 раз

ЗАДАН

10 дней 14 часов назад

По каждому вопросу/ответу можно добавлять комментарии. Комментарии предназначены для уточнения вопроса/ответа.