Round robin vmware настройка

Обновлено: 07.07.2024

всем добрый день!

есть схд EVA P6350 на ней сделан 1 Vdisk.

этот диск презентован двум хостам. В каждом хосте по одному 2-х портовому HBA.

подключение идет через FC свитчи. каждый первый HBA порт хоста и каждый первый

порт из двух контроллеров EVA включены в 1-й свитч. все вторые порты и на хосте и

на EVA включены во второй свитч. Свитчи между собой не соединены.

Если в vsphere cliet выбрать HBA, то он покажет 2 пути к созданному vdisk на eva

и два пути к LUN 0 (к самому контроллеру eva). Контроллер EVA имеет статус всегда как ActiveIO/ActiveIO

а сам vdisk как active IO /active.

Жить это не мешает, но получается, что как будто EVA не active/active, а active/passive. На третьем скриншоте

видно, что только два порта находятся в состоянии active IO, и тот и другой на 2-м контроллере СХД.

в тоже время путь к самому контроллеру(к-й почему-то LUN 0) по всем 4-м значениям active IO.

и еще есть различия между свойствами Manage Paths у контроллера(который LUN 0) и у самого диска. У обоих Round Robin.

но у контроллера SATP: VMW_SATP_DEFAULT_AA

у диска VMW_SATP_ALUA

если у кого-то есть соображения по этому поводу, то

Dmitry_G

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Судя по всему EVA предоставляет ALUA доступ к дискам (утверждать не буду но поему EVA не high-end storage, что бы быть active-active). То есть она не совсем active/active, доступ к lun осуществляется через контроллер "owner" этого lun, этот путь называется "active optimized" (у vmware active IO), достпут к LUN через другой контроллер так же возможен, он называется "active non optimized" (у vmware просто active).

Для ситуации ALUA это совершенно типичная картина, у Вас 4 пути до LUN, по 2 пути через 2 фабрики, 2 пути являются active optimized и для них осуществлятся балансировка нагрузки RR.

Надеюсь ничего не напутал в терминологии и объяснение Советую прочитать " Storage Implementation in vSphere 5.0"

То есть на мой взгялд у Вас все нормально работает, SATP тоже верно отработал.

Akopylov

Mark as New
Bookmark
Subscribe
Mute
Email to a Friend

Судя по SNAG-0003.jpg vmhba2 (на Active (I/O)) связывается с LUN1 через target0, т.е. скажем грубо через "0й сторадж процессор", vmnba3 (на Active (I/O)) связывается с LUN через target1, т.е. грубо через "1й сторадж процессор", т.е. контроллеры СХД используются разные, так что не похоже на Active-Passive. А при работе со стандартными nmp/satp/psp и настройке Round Robin вроде и должно быть в вашем случае Active (I/O) только 2 а не 4, т.к. стандартный PSP не умеет использовать сразу несколько путей, использует их по очереди, и по умолчанию свичит пути каждые 1000 команд SCSI, если мне не изменяет память.

Round Robin (RR) : Uses an automatic path selection rotating through all available paths, enabling the distribution of load across the configured paths.

For Active/Passive storage arrays, only the paths to the active controller will be used in the Round Robin policy.
For Active/Active storage arrays, all paths will be used in the Round Robin policy.

У вас все пути горят как Active, только в данный момент (I/O) на таких-то.

Но возможно стоит подождать гуру, мне тоже интересно что скажут по этому вопросу.

В прошлый раз мы говорили о возможностях NSX Edge в разрезе статической и динамической маршрутизации, а сегодня будем разбираться с балансировщиком.

Прежде чем приступить к настройке, я хотел бы совсем кратко напомнить об основных видах балансировки.

Теория

Все сегодняшние решения по балансировке полезной нагрузки чаще всего делят на две категории: балансировка на четвертом (транспортном) и седьмом (прикладном) уровнях модели OSI. Модель OSI не самая лучшая референтная точка при описании методов балансировки. Например, если L4-балансировщик также поддерживает терминирование TLS, становится ли он в таком случае L7-балансировщиком? Но что есть, то есть.

Режим прокси, или one-arm. В этом режиме NSX Edge при отправке запроса на один из бэкендов использует свой IP-адрес в качестве адреса источника. Таким образом, балансировщик выполняет одновременно функции Source и Destination NAT. Бэкенд видит весь трафик как отправленный с балансировщика и отвечает ему напрямую. В такой схеме балансировщик должен быть в одном сетевом сегменте с внутренними серверами.

Вот как это происходит:

Пользователь отправляет запрос на VIP-адрес (адрес балансировщика), который сконфигурирован на Edge.
Edge выбирает один из бэкендов и выполняет destination NAT, заменяя VIP-адрес на адрес выбранного бэкенда.
Edge выполняет source NAT, заменяя адрес отправившего запрос пользователя на свой собственный.
Пакет отправляется к выбранному бэкенду.
Бэкенд отвечает не напрямую пользователю, а Edge, так как изначальный адрес пользователя был изменен на адрес балансировщика.
Edge передает ответ сервера пользователю.

Прозрачный, или inline, режим. В этом сценарии балансировщик имеет интерфейсы во внутренней и внешней сети. При этом ко внутренней сети нет прямого доступа из внешней. Встроенный балансировщик нагрузки действует как шлюз NAT для виртуальных машин во внутренней сети.

Пользователь отправляет запрос на VIP-адрес (адрес балансировщика), который сконфигурирован на Edge.
Edge выбирает один из бэкендов и выполняет destination NAT, заменяя VIP-адрес на адрес выбранного бэкенда.
Пакет отправляется к выбранному бэкенду.
Бэкенд получает запрос с изначальным адресом пользователя (source NAT не выполнялся) и отвечает ему напрямую.
Трафик снова принимается балансировщиком нагрузки, так как в inline схеме он обычно выступает в качестве шлюза по умолчанию для фермы серверов.
Edge выполняет source NAT для отправки трафика пользователю, используя свой VIP в качестве source IP-адреса.

Практика

Генерируем SSL-сертификат, который будет использовать NSX Edge

Вы можете импортировать валидный CA-сертификат или использовать самоподписанный. В этом тесте я воспользуюсь самоподписанным.

Настраиваем Application Profile

Application profiles дают более полный контроль над сетевым трафиком и делают управление им простым и эффективным. С их помощью можно определять поведение для конкретных типов трафика.

Persistence – сохраняет и отслеживает данные сеанса, например: какой конкретный сервер из пула обслуживает пользовательский запрос. Это позволяет гарантировать, что запросы пользователя направляются одному и тому же члену пула в течение всей жизни сеанса или последующих сеансов.

Enable SSL passthrough – при выборе этой опции NSX Edge перестает терминировать SSL. Вместо этого терминация происходит непосредственно на серверах, для которых выполняется балансировка.

Создаем пул серверов, трафик к которым будет балансироваться Pools

Если опция выключена, трафик для внутренних серверов идет с source IP балансировщика.
Если опция включена, внутренние сервера видят source IP клиентов. В такой конфигурации NSX Edge должен выступать в качестве шлюза по умолчанию, чтобы гарантировать, что возвращаемые пакеты проходят через NSX Edge.

Здесь нужно указать:

имя сервера;
IP-адрес сервера;
порт, на который сервер будет получать трафик;
порт для health check (Monitor healthcheck);
вес (Weight) – с помощью этого параметра можно регулировать пропорциональное количество получаемого трафика для конкретного члена пула;
Max Connections – максимальное количество соединений к серверу;
Min Connections – минимальное количество соединений, которое должен обработать сервер, прежде чем трафик будет перенаправлен следующему члену пула.

Вот так выглядит итоговый пул из трех серверов.

Добавляем Virtual Server

Connection Limit – максимальное количество одновременных соединений, которые может обработать виртуальный сервер;
Connection Rate Limit (CPS) – максимальное количество новых входящих запросов в секунду.

На этом конфигурация балансировщика завершена, можно проверить его работоспособность. Сервера имеют простейшую конфигурацию, позволяющую понять, каким именно сервером из пула был обработан запрос. Во время настройки мы выбрали алгоритм балансировки Round Robin, а параметр Weight для каждого сервера равен единице, поэтому каждый следующий запрос будет обрабатываться следующим сервером из пула.

Вводим в браузере внешний адрес балансировщика и видим:

После обновления страницы запрос будет обработан следующим сервером:

И еще раз – чтобы проверить и третий сервер из пула:

При проверке можно видеть, что сертификат, который отправляет нам Edge, тот самый, что мы генерировали в самом начале.

Проверка статуса балансировщика из консоли Edge gateway. Для этого введите show service loadbalancer pool.

