Сайзинг и планирование

В этом разделе мне бы хотелось обозначить  некоторые  вопросы сайзинга  аппаратного обеспечения  под vSphere. Вопрос вида «какой сервер выбрать под любимый гипервизор» – один из популярных и самых раздражающих – потому что такая формулировка вопроса не корректна.

То, что написано далее, ни в коей мере не «Полное и абсолютное руководство  по подбору оборудования всегда», нет. Это немного теории про то, что такое производительность, – как  показывает  мой  пятилетний  опыт  ведения  ИТ-курсов, даже у самых опытных людей бывают пробелы в обыденных для кого-то другого вещах. Это небольшие нюансы выбора оборудования, связанные именно с виртуализацией. Это вопросы, на которые нельзя давать ответ абстрактно, но о которых стоит задуматься, имея на руках данные конкретного случая.

Итак – нам нужно оборудование  под ESX(i). Что дальше?

Самое  главное  для  понимания,  пусть и очевидное  до невозможности, – это следующее соображение:

Количество  ресурсов, которыми  должен обладать сервер под ESX(i), зависит от суммы требований  для выполнения всех задач, которые мы собираемся  выполнять в ВМ на этом сервере. И еще от того, будем ли мы использовать некоторые функции vSphere (в первую очередь HA/FT), так как эти функции требуют ресурсов сверх необходимых для работы ВМ.

Поговорим  про все подсистемы – процессор, память, диски, сеть. Самая большая и сложная тема – это дисковая подсистема. Должна ли она быть представлена  системой хранения данных (СХД) или обойдемся локальными дисками сервера –

это вопрос относительно простой. Есть бюджет на СХД – она нам нужна ?. На нет и суда нет. Какую именно СХД использовать – будет ли это система с подключением по оптике, Fibre Channel  SAN? Или  достаточно будет 1 Гбит подключения Ethernet и это будет iSCSI SAN? Или это будет iSCSI, но с 10 Гбит подключением? Или NFS? Вариантов масса. Какие диски там будут стоять? Или стоит задуматься  не о дисках, а о SSD-накопителях?

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

Для уже существующей  инфраструктуры статистику  использования той или иной  подсистемы  имеет  смысл  получать  с помощью  соответствующих  средств мониторинга.  Мне известно решение от Майкрософт – System Center Operations Manager (OpsMgr, SCOM).

Ну а наиболее  правильно и удобно использовать специализированное средство анализа инфраструктуры для ее виртуализации – VMware  Capacity Planner. Услуги по обследованию с его помощью оказывают компании-партнеры VMware.

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

1.7.1. Процессор

Мне  видятся  два момента,  связанных с выбором  процессоров  в сервер  под ESX(i).

Первый  – какой производительностью они должны обладать, и второй – накладываются ли на процессоры какие-то условия с точки зрения некоторых функций vSphere.

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

Выбор процессоров с точки зрения функционала

Процессор  – это единственный компонент  сервера, который  не виртуализируется. Это означает, что гостевая  ОС видит тактовую  частоту и, самое главное, наборы инструкций (типа SSE4 и т. п.) физического процессора. Если ВМ просто и без затей работает на каком-то ESX-сервере,  то от такого положения вещей нам ни холодно, ни жарко. Проблемы начинаются, если мы хотим осуществить живую миграцию (ту, что у VMware называет vMotion) этой ВМ на другой ESX(i).

Вывод: если мы предполагаем использование vMotion, то ЦП на этих серверах должны быть одинаковыми. Раскроем  нюансы.

«Одинаковость» здесь должна  быть по функциям этих процессоров. Например, набор инструкций SSE 4.2 – если их поддерживает ЦП сервера, то наличие  этих инструкций увидит и гостевая ОС. Если на ЦП другого сервера этих инструк ций не будет, а мы мигрируем  включенную  ВМ на этот сервер, то гостевая  ОС чрезвычайно удивится  невозможности использовать то, что только что было до-

ступно. И может умереть, сама ОС или приложение. Чтобы такого не было, vCenter в принципе  не даст нам мигрировать ВМ между серверами с разными ЦП.

Резюме:  не важны  тактовая  частота, размер  кеш-памяти и количество ядер. Важны  поддерживаемые функции,  то есть поколение  ЦП,  версия  прошивки и (важно!) настройки BIOS.  Некоторые функции могут  включаться/выключаться из BIOS, поэтому вроде бы одинаковые ЦП могут оказаться  несовместимыми с точки зрения vMotion.  Кстати говоря, не всегда легко найти отличия  в настройке. В моей практике  в таких ситуациях помогал сброс настроек BIOS на значения  по умолчанию.

Далее. Забудьте  предыдущий  абзац. ?

