Как стать автором
Обновить

Производительность VMware vSphere 5.5 и 6.0 — настройки, соображения. Perfomance Best Practices

Время на прочтение 8 мин
Количество просмотров 58K

Проштудировав документы Perfomance Best Practices for vSphere 5.5 и Perfomance Best Practices for vSphere 6.0, не выявил особых расхождений в настройке, как и чего-то дополнительно специфичного для vSphere 6.0.

Большая часть написанного умещается в стандартные рекомендации формата «используйте совместимое и сертифицированное оборудование» и «при сайзинге ВМ выделяйте ресурсы (vCPU, vRAM) в объёме не более необходимого».

Тем не менее, базовые вещи решил оформить отдельным постом, немного переструктурировав, избавив от «воды» и некоторых отсылок и замечаний, которые являются слишком специфичными и для большинства реализаций являются скорее вредными чем полезными. В сухом остатке остались рекомендации, советы и соображения, проверенные и протестированные на практике и применимые для 90% инфраструктур VMware vSphere и standalone ESXi. Разбавленные общими соображениями и дополнениями.

Хост ESXi


Общие рекомендации

  • Ну понятно, стоит использовать совместимое оборудование. Процессоры с аппаратной поддержкой виртуализации. Процессоры в разных хостах кластера должны быть минимум одного производителя (Intel/AMD) а желательно и одного уровня технологий и поколения. Иначе проблемы с vMotion и производительностью. И желательно вообще единообразие в аппаратной конфигурации кластера — проще управлять (Host Profiles) и диагностировать.
  • Установить свежие версии BIOS и firmware на все «железки». Не обязательно это скажется на росте производительности, но в случае проблем на стыке железо-софт техподдержка вендора всё равно будет требовать обновления прошивок. Мы с IBM так почти год чинили Blade-корзину — пока обновили прошивки на всех задействованных и не очень компонентах, они выпустили их новые версии и пришлось идти по второму кругу.


BIOS

  • Убедиться, что включены все необходимые и полезные компоненты и технологии — ядра процессора, Turbo Boost, если есть, технологии виртуализации (VT-x, EPT, AMD-V и т.п.).
  • Отключена опция NUMA Node Interleaving или включена опция Enable NUMA. Данный пункт часто вводит в заблуждение. ESXi — NUMA-awared ОС, более того, она умеет транслировать NUMA-архитектуру в виртуальные машины, так что включение возможности распознавать NUMA-ноды сказывается положительно на общей производительности в большинстве случаев. Однако опция «NUMA Node Interleaving», будучи в состоянии «Enable» на деле объединяет ноды в единое пространство, то есть отключает распознавание NUMA-нод.
    NUMA
    /NUMA — Non-Uniform Memory Access — архитектура серверных систем, при которой время доступа к памяти определяется размещением её относительно процессора. У каждого процессора свой набор модулей памаяти, куда доступ быстрее, этот комплект и образует NUMA-ноду./
  • Отключить неиспользуемые устройства. Это освободит прерывания и немного разгрузит процессор.
  • Включить Hyper-Threading (если есть). В этом случае vCPU назначаются по логическим ядрам и в большинстве случаев это приводит к оптимизации использования процессорных ресурсов.
  • CPU Power Saving — OS Controlled mode. Или что-то аналогичное. Если поддерживается. ESXi — имеет полный набор средств для управления питанием сервера. И лучше отдать этот вопрос на откуп гипервизору, если хочется быть уверенным, что он не скажется на производительности негативно.


Гипервизор

Тут стоит иметь ввиду, что и по процессору и по памяти для каждой виртуальной машины есть определённый оверхед — дополнительное количество того и другого, необходимое для работы самой ВМ:

— для процесса vmx (VM eXecutable);
— для процесса vmm (VM Monitoring) — мониторинг состояния виртуального процессора, маппинг — виртуальной памяти и т.д.;
— для работы виртуальных устройств ВМ;
— для работы других подсистем — kernel, management agents.

Оверхед каждой машины более всего зависит от количества её vCPU и объёма памяти. Сам по себе он не большой, но стоит иметь ввиду. Например, если весь объём памяти хоста будет занят или зарезервирован виртуальными машинами, то может увеличиться время отклика на уровне гипервизора, а также возникнут проблемы с работой таких, например, технологий как DRS.

Виртуальные машины


Главная рекомендация — сайзинг по минимуму. В смысле — выделять виртуальной машине не больше памяти и процессоров, чем ей реально нужно для работы. Ибо в виртуальной среде больше ресурсов зачастую приводят к худшей производительности, чем меньше. Это сложно понять и принять сразу, но это так. Основные причины:

— оверхед, описанный в предыдущем разделе;
— NUMA. Если количество vCPU соответствует количеству ядер в NUMA-сокете и объём памяти тоже не выходит за пределы NUMA-ноды, то гипервизор старается локализовать ВМ внутри одной NUMA-ноды. А значит доступ к памяти будет быстрее;
— Планировщик процессора. Если на хосте много ВМ с большим количеством vCPU (больше в сумме, чем количество физических ядер), то растёт вероятность появления такого явления как Co-Stop — притормаживание некоторых vCPU из-за невозможности обеспечить их синхронную работу в рамках отдельной ВМ, потому что количества физических ядер не хватает для одновременного цикла;
— DRS. Машины с небольшим количеством процессоров и памяти переносить с хоста на хост проще и быстрее. В случае внезапного скачка нагрузки легче будет перебалансировать кластер, если он состоит из небольших ВМ, а не из многогигабайтных монстров;
— Локализация кэша. Внутри ВМ гостевая ОС может переносить однопоточные процессы между различными процессорами и терять процессорный кэш.

Выводы и рекомендации:

  • Лучше один процессор, загруженный на 80%, чем 4 по 20%.
  • Если у сервера пиковая загрузка происходит раз в квартал, а в остальное время он работает на 10% своих ресурсов, лучше урезать их (ресурсы) сразу в 8 раз, а раз в квартал добавлять необходимое количество.
  • Стараться умещать ВМ по количеству vCPU и памяти в границы NUMA-node.
  • Если ВМ выходит за пределы NUMA-ноды (wide VM), конфигурировать число процессоров кратное числу ядер в NUMA-ноде. Если у нас в одном сокете 4 ядра, то кратные числа процессоров, рекомендуемые для ВМ будут 4, 8, 12...
  • При использовании нескольких vCPU, лучше конфигурировать их как отдельные виртуальные сокеты с одним виртуальным ядром в каждом. Ну или с количеством ядер, являющимся целым делителем от числа ядер в NUMA. Если в физическом сокете 4 ядра, то в виртуальном правильным значением будет 1, 2, 4. Но не 3 или 6.
  • Отключать неиспользуемое виртуальное оборудование виртуальной машины (COM-, LPT-, USB-порты, Floppy Disks, CD/DVD, сетевые интерфейсы и т.д.)
  • Использовать паравиртуальное оборудование (VMware Paravirtual для SCSI-контроллера и VMXNET для сетевого адаптера). Это уменьшает нагрузку на процессор и время отклика, но может потребовать драйвера для установки ОС.


Гостевая ОС



  • Использовать последние версии VMware Tools. После каждого обновления ESXi приводить в соответствие.
  • И вообще иметь установленными VMware Tools.
  • Отключать screen saver'ы и вообще любую анимацию и красивости. По возможности отключать графику. Это значительно снижает нагрузку на процессор.
  • Избегать одновременного запуска интенсивных задач (таких как антивирусное сканирование, бэкапы и особенно дефрагментация). Дефрагментацию лучше вообще отключить. Остальное, если нельзя избежать, размазывать для разных машин в разное время.
  • Синхронизировать время гостевой ОС с помощью ntp-сервисов или VMware Tools, но не обоих инструментов сразу. Но хотя бы одним. Так как стоит иметь ввиду, что время в гостевой ОС — не точная величина, поскольку зависит от процессора, а процессорного ресурса ВМ может получать не равномерно и не всегда в нужном объёме.
  • vNUMA. Стоит принимать во внимание, что для ВМ с количеством vCPU большим восьми активируется проброс NUMA-архитектуры внутрь ВМ. Для некоторых NUMA-awared приложений, например, Exchange или MS SQL это полезно. Однако vNUMA определяется при первой загрузке ОС и не меняется, пока не изменится количество процессоров. Поэтому, если в кластере наличествуют хосты с разным количеством ядер в сокетах, а значит с разной NUMA-архитектурой, то при переезде ВМ с хоста на хост, производительность может падать из-за того что vNUMA не совпадает с NUMA на новом хосте.


Хранение и хранилища


Главное, что стоит принять во внимание — ваше хранилище должно поддерживать vStorage API for Array Integration (VAAI). В этом случае будет поддерживаться следующее:

— Оффлоад процессов копирования, клонирования и переноса ВМ между LUN одного хранилища или между хранилищами, поддерживающими технологию. То есть процесс будет выполняться большей частью самим хранилищем, а не процессором хоста и сетью.
— ускорение зануления блоков при создании Thick Eager Zeroed дисков и при первичном наполнении Thick Lazy Zeroed и Thin дисков.
— Atomic Test and Set (ATS) — блокирование не всего LUN, при изменении метаданных, а только одного сектора на диске. Учитывая, что метаданные изменяются при таких процессах как включение/выключение ВМ, миграция, клонирование и расширение тонкого диска, LUN с большим количеством ВМ на нём может не вылезать из SCSI Lock'а.
— Unmap — «освобождение» блоков тонких LUN при удалении/переносе данных (касается только LUN, но не vmdk).

Соображения и рекомендации:

  • Independent Persistent Mode vmdk-диска — наиболее производительный, поскольку изменения вносятся сразу на диск, не журналируясь. Но такой диск не подвержен снапшотам, его нельзя откатить.
  • При использовании iSCSI рекомендуется настроить jumbo frames (MTA=9000) на всех интерфейсах и сетевом оборудовании.
  • MultiPathing — для большинства случаев RoundRobin — ОК. Fixed может дать большую производительность, но это после вдумчивого планирования и ручной настройки каждого хоста до каждого LUN. MRU можно поставить при active-passive конфигурации, если какие-то пути время от времени пропадают — чтобы не перескакивало туда-обратно.


Инфраструктура виртуализации


DRS и кластеры

  • Для управления ресурсами и контроля их использования, лучше использовать Shares в большей мере, а Limits и Reservation — в меньшей. Лимиты жёстко ограничивают ВМ, даже если кластер имеет свободные ресурсы. Резервирование, напротив, отъедает много ресурсов, даже если они не используются. Кроме того, при апгрейде физического оборудования настройки Shares автоматически распределяют новые мощности пропорционально. А забытые лимиты и резервирование могут привести к тому, что часть машине недополучает ресурсов, хотя в кластере их уже более чем достаточно.
  • Не стоит сооружать сложные многоступенчатые иерархические конструкции из Resource Pools. Для иерархий есть папки. А также держать на одном уровне (например, в корне) и Resource Pools и виртуальные машины. Потому что расчёт Shares для этих типов объектов производится по разному и могут появляться непредвиденные перепады производительности.
  • Ещё раз — чем ближе хосты друг другу по конфигурации, тем лучше. В идеале — в кластеры все хосты однотипные. Без EVC даже на хосты с процессорами одного вендора, но разным набором технологий ВМ перемещаться смогут только в выключенном состоянии.


vMotion и Storage vMotion

По умолчанию, на каждый активный процесс vMotion гипервизор отъедает 10% одного ядра процессора. И на приёмнике и на источнике. То есть если на хосте все процессорные ресурсы находятся в резервировании, с vMotion могут быть проблемы. (С DRS точно будут).

При Storage vMotion с исходного датастора активно идёт чтение, а на целевой — запись. Кроме того, на оба датастора идёт синхронная запись изменений внутри ВМ. Отсюда вывод — если двигаем ВМ с медленного датастора на быстрый, эффект будет заметен только по окончанию миграции. А если с быстрого на медленный, то деградация производительности наступит сразу.

vCenter Server

  • Минимум хопов между сервером vCenter и его БД. Желательно чтоб оба сервера были в одной сети.
  • И vCenter и его БД не должны испытывать недостатка ресурсов.
  • В БД сама база генерирует, в основном, случайное чтение, а логи — последовательную запись. Отсюда то и другое лучше положить на разные LUN. Лучше даже, если и пути до них будет разные (разные контроллеры или массивы). Или разные диски, как минимум.
  • Также отдельно стоит положить tempDB.
  • Стоит регулярно обновлять статистику таблиц и индексов в базе и избавляться от фрагментации.
  • Закрывать сессии клиентов (и толстых и веб), если они не используются — отъедают много ресурсов на обновление inventory.
  • Если в инфраструктуре больше 30 хостов и/или 300 ВМ, базу данных компонента Update Manager лучше вынести отдельно от БД vCenter.
  • Если в инфраструктуре больше 100 хостов и/или 1000 ВМ стоит вынести отдельно и сам Update Manager
  • Если в инфраструктуре больше 32 хостов и/или 4000 ВМ стоит отделить компонент Web-client Server.
Теги:
Хабы:
+8
Комментарии 28
Комментарии Комментарии 28

Публикации

Истории

Работа

DevOps инженер
39 вакансий

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн