VMware vSphere. Ограничение пользователя пулом ресурсов
VMware vSphere позволяет ограничить любого пользователя или группу определенным набором действий. Но, эта система разделения прав доступа предполагает ролевое разделение полномочий. То есть позволяет распределить обязанности между администраторами, но она не как не лимитирует ресурсы затрачиваемые ими. В такой схеме, любой оператор ВМ может на создавать виртуалок, столько сколько ему вздумается, что в моем конкретном случае не приемлемо. Я долго бился над решением этой задачи.
Необходимо было сделать так, что бы группа пользователей(назовем ее Support_group) авторизуясь в vCentre видела только свой пул ресурсов и имела в нем административные привилегии. При этом не видела другие пулы и не могла создавать или изменять ВМ и другие объекты вне своего пула. С ролевой моделью доступа vSphere это оказалось не просто.
Пошаговая инструкция как этого добиться
1. На уровне датацентра определяем для нашей группы все необходимые привилегии. Для этого лучше создать новую роль. При назначении роли, обязательно необходимо снять галочку Propogate! Это отменяет наследования полномочий на нижележащие объекты.
В моем случае эта роль имеет примерно следующие привилегии: 2. На уровне кластера не какие привилегии не назначаются.
3. Создаем новый пул и определяем лимиты. В моем случае он назван Support_pool. На нем, назначаем нашей группе полные права. Роль Администратор.
4. На конкретном Датасторе назначаем нашей группе роль Datastore consumer (sample). Галочку Propogate так же снимаем. 5. На порт-группах виртуального коммутатора в которые будет разрешено включать ВМ так же назначаем нашей группе роль Network administrator (sample). Галочку Propogate так же снимаем.
6. На всех остальных пулах, видеть которые не нужно, назначаем нашей группе роль No access.
Вот что доступно администратору Вот что доступно пользователю нашей ограниченной группы А это уже на уровень выше
Более 5560 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes
VM Guru / Articles / Как работают Limit, Reservation и Shares для пулов ресурсов в VMware vSphere / ESX.
Как работают Limit, Reservation и Shares для пулов ресурсов в VMware vSphere / ESX.
Как работают Limit, Reservation и Shares для пулов ресурсов в VMware vSphere / ESX.
Автор: Александр Самойленко Дата: 28/05/2010
Большинству пользователей виртуальной инфраструктуры VMware vSphere известны такие параметры как Limit, Reservation и Shares для пулов ресурсов (Resource Pool) в пределах кластеров VMware DRS и отельных хостов ESX. Именно этими тремя параметрами определяется потребление виртуальными машинами оперативной памяти и процессорных ресурсов хоста VMware ESX.
Limit
Этот параметр определяет ограничение потребления физических ресурсов виртуальной машиной (в пределах хоста ESX) или пулом (в пределах кластера) при любых обстоятельствах. Некоторые думают, что Limit (по аналогии с Shares) начинает работать тогда, когда виртуальные машины на хосте ESX начинают бороться за ресурсы. Но это не так. Если вы поставили виртуальной машине Limit в 500 МГц, то именно с такой максимальной производительностью и будет работать ее vCPU, даже если на хосте с 4-мя физическими процессорами по 3 МГц больше никаких машин нет. При этом, если для двухпроцессорной виртуальной машины установлен Limit в 1000 МГц, то оба ее процессора в совокупности не получат более 1000 миллионов циклов CPU в секунду, оставшиеся свободные циклы в эту секунду планировщик ESX будет просто ждать.
Если говорить о памяти, то если ее потребление виртуальной машиной (или пулом ресурсов) доходит до параметра Limit, оставшаяся часть просто уходит в своп.
Теперь обратите внимание на картинку, где задаются параметры потребления ресурсов для отдельной виртуальной машины:
В качестве ограничения можно задать ресурсов больше, чем есть на отдельном хосте VMware ESX (потому как рассматриваются ресурсы всего пула), но это не значит, что виртуальная машина может исполняться на нескольких хостах. Одна ВМ всегда исполняется только на одном хосте ESX.
Reservation
Параметр Reservation для виртуальной машины или пула ресурсов в VMware vSphere определяет, сколько физической памяти или ресурсов процессора будет гарантировано виртуальной машине при работе (но не при старте!), если ей это потребуется. Параметр используется планировщиками VMware DRS (в пределах кластера) и VKernel (в пределах хоста ESX), а также компонентом Admission Control кластера VMware HA.
Величина разницы между размером памяти в конфигурации виртуальной машины и параметром Reservation определяется, исходя из параметров Shares, установленных для пула ресурсов или отдельной виртуальной машины на хосте ESX (про Shares см. ниже).
Reservation также влияет на размер файла подкачки (vswp, находится в директории с виртуальной машиной). Размер этого файла определяется по формуле:
В Resource Management Guide можно найти также такую фразу:
If a virtual machine has a memory reservation but has not yet accessed its full reservation, the unused memory can be reallocated to other virtual machines.
То есть, если виртуальная машина еще не достигла значения параметра Reservation по памяти, то неиспользуемая память может быть отдана другим виртуальным машинам. Но вот если ВМ уже достигла своего уровня Reservation, то планировщик уже не будет отнимать у нее память, даже если она использовать ее не будет и требования к памяти упадут ниже уровня Reservation.
Для пулов ресурсов есть также параметр Expandable Reservation, который позволяет дочернему пулу забирать ресурсы из родительского при условии наличия в последнем ресурсов.
Это дает почти неограниченную гибкость в управлении физическими ресурсами хост-сервера VMware ESX.
Admission Control
Данный компонент имеет отношение только к памяти и контролирует запуск виртуальных машин с параметром Reservation в пределах виртуальной инфраструктуры VMware vSphere. Есть три уровня работы этого компонента:
Shares
Shares вступает в действие при нехватке ресурсов CPU или памяти в той части ресурсов, которая находится между Reservation (обеспечено физическими ресурсами) и сконфигурированной памятью или CPU виртуальной машины. В пределах хоста есть также Shares по дисковым ресурсам, об этом есть отдельная статья на VM Guru.
Ведь управление ресурсами в пределах кластера VMware DRS для пулов происходит на их уровне, а не на уровне отдельных виртуальных машин. Например, есть такая конфигурация:
Представим, что один гипервизор обслуживает несколько виртуальных машин, у каждой машины свои задачи, у каждой машины свое потребление ресурсов, например несколько машин для разработчиков, несколько web сервров и т.п., отдать им всем все ресурсы сервера на мой взгляд не совсем правильно, в данном случае эффективнее было бы разделить машины по назначению, для каждого «назначения» создать свой пул ресурсов, «раскидать» машины по пулам. Так же можно ограничения на выделение ресурсов выставить в свойствах самих машин. Я например разбиваю машины по уровням, так называемым level’ам, которые определил для себя сам, например L1, L2, L3, где выставляю соответствующие приоритеты / ограничения, или по назначению и их приоритизации.
Ограничение ресурсов через свойства машины
Для этого достаточно открыть сойства машины, перейти на вкладку Resources и выставить нужные параметры
Ограничение ресурсов через пулы
Для этого необходимо создать новый ресурсный пул, в котором можно выставить настройки резервации ресурсов, где можно выставить параметры в ручную
Или просто выставить приоритет, в результате чего гипервизор будет «знать» какой машине в первую очередь выделять ресурсы
VMware vSphere 7 resource pool configuration and examples
Many new vSphere admins do not use resource pools because they seem complicated at first; however, they’re part of vSphere. Moreover, this topic is required to pass the VCP-DCV VMware certification exam. I’m not surprised that the VCP exam has several sections on resource pools and resource management.
VMware vSphere 7 uses resource pools to separate and compartmentalize all resources in a cluster. A resource pool is a logical abstraction for the flexible management of resources, allowing you to create a hierarchy within your environment. Each part of this hierarchy can have different amounts of CPU or memory resources assigned from the total available within your cluster.
A resource pool can have child resource pools, such that each child receives part of the parent’s resources. Child resource pools are smaller units compared to parents. A resource pool can contain other resource pools, as well as individual virtual machines (VMs).
The main advantage of managing resources via resource pools is that you do not need to set resources on each virtual machine individually. Instead, you can control the aggregate allocation of resources to the set of virtual machines by changing the settings on their enclosing resource pool.
vSphere 7 offers a new feature with resource pools. It is a new checkbox called Scalable shares that we detailed in one of our previous articles—What are VMware vSphere 7 scalable shares?
If you have more VMs that are provisioned in a resource pool, VMware vSphere 7 with scalable shares activated recalculates the entitlement for all the workloads running inside the resource pool. Scalable shares are dynamic.
Today’s article will be more general and will teach you the basics of resource pools, their usage, examples, and configuration.
vSphere 7 resource pools enable the separation of resources from hardware. You can use them to manage resources independently from the actual hosts that contribute to the cluster.
Where should vSphere 7 resource pools be created? ^
Simply right-click your cluster, and from the menu, choose New Resource Pool. Note that resource pools are part of vSphere Enterprise or Enterprise Plus licensing.
Before you try, you’ll need to meet a few requirements. You must have DRS enabled on your cluster.
Create a new resource pool
On the next page, you’ll see this screen. You’ll need to give your resource pool a meaningful name first and then choose what CPU and memory allocation you would like to have.
Configure CPU and memory in your resource pool
Shares—The Shares value indicates which virtual machine will request resources with which priority if there is a shortage of resources on an ESXi host. By default, the Shares value is 1000, but you can increase it. If you increase it, the virtual machines in this resource pool will start to prioritize the use of CPU resources, as follows:
Low (2000), Normal (4000), High (8000) or custom.
Reservation—A virtual machine needs CPU and memory resources to run. If you do not want to be affected by the resource bottleneck on the ESXi server, you need to make a resource reservation.
Expandable Reservation—If the reserved resources are not provided, the virtual machine cannot be started. If this option is selected, even if there is no resource in the resource pool, you can use the resources of the resource pool located above it and power on the virtual machine.
Limit—If you set a limit for a resource pool, you can never exceed that limit. I do not recommend that this setting be used in a production environments. For example, if the virtual machine has 2 GHz usage, if you limit it to 1 GHz, this resource will never, ever exceed 1 GHz.
Unlimited—This option should always be checked if you are not setting a limit. It indicates that there is no limit on the amount of CPU you have allocated.
What are some use cases for using a resource pool? ^
You might have more than one database and IIS servers in your infrastructure. Let’s assume that you create a resource pool named Database and add Database servers into it. You can then create a resource pool named IIS and add your IIS-related virtual machines to it. In this way, you can perfectly allocate how much of the overall cluster resources would be available for your Database resource pool and how much for your IIS resource pool.
You might also have VMs that are part of different departments, such as Human Resources (HR), DevOps, CAD Design, Machine Learning etc. Each department might have different requirements when it comes to performance. For example, the Machine Learning VMs might need a lot compared to HR, and so on.
We looked at VMware documentation, where two different departments use a resource pool. The QA department needs more CPU. The admin simply sets the CPU shares toHigh for this resource pool and to Normal for the Marketing resource pool. This is the simplest example.
Resource pools are container objects in the vSphere 7 inventory, and they help to create compartments. Each compartment has its own CPU and memory settings set as a percentage of the overall cluster resources. A delegation can be created within vSphere 7, as resource pools are objects.
Example of vSphere 7 resource pool
There are also more complex cases, especially with a child resource pool. There is a checkbox called Scale Descendant Shares when you have a parent resource pool.
The Scale Descendant Shares option allows the shares allocated to each descendant resource pool to be adjusted to ensure that the relative shares allocated to the VMs are maintained. With scalable shares, the allocation for each pool factors in the number of objects in the pool. You can add/remove objects or VMs, and the shares for each object are adjusted automatically.
Note that this wasn’t the case in previous releases of vSphere, where resource pools were only static.
Scale Descendant Shares option
Final words ^
vSphere 7 resource pools are an important part of vSphere resource management. Admins leaning toward the VMware certification exam and admins who do not know how resource pools work should definitely take a closer look. Resource pools can effectively help to separate the overall resources of the cluster into compartments, where each compartment can have different CPU and memory allocations, preserving the performance of the group of VMs that needs it.
Subscribe to 4sysops newsletter!
Resource pools are particularly useful in large-scale environments with hundreds or thousands of hosts, where you need to use cluster resources effectively.
A resource pool is a logical abstraction for flexible management of resources. Resource pools can be grouped into hierarchies and used to hierarchically partition available CPU and memory resources.
Each standalone host and each DRS cluster has an (invisible) root resource pool that groups the resources of that host or cluster. The root resource pool does not appear because the resources of the host (or cluster) and the root resource pool are always the same.
Users can create child resource pools of the root resource pool or of any user-created child resource pool. Each child resource pool owns some of the parent’s resources and can, in turn, have a hierarchy of child resource pools to represent successively smaller units of computational capability.
A resource pool can contain child resource pools, virtual machines, or both. You can create a hierarchy of shared resources. The resource pools at a higher level are called parent resource pools. Resource pools and virtual machines that are at the same level are called siblings. The cluster itself represents the root resource pool. If you do not create child resource pools, only the root resource pools exist.
In the following example, RP-QA is the parent resource pool for RP-QA-UI. RP-Marketing and RP-QA are siblings. The three virtual machines immediately below RP-Marketing are also siblings.
Figure 1. Parents, Children, and Siblings in Resource Pool Hierarchy
For each resource pool, you specify reservation, limit, shares, and whether the reservation should be expandable. The resource pool resources are then available to child resource pools and virtual machines.
