Directpath i o vmware что это
vSphere DirectPath I/O (DPIO) is a vSphere feature that takes advantage of VT enabled processors installed in ESXi hosts in order to improve perfomance for virtual machines. A processor feature in some Intel and AMD CPUs referred to as I/O memory management unit (MMU) remaps direct memory access (DMA) transfers and device interrupts. This allows virtual machines to bypass the vmkernel and gain direct access to physical hardware. Whilst available in vSphere 4, DPIO has been enhanced for vSphere 5. For example, vMotion is now supported for virtual machines with DPIO enabled on Cisco UCS hardware, though this Note that in order to take advantage of this feature, the VM must be configured with DPIO on Cisco UCS through a Cisco Virtual Machine Fabric Extender (VM-FEX) distributed modular system.
Other than VMs configured with DirectPath on Cisco UCS on a VM-FEX distributed modular system, enabling DPIO for a virtual machine makes the following features unavailable to that virtual machine:
- vMotion
- Hot adding and removing virtual devices
- Record and replay
- Fault Tolerance
- HA
- Snapshots
By interfacing directly with the hardware, DPIO can improve VM performance by reducing CPU cycles, which would have otherwise been used for vmkernel translation. DirectPath I/O is an advanced feature and is only recommended for environments with substantially high network workloads. Anything that is extremely time/latency sensitive may benefit from DPIO. More about the performance benefits here.
Configure a PCI Device on a Virtual Machine
The last step is to configure a virtual machine to use the device. The following process describes how to do this:
- From the vSphere Client, select a VM.
- Click Edit Settings.
- With the Hardware tab selected, click Add.
- Select PCI device, click Next.
- Select the Passthrough device configured previously, click Next.
- Click Finish.
There are a few things to be aware of here, along with the limitations mentioned earlier:
1. A virtual machine must be powered off prior to adding PCI devices.
2. Up to 6 PCI devices can be added to a VM running on ESXi 5.
3. Adding a DirectPath device to a VM sets memory reservation to the memory size of the virtual machine.
The Fix
The first fix I found on the net is the one described in KB1022011 . Basically, you SSH to ESXi and inspect /etc/vmware/esx.conf looking for the line where a device’s owner value is set to passthru. This must be changed to vmkernel to disable pass-through. To verify the device is the correct one, look at the /device value and compare it to the Device ID value in vSphere Web client; Configure -> PCI Devices -> Edit.
In this example, the device ID, for the storage controller, is 3b25 meaning I know I’m changing the correct one. You can see this in the next screenshot.
To replace the entry, use vi, substituting passthru with vmkernel, which is what I did. I rebooted the host a third time and much to my annoyance it was still missing the datastore. After some more digging around, I came across these two links; The wrong way to use VMware DirectPath and KB2043048 .
The first link is what helped me fix the issue and also provided me with the inspiration to write this post, so kudos goes to the author.
VMware VMDirectPath I/O
What is VMware VMDirectPath I/O?
VMDirectPath allows guest operating systems to directly access an I/O device, bypassing the virtualization layer. This direct path, or passthrough can improve performance for VMware ESX systems that utilize high-speed I/O devices, such as 10 Gigabit Ethernet. A single VM can connect to up to two passthrough devices.
VMDirectPath I/O is experimentally supported for the following Storage and Network I/O devices:
- QLogic QLA25xx 8 Gb Fibre Channel adapters
- Emulex LPe12000 8 Gb Fibre Channel adapters
- LSI 3442e-R and 3801e (1068 chip based) 3 Gb SAS adapters
- Intel 82598 10 Gigabit Ethernet controller
- Broadcom 57710 and 57711 10 Gigabit Ethernet controllers
VMware regularly adds support for new hardware. Check your hardware’s support at the VMware Hardware Compatibility Guide portal.
What are the advantages of using VMware VMDirectPath I/O?
VMDirectPath I/O can be used when your guest OS needs a greater performance from the I/O device. It also allows the use of I/O devices, which are not supported by the ESX server directly, to be linked to VM’s as the virtualization layer is bypassed.
What are the disadvantages of using VMware VMDirectPath I/O?
- Once you have your VM directly connected to an I/O device, your VM will no longer be able to use features such as VMotion and DRS.
- You cannot have two devices in two different contexts (for example, one used by VMkernel and one in pass-through) using the same PCI slot. For example, the dual head NIC is dedicated to the VMkernel OR is available for pass-through. If you select one, the other is automatically selected as well. A dialog informs you why this occurred.
How is VMware VMDirectPath I/O configured on an ESX Host?
To configure VMDirectPath I/O on your ESX Host, follow the steps on the VMware guide: Configuring VMDirectPath I/O pass-through devices on an ESX host
The GParted Fix
GParted, GNOME Partition Editor, is a free Linux-based disk management utility that has saved my skin on countless occasions. You can create a GParted bootable USB stick by downloading the ISO from here and using Rufus.
As mentioned already, we need to change the passthru setting in the backed up esx.conf file found in the state.tgz archive. To do this, we must first uncompress state.tgz which contains a second archive, local.tgz.
Uncompressing local.tgz yields /etc folder where we find esx.conf. Once there, open esx.conf in an editor. Find and change the passthru entry and compress the /etc folder back to state.tgz.
Finally we overwrite the original state.tgz files under /sda5 and /sda6 and reboot the host.
Here’s the whole procedure in step form.
Step 1 – Boot the ESXi server off the GParted USB stick. Once it’s up, open a terminal window.
Step 2 – Run the following commands.
Step 3 – Determine which state.tgz file is most current. Run the following commands and look at the time stamps. You’ll need to uncompress the most recent one to keep using the current host configuration save for the changes we’ll be making.
Here I’m showing the file while SSH’ed to the host
Step 4 – Copy the most current state.tgz to /temp. Here, I’ve assumed that the most current file is the one under /mnt/hd1. Yours could be different.
Step 5 – Uncompress state.tgz and the resulting local.tgz using tar. You should end up with an etc directory as shown.
Step 6 – Navigate to /temp/etc/vmware and open esx.conf in vi.
- Press [/] and type passthru followed by Enter. This takes you to the line you need to edit assuming passthru has been enabled just for one device. If not, make sure the device ID matches as explained above.
- Press [Insert] and change the value to vmkernel.
- Press [ESC], [:] and type wq.
- Press [Enter] to save the changes.
Step 7 – Compress the archive and copy it back to /mnt/hd1 and /mnt/hd2.
Reboot the host and your datastore and virtual machines should spring back to life. The procedure worked for me. The storage adapter, datastore and VM all came back to life with no apparent issues.
Conclusion
The moral of the story is to test, test and test before replicating something on a production system. Reading the manual and doing some research first goes a long way in avoiding similar situations. The correct solution of course, in this case, would have been to install a 2nd storage controller and enable DirectPath on it. The optimal solution would be to install FreeNas on proper hardware instead of virtualizing it, something I haven’t written about but might cover in a future post. In the meantime, have a look at the complete list of VMware posts on this blog for more interesting topics to learn from.
Posted by Simon Long Aug 3, 2009
So, why did the fix fail?
The simple explanation is that the changes done, given my setup, won’t persist because everything is running off volatile memory, in RAM that is. This means that once ESXi is rebooted, the change done to esx.conf is lost too and it’s back to square one. During the booting process, the ESXi binaries are loaded from partition sda5 (bootbank) or sda6 (altbootbank) depending on which one is currently marked active.
The host’s configuration files are automatically and periodically backed up via script to an archive called state.tgz which is copied to both partitions depending on which one is active at the time. This backup mechanism is what allows you to revert to a previous state using Shift-R while ESXi is booting. Unfortunately, in my case, the pass-through change was backed up as well and copied to both partitions or so it seemed.
ESXi has full visibility of the drive while booting up, which explains why it manages to in the first place despite the pass-through setting. It is only when esx.conf is read, that the pass-through setting is enforced/
Reverting to a previous state using Shift-R did not work for me, so I went down the GParted route.
What went wrong?
The physical host I chose for my grandiose plan, has a single IBEX SATA controller with 3 disks attached to it. Nothing fancy. It’s just software emulated RAID which ESXi doesn’t even recognize hence the non-utilized drives. I’m only using one drive which I’ve also used to install ESXi on. Remember, this is a testing environment. On this one drive, there’s also the default local datastore and a couple of VMs.
The drive, by default, is split into a number of partitions during the ESXi installation. Two of the partitions, called bootbank and altbootbank, hold the ESXi binaries that are loaded into memory during the booting process. I’ll come back to this later.
Back to the business of enabling DirectPath I/O on a PCI card such as a storage controller. In the next screenshot, I’ve highlighted the ESXi host in question and labeled the steps taken to enable DirectPath for a PCI device. This is enabled by simply ticking a box next to the device name. In this case, I enabled pass-through on the Ibex Peak SATA controller. Keep in mind that this is my one and only storage controller.
After enabling DirectPath , you are reminded that the host must be rebooted for the change to take root.
Again, without giving it much thought, I rebooted the host. Five minutes later and the host was back on line. I proceeded to create the new VM for FreeNAS but I quickly found out that I no longer had a datastore where to create it. And it suddenly dawned on me! With DirectPath enabled, the hypervisor will no longer have access to the device. Darn!
And that’s when I ended up with a bunch of inaccessible VMs on a datastore that was no more.
At this point, panic would have quickly ensued if this were a live system but thankfully it was not. I started digging around in vSphere client, and one of first things noticed was that the Ibex storage adapter was not listed under Storage Adapters irrespective of the number of rescans carried out.
The logical solution that first came to mind was, disable DirectPath I/O on the storage controller, reboot the host and restore everything to its former glory. So I did, rebooted the host and waited for another 5 minutes only to discover the host was still missing the datastore and storage adapter.
References and Useful Links
Thanks to the following articles, where much of the info here was gathered..
Пятая и заключительная часть касательно «железа» в vSphere будет полностью про сеть.
Как и в большинстве случаев, все начинается с общих рекомендаций:
- Повышенная утилизация CPU хостов может влиять на производительность сетевой подсистемы. Чем большая производительности сети – тем больше процессорных ресурсов требуется. Недостаточное количество процессорных ресурсов снижают пропускную способность сети. В связи с этим рекомендуется наблюдать за загрузкой CPU на хостах;
- Если сетевое устройство используется несколькими потребителями, будь то виртуальная машина, либо VMKernel, наиболее активные из них могут оказывать влияние на всех остальных. В связи с этим рекомендуется выделять отдельные сетевые адаптеры для особо «интенсивных» потребителей. Добавлю от себя, что стоит подумать на тему того, чтобы вынести трафик iSCSI (если используется), на отдельные сетевые интерфейсы. Также можно использовать NIOC для деления сетевого трафика на классы и резервирования пропускной способности для классов;
- Для установки сетевого соединения двух виртуальных машин в рамках одного хоста, необходимо подключить обе машины к одному виртуальному свитчу. При подключении машин к разным виртуальным свитчам, сетевой трафик будет покидать гипервизор, создавая при этом дополнительную грузку на CPU.
Network I/O Control (NetIOC)
NetIOC позволяет «поделить» доступную пропускную способность сети на пулы. В NetIOC имеется 9 пулов, создаваемых по умолчанию (MGMT, FT, iSCSI, NFS, vSAM, vMotion, Replication, Backup и трафик виртуальных машин), а также имеется возможность создать свои пулы сетевых ресурсов.
Начиная с версии vSphere 6, NIOC версии 3 управляет пропускной способностью на уровне распределенного свитча (dvSwtich), в то время как NIOC v2 работал на уровне физического адаптера.
При создании распределенного свитча (Distibuted Switch) версия 3 используется по умолчанию. При апгрейде версии dvSwitch, NIOC не всегда может быть обновлен с версии 2 до версии 3.
В целом же NetIOC позволяет гарантировать пропускную способность для пулов ресурсов и исключить влияние систем, работающих в пуле на другие пулы.
Начиная с версии vSphere 6.0 DRS учитывает настройки NIOC при подсчете возможностей для миграции виртуальных машин.
При использовании NetIOC пропускная способность сетевых пулов ресурсов может быть поделена с помощью shares, reservations и limits:
- Shares могут быть использованы для выделения сетевому адаптеру, либо пулу, части сетевых ресурсов, по аналогии с Shares для CPU. Чем больше значение Shares – тем больше ресурсов будет выделено в случае их нехватки;
- Bandwidth reservation – гарантия минимальной пропускной способности в Mb/s для пула ресурсов, либо сетевого адаптера VM. Максимально допускается зарезервировать не более 75% от пропускной способности сетевого адаптера. Если пул, либо машина не используют все зарезервированные для них ресурсы, данные ресурсы могут быть использованы остальными потребителями;
- Limits – используются для ограничения максимальной пропускной способности пула, либо vNIC. Лимиты применяются всегда, даже когда нагрузки на сетевые интерфейсы нет и имеется доступная пропускная способность.
DirectPath I/O
vSphere DirectPath I/O позволяет гостевой операционной системе получать доступ к физическому сетевому адаптеру напрямую без использования эмулированных адаптеров E1000, либо, паравиртуальных адаптеров VMXNET. Это позволяет получить большую пропускную способности сети в виртуальной машине при меньших затратах процессорных ресурсов.
Однако, это было бы так прекрасно, если бы не существующие ограничения. DirectPath I/O не совместим с vMotion, снапшотами, операциями suspend/resume, FT, NIOC, и т.п.
В большинстве случаев виртуальные машины не нуждаются в использовании данной функции, однако, для некоторых, крайне активно использующих сеть, DirectPath I/O может быть полезен с учетом ограничений на использование функций виртуализации.
Single Root I/O Virtualization (SR-IOV)
SR-IOV работает по тому же принципу, что и DirectPath I/O. Данная функция предназначена для систем с высокой сетевой нагрузкой, имеет те же ограничения, однако позволяет использовать одно физическое устройство несколькими гостевыми системами одновременно.
SplitRx Mode
Использование SplitRX позволяет задействовать большее количество ядер ЦПУ для обработки сетевого трафика в очереди. Использование данной функции позволяет улучшить сетевую производительность в некоторых случаях:
- Большое количество виртуальных машин на хосте ESXi, каждая из которых получает multicast трафик от одного и того же источника;
- При использовании DVFilter, между двумя машинами в рамках одного ESXi хоста.
Начиная с ESXi 5.1 и выше, данная функция включается по умолчанию для сетевого адаптера VMXNET3 (единственный тип сетевого адаптера, который это поддерживает), в случае, если физический интерфейс сильно утилизирован и получает больше 10000 broadcast/multicast пакетов в секунду.
SplitRX включается автоматически только когда сетевой трафик проходит через физический сетевой интерфейс, не в случаях, когда сетевой трафик проходит внутри ESXi. В случае с сетевым трафиком внутри хоста, SplitRX необходимо включить вручную.
Для включения и отключения SplitRX на уровне хоста необходимо использовать параметр NetSplitRXMode. 0 – функция отключена, 1 – включена.
Включить SplitRX можно так же индивидуально для сетевых адаптеров виртуальной машины. Делается это в файле vmx виртуальной машины параметром ethernetX.emuRxMode.
Receive Side Scaling (RSS)
RSS позволяет выполнять обработку сетевого трафика на нескольких CPU за счет создания множества очередей. Эта функция может помочь увеличить пропускную способность сетевой карты, однако так же может увеличить накладные процессорные расходы.
ESXi позволяет использовать RSS сетевыми адаптерами виртуальных машин, в большинстве случаев тех, которые работают с большим объемом сетевого трафика.
Ввиду возможного увеличения накладных расходов в части потребления процессорных ресурсов, данная функция по умолчанию отключена.
Virtual Network Interrupt Coalescing
Данная функция позволяет уменьшить количество прерываний, что потенциально может снизить утилизацию процессора хоста. С другой стороны, включение Interrupt Coalescing может увеличить сетевые задержки с микросекунд до миллисекунд, однако для большинства систем это мало ощутимо.
По умолчанию данная возможность включена для всех сетевых интерфейсов виртуальных машин на ESXi, однако, при необходимости может быть отключена.
Включение\отключение\настройка производится в файле vmx виртуальной машины параметром ethernetX.coalescingScheme.
Running Network Latency Sensitive Workloads
Изначально ESXi сконфигурирован с целью получения большой пропускной способности с минимальными затратами ЦПУ. И, хотя, эта конфигурация обеспечивает в большинстве случаев лучшее масштабирование и позволяет запускать большее количество машин в рамках хоста, это может сказаться на повышенных сетевых задержках.
vSphere предоставляет различные возможности для конфигурации систем, которые крайне требовательны к сетевым задержкам. Об этом ниже:
- Стоит определить чувствительные к задержкам виртуальные машины и использовать параметр Latency Sensitivity (в свойствах виртуальной машины) в значении High. В этом случае планировщик гипервизора будет пытаться выделять для каждого vCPU виртуальной машины свое физическое ядро. Это так же означает, что на данном ядре не смогут исполняться другие виртуальные машины, а также, например, vmkernel. Если ему это удается, сетевые задержки значительно снижаются. Включение данной функции требует 100% резерв оперативной памяти для VM, а также (в зависимости от VMHardware) 100% резерв CPU;
- Даже если параметр Latency Sensitivity не включен для виртуальной машины, резерв CPU и оперативной памяти может помочь в снижении сетевых задержек;
- Использовать SR-IOV, DirectPath I/O, для придется пожертвовать основными функциями виртуализации, как уже было сказано ранее;
- Перевести Power Management в режим Maximum Performance, либо отключить его в BIOS. Отключить C1E и C-States в BIOS. Включить Turbo Boost.
Host-Wide Performance Tuning
Начиная с версии 6.0 в vSphere появилась функция Host-Wide Performance Tuning, она же Dense Mode, позволяющая оптимизировать хосты ESXi для размещения на них большого количества виртуальных машин.
При использовании Dense Mode, ESXi следит за количеством виртуальных машин, количеством vCPU и общей утилизацией процессора и в случае, если эти значения выше пороговых (количество VM больше количества физических ядер, количество виртуальных процессоров больше физических ядер в два раза и утилизация процессора выше 50%), хост начинает применять ряд оптимизаций в работе.
Поскольку данный режим работы может сказаться на обработке сетевого трафика и в некоторых случаях увеличить сетевые задержки, рекомендуется включать его только на тех хостах, где это действительно необходимо.
Стоит понимать. Что даже если этот режим переведен в «Enabled», активироваться он будет только при достижении пороговых значений, о которых было написано выше.
На этом мы заканчиваем серию постов про ресурсы гипервизора, а следующая тема будет посвящена оптимизации работы виртуальных машин.
Недавно вышел в свет один из важнейших документов, содержащий в себе концентрацию лучших практик для обеспечения производительной работы VMware vSphere с поправками на последнюю, седьмую, версию.
Данная серия постов, скорее, вырезка интересующих меня моментов из гайда, которыми можно поделиться с коллегами, с моими комментариями и дополнениями, но не в коем случае не попытка перевести полностью и дословно данный документ.
Мой перевод и понимание документа могут содержать неточности и, возможно, ошибки, поэтому в первую очередь настоятельно рекомендую самостоятельно ознакомиться с документом в его оригинальном виде.
В целом, документ состоит из большого количества секций. Я просто пойду сверху вниз по всем пунктам, которые интересуют меня, и могут быть полезны в первую очередь новичкам.
Первая часть «Hardware for Use with VMware vSphere» посвящается моментам, на которые необходимо обратить внимание при выборе серверного оборудования и начальной конфигурации.
Validate Your Hardware
Всегда необходимо проверять серверное оборудование, планируемое для использования под задачи виртуализации на совместимость с устанавливаемой версией vSphere. Проверять по Support Matrix необходимо все:
- HBA, NIC, CPU;
- Версии Firmware, драйвера;
- СХД, протокол подключения;
- Версии гостевых ОС.
Конечно, это не значит, что если в матрице совместимости отсутствует нужная прошивка, либо драйвер, модель CPU и т.п., то система не запустится, но вот в случае возникновения проблем, в технической поддержке могут и отказать до обновления на поддерживаемые версии компонентов.
При новых инсталляциях, рекомендуется тестировать ОЗУ в течение 72 часов, для выявления возможных ошибок.
CPU Hardware Considerations
Hardware-Assisted Virtualization
Большинство современных процессоров Intel и AMD включают в себя функции «помощи в виртуализации» и улучшают производительность виртуальной среды. Данные функции ниже:
- Hardware-Assisted CPU Virtualization (Intel VT-x and AMD-V™) – Осуществление виртуализации CPU;
- Hardware-Assisted MMU Virtualization (Intel EPT and AMD RVI) – Ведение таблицы соответствия физической памяти гостевой ОС и физической памяти хоста;
Программная реализация вышеуказанных функций не поддерживается VMware начиная с версии 6.7, теперь данную задачу должен полностью брать на себя процессор.
3. Hardware-Assisted I/O MMU Virtualization (VT-d and AMD-Vi) – Виртуализация устройств ввода-вывода (Сеть, HBA, GPU). К этому разделу относится, например, DirectPath I/O, SR-IOV.
Memory Hardware Considerations
Persistent Memory (PMem)
Планки энергонезависимой памяти, которые включаются в стандартные слоты DIMM. Дешевле, данные сохраняются при перезагрузке, большие объемы памяти, по сравнению с классической ОЗУ, обладают более низкой скоростью доступа. Пример – Intel Optane (DCPMM – DC Persistent Memory Modules), NVDIMM-N.
Intel Optane работает в двух режимах:
- Memory mode – DCPMM выступает для операционной системы как основная оперативная память. В этом случае «классическая ОЗУ» DRAM выступает в качестве кэша для DCPMM. Данный режим позволяет «сэкономить» на более дорогой DRAM, не без уменьшения скорости доступа. Производительность зависит от размера DRAM под кэш, как часто необходимо обращаться к ОЗУ и т.п. Подробнее.;
- App Direct Mode – В данном случае приложение, либо ОС понимает, что работает как с классической DRAM, так и с Persistent Memory, в связи с чем само выбирает, какую память использовать в конкретный момент. DCPMM может представляться в виртуальной машине виде классического диска (vPMEMDisk) также, как и устройство, выступающее в качестве виртуальной NVDIMM (vPMEM). В этом случае, гостевая операционная система должна понимать, что работает с NVDIMM памятью (PMem aware). Подробнее.
VMware рекомендует использовать режим App Direct как устройство vPMEM. Для получения максимальной производительности приложение должно быть PMem-aware, например, MS SQL Server 2019.
NVDIMM – тип Persistent Memory, работающий на тех же скоростях, что и DRAM, но сохраняет данные при перезагрузках. Всегда подключается в виртуальную машину как PMem и не может работать в режиме Memory Mode, как DCPMM.
В App Mode работает аналогично DCPMM как vPMEMDisk, либо как vPMEM. Подробнее.
Storage Hardware Considerations
В большинстве случаев, на итоговую работу дисковой подсистемы влияет не сколько конфигурация ESXi, сколько конфигурация СХД и сети передачи данных.
Производительность дисковой подсистемы зачастую зависит от множества факторов, включая уровень используемого RAID, типы дисков, размер кэш и т.п.
Перед непосредственным внедрением, крайне рекомендуется ознакомиться с документацией вендора СХД, а также с документацией VMware относительно работы системы виртуализации с СХД выбранного вендора.
- Стоит подумать на тему использования флэш памяти на хостах – SSD, NVME, что может помочь, например, со swap файлами;
- Если используются 4Kn диски, необходимо чтобы приложения и ОС так же были оптимизированы для работы с дисками 4K, иначе можно получить проблемы с производительностью;
- Если планируется использовать vSAN – будет неплохо рассмотреть all flash конфигурацию, как альтернативу гибриду;
- При дизайне сети передачи данных, нужно думать не только про логику, но и про физику. VLAN никак не спасет, если линк будет утилизирован на 100%;
- Если планируется использовать vVols – система хранения данных должна поддерживать vStorage API for Storage Awareness (VASA);
- Лучше – выделенные интерфейсы под сеть передачи данных, поскольку приложение, которое много пишет, может мешать другим, утилизировав весь линк;
- При использовании локального хранилища – включать Write-Back Cache, при этом контроллер должен быть оборудован батареей на случай отключения питания;
- Необходимо убедиться, что карты для подключения к сети СХД (NIC, HBA) установлены в соответствующие по скорости PCI слоты, например, FC HBA 32GB/s с одним портом установлен в слот PCIe Gen3 x4, в то время как FC HBA 32GB/s с двумя портами установлен в слот PCIe Gen3 x8. Данные карты обычно работают и в других слотах, однако получить максимальную производительность будет проблематично.
VMware vStorage APIs for Array Integration (VAAI)
Выбираем СХД, которая поддерживает VAAI, чтобы перенести выполнение некоторых дисковых операций с гипервизора ESXi на СХД.
В некоторых случаях использование VAAI снижает нагрузку на CPU гипервизора, поскольку теперь часть своей работы он перекладывает на СХД, снижается latency, уменьшается трафик в сети передачи данных.
Основные возможности VAAI для SAN:
- Scalable Lock (hardware-assisted locking, atomic test & set он же ATS). Используется при обновлении метаданных VMFS. Ранее, при изменении метаданных ненадолго, но блокировались обращения ко всему VMFS-тому. С использованием Scalable Lock эта проблема решается, блокируется только доступ к изменяемому элементу, но не ко всему Datastore. Выражается в ускорении многих операций, типа изменения конфигураций машин, снапшотов, расширения диско, увеличивается производительность «тонких» VMDK и т.п.;
- Extended Copy (XCOPY, copy offload) перекладывает операции по копированию (в рамках одной СХД) на систему хранения данных. Например, при клонировании машин, Storage vMotion. Снижает нагрузку на ESXi. Не будет работать при копировании\клонировании между двумя разными СХД;
- Block zeroing (Write Same) – «зануление» дисков thick provision eager-zeroed тоже перекладывается на СХД, уменьшая работу гипервизора;
- Dead space reclamation (UNMAP) – крайне полезная вещь, при использовании тонких LUN на СХД. Возвращает освобожденное на Datastore пространство обратно в СХД. Удалил виртуальную машину – стал меньше размером тонкий LUN на СХД (конечно, не моментально).
Основные возможности VAAI для NAS:
- Hardware-accelerated cloning – перекладываем клонирование на уровень СХД;
- Native Snapshot Support (Fast File Clone) – позволяет использовать снапшоты, либо linked clone используя встроенный механизм snapshot в СХД, вместо механизма снимков VMware. В документе указывается, что процедура создания снапшотов с помощью NAS может быть медленней, нежели выполнение того же самого средствами VMware;
- Reserve Space – Можно создавать не только тонкие диски, но и «толстые». VAAI NAS поддерживает lazy-zeroed thick и eager-zeroed thick.
Исходя из вышеуказанных возможностей VAAI для SAN и NAS, очевидно, что использование массивов с поддержкой данной технологии настоятельно рекомендуется.
iSCSI and NFS Storage
Убеждаемся, что у нас на сети нет узких мест, желательно, роутинга (точнее крайне настоятельно рекомендуется).
Держим в голове, что использование software-initiated iSCSI адаптера, а также NFS могут потребовать дополнительных ресурсов CPU на хосте, поскольку заниматься обработкой дискового трафика придется ему.
NVMe Storage
NVMe быстрее, но так же требует больше процессорных ресурсов. Рекомендуются к использованию многоядерные процессоры, хотя бы от 8 ядер. Больше процессоров – лучше, но хотя бы 2. С частотой так же – выше – лучше.
NVMe over Fabrics (NVMe-oF) Storage
Начиная с версии 7, ESXi поддерживает технологию NVMe-oF с помощью FC, либо RDMA в качестве транспорта.
NVMe-oF позволяет получить больше значения IOPS при меньших задержках.
Network Hardware Considerations
Убеждаемся, что мы используем «server-class» сетевые адаптеры для получения максимальной производительности. Убеждаемся, что на сети нет узких мест, все кабеля, коммутаторы работают на максимально доступных скоростях.
Так же рекомендуется использовать карты, поддерживающие функции Checksum offload, TSO, LRO, RSS, Jumbo и т.д. (если они, конечно, планируют использоваться).
По аналогии с HBA адаптерами, сетевые карты должны быть установлены в соответствующие PCI слоты, для получения максимально-доступной скорости приема/передачи.
Однопортовые 10Gb/s адаптеры рекомендуется устанавливать в слоты PCIe x8 (или выше), в то время как двухпортовые уже в PCIe x16.
При этом 40 гигабитные адаптеры следует устанавливать в PCI Gen3 x8/16 (либо выше).
По возможности, и крайне рекомендуется, чтобы виртуальный свитч vSwitch содержал адаптеры с одинаковой пропускной способностью.
Использование LACP может увеличить пропускную способность и доступность.
Hardware BIOS Settings
Всегда следует использовать последнюю версию BIOS, доступную для системы (но матрицу совместимости глянуть все равно стоит).
После обновления версии, следует проверить настройки BIOS, вдруг, ранее выставленные значения были изменены.
Добавлю от себя, что, если не знаешь, зачем нужен параметр, лучше его не изменять, чтобы не получить в дальнейшем проблем.
- Следует убедиться, что в BIOS задействованы все процессорные сокеты и все ядра на установленных процессорах, включен Hyper-Threading и Turbo Boost;
- Не стоит переводить Node Interleaving в параметр enabled (это отключит использование NUMA). Для использования NUMA – выставляем этот параметр в disabled, для использования UMA – enabled. В большинстве случаев, при правильном сайзинге виртуальных машин, с NUMA мы получим большую производительность;
- Необходимо убедиться, что все функции hardware-assisted virtualization включены (VT-x, AMD-V, EPT, RVI);
- Неплохим решением будет отключить в BIOS устройства, которые не используются. Например, USB, либо сетевые порты.
Power Management BIOS Settings
Не про употребление электропитанием сервера, а про управление питанием CPU.
Рекомендуется переложить управление питанием с плеч BIOS на плечи ESXi, и выставить в BIOS значение “OS Controlled Mode”, либо аналогичное.
C-States помогают экономить электроэнергию, переводя простаивающие процессоры в режим пониженного энергопотребления за счет приостановки работы его отдельных компонентов.
Всего таких уровней 6. Чем выше уровень – тем больше элементов процессора в режиме минимального энергопотребления.
Все выглядит прекрасно до тех пор, пока нагрузка не начинает расти и процессору необходимо перейти из состояния с отключёнными компонентами в полностью рабочее состояние (из режима C6 в C0). Этот переход занимает какое-то время, и это может сказаться на работе некоторых приложений. Подробнее.
Далее идет ряд рекомендаций по использованию C–States:
- Использование C1E (аппаратно-управляемое состояние) зачастую уменьшает потребление электроэнергии с минимальным, либо вообще без влияния на производительность. Однако, некоторые приложения, крайне чувствительные к I/O latency, например, финансовые платформы, могут быть к этому чувствительны. В таком случае рекомендуется отключение C1E в BIOS;
- C-States глубже чем C1 и C1E управляются программно. Чтобы получить максимальную производительность на ватт электроэенергии, рекомендуется оставить включенными все C-States, которые в дальнейшем будут управляться с помощью vSphere;
- При использовании технологии Turbo Boost или Turbo Core, использование C-States в некоторых ситуациях могут даже увеличить производительность некоторых немногопоточных приложений (в случае, если некоторые ядра процессора простаивают).
На этом раздел по «железной» части подходи к концу. В следующей части посмотрим на все, что касается раздела ESXi and Virtual Machines этого замечательного гайда.
I was recently toying with the idea of setting up a FreeNAS virtual machine on my ESXi 6.5 host. This would give me an alternative shared storage resource to add to my testing environment. With that in mind, I sat down and started looking around for recommendations and what not, on how to accomplish the task. Many of the posts I came across, recommended to go for passthrough, or passthru, technically known as DirectPath I/O. My original thought was to use RDM or a plain old vmdk and attach it to the FreeNAS VM.
The problem with the latter solution is mainly one of performance regardless of this being a testing environment. With DirectPath enabled, I can give the FreeNAS VM direct access to a couple of unused drives installed on the host. So, without giving it further thought, I went ahead and enabled pass-through on the storage controller on my testing ESXi host.
And here comes the big disclaimer. DO NOT DO THIS ON A LIVE SYSTEM. You have been warned!
This post exists for the sole reason of helping some poor soul, out there, to recover from what turned out to be a silly oversight. More to come on this.
Configure DirectPath I/O on an ESXi Host
There are a number of prerequisites for getting DPIO to work on your hosts. First of all you need to ensure that your ESXi host’s processor supports passthrough and that virtualisation support is enabled. You can check this in the vSphere client by browsing to your host, then the Configuration tab and Advanced Settings. If you see the message: “Host does not support passthrough configuration”, then you should check to see that the server’s BIOS is configured correctly.
Once you have made the necessary changes the ‘not supported’ message should be replaced by a message stating that there are “No devices currently enabled for passthrough.”:
So, now you can click Configure Passthrough , then s elect the devices to be configured for passthrough:
Select the device that you’re configuring passthrough on and click ok. Note: if you pick a device that ESXi is already using, you’ll be presented with a warning message. This might be very useful in the event that you accidentally pick the wrong device:
The devices should now appear as available for direct access. Note : If the device icons contain an orange arrow, you will need to reboot the host before the device can be assigned to a virtual machine:
Читайте также: