1. Зачем проверять резервирование при ПНР
2. Типы резервирования: PSU, кольца, uplink, контроллеры
3. Расчёт запаса блоков питания N+1
4. STP, RSTP и MSTP: время сходимости и измерения
5. Таблица сценариев испытаний failover
6. Dual uplink: LACP и active-standby
7. Резервирование питания АПС и СКУД
8. CLI: Cisco, MikroTik, HPE
9. Безопасность испытаний и окно обслуживания
10. Образец записи в протокол ПНР
11. Ложные срабатывания и типовые ошибки
12. Чек-лист сдачи резервирования

Зачем проверять резервирование при ПНР

Резервирование (redundancy) — это не надпись в спецификации и не «два блока питания в шкафу», а подтверждённая способность системы продолжать работу при отказе одного элемента. На объекте инженер-пусконаладчик (ПНР) обязан не только убедиться, что оборудование включено, но и воспроизвести отказ: выдернуть кабель, отключить БП, перевести контроллер в standby — и зафиксировать, что система восстановилась в пределах проектных сроков.

Проверка резервирования затрагивает несколько уровней инфраструктуры:

• Электропитание — dual PSU (два блока питания), резервные линии 220 В, ИБП, генератор;
• Сеть L2 — кольцевые топологии, протоколы STP (Spanning Tree Protocol), RSTP (Rapid STP, IEEE 802.1w), MSTP (Multiple STP);
• Агрегация uplink — LACP (Link Aggregation Control Protocol, IEEE 802.3ad/802.1AX) или active-standby;
• Контроллеры — dual controller в BMS, СКУД, АПС, видеонаблюдении.

Без документированных испытаний заказчик формально не может принять систему: при реальном отказе выяснится, что «резерв» существует только на схеме. Эта статья — практическая методика для инженера на объекте: что считать, что отключать, что писать в протокол и как не получить ложный «успех».

Типы резервирования: PSU, кольца, uplink, контроллеры

Перед испытаниями составьте таблицу «что заявлено проектом» и сопоставьте с фактической конфигурацией. Ниже — четыре базовых типа, которые встречаются на каждом втором объекте слаботочных систем.

N+1 блоки питания (dual PSU)

N+1 означает: для нагрузки N достаточно одного рабочего блока, второй — резерв. В коммутаторе, сервере, СХД или шасси контроллера АПС обычно установлены два модуля питания (PSU, Power Supply Unit), подключённые к разным линиям электроснабжения (разные автоматы, фазы или ИБП). При выходе одного PSU нагрузку должен принять второй без перезагрузки и без просадки ниже допустимого.

На практике проверяют: индикацию «PSU OK» на обоих модулях; фактическое потребление vs номинал каждого БП; отключение одного БП (вынуть модуль или обесточить одну линию 220 В) — система продолжает работу, на мониторинге нет аварии уровня Critical.

Кольцо L2 (ring)

Кольцевая топология связывает коммутаторы замкнутым контуром: трафик идёт по «короткому» пути, один линк в кольце логически блокируется протоколом spanning tree, чтобы не было петли. При обрыве любого участка кольцо «разрывается» в одной точке, STP/RSTP перестраивает дерево, и связность восстанавливается через резервный путь.

Для АПС, СКУД, CCTV и BMS кольца часто строят на промышленных коммутаторах (Moxa, Hirschmann, Cisco IE) или на «офисных» с включённым RSTP. Критично: корневой мост (root bridge) назначен осознанно, порты к конечным устройствам — edge, BPDU Guard включён на access-портах.

Dual uplink (два восходящих канала)

Коммутатор доступа или агрегации имеет два линка к ядру или к парному коммутатору. Режимы:

• LACP (802.3ad) — оба линка активны, пропускная способность суммируется (с оговорками по хешированию потоков); при отказе одного линка трафик перераспределяется на оставшийся;
• Active-standby — один линк в forwarding, второй blocked STP или протоколом типа VRRP/HSRP на L3; переключение при отказе активного.

Dual uplink не заменяет кольцо: uplink — «вверх» к ядру, кольцо — «вбок» между шкафами этажей. На объекте проверяют оба сценария, если они заявлены.

Dual controller (горячий/ тёплый резерв)

Пара контроллеров: один active, второй standby/hot-standby. Примеры: два сервера СКУД, кластер BMS, резервный ППК (прибор приёмно-контрольный) пожарной сигнализации по проекту. Переключение может быть автоматическим (heartbeat по сети) или ручным. При ПНР проверяют: синхронизацию конфигурации и журналов; время переключения; отсутствие «потери» событий и точек доступа/шлейфов при failover.

Расчёт запаса блоков питания N+1

Dual PSU на корпусе — необходимое, но недостаточное условие. Если оба блока номиналом 300 Вт, а суммарная нагрузка 280 Вт, при отказе одного БП второй работает на 93 % номинала — перегрев, отключение по защите, каскадный отказ. Проект и методики эксплуатации требуют запас мощности на режим «один БП выведен из строя».

Исходные данные

• P_total — суммарная текущая нагрузка шасси (из SNMP, web GUI, «show power» или таблицы PD + собственное потребление коммутатора);
• P_rated — номинальная мощность одного PSU (из шильдика или datasheet);
• режим N+1: при штатной работе нагрузка распределена между двумя БП; при отказе одного весь P_total ложится на оставшийся модуль.

Формула запаса (margin)

Запас мощности в процентах относительно текущей нагрузки:

margin = (2 × P_rated − P_total) / P_total × 100 %

Условие приёмки для схемы N+1 (два одинаковых PSU, один резервный):

margin ≥ 30 %

Эквивалентная запись: один PSU должен покрывать P_total с запасом не менее 30 %, то есть P_rated ≥ P_total × 1,30.

Пример расчёта

Коммутатор PoE+ 24 порта: P_total = 340 Вт (PoE PD + собственное ~25 Вт). Установлены два PSU по P_rated = 250 Вт каждый.

margin = (2 × 250 − 340) / 340 × 100 % = 160 / 340 × 100 % ≈ 47 %

47 % ≥ 30 % — условие N+1 выполнено. При отказе одного БП оставшийся 250 Вт модуль несёт 340 Вт — это перегруз (136 % номинала). Ошибка: формула через 2×P_rated проверяет суммарную ёмкость пары, но физически один модуль должен выдержать P_total. Корректная проверка для failover:

P_rated ≥ P_total × 1,30  →  250 ≥ 340 × 1,30 = 442 — не выполнено

На объекте зафиксируйте в протоколе: модель шасси, серийные номера PSU, измеренное P_total (скрин «Power Consumption»), P_rated, расчёт margin, результат отключения одного БП (время, аварии, температура через 15 мин работы на одном модуле).

STP, RSTP и MSTP: время сходимости и измерения

STP (IEEE 802.1D) — классический spanning tree. При изменении топологии проходит состояния listening → learning → forwarding; типичное время сходимости 30–50 секунд (max age 20 с + forward delay 15 с × 2). Для кольца с IP-камерами и контроллерами это неприемлемо: потоки видео рвутся, BMS теряет точки.

RSTP (IEEE 802.1w) — rapid spanning tree. Согласование через proposal/agreement, edge-порты переходят в forwarding почти мгновенно. Типичное время восстановления кольца после обрыва линка: 1–6 секунд на оборудовании без тяжёлых нестандартных таймеров. На практике закладывают ≤6 с для приёмки, ≤3 с — хороший результат на промышленных коммутаторах.

MSTP (IEEE 802.1s) — несколько spanning-tree instances в одной сети (VLAN mapping на instance). Время сходимости сопоставимо с RSTP для каждого instance, но конфигурация сложнее: ошибка в region name/revision → MST island, непредсказуемое поведение.

Что измерять на объекте

1. Непрерывный ping с ноутбука ПНР до хоста «за кольцом» (контроллер, камера, шлюз): ping -t <IP> (Windows) или ping <IP> в цикле. Фиксируйте количество потерянных echo-reply и время от последнего успешного до первого после восстановления.
2. Секундомер — от момента отключения патч-корда (или shutdown порта) до момента, когда ping стабильно отвечает (3–5 успешных подряд). Запишите t_failover в протокол.
3. SNMP / syslog — метка времени STP topology change notification на корневом и затронутых коммутаторах; сверка с секундомером.
4. Прикладной уровень — для CCTV: нет ли «чёрного экрана» >10 с; для BMS: опрос Modbus/BACnet восстановился; для СКУД: событие «связь с контроллером восстановлена» в журнале.

Таблица сценариев испытаний failover

Используйте таблицу как основу протокола. Колонка «Поле протокола» — что переносить в бланк ПНР без переписывания простыней текста.

Каждый сценарий выполняют дважды, если проект требует: отказ элемента A, восстановление, отказ элемента B (симметрия). После теста — возврат в штатное состояние и пауза 2–3 мин для стабилизации STP/MAC table.

Dual uplink: LACP и active-standby

Режим LACP (802.3ad)

Оба линка входят в port-channel (Cisco Po, HPE Trunk, MikroTik bonding mode 802.3ad). LACP PDU обмениваются каждые 30 с (fast LACP — 1 с, если настроено). При отказе одного member агрегат остаётся Up, если хотя бы один линк жив.

Как тестировать LACP:

1. Зафиксировать состояние bundle: show etherchannel summary (Cisco) — флаги (P) для LACP, (I) для individual.
2. Запустить ping и, по возможности, iperf3 через uplink-сеть до хоста за ядром.
3. Отключить один патч-корд member — bundle должен остаться Up (flags (P) на оставшемся порту).
4. Зафиксировать потерю ping (обычно 0–3 пакета при fast LACP, до 1–2 с).
5. Проверить, что MAC таблица и spanning tree не видят петлю (counter increment on interface stable).
6. Вернуть линк — member снова (P) в bundle без ручного вмешательства.

Режим active-standby

Второй uplink в состоянии blocking (STP) или не участвует в forwarding до отказа первого. Варианты: два физических линка, один в VLAN trunk blocked; proprietary «flex link»; L3 — HSRP/VRRP на паре маршрутизаторов.

Как тестировать active-standby:

1. До теста: show spanning-tree interface — один uplink FWD, второй BLK/ALT (Cisco RSTP).
2. Ping -t через сеть; отключить активный uplink.
3. Зафиксировать t_failover до стабильного ping; второй uplink перешёл в FWD.
4. Убедиться, что не образовалась L2-петля (broadcast storm — симптом ошибки STP root/design).
5. Вернуть первый uplink — проверить, вернулась ли приоритетная схема (preempt) или активным остался бывший standby (зависит от проекта).

LACP и active-standby не смешивают на одной паре портов без чёткой политики: два линка в LACP — оба active; active-standby — только один forwarding. В проектной документации должно быть явно указано, какой режим где.

Резервирование питания АПС и СКУД

Пожарная сигнализация (АПС) и система контроля и управления доступом (СКУД) предъявляют отдельные требования к электроснабжению — выше, чем к «офисной» сети. СП 484.1311500.2020 и СП 6.13130.2021 (в части АПС) требуют категорирования электропитания; на практике при ПНР проверяют следующее.

Раздельные цепи (separate circuits)

• АПС и СКУД питаются от отдельных автоматов (или групп), не от общей розетки с уборочным оборудованием и ПК охраны;
• линии проложены отдельными кабелями или как минимум с маркировкой и раздельными вводами в щит;
• резервная линия — второй ввод, ИБП или ДГУ (по проекту) — физически независима от основной: отключение «основной» не обесточивает резерв автоматически только если схема ВРУ/АВР выполнена корректно.

Испытания на объекте

1. Снять напряжение на шине питания ППК/блока СКУД при штатной работе (в пределах 24 В ± допуск по РЭ).
2. Отключить основной автомат — зафиксировать время переключения на ИБП/резерв (осциллограф или секундомер + индикация «Сеть/Батарея»).
3. Убедиться: нет ложного «Пожар», «Вскрытие», mass alarm; событие «пропадание сети 220 В» в журнале — штатное.
4. Измерить автonomy time ИБП под реальной нагрузкой (шлейфы + СКУД) — не менее проектного (часто 24 ч для АПС в режиме дежурства + тревога, по проекту).
5. Dual PSU внутри сервера СКУД — по методике раздела расчёта margin; плюс разные фазы/автоматы на каждый БП.

СКУД при пропадании связи с контроллером часто переходит в «fail-safe» или «fail-secure» (зависит от проекта дверей). Зафиксируйте фактическое поведение каждой критичной точки при тесте сетевого failover — расхождение с проектом требует настройки или актуализации документации.

CLI: Cisco, MikroTik, HPE

Перед отключением кабелей сохраните baseline — вывод команд ниже. После failover сравните: изменился ли root port, role порта, состав LACP bundle, статус bridge.

Cisco IOS / IOS-XE

show spanning-tree detail
show spanning-tree interface Gi1/0/24 detail
show etherchannel summary
show interface status
show power inline ! PoE load
show environment power

В выводе show spanning-tree detail смотрите: «Root ID», «Bridge ID», «Number of topology changes», last change occurred, role каждого порта (Desg Fwd, Root Fwd, Altn Blk). После обрыва кольца counter topology changes должен увеличиться, blocked port на резервном участке — перейти в forwarding.

MikroTik RouterOS

/interface bridge monitor [find name=bridge1] once
/interface bridge port print detail where bridge=bridge1
/interface bonding print detail
/interface ethernet print stats

/interface bridge monitor в реальном времени показывает role (root/designated/alternate) и state (forwarding/discarding). Для RSTP: /interface bridge set bridge1 protocol-mode=rstp. Edge: point-to-point=yes, bpdu-guard=yes на портах к камерам.

HPE / Aruba (ProCurve, CX)

show trunk
show trunks detail
show spanning-tree detail
show spanning-tree root
show power-over-ethernet brief

show trunk — LACP trunks: порт, type (LACP), status Active/Standby, partner. При отказе линка один trunk member «Down», aggregate остаётся «Up» если второй member active.

Безопасность испытаний и окно обслуживания

Испытания резервирования — контролируемый риск для production-среды. Минимальный регламент для инженера ПНР:

1. Согласование maintenance window — письменно (заявка, email, журнал объекта): дата, время, перечень отключаемых линков, ответственный от заказчика.
2. Уведомление NOC / мониторинга — suppress alert или комментарий «planned maintenance»; иначе SLA реагирования и эскалация ложная.
3. Rollback plan — патч-корды промаркированы, знаете какой вернуть первым; доступ к щиту 220 В и шкафам с ключами.
4. Два человека на объекте при отключении магистральных uplink или питания АПС: один выполняет, второй контролирует ping и связь с диспетчерской.
5. Не каскадировать отказы — один тест за раз; пауза между сценариями; не отключать PSU и uplink одновременно.
6. Out-of-band — консольный доступ (console/IPMI) к core switch на случай потери in-band management.
7. Фиксация «до/после» — конфиг backup, MAC/STP baseline, время начала и окончания окна.

Если заказчик не даёт окно для реального failover — документируйте ограничение: «испытание отложено, проверена только конфигурация STP/LACP и расчёт PSU». Не подменяйте отключение кабеля просмотром конфига — это не испытание резервирования.

Образец записи в протокол ПНР

Фрагмент бланка для включения в общий протокол пусконаладочных работ (адаптируйте под форму заказчика):

Аналогичные блоки оформляют для PSU (с расчётом margin), LACP uplink и переключения контроллера СКУД. Приложения: скрин power consumption, фрагменты CLI, скрин ping с временными метками.

Ложные срабатывания и типовые ошибки

«Failover прошёл» в отчёте часто означает «ничего страшного не случилось», а не «резерв сработал корректно». Распространённые ложные положительные результаты:

Порт не настроен как edge (PortFast)

Камера или ППК подключены к порту без edge — при любом topology change порт 15 с в learning. Ping «ожил» через 20 с — инженер списывает на «медленное кольцо», хотя кольцо converged за 2 с, а access-port — bottleneck. Исправление: spanning-tree portfast / edge на всех access; проверка show spanning-tree interface — Edge: Yes.

BPDU Guard отключён на edge

Без BPDU Guard случайное подключение дешёвого mini-switch «под камеру» создаёт петлю. STP блокирует uplink кольца — «резерв сработал», но причина — нарушение политики, не обрыв магистрали. На ПНР: BPDU Guard enabled на edge; тест — подключить тестовый switch, порт должен уйти в errdisable, не положить кольцо.

Другие ловушки

• Отключили не тот линк — backup уже был active из-за прошлого errdisable; тест «отключил standby» — ложный pass.
• Кольцо физически «шина» — один коммутатор не в кольце, резервного пути нет; ping идёт через единственный uplink.
• LACP passive на обоих — bundle up после reboot по таймингу; при отказе member не пересобирается.
• Dual PSU в одну розетку — отключение автомата гасит оба БП; «тест PSU» не проводился.
• STP вместо RSTP — 40 с простоя списаны на «норму» без сверки с 802.1w.
• MST region mismatch — коммутаторы в разных region видят друг друга как одно CST; роли портов не те, что на схеме.
• ИБП без нагрузки — autonomy 2 ч на пустом ИБП; под шлейфами АПС — 20 мин.

Чек-лист сдачи резервирования

• ☐ Таблица типов резервирования на объекте (PSU, ring, uplink, controller) — заполнена;
• ☐ Расчёт P_total, margin ≥30 %, P_rated ≥ 1,3×P_total для каждого dual PSU;
• ☐ RSTP/MSTP: root bridge назначен; edge + BPDU Guard на access;
• ☐ Кольцо: t_failover измерен секундомером + ping, ≤ проектного (1–6 с для 802.1w);
• ☐ Dual uplink LACP: оба member (P); тест отказа member — bundle Up;
• ☐ Active-standby uplink: blocked порт документирован; switchover по времени;
• ☐ АПС/СКУД: раздельные автоматы; тест основной/резерв 220 В; autonomy ИБП;
• ☐ CLI baseline и post-failover приложены к протоколу;
• ☐ Maintenance window и уведомление NOC задокументированы;
• ☐ Ложные сценарии (edge, BPDU, одна розетка на оба PSU) проверены и исключены.

См. также на PNR24: статьи по PoE-бюджету (нагрузка на PSU коммутатора), Modbus/BACnet (восстановление полевых шин после сетевого failover) и заземлению слаботочных систем.