006、高可用和联邦集群

原文地址

https://zhuanlan.zhihu.com/p/86763004

小规模高可用方法：

部署多个相同配置的server即可

架构图如下：

A和B配置完全一样，同时收集所要监控的所有数据

但是这种方法存在明显的弊端：

1、无法扩展

2、数据可能不一致

所以这种架构的使用场景是只适用小规模集群和短期的存储需求

小规模高可用方法之二：

用第三方tsdb来存储数据，作为server的后端

架构图如下：

A和B的配置一样，数据写入第三方存储，A挂了则启动B

相比第一种方法、这种架构有以下优点：

1、可以保证数据一致

2、数据可长期存储

3、server可以灵活迁移

但是实际工作的server同样是单点，数据量大的时候存在性能瓶颈

所以也只是适合小规模集群，只是可以做数据的长期存储

以上两点只支持小规模集群，如果面对大规模集群应该用什么方法呢？

联邦机制介绍

在开始之前我们先介绍一下prometheus的联邦机制：

Prometheus原生支持联邦架构，能够实现从别的prometheus来抓取符合特定条件的数据，简单的举个例子说明一下：

这段配置可以抓取目标prometheus中job为kubernetes开头的所有监控项

知道了联邦机制之后我们再继续讨论高可用架构问题：

单资料中心高可用架构

单资料中心意思是所有监控最终要汇总到一个节点上的

架构图如下：

如果我们的规模比较大，单台server有压力的话，可以用上图的方法来实现高可用，首先我们的serverA和serverB都分别收集一部分数据，然后serverC通过联邦机制，从A和B中抓取特定的需要持久保存的数据，写入第三方的存储落地

这种架构有以下优点：

1、资料能够被持久性保持在第三方存储系统中

2、能够依据不同任务进行层级划分

3、server可以灵活迁移

4、serverA和serverB可以用前面提到的方法进行高可用扩展

当然伴随而来的就是：

1、单一资料中心带来的单点(ServerC压力较大)

2、分层带来的配置复杂，维护成本较高

不过这种架构已经基本可以满足绝大部分公司的需求了，下面介绍一下我们线上的架构设计作为结尾：

我们线上的架构有着显著的特点，首先我们用了多套k8s集群，其次呢prometheuds对接了业务数据，业务数据和线上访问量成正比，数据量非常大，所以最终的设计架构如下：

这里分了两层，首先系统监控我们要做持久保存，然后业务数据做实时报警，没有这个需求，因此这个分开来做，防止互相影响，我们每个集群部署一套系统监控的server和一套业务监控的server同时所有指标分别打上cluster=1，cluster=2，cluster=3的标签，然后起一个系统汇总的server通过联邦机制收集需要汇总的系统指标，写入第三方存储来做持久话保存，同时起一个业务汇总的server收集需要汇总的业务指标，来做实时展示，因为没有持久话需求，所以没设置第三方存储。