Форум компании Ритм - НПО «Ритм»

Настройка Кластера PCN 6

Поиск  Пользователи  Правила  Войти  
Страницы: 1 2 След.
RSS
Настройка Кластера PCN 6, Как настроить Кластер в PCN 6, принцип работы.
Здравствуйте коллеги, мы сейчас разворачиваем мониторинг стационарных объектов на Контакт 5, есть несколько вопросов по кластеру:
1) При организации кластера из двух серверов, каждый имеет собственную базу MySQL или используются средства кластиризации средствами MySQL?
2) Для правильной работы какие порты должны быть открыты между серверами?
3) Подразумевается ли нормальная работа системы при выходе из строя основного сервера в кластере?
Смотря что Вы понимаете под кластером.

MySQL может работать в кластере, но полноценного тестирования не проводилось.
Inetserver может работать в Windows Server Network Load Balancing Services - есть опыт использования.
Перед нами поставлена следующая задача:

Два одинаковых полноценных сервера (условно один основной, второй резервный), каждый оснащен стационарными модемами (CSD, SMS), в случае выхода из строя любого из них система продолжает работать на одном сервере. Посоветуйте как нам лучше организовать такую систему.
Можно собрать два сервера - один копия другого: на каждом будет MySQL, PCN6, inetserver.

Далее можно либо настроить репликацию MySQL, либо в одном из inetserver настроить поток "БД в Sur-gard", а в другом - "Мониторинговая станция Контакт" и соединить их нуль-модемным или виртуальным COM кабелем.

К серверу с основной БД нужно подключить приёмное оборудование.

Таким образом получится что события будут приходить на один сервер и дублироваться на втором.

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

Переключение можно делать физически переключая COM кабель от одного сервера на другой. Либо переключение можно делать программно - с помощью устройств преобразования RS-232->Ethernet.

Конечно это не отменяет резервирование БД.
Опишу как это реализовано у нас.
Есть два сервера с IS, к которым подключено по паре модемов. Сервер с БД "уехал" на площадку хостера, о чем тут в какой-то теме (а может и не одной) я уже писал. Таким образом оба сервера обращаются к одной базе. В случае отключения (краха) одного, второй остается вполне себе жизнеспособным.
В настроках IS одного из серверов отключается "управление архивом" (назову это так). Т.е. перекидывать сообщения в архив должен только один IS.
На интернет-шлюзе организации (канал от IS до базы) настроено резервирование интернет-канала. В случае пропадания одного, происходит переключение на другой.
Соответственно пользователи обращаются либо к веб интерфейсу, который так же размещен на хостинге, либо напрямую к MySQL посредством pcn6.

P.S. В подобной схеме работы есть проблема, описанная здесь
Максим, а вот хотелось бы избежать ручного переключения, и этот переход осуществлять автоматически при выходе из строя любого сервера, при этом теряя часть резервных каналов (половину модемов). Я так понимаю, что режим кластерной системы в ПЦНсервер предназначен только для снижения нагрузки на каждый сервер и в случае выхода основного сервера, все прекратит работать?
Алексей, ваш вариант подразумевает наличие 3 серверов? два для IS и один для БД? У нас основная задача обеспечить бесперебойное резервирование работоспособности самой системы и сохранности данных.
Цитата
Дмитрий Артамонов пишет:
Максим, а вот хотелось бы избежать ручного переключения, и этот переход осуществлять автоматически при выходе из строя любого сервера, при этом теряя часть резервных каналов (половину модемов). Я так понимаю, что режим кластерной системы в ПЦНсервер предназначен только для снижения нагрузки на каждый сервер и в случае выхода основного сервера, все прекратит работать?


Имея ограничения в каналах связи CSD и SMS нужно использовать приёмное оборудование: Мониторинговая станция "Контакт" и Стационарный GSM модем. Станция и модем подключаются к серверу через COM-порты, соответственно принимать события от панелей по этим каналам можно только на один сервер для каждого канала связи. Из этого следует, что необходимо: либо при выходе из строя сервера руками (или программно в настройках драйвера преобразователя RS-232->Ethernet) переключать COM-кабели с не рабочего сервера на резервный, либо в настройках панелей указывать несколько каналов связи (через логику "или").
Если бы Вы использовали на объекте канал GPRS или Ethernet, то тогда всё проще - NLB для inetserver, MySQL серверы независимы друг от друга - имеем полностью независимо от присутствия человека работающую систему. Дополнительно можно настроить внешнюю программу для проверки серверов внутри сети (inetserver и MySQL) и снаружи (inetserver). Не забудьте про резервную электростанцию и можете отправляться в отпуск.
Цитата
Дмитрий Артамонов пишет:
Алексей, ваш вариант подразумевает наличие 3 серверов? два для IS и один для БД?

Сказать точнее, данный вариант подразумевает вынесенный север БД и относительно произвольное количество серверов IS. В варианте, который реализован у нас, фактически два наших сервера и "сервер БД" на базе ресурсов хостинг-провайдера.
Цитата
Дмитрий Артамонов пишет:
... У нас основная задача обеспечить бесперебойное резервирование работоспособности самой системы и сохранности данных.

Преследовал такую же задачу + бюджетность решения ...

С прискорбием вынужден заключить, что связка БД + IS рассчитана на функционирование в рамках одной локальной сети или одного сервера. Вопрос отсутствия связи между IS и БД, как я понимаю, разработчиками не учитывается smile:(

Т.е. все здорово, когда IS + СУБД находятся в одном помещении/здании с диспетчерской службой. Если диспетчер куда-либо "уезжает", то повышение доступности сервиса становится той еще задачкой ...

P.S. Если интересно, могу попытаться собрать в кучку свои мысли и описать подробнее почему пришли к такому варианту ...
Спасибо за разъяснения, мы определились со схемой резервирования, но у наших IT специалистов внезапно возник вопрос, а поддерживается ли MS SQL Server?
Выбранная схема резервирования на 2-х серверах
1) Основной сервер (белый IP №1) установлено IS + БД + 2 стационарных модема CSD
2) Резервный сервер (белый IP №2) установлено IS + 2 стационарных модема CSD все это настроено на БД основного сервера, с основного сервера репликация MySQL. + волшебная кнопка.
В случае выхода из строя основного сервера, нажимаем "волшебную кнопку" и резервный сервер становиться основным IS на резервном переключается к своей базе, объекты автоматом переходят на второй поток (IP №2).
Страницы: 1 2 След.