«High IO shares allocation» в VCF 9.0: политика на месте, приоритета нет

Два хоста обновили с vSphere 8.0 U3 на 9.0, у ВМ с 1С всё та же политика хранения «High IO shares allocation», Compliance зелёный — а в окне резервного копирования база тормозит так, будто политики нет. Так и есть: название осталось, механизм приоритета убрали. Ниже — точная формулировка Broadcom (что deprecated, а что уже removed), как это выглядит на небольшой площадке, как за час проверить свои ВМ и датасторы и чем реально заменить приоритет ввода-вывода, если у вас не ЦОД, а пара серверов в стойке.

Что именно выключили в VCF 9.0

Формулировки Broadcom стоит читать внимательно, потому что в них три разных статуса. В release notes vCenter 8.0 Update 3 было предупреждение: SDRS I/O Load Balancer, балансировщик по I/O-резервированиям и vSphere Storage I/O Control Components «will be deprecated in a future vSphere release». В VCF 9.0 это уже не deprecation, а удаление: в Product Support Notes для vSphere, раздел End of Support Notes, пункт называется «Removal of Storage DRS Load Balancer and Storage I/O Control (SIOC)» — vCenter 9.0 «discontinues support» этих механизмов, а 8.x и 7.x продолжают их поддерживать. И третий статус — в KB 385396: сами дефолтные компоненты политик SIOC объявлены deprecated и «could be removed in future VCF release», а бэкенд с 9.0 GA поддерживает в SIOC-политике только limits.

Важно понять разницу между тремя вещами, которые в SIOC жили вместе. Shares — это доля при конкуренции: когда на датасторе тесно, машина с высоким весом получает больше очереди, чем машина с низким. Reservation — гарантированный минимум IOPS. Limit — верхний потолок, выше которого ВМ не пустят, даже если массив пустой. Первые две вещи — про справедливость и про защиту важной нагрузки. Третья — про наказание нагрузки неважной. В VCF 9.0 из трёх осталась ровно та, которая ничего не гарантирует.

Отдельная подлость — в именах. Дефолтные Storage Policy Components исторически назывались «High / Normal / Low IO shares allocation» и содержали пару «вес + потолок»: High — шары High и лимит 100 000 IOPS, Normal — Normal и 10 000, Low — Low и 1000. Из этой пары выжила только правая половина. Название осталось прежним, интерфейс рисует знакомый компонент, галка соответствия зелёная — а внутри теперь просто цифра потолка. Broadcom в KB 385396 прямо объясняет, зачем объявил эти компоненты deprecated: их имена больше не отражают того, что они делают, и рекомендует вместо них создавать собственные компоненты с явным лимитом.

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

• «High IO shares allocation» — не приоритет, а потолок 100 000 IOPS. На ВМ небольшой компании он недостижим, то есть фактически не делает ничего.
• «Normal IO shares allocation» — потолок 10 000 IOPS без веса. Для 1С на 25 пользователей обычно не достигается, но и приоритета больше не даёт.
• «Low IO shares allocation» — потолок 1000 IOPS, как и раньше. Изменилось другое: соседи с High больше не получают перед этой ВМ преимущества при заторе.
• Reservations через SPBM в 9.0 не поддерживаются: если вы на них рассчитывали, гарантированного минимума IOPS у ВМ больше нет.

Что ещё поехало вместе с SIOC — и что осталось живым

SIOC-политика — не единственная потеря. По тому же пункту Product Support Notes из vCenter 9.0 убрали балансировщик Storage DRS по вводу-выводу: и вариант по латентности, и вариант по I/O-резервированиям. Там же прямо сказано, что больше не поддерживается включение SIOC на датасторе (enabling of SIOC on a datastore) — той самой галки на уровне хранилища с congestion threshold, которую многие поставили один раз и больше не трогали.

Живым осталось меньше, чем кажется на первый взгляд, но и не пусто. Работает начальное размещение ВМ силами Storage DRS — то есть кластер датасторов по-прежнему подскажет, куда класть новый диск. Работает балансировка по свободному месту: это как раз то, ради чего SDRS чаще всего и включали. И работают лимиты через SPBM — единственный оставшийся рычаг управления вводом-выводом средствами гипервизора.

Сама Product Support Notes замены не предлагает — только фиксирует, что убрано и что осталось. Практическая рекомендация, которую повторяют и KB 385396, и разборы партнёров, — балансировка по месту плюс SPBM-политики с лимитами, а управление производительностью отдать системе хранения, её встроенному QoS. Скажу честно: по сути это правильно, на практике неудобно. У СХД начального уровня, которые стоят у половины наших клиентов, QoS либо нет вообще, либо он живёт на уровне пула, а не отдельного тома — гранулярности «эта ВМ важнее той» там не получить.

Для площадки из одного-двух хостов картина обычно проще, чем для корпоративного кластера. Кластер датасторов со Storage DRS там почти не встречается: датастор один, максимум два, и балансировать нечего. Если хост один и диски локальные, конкуренция всё равно есть — все ВМ делят один RAID-контроллер, — но SIOC на локальном VMFS и раньше мало кто включал. Поэтому для малого бизнеса реальная зона поражения сводится к одному вопросу: висели ли на ваших ВМ дефолтные SIOC-компоненты в расчёте на приоритет.

• Убрано: балансировка Storage DRS по латентности I/O.
• Убрано: балансировка Storage DRS по I/O-резервированиям.
• Убрано: включение SIOC на датасторе (datastore-level SIOC, congestion threshold).
• Убрано: shares и reservations в SPBM-политике SIOC.
• Осталось: начальное размещение SDRS, балансировка по свободному месту, лимиты IOPS через SPBM.

Разбор: «Экспертиза стройки», 25 рабочих мест, 1С просела в окне бэкапа после апгрейда

Условный клиент — строительная консалтинговая компания «Экспертиза стройки»: 25 рабочих мест, инженеры-сметчики и эксперты, бухгалтерия из трёх человек. Инфраструктура типичная для такого размера: два хоста ESXi, общая СХД начального уровня по iSCSI с SSD-кэшем, один VMFS-6 датастор на 4 ТБ и около дюжины ВМ — контроллер домена, 1С:Бухгалтерия и ЗУП на MS SQL, терминальный сервер, файловый сервер с архивом проектной документации (сканы заключений, PDF и DWG) и ВМ резервного копирования. Подписку, дающую право на 9.x, продлили, поэтому решили обновиться с vSphere 8.0 U3 на 9.0 в выходные. Апгрейд прошёл без единой ошибки — и именно поэтому связь с симптомами нашли не сразу.

Симптом всплыл в конце месяца, когда бухгалтерия закрывала период по вечерам. После 19:00 проведение документов в 1С подвисало на 10–30 секунд. В 19:00 стартовало резервное копирование, а файловый сервер параллельно гонял полную антивирусную проверку архива проектов — несколько сотен гигабайт мелких файлов. В esxtop латентность на диске данных SQL выросла с обычных 2–4 мс до 25–35 мс. DAVG при этом рос умеренно, а основную прибавку давал KAVG за счёт QAVG — команды стояли в очереди на хосте, а не тонули в массиве. В самом SQL это выглядело как рост ожиданий PAGEIOLATCH_SH и WRITELOG.

Дальше — самое интересное. Несколько лет назад предыдущий подрядчик повесил на ВМ с SQL компонент «High IO shares allocation», а на файловый сервер — «Normal»: задумка была в том, чтобы при заторе база получала больше очереди. На 8.0 U3 это действительно работало — вечерний скан и бэкап замедлялись, а 1С почти не страдала. После апгрейда веса исчезли: потолки 100 000 и 10 000 IOPS остались, но на такой СХД ни одна ВМ до них не доезжает, то есть фактически обе машины стали равноправными. Файловый сервер с его миллионами мелких чтений просто перетянул очередь на себя.

