取消
搜索历史
热搜词
原创
活动
创新2.0
I T
产业
当前位置:首页 >互联网•IT > 互联网+ > 互联网化 > 正文
云原生系统的智能化管理之讨论
来源:腾讯网  作者:佚名 2020-11-09 12:23:05
云原生系统中,以微服务构建的在线应用对响应延迟非常敏感,如何保障在线应用服务质量的同时提高系统资源利用率是云原生系统管理面临的大挑...

云原生系统中,以微服务构建的在线应用对响应延迟非常敏感,如何保障在线应用服务质量的同时提高系统资源利用率是云原生系统管理面临的大挑战,而自动策略生成及多层感知网等技术能在定程度上提升云原生系统的智能化管理水平。

1. 多层级交互型应用的自动整合策略生成方法:

针对多种负载混合部署到同一共享资源池上导致的竞争和干扰问题,深圳先进院团队从用户感知的尾延迟(tail latency)角度研究了多层交互式工作负载的整合调度问题,提出了一种新型的基于轮廓分析(profiling)的整合方法,可以满足尾延迟的要求,同时减少使用的物理机数量。为了实现这一目标,首先在私有KVM虚拟化集群中对不同配置下的整合性能进行测试,以建立经验性能值,同时考虑影响多层工作负载尾延迟的两个关键因素:混部负载的干扰以及负载层间的交互。该方法将多层工作负载的整合建模为具有不同目标和约束的优化问题,并自动生成具体的整合策略。实验表明,与不进行轮廓分析的方法相比,该方法能够把尾延迟降低到原来的1/6,同时与不考虑层间交互的方法相比,该方法能够把尾延迟降低到原来的43%。

2. 基于多层感知网的资源智能调整机制:

混合部署带来的性能波动归根结底是混部应用无序共享底层硬件资源造成的,由于多级共享资源造成应用性能干扰成因复杂,计算所团队尝试引入多层感知网模型,建立各类资源实时使用状态、共享应用运行状态、系统整体环境状态等因素与当前监控在线应用性能之间的关系。当应用性能发生波动时,可以通过多层感知网模型追溯造成当前性能波动的因素,如果是应用自身的因素,则认为波动是正常的,当追溯到系统环境中的其他因素时,则该因素被认定为造成性能干扰的关键瓶颈资源,进而对该应用在关键瓶颈资源上进行隔离保护,保障应用的服务质量。实验结果表明,随着共享应用的不断增加,该方法可以使在线应用平均延迟和尾延迟均保持稳定,比无序竞争场景的尾延迟降低了66.7%~80%,尾延迟性能波动从1.53%~130.53%降低到了3.15%~9.51%,同时能够维持较高的资源利用率。

可靠性对于云原生系统来说非常重要。由于大量的在线业务运行在云原生系统上,如果不及时处理故障,可能会造成严重的后果,甚至造成严重的经济损失。但实现这一目标并不容易,面临的主要挑战是:缺乏故障生成及注入工具集,系统规模庞大且结构复杂导致问题定位困难,已有监控工具对故障的可视化展示的程度弱等。

容器故障注入工具:

为了方便对云原生容器平台进行可靠性测试,深圳先进院团队提出了一个面向容器的故障注入框架,用于观察故障注入到容器后的性能表征。首先,我们基于容器平台开发了一个故障注入工具和四个典型的攻击程序,故障程序包括CPU攻击、内存攻击、磁盘攻击和网络攻击。故障注入的目的是模拟容器的异常行为。我们分析了多个容器之间的故障行为,主要针对卷积神经网络(CNN)、递归神经网络(RNN)、双向递归神经网络(BRN)和动态递归神经网络(DRNN)等四种主流人工智能应用。实验结果表明,深圳先进院团队所提出的容器故障注入工具能有效地控制故障类型的选择、注入的位置、策略及持续时间,从而为故障行为分析和检测算法研究提供工具支持。

基于图推理的容器异常检测与定位算法:

数据中心的容器数量众多,同时上层应用结构复杂且相互依赖,使得对容器云的异常检测和定位非常困难。传统的检测模型通常采用CPU和内存使用率等系统资源指标,但很少考虑组件之间的关系,导致误报率较高。深圳先进院团队提出了一种新的基于图相似度的容器化云环境异常检测和根源定位方法ADGS:首先监控应用程序中每个组件的响应时间和资源使用情况,以确定系统状态是否正常;在此基础上,提出了一种基于图相似度的异常根源定位机制,并研究了异常在组件中的传播规律。基于Docker实际容器的实验评估表明,该方法能有效、准确地检测和确定异常的根本原因。

免责声明:本文系网络转载,版权归原作者所有。本文所用图片、文字如涉及作品版权问题,请联系删除!本文内容为原作者观点,并不代表本网站观点。
编辑:宋含怡
活动 直播间  | CIO智行社

分享到微信 ×

打开微信,点击底部的“发现”,
使用“扫一扫”即可将网页分享至朋友圈。

Baidu
map