«Safe» режим 2.0 OSS

В документ, описывающий концепцию реализации версии 2.0 OSS добавлено описание Safe режима работы агентов, который спустя 7 лет с момента появления его первой реализации обрел черты существенного конкурентного преимущества.
В режим «Safe» в версии OSS могут функционировать все агенты системы. Основным, но не единственным его достоинством является возможность построения распределенной биллинговой схемы при которой в непосредственной близости от оборудования при помощи которого оказывается услуга устанавливается только агент, без центрального хранилища, серверной части LBserver и API LBCore. Все основные компоненты могут находиться на удалении от агента и узла связи. При этом гарантируется, что услуга продолжает оказываться на уровне узла и управление ее не страдает при пропадении сетевой связности между агентом и центральной частью системы.
Применение такой конфигурации оправдано в случаях когда услуги оказываются в рамках одной компании, необходим централизованный учет и контроль, единая отчетность, при этом узлы связи территориально распределены и объеденены каналами, надежность которых не гарантирована. В реализации версии 2.0 OSS данный режим предусматривает такие аварийные ситуации, при которых в период отсутствия связности компонентов биллинговой системы происходят перезагрузки агента, отключение с последующим восстановлением данных из локального временного хранилища.
В конфигурации при наличии Safe режима все централизованные операции, такие как прием платежей, работа абонентского отдела, сервисных служб производится в едином центре управления. В ряде случаев отсутствует необходимость иметь на местах оказания услуг квалифицированный персонал.
Так, в качестве примера, можно привести конфигурацию при которой центральная часть АСР LANBilling 2.0 OSS может быть установлена в Екатеринбурге, а в узлах «саттелитах», таких как Миасс, Челябинск и Магнитогорск устанавливаются лишь агенты. В момент потери связности с центральными компонентами АСР LANBilling 2.0 OSS агенты начинают работать в автономном режиме и актуальность данных разделяется между локальным хранилищем и центральной СУБД. В момент восстановления происходит синхронизация актуальных данных. Чем дольше агент проработает в автономном режиме тем, дольше займет времени процесс синхронизации. Этот фактор необходимо учитывать при проектировании IT инфраструктуры.