Еще в ESX 3.5 Update 2 и тем более в версии 4 VMware  реализовала и предлагает нам функцию EVC – Enhanced vMotion Compatibility. Суть этой функции – в том, что мы можем «привести  к единому  знаменателю» разные  ЦП  на группе серверов. Например, у нас есть серверы с ЦП поновее – поддерживающие наборы инструкций до SSE 4.2. И есть серверы с ЦП постарше, поддерживающие набор инструкций SSE 4. Если мы объединим  две эти группы серверов и включим  для них EVC, то более новые ЦП выключат у себя SSE 4.2. И все эти серверы (их ЦП)  станут совместимы для vMotion.

Однако для работы EVC требуется, чтобы все процессоры поддерживали технологию «AMD-V  Extended Migration» или «Intel  VT FlexMigration». Это:

Q  для AMD: процессоры Opteron™ начиная с моделей Rev. E/F;

Q  для Intel: начиная с Core™ 2 (Merom).

Подробную  информацию о моделях  можно почерпнуть  или в списке совместимости, или в статье базы знаний http://kb.vmware.com/kb/1003212.

Резюме: если мы приобретаем  процессоры  с поддержкой  этой технологии,  то мы можем не волноваться – совместимость для vMotion будет обеспечена. Ценой этому будет недоступность части новых функций в новых ЦП. Как правило,  это более чем допустимая  жертва.

Надо понимать, что vMotion между серверами с процессорами разных производителей (c AMD на Intel и обратно) невозможен ни при каких условиях.

Попытаюсь резюмировать.

1.    Если вы выбираете процессоры в сервер под ESX, предполагаете использо вание живой миграции aka vMotion и

•    это будут первые ESX(i) серверы вашей инфраструктуры – то выбирать  можно достаточно  свободно  (см. еще соображения по производительности).  Если  в среднесрочной перспективе планируется докупать  еще серверы, то лучше сейчас выбирать процессоры  поновее (из последней группы совместимости EVC), чтобы в будущих серверах еще были доступны к заказу такие же (или представители той же группы);

•    у вас уже есть несколько  ESX(i)-серверов, к ним надо докупить  еще.

Процессоры с поддержкой  EVC можно использовать в одном «кластере EVC»  с процессорами, не поддерживающими Extended Migration / FlexMigration. В таком случае процессоры без поддержки  EVC должны быть одинаковы  между собой.

2.    Если vMotion не предполагается к использованию, то обращать внимание нужно лишь на соображения производительности. Однако в силу того, что на момент написания у VMware  остались только две редакции vSphere, не включающие  vMotion,  – Free и Essentials,  лучше исходить из возможного  включения vMotion в будущем.

Если процессоры  у нас не поддерживают EVC, то совместимость ЦП можно обеспечить  на уровне настроек  ВМ. По эффекту  это похоже на EVC, но выполняется  вручную  и на уровне  отдельной  ВМ, а не группы  серверов.  Правда,  эта

возможность является неподдерживаемой. Вас интересует  настройка  Options ?

CPUID Mask ? Advanced. Наконец,  можно просто отключить  проверку совме-

стимости  ЦП  на уровне  настроек  vCenter.  Подробности см. в соответствующем разделе – про vMotion.

Вторая после vMotion функция, которая обладает собственными требованиями к процессорам, – это VMware Fault Tolerance, FT.

Для  серверов, на которых  работает  VMware  Fault  Tolerance,  должны выполняться  все условия  для vMotion.  Плюс к тому тактовые  частоты процессоров  на разных серверах не должны отличаться более чем на 300 МГц. Наконец, эта функция работает только на процессорах  из списка:

Q  Intel 31xx, 33xx, 34xx, 35xx, 36xx, 52xx, 54xx, 55xx, 56xx, 65xx, 74xx, 75xx;

Q  AMD 13xx, 23xx, 41xx, 61xx, 83xx.

Актуальную информацию о моделях процессоров  для FT ищите в статье базы знаний VMware № 1008027 (http://kb.vmware.com/kb/1008027).

Выбор процессоров с точки зрения производительности

На производительность процессорной  подсистемы оказывают влияние:

1)    количество  ядер (ну и самих процессоров, само собой);

2)    их тактовая частота;

3)    размер кеш-памяти;

4)    поддерживаемые инструкции.

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

Самое эффективное в общем случае – использовать меньше процессорных сокетов и больше ядер, из тех соображений,  что ESX(i) лицензируется на процессоры. Получим более эффективное соотношение цены и производительности. Но не забываем о том, что ESXi с бесплатной  лицензией заработает на сервере не более чем с двумя процессорами, и для всех лицензий, кроме Advanced и Enterprise Plus, возможно  использование процессоров  не более чем с шестью ядрами  (информация верна на момент написания).

Еще один нюанс: один виртуальный процессор равен одному ядру физическо-

го сервера как максимум. Нельзя взять два физических ядра и объединить в одно

виртуальное,  можно только «поделить»  одно физическое на несколько виртуаль ных. Поэтому чем большей частотой будут обладать выбранные вами процессоры, тем большей максимальной производительностью будет обладать один виртуаль ный процессор.

