Несколько слов об автоматическом выделении ресурсов для ВМ

Нередко при общении с заказчиками на тему виртуальной инфраструктуры (частного облака) я получаю от них требование по автоматическому масштабированию ресурсов для виртуальных машин. Система должна выделять виртуальной машине больше процессоров, оперативной памяти, полосы пропускания сетевого адаптера или дисковых операций, когда та становится сильно загружена, желательно - автоматически, а еще лучше - проактивно, до возникновения проблемы с производительностью. Кто-то оперирует терминами, вроде "автоматизация" и "эластичность" из маркетинговых презентаций вендоров, другие "на пальцах" рассказывают о сервере с аналитическим ПО, на котором раз в месяц запускается ресурсоемкая задача, в остальное же время сервер фактически простаивает и зря греет воздух.

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

1. Ресурсы виртуальной инфраструктуры, развернутой внутри компании, в отличии от публичного облака провайдера, конечны. В кластере есть определенное количество серверов, с определенным количеством процессоров и оперативной памяти. Администраторам сразу доступны все вычислительные ресурсы, за исключением некоего резерва, который оставляют для обеспечения высокой доступности на случай выхода из строя одного или нескольких серверов. Отсюда возникает вопрос - если появится потребность выделить дополнительные вычислительные ресурсы одной или нескольким ВМ, то откуда их брать? Будут ли это ресурсы из запаса, оставленного под возможный рост виртуальной инфраструктуры, ресурсы, отобранные у других ВМ, или резерв, сделанный для отказоустойчивости? Не будет ли более правильным с точки зрения планирования учесть пиковые нагрузки в работе приложений, заложить и заранее выделить ресурсы нужной ВМ?

2. Следует разделять понятие выделенных ресурсов (allocated) и реально используемых/потребляемых (consumed) ресурсов. Если одной машине выделено 8 процессорных ядер, то это не означает, что она их утилизирует на 100% все время, пока запущена и работает. Гипервизоры давно научились эффективно распределять процессорные ресурсы между несколькими ВМ. На одном сервере, может быть создано множество ВМ, и все ВМ могут работать одновременно, не конкурируя друг с другом за ресурсы, пока нагрузка на них невелика. У всех современных гипервизоров есть механизмы возврата выделенной, но неиспользуемой памяти из ВМ, например Memory Ballooning и Host Swap у VMware vSphere, Dynamic Memory у Microsoft Hyper-V и т.д. В случае нехватки вычислительных ресурсов, т.н. перезакладки (overcommitment), гипервизор начнет использовать различные механизмы планирования, основанные на пропорциональном делении ресурсов, резервировании и лимитировании потребления. Изменяя эти метрики, можно обеспечить гарантированный уровень производительности для определенных ВМ в ущерб остальным, менее критичным.

3. Производительность ВМ ограничена производительностью физического сервера. Больше всего ресурсов ВМ сможет получить, если она будет единственной ВМ работающей на сервере, и количество процессоров и объем памяти будут равны или чуть меньше, чем у физического сервера (этакий Monster VM), т.е. при коэффициенте консолидации 1:1. Поэтому в ряде случаев проблему производительности можно решить, разнеся ресурсоемкие ВМ по разным физическим серверам (чем, например, занимается VMware DRS вместе с Anti-Affinity Rules).

4. Отсутствие у большинства гипервизоров механизмов выделения процессоров и памяти ВМ "на лету". Хотя возможность горячего добавления (Hot Plug/Hot Add) процессоров и памяти присутствует в гипервизоре VMware vSphere, данный механизм требует предварительной настройки и резервирует под свою работу часть вычислительных ресурсов сервера. Кроме того, на текущий момент нет возможности отбирать у ВМ назад не используемые процессоры и оперативную память, не выключая ее. По этой причине изменение аппаратной конфигурации виртуальных машин - не очень хороший вариант для сервисов, требующих непрерывной доступности.

5. Отсутствие готовых решений, позволяющих на основании данных системы мониторинга выполнять изменение конфигурации ВМ. Такую возможность, конечно, можно реализовать с помощью исполняемых сценарием и средств оркестрации/автоматизации, но это потребует серьезной работы "напильником", а также учета большого количества всевозможных условий. Например, должен учитываться не только сам факт роста загрузки ВМ, но и его длительность, время возникновения, периодичность, причина повышения загрузки (требуется ли выделать больше ресурсов под задачи антивирусного сканирования или резервного копирования, или только под задачи приложений) и т.д., чтобы не запускать процедуру изменения конфигурации ВМ по малейшему поводу.

Суммируя все вышесказанное, наибольшей производительности работы приложений можно добиться при правильном планировании ресурсов и выборе подходящей архитектуры для виртуальной инфраструктуры. Для этого следует, в первую очередь, придерживаться рекомендаций производителей программного и аппаратного обеспечения, проводить нагрузочное тестирование, а также осуществлять мониторинг с помощью систем, позволяющие проводить анализ производительности и выдавать рекомендации по оптимальному сайзингу ресурсов для ВМ, например, VMware vCenter Operations Manager или Veeam ONE.

Механизм ролей в VMware vCenter

Для организации работы большого количества пользователей с виртуальной инфраструктурой VMware vSphere предназначается механизм делегирования полномочий. Делегирование позволяет предоставлять минимальный необходимый доступ только к тем объектам, к которым требуется, без риска, что пользователь залезет куда не надо и что-нибудь сломает.

Иерархия vCenter включает в себя корневой объект Datacenters (при подключении с помощью vSphere Clients имя объекта будет соответствовать имени сервера vCenter или его IP адресу, в зависимости от того, что было указано в строчке подключения).

В корневом каталоге могут располагаться один или несколько дочерних объектов: виртуальных датацентров или каталогов, внутри которых, в свою очередь, могут располагаться другие дочерние объекты: дочерние каталоги, хосты, кластеры, пулы ресурсов, виртуальные машины, хранилища, виртуальные коммутаторы, группы портов и т.д.

Некоторые из объектов видны в иерархии vCenter только при включении определенного отображения, например, кластеры и пулы ресурсов видны в Hosts and Cluster, шаблоны виртуальных машин - в VMs and Templates, сети - в Networking и т.д. Исключением являются два типа объектов - виртуальные машины и vApp, которые отображаются и в Hosts and Cluster, и в VMs and Templates.

Модель прав в VMware vCenter основана на ролях, представляющих собой совокупность привилегий - различных операций, которые разрешается выполнять пользователю, например, создавать или удалять виртуальные машины, изменять настройки кластера, просматривать хранилища, подключать ВМ к сети и многое другое. Для удобства привилегии группируются в несколько категорий в зависимости от области применения.

Список ролей и привилегий может быть расширен при установке сторонних компонентов (например, vCenter Operations Manager, vCenter Site Recovery Manager), интегрирующихся с vCenter.

По умолчанию в vCenter присутствует несколько заранее созданных ролей. Существует два типа ролей:

Системные (System):

• Administrator - данная роль включает все доступные привилегии.
• Read Only - позволяет только видеть объекты в иерархии vCenter, но не изменять или взаимодействовать с ними. При создании новой роли возможность просмотра выставляется автоматически.
• No Access - данная роль запрещает любые действия с объектами, а также скрывает их от просмотра в иерархии vCenter. Она может быть полезна, если вам требуется скрыть какой-либо объект от определенного пользователя или группы.

Пользовательские (User Defined):

• Virtual Machine User.
• Virtual Machine Power User.
• Resource pool administrator.
• Datastore Consumer.
• Network administrator.
• другие роли.

Системные роли нельзя ни удалять, ни изменять. Они присутствуют всегда и имеют заранее заданный идентификатор (Role ID), зная который и имея доступ к СУБД vCenter "можно взломать все эти ваши ESXi" (чуть подробнее описано тут). Пользовательские роли можно изменять или удалять. Кроме того, все роли создаваемые администратором, или добавляемые сторонними приложениями, также являются User Defined и имеют свой уникальный идентификатор.

Администратор может создать роль с нуля или скопировать одну из имеющихся.

В качестве учетных записей, используемых для назначения ролей могут использоваться доменные учетные записи пользователей и групп, локальные учетные записи сервера vCenter, а также учетные записи хранящиеся в каталоге vCenter SSO (vsphere.local).

По умолчанию пользователи, которым не назначены никакие роли, не могут подключиться к серверу vCenter (что эквивалентно правам роли No Access).

При установке vCenter Server с нуля, права на подключения к vCenter есть только у административной учетной записи Administrator@vsphere.local, которой автоматически присваивается роль Administrator на виртуальную инфраструктуру.

Чтобы пользователь получил права, требуется назначить ему соответствующую роль на определенный объект.

Для доменных групп поддерживается вложенность (роли, назначенные на родительскую группу, наследуются дочерними).

Для пользователя или группы может быть назначена только одна роль на объект, однако, разрешения для пользователя могут складываться, если он является членом нескольких групп, для которых назначены разные роли на объект.

Исключением из этого является случай, когда роль явно назначается учетной записи пользователя, в этом случае она перекрывает все права, полученные от групп.

При назначении роли на объект можно включить наследование, для того, чтобы права данной роли распространялись на дочерние объекты.

Определить - от какого объекта наследуются права, можно по столбцу Defined in. При явном назначении роли на данный объект в столбце будет отображаться "This object", при наследовании - имя объекта, на который была назначена роль.

Если группе или пользователю назначены разные роли на родительский и дочерний объект, то роль, назначенная на дочерний объект, перекроет (переопределит) все унаследованные роли от родительского объекта.

Посмотреть, кому и на какой объект назначена роль, можно в окне Roles.