Это продолжение серии из двух постов, в которых я рассказываю о построении VDI-решения для крупной российской софтверной компании. Первый пост здесь.
Опираясь на описанную в предыдущем посте теорию, проведем расчеты:
Одновременно от 6 до 9 пользователей VDI могут использовать одно физическое ядро CPU. Для упрощения возьмем среднюю цифру — 7 пользователей.
Согласно требованиям заказчика необходимо обеспечить работу 700 пользователей по VDI с расширением до 1000.
Посчитаем количество необходимых процессоров.
Серверы заказчика на 6-ядерных процессорах Intel Xeon, 2 шт на сервер, т.е. 2 x 6 x 7 = 84 пользователя на 1 ESX-сервер с 2-мя процессорами. Кроме этого, архитектура Nehalem и Westmere очень эффективно позволяет задействовать Hyper Threading и получить на 50-80% больше клиентов. Т.е. на практике где-то: 1,52 * 84 = 126-128 пользователей.
Еслу Hyper Threading не может быть использован или дает прирост меньше 50%, или если необходимо сделать просчет с запасом, то рекомендуемое правило: использовать 75% пользователей на сервер от показателя с hyper threading (т.е. в нашем случае: 128 * 75% = 96 пользователей на сервер), но в текущем расчете все показатели были проверены на практике и совпали с расчетными.
Число серверов для первого этапа (700 пользователей) — 6 серверов, с учетом дальнейшего расширения — 8 серверов.
Объем памяти напрямую зависит от используемой версии ОС Windows, и от того какие приложения будут запускаться. Требования по каждому приложению всегда можно посмотреть на сайте производителя ОС и программного обеспечения.
Например, с Windows XP (это наш случай) для базовых операций требуется 400-500 МБ, с кэшированием — не более 700 МБ. Система в обычных условиях начинает использовать файл подкачки, когда остается менее 25% свободного места в оперативной памяти. ОС всегда старается сохранить как минимум 25% свободного места в резерве. Но использование файлов подкачки в виртуальной среде приведет к потере производительности, поэтому вместо создания файла подкачки с объемом в 1,5-2 от оперативной памяти жестко зафиксируем: не более 200-500 МБ на файл подкачки, если это недостаточно, то клиенту необходимо добавить больше оперативной памяти.
Помимо этого, примерно половина всей используемой памяти содержит похожие блоки на всех клиентах (DLL, схожие блоки приложений и пр.). vSphere Memory Management делит всю память на страницы по 4 КБ, а служба TPS сканирует все блоки данных каждые 60 минут и вычисляет хэш. Ядро сохраняет хэш в таблицу и сравнивает с уже записанными ранее значениями, оставляя только одну копию из двух идентичных, высвобождая таким образом свободное пространство. Если необходимо внести изменения в эту страницу, то создается ее копия для записи. Процент RAM, который высвобождается c использованием TPS — относительный показатель, зависящий от многих факторов и может достигать 35%-50%. На Windows 7 этот показатель ниже из-за использования ASLR (Address Space Load Randomisation), но его также можно отключить.
Для запуска Windows XP на ESX-сервере нам необходимо:
К счастью, в нашем случае Transparent Page Sharing функционировал, гостевой системой была выбрана Windows XP, поэтому расчет делался по «худшему» сценарию из возможных для этого случая — пункт 2, т.е 75 ГБ RAM на сервер.
Показатель IOPS очень сильно зависит от версии ОС и от тех приложений, которые будут использоваться. Для ОС Windows XP примерный показатель — 8 IOPS на саму систему, для Windows 7 — 10 IOPS на систему. Исходя из этого, на 128 виртуальных машин Windows XP (8 IOPS) необходимо 1024 IOPS в режиме чтение/запись 20/80, т.е. 205 IOPS на чтение и 819 IOPS на запись. Т.е получаем количество дисков в RAID1: 205 / 160 IOPS + 819 / 80 IOPS (см. предыдущий пост, часть по RAID) = 14 дисков, неважно стоят ли они на хосте или на общем хранилище.
В RAID5: 205 / 160 + 819 / 45 = 21 диск.
Исходя из замеров на дисковую подсистему: на каждого обычного пользователя необходимо 20 IOPS дисковой производительности, таким образом: 20 IOPS * 1000 пользователей = 20000 IOPS. Из них 20% на чтение (4000 IOPS) и 80% на запись (16000 IOPS). Рассчитаем число дисков в RAID1: 4000 / 160 + 16000 / 80 = 226 дисков. Если пользователи отличаются по приложениям, то расчет берется по каждой группе пользователей.
Если необходимо посчитать число дисков в RAID5: 4000 / 160 + 16000 / 45 = 381 диск.
В требованиях нашего заказчика были указаны обычные пользователи (email, интернет, таблицы, текстовые документы).
Так как текущее хранилище (HP EVA) могло быть расширено до требуемых 226 дисков, то необходимости в замене хранилища не было.
Для получения показателей производительности VDI профилей в рамках массива используется команда vscsiStats. C помощью нее подсчитываются: IO size, seek distance, Outstanding IOs, Latency.
У vmWare есть документ, в котором указаны показатели и команды для запуска статистики.
После подсчетов в теории необходимо проверить этой командой правильно ли отрабатывает тестовая конфигурация, и если необходимо — внести корректировки в конфигурацию.
Подведем итог в виде таблицы по VDI:
Показатели количества VDI-клиентов на 1 физический диск и числа дисков, необходимых для работы 128 пользователей:
Таким образом, вот ряд шагов, которые могут повысить производительность VDI:
Интересное чтение:
Немного математики
Опираясь на описанную в предыдущем посте теорию, проведем расчеты:
Одновременно от 6 до 9 пользователей VDI могут использовать одно физическое ядро CPU. Для упрощения возьмем среднюю цифру — 7 пользователей.
Согласно требованиям заказчика необходимо обеспечить работу 700 пользователей по VDI с расширением до 1000.
Процессоры
Посчитаем количество необходимых процессоров.
Серверы заказчика на 6-ядерных процессорах Intel Xeon, 2 шт на сервер, т.е. 2 x 6 x 7 = 84 пользователя на 1 ESX-сервер с 2-мя процессорами. Кроме этого, архитектура Nehalem и Westmere очень эффективно позволяет задействовать Hyper Threading и получить на 50-80% больше клиентов. Т.е. на практике где-то: 1,52 * 84 = 126-128 пользователей.
Еслу Hyper Threading не может быть использован или дает прирост меньше 50%, или если необходимо сделать просчет с запасом, то рекомендуемое правило: использовать 75% пользователей на сервер от показателя с hyper threading (т.е. в нашем случае: 128 * 75% = 96 пользователей на сервер), но в текущем расчете все показатели были проверены на практике и совпали с расчетными.
Число серверов для первого этапа (700 пользователей) — 6 серверов, с учетом дальнейшего расширения — 8 серверов.
Оперативная память
Объем памяти напрямую зависит от используемой версии ОС Windows, и от того какие приложения будут запускаться. Требования по каждому приложению всегда можно посмотреть на сайте производителя ОС и программного обеспечения.
Например, с Windows XP (это наш случай) для базовых операций требуется 400-500 МБ, с кэшированием — не более 700 МБ. Система в обычных условиях начинает использовать файл подкачки, когда остается менее 25% свободного места в оперативной памяти. ОС всегда старается сохранить как минимум 25% свободного места в резерве. Но использование файлов подкачки в виртуальной среде приведет к потере производительности, поэтому вместо создания файла подкачки с объемом в 1,5-2 от оперативной памяти жестко зафиксируем: не более 200-500 МБ на файл подкачки, если это недостаточно, то клиенту необходимо добавить больше оперативной памяти.
Помимо этого, примерно половина всей используемой памяти содержит похожие блоки на всех клиентах (DLL, схожие блоки приложений и пр.). vSphere Memory Management делит всю память на страницы по 4 КБ, а служба TPS сканирует все блоки данных каждые 60 минут и вычисляет хэш. Ядро сохраняет хэш в таблицу и сравнивает с уже записанными ранее значениями, оставляя только одну копию из двух идентичных, высвобождая таким образом свободное пространство. Если необходимо внести изменения в эту страницу, то создается ее копия для записи. Процент RAM, который высвобождается c использованием TPS — относительный показатель, зависящий от многих факторов и может достигать 35%-50%. На Windows 7 этот показатель ниже из-за использования ASLR (Address Space Load Randomisation), но его также можно отключить.
Для запуска Windows XP на ESX-сервере нам необходимо:
- Если будет занято 60% памяти и половина ее будет разделяться между другими виртуальными машинами (Transparent Page Sharing), то нам нужно 1 ГБ * 60% * 50% = 300 МБ. Плюс, каждая виртуальная машина требует немного оперативной памяти сама по себе – около 5% от общего объема памяти сервера, те около 50 МБ на клиента. Итого 350 МБ. Хост сам по себе требует 4 ГБ RAM. Итого: 4 ГБ (хост) + 350 МБ * 128 (число виртуальных машин на сервер) = 48 ГБ RAM на сервер.
- Если занято 75% оперативной памяти и только треть будет разделяться, то каждому клиенту необходимо 1 ГБ * 75% * 67% = 512 МБ. Итого: 4 ГБ (хост) + (512МБ + 50 МБ) *128 = 75 ГБ RAM на сервер.
- Если хост вобще не поддерживает разделение страниц, то нам необходимо: 4 ГБ (хост) + (1024 МБ +50 МБ)* 128 = 139 ГБ RAM.
- Для клиентов Windows 7 цифры следующие: (2 ГБ + 102МБ) * 50% * 60% = 645МБ на клиент. Итого: 4ГБ + 660МБ *128 = 81 ГБ. Если хост не поддерживает transparent page sharing, то необходимо: 4ГБ + (2ГБ + 102МБ) * 128 = 275 ГБ.
К счастью, в нашем случае Transparent Page Sharing функционировал, гостевой системой была выбрана Windows XP, поэтому расчет делался по «худшему» сценарию из возможных для этого случая — пункт 2, т.е 75 ГБ RAM на сервер.
Диски
Показатель IOPS очень сильно зависит от версии ОС и от тех приложений, которые будут использоваться. Для ОС Windows XP примерный показатель — 8 IOPS на саму систему, для Windows 7 — 10 IOPS на систему. Исходя из этого, на 128 виртуальных машин Windows XP (8 IOPS) необходимо 1024 IOPS в режиме чтение/запись 20/80, т.е. 205 IOPS на чтение и 819 IOPS на запись. Т.е получаем количество дисков в RAID1: 205 / 160 IOPS + 819 / 80 IOPS (см. предыдущий пост, часть по RAID) = 14 дисков, неважно стоят ли они на хосте или на общем хранилище.
В RAID5: 205 / 160 + 819 / 45 = 21 диск.
Исходя из замеров на дисковую подсистему: на каждого обычного пользователя необходимо 20 IOPS дисковой производительности, таким образом: 20 IOPS * 1000 пользователей = 20000 IOPS. Из них 20% на чтение (4000 IOPS) и 80% на запись (16000 IOPS). Рассчитаем число дисков в RAID1: 4000 / 160 + 16000 / 80 = 226 дисков. Если пользователи отличаются по приложениям, то расчет берется по каждой группе пользователей.
Если необходимо посчитать число дисков в RAID5: 4000 / 160 + 16000 / 45 = 381 диск.
В требованиях нашего заказчика были указаны обычные пользователи (email, интернет, таблицы, текстовые документы).
Так как текущее хранилище (HP EVA) могло быть расширено до требуемых 226 дисков, то необходимости в замене хранилища не было.
Для получения показателей производительности VDI профилей в рамках массива используется команда vscsiStats. C помощью нее подсчитываются: IO size, seek distance, Outstanding IOs, Latency.
У vmWare есть документ, в котором указаны показатели и команды для запуска статистики.
После подсчетов в теории необходимо проверить этой командой правильно ли отрабатывает тестовая конфигурация, и если необходимо — внести корректировки в конфигурацию.
Подведем итог в виде таблицы по VDI:
Значение |
Windows XP |
Windows 7 |
|---|---|---|
| Число VDI клиентов на ядро CPU | 6-9 | 6-9 |
| Эффективность Hyper-threading | 150-180% | 150-180% |
| ЭRAM на VDI клиента | 1 ГБ | 1 ГБ |
| Используемая RAM | минимум: 37.5% средняя: 50% без TPS: 100% |
минимум: 20% средняя: 50% без TPS: 100% |
| IOPS на VDI-клиента | light user: 4-6 medium user: 8-10 heavy user: 12-16 |
light user: 6-8 medium user: 10-12 heavy user: 14-20 |
Показатели количества VDI-клиентов на 1 физический диск и числа дисков, необходимых для работы 128 пользователей:
Сценарий со 128 пользователями |
20 IOPS |
20 IOPS |
10 IOPS |
10 IOPS |
| VDI-клиентов на диск | RAID5: 3 RAID1: 4 |
RAID5: 3 RAID1: 5 |
RAID5: 6 RAID1: 8 |
RAID5: 7 RAID1: 10 |
| Число дисков на хост | RAID5: 50 RAID1: 34 |
RAID5: 36 RAID1: 26 |
RAID5: 24 RAID1: 16 |
RAID5: 18 RAID1: 12 |
Таким образом, вот ряд шагов, которые могут повысить производительность VDI:
- Отключить Memory Ballooning — для VDI файл подкачки не приносит пользы, стараться выставлять жесткие значения, при необходимости — увеличивать RAM, не файл подкачки.
- Использовать single vCPU VMs — большинство приложений пользователей однопоточные, им не нужны multi vCPU.
- Timed Boots — разделить группы пользователей по группам, запускать группы по приоритету.
- Оптимизировать антивирусное сканирование. Антивирусное ПО — «необходимое зло» в IT, но если ПО не настроено грамотно, то это приведет к резкому снижению производительности. Полезно будет выставить сканирование по записи, сканирование только локальных дисков и исключить Pagefile.sys и папку Print Spool.
- Отключить 3D Screen Savers в профилях пользователей – эти заставки потребляют очень много ресурсов CPU.
- Использовать физические контроллеры доменов — да, можно запустить DC в виртуальной среде, но Microsoft все еще рекомендует использовать DC в виде физической машины.
- NIC Teaming (Aggregation) — NICs должны быть объединены для большей пропускной способности.
- Виртуализация приложений — приложения должны быть виртуализованы также, как и ОС. Это упрощает поддержку и сжимает размер «золотых образов». Такие образы легче разворачивать и обновлять.
- Правильно рассчитывать пропускную способность сети — раньше расчет делался, исходя из показателя 20 КБ/с на пользователя, но это не отвечает текущему положению вещей. Актуальным значением сейчас будет около 100 КБ/с на пользователя.
- Грамотно рассчитывать производительность системы хранения — выбор типа дисков и уровня RAID определяет как хорошо ваша система хранения выполняет работу в VDI-окружении. Опыт показывает, что RAID 10 – это разумный выбор для VDI из-за высокой производительности. А SSD и Flash-память серьезно уменьшают время загрузки, но имеют большую стоимость (правда, цена такого решения неуклонно падает).
Интересное чтение:
