Миграция 80 серверов с CentOS на альтернативный Linux без потери SLA

«СвязьИнфо» — региональный телеком-оператор с абонентской базой в 340 тысяч клиентов. Инфраструктура: 80 серверов на CentOS 7, из которых 24 обслуживают L3/L4 балансировщики нагрузки для маршрутизации VoIP и интернет-трафика, а остальные — биллинг, CRM и внутренние системы.

В июне 2024 года CentOS 7 вышел из поддержки (End of Life). Клиент стоял перед выбором:

После анализа мы рекомендовали Oracle Linux с ядром UEK (Unbreakable Enterprise Kernel) для серверов балансировки трафика и Rocky Linux 9 для остальных. UEK основан на свежем mainline ядре с патчами Oracle для производительности сетевого стека — критично для L3/L4 балансировщиков.

Наша команда: 2 Linux-инженера и 1 сетевой инженер. План — 80 серверов за 12 недель с нулевым даунтаймом для абонентов.

Первые 4 сервера (L3/L4 балансировщики) мы мигрировали за первую неделю. Процедура стандартная: новый сервер с Oracle Linux 7 + UEK 5.4.17, переключение трафика через ECMP, мониторинг 48 часов.

На стресс-тесте с высоким PPS (packets per second) мы обнаружили аномалию: утилизация CPU выросла на ~10% по сравнению с CentOS 7. При пиковой нагрузке в 1.2 млн пакетов/сек это означало переход с 65% до 75% CPU — опасно близко к порогу деградации (80%).

Сравнение конфигураций:

SOFTIRQ — обработка сетевых прерываний — удвоился. Мы поставили миграцию на паузу и начали детальное расследование.

Для диагностики мы использовали набор инструментов ядра Linux и BPF-трассировку. Весь процесс занял 5 рабочих дней.

Шаг 1: Анализ /proc/softirqs

# Сравнение количества SOFTIRQ событий за 10 секунд
# CentOS 7:
watch -n 10 cat /proc/softirqs
#            CPU0       CPU1       ...
# NET_RX:    847231     823445     ...

# Oracle Linux 7:
# NET_RX:    851003     829712     ...
# Количество событий практически одинаковое!

Шаг 2: BCC tools — измерение времени SOFTIRQ

# Замер времени выполнения каждого типа SOFTIRQ за 10 секунд
/usr/share/bcc/tools/softirqs -d 10

# CentOS 7 — CPU 0:
# NET_RX: avg 314us, total 266ms/10s

# Oracle Linux 7 — CPU 0:
# NET_RX: avg 318us, total 271ms/10s

# Время обработки практически идентичное!

Парадокс: количество событий и время обработки одинаковые, но утилизация SOFTIRQ различается вдвое. Значит, проблема не в самой обработке пакетов.

Шаг 3: perf record + FlameGraph

# Сбор stacktrace на конкретном ядре CPU
perf record -C 0 -g -- sleep 10
perf script | stackcollapse-perf.pl | flamegraph.pl > flame_cpu0.svg

FlameGraph подтвердил: функция net_rx_action занимает ~23% времени на обоих системах. Обработка пакетов через vmxnet3_poll_rx_only (DMA-чтение из сетевой карты, бюджет ~2 мс, до 64 пакетов за итерацию) работает одинаково.

На пятый день расследования наш инженер обнаружил ключевое различие в конфигурации ядер.

В ядре Linux функция irqtime_account_process_tick контролируется опцией CONFIG_IRQ_TIME_ACCOUNTING. Эта опция определяет, как ядро подсчитывает время, проведённое в обработке прерываний.

# Проверка конфигурации ядра
# CentOS 7 (4.19.125-1):
grep IRQ_TIME /boot/config-4.19.125-1.el7.x86_64
# CONFIG_IRQ_TIME_ACCOUNTING is not set

# Oracle Linux 7 (5.4.17-2102):
grep IRQ_TIME /boot/config-5.4.17-2102.200.13.el7uek.x86_64
CONFIG_IRQ_TIME_ACCOUNTING=y

Вот разница:

• При CONFIG_IRQ_TIME_ACCOUNTING=n (CentOS) — ядро оценивает SOFTIRQ время по семплам таймера (раз в ~4 мс). Если SOFTIRQ завершается между тиками — его время приписывается user-space или idle
• При CONFIG_IRQ_TIME_ACCOUNTING=y (Oracle Linux) — ядро точно замеряет время каждого входа и выхода из SOFTIRQ обработчика. При возврате из простоя накопленное время корректно распределяется между steal, irq и softirq

Другими словами: Oracle Linux показывает реальное время CPU, проведённое в SOFTIRQ, а CentOS недооценивал его примерно на 50%.

Для окончательного подтверждения гипотезы мы пересобрали ядро Oracle Linux с отключённым CONFIG_IRQ_TIME_ACCOUNTING:

# Получаем исходники ядра UEK
yum install -y kernel-uek-devel-5.4.17-2102.200.13.el7uek
cd /usr/src/kernels/5.4.17-2102.200.13.el7uek.x86_64

# Копируем текущий конфиг и отключаем опцию
cp /boot/config-5.4.17-2102.200.13.el7uek.x86_64 .config
scripts/config --disable CONFIG_IRQ_TIME_ACCOUNTING

# Сборка и установка
make -j$(nproc) && make modules_install && make install
grub2-set-default 0
reboot

Результат после перезагрузки с модифицированным ядром:

С отключённой опцией SOFTIRQ показывает ~14% — практически идентично CentOS. Гипотеза подтверждена: рост утилизации — результат более точного учёта, а не реального снижения производительности.

Мы подготовили bpftrace-скрипт для визуализации SOFTIRQ латентности в реальном времени:

#!/usr/bin/env bpftrace
// softirqlat.bt — замер латентности SOFTIRQ обработчиков
tracepoint:irq:softirq_entry
{
    @start[args->vec] = nsecs;
}

tracepoint:irq:softirq_exit
/@start[args->vec]/
{
    $lat = nsecs - @start[args->vec];
    @latency_us[args->vec] = hist($lat / 1000);
    delete(@start[args->vec]);
}

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

Рабочая нагрузка осталась прежней, но статистика стала точнее. Мы обновили алерты в Zabbix и Grafana для всех мигрированных серверов:

# Старые пороги (CentOS, неточный учёт)
cpu_warning_threshold: 70%
cpu_critical_threshold: 80%
softirq_warning: 20%

# Новые пороги (Oracle Linux, точный учёт)
cpu_warning_threshold: 82%
cpu_critical_threshold: 90%
softirq_warning: 35%

# Добавили метрику реальной пропускной способности
pps_warning_threshold: 1400000  # packets/sec
pps_critical_threshold: 1600000

Ключевое изменение: вместо ориентации только на % CPU мы добавили метрику PPS (packets per second) как прямой индикатор нагрузки. PPS не зависит от метода учёта процессорного времени и точно отражает реальную нагрузку на балансировщик.

Также мы задокументировали различие в учёте CPU для команды мониторинга «СвязьИнфо», чтобы в будущем не возникало ложных тревог.

Убедившись, что производительность не деградировала, мы возобновили миграцию. Процесс для 80 серверов был организован в 4 волны:

• Волна 1 (недели 1-3): 24 L3/L4 балансировщика → Oracle Linux 7 + UEK 5.4
• Волна 2 (недели 4-6): 18 серверов биллинга → Rocky Linux 9
• Волна 3 (недели 7-9): 22 сервера CRM и внутренних систем → Rocky Linux 9
• Волна 4 (недели 10-12): 16 серверов мониторинга, DNS, почты → Rocky Linux 9

Процедура миграции каждого сервера:

# 1. Развёртывание нового сервера с Oracle Linux / Rocky Linux
# 2. Установка идентичного ПО через ansible
ansible-playbook -i inventory/production site.yml --limit new-server-01

# 3. Синхронизация конфигурации
rsync -avz --checksum old-server:/etc/keepalived/ new-server:/etc/keepalived/
rsync -avz --checksum old-server:/etc/sysctl.d/ new-server:/etc/sysctl.d/

# 4. Нагрузочное тестирование в изоляции
iperf3 -c new-server -P 16 -t 300
hping3 --flood -S new-server -p 80

# 5. Переключение трафика через ECMP (50/50)
ip route replace default \
  nexthop via 10.0.1.1 dev eth0 weight 1 \
  nexthop via 10.0.1.2 dev eth0 weight 1

# 6. Мониторинг 48 часов
# 7. Полное переключение
# 8. Вывод старого сервера

Каждая волна проходила по принципу blue-green: новые серверы работали параллельно со старыми, трафик переключался постепенно.

Миграция 80 серверов «СвязьИнфо» завершена за 11 недель (на неделю раньше плана). Ни одной минуты даунтайма для абонентов.

Главный урок этого проекта: рост метрик после миграции — не всегда деградация. Новые ядра Linux более точно измеряют потребление ресурсов. Прежде чем паниковать и откатывать изменения, проведите глубокий анализ с помощью perf, bpftrace и FlameGraph. Подробнее о миграции Linux-инфраструктуры — на itfresh.ru.