Red Hat Enterprise Linux 7 以前の CGroups V1 から Red Hat Enterprise Linux 8 の CGroups V2 への移行

概要

コントロールグループ (CGroups) は、メモリー消費量、CPU 時間、読み取りおよび書き込み操作におけるブロックデバイスの帯域幅など、システム内のリソースを階層的に管理する方法を提供します。たとえば、システムは CPU 実行時間を分割して、CPU 実行時間全体の 80% をデータベースワークロードに費やすことができます。この 80% の内、CPU 実行時間はさらに、ログ操作用に 5%、ユーザークエリー用に 75% に分割できます。CGroups は、問題のリソースが同じシステム内の複数のワークロード間で共有されている場合 (バックアップが実稼働データベースと同じストレージデバイスに書き込まれる場合や、混合ワークロード内の CPU など) に非常に便利な機能を提供します。

RHEL ファミリーでは、RHEL 6 で CGroups (現在は CGroups V1 と呼ばれています) が導入されました。長年にわたり、Linux コミュニティーは、CGroups V1 で達成された成果を改良し、はるかに単純な階層と、リソースの階層管理に使用しやすいサブシステムを導入するために、CGropus V2 の開発を開始しました。RHEL 8 で CGroups V2 が導入されました。

CGroups の詳細は、CGroups に関する ブログ投稿シリーズ を参照してください。

CGroups V2 階層を操作する方法

概念レベルでは、CGroups V1 にマウントされたリソースコントローラーと cgroups が、コントローラー階層内に作成されました。代わりに、CGroups V2 は問題の cgroups を作成し、次に cgroup.subtree_control ファイルを介して、必要なこちらのコントローラーを cgroups に組み込みます。基本的に、CGroups V1 にはコントローラーに関連付けられた cgroups が、CGroups V2 には cgroups に関連付けられたコントローラーがあります。

上記では、bg cgroup は V1 の blkio および cgroups のメモリーに関連付けられていますが、bg cgroup は複数のコントローラーに関連付けられているため、階層内でエントリーが重複しています。V2 では、bg cgroup は 1 回存在し、cgroup.subtree_control に記載されているように、メモリー および IO コントローラーが関連付けられています。

CGroups V2 を有効にするには、起動時にカーネルパラメーターを変更して一時的にカーネルパラメーターに追加するか、grub.cfg ファイルを更新して永続的に カーネルパラメーターに systemd.unified_cgroup_hierarchy=1 を追加する必要があります。このパラメータで起動すると、systemd は CGroups V2 のコントローラーを使用し、パラメーターが提供されていない場合の CGroups V1 と同様に、cgroup の擬似ファイルシステムを自動的にマウントします。ここで、ユーザーは /sys/fs/cgroup/ にアクセスし、cgroup の作成を表すディレクトリーを作成し、cgroup の疑似ファイルシステム内に自動的に生成されたファイルに値を echo で書き出すことで、コントローラーのパラメーターを変更できます。

CGroups V2 が有効な場合でも、CGroups V1 コントローラーをマウントして使用できますが、現時点では CGroups V1 と V2 の混在はサポートされていません。さらに、現在、RHEL 8 に同梱されている Podman、Red Hat Virtualization 内の libvirtd、KVM などの さまざまなアプリケーションスタックでの CGroups V2 の使用はサポートされていません。

CGroups V1 から CGroups V2 に移行する方法

ご使用の環境で CGroups V1 の以前の設定が libcgroup スタイルの設定 (例: cgconfig では /etc/cgconfig.conf を使用して cgroup 階層を管理) と適切に連携していた場合、libcgroup から管理するサービスには、systemd ユニットファイルを書き込む必要があります。ワークロードやアプリケーションスタックの要件や複雑性は異なるため、システムユニットファイルを作成して、systemd 経由でのサービス管理を設定するのは、アプリケーションベンダーが行い、すべてのアプリケーションスタックの要件が満たされるようにすることがベストプラクティスです。ユニットファイルの作成に関する追加のサポートについては、他の ナレッジベースの記事 または ドキュメント を参照してください。

関連するサービスにユニットファイルが存在する場合は、systemd ディレクティブ (制限の操作) の大部分については systemd.resource-control (5) を参照してください。主な違いは次のとおりです。

• RHEL 7 以降の systemd では Cgroups CPU Set は、CPUAffinity に置き換えられました (systemd-system.conf (5) を参照)。
  • CPUAffinity は CGroups cpuset ではなく sched_setaffinity (2) を使用することに 注意してください。
• CGroups V2 には現在、CPU、IO、メモリー、および PID コントローラーのみが含まれています。

よくある質問 (FAQ)

• RHEL 8 より前のリリース用に作成されたコンテナーを RHEL 8 ホストで実行できますか?
  • はい、できます。RHEL 8 では CGroups V1 がデフォルトであるため、RHEL 7 CGroup V1 コンテナーを特に変更せずに RHEL 8 で使用を続けることができます。
• cgroupV2 ではどのようなコントローラーを使用できますか?
  • 現在、明示的に存在する V2 コントローラーは 4 つだけです。(CPU、IO、メモリー、PID)。
• CGroup V2 を有効にするにはどうすればいいですか?
  • V1 と V2 を切り替えるには、それぞれのコントローラーをマウントおよびアンマウントするだけで済みますが、systemd では少なくとも 1 セットをマウントする必要があります。そのため、切り替え方法として、カーネルブートパラメーターの使用のみが唯一、サポートされています。

systemd.unified_cgroup_hierarchy=1

• CGroup V1 は RHEL 8 で廃止されますか?libcgroup は非推奨になっており、削除リストに載っているようです。他にどのパッケージがこれに依存していますか?
  • CGroup V1 は、下位互換性の理由から、マウントするデフォルトの CGroup として RHEL 8 で引き続きサポートされます。CGroup V2 は、libvirt、runc などのアプリケーション移行開発のための補助機能です。Systemd はすでに CGroups V1 と CGroups V2 の両方をサポートしています。
• Cgroup V1 と V2 を同じホストで同時に使用する場合の要件と制限は何ですか?
  • 現在、V1 と V2 の両方を同時にマウントすることはサポートされていません。
• CGroup V1 は RHEL 8 で廃止されますか?
  • いいえ、下位互換性の理由から、RHEL 8 のランタイムセットアップ中は CGroup V1 がデフォルトの cgroup になります。
• libcgroup は非推奨になっており、削除リストに載っているようです。
  • 現時点で、Red Hat は libcgroup スタイルの CGroups から、systemd スタイルの CGroups に移行することを強く推奨します。
• CGroups V1 に依存する他のパッケージは何ですか?
  • すべてのアイテムがリストアップされているわけではなく、サードパーティーのツールは含まれていませんが、libvirt, runc, docker, kubernetes が CGroups V1 に依存しています。