Что сделали. Первое — завели свои компоненты с числом в имени и сняли дефолтные с обеих ВМ. На SQL — ITF-NOLIMIT-SQL, по сути явная политика «без ограничения», чтобы в отчётах было видно, что машина учтена. Второе — повесили компонент ITF-IOPS-1500 на диск данных файлового сервера: для работы 25 человек с документами этого хватает с запасом, а полный скан просто идёт дольше. Третье — сдвинули полную антивирусную проверку архива на субботнюю ночь, а ежедневный бэкап — на 21:00, после ухода бухгалтерии. Итог замеряли две недели: латентность диска SQL в вечерние часы — 4–6 мс, подвисаний нет, полный скан архива вырос с 3 до 5 часов. Этот размен приняли осознанно: скан терпит, закрытие месяца — нет.

• До: латентность vmdk с данными SQL вечером 25–35 мс, подвисания 1С 10–30 с.
• После: 4–6 мс, подвисаний нет, полный антивирусный скан архива дольше на два часа.
• Ключевая находка: приоритет базы держался только на shares, которых в 9.0 больше нет.
• Потрачено около трёх часов, из них два — на то, чтобы перестать верить зелёному Compliance.
• Лицензии, железо и СХД не менялись: вся правка — два компонента политики и расписание.

Как за час проверить свой кластер

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

Connect-VIServer vcenter.example.local

# все политики хранения и их описания
Get-SpbmStoragePolicy | Select-Object Name, Description | Format-Table -AutoSize

# какая политика на какой ВМ (home-объект)
Get-VM | Get-SpbmEntityConfiguration |
  Where-Object { $_.StoragePolicy -ne $null } |
  Select-Object Entity, StoragePolicy, ComplianceStatus

# то же по отдельным виртуальным дискам — тут чаще всего и прячется потолок
Get-VM | Get-HardDisk | Get-SpbmEntityConfiguration |
  Where-Object { $_.StoragePolicy -ne $null } |
  Select-Object Entity, StoragePolicy

# на каких датасторах был включён SIOC (снимать на 8.x, до апгрейда)
Get-Datastore | Select-Object Name, Type, StorageIOControlEnabled, CongestionThresholdMillisecond

Отдельно проверьте кластеры датасторов: если Storage DRS был включён в режиме с балансировкой по I/O, теперь он балансирует только место, и это надо либо принять, либо перестроить раскладку вручную. И посмотрите, не осталось ли у вас документации или скриптов, которые ставят «Low IO shares allocation» новым ВМ автоматически — такие шаблоны любят жить в чужих раннерах развёртывания годами.

Живой замер делаю через esxtop на хосте: клавиша u — вид по устройствам, v — по дискам виртуальных машин. Смотрю DAVG (задержка массива), KAVG (задержка в ядре гипервизора, в неё входит очередь QAVG) и итоговый GAVG. Если растёт DAVG — упирается СХД, и никакие политики вас не спасут. Если растёт KAVG за счёт QAVG при спокойном DAVG — затор на хосте, и вот тут раньше помогали shares, а теперь помогут только лимиты на соседей или разнесение по датасторам.

На маленькой площадке этот срез укладывается в один экран: десяток ВМ, один-два датастора. Если в выводе нет ни одной политики с именами «IO shares allocation», а на датасторах StorageIOControlEnabled = False — вас удаление SIOC не касается, и тему можно закрыть одной строкой в журнале изменений.

• Найти все ВМ и диски с прикреплёнными SIOC-компонентами.
• Отдельно выписать ВМ, чей приоритет держался на High/shares (в 9.0 его нет), и ВМ с Low (1000 IOPS) — это действующие потолки.
• Проверить режим балансировки в кластерах датасторов.
• Снять esxtop в час пик и в окно бэкапа: DAVG / KAVG / QAVG.
• Проверить шаблоны развёртывания и скрипты на автоматическое навешивание дефолтных компонентов.

