Bug 1683528 - glusterfs slice setup is missing in gluster-ansible-roles
Summary: glusterfs slice setup is missing in gluster-ansible-roles
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: gluster-ansible
Version: rhgs-3.4
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: RHGS 3.4.z Batch Update 4
Assignee: Sachidananda Urs
QA Contact: SATHEESARAN
URL:
Whiteboard:
Depends On:
Blocks: 1683529
TreeView+ depends on / blocked
 
Reported: 2019-02-27 06:49 UTC by SATHEESARAN
Modified: 2019-03-27 03:44 UTC (History)
6 users (show)

Fixed In Version: gluster-ansible-features-1.0.4-5.el7rhgs
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1683529 (view as bug list)
Environment:
Last Closed: 2019-03-27 03:44:39 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0661 0 None None None 2019-03-27 03:44:53 UTC

Description SATHEESARAN 2019-02-27 06:49:43 UTC
Description of problem:
-----------------------
As there are gluster and virt services are running on the same host/machines,
gluster slice setup is required to cap the number of cores consumed by gluster process. Gdeploy has gone with the standard value of 33% cores allocated to gluster process. The same needs to implemented with gluster-ansible roles too.

Version-Release number of selected component (if applicable):
-------------------------------------------------------------
gluster-ansible-roles-1.0.4-3

How reproducible:
-----------------
Always

Steps to Reproduce:
-------------------
1. Complete RHHI-V deployment with RHVH 4.3

Actual results:
---------------
gluster slice is not configured

Expected results:
-----------------
gluster slice should be configured

Comment 3 Sachidananda Urs 2019-02-28 13:55:37 UTC
I'm a bit stuck on this, on setting CPUQuota. Lack of enough documentation is blocking me.

https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#CPUQuota=
<snip>

CPUQuota=

    Assign the specified CPU time quota to the processes executed. Takes a percentage value, suffixed with "%". The percentage specifies how much CPU time the unit shall get at maximum, relative to the total CPU time available on one CPU. Use values > 100% for allotting CPU time on more than one CPU. This controls the "cpu.max" attribute on the unified control group hierarchy and "cpu.cfs_quota_us" on legacy. For details about these control group attributes, see cgroup-v2.txt and sched-bwc.txt.

    Example: CPUQuota=20% ensures that the executed processes will never get more than 20% CPU time on one CPU.

</snip>

So, how do we calculate the CPUQuota for servers with N processors? I don't know yet.
It is not straight forward like N * (% of CPU to be reserved) as per the example above. It has be > 100% for allotting CPU time on more than one CPU. If there are two cores and we set 2*33 = 66% then as per above documentation it'd be 66% per processor.

@sas, @sahina, @gobinda any ideas?

Comment 4 Sahina Bose 2019-03-04 06:47:54 UTC
(In reply to Sachidananda Urs from comment #3)
> I'm a bit stuck on this, on setting CPUQuota. Lack of enough documentation
> is blocking me.
> 
> https://www.freedesktop.org/software/systemd/man/systemd.resource-control.
> html#CPUQuota=
> <snip>
> 
> CPUQuota=
> 
>     Assign the specified CPU time quota to the processes executed. Takes a
> percentage value, suffixed with "%". The percentage specifies how much CPU
> time the unit shall get at maximum, relative to the total CPU time available
> on one CPU. Use values > 100% for allotting CPU time on more than one CPU.
> This controls the "cpu.max" attribute on the unified control group hierarchy
> and "cpu.cfs_quota_us" on legacy. For details about these control group
> attributes, see cgroup-v2.txt and sched-bwc.txt.
> 
>     Example: CPUQuota=20% ensures that the executed processes will never get
> more than 20% CPU time on one CPU.
> 
> </snip>
> 
> So, how do we calculate the CPUQuota for servers with N processors? I don't
> know yet.
> It is not straight forward like N * (% of CPU to be reserved) as per the
> example above. It has be > 100% for allotting CPU time on more than one CPU.
> If there are two cores and we set 2*33 = 66% then as per above documentation
> it'd be 66% per processor.
> 
> @sas, @sahina, @gobinda any ideas?

Will this work - https://github.com/oVirt/ovirt-engine/blob/master/packaging/playbooks/roles/hc-gluster-cgroups/tasks/main.yml
This is what was implemented in ovirt-engine for nodes added to engine post the 3 node deployment

Comment 5 Sachidananda Urs 2019-03-04 08:40:24 UTC
(In reply to Sahina Bose from comment #4)
> (In reply to Sachidananda Urs from comment #3)
> > I'm a bit stuck on this, on setting CPUQuota. Lack of enough documentation
> > is blocking me.
> > 
> > https://www.freedesktop.org/software/systemd/man/systemd.resource-control.
> > html#CPUQuota=
> > <snip>
> > 
> > CPUQuota=
> > 
> >     Assign the specified CPU time quota to the processes executed. Takes a
> > percentage value, suffixed with "%". The percentage specifies how much CPU
> > time the unit shall get at maximum, relative to the total CPU time available
> > on one CPU. Use values > 100% for allotting CPU time on more than one CPU.
> > This controls the "cpu.max" attribute on the unified control group hierarchy
> > and "cpu.cfs_quota_us" on legacy. For details about these control group
> > attributes, see cgroup-v2.txt and sched-bwc.txt.
> > 
> >     Example: CPUQuota=20% ensures that the executed processes will never get
> > more than 20% CPU time on one CPU.
> > 
> > </snip>
> > 
> > So, how do we calculate the CPUQuota for servers with N processors? I don't
> > know yet.
> > It is not straight forward like N * (% of CPU to be reserved) as per the
> > example above. It has be > 100% for allotting CPU time on more than one CPU.
> > If there are two cores and we set 2*33 = 66% then as per above documentation
> > it'd be 66% per processor.
> > 
> > @sas, @sahina, @gobinda any ideas?
> 
> Will this work -
> https://github.com/oVirt/ovirt-engine/blob/master/packaging/playbooks/roles/
> hc-gluster-cgroups/tasks/main.yml
> This is what was implemented in ovirt-engine for nodes added to engine post
> the 3 node deployment

Sahina, thank you. That definitely helped.

Comment 6 Sachidananda Urs 2019-03-04 08:44:52 UTC
https://github.com/gluster/gluster-ansible-features/pull/22 fixes the issue.

Note that the calculation for 1/3 of the cores is done as follows:

ceil(processor_vcpus/3)*100

So if there are 4 processors, the CPUQuota will be 4/3 = 1.333 and ceil(1.333) = 2 * 100 = 200%
Due to ceil, it would be 50% in this case than 33%. It is not a bug but for smaller number of processors that is how it is.

Comment 7 SATHEESARAN 2019-03-06 11:56:49 UTC
Tested with gluster-ansible-features-1.0.4-5

Glusterfs slice is now available

[root@ ~]# systemctl status glusterd
● glusterd.service - GlusterFS, a clustered file-system server
   Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/glusterd.service.d
           └─99-cpu.conf
   Active: active (running) since Wed 2019-03-06 13:53:36 IST; 3h 30min ago
 Main PID: 5365 (glusterd)
   CGroup: /system.slice/glusterd.service
           ├─ 5365 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level IN...
           ├─ 9863 /usr/sbin/glusterfsd -s dhcp37-161.lab.eng.blr.redhat.com ...
           ├─10355 /usr/sbin/glusterfsd -s dhcp37-161.lab.eng.blr.redhat.com ...
           └─10377 /usr/sbin/glusterfs -s localhost --volfile-id gluster/glus...

Mar 06 13:53:31 dhcp37-161.lab.eng.blr.redhat.com systemd[1]: Starting Gluste...
Mar 06 13:53:36 dhcp37-161.lab.eng.blr.redhat.com systemd[1]: Started Gluster...
Mar 06 14:29:28 dhcp37-161.lab.eng.blr.redhat.com glusterd[5365]: [2019-03-06...
Mar 06 14:29:40 dhcp37-161.lab.eng.blr.redhat.com glusterd[5365]: [2019-03-06...

[root@ ~]# cat /etc/systemd/system/glusterfs.slice 
[Slice]
CPUQuota=200%

[root@ ~]# nproc
4

Comment 9 errata-xmlrpc 2019-03-27 03:44:39 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0661


Note You need to log in before you can comment on or make changes to this bug.