Как работает Storage IO Control (SIOC)

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

Вопрос в том, какие именно метрики задержек отслеживаются SIOC - среднее время ответа устройства (DAVG), время ответа ядра (KAVG) или задержки ВМ (GAVG)?

На самом деле ни одна из них. Все они являются локальными метриками планировщика ресурсов, которые и отвечает за отправку всех запросов к СХД. Основная же задача SIOC - управлять ресурсами общей СХД между несколькими ESXi хостами, предоставляя IO ресурсы для всех ВМ независимо от того на каком хосте они работают. И так как SIOC должен регулировать и приоритезировать доступ к общему хранилищу нескольких ESXi хостов, локальные метрики хоста игнорируются. Но какие же, в таком случае, используются метрики? По сути, пороговое значение сравнивается со средним значением DAVG на каждом хосте и средним количеством IOPS на хосте.

vSphere Admission Control

Когда мы говорим про контроль доступа, или же admission control, мы обычно имеем в виду политики HA, хотя это не единственная функция, использующая контроль доступа. DRS, Storage DRS, да и сами ESXi хосты имеют свой собственный механизм контроля доступа. Предлагаю детально взглянуть на то, чем же является механизм контроля доступа, и какое участие он принимает в запуске виртуальной машины.

Какова же основная функция контроля доступа? Мне нравится называть эту функцию командой виртуальных балансировщиков. Admission control разработан, чтобы гарантировать предоставление виртуальной машине требуемое и настроенное количество ресурсов. Последняя часть предыдущей фразы и объясняет суть контроля доступа.

Параметры DRS кластера MinGoodness и CostBenefit

В VMware KB есть статья о настройке таких параметров DRS кластера как MinGoodness и CostBenefit. Обычно после перезагрузки хоста или перевода его в/из режима поддержки DRS ещё какое-то время не перемещает на него ВМ, и сервер работает вхолостую. С помощью данных параметров эту опцию можно выключить, а также заставить DRS более агрессивно мигрировать ВМ между хостами. Вместе с тем, эти параметры были сделаны тоже не просто так, и я не рекомендую изменять эти параметры, и вот почему.

Задачи балансировки нагрузки DRS
Главная задача DRS это предоставление виртуальным машинам требуемые ресурсы. Если ВМ получает ресурсы, которые она запрашивает (динамическое выделение ресурсов), то нет необходимости искать для неё лучший сервер. Если же ВМ не получает ресурсы, доступные ей в рамках динамического выделения, то DRS будет рассматривать возможность её перемещения, принимая во внимание дополнительные факторы.

Изменения в обработке отказа СХД в vSphere 5.0 U1

О том какие бывают типа отказа СХД и чем отличает APD от PDL можно прочитать в данной статье.

В vSphere 5.0 НА никак не реагировал на изменения состояние СХД, и если у ВМ пропадал доступ к данным считалось, что так и должно быть, и ВМ продолжит работать или будет перезапущена администратором после решения проблем с СХД.

В vSphere 5.0 U1 был представлен новый механизм, который позволяет менять поведение НА в случае потери доступа (PDL) к массиву. Управлять реакцией НА в можно с помощью двух опций: disk.terminateVMOnPDLDefault, параметры которой редактируются в файле /etc/vmware/settings, и das.maskCleanShutdownEnabled, параметры которой редактируются в расширенных свойствах НА кластера.

VMware рекомендует выставлять параметры обоих опций всегда в True, тогда в случае потери доступа к массиву, виртуальная машина будет выключена в момент обращения к потерянному массиву (за это отвечает первая опция), а при восстановлении доступа к массиву будет перезапущена с помощью НА (за это отвечает вторая опция, которая и позволяет НА отличать какая машина была выключена администратором, а какая была выключена в результате PDL).

Также при наступлении аварийной ситуации в логе vmkernel будут появляться следующие сообщения:

2012-03-14T13:39:25.085Z cpu7:4499)WARNING: VSCSI: 4055: handle 8198(vscsi4:0):opened by wid 4499 (vmm0:fri-iscsi-02) has Permanent Device Loss. Killing world group leader 4491
2012-03-14T13:39:25.085Z cpu7:4499)WARNING: World: vm 4491: 3173: VMMWorld group leader = 4499, members = 1

Оригинал: Duncan Epping