Свой компонент политики вместо дефолтных

Broadcom в KB 385396 прямо предлагает не полагаться на дефолтные компоненты, а завести собственные. Путь в интерфейсе: «Policies and Profiles» → «Storage Policy Components» → «Create». Дальше задаёте имя, в категории выбираете «Storage I/O Control», провайдера оставляете «VMware Storage IO Control» и указываете значение IOPS limit — либо одно из привычных дефолтных (1000 / 10 000 / 100 000), либо своё, посчитанное под нагрузку. Созданный компонент потом подключается в правило VM Storage Policy наравне с остальными.

Единственный совет по неймингу, который экономит потом часы: пишите число прямо в имени. ITF-IOPS-1500, ITF-IOPS-5000, ITF-NOLIMIT-SQL. Именно из-за красивых абстрактных имён вроде «High» вся эта история и произошла — через три года никто не помнит, что за ними стоит, а интерфейс подсказки не даёт. Заодно в описании компонента укажите дату и причину: «лимит для файлового сервера, чтобы полный скан архива не топил датастор вечером».

Если нужно прижать не всю ВМ, а один её диск, политика назначается на уровне отдельного виртуального диска: в интерфейсе — Edit VM Storage Policies и переключатель «Configure per disk», в PowerCLI — через Set-SpbmEntityConfiguration на объекте жёсткого диска:

$pol  = Get-SpbmStoragePolicy -Name 'ITF-IOPS-1500'
$disk = Get-HardDisk -VM 'FILE-SRV-01' -Name 'Hard disk 2'
$disk | Set-SpbmEntityConfiguration -StoragePolicy $pol

# проверить, что легло и в каком статусе соответствия
Get-HardDisk -VM 'FILE-SRV-01' | Get-SpbmEntityConfiguration |
  Select-Object Entity, StoragePolicy, ComplianceStatus

Честная оговорка: старые рецепты с прямой правкой расширенных параметров планировщика диска в .vmx я в статью сознательно не включаю — в официальной документации 9.0 опоры для них нет, а поддерживаемый путь для лимитов Broadcom назвал явно: SPBM. Изменение политики я применяю в рабочее время на одной ВМ и сразу смотрю esxtop; если для вас критично, подхватывается ли лимит без перезагрузки, проверьте на тестовой машине своего билда, а не верьте статье. И не держите два источника лимитов на одном диске: следующий админ потратит полдня, выясняя, какой из них действует.

• Категория компонента — «Storage I/O Control», провайдер — «VMware Storage IO Control».
• Единственный настраиваемый параметр, который теперь работает, — IOPS limit.
• Дефолтные значения для ориентира: 1000 / 10 000 / 100 000 IOPS.
• Число выносите в имя компонента, причину — в описание.
• Для точечного случая назначайте компонент на конкретный диск (Configure per disk), а не на всю ВМ.

Чем на самом деле заменить приоритет ввода-вывода

Первое и самое неприятное, что надо принять: прямого эквивалента shares в vSphere 9 нет. Приоритет — это про «поделить дефицит справедливо», а инструментов дележа у гипервизора больше не осталось. Значит, работать надо не с дележом дефицита, а с его отсутствием. Три рабочих способа, в порядке моей личной надёжности.

Способ первый и лучший — физическое разнесение. Боевая база на своём датасторе, на своём LUN, желательно на своём пуле дисков — и никакие политики ей больше не нужны. Это звучит скучно и старомодно, зато не ломается при апгрейдах, не зависит от решений вендора и понятно любому админу, который придёт после вас. У «Экспертизы стройки» это стоит следующим этапом: под SQL выделяем отдельный небольшой том на SSD-полке, а архив проектной документации оставляем на общем датасторе.

