物联网-云平台可靠性设计

这篇具有很好参考价值的文章主要介绍了物联网-云平台可靠性设计。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、云平台可靠性要求

        云平台的可靠性是其是否广泛应用的一个关键因素,也是用户选择云平台厂商的一个重要指标。用户对于物联网云平台可靠性主要从但不限于以下几个方面提供可靠性:

        【1】业务可靠性:主要考虑解决方案架构上物理容灾、计算/存储资源、计算和存储快照和恢复,网络服务冗余切换等,具备保障业务连续运行的能力。

        【2】管理可靠性:主要考虑告警、日志管理、配置管理、升级不中断业务管理以及在线无损扩容、分布式集群等功能,具备保障管理面业务冗余部署,单节点故障后快速恢复提供云平台管理服务的能力。

        【3】资源池可靠性:主要考虑节点HA、故障管理、负载均衡、流控、数据一致性、资源动态调度与热点消除、存储多路径访问、分布式事务机制、网络平面隔离等功能,具备保障数据不丢失的能力。

二、云平台高可靠性设计

        平台应采用冗余架构部署,包括基础云服务节点的高可靠(反亲和性),管理服务节点的高可靠以及数据库的高可靠部署。以保障在管理服务节点或者物理节点故障情况下,业务通过自身的高可用配置自动切换,保障管理面业务的高可用。平台提供告警上报机制,实现业务故障告警主动上报,关键业务故障秒级上报功能。

        2.1 云平台管理的高可靠性设计

        云平台管理可靠性主要包括服务部署、服务运行可靠性。各服务插件均为按照冗余部署的方式分布在不同的物理节点上,管理服务节点的可靠性通过多节点冗余以及服务节点的反亲和性,使各服务节点分布到不同的物理主机上,保证服务节点、服务插件以及硬件服务器故障情况下,服务通过自身冗余的设计完成节点倒换,保证管理面业务的连续性。

        【1】服务部署高可靠性设计

        建议采用Server、Client方式的二级架构模式及容器编排管理服务的方式,对服务部署、升级以及服务状态的全程监控。Client部署在每台服务器上,监控其部署的服务,当服务故障时将重新启动该服务。另外Client定期向Server发送心跳,当Server检测到Client的心跳丢失超过阈值,即判断Client所在服务器故障,通过虚拟机管理在其它服务器上重新启动故障服务器上的服务虚拟机。Server采用集群模式部署,通常部署在多台服务器上,可以通过选举出主Server。Client除了监控服务器运行状态,还提供主备仲裁服务。

        【2】服务高可靠性设计

        服务高可靠性主要指底层虚拟化平台对外提供服务功能的可靠性,主要包含以下几个部分:
        (1)Rest API服务可靠性,对用户提供不中断的API服务。
        (2)数据库服务可靠性,保证用户配置数据不丢失,服务不中断。
        (3)通讯服务可靠性,保证组件间交互正常不中断。
        底层服务平台中的服务采用冗余部署,采用采用热主备方式或双活方式,通过负载均衡方式提供服务。

        【3】数据库高可靠性设计

        数据库高可靠性设计,通过热冗余、数据库备份、流量控制技术为保证数据库的可用性和连续性。

        热冗余,健壮的数据服务支撑应用的无状态化,应用将状态数据外置到数据服务。数据服务热冗余双活,主备之间日志同步复制,支撑故障自动快速微损切换。搭建数据库集群代理服务,屏蔽数据库集群主备倒换。数据服务的IP地址、端口变化对应用不感知。代理服务无状态,支持在每个应用节点部署一个实例。或热主备设计,基于原生复制能力提供的热冗余保护。支持服务集群自动倒换、手动倒换。
        数据库备份,备份与恢复功能是保证系统在出现异常情况时,能够快速恢复正常运行的重要保证。数据库集群能支持数据库的备份与恢复,可通过客户端界面操作实现,通过维护界面,可以设置定期备份的周期和备份的路径。同时支持备份数据库到本地和远程服务器。
        流量控制,支持包大小和连接数的最大控制。若超过处理能力,则丢弃数据包,以保证服务正常运行。

        2.2 资源池高可靠性设计

        云平台资源池一般由计算资源池、网络资源池和存储资源池组成,并通过云管理平台虚拟化后统一进行资源调度管理,为客户提供稳定可靠的云资源。

        2.2.1 计算高可靠

        计算高可靠是为了应对客户计算资源池出现故障后,通过计算高可靠的能力将客户的计算业务VM自动或者手动的迁移到其他主机上,减少客户业务中断时间,提升客户业务的连续性。
        【1】虚拟机高可用

        当计算节点宕机或者虚拟机状态为error,系统可以将具有高可用属性的虚拟机故障迁移到其他健康的计算节点,保证虚拟机能够快速恢复,通过防群体和防传染的方案设计,控制虚拟主机的切换的规模和同一虚拟主机的次数,保障业务连续。

        计算节点的Client定期向集群内的Server发送心跳,当心跳丢失超过阈值后,Server通知虚拟机管理模块,转化为事件触发,在其它正常计算节点上快速恢复故障节点上的虚拟机。
        虚拟机高可用管理模块周期检测虚拟机状态,当检测到虚拟机状态异常时,转化为事件触发,在其它正常计算节点上快速恢复故障节点上的虚拟机。并通过锁机制防止同一个虚拟机实例在多个计算主机上同时启动。
        【2】虚拟机热迁移

        为保证虚拟机的可用性,规避业务中断的风险,系统提供虚拟机热迁移能力,即虚拟机在不中断业务的情况下实现迁移。虚拟机迁移时,管理系统会在迁移的目的端创建该虚拟机的完整镜像,在源端和目的端进行同步。同步的内容包括内存,寄存器状态,堆栈状态,虚拟CPU状态,存储以及所有虚拟硬件的动态信息。在迁移过程中,为保证内存的同步,虚拟机管理器提供了内存数据的快速复制技术,从而保证了在不中断业务的情况下将虚拟机迁移到目标主机。同时,通过共享存储保证了虚拟机迁移前后持久化数据不变。

        1.降低客户的业务运行成本:根据时间段的不同,客户的服务器会在一定时间内处于相对空闲状态,此时若将多台物理机上的业务迁移到少量或者一台物理机上运行,而将没有运行业务的物理机关闭,就可以降低客户的业务运行成本,同时达到了节能减排的作用。
        2.保证客户系统的高可靠性:如果某台物理机运行状态出现异常,在进一步恶化之前将该物理机上运行的业务迁移到正常运行的物理机上,就可以为客户提供高可用性的系统。
        3.硬件在线升级:当客户需要对物理机硬件进行升级时,可先将该物理机上的所有虚拟机迁移出去,之后对物理机进行升级,升级完成再将所有虚拟机迁移回来,从而实现在不中断业务运行的情况下对硬件进行升级,保证服务的持续可用性。
        虚拟机热迁移典型操作场景:
        1.根据需要按照迁移目的手动把虚拟机迁移到空闲的物理服务器;
        2.根据资源利用情况将虚拟机批量迁移到空闲的物理服务器。

        【3】虚拟机故障检测

        当虚拟机本身发生故障虚拟机出现异常挂死的情况时,系统能够检测并本地重启尝试恢复。

        1.虚拟机具备看门狗特性,为虚拟机提供了一种心跳检测机制,用于监控虚拟机内部系统的健康状况。当虚拟机运行过程中或者启动过程中操作系统内部卡死,检测模块上报虚拟机软件狗喂狗超时事件到控制中心上报告警,同时调用硬重启虚拟机进行恢复。
        2.控制中心对虚拟机内部异常事件进行监听,当虚拟机内部发生异常时,由虚拟机内部的检测模块捕捉到虚拟机异常事件,上报给控制中心,其故障检测应达到秒级。
        3.QEMU进程故障,虚拟机不可用,系统支持秒级检测,故障后虚拟机自动本地快速重启,恢复并上报告警。

        2.2.2 网络高可靠性设计

        网络的规划设计主要满足隔离、冗余和符合分担确保解决方案提供的网络服务能力的高可用、高带宽。
        【1】网络分平面通信
        系统通信平面逻辑上可以分为四类平面:管理平面、存储平面、业务平面和I智能平台管理接口(IPMI)平面。其中:
        管理平面网络:用于承载业务节点之间的API/RPC消息流量。
        业务平面网络:用于承载虚拟机业务数据。
        存储平面网络:用于承载存储平面内的存储数据互连。
        智能平台管理接口平面:用于承载服务器硬件管理消息。
        为了保证各种网络平面数据的可靠和安全,云计算平台要采用多网络平面的架构方案,不同平面间采用VLAN进行隔离,单个平面的故障不影响其他平面继续工作。例如当管理平面暂时故障时,业务平面还能够用于继续访问虚拟机。此外,系统还支持基于VLAN的优先级设定,使得内部的管理/控制报文具备最高的权限,出现拥塞时,管理员和用户均可以管控系统。

        在服务器内部,可通过对多个网卡的合理绑定和分类,允许将管理、业务和存储平面部署在不同物理网卡上,并将其连接到不同的接入层交换设备接口上,从而实现物理层面的网络隔离。

        【2】网络路径冗余

        网络按照层次划分,可以分为核心层、接入层和虚拟网络层。
        核心层交换设备主要完成各数据中心之间的通信互联,同时提供云计算中心对外网络出口。核心交换机保证对外和对内各数据中心核心交换机连接的冗余。
        接入交换机位负责本单元或机柜内部的服务器接入,保证对外与核心层交换设备和对内虚拟网络层连接的冗余。
        虚拟网络层位于服务器内部,负责服务器内部的虚拟机之间以及对外通信功能。通过采用多网卡绑定,避免单个网卡故障引发的业务中断。

        【3】网卡负荷分担

       对于物理服务器提供的多块网卡,出于可靠性以及流量负载均衡的考虑,系统采用了Bond模式,网卡被绑定成逻辑上的“一块网卡”同步一起工作,对服务器的访问流量被均衡分担到多块网卡上,减少每块网卡的负载压力,提高整体并发访问的能力,保证了服务器访问的稳定。同时当一个网口发生故障的时候,另外的网卡无缝接管全部负载,服务流量不会中断。避免单个网卡或者链路故障引发的业务中断。

        服务器绑定多网卡的实际意义在于当系统采用绑定多网卡形成一个虚拟网口之后,不仅可以扩大服务器网络进出口带宽,而且可以实现有效负载均衡和提高可靠性。

        【4】虚拟路由冗余保护

        虚拟路由冗余协议(VRRP,Virtual Router Redundancy Protocol),是一种容错协议。该协议通过把几台路由设备联合组成一台虚拟的路由设备,使用一定的机制保证当主机的下一跳交换机出现故障时,及时将业务切换到其它交换机,从而保持通讯的连续性和可靠性。

        VRRP 将局域网的一组路由设备构成一个VRRP 备份组,相当于一台虚拟路由器。局域网内的主机只需要知道这个虚拟路由器的IP 地址,并不需知道具体某台设备的IP 地址,将网络内主机的缺省网关设置为该虚拟路由器的IP 地址,主机就可以利用该虚拟网关与外部网络进行通信。

        VRRP 将该虚拟路由器动态关联到承担传输业务的物理设备上,当该设备出现故障时,再次选择新设备来接替业务传输工作,整个过程对用户完全透明,实现了内部网络和外部网络不间断通信。

        2.2.3 存储高可靠性设计

        高可用的存储资源的使用,应提供多路径访问、数据存储的冗余设计,确保数据的可用性和持久性。
        【1】存储多路径访问
        计算节点支持存储资源模块的冗余部署,其上虚拟机通过标准协议访问存储系统,并通过多块网卡的负荷分担技术、交换机的堆叠和集群技术提供存储路径的物理冗余。

        存储节点使用协议通信时的多路径访问流程,任意一个虚拟机对所挂载的任意一个虚拟卷,都将至少有两个完全冗余的路径来实现卷的多路径访问,并通过多路径软件来实现访问多路径的控制和故障切换,从而避免单点故障带来的系统可靠性问题。

        【2】数据强一致性
        强一致性复制协议可保证多个副本数据的一致性,即只有当所有副本都写成功,才返回写入磁盘成功。正常情况下平台要保证每个副本上的数据都是完全一致,从任一副本读到的数据都是相同的。如果某个副本中的某个磁盘短暂故障,平台可以暂时不写这个副本,等恢复后再恢复该副本上的数据;如果磁盘长时间或者永久故障,平台要把这个磁盘从群集中移除掉,并为副本寻找新的副本磁盘,再通过重建机制使得数据在各个磁盘上的分布均匀。

      2.3 业务高可靠性设计

        不少服务故障,是由于业务自身设计或者编码不当导致。理想情况下,每个服务都独立打包和部署,服务之间天然就支持进程级隔离,但事实上,对于一个云计算平台,通常是由成百上千个服务组成的,在实践中,各服务通常是不可能做到百分之百独立部署的,因此需要做以下设计:

        【1】同一业务域的服务往往打包和部署在一起,而不是每个服务独立打包部署。
        【2】海量的服务进程会增加部署、数据采集(性能KPI和日志等)、告警、问题定位等成本,需要构建高程度的运维自动化能力支撑大规模的服务自动化部署。
        【3】一些业务对时延非常敏感,如果该业务链上的所有服务调用都跨网络通信,时延往往无法满足业务要求。通过将服务合设在同一个进程之内,利用路由短路,把RPC调用转化成本地方法调用,可以极大的提升性能。
        【4】简化分布式事务处理,分布式部署之后,会带来分布式事务问题。有时候业务为了简化分布式事务的处理,将事务相关的服务部署在同一个进程中,把分布式事务转换成本地事务,简化事务处理。

        【5】不同的服务合设在同一个进程之中,就会引入一系列潜在的故障点,需要注意服务设计时,解决服务依赖问题:因为处理较慢的服务会阻塞其它服务;在某个服务发生故障蔓延,可能导致整个进程不可用;同时也要防止低优先级的服务抢占高优先级服务的资源的业务逻辑。

        在服务运维管理时,通过分布式日志采集系统、告警系统、性能KPI数据采集等,利用在线数据实时分析技术,对服务状态按照周期进行实时诊断,在服务发生异常时,可及时对服务进行降级、熔断等处置,并同时服务资源调度管理模块。文章来源地址https://www.toymoban.com/news/detail-789965.html

到了这里,关于物联网-云平台可靠性设计的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 系统架构设计师教程(十)软件可靠性基础知识

    软件架构的演化是为了适应用户需求、业务环境和运行环境的变化,它涵盖了软件架构的全生命周期,包括需求获取、建模、文档、实现和维护等阶段。软件架构的演化的重要性体现在以下几个方面: 保障软件系统质量:软件架构支撑整个软件系统,决定其性能、可靠性、安

    2024年01月18日
    浏览(65)
  • 系统架构设计高级技能 · 软件可靠性分析与设计(三)【系统架构设计师】

    系统架构设计高级技能 · 软件架构概念、架构风格、ABSD、架构复用、DSSA(一)【系统架构设计师】 系统架构设计高级技能 · 系统质量属性与架构评估(二)【系统架构设计师】 系统架构设计高级技能 · 软件可靠性分析与设计(三)【系统架构设计师】 现在的一切都是为

    2024年02月13日
    浏览(48)
  • 用户界面设计和评估:如何设计具有吸引力、易用性和可靠性的用户界面?

    作者:禅与计算机程序设计艺术 用户界面(User Interface)是一个给用户提供服务或者产品的系统界面,通过人机交互、信息呈现、文字表达、图形符号等表现形式进行沟通,帮助用户更好的使用产品或服务。它对于提升企业的品牌影响力、增加客户黏性、改善用户体验、降低

    2024年02月13日
    浏览(41)
  • 【可靠性测试】什么是可靠性测试:定义、方法和工具

    可靠性定义为在特定环境中指定时间段内无故障软件运行的概率。 执行可靠性测试是为了确保软件是可靠的,它满足其目的,在给定的环境中指定的时间量,并能够呈现无故障运行。 在这个机械化的世界里,现在人们盲目地相信任何软件。无论软件系统显示出什么结果,人

    2024年02月05日
    浏览(43)
  • TCP如何保证可靠性,TCP如何实现可靠性传输的

    tcp 如何保证可靠性 大家都知道TCP是可靠性传输协议,既然是可靠的,就需要解决比如包丢失了、数据被破坏了、包重复了、乱序了等等这样的问题。下面将从几个方面介绍TCP的可靠性。 1. 校验和 TCP每一段报文都有校验和,这保证了报文不被破坏或篡改,如果收到的报文在校

    2024年02月10日
    浏览(51)
  • 嵌入式硬件电路可靠性的关键问题的分析(可靠性介绍)

    :失效率 温度 可靠性 降额 器件工艺 质量与可靠性的区别 质量:时间点上去衡量                                              可靠性:一段时间上才能衡量,需要有量才能去衡量(大部分是产品量产之后才会出现问题) 质量:在时间点上衡量

    2024年03月24日
    浏览(48)
  • 配电网可靠性评估(4)—(顶刊复现)基于线性规划的配电网可靠性评估

            之前的博客中介绍了配电网可靠性评估的三种方法、分别是解析法中的最小路法,以及序贯蒙特卡罗模拟法及非序贯蒙特卡洛模拟法,顺带提到了含有分布式电源的配电网可靠性评估方法。 配电网可靠性评估(一)最小路法和非序贯蒙特卡洛模拟法 配电网可靠性评

    2024年02月08日
    浏览(53)
  • RabbitMQ --- 消息可靠性

    消息队列在使用过程中,面临着很多实际问题需要思考:      消息从发送,到消费者接收,会经理多个过程: 其中的每一步都可能导致消息丢失,常见的丢失原因包括: 发送时丢失: 生产者发送的消息未送达exchange 消息到达exchange后未到达queue MQ宕机,queue将消息丢失 co

    2024年02月14日
    浏览(50)
  • 可靠性测试

    我们认为软件可靠性始终是重要的,但它对于任务关键型、安全关键型和高使用率系统是必不可少的。如您所料,可靠性测试可用于降低可靠性问题的风险。可靠性故障背后的常见问题包括内存泄漏、磁盘碎片和耗尽、间歇性基础设施问题以及超时值低于可行值。 可靠性定义

    2024年02月16日
    浏览(49)
  • SpringAMQP开启“可靠性”机制

    上一篇介绍了如何在 《SpringBoot 中集成和使用消息队列》,看过这一篇就基本上可以在SpringBoot中使用消息队列了,但是消息队列他归根结底是一个客户端服务器模式的中间件,面对复杂的网络环境和分布式使用环境,难免会出现各种问题。出现问题不可怕,重点在于如何预防

    2024年02月21日
    浏览(50)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包