在这个问题上,风险发生的引发点有两个:数据库和集群的仲裁触发以及仲裁过程的时间顺序发生紊乱;资源被1:1割裂之后的默认仲裁策略不一致。也就是说,只要控制这两个引发点,那么这个问题从理论上也就避免了。对于第一个引发点来讲,实际上存储集群的默认仲裁触发时间会是15秒左右,而数据库仲裁触发的控制参数由misscount这个参数来决定,所以只要我们将misscount这个参数调整到45秒之后,也就是说理论上绝对保障存储集群仲裁在前,而数据库仲裁在后,那么第一个引发点就没有了。对于第二个引发点来讲,假设两站点节点资源对等,仲裁选票同样对等的情况下,存储集群会有一个默认的Winner策略,同样在这种情况下数据库集群也有一个默认仲裁策略:选择实例号小的集群存活。只要我们保证这两个策略结果的一致性,那么第二个引发点也就不存在了。
这个问题是两种架构都面临的问题。主要表现为两个方面:链路稳定状况不可控;延时指标不可控。因为双中心之间的链路是通过租用运营商的裸光纤链路实现的,那么这其中会经历很多的中继设备及节点。无论从管理上还是从技术把控上都是金融企业自身不可控制的因素。假设双中心间链路延时指标不稳定,也就是说数据库节点之间私网传输的延时会经常出现长延时情况,这势必导致这种延时会加倍放大到数据库节点之间的读写热点竞争上。由于数据库集群之间的数据传输量非常大(缓存、锁、心跳等),在读写热点相对突出的业务上,轻则导致数据库读写性能灾难,重则导致数据库节点直接处于僵死状态。另外,链路的不稳定会导致存储链路频繁切换,甚至会导致集群仲裁频繁发生,这对于业务连续性更是一个灾难。
对于这个问题来讲,就目前金融行业的传统数据架构来讲,并没有一个十足的解决方案。我们只能通过以下措施来减少这种问题带给我们的风险。
一、业务层面需要进行拆分重组:按照IO特点进行合理拆分,将读写业务尽量分布于不同节点上,减少节点间的锁竞争。按照业务将数据库表进行分区,避免在数据库写上的数据热点块儿。例如,对于银行核心系统来讲,尤其是要将批量业务和联机业务区分对待,批量业务的热点以及数据量非常之巨大,所以一定要将批量业务的数据库读写放在单边实现。对于联机业务来讲可以根据热点状况以及链路质量评测结果可以尝试实现双中心同时读写,但是本文建议对于这种重量级的业务还是要从业务层尽量实现应用上的读写分离,或者在应用层双中心部署而在数据库层将数据引到单边来做。
二、双中心间通讯的整体控制,具体包括对通讯带宽的优先级管理、对通讯的实时监控和控制、对跨中心数据传输的严格策略把控。例如:优先保障存储和数据库通讯的优先级和带宽,严格的规则算法和优先级限定VMOTION、DRS等行为的跨中心随意性,从LTM负载分发上尽可能保障正常情况下纵向IO的单中心效率策略,故障情况下保障跨中心访问的科学性。DWDM上设置双中心间通讯带宽的逻辑隔离以及实时可控。
这是两种架构都会面临的问题,只是架构一可能性相对高一些。
如果我们把两个中心的SAN环境整合为一张大网,物理上没有任何隔离的大网,那么可能会因为局部的存储网络故障而波及到整个存储网络。尽管我们通过SAN交换机上的逻辑隔离能够解决大部分的安全问题,但是这样的风险毕竟还是存在的。
所以我们可以通过对数据中心内部SAN环境前后物理隔离,双中心之间靠专一SAN交换机实现存储后端网络的联通来解决该问题。这样的话,单中心内前段SAN环境故障不会波及存储后端,更不会波及整个基础架构的存储网络。
这个问题是针对架构二的问题。
架构深度越深,那么IO的性能就会越差,因为IO每经过一层设备就会有一定的延时消耗,纵向深度越深经历的设备越多,那么IO的延时也就越高。如果我们的架构在纵向上越复杂,那么这个问题应该说从本质上是无法消除的,只能通过一定的方法来减少和优化。
从存储层来看,一般存储侧在对物理卷进行虚拟化的时候都会有几种策略。为了增加管理的灵活性及扩展性,虚拟化的时候可能会经过多层映射。另外一种策略是为了提高性能,在虚拟化的时候尽量较少映射。我们在规划存储卷的时候,尽量采用后一种策略。例如VPLEX就会有(1:1map、Raid等策略),我们可以选择1:1map这种策略,仅仅利用它的镜像聚合,而舍弃它的灵活伸缩特性。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞18
添加新评论5 条评论
2020-06-03 07:33
2019-11-14 15:44
2018-11-28 18:47
2018-09-27 20:38
2018-09-04 09:07