Способ второй — QoS на массиве. То, что рекомендует сам Broadcom. Если у вас СХД среднего класса с QoS на уровне тома, это правильное место для политики производительности: массив видит реальную загрузку и не теряет настройки при обновлении гипервизора. Если QoS только на уровне пула — толку немного, честно скажите себе об этом и идите к способу первому или третьему.

Способ третий — лимиты на шумных соседей. Не на важные ВМ, а именно на источники шума: файловые серверы с полными антивирусными проверками и индексацией, машины разработки и тестирования, всё, что раз в сутки устраивает шторм. Это единственное, что осталось от SIOC, и в такой роли оно работает нормально. Плюс банальное разведение окон по времени: бэкап, реиндекс, обновление баз и антивирусный скан не должны стартовать в один час. Отдельно для vSAN (на двух хостах это конфигурация с witness): там в политике есть своё правило «IOPS limit for object»; в пункте Product Support Notes про удаление SIOC оно не упоминается, но после апгрейда проверьте его поведение на своём билде.

• Разнести боевую нагрузку по отдельным датасторам и LUN — самый надёжный «приоритет» в 2026 году.
• Включить QoS на СХД, если он есть на уровне тома.
• Лимиты IOPS — только на шумных соседей, не на боевые ВМ.
• Развести по времени бэкап, реиндекс, обновления и антивирусный скан.
• Для vSAN использовать правило «IOPS limit for object» в политике vSAN и проверить его после апгрейда.

Порядок действий и на что можно забить

Если вы ещё на 8.0 U3 — снимите срез политик и датасторов до апгрейда: 8.x по-прежнему поддерживает shares и reservations, и это последний момент, когда видно, на что опиралась схема. Если вы уже на 9.0 — делайте по порядку и не пытайтесь охватить всё сразу. Сначала найдите ВМ, где приоритет держался на shares, и ВМ с потолками Low: это единственные места, где старые настройки прямо сейчас влияют на работу. Потом снимите замер в окно бэкапа и сравните с дневным — если разницы нет, вы вне зоны поражения. Если разница есть, ограничивайте шумных соседей и разводите окна по времени. И только потом планируйте разнесение томов и QoS на массиве.

Теперь про то, где риск преувеличен. У большинства небольших инфраструктур, с которыми я работаю, SIOC был выключен вообще или включён формально, дефолтные компоненты никуда не прикреплялись, а датасторы не упирались в потолок. Для таких стендов вся эта деприкация — новость на пять минут: ничего не изменилось и ничего делать не надо. Не надо в панике переделывать работающий кластер только потому, что вендор что-то убрал из списка возможностей.

Где я бы всё-таки не расслаблялся. Первое — если у вас общий датастор, на котором одновременно живут боевая БД и прокси резервного копирования. Второе — если у вас есть автоматизация развёртывания, которая навешивает политики по имени: она продолжит успешно отрабатывать и навешивать пустышки, никто вам ошибку не покажет. Третье — если Storage DRS был включён именно ради выравнивания латентности: этой функции больше нет, и раскладку надо пересматривать руками.

И последнее, скорее организационное. Обновите свою внутреннюю документацию сразу после апгрейда, пока помните. Строчка «важные ВМ помечены High IO shares allocation» в вашей вики теперь врёт, и врать она будет ровно до того дня, пока следующий человек не потратит четыре часа на то же самое расследование, что описано выше. Пять минут правки текста экономят чужой рабочий день.

• Шаг 1. Найти ВМ, где приоритет держался на shares, и ВМ с Low — заменить дефолтные компоненты своими.
• Шаг 2. Замер esxtop в окне бэкапа против дневного.
• Шаг 3. Лимиты на прокси бэкапа и прочих шумных соседей.
• Шаг 4. Развести окна обслуживания по времени.
• Шаг 5. Планово — отдельные тома под боевую БД и QoS на массиве.
• Шаг 6. Поправить вики и шаблоны развёртывания.

Частые вопросы