Как ускорить работу vmware
Как ускорить работу виртуальной машины
Тем не менее, грамотная оптимизация BM позволит вам увеличить производительность последней без оказания существенного влияние на хостовой компьютер.
Фиксированный размер диска
Используйте фиксированный размер виртуального диска.
Большинство систем виртуализации по умолчанию создают динамические диски, увеличивающиеся по мере «разрастания» установленной на них операционной системы. С одной стороны, использования такого типа контейнеров позволяет экономить место на физическом диске, однако установленная на динамический диск система работает медленнее, причем ее производительность падает с увеличением последнего.
Используйте дополнения гостевой ОС
Даже если вы не собираетесь пользоваться общими папками, буфером обмена и другими опциями расширения функциональности, не пренебрегайте установкой дополнений гостевой ОС, их инсталляция в систему обеспечивает более эффективное использование ресурсов хостовой машины.
Особенности использования антивирусов
Не устанавливайте в гостевую операционную систему антивирусных программ, в этом нет никакой необходимости, заботиться нужно о безопасности не виртуальной, а хостовой системы. Отключите в виртуальной ОС встроенную защиту, если не собираетесь использовать ее в рамках тестирования. Рекомендуем также добавить весь каталог с ВМ в исключения вашего антивируса.
Сканирование контейнера с ВМ не только замедляет ее работу, но и не приносит никакой пользы с точки обнаружения вредоносного ПО внутри виртуального контейнера.
Проверьте настройки виртуальной машины вручную
Что касается установленных по умолчанию параметров виртуальной машины, здесь нужно действовать по принципу «доверяй, но проверяй».
Зайдите в настройки вашей ВМ и и проверьте эти параметры:
Оперативная память
Увеличьте, если возможно, объем выделенной ОЗУ до 2 Гб.
Процессор
Выделите максимально допустимое количество ядер процессора и убедитесь, что в пункте PAE/NX стоит галочка. Если в вашей системе виртуализации доступны функции Nested VT-х/AMD-v, включите их, они улучшают виртуализацию.
Дисплей
Выделите виртуальной машине максимальный объем видеопамяти и включите, если выключено, ускорение 2D и 3D.
Установка виртуальной машины на SSD
Файл подкачки и автозагрузка
Не стоит пренебрегать и внутренней оптимизацией. Для увеличения производительности виртуальной машины используйте внутри нее файл подкачки, особенно на популярных Linux-системах. Размер файла свопа в данном случае определяется общими правилами.
К внутренней оптимизации также следует отнести отключение неиспользуемых элементов автозагрузки, визуальных эффектов, фоновых приложений, службы автоматического обновления системы и индексирования.
Базовый траблшутинг в среде VMware vSphere или что делать, если тормозит ВМ
Что-то в последнее время технические статьи о виртуализации (да и не только о виртуализации) скатываются к формату «в новой версии ожидается такая фича». Складывается ощущение, что разбор механизмов и описание опыта, проблем и решений интересны только зарубежным экспертам. С другой стороны, есть такая проблема у экспертов — если что-то изучил, оно становится элементарным и воспринимается само собой разумеющимся, настолько, что писать об этом как-то глупо. Особенно если уже было кем-то описано где-то. Когда-то. На каком-то языке. Ниженаписанное — плод консолидации личных заметок, сначала предназначавшийся для личного упорядочивания мыслей, но наупорядочив значительный объём текста, подумал, что кому-то может пригодиться.
Типовая проблема «виртуализаторов» — владелец сервиса, заказчик или пользователь жалуется, что у него «тормозит» виртуальная машина. Так как виртуализация предполагает консолидацию большого количества ВМ на базе одного комплекта аппаратных ресурсов, переподписку (overprovision — когда мы предполагаем, что серверы не затребуют одновременно максимум своих ресурсов, а значит, например, в 40 ГБ физической памяти мы можем натолкать не 10 серверов по 4 ГБ RAM, а 15, используя Dynamic Memory), а кроме того, серверы могут тормозить и из-за ошибок в программных компонентах и их настройках, то каждый раз приходится решать за что хвататься и куда смотреть в первую очередь. Особенно, если с таким ёмким описанием проблемы, как «тормозит машина» не предоставлено никакой диагностической информации, как чаще всего и бывает. Под катом небольшое руководство для этого случая.
Конечно, всё зависит от специфичности реализации конкретной инфраструктуры, но практика показывает, что в большинстве случаев имеет смысл следующая последовательность анализа подсистем ВМ:
На практике, до 4-го этапа почти никогда не доходит, после третьего (а то и после первого) имеет смысл запускать (или запрашивать) параллельную диагностику гостевой ОС, но диски стоит проверить сразу — самая значительная часть инцидентов с жалобами на производительность связано с ними. Если, конечно, у вас не All-Flash массив.
А теперь чуть подробнее по каждому пункту.
1. Диски (подсистема хранения)
Самый ключевой тут показатель — это Latency. Задержка времени отклика. Она складывается из большого количества промежуточных элементов и зависит от большого количества факторов. Сюда входит время отклика гипервизора, время прохождения сигнала по кабелям и промежуточным устройствам (коммутаторы, адаптеры и контроллеры), время нахождения в очередях на всех этих устройствах, если нагрузка на них превышает норму и ещё некоторые нюансы, такие как повреждения оборудования. Однако, оставив нюансы для расширенной диагностики, требуемой в редких случаях, можно выделить простой общий показатель — время задержки от ВМ до дисков.
Perfomance Tab
(закладка Perfomance в vSphere Client и счетчики производительности).
Наиболее часто используемые счётчики группы Disk:
Highest Latency — норма до 10-15 мс. Если регулярно выше, надо что-то менять, хотя разовые пики не страшны;
Average write requests per second;
Average read requests per second.
Наиболее часто используемые счётчики группы Virtual Disk:
Read/Write latency;
Average number of outstanding read/write requests — количество одновременных IO-запросов (если их число держится выше 30 в сумме на датастор или на сервер, это будет приводить к дополнительным задержкам);
ESXTop
Консольная утилита ESX/ESXi. Выдаёт целую кучу диагностической информации об отдельно взятом ESXi. Базовую информацию по использованию можно получить, нажав h после запуска утилиты.
В плане диагностики дисковой подсистемы будет полезен контекст виртуальных дисков (нажать v) и контекст HBA-адаптеров (нажать d). В последнем случае стоит обратить внимание на следующие показатели:
KAVG (Kernel Latency Avg) — время отклика гипервизора (норма — до 1 мс);
DAVG (Device Latency Avg) — время отклика от HBA до дисков (норма — 10-15мс);
GAVG (Guest Latency Avg) — время отклика для гостевой системы = сумма KAVG и DAVG
Кстати, в этой же области исследований стоит сразу проверить нет ли у ВМ снапшота. А то и нескольких. Они могут стать проблемой не только паденрия производительности, но и сбоев операций резервного копирования, клонирования и миграции.
2. Процессор
Здесь аналогичный по важности дисковым задержкам показатель — CPU Ready. Также стоит обращать внимание на Used, Wait и Co-Stop. Мониторить можно также через Perfomance Tab или ESXtop.
CPU Ready (%RDY) — % времени, когда ВМ готова производить какие-то вычисления, но физические процессоры в данный момент заняты другими процессами (системными или другими ВМ) и vCPU виртуальной машины находятся в режиме ожидания. Нормой считается значение до 10%. При росте этого показателя выше 40% развивается высокая вероятность сбоев и зависаний гостевой ОС. Причиной вынужденного простоя может стать:
Wait (%WAIT) — % времени, в течение которого ВМ ждёт окончания какой-то активности VMkernel. Чаще всего это дисковая IO-активность. Высокие показатели этого счётчика могут говорить о недостаточно быстром отклике от датастора. Также проблему могут вызывать некорректная работа USB или COM-портов или виртуальный CD/DVD-приводы, в который замонтирован отсутствующий ныне ISO.
Used (%USED) — % времени, в течение которого машина реально работала. Если он около нуля, значит машина просто стоит или её пересайзили процессорами. Если он около 100 (на каждый vCPU), значит или недосайзили, или в ней что-то зациклилось (если она ещё и не откликается при этом), или сейчас там лопатится какой-то квартальный отчёт. Этот показатель стоит изучать при размышлении на тему «дать ли ВМ ещё процессоров, чтоб быстрее работала?». Если у неё 4 ядра и ни одно не задействовано более чем на 50%, то 8 ядер её скорее всего не ускорят. Возможно даже замедлят (см. CPU Ready).
Инструменты диагностики те же.
Perfomance Tab
Удобно, что можно посмотреть данные не только по машине в целом, но и по каждому ядру. Кроме того, доступна статистика за период. Однако, информация предоставляется не в процентах, а в миллисекундах. Так как данные собираются не в real-time, а за определённый интервал, отображается, сколько именно mc процессор находился в том или ином состоянии. Перевести в проценты можно разделив значение на длину интервала и умножив на 100%.
Пример: на рисунке диаграмма с интервалом 20 секунд (real-time), то есть 20 000 мс. То есть среднее CPU Ready будет 50288 / 20000 * 100% = 251.44%. Так как у машины 4 ядра, а не одно, то результат делим на 4 и получаем почти 63%. Машина очень страдает. А всё потому, что лежит на третьем уровне вложенности Resource Pools с низкими shares на каждом.
Ещё раз, формула преобразования: / / * 100%. Получается 5% на 1000 мс для одного ядра.
ESXTop
Тут значение указано сразу в %. Только оно указано сразу в сумме для всех ядер, так что не стоит пугаться чисел больше 100. Делите на количество vCPU машины.
3. Оперативная память
Базовая диагностика здесь простая — да или нет. Если есть факт balooning’а значит хосту не хватает памяти и процессы гостевых ОС страдают, потому что активно используется файл подкачки. Если есть факт свопинга на уровне гипервизора, надо срочно принимать меры — машина попавшая в своп впадает в кому в 100% случаев (по крайней мере моей практики). Вышеуказанные факты позволяют определить такие счётчики как
Balloon (MCTLSZ) — количество памяти, вытянутое baloon-драйвером из гостевых ОС.
4. Сеть
Чтобы проблемы были на уровне сети, в случае жалоб на отдельную виртуальную машину, я в своей практике помню только один случай — когда в VDI использовалась какая-то дешёвая веб-камера, гнавшая несжатый поток видео и забивавшая все 100 Мб/с.
Стоит мониторить такие счётчики:
Transmit Dropped Packets (%DRPTX) — количество (или процент в случае esxtop) отброшенных отправленных пакетов;
Receive Dropped Packets (%DRPRX) — количество (процент) отброшенных принятых пакетов.
Ненулевое их значение, возникающее на регулярной основе говорит о некорректной работе сетевых устройств или некорректной их настройке.
Для базовой диагностики, покрывающей более половины (пожалуй, до 90%) обращений или собственных потребностей при диагностике и тестировании, этого достаточно.
Оптимизация работы виртуальной инфраструктуры на базе VMWare vSphere
Практика показывает, что любой процесс, в определенной степени, всегда можно оптимизировать. Это вполне можно отнести и к виртуализации. Возможностей оптимизации тут достаточно много, и задача эта многогогранна.
В пределах данной статьи я хочу ознакомить вас с методиками сайзинга виртуальных машин, а так же о методах оптимизации их работы. Материал будет техническим и рекомендуется к ознакомлению всем специалистам по vSphere.
Для начала хотелось бы рассказать о двух технологиях, основным образом влияющих на производительность vSphere. Это технология NUMA и технология работы шедулера гипервизора ESXi.
Про NUMA существует достаточно много подробных статей, пересказывать эту информацию не вижу смысла, ограничусь лишь базовым описанием для целостности материала. Итак, NUMA – Non Uniform Memory Access. На русский язык это можно перевести как Неравноценный Доступ к Памяти.
Современные многосокетные сервера, по сути, представляют собой несколько изолированных односокетных компьютеров, объединенных на одной материнской плате. Каждый процессор монопольно владеет своими слотами оперативной памяти, и только он имеет к ней доступ. Аналогично, каждый процессор имеет свои персональные PCI-E шины, к которым подключены различные устройства материнской платы, а так же слоты расширения PCI-E. Процессоры соединены между собой высокоскоростной шиной обмена данными, по которой они получают доступ к «чужим» устройствам, делая запрос на это соответствующему процессору-хозяину. По понятным причинам, доступ процессора к «своей» памяти происходит гораздо с меньшими накладными расходами, чем к «чужой». Пока это все, что необходимо знать о данной технологии.
vSphere прекрасно знает про NUMA и старается размещать виртуальные ядра машин на тех физических процессорах, в чьей памяти сейчас находится оперативная память виртуальной машины. Но тут возникают подводные камни. Производители серверов любят включать в BIOS по умолчанию эмуляцию NUMA. То есть сервер представляется операционной системе как НЕ NUMA устройство, и vSphere не может использовать свою оптимизацию для управления данной технологией. В документации по vSphere рекомендуется отключать (Disable) данную опцию в BIOS, это позволяет vSphere самостоятельно разбираться с вопросом.
Рассмотрим потенциальные проблемы, которые могу возникнуть с NUMA. Предполагаем, что vSphere его видит и корректно с ним работает. Для примера будем рассматривать 2-процессорную систему, как самый простой вариант NUMA. Предположим, что на физическом сервере 64 GB оперативной памяти, по 32 на каждом сокете.
1. Мы создаем виртуальную машину (ВМ) с одним виртуальным ядром (vCPU). Естественно, такую виртуальную машину сможет исполнить только один физический процессор. Рассмотрим ситуацию, когда ВМ надо дать 48 GB оперативной памяти. 32 GB памяти ВМ заберет у «своего» физического процессора, а еще 16 ей вынужденно придется забрать у «чужого». И при доступе к этим «чужим» гигабайтам мы получаем гарантированно высокие задержки, что ощутимо снизит быстродействие виртуальной машины и увеличит нагрузку на шину передачи данных между физическими процессорами. Исправить ситуацию можно, если дать виртуальной машине 2 виртуальных сокета по 1 ядру каждый. Тогда vSphere распределит 2 vCPU ВМ по разным физическим процессорам, взяв у каждого по 24 GB оперативной памяти. Дав виртуальной машине 1 виртуальный сокет мы лишим её возможности грамотно использовать 2 физических процессора.
2. Вариант, когда мы создаем в плюс к первому пункту вторую ВМ на 10 GB оперативной памяти и один vCPU. Если бы эта ВМ была одна, то никаких проблем нет, она вполне умещается в одну NUMA ноду с 32 GB оперативной памяти. Но у нас уже есть первая машина, которая у обоих нод NUMA отъела по 24 GB памяти, и у каждой ноды осталось свободно всего по 8 GB. В данной ситуации либо первая, либо вторая ВМ начнут использовать часть «чужой» памяти, хотя вроде бы каждая из них сконфигурирована правильно с точки зрения NUMA. Это очень характерная ошибка и необходимо очень досконально просчитывать вашу виртуальную инфраструктуру при проектировании, а так же комплексно подходить к конфигурированию виртуальных машин при эксплуатации.
Хотелось бы отметить, что vSphere имеет свою четкую логику при работе с NUMA и Hyperthreading.
Если у ВМ всего 1 виртуальный сокет, то при увеличении vCPU, исполнение машины будет производиться на одном физическом процессоре исключительно на его физических ядрах без использования технологии Hyperthreading. При превышении количества vCPU над количеством физических ядер процессора, ВМ продолжит исполняться в пределах этого физического процессора, но уже с использование Hyperthreading. Если количество vCPU превысило количество ядер процессора с учетом Hyperthreading, то начнут использоваться ядра соседних NUMA нод (других физических процессоров), что приведет к потере производительности (если указать неверное количество виртуальных сокетов). В случае, когда физический процессор сильно нагружен, и свободных физических ядер не осталось, то в любом случае будет использоваться технология Hyperthreading (если иное не указано в конфигурации виртуальной машины). Если посмотреть на цифры, то в среднем ВМ теряет порядка 30-40% производительности, если она работает на чистом Hyperthreading по сравнению с чистыми физическими ядрами. Но сам физический процессор имеет общую производительность примерно на 30% больше с технологией Hyperthreading, чем без нее (используя только физические ядра). Данный показатель очень зависит от типа нагрузки и оптимизации приложений ВМ к многопоточной работе.
Если у ВМ более одного виртуального сокета, то vSphere будет оптимизировать работу такой ВМ, размещая исполняемые ядра и оперативную память на разных физических процессорах сервера.
По понятным причинам, ситуация с нагрузкой физического сервера постоянно меняется. Зачастую, возникает неравномерность нагрузки на физических процессорах сервера. vSphere следит за этим. Шедулер анализирует положение дел, вычисляет накладные расходы на перемещение ВМ или её части на другую NUMA ноду (перемещение памяти, ядер). Сравнивает эти расходы с потенциальной выгодой от перемещения и принимает решение — оставлять все как есть или же перемещать. Иными словами, при любой ситуации vSphere старается оптимизировать работу виртуальных машин. Наша задача состоит в том, чтобы упростить vSphere эту задачу и не ставить её в безвыходное положение.
О каких потерях может идти речь при неправильной конфигурации машин с NUMA нодами? Руководствуясь собственным опытом, могу сказать, что потери могут доходить до 30% общей производительности физического сервера. Много это или мало – решать вам.
Теперь, когда мы немного разобрались с NUMA и Hyperthreading, мне хотелось бы чуть подробнее рассказать о работе шедулера с ядрами виртуальных машин, vCPU.
Я не буду вдаваться в совсем уж глубины, это мало кому интересно, но постараюсь рассказать про принципы и методику работы данного механизма. Итак, основной механизм гипервизора работает следующим образом. В оперативной памяти постоянно работает процесс, обслуживающий работу виртуальных машин. Этот процесс можно представить как конвейер состояния READY и хранилище состояния WAIT. Опустим другие, менее значимые состояния виртуальных машин, они сейчас не принципиальны.
Для легкости восприятия, предлагаю воспринимать все vCPU виртуальных машин как цепочку. Каждое звено цепи – это ядро vCPU (world, в терминах vSphere). Таких world у машины столько, сколько у нее vCPU. Есть еще 2 невидимых, служебных world, сопутствующих каждой виртуальной машине. Один отвечает за обслуживание машины в целом, второй за её ввод-вывод. Реальное потребление вычислительной мощности этими служебными мирами совершенно незначительное, а потребление ими оперативной памяти можно оценить по показателю overhead у каждой виртуальной машины. Стоит отметить, что при создании ВМ размером в весь физический хост, с равным количеством виртуальных и физических ядер, могут возникнуть некоторые потери производительности. Этого момента я коснусь чуть ниже.
Конвейер READY, это «труба», в которую по очереди сброшены все такие цепочки. Таймслот – это время, в течение которого виртуальные машины исполняются физическим процессором (исполняются их vCPU). На это время виртуальная машина практически без потерь, аналогично физическому серверу, использует физические процессоры аппаратного сервера (pCPU). Максимальная величина таймслота искусственно ограничена величиной порядка 1 миллисекунды. После окончания таймслота, vCPU ВМ принудительно помещаются шедулером в очередь конвейера READY. Шедулер имеет возможность менять очередность виртуальных машин в конвейере READY, приоритет каждой машины вычисляется исходя из её текущей фактической нагрузки, её прав на ресурсы (Shares), как давно машина была на физическом процессоре и еще нескольких менее значимых параметров. Логично предположить, что если ВМ на хосте одна, то она всегда будет проходить конвейер очереди READY без задержек т.к. у нее нет конкурентов на ресурсы со стороны других ВМ.
Каким образом шедулер располагает миры виртуальных машин на физических ядрах? Представим себе таблицу, которая имеет по ширине столько столбцов, сколько ядер у нашего физического сервера (с учетом Hyperthreading). По высоте каждая строка будет соответствовать очередному такту процессора(ов) сервера. Давайте представим себе 2-процессорный сервер, по 6 физических ядер на процессор, + Hyperthreading. Всего получим 24 ядра на сервер. Предположим, что у сервера высокая нагрузка, и vSphere вынуждена использовать Hyperthreading, так будет проще считать. Допустим, у нас есть несколько виртуальных машин:
• 4 штуки по 1 ядру
• 4 штуки по 2 ядра
• 2 штуки по 8 ядер
• 1 штука по 16 ядер
Итак, наступает первый таймслот, шедулер выбирает претендентов. Пусть первой будет машина на 16 ядер. Первые 16 физических ядер (pCPU) заняты, осталось 8. Туда поместились, допустим, 4 машины по 2 ядра (причем машина на 16 ядер должна иметь 2 виртуальных сокета, чтобы корректно работать с NUMA). Всё, таймслот заполнен полностью, это идеальный вариант. Мы не теряем производительность, pCPU не простаивают. Остальные виртуальные машины в это время не работают и находятся в очереди ожидания READY. Предположим, что «счастливые» виртуальные машины получили одинаковый по величине таймслот (хотя в реальности у всех ВМ таймслот разный и зависит от множества факторов). Итак, наступает второй таймслот, и шедулеру надо его заполнить.
Остались не обслуженными машины:
• 4 штуки по 1 ядру
• 2 штуки по 8 ядер
Начинаем заполнять, 2 машины по 8 ядер, 4 машины по 1, осталось 4 свободных pCPU, можно положить туда две 2-ядерных машины, которые уже отработали в первом таймслоте. Больше мы туда уместить ничего не можем, не помещается. Таймслот опять заполнен полностью и мы не теряем мощность.
Аналогичным образом шедулер будет и далее наполнять таймслоты мирами виртуальных машин, стараясь сделать это максимально эффективно, чтобы уменьшить «дыры» в заполнении и повысить КПД виртуальной среды.
Ниже представлен негативный вариант расположения виртуальных машин на хосте. Одна большая машина размером в хост, и одна малая, с 1 vCPU. При равных правах на ресурсы и равных потребностях к производительности эти машины получат одинаковое количество таймслотов, то есть поделят между собой процессорное время. Т.к. обе машины не смогут работать одновременно (не умещаются в один таймслот), то работать они будут по очереди, причем малая машина будет работать в пустом таймслоте, где кроме нее больше никого не будет (таймслот израсходуется практически впустую). Большая машина при всем желании не сможет получить процессорное время, даже если оно этой машине необходимо. Например, при частоте центрального процессора 3 ГГц, обе эти машины смогут максимум получить по 1.5 ГГц.
Виртуализация позволяет создать на хосте несколько виртуальных машин, и может сложиться ситуация, когда суммарное количество vCPU всех машин будет больше количества pCPU физического хоста. Это вполне нормальное явление, но нужно четко осознавать, что одновременно все vCPU не смогут получить 100% от своей завяленной мощности. Иными словами, если у вас на одном хосте виртуализации находятся несколько нагруженных машин и их общее количество vCPU больше чем pCPU хоста, то с высокой долей вероятности эти машины будут мешать друг другу, что снизит их суммарную производительность.
Сейчас хотелось бы вернуться к созданию виртуальной машины величиной в весь хост. Хорошо, пусть такая ВМ заняла собой целиком первый таймслот и отработала его. Теперь вспоминаем про системные миры, сопутствующие этой машине. Их тоже надо исполнять, как надо исполнять сам гипервизор и его собственные системные процессы. То есть надо и им выдавать таймслоты и занимать в них некоторое количество pCPU. А что в это время делать нашей большой ВМ? Правильно, ожидать освобождения ВСЕХ pCPU, чтобы иметь возможность там уместиться. То есть мы гарантированно теряем производительность на служебных задачах гипервизора (таймслотах), а это плохо (вспоминаем пример выше с большой и малой машинами). Для примера, программный iSCSI инициатор под высокой нагрузкой потребляет до 6 ГГц процессорной мощности. Это было бы не так заметно в случае с малыми ВМ т.к. они работали бы параллельно служебным процессам (в этих же таймслотах). А для большой ВМ так не получится т.к. она занимает весь таймслот целиком, все его pCPU, и не может уместиться в таймслот, если хоть один его pCPU уже кем-то занят, пусть и системным процессом.
О каких потерях может идти речь при неправильном конфигурировании виртуальной инфраструктуры и размещении машин по нодам? От нуля до бесконечности (в теории). Все зависит от конкретной ситуации.
Отдельно хотелось бы озвучить главное правило при сайзинге виртуальных машин: давайте виртуальной машине МИНИМАЛЬНО возможные ресурсы, при которых она сможет выполнять свои задачи. Не нужно давать ВМ 2 ядра, если хватает одного. Не нужно давать 4, если хватает 2-х (лишние ядра занимают место в таймслоте). Аналогично с памятью, не стоит выдавать машине лишнего. Возможно, другой машине может не хватить, не говоря уже о возникающих проблемах с живой миграцией (по сути копированием объема памяти ВМ) и NUMA.
Теперь, разобравшись с механизмом размещения vCPU виртуальных машин на pCPU таймслота, давайте вспомним про NUMA и его правила размещения. Для шедулера гипервизора все эти правила имеют значение при заполнении таймслота т.к. pCPU таймслота могут относиться к разным NUMA нодам. Теперь, помимо сложностей учета NUMA при конфигурировании виртуальных машин на хосте, мы получили и ограничения, накладываемые методикой работы шедулера гипервизора с таймслотами. Если мы хотим получить хорошую производительность ВМ, нужно обращать внимание на все подводные камни и руководствоваться следующими правилами:
• Стараться не создавать машины-гиганты (по сравнению с размером хоста)
• Для больших машин надо учитывать ограничения, накладываемые технологией NUMA
• Не стоит злоупотреблять с количеством vCPU по отношению к pCPU хоста
• Несколько мелких или средних машин всегда будут иметь преимущество в гибкости и общей производительности перед огромными машинами
Напоследок хотелось бы сказать о работе шедулера гипервизора с вводом-выводом. При обращении виртуальной машины к своему виртуальному аппаратному обеспечению, гипервизор приостанавливает работу ВМ, снимает её с pCPU и ставит в хранилище WAIT. В таком состоянии машина не работает, она просто ждет. В это время гипервизор трансформирует («подделывает») команды виртуального устройства гостевой машины в реальные команды, соответствующие командам гипервизора, после чего гипервизор возвращает виртуальную машину в конвейер READY. Аналогичная «заморозка» виртуальной машины происходит и при ответе виртуального устройства машине (гипервизору необходимо снова трансформировать ответ, но уже в обратную сторону ). Чем больше команд ввода-вывода производит виртуальная машина, тем чаще она находится в «заморозке» WAIT, и тем меньше её производительность. Чем более «старые» виртуальные устройства ввода-вывода использует виртуальная машина, тем сложнее гипервизору трансформировать команды, и тем дольше ВМ находится в состоянии WAIT.
VMWare прямо и официально не рекомендует виртуализовывать приложения с гиперактивным вводом-выводом. Уменьшить негативное влияние от состояния WAIT можно с помощью использования паравиртуальных устройств для виртуальной машины. Это 10-гигабитная сетевая карта VMXNET3 и паравиртуальный SCSI контроллер жесткого диска PVSCSI. Так же уменьшению влияния WAIT и общему повышению производительности способствует применение в физических серверах аппаратных устройств, предназначенных для ускорения работы виртуальных машин. Это различные сетевые и HBA адаптеры с поддержкой аппаратного iSCSI offload, прямого доступа к памяти, сетевые карты с поддержкой виртуализации и т.д.
На этом я хотел бы остановиться. Надеюсь, информация в данной статье была вам интересна, и вы сможете более эффективно подойти к построению или эксплуатации своей виртуальной инфраструктуры.