大家好我是大白,我们在上一篇边缘技术之深信服边缘云计算平台SIEP第二篇中在综合层面所进行的深信服边缘云计算产品的特色优势等介绍,本篇文章我们将通过技术层面进行“解剖”深信服边缘云计算的管理协同与物联协同。
上一篇我们提到了边缘云计算的多维云边协同能力:管理协同、物联协同、智能协同、安全协同,我们以技术的角度进一步了解深信服边缘云计算的技术创新突破。
管理协同【边缘云原生,实现软件定义的边缘能力】
应用场景:
边缘侧用户场景繁多且需求随时变化,需要厂商快速响应。
1)应用开发适配慢:云端应用的部分计算需操作要下沉到边缘执行,或边缘计算硬件规格不满足客户场景需求,传统应用需要频繁针对边缘运行环境(硬件、驱动、操作系统)重新适配,显著增加开发工作量
2)应用持续迭代难:一体机出厂后,客户使用过程中想更新软件功能(如替换算法、更新设备接入组件、修改业务代码等),传统做法中,厂商非软件bug一般无法支持
关键技术&价值特性:
从离线/嵌入式/专用边缘设备,升级为在线、通用的软件定义边缘计算节点——
1)边缘容器底座:应用与运行环境解耦,应用一次构建、到处运行 为客户应用隔离底层硬件复杂性,统一利用多种操作系统、arm/x86 CPU、算力芯片的能力 简化客户应用的边缘适配工作,帮助客户更快实现云边协同 容器间资源隔离,k8s编排实现更强的运行稳定性
2)云端镜像仓库:集成Harbor企业级镜像仓库,支持边缘应用全生命周期管理 能力灵活下发,响应客户需求,提供更多商业可能性 设备标准品发货,现场快速部署,简化交付实施
管理协同【云边双向运维通道】
应用场景:
边缘节点数量多、位置分散,需要持续监测应用运行情况,保障SLA。但在实际场景中往往会遇到困难:
1)网络架构复杂:边缘节点多位于本地专有网络中,与云端不在同一网络平面,云-边无法建立有效的网络通信链路,运维原生k8s运维APIs(logs/exec/metrics)失效,无法直接使用
2)故障根因难定位:市面上常见的边缘运维功能往往局限在查看设备在线状态、OTA升级、远程重启等表层,针对应用、操作系统乃至硬件层面的监控深度有限,出现故障后往往只能重启、刷机,难以定位根因
关键技术&价值特性:
深信服SIEP通过构建双向认证隧道,实现云端主动向边缘容器下发运维指令,边缘也可主动上报运维监控数据
1)云边双向运维通道:内置DNAT规则,定向转发云端节点请求,使得Prometheus 、metric server等运维组件可通过代理访问边缘节点,实现双向云边运维通道
2)通道安全加密:动态申请安全证书,确保中心集群与边缘节点实现安全通信
3)更深度的监测告警:客户可利用Prometheus、ELK Stack等业界主流云原生运维软件,快速实现全面的边缘运维监测、告警功能
管理协同【边缘自治】
应用场景:
云边网络连接常常不稳定,若将原生k8s直接应用于边缘计算场景,将会面临以下问题:
kubelet所管理的容器信息保存在节点内存中,当云边网络断连或节点重启时,内存信息清空,节点上的业务容器无法恢复。 云边网络长时间断连时,APIServer将对业务容器启动驱逐机制。 长时间断连,网络恢复之后,边缘与云端的数据一致性无法保障。
关键技术&价值特性:
深信服边缘计算平台基于原生k8s实现了边缘离线自治能力:
EdgeHub实现边缘节点与云端的通信代理,并且通过本地缓存机制,确保业务容器可持续获得运行所需信息。 云边网络断连,边缘节点不再同步云端管控指令,确保业务容器不被驱逐。 断网期间,边缘缓存数据不更新,网络恢复后,及时同步云端最新数据。
管理协同【应用可靠性保障】
应用场景:
传统架构下,应用之间耦合度高,单个组件的故障容易引发全局应用故障,应用的可靠性设计困难,难以针对应用提供有效的故障自愈机制,运维成本高,业务连续性无法保障。
原生docker虽然可以提供容器重启策略,但需要以容器进程异常退出作为触发条件,监测粒度较粗,难以覆盖应用假死、资源死锁等情况。
关键技术&价值特性:
平台提供细粒度的健康检查机制,支持为pod(应用)设置存活探针LivenessProbe,并按照自定义策略定期检查容器应用健康状态,实现应用故障自愈。探针检测方式支持以下容器中进程退出状态码检查、TCP端口检查、HTTP请求状态检查。
例如每隔10s,跟应用建立TCP连接或发送HTTP GET请求,如果TCP连接正常或HTTP响应状态码为200-400之间,则判定为健康,否则平台将会主动拉起容器应用。
平台采用声明式API,支持用户通过页面配置来自定义pod(应用)实例数,并实时监控pod状态,确保pod实例数与预设值保持一致,提高应用可靠性。
管理协同【应用滚动升级】
应用场景:
传统架构下,应用往往采用冷升级方式(关闭服务→更新应用→重启服务→服务上线),升级过程会导致业务中断,且升级效果依赖运维人员经验,难以保障
关键技术&价值特性:
平台支持滚动升级方式,根据边缘应用特点,可提供多种升级策略进行灵活匹配,例如先创建新应用,再删除旧应用。
升级期间可保障业务连续不中断,升级过程中即便出现云边网络抖动或断连,可在网络恢复之后,在已有基础上继续自动完成升级。
平台支持页面可视化一键操作升级,减少升级过程对运维人员的依赖,提高升级效率。
管理协同【配置参数注入与更新】
应用场景:
边缘节点数量多,边缘应用多具备敏态属性,配置参数需要根据不同环境进行变更。传统方式中,应用与配置参数耦合,修改参数需要重启应用来生效,业务连续性无法保障,且不灵活。
关键技术&价值特性:
应用与配置解耦,通过configmap或secret可实现配置参数灵活注入,提高业务扩展性。 configmap以数据卷形式挂载至容器应用,配置参数更新时,应用可自动感知,从而实现热更新。 secret加密配置参数,确保边缘应用的运行安全,例如针对数据库环境变量加密。
物联协同【基于物模型的端侧设备统一接入管理】
应用场景:
在开发AIoT应用时,客户应用开发人员往往需要查找具体设备的网络协议,对各厂家、各型号、各协议逐一适配。 不同项目上,前端设备的供应商经常变化,北向应用侧若去适配南向设备,会导致频繁改动、测试。 不同厂家的同类设备、不同设备的同类变量/功能,如何统一管理、获取数据、进行控制。
关键技术&价值特性:
通过物模型,对南向设备的属性、功能、数据进行抽象建模,转换为客户业务侧对设备的理解和定义。 对于任意接入的设备,关联物模型后,平台即按物模型的定义对设备进行管理和利用,应用不需要关注底层细节,如:1)设备的硬连接和鉴权,2)设备协议解析,3)设备点表对应。 应用侧通过边缘计算平台API获取物联能力,方便设备的统一管理、功能调用、参数配置,显著降低应用开发复杂度。
物联协同【边缘数据治理:业务友好,助力业务应用开发降本提效】
应用场景:
除了视频类数据外,物联网场景中存在大量时序类数据,需要进行采集、传输和计算。边缘侧的数据治理可使流向中心的数据干净有效,提升应用的开发效率、降低数据上云的传输存储成本。 常见的边缘侧数据治理操作包含降采样、数据去除杂点、补齐缺失、碰撞分析、字符类型转换等。
关键技术&价值特性:
边缘计算节点内置时序存储和计算引擎,能够高效的进行数据的写入、读取和聚合,用户具体业务场景所需的逻辑运算,都可通过实时计算或批量计算的方式,写入结果表,业务应用从MQ指定Topic下高效接收结果数据。
由于采用了同一数据库进行数据存取和计算,实现了边缘侧的数据零拷贝,效率比三方数据服务更高,并且也减轻了中心计算压力。使应用开发者能够专注于业务实现。
物联协同【云边规则引擎:边缘业务联动的核心模块--开发计划中】
应用场景:
边-端联动,边缘节点内各容器联动,边-云联动,都需要基于物联网数据采集、分析、治理得到的结果进行判断、执行相应规则。然而在具体项目上,常见的情况是懂业务的用户不懂编程,懂编程的人员不懂业务,导致常常见到专业系统功能不符合需求的情况。是否能让业务人员,以零代码的方式直接编辑边缘节点上执行的规则?
关键技术&价值特性:
和业界以云端为主的规则引擎不同,深信服边缘计算平台+边缘计算节点同时具有规则引擎,开发者可以零代码在云端配置规则应用并且下发到边缘侧,在边缘侧实现基于业务规则的事件响应和业务联动,并支持断网、弱网环境。
规则引擎支持零代码画板式的规则编写,不需要任何编程知识,方便现场业务人员将专业知识内化至边缘中,实现端-边、边-边、边-云的有机协同。
在许多场景下,云端应用以及边缘应用,需要根据边缘侧采集、分析与治理后的数据结果,进行相应业务逻辑操作,从而实现场景需求的闭环。例如在某栋大楼内部部署摄像头以及声光报警器,摄像头检测到异常事件之后,需要联动声光报警器进行预警。不同场景下,这个业务逻辑规则是多变的,如果客户直接以代码形式写死,灵活性差,开发成本高。
通过我司提供的云边规则引擎,可以对业务逻辑进行内化沉淀,实现事件响应和业务联动。同时规则引擎支持零代码画板式的规则编写,不需要任何编程知识,方便现场业务人员将专业知识内化至边缘中,大幅度降低开发成本。
如上就是在基于目前深信服边缘计算技术深信服边缘云计算的管理协同与物联协同的''解剖''。我们下一篇将针对深信服边缘计算的智能协同、安全协同在技术层面进行详细的介绍以及讲解,感谢大佬们的参阅,此贴先到这里后续会带上更加优质的帖子,感谢大家!!!
励志分享超清壁纸语句~~:
生活像一只看不见的储蓄罐,你投入的每一份努力都不会白费。把身体照顾好,把喜欢的事做好,把重要的人待好,与万事言和,与独处相安,自行,自醒,自清欢-
好的今天就到这里,老样子,感谢各位大神的参阅,孩子为了挣豆子不容易,孩子家里穷没豆子吃饭了!!!
|