Správa cgroups pomocí systemd

V tomto posledním pokračování mé čtyřdílné série článků o cgroups se zabývám integrací cgroup s systemd. Nezapomeňte se také podívat na první, druhý a třetí díl série.

Cgroups s systemd

Ve výchozím nastavení systemd vytvoří novou cgroup pod system.slice pro každou službu, kterou monitoruje. Vraťme se k našemu hostiteli OpenShift Control Plane, kde běží systemd-cgls zobrazuje následující služby pod system.slice (výstup je kvůli stručnosti zkrácen):

└─system.slice
  ├─sssd.service
  ├─lvm2-lvmetad.service
  ├─rsyslog.service
  ├─systemd-udevd.service
  ├─systemd-logind.service
  ├─systemd-journald.service
  ├─crond.service
  ├─origin-node.service
  ├─docker.service
  ├─dnsmasq.service
  ├─tuned.service
  ├─sshd.service
  ├─NetworkManager.service
  ├─dbus.service
  ├─polkit.service
  ├─chronyd.service
  ├─auditd.service
    └─[email protected]

Toto chování můžete změnit úpravou souboru služby systemd. Pokud jde o správu cgroup pomocí systemd, existují tři možnosti:

• Úprava samotného souboru služby.
• Pomocí souborů typu drop-in.
• Pomocí systemctl set-property příkazy, které jsou stejné jako ruční úprava souborů, ale systemctl vytvoří za vás požadované položky.

Níže se o nich podrobněji věnuji.

Úprava souborů služeb

Upravme samotný soubor jednotky. Za tímto účelem jsem vytvořil velmi jednoduchý soubor jednotky, který spouští skript:

[Service]
Type=oneshot
ExecStart=/root/generate_load.sh
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Skript bash má pouze dva řádky:

#!/bin/bash
/usr/bin/cat /dev/urandom > /dev/null &

Když prozkoumáte výstup systemd-cgls , vidíte, že naše nová služba je vnořena pod system.slice (výstup zkrácen):

└─system.slice
  ├─cat.service
  ├─tuned.service
  ├─sshd.service
  ├─NetworkManager.service
  ├─sssd.service
  ├─dbus.service
  │ └─[email protected]
  └─systemd-logind.service

Co se stane, když do servisního souboru systemd přidám následující řádek?

Slice=my-beautiful-slice.slice

Výstup systemd-cgls ukazuje něco kuriózního. cat.service soubor je nyní hluboce vnořen:

Control group /:
├─my.slice
│ └─my-beautiful.slice
│   └─my-beautiful-slice.slice
│     └─cat.service
│       └─4010 /usr/bin/cat /dev/urandom

Proč je to? Odpověď souvisí se způsobem, jakým systemd interpretuje vnořené cgroups. Děti jsou deklarovány následujícím způsobem:-.slice . Protože systemd se snaží být nápomocný, pokud rodič neexistuje, systemd ho za vás vytvoří. Kdybych použil podtržítka _ místo pomlček - výsledek by byl takový, jaký byste očekávali:

Control group /:
├─my_beautiful_slice.slice
│ └─cat.service
│   └─4123 /usr/bin/cat /dev/urandom

Používání souborů typu drop-in

Nastavení Drop-in souborů pro systemd je poměrně triviální. Začněte vytvořením vhodného adresáře na základě názvu vaší služby v /etc/systemd/system . V cat například spusťte následující příkaz:

# mkdir -p /etc/systemd/system/cat.service.d/

Tyto soubory lze organizovat, jak chcete. Fungují na základě číselného pořadí, takže byste měli své konfigurační soubory pojmenovat nějak jako 10-CPUSettings.conf . Všechny soubory v tomto adresáři by měly mít příponu .conf a vyžadují, abyste spustili systemctl daemon-reload pokaždé, když upravíte jeden z těchto souborů.

Vytvořil jsem dva soubory drop-in, abych ukázal, jak můžete rozdělit různé konfigurace. První je 00-slice.conf . Jak je vidět níže, nastavuje výchozí možnosti pro samostatný řez pro cat služba:

[Service]
Slice=AWESOME.slice
MemoryAccounting=yes
CPUAccounting=yes

Druhý soubor nastavuje počet CPUShares a jmenuje se 10-CPUSettings.conf .

[Service]
CPUShares=256

Abych ukázal, že tato metoda funguje, vytvořím ve stejném řezu druhou službu. Pro snazší rozlišení procesů je druhý skript mírně odlišný:

#!/bin/bash
/usr/bin/sha256sum /dev/urandom > /dev/null &

Pak jsem jednoduše vytvořil kopie cat soubory, nahrazením skriptu a změnou hodnoty CPUShares:

# sed 's/load\.sh/load2\.sh/g' cat.service > sha256sum.service
# cp -r cat.service.d sha256sum.service.d
# sed -i 's/256/2048/g' sha256sum.service.d/10-CPUSettings.conf

Nakonec znovu načtěte démona a spusťte služby:

# systemctl daemon-reload
# systemctl start cat.service
# systemctl start sha256sum.service

[ Čtenářům se také líbilo:Co se děje v zákulisí kontejneru Podman bez kořenů? ]

Místo zobrazení výstupu z top , nyní je ten správný čas představit vám systemd-cgtop . Funguje podobným způsobem jako běžný top kromě toho vám poskytne rozpis podle řezu a poté znovu podle služeb v každém řezu. To je velmi užitečné při určování, zda ve svém systému obecně dobře využíváte cgroups. Jak je vidět níže, systemd-cgtop ukazuje jak agregaci pro všechny služby v určitém řezu jako součást celkového systému, tak využití zdrojů každou službou v řezu:

Použití systemctl set-property

Poslední metodou, kterou lze ke konfiguraci skupin cgroups použít, je systemctl set-property příkaz. Začnu základním servisním souborem md5sum.service :

[Service]
Type=oneshot
ExecStart=/root/generate_load3.sh
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
Slice=AWESOME.slice

[Install]
WantedBy=multi-user.target

Pomocí systemctl set-property příkaz umístí soubory do /etc/systemd/system.control . Tyto soubory nelze upravovat ručně. Ne každá vlastnost je rozpoznána pomocí set-property příkaz, tedy Slice definice byla vložena do samotného souboru služby.

Poté, co jsem nastavil soubor jednotky a znovu načetl démona, použiji systemctl příkaz podobný následujícímu:

# systemctl set-property md5sum.service CPUShares=1024

Tím se vytvoří soubor drop-in umístěný na adrese /etc/systemd/system.control/md5sum.service.d/50-CPUShares.conf . Neváhejte se podívat na soubory, pokud vás zajímá jejich obsah. Protože tyto soubory nejsou určeny k ruční úpravě, nebudu nad nimi trávit čas.

Můžete otestovat, zda se změny projevily spuštěním:

systemctl start md5sum.service cat.service sha256sum.service

Jak vidíte na obrázku níže, změny se zdají být úspěšné. sha256sum.service je nakonfigurován pro 2048 CPUShares, zatímco md5sum.service má 1024. Nakonec cat.service má 256.

[ Přemýšlíte o bezpečnosti? Podívejte se na tohoto bezplatného průvodce posílením zabezpečení hybridního cloudu a ochranou vaší firmy. ] 

Sbalit

Doufám, že jste se během naší společné cesty naučili něco nového. Bylo toho hodně, co bylo třeba řešit, a sotva jsme se ani poškrábali na povrchu toho, co je možné pomocí cgroups. Kromě role, kterou cgroups hrají při udržování zdravého vašeho systému, hrají také roli ve strategii „hloubkové ochrany“. Kromě toho jsou cgroups kritickou komponentou pro moderní úlohy Kubernetes, kde napomáhají správnému běhu kontejnerizovaných procesů. Cgroups jsou zodpovědné za tolik věcí, včetně:

• Omezení zdrojů procesů.
• Rozhodování o prioritách, když se objeví spory.
• Řízení přístupu k zařízením pro čtení/zápis a mknod.
• Poskytování vysoké úrovně účtování pro procesy běžící v systému.

Dalo by se namítnout, že kontejnerizace, Kubernetes a řada dalších kriticky důležitých implementací by nebyly možné bez využití cgroups.

Pokud máte nějaké dotazy nebo připomínky nebo možná jiné nápady na články, neváhejte mě kontaktovat na Twitteru. Těším se na všechny vaše názory.

Zdroje

https://0xax.gitbooks.io/linux-insides/content/Cgroups/linux-cgroups-1.html
https://sysadmincasts.com/episodes/14-introduction-to-linux-control-groups -cgroups
https://itnext.io/chroot-cgroups-and-namespaces-an-overview-37124d995e3d
https://www.certdepot.net/rhel7-get-started-cgroups/
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/resource_management_guide/chap-introduction_to_control_groups
https://oakbytes.wordpress.com/2012/09/02/ cgroup-cpu-allocation-cpu-shares-examples/
https://www.redhat.com/en/blog/world-domination-cgroups-part-1-cgroup-basics
https:/ /www.redhat.com/en/blog/world-domination-cgroups-rhel-8-welcome-cgroups-v2
https://youtu.be/z7mgaWqiV90
https://youtu.be /el7768BNUPw
https://youtu.be/sK5i-N34im8
https://youtu.be/_AODvcO5Q_8
https://youtu.be/x1npPrzyKfs
https:/ /youtu.be/yZpNsDe4Qzg
https://access.redhat.com/solutions/4489171