Остальное,  по моему мнению, менее критично.

Что такое  и зачем надо Intel-VT / AMD-V. Аппаратная поддержка виртуализации

Процессор  исполняет инструкции. Эти инструкции выполняются с тем или иным приоритетом,  который  традиционно называется «кольцом» (ring).  Кольцо 0 имеет наибольший приоритет, и именно в этом кольце работает ядро ОС, управляющее всеми ресурсами.

Но. В случае использования виртуализации ОС несколько, и ресурсами сервера должен управлять гипервизор,  распределяя эти ресурсы между ОС в ВМ. Выходов несколько:

Q  в ESX(i) реализована технология  под названием  «Binary translation» – про-

граммный  механизм  «вытеснения» ядра гостевой  ОС  из нулевого кольца. ESX(i) на лету подменяет  инструкции процессора таким образом, что работают они на уровне выше нулевого  кольца, а ядру гостевой  операционной системы кажется,  что оно на самом деле в нулевом  кольце. Таким  образом, ESX(i) может работать на процессорах без аппаратной поддержки виртуали зации. Гипервизор работает в кольце 0. Это самый старый механизм, который в наше время считается унаследованным. Он обладает самыми высокими накладными расходами и вообще не работает для 64-битных гостевых ОС;

Q  паравиртуализация ОС. Ядро гостевой ОС может быть изменено  для кор-

ректной работы в ВМ – тогда гипервизору не требуется принудительно «выгонять» ядро из нулевого кольца. В силу необходимости изменения кода ОС на уровне ядра, притом изменения разного рода для разных гипервизоров, паравиртуализация не стала массовой. Тем не менее использование паравир туализованных ОС в ВМ на современных  гипервизорах позволяет  снизить накладные  расходы на виртуализацию. Известные мне источники говорят о примерно  10%-ной  разнице  по  сравнению  с непаравиртуализованными ОС. Для запуска паравиртуализованных гостевых ОС нет необходимости в аппаратной поддержке  виртуализации. Паравиртуализация де-факто мало актуальна для ESX(i), поэтому здесь упоминается для полноты картины;

Q  та самая аппаратная поддержка  виртуализации. Она реализуется с помо-

щью технологий  Intel  VT  (Virtualization Technology) или  AMD-V.  Если процессор обладает этой возможностью,  то это означает, что он предоставляет для гипервизора специфический приоритет. Этот приоритет  обычно называют кольцо –1 (минус один). Специфичность проявляется в том, что исполняемые в этом кольце инструкции, с одной стороны, еще приоритет нее, чем инструкции кольца нулевого; а с другой – в минус первом кольце могут исполняться не все инструкции. Впрочем, все, необходимые  гипервизору, в наличии. Таким образом, если процессоры сервера обладают аппаратной поддержкой виртуализации, то гипервизор на таком сервере может

запускать  любые гостевые  операционные системы  без необходимости их модификации. Этот режим является штатным для ESX(i).

Уже несколько лет все выпускаемые серверные (да и не только серверные) процессоры  аппаратно  поддерживают виртуализацию. Если вы работаете с не очень современным  сервером, обратите  внимание  на этот аспект отдельно. Дело в том, что поддержка  аппаратной  виртуализации должна  быть  реализована не только в процессоре, но и в материнской плате (возможно, потребуется обновление BIOS).

Однако  возможность реализовать виртуальную инфраструктуру даже на серверах без аппаратной  поддержки  виртуализации является архиполезной, если подобная задача перед вами все-таки встала.

1.7.2. Память

К ОЗУ требований особо нет. Ее просто должно быть достаточно. Грубая оценка достаточного объема:

1.    Берем  информацию о том, сколько памяти  необходимо  каждой ВМ. Суммируем. Округляем до удобного для установки в сервер объема.

2.    Хотя при сайзинге это учитывать не следует, но часть памяти окажется свободной. В этом помогут механизмы ESX(i) по работе с памятью. Учитывать  же при планировании эти механизмы  не рекомендуется по причине  того, что в общем случае эффект экономии не гарантируется. Впрочем, вы можете вывести  и использовать свой коэффициент в зависимости от собственного опыта,  понимания специфики  планируемой нагрузки  и готовности  идти на риск не полностью сбывшихся  прогнозов.

3.    Кроме того, разные  ВМ  могут действительно использовать свою  память полностью  в разное время. Следовательно, суммарный  объем занятой  памяти  на сервере  в среднем окажется  меньше суммарного объема памяти, выделенной для всех виртуальных машин. На этот эффект  тоже не рекомендуют полагаться  при сайзинге.

4.    По причинам  из пунктов 2 и 3 делать большой запас по памяти  не следует.

Впрочем, большинство инфраструктур имеют обыкновение расти и в сторону увеличения количества  ВМ, и в сторону увеличения нагрузки на существующие ВМ, так что при такой перспективе памяти лучше взять больше.

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий