Проштудировав документы 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.
Комментарии (28)
gotch
29.07.2015 13:04Вот по процессору есть дополнение. Вы в консоли сервера с огромным дискомфортом будете работать, если у вас будет 1 vCPU с утилизацией хотя бы 60. Плюс с такой средней утилизацией у вас, вероятнее всего, будут пики на 100%, и за 100% с образованием очереди, и хорошо если клиентское приложение это не замечает. По мне гораздо комфортнее 4 vCPU с утилизацией 20-40%, чем 1 на 80% или 2 на 60%.
Насколько это «вредно» для хоста надо смотреть в каждом конкретном случае, зависит и от плотности машин, и от архитектуры, числа процессоров и т.д.
kabal375 Автор
29.07.2015 13:24+1Предполагается, что люди не работают в консоли сервера, в основном.
Ну и да, описано идеальное состояние, когда всегда 80% и всегда 20%. Без пиков. На деле-то понятно, что смотреть надо.
Просто запросы приходят на 8-16-24, а то и 32 процессора просто потому что у физического было 32 ядра раньше. Потом мониторишь, а там 2 ядра загружены на 60%, а остальные на 5-10%. И CPUReady адовый. У всех машин на хосте.
Благо, где сейчас работаю, уже более менее грамотные стали, больше 8 не требуют. Хотя и 8 зачастую — много.gotch
29.07.2015 13:37Звучит вполне разумно. Честно говоря, я с 8 видел машину только однажды, это был непомерно нагруженный MS SQL Server. Ему и их не хватало.
Вспомнил второй случай. Пачка CAS-серверов MS Exchange 2010. Еле жили на 4-х, при 60% загрузке, постоянно жалобы на медленную синхронизацию и отпадание Outlook. Довели до 8 — и число жалоб резко снизилось.
Зато вторая крайность — 1 vCPU, регулярно. Кто-то экономит «ресурсы». Кто-то деньги на хостинге в датацентре. Но во всех случаях, обычно ничего хорошего не происходит. Как не крути, если мы говорим о Windows, разработчики Microsoft ожидают, что у вас будет минимум два CPU, а вероятнее всего 4. Не стоит их разочаровывать и в виртуальной среде.
navion
29.07.2015 18:49Зависит от предназначения и конкретных сервисов, у нас для функциональных стендов обычно хватает одного ЦП. Проблемы возникают с нагруженными многопоточными приложениями (тот же Exchange).
gotch
29.07.2015 13:07По дисковой. Действительно, банальное обновление антивирусных баз может легко «приложить» storage на традиционных жестких дисках. Для решения этой проблемы можно играть расписанием обновления, а вот Kaspersky сделал опцию обновления баз в RAM.
support.kaspersky.ru/11942
Казалось бы мелочь, но монитор latency датасторов стал срабатывать в несколько раз реже.kabal375 Автор
29.07.2015 13:29+1У нас в VDI-ферме это особенно заметно. Даже агент SCCM прикладывал VNX до потери датасторов.
Жаль, что Касперский сделал эту фичу только в серверных версиях.gotch
29.07.2015 13:40Так, и что делать? Только SSD для VDI?
kabal375 Автор
29.07.2015 13:56+1Ох, столько всего проделали…
- Убрали всё лишнее с VNX, размазали датасторы по всему объёму — теперь много неиспользованного места, но и latency ниже.
- Стандартные 4 (с 22:00 по 2 часа) окна обслуживания для установки обновлений пришлось ещё раскромсать до 8 — теперь второе окно стартует через час после первого, а не дожидаясь окончания, поскольку пик по IOPS приходится на первые пол часа, а потом линейно падает.
- Добавили памяти ВМ — уменьшился свопинг.
- Настроили BITS, чтоб обновления тянулись в течение рабочего дня, но медленно (4 кб/с).
- Долго и вдумчиво настраивали касперского и его обновления.
- Ну и тюнинг со стороны гипервизоров.
Чёрт, я забыл про SIOC в статье…gotch
29.07.2015 15:39Спасибо, что навели на вашу статью, еще не все их прочитал. )
Скажите, а вы тоже видите на примере IBM SVC значительное падение производительности на VMFS по сравнению с RDM? Столкнулись с этим на старой HP EVA, по замерам sqlio разница около 30%.kabal375 Автор
29.07.2015 16:20Да, именно потому вытащили из SVC все датасторы (и остальное планируем).
В нашем случае это из-за того, что почему-то версия прошивки svc не совместима с ATS из VAAI, а также из-за того, что «интеллектаульность» svc ниже размещённых за ней стораджей (emc).
nickolazz
29.07.2015 15:02Если речь об антивирусе в среде VDI, то возможно стоит попробовать vmware vsphere endpoint + тот же kaspersky.
Говоря кратко — это agentless антивирус для всех машин, запущенных на хосте. А «в целом» я использую и SSD и HDD, all flash по прежнему очень дорого.
DartRaven
29.07.2015 16:04А не поделитесь опытом использования VMWare Virtual SAN, если таковой есть?
kabal375 Автор
29.07.2015 16:16Такого опыта, к сожалению, нет. Текущую инфраструктуру переводить очень накладно и непонятно, ради чего.
nickolazz
29.07.2015 16:41У меня есть пилотный проект на vSAN 5.5. Ну-у-у… Интересно, но дорого. Всегда нужно держать в уме ряд ограничений — в большинстве проектов, с которыми я связан, используются блейд-сервера, а вот vSAN пришлось строить на 3xHP DL380(2xSSD+6HDD на сервер). Работает хорошо(!!! в моем окружении!!!), НО в качестве эксперимента я отключал две ноды из трех(а так лучше не делать), после чего vsan обратно уже не собрался даже с напильником:-) Так что vsan — это вопрос денег, железа, и требований вашего проекта.
navion
29.07.2015 18:37+1Я бы ещё добавил включение и тюнинг TPS на хостах с VDI и стендами.
kabal375 Автор
30.07.2015 09:38+1Как показал опыт, TPS имеет смысл использовать только на VDI и только при нехватке памяти. Нагрузка на процессор получается заметная.
После очередного обновления, добавляющего соль в блоки памяти и убивающего TPS под корень, мы решили перестать за неё держаться, раз сам вендор её использование затрудняет. К тому же освободилась пара дополнительных хостов…
Реально практичнее добавить памяти или хостов в кластер. А до этого использовать TPS в качестве временной меры.navion
31.07.2015 14:57+1У меня основная нагрузка — это функциональные стенды разработчиков и там всегда дефицит оперативки, а процессор почти не загружен. Сейчас TPS с отключенными большими страницами экономит 15-20% опертивки в полностью забитых серверах.
kabal375 Автор
31.07.2015 15:00Тоже верно.
Главное чтоб ВМ в хостах были схожей конфигурации и со схожей нагрузкой. Иначе очень мало получается «общих страниц». По сути, только пустые.
navion
29.07.2015 19:16И лучше отдать этот вопрос на откуп гипервизору, если хочется быть уверенным, что он не скажется на производительности негативно.
К настройкам энергосбережения стоит подходить с осторожностью — при неудачном стечении обстоятельств могут появиться пурпурные экраны в простое. А вендоры будут играть в пинг-понг, так как все тесты система проходит.
alexkuzko
29.07.2015 23:59Раз уж затронули такой важный вопрос как производительность, то может стоит глубже проанализировать нюансы с настройкой локальных дисковых массивов?
Столкнулся со странной проблемой, когда при тесте скорости чтения/записи (но первично именно чтение) внутри виртуалки все хорошо, а вот если читать файл напрямую с ESXi (в консоли), то скорость в районе 33 Мб/сек (как USB 2.0 почти!) и никак выше не выходит. Что по сети, что локально (например через dd).
Заметил это когда пытался использовать Veeam для бекапа с ESXi и обнаружил катастрофическое падение скорости по сравнению с сервером на Hyper-V. Скорости 20-30 Мб/сек против 76 Мб/сек (почти гигабит) у Hyper-V. Тестировал сеть между ESXi серверами — она около 800 мегабит, т.е. в сеть не упираемся. Все исключительно из-за дисковой. Которая представляет собой RAID10 массив из SAS дисков на контроллере P410.
Куда копать, что смотреть? Думаю что не только я буду вам благодарен!
reff
30.07.2015 12:14У Veeam есть FastSCP. Попробуйте копировать файлы с его помощью.
alexkuzko
31.07.2015 07:59В самом Veeam Backup & Replication нет вариантов как делать бекапы с ESXi. Только один способ, да включение/выключение CBT (блочный трекинг).
Возможно, проблема больше в Veeam, чем в ESXi, но хотелось бы понять можно ли изменить ситуацию на стороне ESXi.
beststoragename
31.07.2015 15:37В качестве существенного изменения в 6.0 я бы упомянул возможность использования virtual volumes (VVOLs). Дисковый массив теперь может обрабатывать данные определенного виртуального сервера, а не всех, распожённых на одном LUNe серверов. Этот функционал повлияет не только на производительность, но и методы создания снимков, копий данных и репликации.
EminH
А насколько это влияет на производительность виртуальных машин? vCenter же нужен только для управления/настройки и, насколько я знаю, даже если vCenter упадет все будет работать и без него. Или не так?
kabal375 Автор
Влияет опосредованно. Если vCenter в коме, менеджмент затруднён, а значит в случае перепадов и скачков нагрузки, DRS не сможет своевременно перебалансировать кластер. Да и вообще оценить, что надо перебалансировать, потому что статистика будет собираться местами и не вся.
Кроме того, любые изменения фиксируются через vCenter в базе. То есть создание и удаление машин, миграции, вывод в мэйнтенанс, изменения сетей, обновление инвентори и прочее. И если база будет долго думать над каждым запросом, процесс обслуживания превратится в каторгу.