Electronic Joint Business

Solution for E-Business

cgroups

为 Windows containers 实现资源控制 (一) 作业对象

Windows 可以按容器或者按资源来实施资源控制。默认情况下, 运行的容器受 Windows 资源管理的约束, 以公平分配为原则, 但通过资源控制,开发人员或管理员可以限制或影响资源的使用。可控制的资源包括: CPU/处理器、内存/RAM、磁盘/存储、和网络/吞吐量等等。

Windows 容器利用作业对象(job objects)来对每个容器相关联的进程进行分组和跟踪。资源控制则在与容器关联的父作业对象上实施。 在 Hyper-V 隔离的情况下,系统同时对虚拟机和在虚拟机中运行的容器的作业对象进行自动资源控制,这样即使容器中运行的进程绕过了或逃脱了作业对象控制,虚拟机也会确保其无法越过定义的资源控制。

作业对象
Windows提供一个作业(job)内核对象,它允许我们将进程组合在一起并创建一个“沙箱”来限制进程能够做什么。作业对象允许将进程组作为一个单元进行管理。作业对象是可命名的(namable)、安全的、共享的对象, 可控制与之关联的进程的属性。对作业对象执行的操作会影响和作业对象相关联的所有进程。比如对工作集大小、进程优先级进行强制限制,或终止与作业关联的所有进程。你可以将作业对象想象成一个进程容器。但是,创建只包含一个进程的作业同样非常有用,因为这样可以对进程施加平时不能施加的限制。

作业对象 VS Linux 控制组 cgroups
Linux 的 cgroups 不等同于 Windows 和 VMS 的作业, 它缺乏作业机制的真正功能。这些年来人们一直在抱怨 Systemd 的这个问题,他们非常期待 cgroups 2.0 能提供真正的作业机制,因为现阶段的 Systemd 存在严重的错误,它无法自动终止控制组中的所有内容。

相反,提供“作业”抽象的操作系统内核一般都会提供了能取消/终止整个“作业”的方法,比如 Windows 的 TerminateJobObject()。而对于 Systemd,当其终止 cgroup 中的所有进程时, 它无法执行类似“终止作业”的系统调用,因为根本不存在这种机制。作为替代,Systemd 在应用模式下的某段循环代码中反复扫描 cgroup 中的所有进程 id,它重读一个 PID 列表文件, 并将信号发送到未列其中的新进程。这会带来几个问题:

>>> 阅读全文

 

, , ,