大家好很高兴能够今天在这里与大家分享华为中端云服务使用云烟生技术的大规模生产实践华为的中端云服务实际上是华为智能中端设备的大脑它为各类的中端服务去提供云端的支持这里面的服务包括了像我们熟悉的智慧办公智慧出行 运动健康等等让用户可以享受到更安全辨解的数字的生活体验总体上来说 华为中端云上所运行的业务是非常地丰富多样的这里面有像微服务 中间键等类型的应用也有像事件驱动 函数类的应用以及像AI大数据等等的离线分析以及批量计算类的应用而这些不同的应用聚合在一个平台上去运行呈现出了非常多样化的流量和压力的变化的特点其中像电商的促销包括像早晚高峰的一些出行类的业务它的流量往往是可预测 可提前感知的那么对于一些合作伙伴的一些运动推广活动以及包括一些突发事件等等它的流量就变得不可预测那么在这样的两种的特点之上对于整个平台来说其实业务的可用性 可靠性是最受关注的对于一些关键的核心业务为了保证它的可用性所做出的资源荣誉在多的时候甚至超过了100%而结合到成本的视角来看其实这显然有很大的一个改进空间因此如何去基于云烟深的技术提供一个强大的弹性的算力平台就变得非常的重要它可以屏蔽业务对于底层的云资源的感知让业务团队更好的去聚焦本身的业务的开发由于时间关系这里我挑选了三个优化点与大家进行分享首先是隔离边界的选择在中端云服务发展的前几年为了快速地去迭代上线许多的业务都采用了烟葱式的架构时间一长这样的管理就变得十分地复杂而且其中的韵文成本也在持续的升高对于各个业务的资源池由于它的割裂弹性的能力也比较弱往往也需要去额外规划预留的资源来去补偿可用性的考虑这样的话针对中端云的组织价格和它的业务的划分的特点我们进行了一些印射上的刷新首先是根据各个部门的业务的特点将部门印射到VPC用VPC的相对强的网络的隔离来去区分不同的业务之间的网络第二个是在各个部门之中将它们的一些业务特别是一些关键的业务去独占一个Copinatis集群而对于一些其他的相关性非常强的一些业务可以去共享一个集群在这样的一些业务的系统中还有一些微服的部件其实我们给用户采用的是基于VPC的容器网络的方案基于VPC对于所有的微服的部件它可以直接地使用到VPC的IP那么也可以直接使用到非常经典的Security Group来控制各个微服之间的互通以及包括这些微服和其他的云资源云服的互通这样它的管理就变得非常容易通过这样的多层次的安全区域的划分我们提供了相对来说更细腻度的访问的控制那么可以让用户在尽可能地去共享业务之间的资源的同时避免网络上的一些安全的隐患第二个时间我想与大家分享的是如何去应对突发的流量构建极致的弹性的能力正如前面提到其实中端的业务具有非常多的一些流量的变化和压力变化的一个特点那对于这样的一个弹性的能力构建来说主要地体现在三类的场景一个是流量突发的情况下我们需要端到端地去支持紧急扩容的能力那对于故障的场景我们需要能够支持大量的业务从一个AZ到另一个AZ的迁移以及对于一些非常有特点的一些业务需要去提供计划性的迁移扩容的一个支持针对这些需求其实我们知道它的主要的挑战或者说最关键的瓶颈点在于节点的创建它的速度和吞吐我们知道其实节点大量的使用形态是虚拟机虚拟机的创建是一个分钟级的速度而容器的创建是秒级的速度因此在遇到集群的资源不足的情况下业务的扩容就会降级也会最终导致业务被限流另一个可以做的优化点是集群之间的扩缩容行为的问题那么其实对于整个的全局的视角来说当多个集群分别去存在扩容和缩容的情况如果是传统的先扩后缩或者是让他们同步进行都会有一些或多或少的是整个资源时的分职消耗的挑战或者是耗时长的这些挑战那么经过以上的一些对于业务系统的分析和一些方案的比较我们最终选择了共享的预热节点资源池的方案对于每一个业务的集群来说它在业务压力高的时候它需要能够快速地从资源池中去取到节点来支持业务的能够维持在秒级的扩容的速度那么对于整体的流量较低的时候我们可以快速地将空闲的节点进行逻辑性的释放让它回入到资源池来维持整个资源池的一个大小当然这是一个逻辑上的流程在中端云的场景里为了极致的节点的快速地从池中取出和放回的实现我们将节点的释放实现为了关机的操作它的资源的让出实际上是由底层的S层来控制更多的是将CPU内存等等的资源进行释放而对于整个的磁盘的状态进行一个保留另外对称地从资源池中取出节点加回到集群其实我们实现为了开机的操作这样的话在整体上就可以获得一个相对来说更短的节点的扩缩容的时间实际上它的集群的状态是在一部分的节点从开机和关机状态之间进行转变同样地对于整个预热节点资源池的管理大小的控制在中端云的场景中我们实现为了对于全局的关机状态下的节点数量的管理第三个时间想跟大家分享的是关于资源的调度如何在避免业务互相干扰的前提下仅可能地去提升资源的分配率和利用率实际上应该说分配率是更多的从调度的视角就可以解决而利用率涉及到业务的运行中间的一些状态的实施的管理其实如果只看调度本身其实我们知道提高整个业务的部署密度是十分容易的比如像在Cobanitis EO的功能中通过调整Resource Request和Resource Limit两个值的大小以及他们的相互的关系就可以很容易地去提高资源的密度这看起来十分的美好因为在密度提高之后你的分配率的问题你的利用率的问题都得到了解决都被压满了但是很快你就会发现这些被调整的业务它的稳定性变得非常的差因为在里面技术上最关键的挑战是高压下的业务之间的资源使用上的一些隔离或者说其实我们真正要解决的还是业务的可用性的保证当然我们可以去为不同的业务引入优先级的定义至少在最差的情况下去保证高优先级的业务稳定可靠以及在这样的一些机制下我们还需要去兼顾地去考虑现在的多种类型的算力之间的平衡以避免像CPU被分配完或者内存被分配完而有一些昂贵的算力比如GPU有空闲或者反过来的情况针对这些考虑我们实际上的做法是采用了Vocano作为全局的统一的调度器Vocano的话它能够兼容到Cobanettis原生的所有的调度的功能特性同时支持使用Binpacking就是装箱的算法作为主要的策略这样的话可以在此基础上去叠加对于各个类型的资源的平衡的调度最大限度地去减少调度过程中的碎片问题来提高资源分配率对于一些资源利用率较高的一些集群其实我们还会帮助它去开启基于真实负载调度的策略我们知道其实Cobanettis它的默认的调度是基于Request也就是你声明的资源使用量这样的话开启了真实负载调度之后我们就可以去统计分析那些被申请而没有实际被使用的资源将它们分配给优先级低一些业务的部分去运行这样的话当优先级高的一些应用面临压力的时候我们还需要去借助操作系统层面增强的QRS的保障的机制让这些业务的实力快速地去获得它想要的资源实际上资源的互相之间的抢占更多的是发生在节点上对于调度器来说它主要是在全局做好调度的分配而对于一些有明显的压力波动特征的一些业务其实我们会对它做资源的基于一个时间尺度的画像来统计出它的不同的一些时间段的资源的消耗这样的话其实我们就可以做到在Covonadis现有只对调度时刻最优的这种策略之外的一个补充在一个时间的尺度上去考虑对于一些业务的压力在它的波动到来之前我们可以预先地去做出调整在前面的一些优化的基础上我们其实还借助Vocano引入了重调度的功能主要还是面向于资源碎片的最小化以及对于整个的资源的水位包括业务中的压力水位的理想值的一个控制作为整体的重调度的目标在重调度的过程中其实还有一个非常重要的是我们会去持续地监测用户定义的pod disruption budget以及包括pod的反清和高可用的这些配置来保证在碎片整理在重调度的过程中业务不受到太大的影响那么对于底层的这些资源的隔离其实刚才有简单地提到特别是在KOS的机制的保证方面我们是与操作系统的团队一起合作完成了一系列的优化包括CPU内存网络的IO以及像L3Cache等等的一些资源它的一些隔离以及强调的机制到目前为止其实华为中端语音的整个的资源利用率已经从先前来30%提升到了40%而资源的分配率也达到了87%对于弹性的扩缩人的能力其实一个很重要的改进是能够在集群的资源不足的情况下或者其他的一些场景基本上全天后的保持在每分钟超过2000个坡的这样的一个扩容的速度当然实际上对于一个平台来说它的能力构建特别是最终业务的一个运行的状态以及资源的利用率和成本和可用性之间的平衡是一个长期的话题中端语的话当前的业务的混合不足更多的还是在一些相似类型的或者说具有较多的共性的业务之间有一个不同的优先级的定义和资源的共享后面我们其实还会借助Vocano提供整套的混布的能力去实现更多类型的业务的共资源池和混布包括将在线的业务和AI大数据等等的离线业务去共资源池最后我还想特别强调其实前面提到的相关的功能特别是资源调度混布包括优先级抢占等等的特性已经在Vocano的项目中提供了大家可以通过去获取社区最新的版本来进行试用和体验以上就是我议题分享的内容谢谢