精华内容
下载资源
问答
  • 对资源采用按需分配的策略
    千次阅读
    2020-01-06 22:28:24
    
    资源静态分配策略要求每个过程在开始执行前申请所需的全部资源,
    仅在系统为之分配了所需的全部资源后,该进程才开始执行。这样,
    进程在执行过程中不再申请资源,从而破坏了死锁的四个必要条件
    之一"占有并等待条件",从而防止死锁的发生。

     

     

    更多相关内容
  •  静态分配:批处理操作系统中,作业一级采用资源静态分配方法。作业所需要的资源是在调度到这个作业的时候,根据用户给出的信息进行分配,并在做作业运行完毕后释放所获得的的全部资源。 2.资源管理任务: ...

    一、资源管理  

               1.资源的动态分配:进程所需的资源是在进程运行中根据运行情况动态的分配、使用和释放的。

                            静态分配:批处理操作系统中,对作业一级采用资源静态分配方法。作业所需要的资源是在调度到这个作业的时候,根据用户给出的信息进行分配,并在做作业运行完毕后释放所获得的的全部资源。

              2.资源管理任务:

                  对资源数据结构的描述;确定资源的分配原则和调度原则;执行资源分配;存取控制和安全保护

              3.资源的分类:

                  物理资源和程序资源;

                  单一访问入口资源(一次只能为一个进程所用)/多访问入口资源(可同时为多个进程所共享)

                  等同资源:在某些条件下,申请者申请资源时,无论给它分配哪一个具体设备,对它而言都是等效的。

                  虚拟资源

    二、资源分配机制

              1.资源描述器:描述各类资源的最小分配单位的数据结构(RD),如主存储器的主存块,磁盘的扇区 

               2.资源信息块(rib):说明资源、请求者及实施分配所需的必要信息的数据结构

                        

    三、资源分配策略

           1.实施分配的时机:

                       当请求者发出一个明确地资源请求命令;                            当处理机空闲的时候;

                       当存储区被释放变为空闲的时候;                     当一个外部设备发生完成中断时;

              分配程序选择一个请求的的策略:

                       按照请求来到的先后次序进行查看;                将进程请求者的优先级结合到每一个请求中;

                       满足能更合理应用这个资源的请求

               先请求先服务(FIFO)           优先调度

               针对设备特性的调度:

                            移臂调度:在满足一个磁盘的请求时,总是选取与当前移动臂前进方向上最近的那个情求,使移臂距离最短

                             旋转调度:在满足一个磁盘请求时,总是选取与当前读写头旋转方向最近的那个情求,使旋转圈数最少

    四、死锁

            1.死锁:在两个或多个并发进程中,如果每种进程持有某种资源而又都等待着别的进程释放它或它们现在保持的资源,在未改变这种状态之前都不能向前推进,称这一组进程产生了死锁。

                     同类资源的死锁     ;    非同类资源的死锁

            2.产生死锁的原因及必要条件  

                      根本原因:系统能够提供的资源个数少于要求该资源的进程数

                      原因:系统资源不足;进程推进顺序非法

                      必要条件:互斥条件;不剥夺条件;占有并等待;环路条件 

            3.解决死锁问题的策略

                  预防死锁:通过设置某些限制条件,破坏死锁四个必要条件之一(多),来防止死锁

                                  破坏互斥条件(难)         破坏不剥夺条件(代价大)

                                  破坏部分分配条件(预先静态分配)

                                   破坏环路条件(有序资源分配)

                        较容易实现,但由于限制太严格,导致资源利用率和吞吐率降低

                   避免死锁:在资源的动态分配过程中,用某种方法防止进程进入不安全状态,从而避免死锁的进入。

                         较难实现,只需较弱的限制,就可获得较高的资源利用率和吞吐率

                   检测和恢复死锁:允许死锁发生,但可通过检测机制及时检测出死锁状态,并精确确定与死锁有关的进程和资源,然后采用使用措施,将系统中的死锁清除,将进程从死锁状态中解脱出来。

                              检测方法:难

                             恢复方法:   常用的方法是撤销或挂起一些进程,以回收一些资源,再将它们分配给处于阻塞状态的进程,使之转化为就绪状态

                        实现难度大,但可获得较高的资源利用率和系统吞吐量

              4.预防死锁:

                        静态预防:预先分配所有共享资源

                                   改进:将资源的分配单位由进程改为程序步

                        动态预防:采用资源的动态分配

                  避免死锁:

                         有序资源分配法:系统中所有资源都给定一个唯一的编号,所有分配请求必须以上升的次序进行。要求程序:

                                   对它所必须使用的属于某一类的所有资源必须一次申请完成;

                                   在申请不同类的资源时,必须安各类编号一次申请

                           银行家算法

                    







    展开全文
  • 本文作者通过阿里巴巴容器平台团队在这一领域的工作实践,整理出了一套资源利用提升的方案,希望能够带给大家带来一些讨论和思考。 引言 不知道大家有没有过这样的经历:当我们拥有了一套 Kubernetes 集群,然...

    作者 | 张晓宇(衷源) 阿里云容器平台技术专家

    关注『阿里巴巴云原生』公众号,回复关键词“1010”,可获取本文 PPT。

    **导读:**资源利用率一直是很多平台管理和研发人员关心的话题。本文作者通过阿里巴巴容器平台团队在这一领域的工作实践,整理出了一套资源利用提升的方案,希望能够带给大家带来一些讨论和思考。

    引言

    不知道大家有没有过这样的经历:当我们拥有了一套 Kubernetes 集群,然后开始部署应用的时候,我们应该给容器分配多少资源呢?

    这很难说。由于 Kubernetes 自己的机制,我们可以理解容器的资源实质上是一个静态的配置。

    • 如果我发现资源不足,为了分配给容器更多资源,我们需要重建 Pod;
    • 如果分配冗余的资源,那么我们的 worker node 节点似乎又部署不了多少容器。

    试问,我们能做到容器资源的按需分配吗?接下来,我们将在本次分享中和大家一起进行探讨这个问题的答案。

    生产环境中的真实挑战

    首先请允许我们根据我们的实际情况抛出我们实际生产环境的挑战。或许大家还记得 2018 年的天猫双 11,这一天的总成交额达到了 2135 亿。由此一斑可窥全豹,能够支撑如此庞大规模的交易量背后的系统,其应用种类和数量应该是怎样的一种规模。

    在这种规模下,我们常常听到的容器调度,如:容器编排,负载均衡,集群扩缩容,集群升级,应用发布,应用灰度等等这些词,在被“超大规模集群”这个词修饰后,都不再是件容易处理的事情。规模本身也就是我们最大的挑战。如何运营和管理好这么一个庞大的系统,并遵循业界 dev-ops 宣传的那样效果,犹如让大象去跳舞。但是马老师曾说过,大象就该干大象该干的事情,为什么要去跳舞呢。

    Kubernetes 的帮助

    k1

    大象是否可以跳舞,带着这个问题,我们需要从淘宝、天猫等 APP 背后系统说起。

    这套互联网系统应用部署大致可分为三个阶段,传统部署,虚拟机部署和容器部署。相比于传统部署,虚拟机部署有了更好的隔离性和安全性,但是在性能上不可避免的产生了大量损耗。而容器部署又在虚拟机部署实现隔离和安全的背景下,提出了更轻量化的解决方案。我们的系统也是沿着这么一条主航道上运行的。假设底层系统好比一艘巨轮,面对巨量的集装箱—容器,我们需要一个优秀的船长,对它们进行调度编排,让系统这艘大船可以避开层层险阻,操作难度降低,且具备更多灵活性,最终达成航行的目的。

    理想与现实

    在开始之初,想到容器化和 Kubernetes 的各种美好场景,我们理想中的容器编排效果应该是这样的:

    • 从容:我们的工程师更加从容的面对复杂的挑战,不再眉头紧锁而是更多笑容和自信;
    • 优雅:每一次线上变更操作都可以像品着红酒一样气定神闲,优雅地按下执行的回车键;
    • 有序:从开发到测试,再到灰度发布,一气呵成,行云流水;
    • 稳定:系统健壮性良好,任尔东西南北风,我们系统岿然不动。全年系统可用性 N 多个 9;
    • 高效:节约出更多人力,实现“快乐工作,认真生活”。

    然而理想很丰满,现实很骨感。迎接我们的却是杂乱和形态各异的窘迫。

    杂乱,是因为作为一个异军突起的新型技术栈,很多配套工具和工作流的建设处于初级阶段。Demo 版本中运行良好的工具,在真实场景下大规模铺开,各种隐藏的问题就会暴露无遗,层出不穷。从开发到运维,所有的工作人员都在各种被动地疲于奔命。另外,“大规模铺开”还意味着,要直接面对形态各异的生产环境:异构配置的机器、复杂的需求,甚至是适配用户的既往的使用习惯等等。

    k2

    除了让人心力交瘁的混乱,系统还面临着应用容器的各种崩溃问题:内存不足导致的 OOM,CPU quota 分配太少,导致进程被 throttle,还有带宽不足,响应时延大幅上升…甚至是交易量在面对访问高峰时候由于系统不给力导致的断崖式下跌等等。这些都使我们在大规模商用 Kubernetes 场景中积累非常多的经验。

    直面问题

    稳定性

    问题总要进行面对的。正如某位高人说过:如果感觉哪里不太对,那么肯定有些地方出问题了。于是我们就要剖析,问题究竟出在哪里。针对于内存的 OOM,CPU 资源被 throttle,我们可以推断我们给与容器分配的初始资源不足。

    k3

    资源不足就势必造成整个应用服务稳定性下降。例如上图的场景:虽然是同一种应用的副本,或许是由于负载均衡不够强大,或者是由于应用自身的原因,甚至是由于机器本身是异构的,相同数值的资源,可能对于同一种应用的不同副本并具有相等的价值和意义。在数值上他们看似分配了相同的资源,然而在实际负载工作时,极有可能出现的现象是肥瘦不均的。

    k4

    而在资源 overcommit 的场景下,应用在整个节点资源不足,或是在所在的 CPU share pool 资源不足时,也会出现严重的资源竞争关系。资源竞争是对应用稳定性最大的威胁之一。所以我们要尽力在生产环境中清除所有的威胁。

    我们都知道稳定性是件很重要的事情,尤其对于掌控上百万容器生杀大权的一线研发人员。或许不经心的一个操作就有可能造成影响面巨大的生产事故。

    因此,我们也按照一般流程做了系统预防和兜底工作。

    • 在预防维度,我们可以进行全链路的压力测试,并且提前通过科学的手段预判应用需要的副本数和资源量。如果没法准确预算资源,那就只采用冗余分配资源的方式了。
    • 在兜底维度,我们可以在大规模访问流量抵达后,对不紧要的业务做服务降级并同时对主要应用进行临时扩容。

    但是对于陡然增加几分钟的突增流量,这么多组合拳的花费不菲,似乎有些不划算。或许我们可以提出一些解决方案,达到我们的预期。

    资源利用率

    回顾一下我们的应用部署情况:节点上的容器一般分属多种应用,这些应用本身不一定,也一般不会同时处于访问的高峰。对于混合部署应用的宿主机,如果能都错峰分配上面运行容器的资源或许更科学。

    k5

    应用的资源需求可能就像月亮一样有阴晴圆缺,有周期变化。例如在线业务,尤其是交易业务,它们在资源使用上呈现一定的周期性,例如:在凌晨、上午时,它的使用量并不是很高,而在午间、下午时会比较高。

    打个比方:对于 A 应用的重要时刻,对于 B 应用可能不那么重要,适当打压 B 应用,腾挪出资源给 A 应用,这是个不错的选择。这听起来有点像是分时复用的感觉。但是如果我们按照流量峰值时的需求配置资源就会产生大量的浪费。

    k6

    除了对于实时性要求很高的在线应用外,我们还有离线应用和实时计算应用等:离线计算对于 CPU 、Memory 或网络资源的使用以及时间不那么敏感,所以在任何时间段它都可以运行;实时计算,可能对于时间敏感性就会很高。

    早期,我们业务是在不同的节点按照应用的类型独立进行部署。从上面这张图来看,如果它们进行分时复用资源,针对实时性这个需求层面,我们会发现它实际的最大使用量不是 2 2 1=5,而是某一时刻重要紧急应用需求量的最大值,也就是 3 。如果我们能够数据监测到每个应用的真实使用量,给它分配合理值,那么就能产生资源利用率提升的实际效果。

    对于电商应用,对于采用了重量级 Java 框架和相关技术栈的 Web 应用,短时间内 HPA 或者 VPA 都不是件容易的事情。

    先说 HPA,我们或许可以秒级拉起了 Pod,创建新的容器,然而拉起的容器是否真的可用呢。从创建到可用,可能需要比较久的时间,对于大促和抢购秒杀-这种访问量“洪峰”可能仅维持几分钟或者十几分钟的实际场景,如果我们等到 HPA 的副本全部可用,可能市场活动早已经结束了。

    至于社区目前的 VPA 场景,删掉旧 Pod,创建新 Pod,这样的逻辑更难接受。所以综合考虑,我们需要一个更实际的解决方案弥补 HPA 和 VPA 的在这一单机资源调度的空缺。

    解决方案

    交付标准

    我们首先要对解决方案设定一个可以交付的标准那就是—— “既要稳定性,也要利用率,还要自动化实施,当然如果能够智能化那就更好”,然后再交付标准进行细化:

    • 安全稳定:工具本身高可用。所用的算法和实施手段必须做到可控;
    • 业务容器按需分配资源:可以及时根据业务实时资源消耗对不太久远的将来进行资源消耗预测,让用户明白业务接下来对于资源的真实需求;
    • 工具本身资源开销小:工具本身资源的消耗要尽可能小,不要成为运维的负担;
    • 操作方便,扩展性强:能做到无需接受培训即可玩转这个工具,当然工具还要具有良好扩展性,供用户 DIY;
    • 快速发现 & 及时响应:实时性,也就是最重要的特质,这也是和HPA或者VPA在解决资源调度问题方式不同的地方。

    设计与实现

    k7

    上图是我们最初的工具流程设计:当一个应用面临很高的业务访问需求时,体现在 CPU、Memory 或其他资源类型需求量变大,我们根据 Data Collector 采集的实时基础数据,利用 Data Aggregator 生成某个容器或整个应用的画像,再将画像反馈给 Policy engine。 Policy engine 会瞬时快速修改容器 Cgroup 文件目录下的的参数。

    我们最早的架构和我们的想法一样朴实,在 kubelet 进行了侵入式的修改。虽然我们只是加了几个接口,但是这种方式确实不够优雅。每次 kubenrnetes 升级,对于 Policy engine 相关组件升级也有一定的挑战。

    k8

    为了做到快速迭代并和 Kubelet 解耦,我们对于实现方式进行了新的演进。那就是将关键应用容器化。这样可以达到以下功效:

    • 不侵入修改 K8s 核心组件;
    • 方便迭代&发布;
    • 借助于 Kubernetes 相关的 QoS Class 机制,容器的资源配置,资源开销可控。

    当然在后续演进中,我们也在尝试和 HPA,VPA 进行打通,毕竟这些和 Policy engine 存在着互补的关系。因此我们架构进一步演进成如下情形。当 Policy engine 在处理一些更多复杂场景搞到无力时,上报事件让中心端做出更全局的决策。水平扩容或是垂直增加资源。

    k9

    下面我们具体讨论一下 Policy engine 的设计。Policy engine 是单机节点上进行智能调度并执行 Pod 资源调整的核心组件。它主要包括 api server,指挥中心 command center 和执行层 executor。

    • 其中 api server 用于服务外界对于 policy engine 运行状态的查询和设置的请求;
    • command center 根据实时的容器画像和物理机本身的负载以及资源使用情况,作出 Pod 资源调整的决策;
    • Executor 再根据 command center 的决策,对容器的资源限制进行调整。同时,executor 也把每次调整的 revision info 持久化,以便发生故障时可以回滚。

    指挥中心定期从 data aggregator 获取容器的实时画像,包括聚合的统计数据和预测数据,首先判断节点状态,例如节点磁盘异常,或者网络不通,表示该节点已经发生异常,需要保护现场,不再对Pod进行资源调整,以免造成系统震荡,影响运维和调试。如果节点状态正常,指挥中心会策略规则,对容器数据进行再次过滤。比如容器 CPU 率飙高,或者容器的响应时间超过安全阈值。如果条件满足,则对满足条件的容器集合给出资源调整建议,传递给executor。

    在架构设计上,我们遵循了以下原则:

    • 插件化:所有的规则和策略被设计为可以通过配置文件来修改,尽量与核心控制流程的代码解耦,与 data collector 和 data aggregator 等其他组件的更新和发布解耦,提升可扩展性;

    • 稳定,这包括以下几个方面:

      • 控制器稳定性。指挥中心的决策以不影响单机乃至全局稳定性为前提,包括容器的性能稳定和资源分配稳定。例如,目前每个控制器仅负责一种 cgroup 资源的控制,即在同一时间窗口内,Policy engine 不同时调整多种资源,以免造成资源分配震荡,干扰调整效果;
      • 触发规则稳定性。例如,某一条规则的原始触发条件为容器的性能指标超出安全阈值,但是为避免控制动作被某一突发峰值触发而导致震荡,我们把触发规则定制为:过去一段时间窗口内性能指标的低百分位超出安全阈值;如果规则满足,说明这段时间内绝大部分的性能指标值都已经超出了安全阈值,就需要触发控制动作了;
      • 另外,与社区版 Vertical-Pod-Autoscaler 不同,Policy engine 不主动驱逐腾挪容器,而是直接修改容器的 cgroup 文件;
    • 自愈:资源调整等动作的执行可能会产生一些异常,我们在每个控制器内都加入了自愈回滚机制,保证整个系统的稳定性;

    • 不依赖应用先验知识:为所有不同的应用分别进行压测、定制策略,或者提前对可能排部在一起的应用进行压测,会导致巨大开销,可扩展性降低。我们的策略在设计上尽可能通用,尽量采用不依赖于具体平台、操作系统、应用的指标和控制策略。

    在资源调整方面,Cgroup 支持我们对各个容器的 CPU、内存、网络和磁盘 IO 带宽资源进行隔离和限制,目前我们主要对容器的 CPU 资源进行调整,同时在测试中探索在时分复用的场景下动态调整 memory limit 和 swap usage 而避免 OOM 的可行性;在未来我们将支持对容器的网络和磁盘 IO 的动态调整。

    调整效果

    k10

    上图展示了我们在测试集群得到的一些实验结果。我们把高优先级的在线应用和低优先级的离线应用混合部署在测试集群里。SLO 是 250ms,我们希望在线应用的 latency 的 95 百分位值低于阈值 250ms。

    在实验结果中可以看到:

    • 在大约90s前,在线应用的负载很低;latency 的均值和百分位都在 250ms 以下;
    • 到了 90s后,我们给在线应用加压,流量增加,负载也升高,导致在线应用 latency 的 95 百分位值超过了 SLO;
    • 在大约 150s 左右,我们的小步快跑控制策略被触发,渐进式地 throttle 与在线应用发生资源竞争的离线应用;
    • 到了大约 200s 左右,在线应用的性能恢复正常,latency 的 95 百分位回落到 SLO 以下。

    这说明了我们的控制策略的有效性。

    经验和教训

    下面我们总结一下在整个项目的进行过程中,我们收获的一些经验和教训,希望这些经验教训能够对遇到类似问题和场景的人有所帮助。

    1. 避开硬编码,组件微服务化,不仅便于快速演进和迭代,还有利于熔断异常服务。
    2. 尽可能不要调用类库中还是 alpha 或者 beta 特性的接口。 例如我们曾经直接调用 CRI 接口读取容器的一些信息,或者做一些更新操作,但是随着接口字段或者方法的修改,共建有些功能就会变得不可用,或许有时候,调用不稳定的接口还不如直接获取某个应用的打印信息可能更靠谱。
    3. 基于 QoS 的资源动态调整方面:如我们之前所讲,阿里集团内部有上万个应用,应用之间的调用链相当复杂。应用 A 的容器性能发生异常,不一定都是在单机节点上的资源不足或者资源竞争导致,而很有可能是它下游的应用 B、应用 C,或者数据库、cache 的访问延迟导致的。由于单机节点上这种信息的局限性,基于单机节点信息的资源调整,只能采用“尽力而为”,也就是 best effort 的策略了。在未来,我们计划打通单机节点和中心端的资源调控链路,由中心端综合单机节点上报的性能信息和资源调整请求,统一进行资源的重新分配,或者容器的重新编排,或者触发 HPA,从而形成一个集群级别的闭环的智能资源调控链路,这将会大大提高整个集群维度的稳定性和综合资源利用率。
    4. 资源v.s.性能模型:可能有人已经注意到,我们的调整策略里,并没有明显地提出为容器建立“资源v.s.性能”的模型。这种模型在学术论文里非常常见,一般是对被测的几种应用进行了离线压测或者在线压测,改变应用的资源分配,测量应用的性能指标,得到性能随资源变化的曲线,最终用在实时的资源调控算法中。在应用数量比较少,调用链比较简单,集群里的物理机硬件配置也比较少的情况下,这种基于压测的方法可以穷举到所有可能的情况,找到最优或者次优的资源调整方案,从而得到比较好的性能。但是在阿里集团的场景下,我们有上万个应用,很多重点应用的版本发布也非常频繁,往往新版本发布后,旧的压测数据,或者说资源性能模型,就不适用了。另外,我们的集群很多是异构集群,在某一种物理机上测试得到的性能数据,在另一台不同型号的物理机上就不会复现。这些都对我们直接应用学术论文里的资源调控算法带来了障碍。所以,针对阿里集团内部的场景,我们采用了这样的策略:不对应用进行离线压测,获取显示的资源性能模型。而是建立实时的动态容器画像,用过去一段时间窗口内容器资源使用情况的统计数据作为对未来一小段时间内的预测,并且动态更新;最后基于这个动态的容器画像,执行小步快跑的资源调整策略,边走边看,尽力而为。

    总结与展望

    总结起来,我们的工作主要实现了以下几方面的收益:

    • 通过分时复用以及将不同优先级的容器(也就是在线和离线任务)混合部署,并且通过对容器资源限制的动态调整,保证了在线应用在不同负载情况下都能得到足够的资源,从而提高集群的综合资源利用率。
    • 通过对单机节点上的容器资源的智能动态调整,降低了应用之间的性能干扰,保障高优先级应用的性能稳定性
    • 各种资源调整策略通过 Daemonset 部署,可以自动地、智能地在节点上运行,减少人工干预,降低了运维的人力成本。

    展望未来,我们希望在以下几个方面加强和扩展我们的工作:

    • 闭环控制链路:前面已经提到,单机节点上由于缺乏全局信息,对于资源的调整有其局限性,只能尽力而为。未来,我们希望能够打通与 HPA 和 VPA 的通路,使单机节点和中心端联动进行资源调整,最大化弹性伸缩的收益。
    • 容器重新编排:即使是同一个应用,不同容器的负载和所处的物理环境也是动态变化的,单机上调整 pod 的资源,不一定能够满足动态的需求。我们希望单机上实时容器画像,能够为中心端提供更多的有效信息,帮助中心端的调度器作出更加智能的容器重编排决策。
    • 策略智能化:我们现在的资源调整策略仍然比较粗粒度,可以调整的资源也比较有限;后续我们希望让资源调整策略更加智能化,并且考虑到更多的资源,比如对磁盘和网络IO带宽的调整,提高资源调整的有效性。
    • 容器画像精细化:目前的容器画像也比较粗糙,仅仅依靠统计数据和线性预测;刻画容器性能的指标种类也比较局限。我们希望找到更加精确的、通用的、反映容器性能的指标,以便更加精细地刻画容器当前的状态和对不同资源的需求程度。
    • 查找干扰源:我们希望能找到在单机节点上找到行之有效的方案,来精准定位应用性能受损时的干扰源;这对策略智能化也有很大意义。

    Q & A

    **Q1:**直接修改 cgroup 容器一定会获得资源吗?
    **A1:**容器技术隔离的技术基础就是 cgroup 层面。在宿主机腾出足够资源的情况下,给 cgroup 设置更大的值可以获取更多的资源。同理,对于一般优先级不高的应用,设置较低的 cgroup 资源值就会达到抑制容器运行的效果。

    **Q2:**底层是如何区分在线和离线优先级的?
    **A2:**底层是无法自动获取谁是在线,谁是离线,或者谁的优先级高,谁的优先级低的。这个我们可以通过各种 Kubernetes 提供的扩展实现。最简单的是通过 label,Annotation 标识。当然通过扩展 QoS class 也是一种思路。社区版本的 QoS class设置太过于保守,给予用户发挥的空间不大。我们通过这些方面也进行了增强。在合适的时候或许会推向社区。自动感知是个方向,感知谁是干扰源,感知谁是某种资源型应用,这块我们还在研发中。做到真正的动态,肯定是具备自动感知的智能系统。

    Q3:“与社区版 Vertical-Pod-Autoscaler 不同,Policy engine 不主动驱逐腾挪容器,而是直接修改容器的 cgroup 文件”,想问一下,不主动驱逐的话,如果 Node 的资源达到上线了会怎么处理?
    **A3:**这是一个好问题。首先这里要先区分是哪种资源,如果是 CPU 型的,我们可以调整低优先级容器的 cgroup 下 cpu quota 的值,首先抑制低优先级的容器对于 CPU 的争抢。然后再适当上调高优先级容器的相关资源值。如果是内存型资源,这个不能直接去缩小低优先级容器的 cgroup 值,否则会造成 OOM,对于学习内存型资源的调整,我们会在其他分享中继续讨论。这个技术比较特殊。

    **Q4:**只修改 cgroup,怎么保证 K8s 对单个物理机能够分配更多的容器?
    **A4:**文字直播有了一定说明,容器的资源消耗并非是一成不变的,很多时候它们的资源消耗呈现潮汐现象,相同的资源条件下部署更多应用,完成更多作业就是达到资源利用的最大化的效果。资源出现超卖才是我们这个主题讨论的最大价值。

    **Q5:**也就是说,低优先级的容器,request 设置的比 limit 小很多,然后你们再动态的调整 cgroup?
    **A5:**在现有 QoS 场景下,你可以理解被调整的 Pod 都是 burstable 的。但是我们并不是直接调整 Pod 元数据的 limit 的值,而是调整 limit 在 cgroup 反映的值,这个值在资源竞争缓和的时候还会被调整回去的。我们并不建议单机的 cgroup 数据和 etcd 的中心数据割裂太久。如果长期偏离,我们会像 VPA 发出警报,联动 VPA 做调整。当然在容器运行的高峰期,任何重建容器的操作都是不明智的。

    **Q6:**整体的理解就是你们开始就让物理机超配了一定比例的 pod,然后通过策略动态调整容器的 cgroup 值?
    **A6:**如果资源完全是富足冗余的,这个动态调整也有一定意义。就是并非资源用满场景下,高优先级应用会被干扰,实际上,当主机的 CPU 达到一定比例,打个比方例如 50%,应用的时延就变大。为了完全确保高优先级应用的 SLO,牺牲低优先级的 CPU 正常运行也是有价值的。

    **Q7:**Policy engine 有没有考虑开源?
    **A7:**有计划进行开源,Policy engine 更多的是和自身的应用属性相关,电商应用或者大数据处理应用的策略都是不相同的,我们开源会首先开源框架和附带一些简单的策略,更多的策略可以用户自定义。

    **Q8:**我之前遇到的大部分应用都无法正确感知 cgroup 的配置,因此很多情况都需要在启动参数里面根据 cpu 或者 mem 设置参数,那么也就是说即使改变了 cgroup 对于他们来说都无效,那么使用场景也就有限了
    **A8:**限制容器的资源使用这个还是有价值的。限制低优先级应用本身也可以提升高优先级应用的 SLO,虽然效果没有那么明显。稳定性的考量同样也很重要。

    **Q9:**Policy engine 目前在阿里的使用如何?在生产上有多上的规模使用这种方式进行动态调整?是否和社区的 HPA VPA 配合使用?
    **A9: **Policy engine 在阿里某些集群已经使用。至于规模暂时无法透漏。涉及到很多组件之间的联动,社区的 HPA 和 VPA 目前都不太能满足我们的需求。因此阿里的 HPA 和 VPA 都是我们自行开发的,但是和社区的原理是一致的。阿里 HPA 的开源可以关注 Openkruise 社区。VPA 开源计划我这里还没有确切消息。

    **Q10:**当单机节点资源不足以提供容器扩容时,目前是否可以进行 HPA 或 VPA 扩容呢?
    **A10:**单机节点不足的时候,应用可以通过 HPA 进行增加副本应对。但是 VPA 如果选择原节点进行更新的话,是失败的。只能调度到其他资源丰富的节点。在流量陡升的场景下,重建容器未必能满足需求,很可能导致雪崩,即重建过程中,整个应用其他未升级的副本接受更多流量,OOM 掉,新启动的容器再瞬间被 OOM,所以重启容器需要慎重。快速扩容(HPA)或者快速提升高优先级资源,抑制低优先级容器资源的方式效果更明显。

    关注『阿里巴巴云原生』公众号,回复关键词“1010”,可获取本文 PPT

    “ 阿里巴巴云原生微信公众号(ID:Alicloudnative)关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术公众号。”

    展开全文
  • 文章目录一、资源管理概述资源管理功能资源分配方式计算机中物理资源与虚拟资源分析二、资源管理机制与策略资源分配机制---数据结构资源分配策略三、死锁死锁的定义死锁的起因条件解决死锁问题的策略预防死锁避免...

    一、资源管理概述

    资源管理功能

    • 资源数据结构的描述
    • 确定资源的分配原则
    • 实施资源分配与回收
    • 存取控制与安全保护

    资源分配方式

    静态分配:
    系统对作业一级采用资源静态分配方法。
    系统在调度作业时,根据作业所需资源进行分配;并在作业运行完毕时,收回所分配的全部资源。可能造成资源浪费。

    动态分配:
    系统对进程一级采用资源动态分配方法。
    系统在进程运行中,根据进程提出的资源需求,进行资源的动态分配和回收。

    计算机中物理资源与虚拟资源分析

    在这里插入图片描述

    二、资源管理机制与策略

    资源分配机制—数据结构

    1)资源描述器
    定义:描述各类资源的最小分配单位的数据结构称为资源描述器 rd(resource descriptor)
    内容:资源名、资源类型、最小分配单位的大小、地址、分配标志、描述器链接信息、存取权限、密级、存取时间 。
    2)资源信息块RIB(resource information block)
    定义: 描述某类资源的请求者、可用资源和该类资源分配程序等 必要信息的数据结构。
    内容:
    在这里插入图片描述

    资源分配策略

    1)分配原则:

    • 提高资源利用率;
    • 在合理的时间内使用所有用户都可以得到所需资源(不要出现饿死的情况)——公平;
    • 对独占资源实施互斥使用;
    • 防止因资源分配不当而引起的死锁;这些目标相互牵制,需要权衡。

    2)常用资源分配策略:

    • 先请求先服务 FCFS/FIFO: 每一个新产生的请求均排在队尾;当资源可用时,取队首元素,并满足其需要。
    • 优先调度: 对每一个进程指定一个优先级;每一个新产生的请求,按其优先级的高低插到相应的位置;
    • 针对设备特性的调度策略: 确定调度目标–>移臂调度–>旋转调度

    三、死锁

    死锁的定义

    一组并发进程彼此等待对方所拥有的资源,且这些并发进程在得到对方的资源之前不会释放自己所拥有的资源,从而造成无休止的等待而不能继续向前推进的状态,称为进程死锁,这一组进程就称为死锁进程。

    死锁的起因条件

    起因:

    • 系统资源不足
    • 进程推进顺序、速度不合理

    关于死锁的一些结论:

    • 参与死锁的进程最少是两个,即两个以上进程才会出现死锁;
    • 参与死锁的进程至少有两个已经占有资源;
    • 参与死锁的所有进程都在等待资源;
    • 参与死锁的进程是当前系统中所有进程的子集。

    注:如果死锁发生,会浪费大量系统资源,甚至导致系统崩溃。

    死锁产生的四个必要条件:

    • 互斥使用(资源独占): 一个资源每次只能给一个进程使用;
    • 不可强占(不可剥夺): 资源申请者不能强行从资源占有者手中夺取资源,资源只能由占有者自愿释放;
    • 请求和保持(部分分配,占有申请): 一个进程在申请新的资源的同时保持对原有资源的占有,是动态申请,动态分配。
    • 循环等待: 存在一个进程等待队列 {P1 , P2 , … , Pn}, 其中P1等待P2占有的资源,P2等待P3占有的资源,…,Pn等待P1占有的资源,形成一个进程等待环路。

    上述四个条件只要有一个不满足,就可排除死锁。但必要条件成立,系统未必一定发生死锁。

    解决死锁问题的策略

    解决死锁的方法有两类:
    1)不让死锁发生:

    • 静态策略:设计合适的资源分配算法,不让死锁发生
    • 动态策略:控制性分配资源-----死锁避免

    2)允许死锁发生:
    即发生后在解决死锁

    预防死锁

    在系统设计时,采用某种策略,限制并发进程对资源的请求,从而使得死锁的必要条件在系统执行的任何时间都不满足:打破死锁发生的四个必要条件之一。

    1)打破互斥条件
    互斥条件是由于设备本身特性决定的,不能简单地将其打破,只有通过改造设备特性来实现。
    2)破坏“不可剥夺”条件

    • 方案一:在允许进程动态申请资源(需要资源时才提出请求)前提下规定,一个进程在申请新的资源不能立即得到满足而变为等待状态之前,必须释放已占有的全部资源,若需要再重新申请。
    • 方案二:当一个进程申请的资源被其他进程占用时,可以通过OS抢占这一资源。

    这意味着进程已经占有的资源,在运行过程中可能会暂时释放,从而打破了不剥夺条件,适用于状态易于保存和恢复的资源。
    此方法实现比较复杂,延长进程的周转时间,增加系统开销,降低系统吞吐量。

    3)破坏“请求和保持”条件
    采用设备的预先静态分配法:即在进程开始运行前,预先分配给其所需的全部资源,若系统不能满足,则进程阻塞,直到系统满足其要求。打破了“请求和保持”条件。
    4)破坏“循环等待”条件
    采用资源有序使用法,系统将所有资源按类型进行线性排队,并赋予不同的序号,并且要求每个进程均应严格按照递增的次序请求资源,否则操作系统不予分配。

    避免死锁

    安全状态: 在现有的资源请求和使用状态下,如能使得系统内所有进程都能找到一种资源分配方式,使所需资源能满足,从而能正常运行。此时由系统中所有进程构成的序列P1,…,Pn,称为安全序列。
    安全序列: 如果对于每一个进程Pi(1≤i≤n),它以后尚需要的资源量不超过系统当前剩余资源量与所有进程Pj (j < i )当前占有资源量之和,系统处于安全状态。

    注:安全状态一定是没有死锁发生的。

    不安全状态: 不存在一个安全序列;只是可能会发生死锁,但不安全状态不一定就是死锁。

    银行家算法避免死锁:
    系统允许进程动态地申请资源,如果措施得当,可以使系统获得较为满意的系统性能。
    具体作法是:系统在分配资源过程中,根据资源的使用情况提前作出预测,若分配资源后系统处于安全态,就把资源分配给该进程,否则不分配,从而避免死锁的发生。
    死锁的避免与死锁的预防的区别在于:死锁的预防是严格地至少破坏死锁必要条件之一,使之不在系统中出现,而死锁的避免是不那么严格地限制必要条件的存在,目的是提高系统的资源利用率。

    死锁的检测与解除

    系统为进程分配资源时不采取任何措施,但提供了检测和解除死锁的手段。
    死锁的预防策略是非常保守的,通过限制访问资源和在进程上强加约束来解决死锁问题。死锁检测(deadlock detection)策略则完全相反,不限制资源访问或约束进程行为,OS周期性地执行一个算法检测死锁发生的四个必要条件。
    死锁检测:
    允许死锁发生,操作系统不断监视系统进展情况,判断死锁是否发生,一旦死锁发生则采取专门的措施,解除死锁并以最小的代价恢复操作系统运行。
    检测的时机:

    1. 每当进程请求资源时,就修改资源图,并检查是否构成环路条件,若有,则通过清除回路中的进程,使回路断开,破坏死锁。开销大,不常用;
    2. 周期性检测 (类似于银行家算法) :其策略是查找一个进程,使得可用资源可以满足该进程的资源请求,然后假设同意分配这些资源,让进程运行直到完成,再释放它的所有资源,然后寻找另一个可以满足资源请求的进程;
    3. 系统资源利用率下降时检测死锁。

    死锁的检测机制:

    • 每个进程和资源分配唯一编号
    • 设置资源分配表,记录进程与其占有资源的关系
    • 设置进程等待表,记录进程与要申请的资源之间的关系

    死锁的解除:

    • 重新启动
    • 进程退回:将死锁进程退回到前一个检查点,并重新从该检查点启动这些进程(需系统提供检查点和重新启动机制)。
    • 撤销进程::撤销死锁进程,将它们占有的资源分配给另一些死锁进程,直到死锁解除。
    • 剥夺资源:使用挂起/激活机制挂起一些进程,剥夺他们占有的资源给死锁进程,以解除死锁,待以后条件满足时再激活被挂起的进程。

    死锁相关知识小结:

    在这里插入图片描述

    展开全文
  • 内存分配策略和分配方法

    千次阅读 2018-04-23 16:29:15
    2)物理块的分配策略;3)物理块的分配算法。1、最小物理块数的确定-- 这里所说的最小物理块数,是指能保证进程正常运行所的最小物理块数。-- 当系统为进程分配的物理块数小于此值时,进程将无法运行。-- 进程应...
  • Yarn中资源调度模型及分配

    千次阅读 2020-08-24 21:44:17
    在YARN的资源分配过程中,其采用了双层资源调度模型: 在第一层中,ResourceManager中的资源调度器将资源分配给各个ApplicationMaster; 在第二层中,ApplicationMaster再进一步将资源分配给它内部的各个任务; ...
  • 资源分配与调度

    千次阅读 2019-12-31 19:07:29
    2、在“合理”时间内使所有顾客有获得所需资源的机会; 3、不可共享的资源实施互斥使用; 4、防止由资源分配不当而引起的死锁。 对资源的管理应包括以下几个方面: 1、资源管理的描述--数据结构 2、确定资源的...
  • 文章目录1 虚拟内存1.1 传统...OPT3.2 先进先出置换算法(FIFO)3.3 最近最久未使用置换算法(LRU)3.4 时钟置换算法(CLOCK)3.5 页面置换算法小结4 页面分配策略1.1 页面分配、置换策略 1 虚拟内存 在传统存储管理
  • 磁盘是可供多个进程共享的设备,当有多个进程都要求访问磁盘时,应采用一种最佳调度算法,以使各进程磁盘的平均访问时间最小。由于在访问磁盘的时间中,主要是寻道时间。因此: 磁盘调度算法的目标是使磁盘的平均...
  •     互斥:至少有一个资源必须属于非共享模式,即资源一次只能被一个进程使用;     占有并等待:进程自己有一部分资源,又想得到别人占有的资源;     非抢占:进程不能被抢占,即资源只能被进程在完成...
  • 内存分配策略和分配算法

    千次阅读 2016-06-22 12:13:29
    2)物理块的分配策略;3)物理块的分配算法。 1、最小物理块数的确定 -- 这里所说的最小物理块数,是指能保证进程正常运行所的最小物理块数。 -- 当系统为进程分配的物理块数小于此值时,进程将无法运行。 -- 进程...
  • 操作系统在系统设计时事先确定资源分配的算法,限制进程对资源的申请,从而保证不发生死锁。具体的做法是破坏产生死锁的四个必要条件之一。 在本章第一节第三部分中讨论了产生死锁的四个必要条件。如果设法使四个...
  • JVM篇·垃圾收集器与内存分配策略

    千次阅读 2021-06-17 13:42:36
    内存分配与回收策略 流程 把刚实例化出的对象放入Eden区from survior区,经过一次Minor GCC后进入to surivior区域,默认经过15次Minor GC会进入老年代; 原则 对象优先在Eden分配 大对象直接进入老年代 大对象:...
  • Java GC 机制与内存分配策略

    千次阅读 2016-11-10 00:00:07
    为什么我们要了解学习 GC 与内存分配呢? 在 JVM 自动内存管理机制的帮助下,不再需要为每一个new操作写配对的delete/free代码。但出现内存泄漏和溢出的问题时,如果不了解虚拟机是怎样使用内存的,那么排查错误将是...
  • 如果您更改安全设置和用户权限分配,则可能会导致客户端、服务和程序问题发生 适用于: Microsoft Windows Server 2003 Standard Edition (32-bit x86)Microsoft Windows Server 2003 Datacenter Edition (32-bit ...
  • 《操作系统》速成

    千次阅读 2022-03-23 11:30:17
    【P1申请R1,R2,后结束释放资源,P2再申请R1、R2,则无阻塞】 3)死锁产生的必要条件:死锁产生一定是因为4个条件,但4个条件不一定产生死锁 互斥条件:进程要求分配资源(如打印机)进行排他性控制,即在一段...
  • 08.第九章.人力资源管理

    千次阅读 2022-02-02 08:50:25
    文章目录9.1项目人力资源管理概念9.2项目人力资源管理过程9.3项目人力资源管理工具9.4项目人力资源管理文件 9.1项目人力资源管理概念 1、领导“人”、管理“事” 领导者-设定目标、带人; 管理者-率众实现目标、做事...
  • Unity资源管理(四)-AssetBundle使用模式 参考文献:https://unity3d.com/cn/learn/tutorials/topics/best-practices/assetbundle-usage-patterns 本系列的前几篇文章讲述了AssetBundle的基本原理,包括几种...
  • 策略模式: Bean的实例化的时候决定采用何种方式初始化bean实例(反射或者CGLIB动态字节码生成) AOP 核心概念 1、切面(aspect):类是物体特征的抽象,切面就是横切关注点的抽象 2、横切关注点:哪些方法...
  • 项目管理第九章项目资源管理

    千次阅读 2020-09-18 14:03:57
    项目资源管理:项目资源管理包括识别、获取和管理所需资源以成功完成项目的各个过程。实物资源包括设备、材料、设施和基本设施,而团队资源或人员指的是人力资源。其过程包括: 规划资源管理:定义如何估算、获取、...
  • 第3章 垃圾收集器与内存分配策略

    千次阅读 2013-11-17 11:26:56
    第3章 垃圾收集器与内存分配策略 本章主要内容 概述 对象已死? 垃圾收集算法 垃圾收集器 内存分配与回收策略 Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的高墙,墙外面的人想...
  • 计算hash的方法不一样,hashtable是直接用hashcode,而hashmap使用了key的高16位和低16位做异或运算 Linkedhashmap继承于hashmap,可以顺序读取,底层使用的是双向链表 TreeMap实现了sortmap接口,可以元素进行...
  • 死锁的四个必要条件以及处理策略

    千次阅读 2022-04-10 11:56:32
    死锁是指两个或两个以上的进程(线程)在运行过程中因争夺资源而造成的一种僵局。 例如,某计算机系统中只有一台打印机和一台输入设备,进程P1正占用输入设备,同时又提出使用打印机的请求,但此时打印机正被进程P2...
  • nginx负载均衡的5种策略及原理

    万次阅读 多人点赞 2018-08-08 11:58:51
    每个请求时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。  upstream backserver {  server 192.168.0.14;  server 192.168.0.15;  } 2、指定权重 指定轮询几率,weight和访问比率成...
  • 我发现呀,这大家面试题的需求还是很大的,这里总结了上千道知识点,能换您一个收藏吗
  • 全面了解风控策略体系

    万次阅读 多人点赞 2020-06-28 14:09:48
    模型和策略的开发是一个系统工程,这其中需要有业务经验、统计理论、算法运用、和数据认知,是一个不断反思,不断积累经验的过程。沙滩上建不起摩天大楼。扎扎实实的基本功永远有价值,永远不会过时。
  • 牛逼!Java 从入门到精通,超全汇总版

    万次阅读 多人点赞 2021-05-06 19:40:33
    除此以外,本书在必要时还 Java 语言的功能进行补充说明,以加深读者 Java 的理解,在学习设计模式的同时也在复习 Java。 上面这两本书非常适合初学者学习设计模式 设计模式 这本书结合设计实作例从面向对象的...
  • JVM初探- 内存分配、GC原理与垃圾收集器

    万次阅读 多人点赞 2016-12-30 20:45:21
    JVM初探- 内存分配、GC原理与垃圾收集器 JVM内存的分配与回收大致可分为如下4个步骤: ...VM内存分配策略: 对象内存主要分配在新生代Eden区, 如果启用了本地线程分配缓冲, 则优先在TLAB上分配, 少数情况能会直接分配在
  • 等级保护测评策略建议整改措施

    万次阅读 2019-05-25 10:50:18
    修改配置策略: 1、查看控制面板—管理工具—本地安全策略—账户策略—密码策略; 2、查看控制面板—管理工具—计算机管理—系统工具—本地用户和组—用户—右键—属性—是否勾选“密码永不过期”。 建议修改值: ...
  • 操作系统中的进程调度策略有哪几种

    万次阅读 多人点赞 2018-09-22 09:00:39
    当在作业调度中采用该算法时,每次调度都是从后备作业队列中选择一个或多个最先进入该队列的作业,将它们调入内存,为它们分配资源、创建进程,然后放入就绪队列。在进程调度中采用FCFS算法时,则每次调度是从就绪...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 69,890
精华内容 27,956
热门标签
关键字:

对资源采用按需分配的策略