Мониторинг в ЦОДе: как мы меняли старую BMS на новую. Часть 2

[hooperer]

И в этом моменте интересно, к каким создателям исключительно Scada систем с таким ТЗ обращались?
ну то-есть те — кто не умеет облака известны так же как и те, кто умеет облака.

[Linx]

Добрый день, мы бы не хотели давать в статье рекламу или антирекламу, поэтому решили не упоминать компании, с которыми расстались на этапе обсуждения ТЗ.

[hooperer]

Достаточно мудрое решение.
При этом мне кажется в сфере Scada систем все на рынке и так знают функционал каждой систем. Это достаточно развитый рынок где у каждой компании есть своя ниша.

[click0]

Новая BMS-система должна была находиться в облаке, на виртуальной машине.

Спорное решение.
Ляжет облако — ляжет все.

[KNagorny]

Резонное замечание, согласен с вами. Именно поэтому мы реализовали систему с резервированием ВМ, расположенных в двух облаках в двух разных городах. Это было наше основное требование, о чем мы в том числе рассказали в статье. К тому же стоит заметить, что отдельно стоящий сервер гораздо менее отказоустойчив по сравнению с облачной платформой.

[click0]

Это не причина вводить лишний слой абстракции (точку отказа).
Почитайте, как можно увеличить отказоустойчивость одного физического сервера.
Разрыв связности между двуми облаками может привести к ситуации split-brain.
Это тоже надо тестировать в вашем случае.

[ventcomplex]

Новая система уже работает? Как Вы решаете проблему возможных разных команд от двух серверов к одному оборудованию? Конфигурация, настройки — едины для обоих серверов?
Если вдруг по какой-то причине один сервер дает команду «включить», а второй «выключить» — какая команда дойдет до конечного оборудования?

[KNagorny]

В штатном режиме функционирования активен только один сервер, а второй находится в горячем резерве. Поэтому источник команд для оборудования всегда только один.