Кластеры: настройка Viinex 2.0 “на лету”

Одно из ограничений Viinex 2.0 состояло в том, что данное ПО не позволяло клиентам менять конфигурацию экземпляра Viinex во время работы последнего. Если требовалось добавить камеру или изменить какой-то из аспектов поведения объектов Viinex, -- нужно было остановить весь экземпляр Viinex 2.0, изменить его конфигурацию, и запустить этот экземпляр снова. По сути, для самого экземпляра Viinex это значит, что он не может наблюдать изменение собственной конфигурации.

Начиная со сборки 218 Viinex 2.0, это ограничение стало неактуальным. Теперь Viinex содержит средства для создания и удаления групп объектов прямо во время работы. То есть, если клиентскому ПО нужно динамически создать или удалить, например, источник видео, -- с Viinex 2.0 это теперь стало возможным. И, так же как со всей прочей функциональностью, -- мы предоставляем для этого HTTP API: софт, использующий Viinex, может программно создавать и удалять группы объектов.

При этом, кое-что все же требуется прояснить. Причина, по которой мы изначально решили сделать конфигурацию экземпляра Viinex 2.0 неизменяемой и долго придерживались этого решения, состоит в следующем. Когда к конфигурации программной системы применяются изменения, и система сама состоит из нескольких логических объетов, взаимодействующих друг с другом и зависящих друг от друга, -- для того чтобы конфигурация оставалась целостной и непротиворечивой, изменения настроек связанных объектов должны производиться одновременно и атомарно. Например, если требуется добавить камеру в систему, получать от нее события, настроить правила для реагирования на какой-то из детекторов, и записывать по этому правилу видео от данной камеры в архив, -- если соответствующие изменения в конфигурацию начать делать на лету последовательно, по цепочке, одно за другим, -- то конфигурация системы в целом окажется несостоятельной до тех пор, пока не будет выполнено самое последнее изменение в цепочке.

Мы считаем что это плохой паттерн, поэтому от программного обеспечения, которое использует Viinex, мы требуем, чтобы изменения в конфигурацию вносились "атомарно", то есть чтобы все изменения, связанные с объектами, которые должны работать совместно, -- применялись одновременно. Такой подход обладает существенным преимуществом: при нем все объекты, которые полагаются друг на друга для корректного функционирования, -- могут безопасно предполагать, что их зависимости во время работы Viinex не исчезнут из-за изменения настроек. Непротиворечивость конфигурации может быть проверена единожды, при старте экземпляра Viinex, и эта целостность гарантируется на всем протяжении работы экземпляра.

Способ, предсмотренный нами для динамического добавления и удаления объектов в Viinex, учитывает эти соображения. В частности, -- объекты, которые добавляются или удаляются из Viinex, должны быть добавлены или удалены не поодиночке, а как единая группа объектов, вместе со связями, которые должны быть установленны между новыми объектами. Такие группы в Viinex 2.0 названы кластерами. Важно, что, при том что кластеры могут быть созданы и удалены во время работы экземпляра Viinex 2.0, -- конфигурация каждого кластера, как и ранее, остается неизменяемой (с точки зрения объектов в соответствующем кластере -- они не могут наблюдать изменения конфигурации кластера). Для того чтобы изменить конфигурацию кластера -- его нужно полностью удалить и затем создать заново, уже с новой конфигурацией.

Еще одним следствием принципа неизменности конфигурации кластеров является то, что объекты внутри кластера могут быть связаны только друг с другом, но не с объектами в других кластерах. Это объясняется тем, что связи между объектами являются частью конфигурации, -- которая неизменна для каждого отдельного кластера.

Это ограничение практически может быть преодолено за счет, например, установки сетевых соединений между объектами в различных кластерах. Сетевое соединение по своей сути является хрупким, поэтому реализации объектов в Viinex изначально готовы обрабатывать разрывы сетевых соединений, -- которые будут происходить при удалении кластеров, в которых находятся объекты, с которыми установлены такие соединения. Это будет нормальным, ожидаемым поведением для второй стороны соединения, потому что сетевое соединение может разорваться из-за внешних причин, -- в отличие от связей между объектами Viinex в одном кластере или в главной конфигурации.

Мы убеждены, что такой подход является более прямолинейным и честным, чем попытки обработать не вполне состоятельную конфигурацию, возникающую при последовательном, "частичном" изменении настроек и их применении на лету. Простота описанного выше подхода окупается для разработчиков, использующих Viinex 2.0.

Комментариев еще нет.

Leave a Reply

Вы должны войти Авторизованы чтобы оставить комментарий.