监控系统Falcon服务高可用

监控系统解决了基本的业务需求后,开始逐步考虑自身的高可用问题。大体,可能会有如下三种演进阶段。Falcon目前正在向第二阶段演进。

第一阶段:集中式部署

监控系统的所有核心组件,都部署在一个中心IDC;区域IDC,通过Hbs-Proxy来同步配置信息,通过Transfer-Proxy来上报监控数据。如下图。

central.png

集中式部署,存在机房单点故障风险。为了防止中心机房故障,可以做双机房热备,此时资源消耗会double。

优点

  • 监控系统各组件易于部署,易于维护
  • 数据及状态信息集中存储在中心IDC,有利于UI展示、数据聚合等数据消费活动

缺点

  • 跨IDC传输数据时,数据丢失的风险高,监控服务可用性低(约99.95%)
  • 跨网传输监控数据,带宽成本高(监控占用了约30%的内网带宽)

第二阶段:报警高可用

监控的核心价值,在于及时发现故障,因此,需要保障报警链路的高可用。当业务对监控报警提出更高的可用性要求时,考虑将报警链路下放到区域IDC、消除跨IDC网络影响;历史数据存储、报警状态存储等等的状态信息,依然存储在中心IDC。部署架构,如下图。

alarm_ha.png

较之集中式部署,第二阶段,报警链路下放到了各个IDC,数据及状态信息仍然集中保存在中心IDC。部署架构上,监控报警链路和历史数据存储链路,完全分离。

优点

  • 报警链路本地化,实时报警的可用性提高1+个数量级
  • 数据及状态信息集中存储在中心IDC,有利于UI展示、数据聚合等数据消费活动

缺点

  • 部署变复杂,运维成本提升
  • 网络安全成本提高,跨网操作时,Proxy和RealServer之间需要ACL控制
  • 跨网传输监控数据,带宽成本高

如果不考虑带宽成本,第二阶段的部署架构已经可以满足业务需求,虽然这种架构看起来略微丑陋。

第三阶段:区域IDC自治

分IDC自治,将监控系统各组件均下放到各IDC,每个IDC都具有独立的监控能力,实时报警、历史数据的可用性均达到最高。在中心IDC,提供一个统一的Portal,对用户,屏蔽监控系统分IDC部署的细节。如下图, central.png

中心统一的Portal,无状态,可以较容易的实现高可用。用户在Portal的每次请求,可能会受到当时网络链路的影响,但不影响最终可用性

优点

  • 监控分区自治,报警和绘图的可用性,达到了理论上限
  • 数据分区存储、不跨网传输,节省了网络带宽

缺点

  • 分区部署完整的监控服务,部署和维护成本最高
  • 统一的Portal,需要耗费更多人力,来开发和维护

总结

以上三个阶段的部署演进,取决于如下业务特点:

  1. 公司内网可用性: 不可靠的跨IDC内网专线,不可靠的内网接入
  2. IDC与业务特点: 存在这样的场景,即某IDC接入内网的链路异常、但对外仍然可用
  3. 业务需求: 为获取少量的监控可用性提升(万分之一量级),愿意支付double、甚至triple的成本

网络环境业务需求成本(资源&运维&开发等),最终决定了监控系统的部署架构。特别的,网络环境是可以优化的环节;网络链路可用性的提升 可以节省大量的应用层成本,从公司层面来讲 是值得投入的。



Prev     Next