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"

vAdmin.RU и компания Iomega играют в деда Мороза!

Скоро Новый Год и мы решили немножко поиграть в деда Мороза. Компания Iomega нам в этом помогает :)

Итак, на кону два подарка, а ответы принимаются до 27го декабря.



Медиа-плеер Iomega® ScreenPlay® MX получит кто-то из правильно ответивших на вопросы о компании Iomega.




Ответы более не принимаются.

Новый облачный учебный курс и сертификация от EMC

Компания EMC добавила в облачный трек Cloud Architect новый учебный курс и сертификацию базового уровня по облакам.

Напомню, что ранее для сертификации по программе EMCCA в качестве базового уровня (Associate) требовался общий курс по управлению информацией EMCISA (E20-001 - Information Storage and Management). Курс безусловно полезный, однако к облакам имеющий отношение отдаленное. Теперь появились специализированный базовый облачный курс Cloud Infrastructure and Services и сертификация EMCCIS (E20-002).

Предполагаемые темы вопросов экзамена EMCCIS:

Journey to the Cloud and Cloud Primer
• Business drivers and characteristics of Cloud
• Phases and activities of journey to the Cloud
• Cloud deployment and service models
• Cloud benefits and challenges
Classic Data Center
• RAID Technology and intelligent storage system
• Storage Networking options: DAS, FC and IP SAN, NAS, FCoE, and unified storage
• Backup and Replication
• Data Center management in classic environment
Virtualized Data Center
• Compute virtualization
• Storage virtualization and virtual provisioning
• Network virtualization including virtual LAN and SAN
• Desktop and application virtualization
• Business Continuity in a virtualized environment
Cloud Services and Management
• Cloud infrastructure, service creation and management
• Cloud security concerns, solution, and best practices
• Best practices and consideration for migration to the Cloud

Помимо этого появился учебный курс высшего уровня Expert (EMCCAe) - IT-as-a-Service Planning and Design, однако экзамен на этот уровень ожидается только в феврале 2012.

This expert-level course provides the knowledge and skills necessary to design cloudbased IT-as-a-Service (ITaaS) solutions. Building on the skills acquired in the Virtualized Data Center and Cloud Infrastructure specialist-level course, it focuses on business, organizational, governance, technology, and service management aspects from a designcentric perspective. By utilizing lecture, discussions, case studies, design examples, and a series of interactive problem-solving labs, students will learn to design solutions which transform business operations and virtualized data centers into ITaaS environments. The course is applicable to enterprise, service provider, and existing virtualized data center operations considering ITaaS. This course uses an open approach focusing on core concepts, principals, and technologies rather than specific products. To provide context, the course includes EMC specific examples and case studies.

vSphere 5 Storage DRS и другие видео от EMC Proven Solutions

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

vSphere 5 Storage DRS based on Datastore Capacity Utilization

Вопросы дизайна СХД для vSphere 5 при использовании Storage DRS

В vSphere 5 представлено огромное количество новых функций, множество из которых еще, увы, не освещено. Хотелось бы рассказать о новых функциях, так, или иначе, касающихся вопросов дизайна СХД – Storage DRS и кластера хранилищ.

Storage DRS – механизм, о котором в своё время ходило много слухов. Является развитием технологии Distributed Resource Scheduling, и позволяет мигрировать файлы виртуальных машин между хранилищами, входящими в один кластер для балансировки нагрузки на СХД. Несмотря на то, что Storage DRS позволяет отслеживать производительность ВМ, не нужно путать эту функцию с Storage IO Control (SIOC). Также интегрируется с VASA (VMware vSphere Aware Storage API), о котором ниже.

VMware User Group

Мы сделали это! Предварительные планы на следующий год по VMware User Group одобрены!

Итак, мы планируем проведение встреч VMware User Group в первом полугодии в: Москве, Санкт-Петербурге, Екатеринбурге и Новосибирске! И я вам гарантирую, встреча VMware User Group Russia в Москве будет категории Super Heavy Weight.

Но нам требуется ваша помощь, помощь тех, кто приходит слушать наши доклады и делиться своим опытом. Впрочем, мы просим от вас сделать лишь небольшое усилие, зарегистрироваться в глобальной организации VMware User Group вот здесь: www.myvmug.org.

Все подробности грядущих встреч будут публиковаться по мере поступления здесь.

И кстати говоря, мы только что открыли филиал VMware User Group в Киеве!