Добавлены новые разделы:
- Раздел 22: Балансировщик: мониторинг и диагностика - Раздел 23: Распознавание протоколов (DPI Engine) - Раздел 24: Траблшутинг Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.
This commit is contained in:
Daniel Lavrushin
262
chapters/22.md
Normal file
262
chapters/22.md
Normal file
@@ -0,0 +1,262 @@
|
||||
# 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)
|
||||
Reference in New Issue
Block a user