вторник, 3 февраля 2009 г.

Производительность ESX под терминальной и VDI нагрузкой

Virtual Reality Check провели сравнение поведения Hyper-V, ESX, XenServer и железа под терминальной/VDI нагрузкой.

Желающие подробностей могут скачать 4 подробных документа по 5М здесь.

Я же освещу в русском варианте основные технические моменты, касающиеся VMware ESX.

Тесты проводились на серверах HP DL385 (2*Opteron 2356 (4 core), 32GB RAM, 8*146GB SAS 10k rpm RAID5).

VDI

На сервере с 32GB памяти и отключенной memory overcommitment (далее MO) удается запустить лишь 27 машин с Windows XP (1GB). При включении transparent page sharing (далее TPS) уже 70. Несмотря на то, что данные выбирались случайным образом для тестов, реальные показатели будут пониже, поскольку реальные пользователи VDI имеют тенденцию пользоваться разным софтом, причем более интенсивно нагружающим память, чем в тесте.

Однако использовать TPS следует с осторожностью. Одновременный старт большого количества машин приводит к тому, что TPS не успевает дедуплицировать память и возникают большие проблемы с производительностью.

В данном пункте лично у меня возник вопрос почему ничего не говорилось про MO без TPS, посредством balloon-драйвера.

Terminal

Тестирование показало, что наиболее эффективный и экономичный вариант виртуализации терминальных серверов на ESX - использование 32битной Windows 2003 с двумя процессорами и 4GB памяти на 8-ядерных серверах с 20GB памяти (4*4GB + оверхед ESX) при выключенной TPS.

Оверкоммитинг процессоров (число vCPU > числа физ. ядер) рекомендуется только для виртуализации слабо загруженных серверов, поскольку при высокой загрузке может привести к падению производительности.

Отключение TPS снижает нагрузку на процессор и приводит к увеличению количества сессий на 5-10% при сохранении приемлемого времени отклика.

Не стало сенсацией и превосходство терминальных серверов над VDI по количеству сессий (108 против 69)

5 комментариев:

  1. В данном пункте лично у меня возник вопрос почему ничего не говорилось про MO без TPS, посредством balloon-драйвера.
    Потому что baloon предполагает вытеснение части памяти в своп => тормоза, понижение времени отклика, если эта память используется.
    Я вижу так.

    ОтветитьУдалить
  2. Строго говоря, нет. Скажем, если у нас есть 1GB, но для машины доступно только 700MB, то baloon составит 300MB.

    Внимание вопрос: как изменится производительность ВМ, если реальное использование памяти составляет 300MB?

    ОтветитьУдалить
  3. 1GB, разумеется, следует читать как ВМ с 1 GB памяти.

    ОтветитьУдалить
  4. Ответ: никак.
    А зачем ей тогда выделен гигабайт?
    А если выделен гигабайт каждой, то есть ли гарантия что он им понадобиться не одновременно?

    ОтветитьУдалить
  5. Гарантии нет никакой. Зачем - вопрос к администратору VDI. Он в курсе как кто работает и чем пользуется, он в курсе профилей загрузки ресурсов.

    Настройка VDI на максимальную производительность при минимальных физических ресурсов сродни черной магии.

    ОтветитьУдалить