Настраиваем Service Monitor для проверки состояния серверов в пуле

С помощью Service Monitor мы можем отслеживать состояние серверов в бэкенд пуле. Если ответ на запрос не соответствует ожидаемому, сервер можно вывести из пула, чтобы он не получал никаких новых запросов.

По умолчанию сконфигурировано три метода проверки:

Настраиваем Application Rules

Application Rules – способ манипулирования трафиком, основанный на определенных триггерах. С помощью этого инструмента мы можем создавать расширенные правила балансировки нагрузки, настройка которых может быть невозможна через Application profiles или с помощью других сервисов, доступных на Edge Gateway.

В примере выше мы включили поддержку tlsv1.

Еще пара примеров:

Редирект трафика в другой пул.

Редирект трафика на внешний ресурс.

Здесь мы перенаправляем трафик на внешний веб-сайт, если все участники основного пула в состоянии down.

Еще больше примеров тут.

На этом про балансировщик у меня все. Если остались вопросы, спрашивайте, я готов ответить.

Михаил Коротько
ИТ Архитектор специализирующийся на Cloud Computing, Big Data, комплексных ИТ проектах и решениях, а также блогер, энтузиаст облачных вычислений.
VMware vExpert 2010/2011.

Последние комментарии

Настройка multipathing и Round Robin для iSCSI LUN в ESX/ESXi 4

Недавно я писал о политиках multipathing касательно LUN в ESX/ESXi 4 и в заключение обещал описать настройку Round Robin. Держу обещание, статья ниже.

В данном примере я буду использовать хост на ESX 4, два физических сетевых адаптера выделенных для работы под трафик iSCSI и СХД HP MSA 2324i с двумя контролерами (что то по серьезней пока нет под рукой для свободного разделывания), работающими в режиме Active-Active ULP. Конфигурация из этого примера подойдет для настройки ESX/ESXi c другими типами СХД. Тут я затрону только настройку самого ESX, по умолчанию мы уже имеем несколько LUN на СХД(в моем примере 2 LUN).

Описывать настройку портов VMkernel, как и iSCSI инициатора в ESX/ESXi подробно не буду, а сразу перейду к настройки мультипатчинга и Round Robin.

Сама суть конфигурации для обеспечения multipathing в следующем. Каждый физический интерфейс отдаем только под использование 1-го порта VMkernel, в идеале вообще под монопольное использование. Т.е этот же интерфейс не должен быть задействован на другом порте VMkernel, который также будет использоваться для трафика iSCSI.

Есть два варианта конфигурации.

1. С одним vSwitch и несколькими портами VMkernel, а также несколькими привязанными физ. сетевыми к нему.

2. С несколькими vSwitch, в каждом из которых по 1-му порту VMkernel и к каждому привязана 1 физ. сетевая.

Оба варианта дают один и тот же результат. Я предпочитаю первый вариант, сделать отдельный vSwitch под нужды iSCSI трафика, он мне удобнее. Его я и опишу ниже.

Сама железная конфигурация выглядит так.

Далее конфигурируем хост для работы по iSCSI с мультипатчингом.

Создаем vSwitch с двумя портами VMkernel и привязываем к этому vSwitch 2-е физические сетевые карты.

Проделываем следующие: заходим в свойства порта VMkernel в моем примере iSCSI1 (Идем у нужного нам vSwitch в Properties -> выбираем нужный порт -> Edit) и переходим на вкладку NIC Teaming.

Включаем Failover Order, затем выбираем одну из сетевых карт которая будет не использована в данном подключение и перетаскиваем ее с помощью кнопки Move Down в секцию Unused Adapters. Этим действием мы оставили в использование под VMkernel порт только одну сетевую карту.

Далее проделываем тоже самое только с другим портом VMkernel. Разница лишь в том что, другому порту оставляем активной уже другую сетевую карту.

Теперь из консоли нужно выполнить следующую команду esxcli swiscsi nic add -n <port_name> -d <vmhba>, где port_name имя порта VMkernel, а vmhba имя iSCSI адаптера. Этим действием мы привязываем порты VMkernel к iSCSI инициатору хоста.

В моем примере я последовательно добавляю каждый порт

esxcli swiscsi nic add -n vmk1 -d vmhba34

esxcli swiscsi nic add -n vmk2 -d vmhba34

