Vmware переподписка по cpu что это
Облачные технологии: 5 главных характеристик
Самообслуживание
Облачные услуги оставляют за заказчиком возможность самому, с помощью администраторов или представителей, обслуживать свою инфраструктуру внутри облака. Проще говоря, для компании, заказавшей облачную услугу, провайдер создает личный кабинет с возможностью управления серверными мощностями: в личном кабинете ИТ-специалист компании может создавать виртуальные машины, добавлять необходимые в данный момент ресурсы, и смотреть текущий статус своего заказа. Благодаря самообслуживанию заказчик постоянно держит руку на пульсе и знает, как функционирует ИТ-инфраструктур в его компании.
Универсальный доступ
Универсальный доступ подразумевает, что к облаку, к инфраструктуре, которую заказчик получает у облачного провайдера, можно получить доступ из любой точки мира через интернет. Универсальный доступ к облаку можно также получить, используя любое устройство: планшеты, мобильные устройства, ноутбуки. Таким образом реализуется принцип – работа в облаке и с облаком в любом месте, в любое время, с любого устройства.
Объединение ресурсов
Эластичность
Эластичность – это гибкость выделения ресурсов. Если заказчик создает у себя программно-аппаратный комплекс, он закупает сервера и программное обеспечение под определенную задачу. Он делает сайзинг: подбирает оборудование под требования информационных систем. Правильный сайзинг означает подбор такого количества оборудования, чтобы информационной системе хватило мощностей в периоды пиковых нагрузок. Пиковые нагрузки, например, сайта госзакупок приходятся на конец года и конец квартала. В ритейле период пиковых нагрузок – это момент выхода какого-нибудь нового востребованного продукта или предпраздничное время: 8 марта, 23 февраля, Новый год и т.д. В этот период информационные системы должны выдержать максимальную нагрузку. Проблема в том, что, естественно, в момент непиковой нагрузки закупленные ресурсы простаивают, т.е. закупив оборудование под информационную систему в ПАКе, заказчик тратит больше денег, чем требуется. По факту закупленные ресурсы востребованы лишь 20% в году, а всё остальное время они простаивают.
Эластичность облачных технологий как раз решает эту проблему: заказчик может гибко увеличивать и уменьшать ресурсы в зависимости от задач бизнеса в данный момент. В период пиковых нагрузок заказчик может самостоятельно увеличить количество ресурсов. В момент спада нагрузки он может уменьшить количество серверных мощностей и платить только по факту использования ресурсов.
Учет потребления
Учетом потребления также называется биллинг. Это инструмент, который позволяет заказчику видеть, какое количество ресурсов он использовал. Биллинг позволяет легко проанализировать показатели потребления ресурсов за выбранный промежуток времени: час, сутки, день, год. Системы автоматической отчетности, работающие в облаке, позволят снимать отчеты по нагрузке. Биллинг – это система, которая помимо отчета о нагрузке, также выдает отчеты в денежном эквиваленте – считает потребленные ресурсы в деньгах, выставляет акты, счета.
Нюансы 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 или что делать, если тормозит ВМ
Что-то в последнее время технические статьи о виртуализации (да и не только о виртуализации) скатываются к формату «в новой версии ожидается такая фича». Складывается ощущение, что разбор механизмов и описание опыта, проблем и решений интересны только зарубежным экспертам. С другой стороны, есть такая проблема у экспертов — если что-то изучил, оно становится элементарным и воспринимается само собой разумеющимся, настолько, что писать об этом как-то глупо. Особенно если уже было кем-то описано где-то. Когда-то. На каком-то языке. Ниженаписанное — плод консолидации личных заметок, сначала предназначавшийся для личного упорядочивания мыслей, но наупорядочив значительный объём текста, подумал, что кому-то может пригодиться.
Типовая проблема «виртуализаторов» — владелец сервиса, заказчик или пользователь жалуется, что у него «тормозит» виртуальная машина. Так как виртуализация предполагает консолидацию большого количества ВМ на базе одного комплекта аппаратных ресурсов, переподписку (overprovision — когда мы предполагаем, что серверы не затребуют одновременно максимум своих ресурсов, а значит, например, в 40 ГБ физической памяти мы можем натолкать не 10 серверов по 4 ГБ RAM, а 15, используя Dynamic Memory), а кроме того, серверы могут тормозить и из-за ошибок в программных компонентах и их настройках, то каждый раз приходится решать за что хвататься и куда смотреть в первую очередь. Особенно, если с таким ёмким описанием проблемы, как «тормозит машина» не предоставлено никакой диагностической информации, как чаще всего и бывает. Под катом небольшое руководство для этого случая.
Конечно, всё зависит от специфичности реализации конкретной инфраструктуры, но практика показывает, что в большинстве случаев имеет смысл следующая последовательность анализа подсистем ВМ:
На практике, до 4-го этапа почти никогда не доходит, после третьего (а то и после первого) имеет смысл запускать (или запрашивать) параллельную диагностику гостевой ОС, но диски стоит проверить сразу — самая значительная часть инцидентов с жалобами на производительность связано с ними. Если, конечно, у вас не All-Flash массив.
А теперь чуть подробнее по каждому пункту.
1. Диски (подсистема хранения)
Самый ключевой тут показатель — это Latency. Задержка времени отклика. Она складывается из большого количества промежуточных элементов и зависит от большого количества факторов. Сюда входит время отклика гипервизора, время прохождения сигнала по кабелям и промежуточным устройствам (коммутаторы, адаптеры и контроллеры), время нахождения в очередях на всех этих устройствах, если нагрузка на них превышает норму и ещё некоторые нюансы, такие как повреждения оборудования. Однако, оставив нюансы для расширенной диагностики, требуемой в редких случаях, можно выделить простой общий показатель — время задержки от ВМ до дисков.
Perfomance Tab
(закладка Perfomance в vSphere Client и счетчики производительности).
Наиболее часто используемые счётчики группы Disk:
Highest Latency — норма до 10-15 мс. Если регулярно выше, надо что-то менять, хотя разовые пики не страшны;
Average write requests per second;
Average read requests per second.
Наиболее часто используемые счётчики группы Virtual Disk:
Read/Write latency;
Average number of outstanding read/write requests — количество одновременных IO-запросов (если их число держится выше 30 в сумме на датастор или на сервер, это будет приводить к дополнительным задержкам);
ESXTop
Консольная утилита ESX/ESXi. Выдаёт целую кучу диагностической информации об отдельно взятом ESXi. Базовую информацию по использованию можно получить, нажав h после запуска утилиты.
В плане диагностики дисковой подсистемы будет полезен контекст виртуальных дисков (нажать v) и контекст HBA-адаптеров (нажать d). В последнем случае стоит обратить внимание на следующие показатели:
KAVG (Kernel Latency Avg) — время отклика гипервизора (норма — до 1 мс);
DAVG (Device Latency Avg) — время отклика от HBA до дисков (норма — 10-15мс);
GAVG (Guest Latency Avg) — время отклика для гостевой системы = сумма KAVG и DAVG
Кстати, в этой же области исследований стоит сразу проверить нет ли у ВМ снапшота. А то и нескольких. Они могут стать проблемой не только паденрия производительности, но и сбоев операций резервного копирования, клонирования и миграции.
2. Процессор
Здесь аналогичный по важности дисковым задержкам показатель — CPU Ready. Также стоит обращать внимание на Used, Wait и Co-Stop. Мониторить можно также через Perfomance Tab или ESXtop.
CPU Ready (%RDY) — % времени, когда ВМ готова производить какие-то вычисления, но физические процессоры в данный момент заняты другими процессами (системными или другими ВМ) и vCPU виртуальной машины находятся в режиме ожидания. Нормой считается значение до 10%. При росте этого показателя выше 40% развивается высокая вероятность сбоев и зависаний гостевой ОС. Причиной вынужденного простоя может стать:
Wait (%WAIT) — % времени, в течение которого ВМ ждёт окончания какой-то активности VMkernel. Чаще всего это дисковая IO-активность. Высокие показатели этого счётчика могут говорить о недостаточно быстром отклике от датастора. Также проблему могут вызывать некорректная работа USB или COM-портов или виртуальный CD/DVD-приводы, в который замонтирован отсутствующий ныне ISO.
Used (%USED) — % времени, в течение которого машина реально работала. Если он около нуля, значит машина просто стоит или её пересайзили процессорами. Если он около 100 (на каждый vCPU), значит или недосайзили, или в ней что-то зациклилось (если она ещё и не откликается при этом), или сейчас там лопатится какой-то квартальный отчёт. Этот показатель стоит изучать при размышлении на тему «дать ли ВМ ещё процессоров, чтоб быстрее работала?». Если у неё 4 ядра и ни одно не задействовано более чем на 50%, то 8 ядер её скорее всего не ускорят. Возможно даже замедлят (см. CPU Ready).
Инструменты диагностики те же.
Perfomance Tab
Удобно, что можно посмотреть данные не только по машине в целом, но и по каждому ядру. Кроме того, доступна статистика за период. Однако, информация предоставляется не в процентах, а в миллисекундах. Так как данные собираются не в real-time, а за определённый интервал, отображается, сколько именно mc процессор находился в том или ином состоянии. Перевести в проценты можно разделив значение на длину интервала и умножив на 100%.
Пример: на рисунке диаграмма с интервалом 20 секунд (real-time), то есть 20 000 мс. То есть среднее CPU Ready будет 50288 / 20000 * 100% = 251.44%. Так как у машины 4 ядра, а не одно, то результат делим на 4 и получаем почти 63%. Машина очень страдает. А всё потому, что лежит на третьем уровне вложенности Resource Pools с низкими shares на каждом.
Ещё раз, формула преобразования: / / * 100%. Получается 5% на 1000 мс для одного ядра.
ESXTop
Тут значение указано сразу в %. Только оно указано сразу в сумме для всех ядер, так что не стоит пугаться чисел больше 100. Делите на количество vCPU машины.
3. Оперативная память
Базовая диагностика здесь простая — да или нет. Если есть факт balooning’а значит хосту не хватает памяти и процессы гостевых ОС страдают, потому что активно используется файл подкачки. Если есть факт свопинга на уровне гипервизора, надо срочно принимать меры — машина попавшая в своп впадает в кому в 100% случаев (по крайней мере моей практики). Вышеуказанные факты позволяют определить такие счётчики как
Balloon (MCTLSZ) — количество памяти, вытянутое baloon-драйвером из гостевых ОС.
4. Сеть
Чтобы проблемы были на уровне сети, в случае жалоб на отдельную виртуальную машину, я в своей практике помню только один случай — когда в VDI использовалась какая-то дешёвая веб-камера, гнавшая несжатый поток видео и забивавшая все 100 Мб/с.
Стоит мониторить такие счётчики:
Transmit Dropped Packets (%DRPTX) — количество (или процент в случае esxtop) отброшенных отправленных пакетов;
Receive Dropped Packets (%DRPRX) — количество (процент) отброшенных принятых пакетов.
Ненулевое их значение, возникающее на регулярной основе говорит о некорректной работе сетевых устройств или некорректной их настройке.
Для базовой диагностики, покрывающей более половины (пожалуй, до 90%) обращений или собственных потребностей при диагностике и тестировании, этого достаточно.
Оптимизация CPU в виртуальном окружении vSphere
Одна из причин деградации скорости работы сервиса — это падение производительности процессора. При использовании локальных вычислительных систем без виртуализации их падение влияет только на сам сервер и запущенные на нем приложения. Установленный гипервизор, например от VMware, делит ресурсы физического процессора на все виртуальные машины, и аномальная нагрузка на одну из них может привести к критическому падению производительности на других.
Так же, как и в локальных средах, администратор виртуальной инфраструктуры должен уметь быстро определить причину падения производительности CPU в среде vSphere, используя наиболее информативные метрики.
На потребление ресурсов процессора влияет множество факторов, поэтому мониторинг и контроль ресурсоемкости должны быть хорошо проработаны. Типичными причинами перегрузки могут стать несколько виртуальных машин, на которых запущены очень «прожорливые» приложения, потребляющие слишком много ресурсов, или неэффективно настроенная конфигурация одной из виртуальных машин. В любом случае, если не отследить и вовремя не устранить проблему с производительностью, это может серьезным образом сказаться на критичных для бизнеса сервисах.
Топ-6 проблем с производительностью CPU
Проблема с этим параметром заключается в том, что виртуальная машина ожидает запуска в состоянии полной готовности, но не может быть запущена, так как гипервизор не находит для нее ресурсов физического процессора. Необходимо, чтобы Ready Time был меньше 10%, иначе повышается вероятность зависания гостевой операционной системы и сбоев в работе. Хотя некоторые приложения не так чувствительны к этому параметру и работают нормально, но лучше не допускать больше 10%.
Параметр Co-stoptime показывает, что виртуальных процессоров vCPU больше, чем необходимо. Как это ни парадоксально, порой большое число vCPU снижает, а не увеличивает производительность виртуальной машины.
Этот параметр ограничивает использование процессора виртуальной машиной, задает лимит. Соответственно, если машине надо больше мощности, она ее получит только в рамках предельного значения — для некоторых приложений это приведет к падению производительности.
Параметр, который отслеживает загрузку процессора хоста. Когда средняя загрузка будет более 75% или пиковая достигнет 90%, узел vSphere решит, что ресурсов CPU не хватает, как результат — остановка виртуальных машин или проблемы с запуском.
Показывает перегрузку виртуального процессора. Если запущенное на виртуальной машине приложение «ест» больше 90% ресурсов процессора, производительность будет деградировать. Решение: добавить еще vCPU или разобраться с приложением — может, оно работает нестабильно или просто зависло.
Вот этот параметр как раз поможет определить некорректную настройку приложения или нехватку других ресурсов сервера (память, диск), когда добавление vCPU не решает проблему.
Имитируем загрузку CPU и изучаем особенности
Чтобы проверить корректность работы виртуального сервера, необходимо в тестовой среде запустить скрипт загрузки CPU и проанализировать поведение машины. Для этого в VMware vSphere Power CLI запускаем скрипт Start CPU Test.
Скрипт запускает две виртуальные машины и показывает их удаленные рабочие столы. На машинах PERF-WORKER-01A и PERF-WORKER-01B имитируется сильная нагрузка на vCPU и отображается производительность в режиме реального времени. В нашем случае она составляет около 15 000.
Теперь необходимо в окне vSphere зайти на вкладку мониторинга производительности виртуальной машины PERF-WORKER-01A и для отображения расширенных параметров включить опцию Advanced –> Chart Options.
Теперь мы можем выбрать те счетчики, которые позволят нам отследить производительность процессора и выявить проблемы.
Мы рекомендуем обратить внимание на следующие счетчики:
Выявление проблем путем анализа показателей счетчиков
В процессе тестирования обратим внимание на то, сколько ресурсов необходимо потреблять виртуальной машине и сколько она использует фактически.
На скриншоте мы видим, что значение счетчика Demand (потребление) сильно больше, чем значение счетчика Use (использование). А показатель Ready Time равен 9977 ms. Чтобы перевести значение из миллисекунд в проценты для режима реального времени (real-time), необходимо показатель Ready Time разделить на 200 — в случае одного используемого vCPU. Или воспользоваться калькулятором. Для нашего теста получилось значение 49,89%, что в значительной мере превышает рекомендуемые 10%, а значит, наблюдается серьезная проблема с производительностью.
Также рекомендуем посмотреть статистику CPU на уровне хоста. Для этого выбрать нужный узел на вкладке Monitor-Performance и включить опцию Advanced — теперь станут видны счетчики производительности хоста.
Отследим статистику нагрузки CPU на уровне физического хоста.
На скриншоте видно, что один из процессоров хоста нагружен на 100%, тогда как остальные практически не задействованы. Это является аномальным и сигнализирует о наличии проблемы.
Чтобы решить эту проблему, проверим правильность конфигураций тестовых виртуальных машин.
Проверка параметров виртуальных машин
Для проверки параметров виртуальной машины VMPERF-WORKER-01A выбираем в меню Actions команду Edit Settings.
Теперь проверим параметр CPU affinity, который может быть причиной возникновения такой аномалии.
В нашем случае его значение равно единице — это означает, что данной виртуальной машине назначен только один физический процессор и другие она использовать не может, даже в случае 100% нагрузки. Для правильной балансировки нагрузки между физическими процессорами хоста необходимо очистить это значение (оставить параметр пустым) и нажать «ОК». Те же манипуляции необходимо проделать и с настройками виртуальной машины PERF-WORKER-01B.
Мы не рекомендуем для виртуальных машин в среде VMware вручную выставлять значение affinity. Платформа vSphere отлично справляется с автоматической балансировкой нагрузки виртуальных машин между физическими процессорами. Также заданный вручную параметр affinity не позволяет воспользоваться технологией vMotion, что уменьшает функциональность виртуальной инфраструктуры.
Заключение
У надежных облачных провайдеров настроены системы мониторинга и контроля использования ресурсов. Но аренда виртуальной инфраструктуры IaaS дает клиенту широкие возможности настройки машин, а значит — и создания потенциальных ошибок. Умение определить и устранить проблемы самостоятельно крайне важно.
Мы рассмотрели проблемы, связанные с производительностью CPU, и рассказали, как с помощью тестов и счетчиков обнаружить слабые места виртуальной инфраструктуры. На виртуальную инфраструктуру надейся, но и сам за всем следи!
Хотите сообщить важную новость? Пишите в Телеграм-бот.
А также подписывайтесь на наш Телеграм-канал.
😱 Разработчик прошел 3 собеседования в Facebook, Amazon и Google. И рассказал про самую кошмарную часть — behavioral interview. Читайте, как это было.