Видеонаблюдение с резервированием

Для каждой критичной функции задаём:

• что может отказать;
• что должно продолжать работать;
• сколько времени допустим простой;
• как оператор узнает об отказе;
• как система возвращается в штатный режим.

Проверяем:

• ввод электропитания;
• ИБП;
• PoE-коммутатор;
• магистральное соединение;
• NVR;
• VMS/сервер;
• HDD/RAID;
• интернет;
• межобъектовый канал;
• отдельную критичную камеру.

Для каждого узла фиксируем последствия его отказа.

Не обязательно дублировать всю систему.

Чаще выделяются критичные функции:

• запись входа;
• запись кассы;
• контроль ворот;
• периметр;
• архив определённых камер;
• удалённый доступ;
• просмотр текущего видео оператором.

Резервируем бизнес-функцию, а не всё оборудование одинаково.

Это только один слой.

Для него отдельная страница:

• Видеонаблюдение с ИБП

ИБП помогает пережить пропадание электричества, но не решает:

• отказ NVR;
• отказ диска;
• потерю магистрального соединения;
• отказ центральной VMS.

Если один PoE-коммутатор питает десятки камер, он становится общей точкой отказа.

Варианты зависят от объекта:

• разделить камеры между коммутаторами;
• резервировать питание;
• предусмотреть запасной коммутатор;
• построить другую топологию.

Не создаём избыточную сложность без требования.

Для критичных узлов могут применяться:

• два магистральных соединения;
• резервный коммутатор;
• кольцевая топология;
• разные трассы;
• резервный WAN.

Но два кабеля, проложенные в одном лотке и подключённые к одному коммутатору, не являются полноценным независимым резервом.

Варианты:

• второй NVR;
• резервный сервер с переключением при отказе;
• локальная запись + центральная VMS;
• распределённая архитектура.

Нужно заранее понимать:

• что происходит при отказе основного;
• кто принимает запись;
• как пользователь ищет архив;
• требуется ли ручное переключение.

SD-карта может быть дополнительным уровнем для отдельных моделей/сценариев.

Но нельзя обещать автоматическое восстановление пропущенного архива на NVR без проверки конкретной функции камеры/VMS.

Локальная запись на камере рассматривается как конкретная поддерживаемая возможность, а не универсальное резервное копирование.

RAID повышает доступность дисковой подсистемы при отдельных отказах диска.

Но:

• не является отдельной резервной копией;
• не защищает от удаления;
• не спасает от полного отказа регистратора;
• не заменяет удалённое/дополнительное хранение, если оно требуется.

Возможные уровни:

• RAID;
• второе хранилище;
• второй NVR;
• локальная запись на камере;
• удалённая копия критичных событий;
• центральный архив.

Выбор зависит от:

• ценности записи;
• срока;
• канала;
• допустимой потери.

Если локальная запись должна работать без WAN, это проектируется отдельно.

Резервный внешний канал нужен только тем функциям, которым действительно требуется связь:

• удалённый просмотр;
• уведомления;
• облако;
• центральная VMS.

Локальная запись не должна становиться зависимой от резервного LTE только потому, что он есть.

Для сети объектов особенно важно не делать центр единственной точкой записи.

Рациональная схема часто:

• объект продолжает локальную запись;
• центр получает данные о состоянии, текущее видео и архив по запросу.

При потере WAN центральный оператор видит потерю связи, но локальный архив не должен исчезать, если автономность заложена.

Резерв бесполезен, если никто не знает, что основной узел уже отказал.

Полезно мониторить:

• потеря связи с регистратором;
• отказ диска;
• потеря связи с камерой;
• коммутатор;
• WAN;
• UPS;
• синхронизация времени.

Резервный узел должен включаться до того, как обнаружится второй отказ.

Даже без формальной терминологии полезно определить:

• сколько минут допустим простой;
• допустима ли потеря нескольких секунд;
• нужно ли переключение автоматически;
• можно ли восстановить архив позже.

Это сильнее влияет на архитектуру, чем само слово “резерв”.

1. Критичные функции

Что обязано сохраниться.

2. Карта отказов

Что может отключить функцию.

3. Допустимые последствия

Простой и потеря записи.

4. Архитектура резерва

Питание, сеть, хранилище, сервер.

5. Мониторинг

Как узнаём об отказе.

6. Проверка отказа

Имитируем согласованные отказные сценарии.

7. Восстановление

Проверяем возврат в штатный режим.

Проверяем не наличие второго устройства в шкафу, а реальный отказ.

Например:

• отключаем WAN;
• отключаем согласованное магистральное соединение;
• проверяем потерю центральной VMS;
• тестируем питание;
• имитируем недоступность основного узла безопасным способом.

После каждого теста фиксируем:

• что продолжило работать;
• что отключилось;
• сколько заняло восстановление;
• сохранился ли архив.

• схему;
• камеры;
• коммутаторы;
• NVR/VMS;
• хранилище;
• UPS;
• WAN;
• критичные зоны;
• допустимый простой;
• требования к архиву;
• сеть объектов — если есть.

ИБП = резервирование всей системы?

Нет. Он резервирует питание.

RAID = резервное копирование?

Нет. RAID помогает при отдельных отказах диска, но не заменяет независимую копию.

Нужно дублировать все камеры?

Нет. Сначала определяются критичные функции и точки.

Можно оставить локальную запись при падении центральной VMS?

Да, если архитектура и оборудование это поддерживают.

Резерв обязательно должен переключаться автоматически?

Нет. Это зависит от требуемого времени восстановления и бюджета.