容灾部署调研
背景
最初的调研需求:两地三中心,实际是一种容灾的方案
除了两地三中心,还有其他一些部署方案
本文在讨论 两地三中心方案时,也调研了其他一些容灾级别较弱、以及更强的方案
并分析了这些方案的问题
所有的部署方案,跟具体机器配置无关,因此忽略机器配置
补充关于物理方面的限制:
- 光的传播速度 为 30KM/s
- 同城机房物理距离:<= 50KM
- 异地机房物理距离: >= 500KM
理论上,同城机房的光传播延迟可以到 0.2毫秒左右,但考虑到机房间会部署多级的交换机,延迟也会增大
另外机器处理数据本身也要消耗一定的时间,所以 同城机房的处理延迟 大约为 1
毫秒
异地机房,如北京到上海,物理距离会增大 20倍,考虑到还会跨更多的交换机、核心路由,其处理延迟可能会达到50毫秒
容器部署会需要经过更多的网络协议处理,增加非业务端的处理时间
3级容灾方案
这种架构就是我们正常搭建的环境,单机房,一个master,多个slave
注意,在分布式模式下,可以有多个分片,也就是有多个 master
这种模式下,分布式、非分布式的可用性都 是一样的,受单机房限制
4级容灾方案
异地双机房
这种架构下,使用的是异步方式同步,可能会有 几秒甚至一分钟的延迟
当上海机房挂了之后,北京机房就没有最近这一分钟的数据了,由于缺少了数据,此时北京机房就不能支持写了,只能是只读模式
同城双机房
这种架构下,采用了 一主三从的模式
IDC 1 部署了主节点 + 一个从节点
IDC 2 部署了两个从节点
同IDC采用异步同步,跨IDC采用强同步
这种架构比 上面的 异步双机房 更好,当主 IDC 挂了之后,备IDC依然可以接受读写
同城双机房的问题
Zookeeper部署的问题
- 赤兔、 OSS等需要依赖ZK,来实现选主实现高可用,而ZK一般是采用3、5、7台这种部署方案
- 由于ZK本身也是需要高可用的,所以ZK本身也是需要 分别部署到两个IDC
- 假设部署3台ZK,主IDC一台,备IDC2台,这样当备IDC挂了之后,ZK就不可用了,从而也影响了整个集群
- 如果将ZK多数派部署到主IDC,那么当主IDC挂了之后,从IDC实际也没法用了
改进:
同城三机房, 部署 5台ZK, 机房1单独部署一台ZK,其他什么都不部署,机房1 本身也有其他业务,这台单独的ZK只是借用 机房1的一台机器
使用这种方式后,主IDC、备IDC任意一个挂掉后,都可以自动切换
写入性能问题
- 由于受网络条件限制,同城双机房的架构,强同步方式写入延迟为 1毫秒,那么这个集群的实际 TPC也就是1K
- 在这种情况下,就需要采用 分布式方式来部署,即部署多个分片
- 通过proxy写入到不同的分片,提供集群的并发写入能力,同时从更多的从节点,也可以提供读并发能力
- 并不是说,同城双机房就一定要采用分布式模式,只是因为受网络限制,这种架构的写入会有影响,因此采用分布式方式更好
多活
- 分布式部署下,分片1-master可以部署在IDC-1,分片-2-master可以部署在IDC-2,提供更高的写能力
- 客户端可以根据写入的key的id,直接写到IDC-1,或者IDC-2
- 比如IDC-1的master负责处理 a-m 开头的key,IDC-2负责处理 n-z开头的key
- 则写入 aaa会由IDC-1的master处理,xxx则由IDC-2的master处理
- proxy会根据分片的key,自动分到对应IDC的master
5级容灾方案
两地三中心方案
这种部署模式,就是我们最初调研的部署方案,这种部署方案满足了金融级可靠性
两地三中心的部署方式,可以认为是对 同城双机房的一个扩展
部署方式
- 同城两个机房 IDC-1、IDC-2,采用一主三从模式
- IDC-1一个主+一个从,IDC-2 两个从
- IDC3采用异步方式同步,数据会有一定的延迟
- 当IDC-1挂了之后,IDC-2会自动变为主
- 在这种部署方式下,IDC-1、IDC-2任意一个挂掉,都可以自动切换
- 在这种部署方式下,IDC-1、IDC-2同时挂掉,依然可以提供读服务,即IDC-3,不过最近一分钟的数据可能会丢失
两地三中心的问题
这种方案的问题是,当IDC-1、IDC-2任意一个挂掉后,ZK的性能会有影响
假设 IDC-1部署2台ZK、IDC-2部署2台ZK、IDC-3部署1台ZK
当 IDC-2挂掉后,ZK仍然存有多数派,可以提供服务,但此时读、写就需要跨异地机房了,这个延迟就会比较高
改进,将异地机房的 ZK,挪到一个新的同城机房 1中,这样可以解决延迟问题
两地三中心的 同城机房在写入时,也是受到网络限制,TPS不会很高
因此,也最好部署分布式模式
更高级别的容灾方案
其他还有,五地七中心