Далее командой esxcli swiscsi nic list -d <vmhba> можно просмотреть привязанные порты VMkernel к iSCSI адаптеру.

На вкладке Paths это хорошо видно.

По умолчанию для данного типа хранилищ работающих в режиме Active/Active политика multipathing является Fixed. О политиках multipathing можно прочесть в другой моей заметки.

Возвращаемся на вкладку Devices и щелкаем правой кнопкой мыши по первому LUN и выбираем Manage Paths.

Вот тут как раз и меняем политику multipathing с Fixed на Round Robin.

Затем тоже самое проделываем со следующим LUN.

В итоге у меня получилась вот такая картина.

Вот и все с настройкой.

Из скринов видно что с Round Robin одновременно активны сразу два контролера и оба контролера участвуют во операциях I/O, в отличие от политики Fixed где одновременно активны оба контролера, но в операциях I/O участвует только один контролер.

Похожее

Автор Михаил Коротько в 16:21

11 комментариев

Я хотел с Вами посоветоваться.

У меня все настроено аналогично, только вместо двух свичей один, разделенный на 2 вилана. Проблема заключается в том, что если я отключаю один кабель, то все перестает работать, но примерно через 20 секунд все восстанавливается без потери данных. Скажите пожалуйста, как можно избежать этого делэя

Зарание огромное спасибо

Приветствую!
Я только вот не понял немного, как так все перестает работать, а через 20 сек все работает и без потери данных. Откуда вы это видите, с каких данных и источников?
Могу подозревать, дело в сторадже и уж совсем маловероятное это свитч.
Насчет стороджа есть такая штука, но не всегда(на недорогих стораджей начального и среднего уровня), что при падение одного или нескольких путей от хоста до СХД бывает кратковременная потеря производительности, опять же все это зависит от стораджа, какой у него режим работы контролеров, скорость его работы, как быстро он отрабатывает потерю пути, загруженность и т.п.
И конечно вариант номер два это свитч. Хотя мало вероятно, но для чистоты эксперимента можете взять другой свитч и попробовать смоделировать туже ситуацию.

на последнем скрине видно что 2 активных ио пути 2 пассивных = раунд робин не работает! так как используется 1 путь. причина ? актив/пассив сторадж.

1. Почему все-таки лучше multipath, чем LA, в случае подключения СХД по iSCSI к ESX(i)? Только тем, что используется два разных свича и не нужно настраивать на свичах LA?

2. Настройка со стороны ESX(i) ясна, а со стороны СХД? Два разных, не связанных сетевых интерфейса с разными IP?

3. В качестве примера упомяналась HP MSA 2324i. А будет ли работать в случае с софт-iSCSI? К примеру, FreeNAS на железке с двумя сетевыми контроллерами?

1. Я и не говорил что LA лучше multipath. Это две разные вещи из разных областей, каждая под свои задачи.
2. Со стороны СХД ничего сложного, да именно так, на каждый порт свой уникальный IP.
3. Будет если правильно настроите, хоть с софтом, хоть с железкой.
4. Задаю какие мне доступны и удобны или выделены, все соображения главное небыло бы конфликтов ip и желательно из той же подсети 🙂

Судя по вопросам, советую почитать про iSCSI, СХД, MPIO, ну и про LA. Вопросы сразу отпадут.

Сразу скажу СХД надо подключать по нескольким путям и настраивать правильно MPIO.

Четвертая часть полностью посвящена моментам работы ESXi с дисковой подсистемой и СХД.

VMware vStorage APIs for Array Integration (VAAI)

Как уже говорилось в первой части, рекомендуется использовать дисковые хранилища с поддержкой VAAI. Данные возможности СХД позволяют перенести нагрузку с гипервизора на хранилище, улучшая в некоторых ситуациях производительность.

Если SAN, либо NAS массив поддерживает VAAI, ESXi автоматически это определит и начнет использовать предоставленные возможности.

LUN Access Methods

Помимо классической файловой системы VMFS поверх луна, ESXi также поддерживает технологию raw device mapping (RDM), позволяющую подключать лун напрямую в виртуальную машину. Зачастую RDM может использоваться в кластерных системах.

RDM – файл на VMFS, который выступает как прокси для нижележащего блочного устройства (луна).

RDM может работать в двух режимах – virtual compatibility, либо physical compatibility:

Virtual Mode – функции взаимодействия с диском виртуализируются по аналогии с любым диском, располагаемым на VMFS. Данный режим, например, позволяет создавать снапшоты дисков RDM;
Physical mode – минимизирует функции виртуализации и взаимодействия с диском, перекладывая данные функции на виртуальную машину. Снапошты создавать нельзя.

Virtual Disk Modes

Для каждого диска виртуальной машины ESXi поддерживает три режима:

Стоит понимать, что использование Independent дисков не отключает возможность создания снапшотов с виртуальной машины, однако с данного типа дисков снимки делаться не будут.

Virtual Disk Types

ESXi поддерживает два основных типа дисков – Thick Provisioned и Thin Provisioned.

Thick Provisioned – тип виртуального диска, который сразу резервирует дисковое пространство на хранилище VMFS. Подразделяется на два типа:

Eagerzeroed – при создании виртуального диска, полностью его «зануляет». Увеличивает производительность при первой записи в каждый предварительной зануленный блок, но увеличивает время создания диска (чем больше диск – тем больше время, соответственно). VAAI может ускорить процесс создания таких дисков.
Lazyzeroed – так же резервирует пространство под виртуальный жесткий диск, но зануление блоков происходит только в момент первой записи в них. Диск создается практически моментально, однако, при первой записи будет немного снижена производительность. При последующих записях обладает такой же производительностью, как и eager zeroed диски;
Thinprovisioned – В отличии от Thick provisioned дисков, которые сразу резервируют требуемое пространство на VMFS, пространство под тонкие диски выделяется при записи. Производительность при первой записи в новый блок будет ниже, однако при последующих записях в ранее записанные блоки производительность аналогична eager-zeroed дискам.

Automatic Space Reclamation (UNMAP)

Хранилища VMFS6 (начиная с версии vSphere 6.5) поддерживают автоматическое высвобождение освободившегося пространства для thin provisioned дисков.

Стоит отметить, что VMFS5 так же поддерживает UNMAP, правда только в ручном режиме с помощью esxcli storage vmfs unmap.

Partition Alignment

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

Как и многие другие файловые системы, VMFS может испытывать проблемы с производительностью в случае неправильного выравнивания (misalignment). Начиная с ESXi 5.0 при создании файловой системы через клиента vSphere, VMFS3/5/6 автоматически выравниваются, начиная от границы в 1MB;

Если файловая система VMFS3 создана на более ранней версии гипервизора, чем ESXi5, выравнивание такой FS начинается от границы в 64KB. В случае если файловая система будет обновлена до VMFS5, выравнивание в 64KB так же сохраняется. Единственным решением является пересоздание файловой системы с гипервизора с версией 5 или выше.

Файловые системы VMFS3 и VMFS5 нельзя обновить до VMFS6. Единственный вариант – создание нового datastore на базе VMFS6 и перенос виртуальных машин на него.

Для того, чтобы выровнять VMFS разделы вручную, рекомендуется ознакомиться с документацией производителя СХД, с которой выделяется LUN (в большинстве случаев на выравнивание влияет тип ОС, указанный при создании луна на СХД), ну и, конечно, на рабочей файловой системе такое не делается.

Если выясняется, что с выравниванием не все в порядке, правильным решение будет создать новое, уже выравненное хранилище VMFS и выполнить Storage vMotion виртуальных машин на него.

SAN Multipathing

Поскольку практически во всех инсталляциях доступ к СХД осуществляется по нескольким путям (через несколько портов HBA и несколько свитчей (в SAN это называется фабрикой)), необходимо использовать специальное ПО, управляющие всеми путями и определяющие использование путей до СХД (Multipathing software). В ESXi за это отвечает PSA – Pluggable Storage Architecture.

Политики мультипасинга могут влиять на производительность дисковой подсистемы. В большинстве случаев, политика, выставленная ESXi по умолчанию для СХД будет лучшим выбором.

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

Round Robin – политика, позволяющая в некоторых ситуациях улучшить производительность за счет балансировки нагрузки между активными путями, ведущими к СХД, отправляя фиксированное количество I/O запросов на каждый из путей. Не все массивы поддерживают политику Round Robin. Использование неподдерживаемой политики может привести к проблемам с доступом к предоставленным дисковым ресурсам. Рекомендуется обратиться к документации производителя СХД, чтобы получить список поддерживаемых политика.

