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

[@EminH]

И vCenter и его БД не должны испытывать недостатка ресурсов.

А насколько это влияет на производительность виртуальных машин? vCenter же нужен только для управления/настройки и, насколько я знаю, даже если vCenter упадет все будет работать и без него. Или не так?

[@kabal375]

Влияет опосредованно. Если vCenter в коме, менеджмент затруднён, а значит в случае перепадов и скачков нагрузки, DRS не сможет своевременно перебалансировать кластер. Да и вообще оценить, что надо перебалансировать, потому что статистика будет собираться местами и не вся.
Кроме того, любые изменения фиксируются через vCenter в базе. То есть создание и удаление машин, миграции, вывод в мэйнтенанс, изменения сетей, обновление инвентори и прочее. И если база будет долго думать над каждым запросом, процесс обслуживания превратится в каторгу.

[@gotch]

Вот по процессору есть дополнение. Вы в консоли сервера с огромным дискомфортом будете работать, если у вас будет 1 vCPU с утилизацией хотя бы 60. Плюс с такой средней утилизацией у вас, вероятнее всего, будут пики на 100%, и за 100% с образованием очереди, и хорошо если клиентское приложение это не замечает. По мне гораздо комфортнее 4 vCPU с утилизацией 20-40%, чем 1 на 80% или 2 на 60%.
Насколько это «вредно» для хоста надо смотреть в каждом конкретном случае, зависит и от плотности машин, и от архитектуры, числа процессоров и т.д.

[@kabal375]

Предполагается, что люди не работают в консоли сервера, в основном.
Ну и да, описано идеальное состояние, когда всегда 80% и всегда 20%. Без пиков. На деле-то понятно, что смотреть надо.
Просто запросы приходят на 8-16-24, а то и 32 процессора просто потому что у физического было 32 ядра раньше. Потом мониторишь, а там 2 ядра загружены на 60%, а остальные на 5-10%. И CPUReady адовый. У всех машин на хосте.
Благо, где сейчас работаю, уже более менее грамотные стали, больше 8 не требуют. Хотя и 8 зачастую — много.

[@gotch]

Звучит вполне разумно. Честно говоря, я с 8 видел машину только однажды, это был непомерно нагруженный MS SQL Server. Ему и их не хватало.

Вспомнил второй случай. Пачка CAS-серверов MS Exchange 2010. Еле жили на 4-х, при 60% загрузке, постоянно жалобы на медленную синхронизацию и отпадание Outlook. Довели до 8 — и число жалоб резко снизилось.

Зато вторая крайность — 1 vCPU, регулярно. Кто-то экономит «ресурсы». Кто-то деньги на хостинге в датацентре. Но во всех случаях, обычно ничего хорошего не происходит. Как не крути, если мы говорим о Windows, разработчики Microsoft ожидают, что у вас будет минимум два CPU, а вероятнее всего 4. Не стоит их разочаровывать и в виртуальной среде.

[@navion]

Зависит от предназначения и конкретных сервисов, у нас для функциональных стендов обычно хватает одного ЦП. Проблемы возникают с нагруженными многопоточными приложениями (тот же Exchange).

[@gotch]

По дисковой. Действительно, банальное обновление антивирусных баз может легко «приложить» storage на традиционных жестких дисках. Для решения этой проблемы можно играть расписанием обновления, а вот Kaspersky сделал опцию обновления баз в RAM.
support.kaspersky.ru/11942

Казалось бы мелочь, но монитор latency датасторов стал срабатывать в несколько раз реже.

[@kabal375]

У нас в VDI-ферме это особенно заметно. Даже агент SCCM прикладывал VNX до потери датасторов.
Жаль, что Касперский сделал эту фичу только в серверных версиях.

[@gotch]

Так, и что делать? Только SSD для VDI?

[@kabal375]

Ох, столько всего проделали…

• Убрали всё лишнее с VNX, размазали датасторы по всему объёму — теперь много неиспользованного места, но и latency ниже.
• Стандартные 4 (с 22:00 по 2 часа) окна обслуживания для установки обновлений пришлось ещё раскромсать до 8 — теперь второе окно стартует через час после первого, а не дожидаясь окончания, поскольку пик по IOPS приходится на первые пол часа, а потом линейно падает.
• Добавили памяти ВМ — уменьшился свопинг.
• Настроили BITS, чтоб обновления тянулись в течение рабочего дня, но медленно (4 кб/с).
• Долго и вдумчиво настраивали касперского и его обновления.
• Ну и тюнинг со стороны гипервизоров.

Чёрт, я забыл про SIOC в статье…

[@gotch]

Спасибо, что навели на вашу статью, еще не все их прочитал. )
Скажите, а вы тоже видите на примере IBM SVC значительное падение производительности на VMFS по сравнению с RDM? Столкнулись с этим на старой HP EVA, по замерам sqlio разница около 30%.

[@kabal375]

Да, именно потому вытащили из SVC все датасторы (и остальное планируем).
В нашем случае это из-за того, что почему-то версия прошивки svc не совместима с ATS из VAAI, а также из-за того, что «интеллектаульность» svc ниже размещённых за ней стораджей (emc).

[@nickolazz]

Если речь об антивирусе в среде VDI, то возможно стоит попробовать vmware vsphere endpoint + тот же kaspersky.
Говоря кратко — это agentless антивирус для всех машин, запущенных на хосте. А «в целом» я использую и SSD и HDD, all flash по прежнему очень дорого.

[@DartRaven]

А не поделитесь опытом использования VMWare Virtual SAN, если таковой есть?

[@kabal375]

Такого опыта, к сожалению, нет. Текущую инфраструктуру переводить очень накладно и непонятно, ради чего.

[@nickolazz]

У меня есть пилотный проект на vSAN 5.5. Ну-у-у… Интересно, но дорого. Всегда нужно держать в уме ряд ограничений — в большинстве проектов, с которыми я связан, используются блейд-сервера, а вот vSAN пришлось строить на 3xHP DL380(2xSSD+6HDD на сервер). Работает хорошо(!!! в моем окружении!!!), НО в качестве эксперимента я отключал две ноды из трех(а так лучше не делать), после чего vsan обратно уже не собрался даже с напильником:-) Так что vsan — это вопрос денег, железа, и требований вашего проекта.

[@DartRaven]

Итого, как я понимаю, лучше всё-таки честная отдельная СХД.

[@kabal375]

Если у вас всего три хоста, возможно, более подходящим будет vSAN.
Ну или четвёртый хост в качестве iSCSI-таргета :)

[@navion]

Я бы ещё добавил включение и тюнинг TPS на хостах с VDI и стендами.

[@kabal375]

Как показал опыт, TPS имеет смысл использовать только на VDI и только при нехватке памяти. Нагрузка на процессор получается заметная.
После очередного обновления, добавляющего соль в блоки памяти и убивающего TPS под корень, мы решили перестать за неё держаться, раз сам вендор её использование затрудняет. К тому же освободилась пара дополнительных хостов…
Реально практичнее добавить памяти или хостов в кластер. А до этого использовать TPS в качестве временной меры.

[@navion]

У меня основная нагрузка — это функциональные стенды разработчиков и там всегда дефицит оперативки, а процессор почти не загружен. Сейчас TPS с отключенными большими страницами экономит 15-20% опертивки в полностью забитых серверах.

[@kabal375]

Тоже верно.
Главное чтоб ВМ в хостах были схожей конфигурации и со схожей нагрузкой. Иначе очень мало получается «общих страниц». По сути, только пустые.

[@navion]

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

К настройкам энергосбережения стоит подходить с осторожностью — при неудачном стечении обстоятельств могут появиться пурпурные экраны в простое. А вендоры будут играть в пинг-понг, так как все тесты система проходит.

[@alexkuzko]

Раз уж затронули такой важный вопрос как производительность, то может стоит глубже проанализировать нюансы с настройкой локальных дисковых массивов?

Столкнулся со странной проблемой, когда при тесте скорости чтения/записи (но первично именно чтение) внутри виртуалки все хорошо, а вот если читать файл напрямую с ESXi (в консоли), то скорость в районе 33 Мб/сек (как USB 2.0 почти!) и никак выше не выходит. Что по сети, что локально (например через dd).

Заметил это когда пытался использовать Veeam для бекапа с ESXi и обнаружил катастрофическое падение скорости по сравнению с сервером на Hyper-V. Скорости 20-30 Мб/сек против 76 Мб/сек (почти гигабит) у Hyper-V. Тестировал сеть между ESXi серверами — она около 800 мегабит, т.е. в сеть не упираемся. Все исключительно из-за дисковой. Которая представляет собой RAID10 массив из SAS дисков на контроллере P410.

Куда копать, что смотреть? Думаю что не только я буду вам благодарен!

[@reff]

У Veeam есть FastSCP. Попробуйте копировать файлы с его помощью.

[@alexkuzko]

В самом Veeam Backup & Replication нет вариантов как делать бекапы с ESXi. Только один способ, да включение/выключение CBT (блочный трекинг).
Возможно, проблема больше в Veeam, чем в ESXi, но хотелось бы понять можно ли изменить ситуацию на стороне ESXi.

[@navion]

Скорость в консоли не говорит ни о чем, а вот бекап через даже через NBD должен работать шустрее.
У вас ведь полная версия B&R и платный ESXi?

[@beststoragename]

В качестве существенного изменения в 6.0 я бы упомянул возможность использования virtual volumes (VVOLs). Дисковый массив теперь может обрабатывать данные определенного виртуального сервера, а не всех, распожённых на одном LUNe серверов. Этот функционал повлияет не только на производительность, но и методы создания снимков, копий данных и репликации.