Meltdown and Spectre

В России все еще продолжаются праздники, но весь мир уже третий день будоражит известие о новых уязвимостях, которым подвержены большинство современных CPU.

Как всегда, подобные известия создают множество слухов, провокаций и откровенно глупостей.

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


"Официальный" сайт с описанием найденных уязвимостей: https://meltdownattack.com

Проект Project Zero с подробным техническим описанием уязвимостей: https://googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html

Еще технические детали от Google: https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html

Многие вендоры уже выпустили свои информационные бюллетени, ищем их на сайте уязвимости, внизу страницы есть ссылки: https://meltdownattack.com

Список ссылок на информационные бюллетени вендоров также есть на reddit:
https://www.reddit.com/r/networking/comments/7o4y40/meltdownspectre_vulnerability_tracker/

Что касается VMware

Используем только проверенные источники/первоисточники, на сайте VMware раздел с описание уязвимостей: https://www.vmware.com/security/advisories.html

Согласно VMSA-2018-0002 патчи для ESXi были выпущены еще 19 декабря 2017, их нужно устанавливать: https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html

Гостевые ОС также подвержены уязвимостям, следим за новостями у производителей ОС, ссылки есть здесь: https://meltdownattack.com

Следим за блогом VMware Security & Compliance Blog. Например, сегодня появилась информация о vRealize Operations for Horizon, vRealize Operations for Published Applications, Workstation, Horizon View Client and Tools: https://blogs.vmware.com/security

VMware выпустили статью с описанием уязвимостей в Virtual Appliances: https://kb.vmware.com/s/article/52264

И еще раз, будем внимательны, следим за официальными источниками информации, не "ведемся" на слухи и провокации, осознав прочитанное принимаемся за работу.

Всем успехов!


UPD. История продолжается, прилетели новые обновления для ESXi и vCenter: https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html

UPD. Патчи из VMSA-2018-0004 пока лучше не ставить:
https://kb.vmware.com/s/article/52345

UPD. Вышел новый эпизод:
https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html

Virtual DataCenter Design. Host Sizing. 1

Hyper-Threading

A lot of times I see two contradictory approaches on how to include HyperThreading to sizing. You can just ignore HT at all, and calculate CPU power based on “real” cores, or you can double CPU power because you see twice as much logical CPUs. Unfortunately they’re both wrong. In general you can safely assume HT as +25% CPU, but with some ifs. The main IF is that HT makes most of the efficiency on workloads with a lots of small VMs. Let’s assume we have a dual-way host with 12-core CPUs. That means 24 “real” cores, or 30 “effective” cores. But 24 vCPUs would still be the widest VM you should place on that host.

1 or 2 or 4

Should we choose 2-way or 4-way servers for virtualization? Pretty common problem. So how to solve it?

Target workload is the answer 100% of the cases, and fault domain size. Fault domain in this case is one host. Let’s assume we have a target workload of 200 VMs that can be handled by 10 dual-way hosts with 256GB of RAM each. It’s not a rocket science to deduct that 5 4-way hosts with 512 GB of RAM can handle this workload as well. But! In case of HA event we’ll have double number of VMs affected with services, double number of VMs to restart, increased load on SAN. We have 20% of resources gone from cluster instead of 10% for dual-way servers. And that’ not all, for the planned maintenance we have to evacuate twice as much VMs which leads us to 2-2,5 times more evacuation time.

Latest improvements in CPU design bring us unprecedented number of cores per single socket, making 2-way vs 4-way quarrel even more complicated. Why the hell not 1-way servers with 16-18 cores CPU?

Conclusion. 4-way servers should be used in such cases as:
- Need to use Xeon E7 CPUs instead of E5. But still we can use 4 way servers with 2 sockets filled.
- Need for ultra-wide VMs size of full 2-way server or more, without possibility of application level clustering to split the load.

CPU choice

How to choose CPU in the family – that’s the question. You can try to stick your finger in the sky, use the coin or even a prophecy. But still most of the choices are made without real thinking. Let’s take a view on some basic aspects.
- NUMA. All the current x86 CPUs have the NUMA architecture. So each CPU has it’s own memory instead of globally shared. You have to access another CPU’s memory through the owner which is slower. But that’s not actually the problem, it’s just an issue to consider. Real problem is that you cannot install only half of maximum memory if you don’t install second CPU on 2-way server.
- CPU price, and price per core.
- Software licenses cost.