ALUA (Asymmetric Logical Unit Access) – использование данной политики позволяет увеличить производительность при работе с СХД, которая, собественно, поддерживает ALUA. ALUA информирует ESXi об оптимальных путях до луна (Active Optimized), а так же дополнительных, не оптимальных путях (Active Non-Optimized). В сочетании с Round Robin, ESXi балансирует запросы к СХД между оптимальными путями.

ESXi так же поддерживает сторонние плагины (PSPs), которые могут предоставить наилучшую производительность для конкретных типов хранилищ (обычно поставляются производителем СХД).

Storage I/O Resource Allocation

VMware предоставляет механизмы для динамического управления дисковым вводом-выводом, позволяя критически важным приложениям сохранять их производительность даже во время нехватки ресурсов.

Дисковый ввод-вывод доступный ESXi можно разграничить с помощью Shares, либо Limits:

Часть ввода вывода виртуальных дисков можно разграничить с помощью Shares. В таком случае, каждый виртуальный диск будет иметь часть пропускной способности к хранилищу, в зависимости от выставленной величины Shares;
Максимальное количество I/O доступных виртуальному диску можно ограничить с помощью Limits. Limits выставляются в количестве IOPS. По умолчанию количество IOPS не ограничивается.

Limits и Shares выставляются на уровне виртуального диска в настройках машины.

iSCSI and NFS Recommendations

Если возможно, стоит использовать выделенные сетевые подключения для iSCSI и NFS между сервером и СХД (еще лучше отдельные коммутаторы). Если выделенной сети нет и не предвидится, стоит отделить дисковый трафик хотя бы с помощью VLAN.;
Рекомендованная скорость подключения 10Gb/s и выше. В случае с NFS агрегация сетевых интерфейсов может предоставить большую пропускную способность;
Если возможно – стоит использовать Jumbo frames (MTU 9000).

NVMe/NVMe-oF Recommendations

Для максимальной производительность рекомендуется включить high-performance plug-in (HPP) на хосте ESXi;
Увеличить максимальное количество I/O с параметром Disk.SchedNumReqOutstanding;
Максимальная пропускная способность NVMe может быть достигнута с запуском большого количества виртуальных дисков, либо виртуальных машин, поскольку в NVMe хорошо развит параллелизм;
Необходимо выбирать корректны storage adapter в виртуальной машине. Это может быть, как PVSCSI, так и vNMVe.

vSphere Virtual Machine Encryption Recommendations

Начиная с версии 6.5 vSphere может шифровать виртуальные диски .vmdk, файлы снапшотов .vmsn, NVRAM .nvram, swap .vswp и конфигурационные файлы .vmx.

Шифрация и дешифрация выполняется центральным процессором и, соответственно, потребляет его ресурсы.

При достаточном количестве процессорных ресурсов, в большинстве случаев потеря производительности крайне незначительная. Однако, в случае нехватки ресурсов ЦПУ, могут начаться проблемы с производительностью;
Для минимизации потребления CPU, рекомендуется выбирать процессоры, которые поддерживают инструкции AES-NI;
Необходимо убедиться, что AES-NI в состоянии Enabled в BIOS. Иногда, для этого необходимо обновить версию BIOS;
Поскольку шифрование выполняется непосредственно хостом и СХД видит только зашифрованные данные, это может сказаться на таких показателях как дедупликация и компрессия.

General ESXi Storage Recommendations

Running Storage Latency Sensitive Workloads

С самого начала подсистема дискового ввода-вывода в ESXi сконфигурирована для получения максимальной пропускной способности с минимальными затратами процессорных ресурсов.

Для приложений, чувствительных к дисковым задержкам следует рассмотреть и сконфигурировать следующие моменты:

Host Power Management может влиять на значения Latency дискового ввода-вывода, ввиду чего рекомендуется возможно переключить политику в режим «Maximum Performance», либо отключить Power Management в BIOS. Отключить C1E и прочие C-states в BIOS. Включить Turbo Boost в BIOS;
Если в виртуальной машине используется контроллер LSILogic, либо PVSCSI, можно отрегулировать параметр reqCallThreshold. Данный параметр влияет на скорость прохождения дисковых запросов виртуальной машины, однако может увеличить потребление ресурсов CPU.

На этом часть, посвященная работе с дисковой подсистемой, подходит к концу. В следующей части посмотри более внимательно на работу сетевой подсистемы.

Читайте также: