Performance Best Practices for VMware vSphere 5.0

Что я узнал из документа Performance Best Practices for VMware vSphere 5.0:

 

Железо

Сервера лучше с аппаратной поддержкой и процессора и памяти (т.е. последнего поколения). Не забыть убедиться что эти фичи включены в БИОСе. БИОС должен быть последней версии.
NUMA лучше держать включенной (в некоторых BIOS это значит node interleaving = disabled).
Hyperthreading лучше включить.
Стораджи лучше с поддержкой VAAI. Стораджи вообще чрезвычайно важны, и к их выбору и настройке стоит подойти ответственно.
Рекомендуется повышать глубину очереди на HBA до максимума (http://kb.vmware.com/kb/1267).
Так же можно попробовать увеличить максимальное количество одновременных запросов на диск для каждой ВМ – http://kb.vmware.com/kb/1268.
С точки зрения дисковой подсистемы, лучше отключать всякие Power Managment функции (в ESXi и в БИОСе) – это может помочь уменьшить latency. А в следующей секции выясняется что и с точки зрения задержек сети это тоже рекомендуется.
Кстати, тут я узнал почему overhead, накладные расходы памяти, в пятерке заметно ниже чем в четверке. Оказывается, чтобы уменьшить объем памяти, резервируемый под обслуживание виртуального железа, стал создаваться отдельный файл подкачки, вида vmx-vmname.vswp.
Упоминается, что типы виртуальных дисков есть разные – но рекомендаций не дается . Разве что “без снапшотов лучше”.
Я уже слышал об этом, но увидел здесь подтверждение -

New for vSphere 5.0, when ESXi is running on certain configurations of the Cisco Unified Computing
System (UCS) platform, DirectPath I/O for networking is compatible with vMotion, physical NIC sharing,
snapshots, and suspend/resume. It is not compatible with Fault Tolerance, NetIOC, memory overcommit,
VMCI, or VMSafe.

В случае если на ESXi работают несколько ВМ, получающие мультикаст трафик от одного источника – можно правкой конфига ВМ включить новую фичу SplitRX, оптимизирующую обработку сетевого стека, задействуя сразу несколько процессоров.
Если велики задержки в сети, можно попробовать использовать виртуальные сетевушки vmxnet3, но отключить для них “virtual interrupt coalescing”.

 

Гостевые ОС

VMware tools  - хорошо. Скринсейверы и прочие свистелки и перделки – плохо.
Якобы, в пятой версии улучшен механизм синхронизации времени через VMware tools. Ранее он выступал в качестве “лучше он чем ничего, хоть он и с тараканами”, а сейчас

“As of the version included in ESXi 5.0, the VMware Tools time-synchronization option is a suitable
choice. Versions prior to ESXi 5.0 were not designed for the same level of accuracy and do not adjust the
guest time when it is ahead of the host time.”

Если вдруг у вас будут ВМ с большим количеством виртуальных процессоров\ядер (восемь и больше), то их количество имеет смысл выставлять кратным числу физических ядер в одном NUMA-узле (разумеется, актуально лишь для серверов на NUMA платформах Opteron и Nehalem). Это связанно с тем, что ESXi 5 пытается создать виртуальный сервер тоже архитектуры NUMA. Большой разницы в производительности ждать не приходиться, но оптимальнее не мешать ему транслировать NUMA внутрь. Итак, у нас есть ВМ с 12 vCPU. Рекомендуется или дать ей 12 одноядерных vCPU, или пропорционально меньше vCPU но в каждом ядер столько же, сколько у физического NUMA узла.
У гостевых ОС могут быть собственные мнения по некоторым параметрам работы дисковой подсистемы. Один из факторов – максимальный размер одного блока IO. Если это значение маловато, это может привести к снижение производительности дисковой подсистемы. Может быть, его стоит увеличить.
К сожалению, в этом pdf за подробностями ссылаются на  http://kb.vmware.com/kb/9645697, в этой статье базы знаний за подробностями ссылаются на http://www.lsi.com/DistributionSystem/AssetDocument/documentation/insight_center/tech_trends/fusionmpt/FusionMPT_DevMgrUG.pdf . а туда меня не пустили без регистрации, которая не заработала.
Выравнивание файловой системы гостя – это хорошо. Напомню пару ссылок – что такое alligment, утилита для этого выравнивания уже существующих ВМ - Paragon Alignment Tool(TM) 3.0 can remote align partitions on VMs.
С точки зрения сети лучше использовать vNIC типа vmxnet 3 (на худой конец vmxnet 2, если третья версия не поддерживается для гостевой ОС. Ну или flexible если не поддерживается enhanced vmxnet).
Jumbo Frames для пятой версии поддерживаются vmxnet2,3, e1000.

Инфраструктура

Reservation, Limit и Shares надо использовать только если в них явно есть нужда.
Для базы данных vCenter есть следующие рекомендации:

Update statistics of the tables and indexes on a regular basis for better overall performance of the
database.
As part of the regular database maintenance activity, check the fragmentation of the index objects and
recreate indexes if needed (i.e., if fragmentation is more than about 30%).

Если под БД используется Microsoft SQL, то рекомендуется использовать recovery mode = Simple.
vCenter Web Client Server нормально установить на ту же машину, что и сам vCenter, если серверов под управлением vCenter меньше 33.
DRS запускает обсчет ситуации раз в 5 минут. Можно, хотя и не нужно , изменить это значение в конфигурационном файле vCenter – vpxd.cfg:

<config>
    <drm>
        <pollPeriodSec>
            300
        </pollPeriodSec>
    </drm>
</config>