tspu-docs/chapters/22.md

22. Балансировщик: мониторинг и диагностика

← Оглавление · ← Раздел 21: Балансировщик: конфигурация

---

Балансировщик предоставляет набор команд для мониторинга аппаратного состояния, проверки прошивок, диагностики портов, анализа правил фильтрации и контроля групп балансировки. Все команды мониторинга выполняются в операционном режиме.

22.1. show hardware info — CPU, память, вентиляторы, БП, температура

Команда show hardware info с различными ключевыми словами отображает состояние аппаратных компонентов балансировщика:

Команда	Описание
show hardware info cpu	Нагрузка на процессор (микросервер)
show hardware info memory	Состояние оперативной памяти
show hardware info fans	Состояние вентиляторов
show hardware info power	Состояние блоков питания
show hardware info temperature	Показания температурных датчиков
show hardware info all	Вся информация по всем компонентам

Для быстрой проверки общего состояния платформы удобно использовать show hardware info all — команда выводит полную картину по всем аппаратным подсистемам.

Практический случай: именно через мониторинг температурных датчиков была выявлена проблема с зависаниями балансировщиков весной — BMC некорректно считывал показания датчика, ошибочно определял перегрев и выключал микросервер (подробнее — в разделе 20.4.3).

22.2. show mng if — management-интерфейс

Команда show mng if отображает текущее состояние management-интерфейса:

• IP-адрес;
• Маска подсети;
• Default gateway;
• Состояние интерфейса (up/down).

Команда полезна для быстрой проверки параметров управления после настройки или перезагрузки устройства.

22.3. show rdp firmware version — версии прошивок, tries

Команда show rdp firmware version выводит полную информацию о состоянии прошивок:

    Current active firmware: A

    Partition A:
      Status:  active
      Version: 2.4.1
      Tries:   0

    Partition B:
      Status:  inactive
      Version: 2.3.8
      Tries:   0

Параметр	Описание
Current active	Какой раздел (A или B) является текущим активным
Status	active или inactive для каждого раздела
Version	Номер версии прошивки в разделе
Tries	Счётчик попыток загрузки с данного раздела

Параметр Tries

В нормальном состоянии Tries = 0. Ненулевое значение означает, что балансировщик предпринимал неудачные попытки загрузки с этого раздела.

Если балансировщик более 3 раз подряд за ~20 минут не смог загрузиться с определённого раздела, прошивка считается ненадёжной и происходит автоматический rollback на другой раздел (подробнее — в разделе 21.2.1).

Для сброса счётчика используется команда call rdp firmware reset-tries.

22.4. Состояние портов и трансиверов: SFP-информация, DDM, статистика фреймов

Информация о трансиверах

Для каждого порта можно вывести информацию об установленном трансивере:

    show port <имя_порта> sfp

В выводе отображаются все четыре линии (lane) физического порта, даже если задействованы не все. Для каждой линии показаны:

Параметр	Описание
Тип трансивера	Оптика, DAC (медный кабель прямого подключения) и т.д.
Справочная информация	Производитель, модель, серийный номер SFP
Уровень сигнала (DDM)	Мощность в децибелах (только для оптических трансиверов)

Примечание: для медных DAC-кабелей (гидр) уровень сигнала не отображается, так как DDM-мониторинг применяется только к оптике. Если установлена оптическая гидра — значения мощности будут видны для каждой линии.

Подробная статистика порта

Для каждого порта доступна детальная статистика на уровне фреймов:

    show port <имя_порта> statistics

Вывод содержит подробную информацию:

• Количество полученных и отправленных фреймов;
• Фреймы с ошибками;
• Распределение по размерам фреймов;
• Счётчики различных типов ошибок.

Эта статистика полезна при диагностике проблем с физическим подключением — ошибки на уровне фреймов могут указывать на проблемы с кабелями, трансиверами или несовместимость оборудования.

22.5. Статистика правил фильтрации: счётчики пакетов/байт по каждому flow

По каждому правилу фильтрации (flow rule) балансировщик ведёт счётчики пакетов и байт, прошедших через данное правило:

    show filters <имя_фильтра> flows <имя_правила>

В выводе отображается поле statistics с количеством пакетов и байт, которые были заматчены данным правилом.

Применение для диагностики

Статистика правил — мощный инструмент диагностики. Типовые сценарии:

Сценарий 1: Проверка наличия трафика

Если оператор сообщает, что трафик определённого VLAN проходит через площадку, можно убедиться в этом по счётчикам соответствующего правила. Если счётчики растут — трафик действительно проходит через балансировщик.

Сценарий 2: Исключение ТСПУ как причины проблемы

Для диагностики можно создать временное правило с высоким приоритетом, которое матчит проблемный трафик (например, конкретный VLAN) и выполняет action bypass:

    1. Создать правило: match VLAN <номер>, action bypass, высокий приоритет
    2. Применить конфигурацию (apply)
    3. Проверить: изменилось ли поведение трафика?
    4. Проверить счётчики правила: трафик проходит?

Если после создания bypass-правила проблема исчезла — причина в обработке на фильтрах, и нужно диагностировать дальше. Если проблема осталась, а счётчики показывают, что трафик проходит через правило — ТСПУ не является причиной.

Важно: после завершения диагностики не забудьте удалить временное правило и применить конфигурацию.

22.6. Состояние группы балансировки

Команда для просмотра состояния группы балансировки:

    show balance-group <имя_группы>

Вывод показывает общее состояние группы и статус каждой filter group внутри неё.

22.6.1. Статус filter groups: up/bypass

Каждая filter group (пара портов в сторону фильтра) может находиться в одном из двух состояний:

Состояние	Описание
up	Пара портов активна, трафик отправляется на фильтр
bypass	Пара портов в режиме программного bypass — трафик перекладывается из LAN в WAN и наоборот, не отправляясь на фильтр

В нормальном рабочем состоянии все filter groups должны находиться в состоянии up.

Переход в bypass происходит автоматически при потере заданного количества последовательных keep-alive пакетов (по умолчанию — 5). Обратный переход в up также автоматический — при получении достаточного количества ответных keep-alive пакетов.

22.6.2. Time of pass — время прохождения keep-alive пакета

Внутри каждой filter group отображается параметр time of pass — время прохождения keep-alive пакета через фильтр:

    Filter Group fg1:
      Status:        up
      Time of pass:  27000 ns

Параметр	Описание
Time of pass	Время (в наносекундах) между отправкой keep-alive пакета в LAN-порт и получением его из парного WAN-порта
Time of receipt	Внутренний timestamp — привязан к внутреннему счётчику, практической ценности для эксплуатации не имеет

Механизм измерения:

1. Балансировщик отправляет keep-alive пакет в LAN-порт filter group;
2. Пакет проходит через фильтр (прозрачно, минуя DPI);
3. Балансировщик получает пакет из WAN-порта той же filter group;
4. Фиксируется разница во времени — это и есть time of pass.

В нормальном состоянии time of pass составляет порядка 20–30 микросекунд (20 000–30 000 наносекунд).

Важно: балансировщик ничего не знает о работе DPI на фильтрах. Keep-alive пакеты проходят через фильтр прозрачно, без обработки движком DPI. Параметр time of pass отражает исключительно время прохождения пакета через аппаратную часть фильтра.

Если пакеты начинают теряться — time of pass резко возрастает. После потери 5 последовательных keep-alive пакетов filter group переводится в состояние bypass.

Влияние загрузки фильтра на keep-alive

При высокой загрузке таблиц сессий фильтра (значительно выше рекомендованных 20%) фильтр может начать медленнее обрабатывать трафик и дропать пакеты, в том числе keep-alive. Это может привести к «флапингу» filter group — циклическому переключению между up и bypass.

В такой ситуации оператор не почувствует флапов на физических линках (программный bypass не затрагивает физику), но:

• Небольшое количество пакетов может теряться при каждом переключении;
• Часть трафика временно не фильтруется.

Система мониторинга должна отслеживать загрузку таблиц на фильтрах и сигнализировать о приближении к пороговым значениям до того, как начнутся проблемы с keep-alive.

22.7. Программный байпас: индивидуально для каждой группы портов

Программный bypass на балансировщике может управляться как автоматически (по результатам keep-alive), так и вручную:

    call balance-group <имя_группы> software-bypass <режим>

Режим	Описание
bypass	Принудительно перевести группу в режим программного bypass
primary	Вернуть группу в нормальный режим работы (трафик на фильтры)

Индивидуальный bypass для каждой filter group

Ключевое преимущество программного bypass — его гранулярность. Bypass включается индивидуально для каждой filter group, а не для всей группы балансировки целиком:

    Filter Group fg1: up        ← трафик идёт на фильтр
    Filter Group fg2: bypass    ← трафик байпасится (проблема с этой парой портов)
    Filter Group fg3: up        ← трафик идёт на фильтр
    Filter Group fg4: up        ← трафик идёт на фильтр

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

Преимущества перед переключением на байпасе

Критерий	Bypass на оптическом байпасе	Программный bypass на балансировщике
Флап линков оператора	Да — при каждом переключении	Нет — физические линки не затрагиваются
Гранулярность	Вся площадка целиком	Каждая пара портов индивидуально
Согласование с оператором	Требуется (работы, окна обслуживания)	Не требуется — оператор ничего не замечает
Последствия	Весь трафик не фильтруется	Не фильтруется только часть трафика

Опыт эксплуатации: такое поведение было опробовано при тестировании эшелонированной системы в Сургуте. Вместо переключения трафика на оптическом байпасе (что вызывает флапы линков и недовольство оператора) использовался программный bypass на балансировщике — одной командой трафик уводился с фильтров без каких-либо видимых последствий для оператора.

Автоматическое восстановление

При автоматическом bypass (по результатам keep-alive):

• Если filter group потеряла keep-alive — автоматически переводится в bypass;
• Когда интерфейс восстанавливается и keep-alive снова проходят — filter group автоматически возвращается в рабочее состояние (up);
• Перебалансировки трафика не происходит (при выключенной перебалансировке) — остальные filter groups продолжают работать без изменений.

Проверка Bypass Watchdog (пилотный проект, Урал)

Для уральского проекта с байпасами GL Sun доступна дополнительная диагностика связи между балансировщиком и байпасом:

Состояние	Описание
active	Группа балансировки активна, heartbeat-пакеты отправляются на байпас, байпас отвечает
disconnected	Группа балансировки неактивна или связь с байпасом потеряна — heartbeat-пакеты не отправляются

Связь с байпасом GL Sun осуществляется по протоколу TCP. При переходе группы балансировки в неактивное состояние отправка heartbeat прекращается.

Примечание: данная диагностика не актуальна для федерального проекта с байпасами Silicom, где heartbeat генерируется и проверяется самим байпасом.

---

← Оглавление · ← Раздел 21: Балансировщик: конфигурация · Раздел 23: Распознавание протоколов (DPI Engine) →