数据中心双活该如何构建

思考的牛

功能介绍 分析和交流ICT行业最前沿技术，分享更多存储、服务器、数据中心、网络、软件定义和虚拟化等相关知识，旨在知识交流、开放共享和共同进步。

在今天文章开始之前，首先感谢大家的支持，从昨天大数据时代下数据重删的考虑和投票来看，虽然只有一部分读者参与了赞赏和投票，但就是由于这些力量的支持，才推动我们公众平台不断改进和成长。赞赏不是最终目的，希望昨天的投票大家都能参与并提出宝贵意见。

因为最近经常看到大家在讨论数据中心双活解决方案，所以今天把前期大家的疑问和问题进行汇总，加上我个人的见解写成一篇比较全面的文章，分享出来供大家参考。由于工作原因，可能今后近一个月的时间不能给及时大家写文章了，但是前期跟大家承诺的国内云厂商分析和昨天的投票情况，会在这段时间过后尽快呈现给大家。

双活本身其实有广义和狭义之分，但是在数据中心这个前提下，我们所说的双活就是广义上的应用、网络、存储和数据的端到端的数据中心双活，顾名思义，应用、网络、存储都应该是双活状态，当然在项目部署和实施过程中，技术上支持部分处于双活或HA状态、部分是单点状态，只是这种方式会使整体方案的双活能力大打折扣。下面是一个典型的数据中心双活组网图。更明确的说，这是个基于阵列双活组网图。

数据中心A和B之间采用网络互联，数据中心内采用传统两层或三层组网方式互联，接入层链接业务服务器、核心/汇聚层通过大二层互通技术链接到对端数据中心。大二层互联技术一方面主要解决VM在不断业务的情况下在数据中心之间在线迁移，MAC地址不变故而业务不断；另一方面解决VLAN个数的限制，在成千上万的服务器的数据中心中，为了保证数据安全和网络隔离，传统VLAN是不行的。图上大二层采用CSS+iStack方式实现，当然大二层网络的实现方式各个网络厂商各不一样，但是Trill的实现方式基本每个厂商都会支持。

存储、交换机和服务器通过专门的SAN网络互联，基本都是采用冗余组网。两个数据中心的交换机通过FC互联，注意是FC而不一定非是光纤，采用FC协议的原因就是其高效率和可靠性。这个链路是用来存储之间实时同步两端数据的，当然，存储之间集群的心跳也通过该网络完成。

服务器集群，准确的说应该是应用集群之间数据的同步，是通过大二层网络完成的，目前企业比较常见的集群应用是VMware、Hyper-V、Oracle RAC、SQL MSCS/MSFC，IBM DB2/PureScale等等，其中Oracle RAC和PureScale是Active Active集群。应用之间的心跳也是通过该网络实现。

从图上我们看到了第三方仲裁，该仲裁其实是存储集群的仲裁服务器或仲裁存储，目前支持仲裁服务器的厂商比较多，因为成本低，而且还可以在仲裁服务器中安装虚拟机，在VM之间进行HA提高可靠性；当然也有厂商采用存储，EMC在VMAX3双活中甚至采用VMAX3做仲裁，一套配置几块磁盘的高端是有些奢华，但是EMC就是喜欢玩高大上，个人觉得现在EMC屈身到DELL之后，这个策略可能要变。

然而第三方仲裁也在技术上不一定非要放在第三个站点，虽然很多客户是没有第三个数据中心、也不愿租用第三方数据中心。很多厂商也提供优先存活站点策略，在有些情况下，如果第三方仲裁失效，我们也可以通过优先存储站点来提高业务，但是如果运气不好，优先存活站点发生故障，后果很严重。所以第三方站点仲裁更保险。

此外，服务器应用集群之间也是需要仲裁的，但这个仲裁如何配置是跟应用的要求强相关的。仲裁链路一般情况下不要求非要大二层互通，只需要IP三层可达即可。

然而我们每个用户对双活数据中心资源访问的访问，一般是通过Internet完成，要经过服务器本地缓存、Global NDS、DNS解析定位到资源，当然为了保证负载均衡，数据中心会部署GSLB和SLB来保证每次方案都能负载均衡到相应的数据中心、相应的服务器上。GSLB和SLB之间实时同步两个数据中心IP资源情况，通过HA或本地优先方案的策略实现资源访问IP分配；当然，在DNS阶段可以对两个数据中心同时解析，把RTT时间较小IP返回给用户，用过那这个IP访问资源。

由于篇幅有限，改组网的细节我不打算讲的很细，后面有机会再跟大家分享。接下来我们看看基于网管的双活方案。如下图，对你没看错，这个就是华为基于VIS存储网管的双活解决方案组网图。

网管的双活和存储双活的区别，一方面在于在组网上增加了硬件设备，这无疑增加了成本、同时网关的故障会引起业务切换或业务中断，相当于增加了整个方案故障点，另一方面网关的引入会可能会成为性能的瓶颈，解决该问题的方案就是增加网管集群的节点个数，还好Vplex、SVC和VIS都支持多节点集群扩展。

还有个区别是网关双活一般需要承担存储故障后的业务切换，承担数据两个数据中心间同步工作，所以网关双活可以缓解存储性能压力。网关层双活不需要多路径进行过多支持，网关节点间通过卷镜像的方式进行数据同步。

双活基本技术条件有两个，一是数据实时副本，当一端的数据破环或无法访问时，可以通过另一份完全一样的副本来提高服务；另一个就是服务器、存储、网络等集群的自动切换和恢复。只要满足这两个条件，理论上就可以实现数据中心双活，所以基于应用层也可以实现应用层双活。

基于应用层的双活方案目前有OracleRAC、IBMGPFS、SymantecSVC和PowerHAHyperSwap等。华为VIS可以实现双活，当然Symantec SVC也可以，只是一个基于网管而一个基于应用层；PowerHAHyperSwap配合DS8000存储复制技术的双活请参考浅析PowerHA HyperSwap双活方案。下面是IBM GPFS双活方案。

IBM GPFS双活方案采用IO Failure Group技术进行数据副本保护，采用GPFS Active Active集群实现故障切换和恢复。基于应用层的双活方案目前应用不多，主要原因是基于应用服务器创建卷镜像、基于服务器同步数据、基于服务器故障切换对应用影响太大，所以在存储技术比较泛的情况下，客户更见容易接受基于存储或网管的方案。

然而目前我们看到的数据中心双活方案基本上都是基于SAN块存储，主要的原因是SAN存储的业务一般都是对性能、可靠性要求比较高的应用，如数据库、ERP、SAP等等，所以SAN双活方案应用比较广泛、支持SAN存储的双活方案厂商比较多；但是技术永远不是问题，NetApp的FAS和IBM的GPFS却具备NAS双活方案的能力，主要的原因是很多数据库，如OracleRAC和IBMPureScale支持数据库直接部署在NAS之上。

双活方案是灾备要求中级别要求最高的方案，所以双活方案的部署是有一些必要的要求。接下来我们详细讨论下。

双活方案对距离要求，由于双活数据采用双写机制保障数据强一致性，所以一般应用可接受的距离是同hu城100-300KM之间，虽然应用对IO延时和超时可以设置，但是我们还得考虑用户体验。数据同步链路一般采用FC交换机级联，当两数据中心直线距离大于30KM以后，需要DWDM波分等设备来对光信号进行中继，色散补偿。一般DWDM波分设备最大支持3000KM距离。

双活方案对网络要求，网络时延、带宽、误码率都会影响双活方案。由于两个数据中心数据实时复制，所以链路网络带宽必须高于高峰IO访问时的带宽；网络时延会影响整个应用系统业务响应；误码率会影响网络的利用率，误码率越高就意味着数据需要被重传，从而形象整个网络。

双活方案对性能要求，双活应该无疑对性能是有很高要求的，所以要求两个数据中心的存储、服务器等系统都应该是对等的，否则任何一方如果成为性能瓶颈都将影响另外数据中心。在网关双活方案中，还有考虑网关不要成为性能瓶颈。

所谓的真双活（ActiveAtive）和伪双活（ActivePassive），很多厂商讲的真双活就是两个数据中心存储上的一对镜像LUN设备，可以同时在两个数据中心接收来自一个集群应用的读写IO，数据的一致性需要存储双活集群和应用集群来保证。实际上这跟存储和应用类型关系很大，要求存储双活和应用双活都支持真双活才有意义。如果存储支持真双活，而应用是VMware（并非Active Active集群），那整个方案也只能是Active Passive模式。

双活方案和多路径，基于存储的双活一般都需要多路径来完成在数据中心间的切换，所以一般双活方案提供商都会自己开发多路径进行一些优化。VMware就提供了PSA接口让存储厂商实现自己多路径模块，让厂商对存储方案路径和IO进行优化。然而专有多路径也并非是必须的，存储厂商也可以采用系统原生多路径实现双活，只是效果差而已。如Xenserver，Citrix没有类似VMware的PSA接口，所以无法支持第三方多路径，自带多路径Mutipath可以支持ALUA，只需要阵列也支持ALUA，也可以做到路径优化。

最后跟大家提一点，数据中心双活是指应用、网络、存储和数据的端到端的双活，那基于应用还能不能再创建应用集群呢，答案是肯定的。例如在服务器上基于VMware集群还可以在VMware的VM上创建Oracle RAC或是SOL MSCS集群应用。今天就到此为止，如果大家对双活感兴趣，请多多支持，我会抽时间跟大讨论更详细的双活技术。