Поработав с многочисленными экземплярами VMware vSphere ESXi, установленными на клиентах с различной конфигурацией, я подготовил список из 10 рекомендаций, которые помогут администратору ESXi увеличить производительность виртуальных машин. Надеюсь, некоторые из них помогут улучшить характеристики и ваших виртуальных машин ESXi.

Совет #1. Память узла ESXi и превышение физических ресурсов при выделении памяти

Функция memory overcommit позволяет выделить виртуальным машинам на узле ESXi память, превышающую физические ресурсы компьютера. Это полезно, если требуется запустить виртуальную машину в аварийной ситуации, но, как правило, использования этой функции следует избегать. Многие проблемы с производительностью виртуальной машины вызваны выделением недостаточной памяти для нее или превышением физических ресурсов узла ESXi.

Превышение физических ресурсов при выделении памяти на автономном узле ESXi — неудачный подход, но на узле ESXi, подключенном к кластеру, последствия могут быть катастрофическими. Мы проектируем кластеры ESXi для N-1 узлов. Справятся ли оставшиеся узлы ESXi с нагрузкой в случае отказа одного узла? Предположим, что у нас имеется кластер ESXi с двумя узлами, и учитывая количество виртуальных машин, каждому узлу ESX требуется 32 Гбайт памяти, чтобы избежать превышения физических ресурсов при выделении памяти. В случае отказа одного узла все виртуальные машины, функционирующие на нем, автоматически запускаются на оставшемся узле (если кластер с высокой доступностью настроен правильно).

В этом примере каждому узлу требуется 64 Гбайт памяти, чтобы избежать превышения физических ресурсов в случае отказа одного из узлов. Если память каждого узла всего 32 Гбайт, и один узел выходит из строя, то снизится производительность всех виртуальных машин на оставшемся узле, так как физические ресурсы памяти этого узла ESXi будут превышены на 50 %.

Устанавливая новый кластер ESXi, я всегда использую vMotion для переноса всех виртуальных машин с одного узла на другой узел (или узлы) ESXi. Затем я слежу за реакцией сотрудников офиса. Никто не должен заметить, что один узел ESXi прекратил функционирование. Таким образом можно удостовериться в надежности архитектуры и ее соответствии вычислительным нуждам заказчика, даже при отказе одного узла ESXi. Рекомендую приобрести узел ESXi с памятью не менее 256 Гбайт для будущего расширения.

Я собираю информацию о ценах на отдельные модули DIMM и отыскиваю точку, после которой соотношение цены и объема памяти DIMM становится нелинейным. В таблице приведены приблизительные цены модулей DIMM типа Double Data Rate 3 (DDR3) для сервера HP ProLiant DL380 G7. Цена увеличивается линейно до 8 Гбайт. Однако разница в цене между 8 Гбайт и 16 Гбайт значительна. Например, если требуется узел ESXi с памятью 96 Гбайт, то лучше купить двенадцать модулей DIMM по 8 Гбайт (2040 долл.) вместо шести модулей DIMM по 16 Гбайт (2880 долл.). Такой подход к закупкам предпочтителен несмотря на то, что в будущем, возможно, потребуется заменить модули DIMM по 8 Гбайт, чтобы максимально реализовать возможности сервера. Ко времени, когда потребуется расширить память, цена на модули DIMM по 16 Гбайт будет ниже, чем на 8 Гбайт DIMM сегодня.

 

Приблизительные цены на модули DIMM

При увеличении размера памяти сервера сверх определенного предела (96 Гбайт для DL380 G7) ее быстродействие снижается. Например, при достижении максимального предела 144 Гбайт на узле DL380 G7 быстродействие снижается с 1333 МГц до 800 МГц. Это действительно так, но, на мой взгляд, отсутствие памяти принесет более весомый негативный эффект, чем снижение скорости. Доступ к оперативной памяти приблизительно в 100 000 раз быстрее обращений к диску. Поэтому несмотря на снижение скорости памяти, память на 800 МГц приблизительно в 60 000 раз быстрее диска.

Например, я помогал выполнить миграцию Microsoft Exchange Server 2010 для одной компании. Все серверы Exchange представляли собой виртуальные машины в кластере ESXi. Чтобы обработать дополнительную нагрузку в Exchange 2010, необходимо было увеличить память каждого узла на 96 Гбайт, с 64 до 160 Гбайт. В этой конфигурации Exchange 2010 отличается быстротой и стабильностью. Никто не заметил, что скорость памяти снизилась до 800 МГц, но все бы заметили ухудшение характеристик, не установи мы дополнительной памяти перед переходом на Exchange 2010. Вывод: убедитесь, что узел ESXi располагает достаточной памятью, и старайтесь не превышать физические ресурсы при выделении памяти, чтобы увеличить быстродействие.

