SYSADMIN.KG

Автор: chyngyz.aliev

  • 25 Гбит/с превращаются… в тыкву? История одного траблшутинга на кластере HPE

    Дано: Новенький кластер HPE. Физические хосты с сетевыми картами 25 Гбит/с. Виртуальные машины с адаптерами VMXNET3, подключенные через Distributed Switch (vDS).
    Проблема: При проверке скорости между ВМ утилита iperf3 показывает унылые 900 Мбит/с(??).
    Задача: Понять, куда делись остальные 24 гигабита, и почему скорость ниже, чем на домашнем роутере.

    Задача выглядела нетривиально, так как на соседнем кластере (Cisco HX) всё летало «из коробки». В следствии проверок мы прошли все стадии принятия и не малое количество процедур от проверки драйверов до глобальной перестройки сети, и вот как это было.

    Этап 1: Проверка базовой гигиены на уровне железяк (ОС и Драйверы).
    Первым делом исключил классику: старые драйверы и однопоточность
    Проверка адаптера: На ВМ установлен корректный VMXNET3, VMware Tools свежие..
    Многопоточный тест: Запустили iperf в 8 потоков, чтобы исключить упор в одно ядро CPU.

    iperf3.exe -c 10.10.10.111 -P 8

    Результат:
    – Sender: ~2.5 Гбит/с
    – Receiver: ~80 Мбит/с (!!!)

    Катастрофическая разница. Приемник буквально “захлебывался” пакетами. Появилось подозрение на RSS (Receive Side Scaling) — технологию, которая паралелит обработку трафика по ядрам проца.

    Проверили RSS в PowerShell:

    Get-NetAdapterRss

    Получил стандартный вывод: RSS включен, очереди распределены по ядрам. Настройки ОС в норме.

    Этап 2: Танцы с бубном (RSC и Interrupt Moderation)
    В Windows Server (2019/2022) есть функция RSC (Receive Segment Coalescing). На быстрых картах она часто конфликтует с драйверами VMware, вызывая дропы пакетов.

    Отключил RSC:

    Disable-NetAdapterRsc -Name "Ethernet*" #Тут имя вашего адаптера

    Скорость на приеме выровнялась с отправкой, но общий потолок остался на уровне ~2–2.5 Гбит/с. Провалы исчезли, но скорости нет.

    Тогда попробовал отключить модерацию прерываний (Interrupt Moderation) в свойствах сетевой карты. Это заставляет CPU обрабатывать каждый пакет мгновенно.
    Эффект: Стабильность повысилась, но скорость не выросла.

    Этап 3: Момент хуистины (UDP тест)
    Чтобы понять, виноват ли протокол TCP (окна, задержки) или сама «труба» (сеть), запустил UDP-тест. UDP — протокол “глупый“

    iperf3.exe -c 10.10.10.111 -u -b 5G

    Ровная полка в 1 Гбит/с. И это как раз тот момент когда начинаю что то понимать, ведь, если даже UDP упирается в гигабит, значит, где-то стоит жесткое ограничение.

    Го искать? Го!:

    Network I/O Control (NIOC) на vDS: Лимитов нет (Unlimited), Shares High.Traffic Shaping: Выключен.

    Локальный vSwitch: Создал отдельный стандартный свитч, чтобы исключить баги Distributed Switch. Результат тот же.

    Этап 4: Нахожу слона в комнате виновника (MTU)
    Сравнил проблемный кластер HPE с работающим Cisco HX. Главное отличие: на Cisco используются кастомные карты с мощным Hardware Offload, а на HPE — стандартные адаптеры.

    При стандартном размере пакета MTU 1500 байт, чтобы прокачать 10 Гбит/с, процессору нужно обработать около 800 000 пакетов в секунду. В виртуальной среде накладные расходы слишком велики, и сеть просто упиралась в производительность CPU на обработку прерываний.

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

    ping -f -l 8972 10.10.10.111

    Ответ: Packet needs to be fragmented.

    Сеть физически не пропускала большие пакеты. Тупо уперлись в “софтовый потолок” ~3 Гбит/с для стандартного фрейма.

    Решение: Переход на Jumbo Frames (MTU 9000)
    Чтобы получить скорость, нужно уменьшить количество пакетов, увеличив их размер. Реализовал план Swing-миграции, чтобы не уронить прод (изменение MTU на vDS “на живую” может положить сеть):

    Подготовка: Вывел один физический аплинк из старого vDS.

    Физика: Сетевые инженеры перенастроили порт свитча на MTU 9000.

    Новый vDS: Создали новый Distributed Switch сразу с MTU 9000 и добавили туда освобожденный аплинк.

    ВМ: Переключил тестовые машины в новый vDS и включил Jumbo Packet: 9000 в свойствах адаптера VMXNET3 внутри Windows.

    Контрольный выстрел:

    ping -f -l 8900 10.10.10.111
