Что такое VMware и почему важна ее совместимость с SSD-накопителями
Привет, Хабр! Сегодня мы поговорим о виртуальных машинах, программном обеспечении VMware и накопителях Kingston, конечно же. В частности, разберем вопросы на тему “зачем нужна сертификация VMware Ready, какие из SSD-решений получают статус VMware Ready for Storage, и о чем это говорит?”. Начнем с самого банального.
Безусловно, аудитории Хабра знакома компания VMware, которая занимается разработкой программного обеспечения для виртуализации и организации облачных вычислений. Продукты VMware включают в себя средства виртуализации, управления сетью и безопасностью, программное обеспечение для ЦОД и хранения данных.
Первым таким продуктом стала программа VMware Workstation, которая позволяла любому пользователю установить на своем ПК одну или несколько виртуальных машин: то бишь имитацию аппаратной начинки компьютера в лице процессора, видеокарты, накопителей, оптических приводов и т.д. Эдакий компьютер в компьютере.
В рамках серверной среды VMware Workstation вкупе с установленным гипервизором VMware ESX позволяет запускать несколько виртуальных машин на одном физическом сервере, при этом каждая из ВМ может работать со своей операционной системой. Следовательно — на одном сервере могут быть активными сразу несколько разных ОС.
При этом все установленные ВМ совместно используют доступные ресурсы (сетевую карту и оперативную память), но работают независимо друг от друга. Основными продуктами в этом направлении является платформа VMware vSphere, гипервизор VMware ESX и VMware ESXi, VMware Server и vCenter Server. Впрочем, серверная виртуализация — не единственный тип абстрагирования от аппаратной реализации.
Типы виртуализации VMware
Все программы для виртуализации можно разделить на пять типов: серверная виртуализация, виртуализация десктопов, сетевая виртуализация, виртуализация хранилищ и ПО для управления облачными средами. О виртуализации в серверной среде мы уже немного рассказали выше, а вот что подразумевается под остальными типами?
Виртуализация десктопов и облачные среды
Виртуализация десктопов, которую иногда называют инфраструктурой виртуальных десктопов (VDI), — это такой тип виртуализации, при котором ОС настольных ПК работает как виртуальная машина на физическом сервере с другими виртуальными десктопами. Обработка нескольких виртуальных рабочих мест происходит на одном или нескольких физических серверах, обычно – в централизованном ЦОД. Копия ОС и приложений, которые использует каждый конечный пользователь, обычно кэшируется в памяти, как один образ на физическом сервере.
Пакет VMware Horizon позволяет организациям запускать рабочие столы Windows в центре обработки данных или в облачных сервисах на базе VMware Cloud, что устраняет необходимость размещения и управления десктопами с офисного рабочего места, централизует управление пользовательской средой и обеспечивает ее безопасность.
При развертывании данного типа виртуализации используется ПО для выполнения сетевых функций путем отделения виртуальных сетей от базового сетевого оборудования. Как только вы начнете использовать виртуализацию сети, физическая сеть будет использоваться только для пересылки пакетов, поэтому все управление осуществляется с помощью виртуальных или программных коммутаторов. Поставщиками сетевой виртуализации являются внутренние виртуальные коммутаторы гипервизора. Кроме того, сторонние поставщики, такие как Cisco и IBM, разработали виртуальные коммутаторы, которые могут использоваться гипервизорами, такими как ESXi.
Как мы уже отмечали, для каждого типа виртуализации компания VMware предлагает определенный набор софта. Например, если мы говорим о хранении данных, то следует принимать во внимание такие решения, как VMware vSAN и VMware Site Recovery Manager (SRM). VMware vSAN — программная функция хранения, встроенная в гипервизор ESXi и интегрированная с vSphere. Она объединяет дисковое пространство от нескольких хостов ESXi и выделяет его с помощью интеллектуальных политик, таких как ограничения защиты, тонкое выделение ресурсов и кодирование стирания. А еще эта опция интегрируется с функцией vSphere High Availability, обеспечивая повышенную производительность вычислений и самого хранилища.
VMware Site Recovery Manager (SRM) предназначен для управления аварийным восстановлением, что позволяет администраторам создавать планы восстановления, которые автоматически выполняются в случае сбоя, а также автоматически организовывать аварийное переключение и восстановление виртуальных машин. SRM также интегрируется с VMware NSX (инструмент управления сетевыми операциями) для сохранения сетевых политик и политик безопасности на виртуальных машинах, перемещенных на новые физические сервера.
Зачем нужна сертификация VMware Ready
Начнем с того, что сертификация VMware Ready означает высокий уровень одобрения для продуктов, созданных партнерами компании VMware. Нетрудно догадаться, что Kingston Digital входит в их число: в частности, является членом “Партнерского технологического альянса VMware”. Участники этого альянса разрабатывают свои устройства в соответствии со стандартами VMware и предоставляют их техническим специалистам компании, которые проводят различные сертификационные тесты.
По итогам проверок, сервера, компьютеры, устройства хранения и другие устройства, отвечающие сертификационным требованиям, получают заветный логотип VMware Ready. Кроме того, в дальнейшем эти продукты поддерживаются как со стороны компании-партнера, так и со стороны VMware. Подробную информацию о твердотельных накопителях Kingston из линейки, которые прошли сертификацию VMware можно найти и на портале VMware Solution Exchange (VSX). Там же размещаются обновления ПО для пользователей “железа” сертифицированного VMware.
Возвращаясь к “Партнерскому технологическому альянсу VMware”, стоит упомянуть о том, что участие в нем позволяет клиентам быстро находить сертифицированное оборудование партнеров, не занимаясь точечным и индивидуальным подбором компонентов, которые в итоге могут не обеспечить ожидаемую производительность. Не в последнюю очередь это способствует росту продаж накопителей Kingston. Только за первое полугодие 2019 года компании удалось реализовать более 13,3 миллиона твердотельных накопителей (по исследованиям TrendFocus). Если говорить о глобальных поставках, хорошие продажи обеспечили Kingston третье место в списке лидеров по реализации SSD-накопителей после Samsung и Western Digital.
Какие SSD-накопители обладают статусом VMware Ready
Применительно к накопителям Kingston серверного класса, сертификацию VMware Ready for Storage имеют твердотельные SATA-накопители Kingston DC500R и Kingston DC500M, рекомендованные для использования в ЦОД. Как мы уже отметили выше, присвоенный данным SSD-решениям статус говорит о том, что DC500R и DC500M получили полное одобрение от специалистов VMware, успешно пройдя все тесты.
Именно эта сертификация позволяет представителям Kingston Digital говорить о том, что при использовании SSD DC500R и DC500M в среде vSAN и серверах vSphere можно ожидать высокой производительности при выполнении большого количества операций чтения данных и смешанных нагрузках. К слову, для прохождения сертификации серверные накопители настраиваются в соответствии с требованиями от VMware и в итоге обеспечивают высокую пропускную способность, кол-во IPOS, а также минимальную задержку в 99% сценариев.
Как итог: сертифицированные SSD Kingston с чистой совестью можно отнести к классу высокопроизводительных ускорителей для виртуализированных рабочих нагрузок смешанного типа в рамках серверной среды. Также они позволяют облачным службам работать с максимальной эффективностью и предоставляют пользователям очень быстрый доступ к данным. Собственно, от них это и требуется.
Для получения дополнительной информации о продуктах Kingston Technology обращайтесь на официальный сайт компании.
Нюансы CPU Ready
Товарищи из VMkernel написали еще один интересный документ, посвященный метрике CPU Ready. С ней не все однозначно, поэтому я с интересом взялся за перевод.
CPU Ready — это метрика, показывающая сколько времени процесс стоял в ожидании процессорного времени.
Имеются следующие предпосылки к высокому CPU Ready:
1) Переиспользование (Oversubscription) процессора. То есть соотношение количества физических процессоров (PCPU или «ядер») к количеству виртуальных процессоров (VCPU — процессоров виртуальных машин). Согласно vSphere 5 Configuration Maximums на одно ядро можно впихнуть до 25 виртуальных процессоров. Чудес не бывает — эти процессоры должны быть должным образом ненагружены, чтобы такой фокус удался. VMKernel предлагает следующие варианты:
— от 1:1 до 1:3 — все ок;
— от 1:3 до 1:5 — могут быть проблемы из-за конкуренции за ресурсы;
— от 1:5 — скорее всего будут проблемы.
Тут же стоит помнить о Hyper-Threading: эта технология удваивает количество PCPU, но полноценно выполняться код может только на одном из пары.
Ситуацию с задержкой из-за HT можно увидеть в ESXTOP/RESXTOP. После запуска нажимаете «F» и добавляете поля «I: SUMMARY STATS = CPU Summary Stats». Параметр «%LAT_C» как раз и отвечает за задержки по вине процессора. Обратите внимание еще и на параметр «%LAT_M» — он отвечает за задержки по вине оперативной памяти (например, свопа).
2) Использование лимита процессорного ресурса
Хотя это не рекомендуется, вы можете задать ограничение на количество используемых ресурсов (процессора или памяти) для ВМ или пула ресурсов. В этом случае метрика %RDY будет ненулевой. Данную ситуацию легко можно увидеть, так как в этом случае также ненулевой будет метрика %MLMTD (также включенная в %RDY). То есть для понимания «чистого» CPU Ready вам необходимо из %RDY вычесть %MLMTD.
3) Привязка vCPU к PCPU.
Для определенной виртуальной машины вы можете задать CPU Affinity — список физических процессоров, на которых виртуальная машина может выполняться. В этом случае scheduler не сможет раскидать нагрузку по разным процессорам, и ВМ могут недополучать процессорное время, хотя есть свободные процессоры. Практический смысл тут один — если вы не хотите лицензировать N процессоров физического сервера (например для SQL), задаете подобное соответствие. Вроде бы в этом случае можно купить столько лицензий, на скольки процессорах может работать ВМ.
Ну и подводный камень — vMotion то ли не работает, то ли сбрасывает эту настройку.
4) Использование Fault Tolerance
Если при использовании FT ресурсов хостов не хватает для обеспечения реплики, то машина источник начинает притормаживать. При этом также будет увеличен счетчик %MLMTD.
Основные заблуждения относительно производительности CPU
1) Дополнительный PCPU, получающийся засчет HyperThreading, не дает такой же производительности, как дополнительное ядро. То есть, ваши гигагерцы, указанные в vClient, становятся нечестными. В документе приводится цифра в 75%, на мой взгляд она достаточно оптимистичная. При проектировании это надо учитывать.
2) Большое количество гигагерц, доступных на ваших хостах, вовсе не означает, что вы можете их без проблем «снять».
3) Прямой зависимости между vCPU Usage и CPU Ready нет. Правильнее сказать — оно зависит от… 🙂
4) DRS не помогает решать вопросы с CPU Ready. Он всего лишь оценивает загрузку ЦПУ хоста для принятия решения о миграции.
Сколько CPU Ready считать нормальным?
Авторы статьи считают 5% на один vCPU. Duncan Epping считает — 10%.
В ESXTOP этот параметр так и отображается, в vClient он меряется в миллисекундах и вам необходимо провести несложные вычисления.
Например, у вас есть двухпроцессорная машина, CPU Ready которой составляет 5000ms. Так как период сбора статистики составляет 20 секунд, нам необходимо разделить измеренное значение на 20000. И для подсчета «CPU Ready per processor» поделить также на количество процессоров.
Нюансы CPU Ready: 6 комментариев
>>>>То есть, ваши гигагерцы, указанные в vClient, становятся нечестными.
У меня на хостах с включенным HT, доступные гигагерцы считаются только исходя из реальных физических ядер. Так что все честно 🙂
>>>>В ESXTOP этот параметр так и отображается, в vClient он меряется в миллисекундах и вам необходимо провести несложные вычисления.
В клиенте этот параметр виден и в %, если смотреть в «overview» режиме (на кажый vCPU и суммарно на всю виртуалку).
Блин 🙂
Действительно, это так.
Сколько CPU Ready считать нормальным?
У меня есть два сервака (терминалы Windows 2003 с 1с 7.7 и 8.2). У них если Ready становится больше чем 1-2% на процессор начинаются неприятности в виде обрывов (в основном с автоматическим переподключением) сессий клиентов (с MS SQL связь стабильная). Остальные (терминалы Windows 2003 с MS Office и прочим) «кушают» (правда притормаживая) и положенные 10% на vCPU без вопросов. Нстройки сети везде одинаковые.
НТ у меня существенно улушает дела (на 12 ядер с НТ до 40 ВМ, некоторые до 50 vCPU). 25% дополнительных ВМ получил (процессор больше чем на 78% занят не бывает) с сохранение приемлемого Ready
Добрый день, Алексей. Я склонен метаться между значениями 5% и 10%.
А проблема точно в CPU Ready с вашими терминалами?
То есть, с резервированием ресурсов все работает как часы. Снимаете резервирование процессора — в часы пик начинают происходить разрывы?
—
Вообще говоря, странное поведение. А сервер SQL находится на этом же сервере или другом?
Добавить комментарий Отменить ответ
What’s New in 3.0.0, November 2021 Release Scheduled Tasks Scheduler feature can be used to run periodic health checks on…
Проверь и расскажи нам!
Будет работать Horizon agent вместе с Direct Connect plгпшт с Windows Server в режиме RDSH, без Connection Server?
Ни разу с таким не встречался, это какой-то корнер-кейс с увеличением сразу на 20 ТБ?
А мы успели не только скачать, но и раскатать на несколько хостов 🙂
Так уже откатили же, даже не скачать.
Я не расист. но после того как VMware стала упралвяться и поддерживаться индусами, стабильность продукта сдохла как бобик.
Анализ производительности виртуальной машины в VMware vSphere. Часть 1: CPU
Если вы администрируете виртуальную инфраструктуру на базе VMware vSphere (или любого другого стека технологий), то наверняка часто слышите от пользователей жалобы: «Виртуальная машина работает медленно!». В этом цикле статей разберу метрики производительности и расскажу, что и почему «тормозит» и как сделать так, чтобы не «тормозило».
Буду рассматривать следующие аспекты производительности виртуальных машин:
Для анализа производительности нам понадобятся:
Немного теории
В ESXi за работу каждого vCPU (ядра виртуальной машины) отвечает отдельный процесс – world в терминологии VMware. Также есть служебные процессы, но с точки зрения анализа производительности ВМ они менее интересны.
Процесс в ESXi может находиться в одном из четырех состояний:
Основные счетчики производительности CPU виртуальной машины
CPU Usage, %. Показывает процент использования CPU за заданный период.
Как анализировать? Если ВМ стабильно использует CPU на 90% или есть пики до 100%, то у нас проблемы. Проблемы могут выражаться не только в «медленной» работе приложения внутри ВМ, но и в недоступности ВМ по сети. Если система мониторинга показывает, что ВМ периодически отваливается, обратите внимание на пики на графике CPU Usage.
Есть стандартный Аlarm, который показывает загрузку CPU виртуальной машины:
Что делать? Если у ВМ постоянно зашкаливает CPU Usage, то можно задуматься об увеличении количества vCPU (к сожалению, это не всегда помогает) или переносе ВМ на сервер с более производительными процессорами.
CPU Usage in Mhz
В графиках на vCenter Usage в % можно посмотреть только по всей виртуальной машине, графиков по отдельным ядрам нет (в Esxtop значения в % по ядрам есть). По каждому ядру можно посмотреть Usage in MHz.
Как анализировать? Бывает, что приложение не оптимизировано под многоядерную архитектуру: использует на 100% только одно ядро, а остальные простаивают без нагрузки. Например, при дефолтных настройках бэкапа MS SQL запускает процесс только на одном ядре. В итоге резервное копирование тормозит не из-за медленной скорости дисков (именно на это изначально пожаловался пользователь), а из-за того, что не справляется процессор. Проблема была решена изменением параметров: резервное копирование стало запускаться параллельно в несколько файлов (соответственно, в несколько процессов).
Пример неравномерной нагрузки ядер.
Также бывает ситуация (как на графике выше), когда ядра нагружены неравномерно и на некоторых из них есть пики в 100%. Как и при загрузке только одного ядра, alarm по CPU Usage не сработает (он по всей ВМ), но проблемы с производительностью будут.
Что делать? Если ПО в виртуальной машине нагружает ядра неравномерно (использует только одно ядро или часть ядер), нет смысла увеличивать их количество. В таком случае лучше переместить ВМ на сервер с более производительными процессорами.
Также можно попробовать проверить настройки энергопотребления в BIOS сервера. Многие администраторы включают в BIOS режим High Performance и тем самым отключают технологии энергосбережения C-states и P-states. В современных процессорах Intel используется технология Turbo Boost, которая увеличивает частоту отдельных ядер процессора за счет других ядер. Но она работает только при включенных технологиях энергосбережения. Если мы их отключаем, то процессор не может уменьшить энергопотребление ядер, которые не нагружены.
VMware рекомендует не отключать технологии энергосбережения на серверах, а выбирать режимы, которые максимально отдают управление энергопотреблением гипервизору. При этом в настройках энергопотребления гипервизора нужно выбрать High Performance.
Если у вас в инфраструктуре отдельные ВМ (или ядра ВМ) требуют повышенную частоту CPU, корректная настройка энергопотребления может значительно улучшить их производительность.
CPU Ready (Readiness)
Если ядро ВМ (vCPU) находится в состоянии Ready, оно не выполняет полезную работу. Такое состояние возникает, когда гипервизор не находит свободное физическое ядро, на которое можно назначить процесс vCPU виртуальной машины.
Как анализировать? Обычно если ядра виртуальной машины находятся в состоянии Ready больше 10% времени, то вы заметите проблемы с производительностью. Проще говоря, больше 10% времени ВМ ждет доступности физических ресурсов.
В vCenter можно посмотреть 2 счетчика, связанных с CPU Ready:
Значения счетчика Ready можно посмотреть также в исторической перспективе. Это полезно для установления закономерностей и для более глубокого анализа проблемы. Например, если у виртуальной машины начинаются проблемы с производительностью в какое-то определенное время, можно сопоставить интервалы повешенного значения CPU Ready с общей нагрузкой на сервер, где данная ВМ работает, и принять меры по снижению нагрузки (если DRS не справился).
Ready в отличие от Readiness показывается не в процентах, а миллисекундах. Это счетчик типа Summation, то есть он показывает, сколько времени за период измерения ядро ВМ находилось в состоянии Ready. Перевести данное значение в проценты можно по несложной формуле:
(CPU ready summation value / (chart default update interval in seconds * 1000)) * 100 = CPU ready %
Например, для ВМ на графике ниже пиковое значение Ready на всю виртуальную машину получится следующим:
При подсчете значения Ready в процентах стоит обращать внимание на два момента:
Рассчитаем Ready на основе данных из графика ниже. (324474/(20*1000))*100 = 1622% на всю ВМ. Если смотреть по ядрам получится уже не так страшно: 1622/64 = 25% на ядро. В данном случае обнаружить подвох довольно просто: значение Ready нереалистичное. Но если речь идет о 10–20% на всю ВМ с несколькими ядрами, то по каждому ядру значение может быть в пределах нормы.
Что делать? Высокое значение Ready говорит о том, что серверу не хватает ресурсов процессора для нормальной работы виртуальных машин. В такой ситуации остается только уменьшить переподписку по процессору (vCPU:pCPU). Очевидно, этого можно добиться, уменьшив параметры существующих ВМ или путем миграции части ВМ на другие серверы.
Co-stop
Как анализировать? Данный счетчик также имеет тип Summation и переводится в проценты аналогично Ready:
(CPU co-stop summation value / (chart default update interval in seconds * 1000)) * 100 = CPU co-stop %
Здесь также нужно обращать внимание на количество ядер на ВМ и на интервал измерения.
В состоянии сostop ядро не выполняет полезную работу. При правильном подборе размера ВМ и нормальной нагрузке на сервер счетчик со-stop должен быть близок к нулю.
В данном случае нагрузка явно ненормальная:)
Что делать? Если на одном гипервизоре работают несколько ВМ с большим количеством ядер и есть переподписка по CPU, то счетчик co-stop может вырасти, что приведет к проблемам с производительностью данных ВМ.
Также co-stop вырастет, если для активных ядер одной ВМ используются треды на одном физическом ядре сервера со включенным hyper-treading. Такая ситуация может возникнуть, например, если у ВМ больше ядер, чем физически есть на сервере, где она работает, или если для ВМ включена настройка «preferHT». Про эту настройку можно прочитать здесь.
Чтобы избежать проблем с производительностью ВМ из-за высокого сo-stop, выбирайте размер ВМ в соответствии с рекомендациями производителя ПО, которое работает на этой ВМ, и с возможностями физического сервера, где работает ВМ.
Не добавляйте ядра про запас, это может вызвать проблемы с производительностью не только самой ВМ, но и ее соседей по серверу.
Другие полезные метрики CPU
Run – сколько времени (мс) за период измерения vCPU находился в состоянии RUN, то есть собственно выполнял полезную работу.
Idle – сколько времени (мс) за период измерения vCPU находился в состоянии бездействия. Высокие значения Idle – это не проблема, просто vCPU было «нечего делать».
Wait – сколько времени (мс) за период измерения vCPU находился в состоянии Wait. Так как в данный счетчик включается IDLE, высокие значения Wait также не говорят о наличии проблемы. А вот если при высоком Wait IDLE низкий, значит ВМ ждала завершения операций ввода/вывода, а это, в свою очередь, может говорить о наличии проблемы с производительностью жесткого диска или каких-либо виртуальных устройств ВМ.
Max limited – сколько времени (мс) за период измерения vCPU находился в состоянии Ready из-за установленного лимита по ресурсам. Если производительность необъяснимо низкая, то полезно проверить значение данного счетчика и лимит по CPU в настройках ВМ. У ВМ действительно могут оказаться выставлены лимиты, о которых вы не знаете. Например, так происходит, когда ВМ была склонирована из шаблона, на котором был установлен лимит по CPU.
Swap wait – сколько времени за период измерения vCPU ждал операции с VMkernel Swap. Если значения данного счетчика выше нуля, то у ВМ точно есть проблемы с производительностью. Подробнее про SWAP поговорим в статье про счетчики оперативной памяти.
ESXTOP
Если счетчики производительности в vCenter хороши для анализа исторических данных, то оперативный анализ проблемы лучше производить в ESXTOP. Здесь все значения представлены в готовом виде (не нужно ничего переводить), а минимальный период измерения 2 секунды.
Экран ESXTOP по CPU вызывается клавишей «c» и выглядит следующим образом:
Для удобства можно оставить только процессы виртуальных машин, нажав Shift-V.
Чтобы посмотреть метрики по отдельным ядрам ВМ, нажмите «e» и вбейте GID интересующей ВМ (30919 на скриншоте ниже):
Кратко пройдусь по столбцам, которые представлены по умолчанию. Дополнительные столбцы можно добавить, нажав «f».
NWLD (Number of Worlds) – количество процессов в группе. Чтобы раскрыть группу и увидеть метрики для каждого процесса (например, для каждого ядра многоядерной ВМ), нажмите “e”. Если в группе больше одного процесса, то значения метрик для группы равны сумме метрик для отдельных процессов.
%USED – сколько циклов CPU сервера использует процесс или группа процессов.
%RUN – сколько времени за период измерения процесс находился в состоянии RUN, т.е. выполнял полезную работу. Отличается от %USED тем, что не учитывает hyper-threading, frequency scaling и время, затраченное на системные задачи (%SYS).
%SYS – время, затраченное на системные задачи, например: обработку прерываний, ввода/вывода, работу сети и пр. Значение может быть высоким, если на ВМ большой ввод/вывод.
%OVRLP – сколько времени физическое ядро, на котором выполняется процесс ВМ, потратило на задачи других процессов.
Данные метрики соотносятся между собой следующим образом:
%USED = %RUN + %SYS — %OVRLP.
Обычно метрика %USED является более информативной.
%WAIT – сколько времени за период измерения процесс находился в состоянии Wait. Включает IDLE.
%IDLE – сколько времени за период измерения процесс находился в состоянии IDLE.
%SWPWT – сколько времени за период измерения vCPU ждал операции с VMkernel Swap.
%VMWAIT – сколько времени за период измерения vCPU находилось в состояния ожидания события (обычно ввода/вывода). Аналогичного счетчика нет в vCenter. Высокие значения говорят о проблемах с вводом/выводом на ВМ.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Если ВМ не использует VMkernel Swap, то при анализе проблем с производительностью целесообразно смотреть на %VMWAIT, так как данная метрика не учитывает время, когда ВМ ничего не делала (%IDLE).
%RDY – сколько времени за период измерения процесс находился в состоянии Ready.
%CSTP – сколько времени за период измерения процесс находился в состоянии сostop.
%MLMTD – сколько времени за период измерения vCPU находился в состоянии Ready из-за установленного лимита по ресурсам.
%WAIT + %RDY + %CSTP + %RUN = 100% – ядро ВМ все время находится в каком-то из этих четырех состояний.
CPU на гипервизоре
В vCenter есть также счетчики производительности CPU для гипервизора, но они не представляют из себя ничего интересного – это просто сумма счетчиков по всем ВМ на сервере.
Удобнее всего смотреть состояние CPU на сервере на вкладке Summary:
Для сервера, как и для виртуальной машины, есть стандартный Alarm:
При высокой нагрузке на CPU сервера у ВМ, работающих на нем, начинаются проблемы с производительностью.
В ESXTOP данные о загрузке CPU сервера представлены в верхней части экрана. Помимо стандартного CPU load, который малоинформативен для гипервизоров, есть еще три метрики:
CORE UTIL(%) – загрузка ядра физического сервера. Данный счетчик показывает, сколько времени за период измерения ядро выполняло работу.
PCPU UTIL(%) – если включен hyper-threading, то на каждое физическое ядро приходится два потока (PCPU). Данная метрика показывает, сколько времени каждый поток выполнял работу.
PCPU USED(%) – то же, что PCPU UTIL(%), но учитывает frequency scaling (либо снижение частоты ядра в целях энергосбережения, либо повышение частоты ядра за счет технологии Turbo Boost) и hyper-threading.
PCPU_USED% = PCPU_UTIL% * эффективную частоту ядра / номинальную частоту ядра.
На этом скриншоте для некоторых ядер из-за работы Turbo Boost’а значение USED больше 100%, так как частота ядра выше номинальной.
Пара слов о том, как учитывается hyper-threading. Если процессы исполняются 100% времени на обоих потоках физического ядра сервера, при этом ядро работает на номинальной частоте, то:
В ESXTOP также есть экран с параметрами энергопотребления CPU сервера. Здесь можно посмотреть, используются ли сервером технологии энергосбережения: C-states и P-states. Вызывается клавишей «p»:
Стандартные проблемы производительности CPU
Напоследок пробегусь по типичным причинам возникновения проблем с производительностью CPU ВМ и дам короткие советы их решению:
Не хватает тактовой частоты ядра. Если нет возможности перевести ВМ на более производительные ядра, можно попробовать изменить настройки энергопотребления, чтобы Turbo Boost работал эффективнее.
Неправильный сайзинг ВМ (слишком много/мало ядер). Если поставить мало ядер, будет высокая загрузка CPU ВМ. Если много, словите высокий co-stop.
Большая переподписка по CPU на сервере. Если на ВМ высокий Ready, снизьте переподписку по CPU.
Неправильная NUMA-топология на больших ВМ. NUMA-топология, которую видит ВМ (vNUMA), должна соответствовать NUMA-топологии сервера (pNUMA). Про диагностику и возможные варианты решения данной проблемы написано, например, в книге «VMware vSphere 6.5 Host Resources Deep Dive». Если не хотите углубляться и у вас нет лицензионных ограничений по ОС, установленной на ВМ, делайте на ВМ много виртуальных сокетов по одному ядру. Много не потеряете 🙂
На этом про CPU у меня все. Задавайте вопросы. В следующей части расскажу про оперативную память.