Совет #2. Ядра процессора узла ESXi

Точно так же, как нельзя быть слишком богатым или чересчур стройным, невозможно иметь слишком много ядер процессора на узле ESXi. При использовании vSphere 5 Enterprise Plus можно настроить виртуальную машину с 32-мя виртуальными процессорами. Тактовая частота процессора на узле не столь важна, как число ядер. Если приходится выбирать между высокой тактовой частотой и увеличением числа ядер, я выбираю последнее.

vSphere лицензируется в зависимости от числа процессоров, поэтому выгодно выбирать процессоры с большим числом ядер. Можно настроить узел ESXi с меньшим числом физических процессоров, уменьшив стоимость лицензии vSphere. Ядра процессора особенно важны для виртуальных машин, которым предстоит выполнять приложения с большой нагрузкой на процессор, такие как SSL-шифрование или Microsoft SQL Server.

Совет #3. Память виртуальной машины

Важно выделить каждой виртуальной машине необходимое количество памяти. Exchange 2010 и Exchange 2007 относятся к числу программ, нуждающихся в оперативной памяти большого размера. Для сервера Exchange с 10 пользователями, ролями сервера клиентского доступа, транспортного сервера-концентратора и сервера почтовых ящиков, а также инструментами управления требуется около 16 Гбайт памяти! Для оптимальной производительности сервера Exchange с 300 пользователями и теми же ролями требуется около 72 Гбайт памяти. Выясните требования ваших приложений к памяти и выделите соответствующее количество оперативной памяти каждой виртуальной машине, не превышая физических ресурсов узла ESXi.

Адресное пространство платформы Windows x64 — 2 Тбайт. Если виртуальная машина работает с операционной системой x64, то слабую производительность диска виртуальной машины можно отчасти компенсировать, увеличив память, выделяемую виртуальной машине, и кэшируя данные. Конечно, если выделенная память уже превосходит физические ресурсы узла ESXi, то выделение дополнительной памяти приведет к снижению, а не к увеличению быстродействия виртуальной машины.

Совет #4. Число и конфигурация виртуальных процессоров виртуальной машины

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

В vSphere 5 можно указать как число виртуальных процессоров, так и число ядер в каждом виртуальном процессоре. Например, Exchange 2007 не относится к приложениям, поддерживающим SMP. Если сервер Exchange 2007 привязан к процессору и функционирует на ESXi-узле vSphere 5, то можно увеличить число ядер виртуального процессора при единственном виртуальном процессоре. Если в виртуальной машине выполняется Exchange 2010 (приложение с поддержкой SMP) то ради достижения оптимальной производительности следует увеличить число виртуальных процессоров, каждый из которых располагает одним ядром. Конечно, эффект здесь бывает различным, поэтому выполните тесты, чтобы выяснить оптимальную конфигурацию виртуальных процессоров/ядер для своего случая.

Совет #5. Паравиртуальный SCSI-драйвер

При использовании кластера ESXi, подключенного к Fibre Channel или iSCSI SAN, можно повысить пропускную способность диска (от 10 до 25 %) при данном уровне производительности процессора на узле. Преимущества достигаются, только если узлы подключены к сети SAN, но не к хранилищу с прямым доступом (DAS). У паравиртуального SCSI-драйвера VMware есть некоторые ограничения:

* паравиртуальный SCSI-драйвер поддерживается только в виртуальных машинах с Windows Server 2008 R2, 2008, 2003 R2, 2003 или Red Hat Linux 5;

* для виртуальной машины необходимо оборудование виртуальной машины версии 7 или более новой;

* паравиртуальный SCSI-драйвер непригоден для отказоустойчивых виртуальных машин.

Совет #6. Моментальный снимок виртуальной машины

Моментальные снимки — отличный инструмент, с помощью которого можно выйти из затруднительного положения, возникшего в результате неудачной попытки обновления или применения программных исправлений. Как правило, моментальной снимок виртуальной машины стоит делать непосредственно перед обновлением или применением программных исправлений. Если обновление происходит без проблем, можно ввести изменения из моментального снимка или разностный файл в базовый образ виртуальной машины. Или же можно вернуть виртуальную машину в состояние, предшествующее моментальному снимку.

Виртуальные машины с активными моментальными снимками записывают любые изменения в разностный диск или разностный файл, пока моментальный снимок активен. Если оставить моментальный снимок активным в виртуальной машине в течение длительного времени и внести многочисленные изменения, то размер разностного файла может стать очень большим; возможно, в группе хранения даже не хватит места. По этой причине рекомендуется сделать моментальный снимок виртуальной машины, выполнить обновление, убедиться, что все в порядке, а затем удалить моментальный снимок из виртуальной машины. Не оставляйте моментальный снимок в виртуальной машине просто потому, что он может потребоваться. Безусловно, активный моментальный снимок также снижает быстродействие виртуальной машины. Снижение производительности особенно заметно, если узел ESXi уже работает с высокой нагрузкой. Лишние активные моментальные снимки снижают быстродействие виртуальной машины и повышают вероятность того, что для нее не хватит места на диске.

Совет #7. Сети хранения данных iSCSI и кадры большого размера

По умолчанию размер кадра MTU составляет 1500 байт. Если разрешить кадры большого размера в iSCSI SAN, то значение MTU увеличивается до 9000 байт. Это позволяет передавать в каждом пакете больше данных, повышая пропускную способность iSCSI SAN на 5-15 %. Выигрыш обычно больше в сетях 10 Gigabit Ethernet, нежели в 1 Gigabit Ethernet.

Безусловно, необходимо убедиться, что кадры крупного размера задействованы на каждом устройстве, подключенном к сети SAN. Среди этих устройств могут быть контроллеры SAN, коммутаторы SAN, сетевые адаптеры ESXi и брандмауэры, подключаемые к SAN. Если пропустить всего одно устройство в iSCSI SAN, то производительность, скорее всего, снизится из-за пропущенных кадров. Уровень производительности можно определить до и после разрешения кадров крупного размера с помощью утилиты Iometer (http://www.iometer.org/). Если показатели снижаются, то, вероятно, при настройке пропущено одно или несколько устройств в сети SAN.

Совет #8. Инфраструктура SAN

Всегда используйте для SAN выделенную сеть. Несколько лет назад была популярна технология Fibre Channel over Ethernet (FCoE), но она так и не получила широкого распространения. На мой взгляд, лучшее соотношение цены и производительности среди решений SAN — у 10 Gigabit Ethernet iSCSI. Производительность ее выше, чем даже у 8 Gigabit Ethernet Fibre Channel, а цена ниже.

Совет #9. Конфигурация диска, RAID и твердотельные накопители

В vSphere 5 можно назначить группу хранения, в состав которой входят твердотельные накопители (SSD). Если группа хранения SSD определена, vSphere 5 использует ее для подкачки страниц памяти. В идеале размер памяти узла ESXi должен быть достаточен, чтобы избежать подкачки страниц, но если на сервер уже установлен максимальный объем памяти, то этот вариант может оказаться полезным. Производительность будет не столь высокой, как при использовании оперативной памяти, но лучше, чем при размещении файла подкачки на накопителе, отличном от твердотельного. В общем случае старайтесь не использовать RAID 6 для групп хранения, особенно если необходимо выполнять много операций записи. Если вам требуется высокая отказоустойчивость RAID 6 без потерь быстродействия при записи на диск, настройте массив RAID 5 с одним или несколькими устройствами «горячего» резерва.

SSD-накопители также применяются для виртуальных машин x86 с очень высокой производительностью, для которых требуется быстрый доступ к диску. Например, имеется виртуальная машина с SQL Server версии x86, которую нельзя обновить в течение следующего года. В среде x64 я обычно оснащаю виртуальную машину большим количеством памяти и кэшем для целой базы данных. Но адресное пространство операционной системы x86 — всего 4 Гбайт, а x86 версии SQL Server — всего 2 Гбайт. В такой ситуации рекомендуется хранить эту виртуальную машину x86 в группе хранения, составленной из твердотельных накопителей, в целях повышения производительности дисковой системы.

Совет #10. «Тонкая» и «толстая» подготовка дисков

При создании виртуальной машины администратору предоставляется выбор между «тонкой» (thin) и «толстой» (thick) подготовкой жестких дисков виртуальной машины. В первом случае первоначально формируется малый vmdk-файл. Поначалу файл использует лишь пространство, занимаемое на диске, и увеличивается до предусмотренного размера. При «тонкой» подготовке экономится пространство в группе хранения. Однако увеличивается вероятность быстро израсходовать дисковое пространство в группе хранения, а быстродействие дисков может снизиться из-за фрагментации диска. Если группа хранения размещается в сети SAN, результаты могут быть различными, так как некоторые поставщики SAN используют «тонкую» подготовку, даже в условиях «толстой» подготовки дисков виртуальной машины. Но в качестве общего правила я рекомендую «толстую» подготовку дисков. При этом больше шансов получить высокую производительность, чем при «тонкой» подготовке дисков, и меньше вероятность израсходовать дисковое пространство группы хранения.

Удачной настройки

Эффективность применения этих советов по повышению производительности сильно зависит от характеристик среды. Критический фактор, определяющий быстродействие виртуальной машины — правильная конфигурация памяти как узла ESXi, так и виртуальной машины. Желаю удачи в выборе оптимальных параметров для высокой производительности!