Comments 28
И vCenter и его БД не должны испытывать недостатка ресурсов.
А насколько это влияет на производительность виртуальных машин? vCenter же нужен только для управления/настройки и, насколько я знаю, даже если vCenter упадет все будет работать и без него. Или не так?
Влияет опосредованно. Если vCenter в коме, менеджмент затруднён, а значит в случае перепадов и скачков нагрузки, DRS не сможет своевременно перебалансировать кластер. Да и вообще оценить, что надо перебалансировать, потому что статистика будет собираться местами и не вся.
Кроме того, любые изменения фиксируются через vCenter в базе. То есть создание и удаление машин, миграции, вывод в мэйнтенанс, изменения сетей, обновление инвентори и прочее. И если база будет долго думать над каждым запросом, процесс обслуживания превратится в каторгу.
Кроме того, любые изменения фиксируются через vCenter в базе. То есть создание и удаление машин, миграции, вывод в мэйнтенанс, изменения сетей, обновление инвентори и прочее. И если база будет долго думать над каждым запросом, процесс обслуживания превратится в каторгу.
Вот по процессору есть дополнение. Вы в консоли сервера с огромным дискомфортом будете работать, если у вас будет 1 vCPU с утилизацией хотя бы 60. Плюс с такой средней утилизацией у вас, вероятнее всего, будут пики на 100%, и за 100% с образованием очереди, и хорошо если клиентское приложение это не замечает. По мне гораздо комфортнее 4 vCPU с утилизацией 20-40%, чем 1 на 80% или 2 на 60%.
Насколько это «вредно» для хоста надо смотреть в каждом конкретном случае, зависит и от плотности машин, и от архитектуры, числа процессоров и т.д.
Насколько это «вредно» для хоста надо смотреть в каждом конкретном случае, зависит и от плотности машин, и от архитектуры, числа процессоров и т.д.
Предполагается, что люди не работают в консоли сервера, в основном.
Ну и да, описано идеальное состояние, когда всегда 80% и всегда 20%. Без пиков. На деле-то понятно, что смотреть надо.
Просто запросы приходят на 8-16-24, а то и 32 процессора просто потому что у физического было 32 ядра раньше. Потом мониторишь, а там 2 ядра загружены на 60%, а остальные на 5-10%. И CPUReady адовый. У всех машин на хосте.
Благо, где сейчас работаю, уже более менее грамотные стали, больше 8 не требуют. Хотя и 8 зачастую — много.
Ну и да, описано идеальное состояние, когда всегда 80% и всегда 20%. Без пиков. На деле-то понятно, что смотреть надо.
Просто запросы приходят на 8-16-24, а то и 32 процессора просто потому что у физического было 32 ядра раньше. Потом мониторишь, а там 2 ядра загружены на 60%, а остальные на 5-10%. И CPUReady адовый. У всех машин на хосте.
Благо, где сейчас работаю, уже более менее грамотные стали, больше 8 не требуют. Хотя и 8 зачастую — много.
Звучит вполне разумно. Честно говоря, я с 8 видел машину только однажды, это был непомерно нагруженный MS SQL Server. Ему и их не хватало.
Вспомнил второй случай. Пачка CAS-серверов MS Exchange 2010. Еле жили на 4-х, при 60% загрузке, постоянно жалобы на медленную синхронизацию и отпадание Outlook. Довели до 8 — и число жалоб резко снизилось.
Зато вторая крайность — 1 vCPU, регулярно. Кто-то экономит «ресурсы». Кто-то деньги на хостинге в датацентре. Но во всех случаях, обычно ничего хорошего не происходит. Как не крути, если мы говорим о Windows, разработчики Microsoft ожидают, что у вас будет минимум два CPU, а вероятнее всего 4. Не стоит их разочаровывать и в виртуальной среде.
Вспомнил второй случай. Пачка CAS-серверов MS Exchange 2010. Еле жили на 4-х, при 60% загрузке, постоянно жалобы на медленную синхронизацию и отпадание Outlook. Довели до 8 — и число жалоб резко снизилось.
Зато вторая крайность — 1 vCPU, регулярно. Кто-то экономит «ресурсы». Кто-то деньги на хостинге в датацентре. Но во всех случаях, обычно ничего хорошего не происходит. Как не крути, если мы говорим о Windows, разработчики Microsoft ожидают, что у вас будет минимум два CPU, а вероятнее всего 4. Не стоит их разочаровывать и в виртуальной среде.
По дисковой. Действительно, банальное обновление антивирусных баз может легко «приложить» storage на традиционных жестких дисках. Для решения этой проблемы можно играть расписанием обновления, а вот Kaspersky сделал опцию обновления баз в RAM.
support.kaspersky.ru/11942
Казалось бы мелочь, но монитор latency датасторов стал срабатывать в несколько раз реже.
support.kaspersky.ru/11942
Казалось бы мелочь, но монитор latency датасторов стал срабатывать в несколько раз реже.
У нас в VDI-ферме это особенно заметно. Даже агент SCCM прикладывал VNX до потери датасторов.
Жаль, что Касперский сделал эту фичу только в серверных версиях.
Жаль, что Касперский сделал эту фичу только в серверных версиях.
Так, и что делать? Только SSD для VDI?
Ох, столько всего проделали…
Чёрт, я забыл про SIOC в статье…
- Убрали всё лишнее с VNX, размазали датасторы по всему объёму — теперь много неиспользованного места, но и latency ниже.
- Стандартные 4 (с 22:00 по 2 часа) окна обслуживания для установки обновлений пришлось ещё раскромсать до 8 — теперь второе окно стартует через час после первого, а не дожидаясь окончания, поскольку пик по IOPS приходится на первые пол часа, а потом линейно падает.
- Добавили памяти ВМ — уменьшился свопинг.
- Настроили BITS, чтоб обновления тянулись в течение рабочего дня, но медленно (4 кб/с).
- Долго и вдумчиво настраивали касперского и его обновления.
- Ну и тюнинг со стороны гипервизоров.
Чёрт, я забыл про SIOC в статье…
Если речь об антивирусе в среде VDI, то возможно стоит попробовать vmware vsphere endpoint + тот же kaspersky.
Говоря кратко — это agentless антивирус для всех машин, запущенных на хосте. А «в целом» я использую и SSD и HDD, all flash по прежнему очень дорого.
Говоря кратко — это agentless антивирус для всех машин, запущенных на хосте. А «в целом» я использую и SSD и HDD, all flash по прежнему очень дорого.
А не поделитесь опытом использования VMWare Virtual SAN, если таковой есть?
Такого опыта, к сожалению, нет. Текущую инфраструктуру переводить очень накладно и непонятно, ради чего.
У меня есть пилотный проект на vSAN 5.5. Ну-у-у… Интересно, но дорого. Всегда нужно держать в уме ряд ограничений — в большинстве проектов, с которыми я связан, используются блейд-сервера, а вот vSAN пришлось строить на 3xHP DL380(2xSSD+6HDD на сервер). Работает хорошо(!!! в моем окружении!!!), НО в качестве эксперимента я отключал две ноды из трех(а так лучше не делать), после чего vsan обратно уже не собрался даже с напильником:-) Так что vsan — это вопрос денег, железа, и требований вашего проекта.
Я бы ещё добавил включение и тюнинг TPS на хостах с VDI и стендами.
Как показал опыт, TPS имеет смысл использовать только на VDI и только при нехватке памяти. Нагрузка на процессор получается заметная.
После очередного обновления, добавляющего соль в блоки памяти и убивающего TPS под корень, мы решили перестать за неё держаться, раз сам вендор её использование затрудняет. К тому же освободилась пара дополнительных хостов…
Реально практичнее добавить памяти или хостов в кластер. А до этого использовать TPS в качестве временной меры.
После очередного обновления, добавляющего соль в блоки памяти и убивающего TPS под корень, мы решили перестать за неё держаться, раз сам вендор её использование затрудняет. К тому же освободилась пара дополнительных хостов…
Реально практичнее добавить памяти или хостов в кластер. А до этого использовать TPS в качестве временной меры.
И лучше отдать этот вопрос на откуп гипервизору, если хочется быть уверенным, что он не скажется на производительности негативно.
К настройкам энергосбережения стоит подходить с осторожностью — при неудачном стечении обстоятельств могут появиться пурпурные экраны в простое. А вендоры будут играть в пинг-понг, так как все тесты система проходит.
Раз уж затронули такой важный вопрос как производительность, то может стоит глубже проанализировать нюансы с настройкой локальных дисковых массивов?
Столкнулся со странной проблемой, когда при тесте скорости чтения/записи (но первично именно чтение) внутри виртуалки все хорошо, а вот если читать файл напрямую с ESXi (в консоли), то скорость в районе 33 Мб/сек (как USB 2.0 почти!) и никак выше не выходит. Что по сети, что локально (например через dd).
Заметил это когда пытался использовать Veeam для бекапа с ESXi и обнаружил катастрофическое падение скорости по сравнению с сервером на Hyper-V. Скорости 20-30 Мб/сек против 76 Мб/сек (почти гигабит) у Hyper-V. Тестировал сеть между ESXi серверами — она около 800 мегабит, т.е. в сеть не упираемся. Все исключительно из-за дисковой. Которая представляет собой RAID10 массив из SAS дисков на контроллере P410.
Куда копать, что смотреть? Думаю что не только я буду вам благодарен!
Столкнулся со странной проблемой, когда при тесте скорости чтения/записи (но первично именно чтение) внутри виртуалки все хорошо, а вот если читать файл напрямую с ESXi (в консоли), то скорость в районе 33 Мб/сек (как USB 2.0 почти!) и никак выше не выходит. Что по сети, что локально (например через dd).
Заметил это когда пытался использовать Veeam для бекапа с ESXi и обнаружил катастрофическое падение скорости по сравнению с сервером на Hyper-V. Скорости 20-30 Мб/сек против 76 Мб/сек (почти гигабит) у Hyper-V. Тестировал сеть между ESXi серверами — она около 800 мегабит, т.е. в сеть не упираемся. Все исключительно из-за дисковой. Которая представляет собой RAID10 массив из SAS дисков на контроллере P410.
Куда копать, что смотреть? Думаю что не только я буду вам благодарен!
У Veeam есть FastSCP. Попробуйте копировать файлы с его помощью.
В самом Veeam Backup & Replication нет вариантов как делать бекапы с ESXi. Только один способ, да включение/выключение CBT (блочный трекинг).
Возможно, проблема больше в Veeam, чем в ESXi, но хотелось бы понять можно ли изменить ситуацию на стороне ESXi.
Возможно, проблема больше в Veeam, чем в ESXi, но хотелось бы понять можно ли изменить ситуацию на стороне ESXi.
Скорость в консоли не говорит ни о чем, а вот бекап через даже через NBD должен работать шустрее.
У вас ведь полная версия B&R и платный ESXi?
У вас ведь полная версия B&R и платный ESXi?
В качестве существенного изменения в 6.0 я бы упомянул возможность использования virtual volumes (VVOLs). Дисковый массив теперь может обрабатывать данные определенного виртуального сервера, а не всех, распожённых на одном LUNe серверов. Этот функционал повлияет не только на производительность, но и методы создания снимков, копий данных и репликации.
Sign up to leave a comment.
Производительность VMware vSphere 5.5 и 6.0 — настройки, соображения. Perfomance Best Practices