10fb7f4e18
- Раздел 22: Балансировщик: мониторинг и диагностика - Раздел 23: Распознавание протоколов (DPI Engine) - Раздел 24: Траблшутинг Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.
263 lines
21 KiB
Markdown
263 lines
21 KiB
Markdown
# 22. Балансировщик: мониторинг и диагностика
|
||
|
||
[← Оглавление](../README.md) · [← Раздел 21: Балансировщик: конфигурация](21.md)
|
||
|
||
---
|
||
|
||
Балансировщик предоставляет набор команд для мониторинга аппаратного состояния, проверки прошивок, диагностики портов, анализа правил фильтрации и контроля групп балансировки. Все команды мониторинга выполняются в **операционном режиме**.
|
||
|
||
## 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](20.md)).
|
||
|
||
## 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` выводит полную информацию о состоянии прошивок:
|
||
|
||
```text
|
||
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](21.md)).
|
||
|
||
Для сброса счётчика используется команда `call rdp firmware reset-tries`.
|
||
|
||
## 22.4. Состояние портов и трансиверов: SFP-информация, DDM, статистика фреймов
|
||
|
||
### Информация о трансиверах
|
||
|
||
Для каждого порта можно вывести информацию об установленном трансивере:
|
||
|
||
```text
|
||
show port <имя_порта> sfp
|
||
```
|
||
|
||
В выводе отображаются **все четыре линии** (lane) физического порта, даже если задействованы не все. Для каждой линии показаны:
|
||
|
||
| Параметр | Описание |
|
||
| ------------------------- | ---------------------------------------------------------- |
|
||
| **Тип трансивера** | Оптика, DAC (медный кабель прямого подключения) и т.д. |
|
||
| **Справочная информация** | Производитель, модель, серийный номер SFP |
|
||
| **Уровень сигнала (DDM)** | Мощность в децибелах (только для оптических трансиверов) |
|
||
|
||
> **Примечание:** для медных DAC-кабелей (гидр) уровень сигнала **не отображается**, так как DDM-мониторинг применяется только к оптике. Если установлена оптическая гидра — значения мощности будут видны для каждой линии.
|
||
|
||
### Подробная статистика порта
|
||
|
||
Для каждого порта доступна детальная статистика на уровне фреймов:
|
||
|
||
```text
|
||
show port <имя_порта> statistics
|
||
```
|
||
|
||
Вывод содержит подробную информацию:
|
||
|
||
- Количество полученных и отправленных фреймов;
|
||
- Фреймы с ошибками;
|
||
- Распределение по размерам фреймов;
|
||
- Счётчики различных типов ошибок.
|
||
|
||
Эта статистика полезна при диагностике проблем с физическим подключением — ошибки на уровне фреймов могут указывать на проблемы с кабелями, трансиверами или несовместимость оборудования.
|
||
|
||
## 22.5. Статистика правил фильтрации: счётчики пакетов/байт по каждому flow
|
||
|
||
По каждому правилу фильтрации (flow rule) балансировщик ведёт **счётчики пакетов и байт**, прошедших через данное правило:
|
||
|
||
```text
|
||
show filters <имя_фильтра> flows <имя_правила>
|
||
```
|
||
|
||
В выводе отображается поле **statistics** с количеством пакетов и байт, которые были заматчены данным правилом.
|
||
|
||
### Применение для диагностики
|
||
|
||
Статистика правил — мощный инструмент диагностики. Типовые сценарии:
|
||
|
||
**Сценарий 1: Проверка наличия трафика**
|
||
|
||
Если оператор сообщает, что трафик определённого VLAN проходит через площадку, можно убедиться в этом по счётчикам соответствующего правила. Если счётчики растут — трафик действительно проходит через балансировщик.
|
||
|
||
**Сценарий 2: Исключение ТСПУ как причины проблемы**
|
||
|
||
Для диагностики можно создать **временное правило** с высоким приоритетом, которое матчит проблемный трафик (например, конкретный VLAN) и выполняет action `bypass`:
|
||
|
||
```text
|
||
1. Создать правило: match VLAN <номер>, action bypass, высокий приоритет
|
||
2. Применить конфигурацию (apply)
|
||
3. Проверить: изменилось ли поведение трафика?
|
||
4. Проверить счётчики правила: трафик проходит?
|
||
```
|
||
|
||
Если после создания bypass-правила проблема исчезла — причина в обработке на фильтрах, и нужно диагностировать дальше. Если проблема осталась, а счётчики показывают, что трафик проходит через правило — ТСПУ не является причиной.
|
||
|
||
> **Важно:** после завершения диагностики не забудьте **удалить временное правило** и применить конфигурацию.
|
||
|
||
## 22.6. Состояние группы балансировки
|
||
|
||
Команда для просмотра состояния группы балансировки:
|
||
|
||
```text
|
||
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 пакета через фильтр:
|
||
|
||
```text
|
||
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), так и **вручную**:
|
||
|
||
```text
|
||
call balance-group <имя_группы> software-bypass <режим>
|
||
```
|
||
|
||
| Режим | Описание |
|
||
| ------------ | ------------------------------------------------------------------- |
|
||
| **bypass** | Принудительно перевести группу в режим программного bypass |
|
||
| **primary** | Вернуть группу в нормальный режим работы (трафик на фильтры) |
|
||
|
||
### Индивидуальный bypass для каждой filter group
|
||
|
||
Ключевое преимущество программного bypass — его **гранулярность**. Bypass включается **индивидуально для каждой filter group**, а не для всей группы балансировки целиком:
|
||
|
||
```text
|
||
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 генерируется и проверяется самим байпасом.
|
||
|
||
---
|
||
|
||
[← Оглавление](../README.md) · [← Раздел 21: Балансировщик: конфигурация](21.md) · [Раздел 23: Распознавание протоколов (DPI Engine) →](23.md)
|