Reply from 10.10.10.111: bytes=8900 time=1ms…

    Пинг прошел! Путь чист.

    Финал: Замер скорости
    Запускаю iperf на новой конфигурации:

    iperf3.exe -c 10.10.10.111 -w 4M -P 8 -b 10G


    Результат:

    [SUM] 0.00-10.00 sec 7.64 GBytes 6.56 Gbits/sec sender
[SUM] 0.00-10.00 sec 7.56 GBytes 6.50 Gbits/sec receiver

    Итог: Получаем рост производительности более чем в 2.5 раза (с 2.5 до 6.5+ Гбит/с) и абсолютно стабильный поток данных.

    Выводы
    MTU 1500 — это узкое горлышко для сетей 10/25 Гбит/с в виртуальной среде. Процессор просто не успевает обрабатывать заголовки.

    TCP лжет: Если скорость скачет или падает в ноль, проверяйте UDP. Если там «полка» — ищите лимиты в конфигурации.

    Swing-миграция — лучший способ внедрять изменения в сети без простоя. Строим новый «мост» рядом, переводим трафик, сносим старый. Но все же не забываем правило: Read-Only Friday.

  • Интернет по талонам: Как мы раздавали Chrome через RemoteApp на 200 пользователей.

    «Дайте интернет, но чтобы безопасно и что бы было вчера готово!»
    В любой компании наступает момент, когда безопасность говорит: «Хватит». Хватит пускать пользователей в интернет с их рабочих станций, где лежит бухгалтерия, документы и доступы к базам.
    Задача прилетела мега-классическая: нужно обеспечить доступ к внешним веб-ресурсам для 200 сотрудников, но изолировать этот процесс от внутренней сети. Вариантов было немного:

    • Поставить каждому второй ПК (дорого, супер-тупо, стол как и бюджет, не резиновый).
    • VDI (VDI на 200 персон ради браузера? Оверкилл).
    • Обскурные решения которыми заполнены просторы интернетов.
    • Terminal Server (RDS) + RemoteApp. Наш выбор.

    Почему «по талонам»? Потому что Chrome — это уже давно не браузер. Это операционная система, которая преиодически показывает сайты. И если дать ей волю на терминальном сервере, она съест всю оперативку, закусит процессором и попросит добавки.

    Архитектура: Строим “загон” для Хрома. Мы не стали изобретать велосипед и развернули классическую ферму на базе Windows Server 2022.
    Connection Broker: Мозг операции, балансирует нагрузку.
    Session Hosts: Рабочие лошадки, где, собственно, и крутится Chrome.
    СХД: Профили пользователей (об этом ниже).

    Спойлер

    @Тут я хотел бы вставить скриншот из диспетчера серверов со списком хостов но ИБ строго сказала “А-та-та так делать!”.@

    Битва за ресурсы: Chrome vs RAM Главный враг терминального сервера — это современный веб. Один открытый YouTube в 4K может положить сессию целого отдела. Что мы сделали, чтобы сервер не умер в первый же день:
    GPO для Chrome — наше всё. Мы использовали официальные ADMX-шаблоны от Google.
    Отключение аппаратного ускорения. В виртуалке без vGPU оно только мешает, создавая лишнюю нагрузку на CPU.
    Блокировщик рекламы (uBlock Origin). Это не вопрос комфорта, это вопрос выживания. Баннеры и трекеры жрут трафик и ресурсы процессора. Мы внедрили расширение принудительно через политики.
    Управление вкладками. Расширения типа The Great Suspender помогают выгружать неактивные вкладки из памяти.
    Боль с кэшем. Хранить профили локально на хостах в ферме нельзя — юзера каждый раз может кинуть на новый сервер. Roaming Profiles — медленно. Мы остановились FSLogix.

    Тут же первая проблема: Кэш Хрома растет бесконечно. За месяц профиль может раздуться до 5–10 ГБ.
    Быстрофикс который стал постоянным решением: Настроили политику очистки кэша при выходе или перенаправили папку кэша в temp, который чистится. «Интернет по талонам» не предполагает хранения истории мемов за пять лет.

    Безопасность: RemoteApp создает иллюзию, что приложение работает локально. Но мы-то знаем, что юзверь находится внутри сервера. Чтобы любопытные пользователи не начали изучать файловую систему сервера через «Сохранить как…»:

    Скрытие дисков: Через GPO скрыли диски C: и D: сервера.
    AppLocker: Разрешен запуск только chrome.exe. Даже если они умудрятся скачать “super_game.exe”, запустить они его не смогут.
    Буфер обмена: Ограничили копирование файлов между сессией и локальным ПК, чтобы исключить утечку документов.

    Факапы и выводы Конечно, без приключений не обошлось.

    В первый день забыли настроить таймауты, и «висячие» сессии съели все лицензии. Настроили – радуемся.

    Кто-то нашел сайт, который майнит крипту в браузере, и один хост ушел в 100% CPU. настроили аллертинг и заодно обновили black-list.

    Итог: Ферма живет, 200 пользователей ходят в интернет, внутренняя сеть в безопасности. Нагрузка на техподдержку снизилась: если у юзера «глючит интернет», мы просто сбрасываем его сессию, а не чистим всякое на его компьютере. Хотя все же мне кажется что наиболее лучшим решением мог быть дополнительный слой защиты в виде разнообразные NGFW, HP Wolf Security, RBI и иже с ними, но это уже совсем другая история…

  • Шрамы в инфраструктуре: что скрывают имена виртуальных машин

    Недавно ко мне подошёл младший коллега и спросил:

    «Почему у некоторых виртуальных машин в имени приписка _rest или _restored?»

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

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

    На пример:

    Однажды мы потеряли SRV-DC01 — контроллер домена, который на тот момент был PDC. Причиной стала банальная проблема — datastore переполнился, потому что старые снепшоты не удалялись корректно. В итоге машина «упала», и пришлось срочно поднимать восстановленную копию. Мы добавили суффикс _rest, чтобы сразу видеть, что это новая инстанция, и не путать с оригиналом в документации и системах мониторинга.

    Другой случай — SRV-CRM24_restored. Сервер с CRM-системой упал после неудачного обновления. В тот раз решение внедряли в спешке, и обкатку в тестовой среде посчитали «лишней тратой времени». Клиенты начали жаловаться через 10 минут после начала сбоя. DR-план сработал, но осадок остался. Суффикс — напоминание о спешке, которой могло бы не быть.

    Или один из болезненных случаев — это потеря целого веб-сервиса из 8-ми узлов. Все восемь машин находились на одном и том же датасторе. Из-за физической проблемы с хранилищем мы потеряли всё: веб-серверы, базу данных, кэш, оркестратор. Восстановление заняло 12 часов а данные откатились на сутки. После этого мы пересмотрели подход к размещению и развёртыванию: теперь подобные системы распределены по нескольким хранилищам, а критичные данные дублируются по уровням.

    Да, менять имя виртуальной машины в vCenter — не лучшая практика. Это может нарушить скрипты, автоматизацию, документацию. Но в таких случаях это осознанное решение. Это не про эстетику, а про историю инцидентов, которые нельзя забывать. Эти «шрамы» служат не только напоминанием мне, но и важным сигналом для других коллег: здесь когда-то было больно.

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

  • SureBackup: как убедиться, что ваши бекапы действительно работают

    Создание бекапа — это только половина дела. Гораздо важнее быть уверенным, что в момент аварии данные можно будет восстановить быстро и без ошибок. В моей практике уже были случаи когда бекапы оказались “непригодными”, и это привело к не очень приятным последствиям. Именно для этого Veeam Backup & Replication имеет технологию SureBackup, которая автоматически проверяет работоспособность виртуальных машин в бекапах, при этом делая это безопасно, изолировано и с огромной кучей автоматизации.

    И как же работает SureBackup?

    SureBackup выполняет автоматизированное тестирование бекапов, запуская виртуальные машины в изолированной среде (без влияния на рабочую инфраструктуру). Процесс включает:

    1. Виртуальная лаборатория – изолированная сеть, где разворачиваются ВМ из бэкапа. Причем это выглядит как ВМ которая выступает в качестве прокси для сетевых взаимодействий со своими тестовыми VLAN-ми.
    2. Проверка загрузки ОС – SureBackup убеждается, что машина запускается без ошибок.
    3. Проверка сервисов и приложений – с помощью скриптов или ping-тестов можно удостовериться, что критичные службы (например, SQL, Active Directory) работают корректно и что самое интересное, в зависимости от скриптов pre или post job модно получить огромный комплекс данных вплоть до самых тонких метрик.

    Практическое применение SureBackup

    1. Настройка виртуальной лаборатории

    Перед использованием SureBackup необходимо создать Virtual Lab в Veeam:

    • Указать ESXi-хосты для развертывания тестовых ВМ.
    • Настроить изолированную сеть (например, через vSwitch).
    • Добавить прокси-приложение, если требуется проверка внутренних сервисов (например, веб-сайтов).

    2. Создание задания SureBackup

    • Выбрать бекапы для тестирования.
    • Задать правила проверки (например, «ждать успешного ответа от службы RDP»).
    • Настроить расписание (рекомендуется запускать тесты еженедельно).

    3. Автоматизация отчетов

    Veeam отправляет уведомления о результатах тестов. Если ВМ не загружается, администратор получит алерт до того, как произойдет реальный инцидент.

    Вывод: почему SureBackup — это маст-хэв?

    • Исключает «фантомные» бекапы, которые невозможно восстановить.
    • Экономит время – вместо ручного тестирования всё проверяется автоматически.
    • Соответствует стандартам (например, фин.регуляторы, ISO 27001 и CIS-20 требуют регулярной проверки резервных копий).

    Учитесь на чужих ошибках: Не ограничивайтесь проверкой только “важных” ВМ. Лучше тестировать всё если на то есть возможность, потому что даже файловый сервер может оказаться критичным при аварии а за сломанный бекап виноватым будет кто?

    SureBackup — это не просто инструмент, а страховка от возможной катастрофы. Настройте его один раз, и вы будете чуть менее тревожны за инфру.

    Целостных бекапов и спокойных снов ребята!

  • Немного про ГКС.

    Недавно гиперконвергентные кластеры (ГКС) стали популярны для построения IT-инфраструктуры. Причина в том, что их легко развернуть и можно сэкономить на старте. Но по моему опыту, такой подход не идеален. Хочу объяснить, почему я выбрал классический кластер с внешней системой хранения данных (СХД).

    Первое – цена. Сначала ГКС кажется выгодным, особенно для малого и среднего бизнеса с небольшим бюджетом. Развернуть просто, и не нужно покупать отдельную СХД, что экономит время и деньги. Но эта экономия быстро исчезает, когда нужно увеличить кластер, особенно хранилище. Например, чтобы добавить узел, придётся покупать не только диски, но и модули с ресурсами, памятью и лицензиями. Это дорого.

    Второй важный момент – производительность гиперконвергентных систем. Сначала ГКС работает быстро, потому что вычислительные мощности и хранилище объединены. Но когда нагрузка растёт, особенно если ресурсы используются для виртуализации и хранения, производительность падает. У меня, когда одновременно выполнялись задачи резервного копирования и миграции виртуальных машин, появились задержки и система работала медленно. С отдельной СХД такого не было.

    Что касается отказоустойчивости, то гиперконвергентные системы не сильно лучше классических. Производители обещают надёжность за счёт репликации и распределения данных. Но при поломке узла, восстановление данных и перераспределение нагрузки занимает много времени, и система работает медленнее. В классическом кластере с СХД можно быстро заменить сервер без проблем для инфраструктуры.

    Но ГКС могут подойти для некоторых задач. Небольшие компании, которым не нужен большой рост и у которых стабильный объём данных, могут сократить расходы на администрирование и упростить управление инфраструктурой. Ещё ГКС подходят для удалённых офисов, где не нужно часто масштабироваться.

    В итоге, для меня классический кластер с отдельной системой хранения данных – более логичное и понятное решение. С ним производительность более предсказуемая, и его легко масштабировать. Но выбор всегда за вами.

    Эта статья – моё личное мнение.