Let’s assume we chose Intel R1304WT2GS as basic platform for virtualization. So now we should to decide number of CPU to achieve maximum performance / cost efficiency. We are planning to install vSphere Standard ($1940), Windows 2012R2 Datacenter for VMs ($6155 / 2 CPUs) and Veeam Backup Standard ($1116).
Hardware costs $7970 for 1 socket configuration (E5-2670v3 12c + 192 GB), and we need licenses for 1 socket, which would be another $6133 resulting in approx. $14100 total.
2 socket configuration with the very same performance characteristics would cost $6890 (dual E5-2620v3 6с + 192 GB), but software costs double and result is $19160. So with the very same performance characteristics 1-way server is cheaper and a little bit faster due to just 1 NUMA node. Disclaimer – this is not 100% correct calculation, but a mere example of way to calculate.

So why do we need 2-way or even 4-way systems?
- 2 way servers have twice as much maximum memory.
- Single CPU is not enough for really highly loaded applications.
- As a general rule the more cores CPU have – the less is frequency. For an application with core-based licensing such as Oracle DB that can be an issue. For example, 2*E5-2637 v3 (4с, 3.50 GHz) and 1*E5-2667 v3 (8с, 3.20 GHz) have 10% difference in peak performance (28GHz vs 25,6GHz) while core-based licenses would remain the same.

General recommendations:
- Multi-core CPUs are well suited for loads with a lot of lightly to medium loaded VMs. More cores are better.
- The wider VMs are used – the better they perform.
- If you have only a few VMs with applications known for their love for MHz instead of good parallel procession – stick to higher frequency CPUs with less cores.
- Always start you design with single CPU servers. Add second CPU only after a minimum of 5 hosts reached (except of vSphere Essentials) or when you really need more memory that single CPU can support. Or leave second socket for a future upgrade.

Дизайн VDC. Сайзинг хостов. 1

Hyper Threading

Часто встречаются два противоположных и неверных утверждения – HT не надо учитывать, и учитывать надо как полные ядра, т.е. умножать на два.
HT при сайзинге следует учитывать как +25% процессорной мощности. Хост с 2 процессорами по 12 ядер и HyperThreading имеет 24 ядра или 48 потоков, что с указанным коэффициентом дает мощность, эквивалентную 30 ядрам.
Следует отдельно отметить, что максимальный размер ВМ в этом случае должен быть не более 24 vCPU. Hyper-Threading дает максимальный эффект на большом количестве ВМ с малым количеством vCPU.

1 или 2 или 4

Выбор между 2х или 4х процессорными серверами под виртуализацию следует делать исходя из типа нагрузки, планируемой для данного конкретного кластера. Ключевой показатель – это размер домена отказа. Т.е. насколько виртуальная ферма и продуктивная нагрузка пострадает от отказа единичного сервера. Предположим, под 200 продуктивных ВМ нам требуется 10 2х-процессорных серверов с 256 ГБ памяти. Очевидно, что их можно заменить 5ю 4х-процессорными серверами с 512 ГБ памяти без потери производительности. Однако это означает удвоенное количество ВМ на сервер, и соотв. двойной объем памяти ВМ в нагрузке. При выходе одного хоста из строя и срабатывании HA мы имеем разницу в два раза по количеству ВМ и продуктивных сервисов в рестарте, увеличенную нагрузку на СХД при рестарте ВМ. А также выход двойного объема ресурсов из кластера – 20% (4х) против 10% (2х). При запланированном простое хоста (под регламентные работы) двойное количество ВМ требуют миграции, что в 2-2.5 раза увеличивает время самой миграции.

С учетом роста количества ядер в процессорах для 2х процессорных серверов, возникает смысл в переходе даже на 1-процессорные серверы.

Итого. 4х процессорные серверы под виртуализацию рекомендуются в следующих случаях:
- необходимость использования иного семейства процессоров (Xeon E7, а не E5) под продуктивную нагрузку. В этом случае 4х процессорный сервер может быть с 2мя установленными процессорами.
- необходимость в размещении сверхшироких ВМ, шириной в полный двухпроцессорный физический сервер или более, при невозможности или экономической неэффективности кластеризации приложения с разделением нагрузки на ВМ меньшей ширины.

Выбор процессора

Выбор процессора внутри семейства затрагивает сразу несколько параметров, которые необходимо рассмотреть.
- NUMA. Все современные x86 процессоры имеют архитектуру NUMA. Т.е. у каждого процессора в сервере есть своя память, и обращение к чужой памяти напрямую невозможно. Иными словами, если в 2х процессорном сервере установлен 1 процессор, то памяти можно установить только половину от максимально возможной.
- Стоимость самого процессора и стоимость в расчете на ядро.
- Стоимость лицензий на системное и прикладное ПО и модель лицензирования.

Предположим, что в качестве платформы выбран сервер Intel R1304WT2GS, и теперь стоит вопрос сколько и каких процессоров в него установить для максимальной экономической эффективности. В качестве ПО предполагается vSphere Standard ($1940), Windows 2012 R2 Datacenter ($6155 / 2 CPU), Veeam Backup Standard ($1116).
Итак, для конфигурации 1xE5-2670v3 (12c) и 192 GB сервер будет стоить в сборе $7970 и потребует по 1 лицензии ПО (лицензирование по сокетам), что дает $6133 за софт или $14100 за сервер.
При выборе варианта с 2мя процессорами E5-2620v3 (6с) стоимость самого сервера уменьшается до $6890, однако стоимость лицензий удваивается и дает $19160. /* расчет не является 100% корректным и призван лишь проиллюстрировать сам принцип
При равной мощности и объеме памяти двухпроцессорный сервер обладает большей ценой (спасибо лицензиям) и потенциально меньшей производительностью за счет 2х узлов NUMA.

Так зачем же нам нужны двухпроцессорные и, тем более, четырехпроцессорные серверы?
- В двухпроцессорном сервере вдвое больше максимальный объем памяти.
- Одного, даже топового, процессора может не хватать по вычислительной мощности.
- Многоядерные процессоры не всегда имеют высокую тактовую частоту, а стоимость лицензий на системное ПО значительно ниже стоимости прикладного ПО, лицензируемого по ядрам. Например 2*E5-2637 v3 (4с, 3.50 GHz) и 1*E5-2667 v3 (8с, 3.20 GHz) имеют 10% разницу в пиковой производительности (28GHz vs 25,6GHz), что может стать решающим фактором для выбора процессоров для нагруженной Oracle DB.

Общие рекомендации:
- Многоядерные процессоры хорошо подходят для большого количества ВМ малой или средней загрузки.
- Чем более широкие ВМ используются – тем лучше они работают на многоядерных процессорах.
- Если машин немного и прикладное ПО плохо работает с параллельными потоками, предпочитая частоту, то выбор должен осуществляться в пользу процессоров с большей частотой в ущерб количеству ядер.
- Надо всегда начинать с варианта с одним процессором, и добавлять второй только при нехватке памяти, или оставлять второй процессор как опцию под будущий апгрейд виртуальной фермы.

Горизонтальное и вертикальное масштабирование. Взгляд со стороны бизнес приложений.

К концу 2012 года более 50% приложений работающих на х86 платформе виртуализированы. Вместе с тем виртуализировано только 20% бизнес критических приложений .

Это из-за того что ИТ отделы не доверяют платформам виртуализации? Считают ли они платформы виртуализации не достаточно стабильными для поддержки работы критически важных приложений?

За последние 10 лет VMware доказала что виртуализация это уже реальность, и, фактически, виртуализированные приложения часто более стабильны, когда работают на инфраструктуре под управлением VMware.

Тогда если доверие или стабильность не являются проблемой в чём же причина того что ИТ отделы еще не виртуализировали оставшиеся приложения?

Как работает планировщик процессора ESXi. Презентация с VMUG 2013.

Польза правильного сайзинга ВМ

Я думаю, что описываемый случай является хорошим примером правильного (под данным понятием я подразумеваю достаточного, а не избыточного) выделения ресурсов виртуальной машине.

В кластере с большим количеством ВМ с избыточным уровнем переподиски также развёрнут сервер с 4 ЦПУ на котором работает БД на SQL.

На графике ниже видно, что до 24 июля среднее значение метрики CPU Ready было около 10%, а 24 числа резко скакнуло выше 30%. То есть, 30% времени виртуальная машина ждала, когда на физическом ЦПУ будут доступны ресурсы для выполнения. Приложение, работающее с данной БД испытывало серьёзные проблемы с производительностью из-за этого.

В тот же день количество vCPU было снижено с 4 до 2, и результат очевиден. Значение CPU Ready упало примерно до 1%, и оставалось на том же уровне и дальше. При этом производительность всех приложений, использующих данный БД, в том числе и vCenter Server, серьёзно выросла.

 

Правильное (достаточное) выделение ресурсов улучшает производительность не только данной ВМ, но и снижает уровень борьбы за ресурсы на всём кластере, что влияет на производительность всех ВМ.

Также важно отметить, что это урезаны ресурсы были только у одной машины, и чем больше ВМ будет отрегулировано в кластере, тем меньше будет значение CPU Ready, а производительность будет расти. Снижение нагрузки на кластер также позволяет увеличить значение консолидации ресурсов без снижения доступности или производительности.

Отдельно хотелось бы отметить, что лично я считаю, что данная ВМ могла бы использовать все преимущества и от 4 vCPU, но не в кластере с таким высоким уровнем борьбы за ресурсы.

Теперь вы верите в правильный сайзинг ВМ?

В чем разница между CPU Ready и %RDY?

Самым важным ресурсом для виртуальной машины является ЦПУ. И если администратор сталкивается с падением производительности у какой-либо ВМ, то для тонкого траблшутинга производительности очень удобно пользоваться командной утилитой esxtop, которая все значения показывает в процентном соотношении.

В vSphere Client же, в свою очередь, показывает значения в миллисекундах. И если из документации известно, что значение %RDY не должно превышать 10, то соответствующее значение CPU Ready очень легко посчитать.

Итак, и esxtop и vClient собирают данные в реальном времени, и обновляют их каждые 20 секунд  - 20 000 миллисекунд. Таким образом, если CPU Ready за эти 20 000 мс составил 500 мс, то мы делим 500 на 20 000, и получаем значение %RDY около 3, что является прекрасным показателем. Если же CPU Ready составил 7 500, то деление 7 500 на 20 000 даст около 37.5% RDY, что ужасно для однопроцессорной виртуальной машины.

Здесь важно отметить «для однопроцессорной виртуальной машины», так как значение %RDY является суммой значений для всех ядер ВМ. То есть, если в esxtop у 4-ёх ядерной ВМ значение %RDY 20 – то для каждого отдельного vCPU оно составляет в среднем 5.

vClient же, в отличие от esxtop, позволяет просматривать значение CPU Ready как в целом, так и для каждого отдельного вЦПУ.

Оригинал: Jason Boche

ESX CPU scheduler deepdive. Multicore-Aware Load Balancing. Part 2.

Inter-VM Cache Affinity

В ситуации, когда две ВМ на одном и том же хосте интенсивно обмениваются информацией, возможно увеличение производительности при работе в пределах одного кэша. Эта ситуация применима только к разделению кэша между ВМ, консолидация vSMP применяется для консолидации кэша внутри одной машины. Как следствие, vSMP работает только для многопроцессорных машин, а в данном случае возможно консолидировать и однопроцессорные машины. Планировщик ESX в автоматическом режиме определяет "разговорчивые" машины на хосте и пытается разместить их в пределах LLC. Тем не менее, этого может и не случиться, в зависимости от нагрузки на хост.

Aggressive Hyperthreading Support

Балансировка нагрузки для архитектуры с многопоточными процессорами (hyperthreading) - тема для отдельного поста. Политика миграции по умолчанию выбирает полностью незагруженное ядро (оба потока свободны), предпочитая его частично загруженному - тому, у которого загружен один поток. Посколько оба аппаратных потока конкурируют за один процессор, использование частично загруженного ядра приводит к ухудшению производительности, по сравнению с полностью свободным ядром. Как результат, наблюдается асимметрия в вычислительной мощности среди pCPU, в зависимости от того, насколько загружен поток-близнец. Эта асимметрия ухудшает "справедливость распределения" (fairness). Например, один vCPU работает на частично загруженном ядре, а другой на полностью свободном. Если оба vCPU идентичны по требованиям к вычислительной мощности, то получается несправедливая ситуация, и от нее надо уходить.

В связи с этой асимметрией планировщик рассчитывает потребление процессорной мощности в меньшем объеме для vCPU, расположенном на частично загруженном ядре. В случае если vCPU исполнялся на частично загруженном ядре на протяжении длительного времени, то планировщик может перенести данный vCPU на полностью свободное ядро с целью компенсации недополученной процессорной мощности. В противном случае данный vCPU может оказаться в ситуации постоянного отставания от других vCPU, работающих на полностью свободных ядрах. Компенсация выражается в том, что второй аппаратный поток ядра намеренно сохраняется незагруженным. В этом случае может быть неполной утилизация аппаратных потоков, однако общее снижение производительности достаточно незначительно, ввиду ограниченности потенциального прироста производительности из-за многопоточности.
Внутреннее тестирование показывает, что последние поколения многопоточных процессоров демонстрируют больший прирост производительности и меньшее влияение загрузки потока-близнеца. Это наблюдение дает повод для более агрессивного использования частично загруженных ядер для балансировки нагрузки - полностью свободные ядра все еще предпочтительнее, но если нет полностью свободных, то частично загруженное ядро имеет больше шансов. Ранее частично загруженные ядро могло быть вовсе не выбранным для гарантии справедливого распределения процессорного времени. Эксперименты показывают, что агрессивное использование многопоточности улучшает утилизацию процессора и увеличивает производительность приложений без значительного влияния на справедливость распределения.
Стоит заметить, что бухгалтерия планировщика слегка изменилась - загрузка процессора считается со скидкой, если поток-близнец загружен. Это приводит к ситуации, в которой общая загрузка системы считается меньше реальной. Например, возьмем ситуацию, в которой оба потока-близнеца постоянно загружены. В терминах утилизации процессора система полностью загружена, но в терминах бухгалтерии процесса время исполнения, которое будет списываться со счета исполняемых vCPU, меньше полной загрузки ввиду скидки. В esxtop для поддержки этого появился новый счетчик “PCPU Util” для отображения утилизации системы, а “PCPU Used” все еще показывает текущее время исполнения. Подробности - man esxtop.

Extended Fairness Support

Базовые алгоритмы планировщика гарантируют справедливое распределение ресурсов процессора между виртуальными машиными согласно их конфигурации. В некоторых случаях справедливое распредление процессорных ресурсов может не вести напрямую к метрикам приложений, ввиду комплексности архитектуры и завимости производительности от, например, кэша на кристалле и ширине шины памяти.
Для расширения понятия справедливого распределения ресурсов, миграции могут случаться, например, для справедливого распределения кэша на кристале или ширины полосы доступа к памяти. Однако, в силу стоимости самой миграции, происходит это не так часто, обычно раз в несколько секунда, чтобы снизить негативное влияние на общую производительности.
Прим: поддержка расширенного справедливого распределения ресурсов также реализована в алгоритмах балансировки для NUMA.

Продолжение следует.

Оригинал: "VMware® vSphere™: The CPU Scheduler in VMware ESX® 4.1"

ESX CPU scheduler deepdive. Multicore-Aware Load Balancing. Part 1.

Архитектура CMP (chip mutiprocessor) привносит новые проблемы алгоритмам балансировки нагрузки ввиду различных вариантов исполнения кэша на чипе. Предыдущие поколения процессоров обычно были с частным L2 кэшем, а более новые имеют общий как L3, так и L2 кэш. Также, количество ядер, использующих общий кэш варьируется от двух до четырех и более. Кэш последнего уровня (LLC - last level cache) - кэш, после которого идет обращение к оперативной памяти. Поскольку задержка при доступе к LLC и RAM различается как минимум на порядок, поддержание высокого уровня cache-hit для LLC становится жизненно необходимым для высокой производительности.
Балансировка нагрузки достигается миграцией vCPU, но после миграции vCPU должен "разогреть" кэш. И в связи с этим реальная стоимость миграции очень сильно зависит от того, требует ли разогрев кэша доступа к оперативной памяти, который не может быть удовлетворен за счет LLC. Иными словами, миграция в пределах LLC значительно дешевле, чем между LLC. Ранее эта внутричиповая топология игнорировалась планировщиком и стоимость миграции считалась одинаковой и фиксированной. Тем не менее, результат был удовлетворительным, поскольку механизм приоритезации миграции между ячейками планировщика (scheduler cell) приводил к высокому уровню между-LLC миграций - ячейка в большинстве случаев равняется одному, как максимум двум LLC.
В ESX4 понятие ячейки планировщика более не используется, а следовательно между-LLC миграции более не приоритезируются. Таким образом механизм балансировки нагрузки занчительно улучшился, поскольку миграция внутри LLC предпочтительнее миграции между LLC. Когда планировщик выбирает pCPU для миграции, локальный процессор, разделяющий LLC, всегда предпочтительнее удаленного, не разделяющего тот же LLC. Тем не менее, миграция на удаленный pCPU все еще возможна, если выбор локального pCPU не может решить проблему балансировки нагрузки.

CPU Load-Based Migration Throttling

В ESX4 vCPU, привносящий значительную нагрузку на текущий pCPU не будет мигрировать, вместо этого планировщик будет в первую очередь мигрировать vCPU с низкой нагрузкой. Данный механизм позволяет снизить количество миграций из-за мнимого дисбаланса. В низконагруженных средах легко может оказаться, что лишь несколько процессоров заняты, поскольку не хватает vCPU, способных нагрузить систему. Попытка выровнять нагрузку в данном случае приведет к ненужным миграциям и снизит производительность.
Например, один vCPU дает 95% нагрузки на pCPU (PA), в то время как остальные pCPU простаивают. Если другой простаивающий pCPU (PB) инициирует миграцию vCPU, то через некоторое время оригинальный pCPU (PA) станет проистаивающим и инициирует миграцию назад. Таким образом приоритезация миграции по нагрузке избавляет нас от этого пинг-понга. Высокая нагрузка на pCPU также означает и высокий вклад в кэш, поскольку у vCPU достаточно времени для разогрева кэша и соотв. высокой доли использования кэша. Это, конечно, не идеальная следственная связь, но вполне разумное предположение. Приоритезация миграций в зависимости от нагрузки на процессор может рассматриваться как необходимое условие для приоритезации миграций на основе рабочего набора в кэше. Точное определение размера рабочего набора в кэше и использование этого для приоритезации миграций - то, что возможно, будет реализовано в следующих версиях гипервизора.
Миграция vCPU начинает приоритезироваться по нагрузке только при условии, что vCPU имеет действительно большую долю в нагрузке на текущий pCPU. Пороговое значение установлено достаточно большим, чтобы разрешать миграции, действительно улучшающие общую производительность. По мере роста нагрузки на систему в целом приоритезация становится все менее вероятной ввиду того, что вклад каждого vCPU в процентном соотношении снижается. Проблема мнимого дисбаланса актуальна только для недозагруженных систем.

Impact on Processor Caching

В ESX4 vCPU виртуальной машины может быть размещен на любом pCPU, поскольку ячейки планировщика ушли в небытие. При работе алгоритма балансировки на основе нагрузки на LLC есть тенденция к разбеганию vCPU одной виртуальной машины по разным LLC. Тем не менее, все они остаются в пределах одного узла NUMA, если машина управляется планировщиком NUMA. Большее количество агрегированного кэша и ширины канала доступа к памяти улучшают производительность для большинства видов нагрузок. Однако нагрузки с интенсивной межпроцессной комуникацией могут страдать от снижения производительности при размещении по разным LLC.
Например, рассмотрим параллельное приложение с малым рабочим набором кэша, но очень частым взаимодействием производитель-потребитель взаимодействием между нитями. Также предполжим, что эти нити распределены по различным vCPU. Если хост недозагружен, то скорее всего vCPU были распределены между различными LLC. Таким образом взаимодействие между нитями приводит к большому количеству cache-miss и общему снижению производительности. Если бы рабочий набор был больше, чем LLC, то политика по-умолчанию улучшила бы производительность.
Относительный эффект большего агрегированного кэша в значительной степени зависит от приложения. Также как и с предыдущим механизмом, динамическое определение типа приложения и изменение политики планировщика на лету бросает новые выовы и будет составлять основу будущей работы. На сегодняшний день можно вручную принудительно задать политику консолидирования кэша.

vSMP Consolidation

Если есть уверенность, что приложение в виртуальной машине получит выигрыш от разделяемого кэша, а не от большего его объема, этот эффект можно достичь при консолидации vSMP. Консолидация vSMP приведет к приоритезации выбора pCPU в пределах  LLC для vCPU данной ВМ. Тем не менее, иногда это может и не случиться, в зависимости от доступности pCPU.
Для включения консолидации vSMP необходимо изменить следующий расширенный параметр для ВМ: 

sched.cpu.vsmpConsolidate = true.

Продолжение следует.

Оригинал: "VMware® vSphere™: The CPU Scheduler in VMware ESX® 4.1"

Горячее добавление CPU в VMware vSphere 5

Канал EMCProvenSolutions радует новым видео:

NUMA для vCPU в vSphere 5

Сегодня я бы хотел рассказать о мало освещаемой в блогосфере функции vSphere 5 – virtual NUMA. Что такое NUMA Антон уже описывал около года назад. Технология же virtual NUMA (vNUMA) позволяет гипервизору экспортировать в виртуальную машину данные о NUMA физического сервера. Преимущество этой технологии в том, что все современные ОС уже знают о NUMA и умеют с ней правильно работать, и, как следствие, смогут использовать данные о NUMA для получения максимальной производительности.

Для использования vNUMA необходимо, чтобы ВМ использовала vHW версии 8, а, во-вторых, vNUMA уже автоматически активирована для виртуальных машин с количеством vCPU от 8.
Еще один нюанс состоит в том, что если в ВМ ядер на сокет больше 1го, то размер vNUMA будет равен количеству ядер в сокете. Если же по какой-либо причине Вы выставили 1 ядро на сокет, то параметры vNUMA будут соответствовать NUMA ноде сервера.

Также существует набор тонких настроек vNUMA, изменять которые можно в разделе Aвvanced Settings для ВМ:

cpuid.coresPerSocket - Определяет количество ядер на сокете. Также отвечает за размер vNUMA, если таковая используется. Можно настраивать, если известна точная конфигурация NUMA на сервере.

numa.vcpu.maxPerVirtualNode - Если предыдущая чётко указывает количество ядер на узел, то это настройка указывает максимально возможное. Нельзя использовать их обе одновременно.

numa.autosize - каждый раз при включении ВМ размер vNUMA подгоняется под размер NUMA узлов сервера.

numa.autosize.once - то же самое, только работает один раз. Исключение: если из запущенной хотя бы 1 раз ВМ сделать шаблон – виртуальная машина, развёрнутая из этого шаблона будет иметь такую же vNUMA архитектуру, что и источник для шаблона.

numa.vcpu.min - минимальное количество vCPU, необходимых для создания vNUMA.

numa.vcpu.maxPerMachineNode - максимальное количество vCPU одной ВМ, которые могут работать в рамках одного физического NUMA узла.

numa.vcpu.maxPerClient - количество vCPU в NUMA клиенте. Клиент, в свою очередь - группа vCPU, которые обрабатываются как vNUMA, то есть как 1 объект. По умолчанию, 1 vNUMA является 1 клиентом, но если vNUMA больше pNUMA, то vNUMA может быть разбита не несколько меньших vNUMA клиентов.

numa.nodeAffinity - номера физических NUMA узлов, на которых исполяется виртуальная машина. Крайне не рекомендуется менять эту настройку, так как vmkernel не сможет нормально балансировать такую виртуальную машину между NUMA нодами.

Сайзинг ВМ и NUMA системы

С появлением vSphere стало возможным создавать ВМ с 8 процессорами и 255 GB памяти. И хотя я не много видел машин с 32+GB, я получаю много вопросов о 8-процессорных ВМ. Из-за архитектуры современных процессоров ВМ с более чем 4-мя процессорами могут испытывать снижение скорости работы с памятью на NUMA системах. И хотя степень снижения сильно зависит от типа нагрузки, любой администратор должен избегать проблем с производительностью.

Значит ли это, что вы не должны создавать больших ВМ? Нет, если ВМ действительно требует большой вычислительной мощности. Причина, по которой я пишу это - большинство IT отделов руководствуются одной и той же политикой и для физических и для виртуальных машин. ВМ дают множество процессоров и кучу памяти на случай если вдруг это когда-либо потребуется в будущем. И хотя этот подход экономит время и позволяет не ввзяываться в офисную политику, для больших ВМ он может вылиться в ненужные задержки. И вот почему: