Гипервизор: что это такое, роль в виртуализации, типы и сравнение
Гипервизор — технология развертывания программного обеспечения на физическом оборудовании с использованием виртуализации. Инструмент ускоряет и упрощает разработку, тестирование и поддержку программного обеспечения, а также экономит ресурсы на развертывании дорогостоящих серверных систем. Selectel предлагает современные технологии виртуализации серверов (VPS/VDS), а также рабочих мест (VDI). Мы используем аппаратные ресурсы на базе процессоров Intel® Xeon®, а также SSD-накопителей, […]
Гипервизор — технология развертывания программного обеспечения на физическом оборудовании с использованием виртуализации.
Инструмент ускоряет и упрощает разработку, тестирование и поддержку программного обеспечения, а также экономит ресурсы на развертывании дорогостоящих серверных систем.
Selectel предлагает современные технологии виртуализации серверов (VPS/VDS), а также рабочих мест (VDI). Мы используем аппаратные ресурсы на базе процессоров Intel® Xeon®, а также SSD-накопителей, обеспечивая минимальное время отклика, высокую производительность и надежность. Для серверной виртуализации применяются решения VMware и KVM.
Основные задачи гипервизора:
- эмуляция аппаратных ресурсов;
- безопасное выполнение машинных инструкций;
- предотвращение выполнения команд гостевых операционных систем в режиме супервизора на хост-машине (исключение перехвата и анализа команд).
История гипервизоров
Технологии виртуализации начали активно использоваться разработчиками с конца 60-х годов прошлого века. Мейнфреймы IBM первыми стали поддерживать виртуализацию и предоставлять разработчикам гипервизоры в составе встроенного ПО. Первоначально команды разработки применяли их для эмуляции системных процессов компьютера, тестирования различных операционных систем и улучшений для них.
Повышение интереса IT-сообщества к гипервизорам приходится на середину нулевых. В этот период технологии виртуализации начинают активно использоваться в UNIX-подобных системах. В первую очередь, это было обусловлено ростом производительности серверного оборудования. Также значительную роль сыграла оптимизация архитектуры самих гипервизоров, сделавшая их более надежными и безопасными.
Помимо этого, виртуализация позволяла разворачивать и запускать требующие наличия ОС приложения в различных программных или функциональных средах. А в 2005 году технологии виртуализации начинают поддерживаться на аппаратном уровне в процессорах архитектуры x86, что позволяет использовать их как в серверных, так и в домашних системах.
Проблемы безопасности гипервизоров
В IT-сообществе ведутся дискуссии на тему безопасности виртуализации. Основная проблема — это возможность создания злоумышленниками вредоносного ПО, устанавливаемого на ОС под видом гипервизоров. Этот процесс получил название «гиперджекинг». Его сложно отследить, поскольку вредоносные алгоритмы работают под управлением ОС и перехватывают ее действия (например, авторизацию, запросы к сервисам и пр.).
В настоящее время разрабатываются различные подходы по обнаружению руткитов на базе гипервизоров:
- концепция вредоносного ПО: SubVirt, Blue Pill;
- антируткиты: Hooksafe (защита ОС без потерь производительности).
Контейнеры или гипервизоры
В последнее время все большую популярность приобретает технология контейнеров. Это обусловлено тем, что контейнеры, по сравнению с гипервизорами, могут развернуть большее число приложений на одном физическом хосте.
Гипервизор виртуализирует необходимые для работы ОС аппаратные ресурсы. При использовании гипервизоров возрастает потребность в наращивании аппаратных мощностей (дисковых устройств, CPU, памяти и пр.).
При этом производительность и ресурсоемкость использования той или иной технологии стоит рассматривать и в контексте безопасности. Существует мнение, что контейнеры более уязвимы, чем гипервизоры. Это обусловлено логикой рассматриваемых технологий. Гипервизор создает на физическом сервере несколько изолированных друг от друга виртуальных машин со своими ОС и приложениями. Контейнер же работает под основной ОС хоста.
Таким образом, при атаке на хост, использующий виртуализацию, есть риск потерять одну или несколько виртуальных машин и используемые на них приложения. Если на хосте развернут контейнер, то все его содержимое может быть повреждено или утеряно, поскольку вредоносное ПО получит доступ к основной ОС хоста.
Среди контейнеров наиболее популярен OpenVZ, лежащий в основе платформы Virtuozzo. Решение обладает хорошей производительностью, а также использует ресурсы физического сервера по максимуму за счет высокой плотности размещения виртуальных машин.
Также стоит обратить внимание и на Jailhouse. Решение компании Siemens работает на «железе», при этом запускается из-под работающей ОС Linux. При работе контейнер создает в ОС изолированные разделы для выполнения пользовательских приложений.
Типы гипервизоров
Существует два основных вида гипервизоров. Гипервизоры первого типа (сюда входят решения Hyper-V, KVM, ESXi) работают на аппаратном уровне без необходимости установки какой-либо ОС на хост. Поэтому их еще называют аппаратными. Гипервизорам второго типа (VMware Workstation, Oracle Virtual Box, OpenVZ) необходима ОС для доступа монитора виртуальных машин к аппаратным ресурсам хоста.
Отметим, что для корпоративного сегмента лучше подходят решения первого типа, так как работая на аппаратном уровне без программных посредников, они обеспечивают лучшую производительность. Также выделяются и гибридные гипервизоры. Рассмотрим каждый из типов подробнее.
Сравнение гипервизоров
При выборе технологии виртуализации следует помнить решаемые гипервизорами задачи. Также необходимо учитывать момент с лицензированием, аппаратными требованиями конкретного решения и его возможностями.
Hyper-V: для серверного оборудования под управлением Windows Server есть базовая роль Hyper-V. Кроме того, на рынке есть специальное решение Hyper-V Server. Операционная система Windows Server может поставляться в двух редакциях — Datacenter и Standard. Стандартная версия на одной лицензионной копии позволяет развернуть только две виртуальные машины. В версии Datacenter их число не ограничивается.
В соответствие, с актуальной лицензионной политикой Microsoft, действующей с 2016 года, стоимость лицензии на ПО зависит от количества физических ядер. Если речь идет о виртуализации Linux-машин на серверах под Windows Server, то их количество в стандартной редакции не ограничено. Если же требуется виртуализация Windows-машин, то необходимо решить вопрос с лицензированием ОС на них.
Специально для такой аудитории и был создан Hyper-V. Он позволяет организовать виртуализацию, не платя за лицензию на ОС. Решение доступно бесплатно, при этом и нет каких-либо ограничений на процедуры. Тем не менее, функционал продукта имеет и свои особенности:
- настройка и отладка через удаленную консоль: графический интерфейс не предусмотрен;
- лицензирование: необходимо лицензировать все виртуальные машины под управлением Windows;
- отсутствие поддержки: Microsoft не предоставляет техническую поддержку, но при этом регулярно обновляет продукт.
Эти особенности не критичны, за исключением момента с лицензированием. Кроме того, как и отмечалось ранее, решение может подойти IT-специалистам, планирующим разворачивать только Linux-виртуализацию.
VMware ESXi: в основе решения находится облегченное Linux-ядро VMkernel, содержащее необходимые для виртуализации технологии и приложения. Поставляется внутри продукта VMware vSphere. Лицензия покупается на каждый физический CPU сервера. Объем ОЗУ и виртуальных машин не учитываются при расчете стоимости лицензии.
VMware также предлагает и бесплатные решения для виртуализации, однако, они подходят только для любительского или полупрофессионального использования, поскольку имеют ряд существенных ограничений по функционалу. Так, например, бесплатная версия этого гипервизора 1 типа предоставляет API только для чтения данных. У виртуальной машины не может быть больше 8 vCPU, не предусмотрена работа с бэкапами с помощью продуктов Veeam и другие технологии, необходимые для корпоративного сегмента.
Основной недостаток Hyper-V по сравнению с VMware — это отсутствие USB Redirection. Она необходима для подключения USB оборудования к виртуальным машинам. Вместо нее в Hyper-V предлагается Discrete Device Assignment. Однако, Hyper-V может уменьшать дисковое пространство виртуальных машин, а не только расширять его, как VMware.
Hyper-V позволяет защищать виртуальные машины шифрованием. Однако, если требуется аппаратный проброс портов, то лучшим решением будет VMware, даже бесплатный.
При выборе гипервизора особое внимание следует уделить инструментам управления виртуальными машинами. У Hyper-V это Virtual Machine Manager (VMM), поддерживающий создание, клонирование, развертывание и другие операции с виртуальными машинами.
Инструмент управления от VMware называется vSphere. Он предполагает наличие ESXi хостов и vCenter Server для централизованного управления.
KVM — open-source гипервизор: предназначен для серверов на базе Linux/x86, поддерживает аппаратные расширения (Intel-VT и AMD-V).
Первоначально работал только с архитектурой x86, но актуальные версии KVM поддерживают различные CPU и гостевые ОС, в т.ч. Windows, Linux, BSD и пр.
Богатый функционал KVM сделал его популярным и широко распространенным. В настоящее время гипервизор активно используется во многих сетевых проектах (Wiki-ресурсы, финансовые сервисы, транспортные системы, государственный сектор и пр.).
Решение считается быстрым и за счет интеграции в ядро Linux.
- Управление виртуальными машинами: встроенные сервисы не соответствуют по функционалу решениям для других гипервизоров. Чтобы расширить функционал, приходится использовать сторонние инструменты, например, панель SolusVM.
- Стабильность и отказоустойчивость: этот недостаток проявляется при интенсивном вводе-выводе. Тем не менее KVM развивается и дорабатывается множеством независимых разработчиков, что положительным образом сказывается на работе гипервизора.
Xen (XenServer, Citrix Hypervisor): первый публичный релиз тонкого гипервизора был выпущен в 2003 году. В 2007 году проект был поглощен Citrix. Продукт является кроссплатформенным гипервизором с поддержкой аппаратной виртуализации и паравиртуализации (из-за этого его часто относят к гибридным гипервизорам). Объем кода минимален, т.к. большая часть модулей вынесена за пределы гипервизора. Исходный код открыт, что дает специалистам неограниченные возможности для модификаций продукта.
Oracle VM VirtualBox: кроссплатформенный модульный гипервизор для операционных систем Linux, macOS, FreeBSD и др. Создан в корпорации Sun Microsystems в 2007 году. После поглощения разработчика Oracle проект продолжил развитие под другим брендом. Исходный код базовой версии открыт и распространяется по лицензии GNU GPL, что послужило причиной высокой популярности гипервизора. Отличительная особенность гипервизора — возможность работы с 64-битными гостевыми ОС, даже если ОС хоста 32-битная.
VMware Workstation: первая версия гипервизора вышла в 1999 году. Решение является проприетарным для x86-64 ОС хоста Windows, Linux, Ubuntu, CentOS. Поддерживает более 200 гостевых операционных систем. Для ознакомления и тестирования предоставляется бесплатная версия с ограничениями по функциональности.
Гибридные гипервизоры: для улучшения стабильности, безопасности и производительности описанные выше подходы к виртуализации (непосредственная работа «на железе» и использование основной ОС хоста) комбинируются. В результате на рынке появляются гибридные решения. В последние годы в IT-сообществе к гибридным гипервизорам причисляют Xen и Hyper-V, поскольку их актуальные версии сочетают в себе оба подхода. Таким образом, просматривается тенденция к размытию границ между видами гипервизоров.
Управление числом vCPU и ядер в виртуальной машине
10.02.2020
itpro
Hyper-V, KVM, VMware, Windows 10, Виртуализация
комментария 2
При создании виртуальных машин на различных гипервизорах (VMWare, KVM, Hyper-V и т.д.) вы можете обратить внимание, что иногда виртуальная машина может не видеть все выделенные ей виртуальные ядра (vCPU). В нашем случае виртуальной машине на KVM были выделены 8 vCPU, на нее установлена Windows 10. Однако Windows определяла эти ядра как отдельные процессоры, из которых можно использовать только 2 vCPU.
Виртуальная машина Windows 10 не видит все ядра
Если открыть диспетчер устройств Windows, можно убедится, что все выделенные ядра видны в качестве 8 отдельных виртуальных процессоров типа QEMU Virtual CPU version 2,5.
При этом в свойствах Windows 10 (Computer -> Properties) и в Task Manage видно, что на компьютере доступны только 2 процессора QEMU Virtual CPU.
То есть сколько бы вы не добавили виртуальных ядер, Windows 10 все равно сможет использовать только два. При этом соседний виртуальный сервер с Window Server 2016 на этом же гипервизоре видит все 16 выделенных ему vCPU.
Количество поддерживаемых процессоров в Windows 10
Проблема заключается в том, что в десктопных редакциях Windows (Windows 10/8.1/7) есть ограничение на максимальное количество физических процессоров (сокетов), которое компьютер может использовать:
- Windows 10 Home – 1 CPU
- Windows 10 Professional – 2 CPU
- Windows 10 Workstation – до 4 CPU
- Windows Server 2016 – до 64 CPU
Однако это ограничение не распространяется на ядра. Т.е. для повышения производительности вы можете использовать процессор с большим количеством ядер. Большинство гипервизоров умеют предоставлять vCPU в виде процессоров, процессорных ядер или даже потоков. Т.е. вместо 8 виртуальных CPU вы можете предоставить vCPU в виде 2 сокетов по 4 ядра в каждом. Рассмотрим, как в различных системах виртуализации выделить виртуальные процессоры в виде ядер и как это связать с архитектурой NUMA, использующейся в современных процессорах.
Управление виртуальными ядрами и vCPU в KVM
В моей виртуальной машине KVM c Windows 10, все назначенные виртуальные ядра считаются отдельными процессорами.
Чтобы использовать все ресурсы CPU, выделенные виртуальной машине нужно, чтобы виртуальная машина видела не 8 процессоров, а один 8-ядерный процессор, 2 процессора по 4 ядра или 1 процессор с 4 ядрами по 2 потока. Попробуем изменить способ назначения виртуальных ядер для ВМ на KVM.
Выключите виртуальную машину:
# virsh shutdown server.vpn.ru – где server.vpn.ru это имя виртуальной машины.
Особенности управления ВМ в KVM из консоли сервера с помощью virsh.
Выведите текущую XML конфигурацию виртуальной машины KVM:
# virsh dumpxml server.vpn.ru
Нам интересен блок с описанием процессоров:
8 1000 /machine hvm
Как видим, у нас указано просто 8 vCPU. Изменим конфигурацию:
# virsh edit server.vpn.ru
И после добавим:
- host-passthrough — режим эмуляции при котором на виртуальной машине будет показан физический процессор узла кластера (ноды).
- sockets=’1′ — указываем что процессор 1
- cores=’4′ — указываем, что процессор имеет 4 ядра
- threads=’2′ — указываем, что ядра у нас по 2 потока
Сохраните конфигурационный файл и запустите ВМ. Авторизуйтесь в гостевой ВМ с Windows 10 и в Task Manager или Resource Monitor проверьте, что ОС видит все выделенные виртуальные ядра.
Также в свойства системы теперь стал отображаться физический процессор хоста Intel(R) Xeon(R) Silver 4114 CPU, а не виртуальный.
Так нам удалось решить проблему с нагрузкой на ВМ, так как двух ядер не хватало для полноценной работы приложений.
Настройка виртуальных процессоров и количества ядер в VMWare
Вы можете изменить способ презентации vCPU для виртуальной машины VMWare из интерфейса vSphere Client.
- Выключите ВМ и откройте ее настройки;
- Разверните секцию CPU;
- Изменим конфигурацию ВМ так, чтобы гостевая ОС видела 2 процессора по 4 ядра. Измените значение Cores per Socket на 4. Это означает, что гостевая ОС будет видеть два четырех –ядерных процессора (2 сокета по 4 ядра);
- Сохраните изменения и запустите ВМ.
Архитектура NUMA и виртуальные vCPU
Есть еще несколько аспектов назначения vCPU и ядер виртуальным машинам, которые нужно понимать.
При назначении ядер на сокете учитывайте наличие NUMA архитектуры (используется в большинстве современных CPU). Не рекомендуется назначать вашей ВМ количество ядер на сокет (и общее количество vCPU) больше, чем доступно ядер на вашем физическом сокете/процессоре (ноде NUMA). При размещении на одной физической ноде NUMA, виртуальная машина сможет использовать быструю локальную RAM, доступную на конкретной ноде NUMA. Иначе для выполнения операции процессам придется ждать ответа от другой ноды NUMA (что несколько более долго).
Если вы назначаете для ВМ два отдельных виртуальных сокета, то гипервизор может их запускать на разных нодах NUMA. Что не лучшим образом скажется на производительности ВМ.
Если количество требуемых vCPU превышает количество ядер на 1 физическом сокете (ноде NUMA), нужно создать несколько виртуальных сокетов (процессоров) с необходимым количество ядер. Также не желательно использовать нечетное количество процессоров (лучше добавить 1 vCPU)
Это позволит сохранить производительность виртуальной машины.
Например, для 2 процессорного хоста с 10 ядрами (суммарно доступно 40 vCPU с учетом Hyper—Threading), при настройке vCPU для ВМ оптимально использовать такие конфигурации:
| Требуемое количество vCPU | Количество виртуальных сокетов в настройках ВМ | Количество ядер на виртуальном процессоре в настройках ВМ |
| 1 | 1 | 1 |
| …… | ||
| 10 | 1 | 10 |
| 11 | Не оптимально | |
| 12 | 2 | 6 |
| …… | ||
| 20 | 2 | 10 |
В бесплатной версии ESXi вы не можете создать ВМ более чем с 8 vCPU.
Например, ВМ с Microsoft SQL Server 2016 Enterprise Edition 16 vCPU в конфигурации 8 сокетов по 2 ядра будет работать хуже, чем в конфигурации 2 сокета по 8 ядер.
Также не забывайте, что некоторые приложения лицензируются по физическим сокетам (так было в старых версиях SQL Server). Иногда вам просто выгоднее лицензировать один многоядерный процессор, чем несколько процессоров с меньшим количеством ядер.
Современные версии Windows Server лицензируются в среде виртуализации по-особому. Также есть свои особенности лицензирования процессоров в VMWare vSphere.
Предыдущая статья Следующая статья 
Управление переподпиской в частном облаке
Частное облако — модель облачных вычислений, которая представляет собой выделенную инфраструктуру. В отличие от публичного, частное облако позволяет пользователям иметь полный контроль над инфраструктурой и безопасностью. Частное облако имеет больше возможностей для кастомизации, в том числе разрешает настройку переподписки.
Что такое pCPU, vCPU и переподписка
• pCPU (physical CPU) — это физический процессор, который обычно применяется в вычислительных системах и серверах. pCPU может содержать одно или несколько ядер, которые могут выполнять различные задачи.
• vCPU (virtual CPU) — это абстракция физического процессора, созданная программным обеспечением виртуализации для обеспечения работы виртуальной машины.
vCPU напрямую связан с pCPU, так как виртуальный процессор — это лишь представление части мощностей физического процессора, предоставляемого в пользование виртуальной машине. vCPU — это одно или несколько цельных ядер pCPU, что означает, что на сервер с 8-ядерным процессором можно одновременно запустить не более 8 виртуальных машин.
Реклама на веке
Но благодаря переподписке каждое ядро может быть разделено, что позволяет выделять виртуальной машине не целое ядро pCPU, а лишь его часть, точнее часть времени работы этого ядра.
• Переподписка — процесс логического разделения ядер физического процессора на части, позволяющий выделять виртуальной машине меньшее количество pCPU.
Само слово «переподписка» подразумевает передачу каких-либо ресурсов от одного пользователя к другому, то есть переподписать ресурсы.
Технический аспект переподписки
Возможность виртуализации заключается в том, что на одном физическом сервере можно создать несколько виртуальных серверов, ограниченных в использовании физических ресурсов. Гостевая операционная система, запущенная внутри виртуальной среды, будет думать, что имеет полный доступ ко всем выделенным ресурсам. Однако гипервизор будет скрыто динамически изменять объем ресурсов, выделенных для гостевой операционной системы, в зависимости от их текущей загрузки.
Для обеспечения эффективной работы в режиме переподписки необходимо оценить использование физической памяти виртуальной машиной и назначить ей соответствующий объем памяти. Определение размера рабочего набора, то есть количество страниц физической памяти, используемых гостевой ОС, требует особых алгоритмов.
При запуске гостевой ОС выделяется память виртуальной машине. В режиме переподписки часть физической памяти у виртуальной машины может быть вытеснена. Для этого используется фиктивный захват физической памяти гостевой ОС, реализуемый с помощью специального агента. Агент передает информацию о захваченных страницах гипервизору, который может затем перераспределить их в пользу другой виртуальной машины. Управление фиктивным захватом физической памяти критически важно для эффективной работы гостевой ОС и всей системы в целом.
Недостаточное количество фиктивно занятой памяти приводит к вытеснению других виртуальных машин, что снижает их производительность. Другими словами, если фиктивно захваченной памяти недостаточно, система начинает вытеснять другие виртуальные машины для освобождения дополнительной физической памяти.
Чрезмерный фиктивный захват, в свою очередь, приводит к росту страничных промахов гостевой ОС. Страничный промах — это ситуация, когда процессор пытается получить доступ к странице памяти, которая не находится в физической памяти на данный момент. Чем больше страниц физической памяти изымается, тем больше увеличивается нагрузка на остальные страницы системы.
Для решения этих проблем необходима корректная оценка размера рабочего набора. При наличии такой оценки можно фиктивно занимать объем памяти, равный назначенной памяти за вычетом размера рабочего набора, что позволяет избежать гостевой подкачки.
Фиктивный захват изменяет работу гостевой ОС, что отражается в гостевых счетчиках — статистических параметрах, автоматически вычисляемых для мониторинга. Оценка размера рабочего набора может основываться как на предыдущих наблюдениях, так и на гостевых счетчиках.
Однако оценка размера рабочего набора — сложный и подверженный высокой скорости изменений процесс, что снижает ее точность. Поэтому система виртуализации должна готова к быстрой корректировке объема фиктивно занятой памяти в зависимости от наблюдаемого поведения гостевой ОС.
Путем регулирования объема фиктивно занятой памяти на основании оценки размера рабочего набора и корректировки этого объема в зависимости от реакции гостевой ОС, можно сэкономить физическую память и достичь большей плотности размещения виртуальных машин без ущерба для уровня обслуживания.
Управление переподпиской
При использовании переподписки vCPU в облачном сервисе следует обращать внимание на следующие ключевые аспекты управления ресурсами:
• мониторинг использования ресурсов. Следует регулярно отслеживать, сколько ресурсов было использовано, и сравнивать это с лимитом ресурсов, доступных по подписке. Это поможет определить, сколько ресурсов нужно размещать на виртуальные машины в будущем;
• анализ лимитов. Следует проанализировать, сколько ресурсов требуется в среднем для работы текущих виртуальных машин, а также сколько ресурсов используется при повышенной нагрузке. Это может помочь сделать выводы о том, нужно ли увеличивать или уменьшать степень переподписки;
• автоматизация мониторинга. Автоматическое оповещение о том, что были превышены лимиты, позволяет оперативно реагировать на ситуацию;
• оптимизация использования ресурсов. Оптимизировать работу виртуальных машин и сократить количество потребляемых ресурсов можно с помощью использования технологий и инструментов виртуализации, устранения узких мест и оптимизации настроек работы приложений.
Относительно того, сколько ресурсов выделять на виртуальную машину и какую степень переподписки использовать, здесь нет однозначного ответа. Мы рекомендуем выделять ресурсы в зависимости от комбинации приложений и размера баз данных, используемых на виртуальной машине.
Mission-critical приложения
Для Mission-critical приложений, где высокая доступность, надежность и быстродействие являются ключевыми факторами, предпочтительным является соотношение 1:1 между виртуальными и физическими ядрами.
• минимизация задержек и взаимного влияния. В ситуации, когда активность на одной виртуальной машине не мешает работе другой виртуальной машины, скорость выполнения задач будет выше. Благодаря соотношению 1:1 между vCPU и pCPU задержки и конкуренция за ресурсы снижаются;
• максимизация производительности. Такие приложения могут использовать всю выделенную им мощность, что оказывает положительное влияние на скорость и стабильность их работы;
• высокая доступность. Mission-critical приложения требуют высокой постоянной доступности. Выделение равного количества физических ядер для виртуальных ядер высвобождает ресурсы и исключает возможность их переподписки. Это уменьшает риск сбоев и обеспечивает стабильность работы;
• улучшение качества услуг (QoS). Чтобы обеспечить высокое качество услуг в Mission-critical приложениях, таких как финансовые транзакции, контроль над инфраструктурой и обработка больших объемов данных, перебои в работе и задержки в обработке запросов могут сказываться на бизнесе. Соотношение 1:1 между vCPU и pCPU помогает снизить задержки и улучшить качество услуг для конечных пользователей.
• высокая стоимость. Использование соотношения 1:1 между vCPU и pCPU может быть более дорогостоящим, поскольку все доступные ресурсы используются без переподписки. Это может привести к увеличению операционных расходов;
• снижение эффективности использования ресурсов. В некоторых случаях приложение может быть менее требовательным к ресурсам, и выделение одного физического ядра на одно виртуальное ядро может привести к недостаточному использованию имеющихся ресурсов, что снижает их экономическую эффективность.
Чаще всего отказ от переподписки для Mission-critical приложений полностью оправдывает себя. Недостатки, связанные с удорожанием поддержки таких приложений, полностью перекрываются тем фактом, что ресурсы, выделенные на ВМ, будут использованы только на соответствующие приложения в любой момент времени.
Business-critical приложения — 3 vCPU / 1 pCPU.
В зависимости от приложения и его требований к производительности и доступности, соотношение 3 vCPU на 1 pCPU может быть подходящим решением.
• повышение уровня утилизации ресурсов. Использование трех виртуальных ядер на одно физическое ядро позволяет эффективнее использовать ресурсы, что хорошо влияет на общую стоимость владения и экономическую эффективность;
• уменьшение затрат. Такое соотношение дешевле по сравнению с использованием 1:1 между vCPU и pCPU. В результате снижаются расходы на операционные затраты и стоимость оборудования;
• увеличение плотности виртуальных машин. С повышением соотношения vCPU к pCPU может быть размещено больше виртуальных машин на имеющихся физических серверах, что снижает необходимость увеличения площади для размещения и расходы на энергоснабжение, что, в свою очередь, позволяет экономить.
• возможное снижение производительности. При наличии большего количества vCPU на одном pCPU ресурсы могут быть ограничены и привести к конкуренции за вычислительную мощность. Это может снизить производительность отдельных приложений и вызвать небольшие задержки;
• потенциальное влияние на надежность и доступность. При использовании более высокого соотношения vCPU к pCPU риски, связанные с высокой нагрузкой или сбоями, могут увеличиться, что может повлиять на надежность и доступность бизнес-критических приложений;
• ухудшение качества услуг (QoS). Большее количество задач выполняется на одном физическом ядре, что может снизить качество обслуживания для конечных пользователей, особенно для бизнес-критических операций.
Большинство архитекторов сходится на том, что соотношение 3:1 допустимо для Business-critical приложений без существенного влияния на производительность. Если данное соотношение является слишком рискованным для бизнеса, а 1:1 достаточно дорогим, можно использовать 2 vCPU на 1 pCPU. Это станет оптимальным решением между надежностью и ценой при повышенных потребностях к производительности.
Инфраструктурные и обеспечивающие приложения
Такие приложения обычно не являются критическими для бизнеса. Соотношение 5 vCPU на 1 pCPU может быть обоснованным. Но, конечно, все зависит от требований приложений.
• сокращение расходов. При использовании соотношения 5:1 уменьшается количество физических серверов, нужных для запуска тех же приложений, что в свою очередь экономит на затратах на оборудование и технические услуги;
• рациональное использование ресурсов. Соотношение 5:1 позволяет более эффективно использовать pCPU и повышает уровень утилизации мощности оборудования.
• уменьшенный уровень доступности. При использовании соотношения 5:1 понижается уровень доступности. Например, если у одного из серверов сбоит один pCPU, будет недоступно сразу несколько виртуальных машин, что вызовет проблему для приложений и пользователей;
• снижение производительности. При повышенной загрузке машины уменьшается доступная вычислительная мощность, из-за чего на каждую виртуальную машину приходится меньше мощности;
• несоответствие требованиям приложений. Некоторые приложения могут требовать большего количества ресурсов, чем может предоставить такая степень переподписки, что может сказаться на производительности.
Соотношение 5 vCPU на 1 pCPU может эффективно использовать ресурсы сервера и сократить расходы, но следует учитывать низкий уровень доступности и возможные риски снижения производительности. Каждая организация должна сама решить, подходит ли такое соотношение для ее требований и бизнес-целей.
Виртуальные десктопы
Виртуальные десктопы представляют собой виртуальные машины, созданные для работы пользователей, которые могут удаленно управлять виртуальным рабочим столом и использовать приложения, установленные на этом виртуальном рабочем столе. В такой конфигурации архитекторы советуют использовать степень переподписки, равную 10:1.
• высокая степень гибкости и адаптивности. Виртуальная машина может быстро адаптироваться к изменениям нагрузки и изменениям потребностей пользователей;
• возможность запуска большего числа ВМ. Это позволяет сэкономить затраты на оборудование и улучшить управление ресурсами;
• высокая степень изоляции между виртуальными машинами. Если один виртуальный десктоп или приложение зависнет или упадет, это не повлияет на работу других виртуальных машин;
• возможность управления ресурсами между виртуальными машинами. Организации могут управлять нагрузкой на сервер, перераспределяя ресурсы между виртуальными машинами при необходимости;
• низкая стоимость. За счет того, что на одном pCPU могут располагаться 10 vCPU, увеличивается количество машин, способных работать на одном физическом сервере. Это является очень выгодным решением.
• большая нагруженность. Совместное использование процессора между 10 виртуальными машинами может привести к увеличению времени отклика, когда много машин находятся в активном состоянии. Это может повлиять на производительность приложений, работающих на виртуальной машине.
Соотношение 10 vCPU / 1 pCPU является выгодным вариантом для обеспечения эффективности виртуальных десктопов и оптимального распределения нагрузки на оборудование. Однако необходимо учитывать потребности собственной организации и масштабы ее деятельности для выбора оптимального варианта и эффективной работы с виртуальными машинами.
От своих задач и степени важности работающих на ВМ приложений зависит то, какую степень переподписки выбрать. Каждое соотношение имеет свои плюсы и минусы. Чаще всего провайдеры устанавливают степень переподписки равную 5:1, а лоукостеры могут поднимать ее вплоть до 10:1. Часто переподписку не позволяют регулировать на стороне клиента, провайдер устанавливает фиксированные значения. Но ITGLOBAL.COM позволяет самостоятельно настраивать степень переподписки в частном облаке.
Отличия ядер Standard и Nova
для сервисов с невысокой нагрузкой и небольших сайтов.
Гарантированная производительность ядер — не менее 30%.
1 vCPU Nova
для высоконагруженных сервисов и приложений проектов.
Гарантированная производительность ядер — 100%
Ядра Standard
Гарантированная производительность виртуальных ядер Standard — от 30%. Это связано с тем, что 1 поток ядра процессора обслуживает несколько виртуальных серверов с ядрами Standard. Если на одном из них повысится нагрузка, производительность остальных снизится. Это не частый случай — обычно виртуальные серверы не загружены до пиковых значений. Большую часть времени сервер с ядрами Standard будет работать с полной производительностью. Однако рекомендуем использовать его для некритичных сервисом: небольших сайтов, почтовых серверов и другого нетребовательного ПО.
Ядра Nova
vCPU Nova — это виртуальные ядра со 100% производительностью — 1 vCPU равен 1 потоку физического ядра. Выбирайте ядра Nova при создании сервера для критических и высоконагруженных проектов: базы данных, 1с, тяжелое вычислительное ПО.
Виртуальные серверы с ядрами Nova полностью изолированы друг от друга. Повышение нагрузки в дата-центре никак не скажется на производительности вашего проекта.
Это как жизнь в коттеджном поселке — дом и участок полностью принадлежат владельцу, не нужно ни с кем делить помещения. А безопасность и уход за общей территорией берет на себя управляющая компания.