Добрый день.
Наконец то появилась возможность взяться за блог и написать цикл статей "Проектирование ЦОД, виртуализация", о том, что наболело, и о том, что является квинтэсенцией моего опыта и теоритического материала. Это первая статья из серии.
В течение этого года я неоднократно сталкивался с виртуализацией и различными аспектами её применения. В свете выхода Windows Server 2012 и Hyper-V 3.0, появления концепции Private Cloud, тема виртуализации и динамического ЦОД становится ещё более актуальной.
Освежим в памяти некоторые моменты.
Как Microsoft Hyper-V использует аппаратные ресурсыДля начала поговорим о наиболее частро встречающейся проблеме: неверное понимание конфигурации виртуальной машины при выделении ей процессорных ресурсов.
Если мы с вами посмотрим в свойства процессоров виртуальной машины, созданной на базе Hyper-V мы увидим следующую картинку
Мы можем видеть два параметра:
1. Virtual machine reserve (percentage) - процент системных ресурсов, зарезервированных конкретно для этой виртуальной машины, в данном случае равное 0.
2. Virtual machine limit (percentage) - максимальный процент системных ресурсов физического сервера, которые виртуальная машина могла бы использовать с 4-мя виртуальными процессорами.
В чём разница и что это значит?
Начнём с Virtual machine limit (percentage). На рисунке ниже мы видим снимок Task Manager физического сервера, где находится эта виртуальная машина. Данный сервер снаряжен 2-мя процессорами Intel с 4 ядрами и технологией Hyper Threading. Всего 16 ядер (в данной статья я не планирую объяснять технологию Hyper Threading, но для понимания написанного, рекомендую ознакомиться с материалами о ней в интернет - и это крайне важно).
Значение в поле Virtual machine limit (percentage) равно 100% и ниже на рисунке мы видим значение 25 в поле Percent of total system resources.
По идее это значит, что данная виртуальная машина могла бы использовать 25% производительности физического сервера за единицу времени.
Если я изменю число виртуальных процессоров на 1, вуаля, наша виртуальная машина уже способна утилизировать только 6%.
Однако, здесь необходимо пояснить разницу между физическим ядром (процессором) и его логическим эквивалентом - виртуальным процессором. В терминологии Microsoft (да и нетолько) виртуальный процессор - это ничто иное, как время отведённое потоку данных (исполняемому коду) виртуальной машины на стеке физического процессора (vCPU - это логическая единица, управляемая гипервизором, а не сам процессор. Кстати, именно по этому VM не может запускаться на bare metall).
Когда мы назначаем 4-ре виртуальных процессора мы предоставляем определенное количество времени на выполенение кода виртуальной машины. Причем этот код будет выполнен на любых доступных логических ядрах сервера. То есть вся нагрузка виртуальной машины будет распределена на все физические ядра сервера, но на 25% времени.
Если мы говорим о Windows Server 2008 R2 то максимум мы можем выделить 4-ре виртуальных процессора, а безопасный максимум это 8-мь потоков на одно физическое ядро. В Windows Server 2012 это количество равно 64-м виртуальным процессорам.
Отсюда возникает следствие: чем меньше виртуальных процессоров назначено на сервере виртуализации, тем больше времени код конкретной виртуальной машины сможет обрабатываться на физических процессорах. То есть увеличится её производительность.
Но тут существует тонкий момент: если значение параметра Virtual machine reserve (percentage) равно нулю, ресурсы физических процессоров сервера виртуализации (хоста) являются разделяемыми (shared resource).
То есть, любая виртуальная машина может забрать общий процессорный ресурс, если её требования к производительности это потребуют. Что может привести к нежелаемым последствиям.
Для того, чтобы обеспечить требования: если мы хотим обеспечить виртуальной машине производительность в 25% системных ресурсов на сервере при его виртуализации, нам надо установить параметр Virtual machine reserve (percentage) равное 100
Отсюда мы можем сделать следующие выводы:
- Необходимо чётко планировать загрузку серверов виртуализации, чтобы обеспечить правильное размещение высоконагруженных виртуальных машин при миграции их, в случае сбоев одного из узлов кластера.
- Для достижения желаемой производительности виртуальной машины необходимо нетолько указать число процессоров, но и выполнять резервирование системных ресурсов.
- Число размещаемых виртуальных машин на одном узле кластера - конечно и зависит от количества физических ядер процессоров, а так же желаемой производительности каждой виртуальной машины.
Для справки:
Каждое ядро обладает скоростью, указанной в маркировке процессора:
Intel Xeon 2.66 Ghz (4 cores) говорит о том, что данный процессор содержит 4 ядра и скорость каждого из них 2.66 Ghz.
Второй аспект о котором надо помнить - это оперативная память.
В Windows server 2012 произошло изменение - теперь Hyper-V 3.0 и виртуальные машины полноценно поддерживают архитектуру NUMA. Non-Uniform Memory Access позволяет оптимизировать использование процессорами оперативной памяти, на основе её расположения в отношении процессора. К примеру, SQL server на виртуальной машине на базе Hyper-V 2.0 не мог использовать такой вид оптимизации, в результате при попытке задействовать память, назначенную другому процессору, возникали проблемы с производительностью. Теперь эта проблема устранена.
Работает это следующим образом:
Виртуальная NUMA представляет NUMA топологию внутри виртуальной машины таким образом, что гостевая операционная система и приложения могут принимать "умные" решения о выделении памяти и потоков, которые размещаются в соответствии с физической топологии NUMA сервера виртуализации.
К примеру, есть сервер виртуализации с 4-мя процессорами с 4-мя физическими NUMA узлами (на рисунке обозначены цифрами с 1 - 4). На сервере запущены две виртуальные машины "A" и "B", которым выделены по 2 NUMA узла. Но для запущенного внутри гостевой операционной системы приложения это выглядит, как будто оно запущено на физическом сервере с двумя NUMA узлами.
Для справки:
Расчёт узла NUMA можно провести следующим образом: надо разделить количество оперативной памяти сервера виртуализации на количество ядер на сервере. То есть, если у нас на сервере 128 гигабайт оперативной памяти и 16 ядер, то один NUMA узел будет размеров 8 гигабайт.
Аналогично это решение работает при отказоустойчивой кластеризаци.
Для справки: NUMA работает на Hyper-V 3.0 Windows Server 2012 только если на сервере виртуализации не используется Dynamic Memory.
А теперь разберём пример расчёта оперативной памяти:
Предположим на сервере виртуализации 48 гигабайт оперативной памяти.
2 гигабайта мы резервируем для сервера виртуализации, назначив память в мегабайтах в этой ветке реестра
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\MemoryReserve (REG_DWORD)
Остаётся 46 гигабайт.
Однако, существует определенные нюансы:
- 1-й гигабайт оперативной памяти, выделенный для каждой виртуальной машины, получает 32 мегабайта административной нагрузки
- каждый последующий гигабайт оперативной памяти, выделенный для виртуальной машины, получает 8 мегабайт административной нагрузки
Server name
|
RAM
|
Sirius
|
8 GB
|
Quantum
|
4 Gb
|
Tesla
|
16 Gb
|
Nessy
|
8 Gb
|
то расчёт выполняется следующим образом
ADMoverhead = (4*32) + (32*8) = 384 Mb
Итого у нас остаётся ~45 гигабайт памяти доступной для виртуальных машин.
Англоязычный вариант информации в очень хорошем качестве представлен тут
http://social.technet.microsoft.com/wiki/contents/articles/1234.hyper-v-concepts-vcpu.aspx
Так же очень рекомендую ознакомиться с книгой Microsoft Press: Introducing Windows Server 2012 RTM Edition
http://go.microsoft.com/FWLink/?Linkid=251464
Англоязычный вариант информации в очень хорошем качестве представлен тут
http://social.technet.microsoft.com/wiki/contents/articles/1234.hyper-v-concepts-vcpu.aspx
Так же очень рекомендую ознакомиться с книгой Microsoft Press: Introducing Windows Server 2012 RTM Edition
http://go.microsoft.com/FWLink/?Linkid=251464
Комментариев нет:
Отправить комментарий
Уважаемый коллега, Ваш комментарий пройдёт модерацию, чтобы избежать спам-атак в ленте. Спасибо за понимание.