Резервированная архитектура
«КАСКАД Цифра» может работать в резервированном режиме, где используются два сервера «КАСКАД Цифра» (далее называемые «левыми» и “правыми”), где отказоустойчивость одной из этих систем компенсируется другой. Один из серверов всегда является “активным», отправляя данные на периферийные устройства и обрабатывая пользовательские интерфейсы, другой сервер является “пассивным”, поддерживая копию состояния активного сервера.
Основной аспект резервирования NGA заключается в том, чтобы избежать потери исторических данных из-за одиночных аппаратных или программных сбоев. Резервирование предназначено для того, чтобы иметь возможность справляться с одиночными сбоями. Оно не может справится с несколькими серьезными сбоями одновременно (например, со сбоем жестких дисков на обоих серверах). Еще одним аспектом резервирования NGA является обеспечение доступа к чтению исторических данных для удаленных интерфейсов пользователя, даже если один резервный узел не работает.
Существует специальная опция резервирования под названием «Разделенный режим», где оба сервера будут активны, и при деактивации разделенного режима один из них будет оставаться активным, другой будет перезапущен и будет произведено восстановление (это стандартная процедура при перезапуске серверного проекта). На данный момент разделенный режим не поддерживается архиватором нового поколения.
Каждый резервный сервер имеет так называемое «состояние ошибки“ (также называемое ”состоянием работоспособности»), которое обычно должно быть идентичным на обоих серверах. Если состояния серверов различны, то сервер с лучшим состоянием «здоровья» станет активным, что может привести к «переключению» между активным и пассивным серверами. Если сервер остановился, он должен быть синхронизирован при следующем перезапуске, чтобы иметь то же самое «состояние» (значения точек данных, состояния алармов и т.д.), что и сервер, активный в настоящее время. Данная процедура называется восстановлением.
Для преобразования существующего проекта с NGA в резервный в дополнение к стандартным шагам (см. «Резервирование, основы»), frontend-менеджер и backend-коннекторы NGA также должны быть резервированы. Это достигается нажатием кнопки «Создать избыточные данные NGA” (вкладка «Общие» на панели конфигурации NGA, см. раздел «Конфигурация архивных групп»).
Для использования NGA в резервированной системе возможны две различные схемы (в зависимости от поддержки избыточности используемой базы данных):
- Если база данных не может выполнять резервирование самостоятельно (например, версия InfluxDB с открытым исходным кодом), то база данных должна работать на обоих узлах независимо друг от друга (это условие распространяется только на саму БД)
- Если база данных поддерживает резервирование (например, Oracle RAC) , то оба резервированных экземпляра NGA могут взаимодействовать с общим экземпляром базы данных, который будет выполнять операции по резервированию (переключение, восстановление) самостоятельно.
Резервирование NGA для баз данных, не поддерживающих резервирование
В случае баз данных, которые не поддерживают резервирование, архиватор должен позаботиться об основных вариантах использования резервирования:
- Синхронизация пассивной БД с активной
- Переключение между резервными узлами
- Синхронизация баз данных после перезапуска пассивной системы
- Учет состояния базы данных при определении работоспособности системы
Рисунок: архитектура резервированного NGA для баз данных, не поддерживающих резервирование
Основная идея заключается в использовании двух идентичных backend-коннекторов на каждом резервном узле, один из которых подключен к локальной базе данных, а другой – к базе данных на резервном узле. Активный сервер записывает данные через оба backend-коннектора, пассивный сервер просто буферизует блоки данных до тех пор, пока они не будут успешно записаны в базы данных активным backend-коннектором, а затем эти данные с резервного сервера стираются.
При резервировании frontend-менеджер NGA будет дополнительно отправлять все данные на коннектор, записывающий данные в другую систему (“backend-коннектор 2″ на рисунке выше). После переключения ранее пассивный сервер начинает записывать существующие буферы (которые еще не были записаны ранее активным сервером) в базы данных (локальные и удаленные).
Если другой сервер (или, по крайней мере, база данных) не работает или недоступен, backend-коннектор, записывающий данные на этот хост, будет буферизировать данные. Для покрытия более длительного временного диапазона в резервированной среде необходимо соответствующим образом настроить метод буферизации (буферизировать на диск) – см. раздел «Конфигурация frontend-менеджера».
После перезапуска пассивного сервера / базы данных, backend-коннектор активного сервера, записывающего данные в пассивную базу данных, автоматически обнаружит доступность базы данных и начнет запись буферизованных данных (восстановление). Пассивная система должна удалить все локально сохраненные буферы.
Все запросы на чтение исторических значений / алармов (dpGetPeriod, dpGetAsynch, alertGetPeriod, dpQuery) из пользовательских интерфейсов будут автоматически перенаправлены менеджером событий в активную систему. Менеджеры сценариев должны быть запущены с опцией «-connectToRedundantHosts», чтобы автоматически перенаправляться на активный хост.
ПРИМЕЧАНИЕ
Обратите внимание, что в NGA V1.0 опция «Непосредственное считывание” недоступна для резервных систем.
Рисунок: панель обзора системы «КАСКАД Цифра» для резервированного проекта NGA
Архиватор нового поколения также показан на панели обзора системы «КАСКАД Цифра». При создании проекта, использующего NGA, стандартный backend-коннектор (”InfluxDB») отображается для обоих резервированных узлов, а вычисление состояния ошибки включает в себя менеджер NGA (вместо менеджеров архивов или менеджера RDB). Вес ошибки вычисляется на основе подключения backend-коннектора к базе данных (плохо = нет подключения к базе данных).
Резервирование NGA для баз данных с поддержкой резервирования
Для баз данных, которые способны сами поддерживать избыточность (т.е. предлагают один виртуальный узел для связи и способны изнутри управлять записью / чтением /синхронизацией резервированных узлов базы данных), может быть использована аналогичная, но упрощенная архитектура. Примечание: обычно для этого требуется, чтобы базы данных находились на другом узле или на компьютерах, отличных от компьютеров, на которых работает «КАСКАД Цифра».
ПРИМЕЧАНИЕ
Эта опция резервирования пока недоступна, так как она пока что не требуется для backend-коннектора InfluxDB®.
Рисунок: резервированная архитектура NGA для баз данных с поддержкой резервирования
На каждом резервном узле «КАСКАД Цифра» требуется только один backend-коннектор NGA, каждый из которых подключен к одному и тому же виртуальному экземпляру БД. NGA на активном сервере записывает данные в базу данных, пассивный буферизует и отбрасывает буферы, когда они были зафиксированы активной стороной. Это решение очень похоже на архитектуру резервирования, используемую менеджером RDB «КАСКАД Цифра».
Поскольку резервированная база данных может выполнять переключение самостоятельно, активный сервер должен иметь возможность обрабатывать прерванные транзакции (вызванные переключением базы данных) и повторять их. Это обеспечивается алгоритмом буферизации NGA, который повторяет запись буфера до тех пор, пока операция не завершится успешно или не будет превышено допустимое количество попыток.
Все операции чтения (в том числе и непосредственные) всегда отправляются на один и тот же виртуальный узел БД, поэтому нет необходимости «адресовать» активный узел для прямых запросов.