金融行业双活数据中心架构设计最佳实践

金融行业双活数据中心架构设计最佳实践一、 存储双活方面1、跨中心的双活存储数据一致性如何保障？一方面，当写入数据时，在复制过程中，数据传递是在缓存中进行的，这样做的好处是提升了性能，问题是当出现控制器节点异常宕机事件时，就会导致缓存内的数据不能写入存储中，从而造成数据的不一致，这时有没有保障单个存储数据一致性的措施？另外一方面， 两个站点的存储之间的数据一致性，从缓存层、底层数据层又是如何保障的？答：第一个问题：前端节点写缓存与后端存储间的数据一致性如何保障？存储跨中心双活中的单个存储架构分为三种：1.物理存储的内部双控制器比如 V5000/V7000/V9000 HYPERSWAP，写存储的操作也就是写缓存的过程，写了一个控制器，控制器也会将缓存数据同步至另一控制器的缓存，只有当真正同步完，这次的写操作才算完成，当写缓存达到水位线后，会将写缓存刷入到磁盘组中，当一个控制器异常宕机时， IO HANG 住一小段时间，另一控制器将接管，缓存数据也不会因此丢失，一致性得到保障； 单控制器时，写缓存被禁止，之前的缓存被刷入后端存储，即使这时这个控制器也异常宕机， 后端磁盘的数据完整性和一致性也得到了保障；如果不幸两个控制器的电源同时断电了，这时写缓存数据还未及时刷入磁盘组，不用怕，几乎所有存储都会考虑到这一点，都有专门的电池模块维持供电几分钟，保证缓存数据能够顺利落到磁盘组当中。2.物理存储+存储虚拟化网关（有写缓存）比如 SVC ESC/HYPERSWAP，NETAPP MCC（叫写日志），这种架构也就是相当于在物理存储前端又加了一道控制器，也存在写缓存，相当于扩大了后端物理存储的缓存容量，写操作 要先写入 SVC 节点，再同步至另一 SVC 节点，只有完全同步成功，才算做是一个完整的写周期，后面的操作也是等待写缓存达到水位线刷后端存储。佑了这种机制的保障，存储虚拟化 网关的缓存与后端物理存储的数据完整性和一致性得到保障，无论是单 SVC 节点故障，另一节点缓存数据冗余，写缓存被禁止，所有缓存刷入后端存储，还是 SVC 的电源断电，SVC 有专门的 UPS 供电模块保障写缓存及时刷入后端存储，都能完整的保障数据的完整性和一致性。这里不再赘述。3.物理存储+存储虚拟化网关（无写缓存）比如 EMC VPLEX METRO，它只有读缓存，写缓存还是由后端的物理存储提供，所以该问题还是和前面说的类似的保障机制。第二个问题：两个站点的双活存储间的数据一致性如何保障？这里分两种方式来阐述这个问题：1.一种是两个站点的主机识别的是相同的 VOLUME比如：SVC ESC、EMC VPLEX、HDS GAD 等，两个站点的主机对这一个 VOLUME 写操作时， 数据被刷入两个镜像的后端存储，这有两个存储都写完成返回，才算一个完整的缓存刷后端存储的写周期，这时两个存储从数据块角度来说，是一致的，一个站点或者存储故障，另一个站点的存储是可以接管，而不会造成数据丢失。2.另一种是两个站点的主机识别的是不同的 VOLUME比如：SVC V7000/V5000 HYPERSWAP、NET APP MCC 等，由于两个站点的主机识别的不是同一个 VOLUME，必然存在存储或者存储虚拟化网关的 VOLUME 与 VOLUME 的同步复制技术，HYPERSWAP 有 METRO MIRROR，MCC 有 Syncmirror，它们的技术共同点是复制技术的一致性校验机制，更高级的有以多个卷为单位的卷组一致性校验机制，来保障跨站点的两个卷/卷组的一致性，在某站点所有控制器或者站点完全故障时，另一站点有完整的、一致的存储可以接管。2、存储跨中心双活是块存储的同步，无法避免逻辑错误被同步，出现该问题又该如何防范？ 数据同步逻辑错误问题：存储层面的复制技术基本以存储块为单位进行的数据复制，假设数据块发生了逻辑错误，那么存储是无法检测到的，它会继续将坏的数据块儿同步到灾备端，如果因此数据库发生宕机，那么灾备端的数据库也同样无法正常启动。答：这是一个很典型的问题，块存储如何防范逻辑错误。做了存储的跨中心的双活或者做了存储的镜像，同步复制，很容易就会觉得数据有两份甚至多份一致性的副本，就会觉得万事大吉，甚至觉得不需要备份系统了。数据备份系统是企业数据安全的最后一道防线，无论做了什么同步、异步、双活还是连续性数据保护，数据备份系统都应该作为一个最稳固可靠的基础的存在，地位无法替代。回到问题来，基于存储的复制技术，无论复制方式是同步、异步、双活还是连续性数据保护， 都是基于存储数据块级别的复制技术，复制源端在可读时，会将块中的数据原样的拷贝一份至目标端，当源端数据出现误删、误改、磁区退化数据异变、数据库事物层逻辑错误等数据逻辑性错误时，复制目标端无法检测到这些错误，依旧复制“错误”的数据，导致两份副本都无法正常使用的灾难。所以我们要有多层次的防范机制，来保障数据的可靠性和安全性，存储双活技术只是其中的一个层次，要辅以备份技术、数据库复制技术，连续性数据保护，建立了完善的数据保障体系。（1）备份系统按照一定的时间频率对数据库做全量和增量备份，在遇到数据逻辑错误时， 通过恢复将数据回退到最后一个备份版本。如 TSM、NBU、COMMVAULT。（2）数据库复制技术有实时同步、准同步、异步等方式，保障主数据库逻辑错误无法正常运行时，切至备数据库，回退到备库前一个日志 COMMIT 后的版本。如 DB2 HADR、ORACLE ADG、MYSQL 主从复制等。（3）连续性数据保护技术也是准/实时对存储数据块做快照，源端数据无法继续使用时，通过快照回退至前一个数据可用版本。如 CDP。通常为了考虑不影响源端数据的访问性能或者单个系统无法满足需求时，可以考虑多种方式结合，比如备份系统在备份超大数据库时，没有充足的带宽或者备份时间窗口，可以用数据库的异步复制方式来做为备份方式的补充；连续性数据保护技术需要通过 LVM 镜像源端数据，增加了写延迟，可以通过数据库准实时同步或者异步的方式复制数据到备库节点，备库节点的后端存储为连续性数据保护的存储节点，如 DB2 HADR+CDP 的组合。所以总结来看，存储跨中心双活并不是万能的，依旧需要传统的数据保障技术辅助，建立常态高效的数据保障体系，才能应对万难。3、两个中心光纤距离 10KM，租用运营商的 DWDM，线路的稳定性依赖运营商？如何向运营商提出要求？答：链路冗余度方面：通常我们企业做双活，都是自己购买波分设备，然后租用运营商的裸光纤，作为通讯的链路。所以波分设备需要冗余，裸光纤也要冗余，波分设备好办，购买即可。裸光纤通常租用两家或两家以上的运营商线路，比如电信和联通，电信的裸光纤也需要冗余，联通的裸光纤也需要冗余，防止单根裸光纤意外割断或者损坏。然而单家运营商的裸纤都通常在一个弱点井中，一起意外割断的事情常有，所以需要两家运营商互相冗余。这两家运营商裸纤的路线还不能一致，弱电井需要在不同的街道，并且分别走不同的路线到达目的地。所以可以看到，由于我们是租用，根本不可能要求运营商完全达到你的要求，最好的方式只能自建，成本太高，好像根本不现实。链路质量方面：链路质量包括光衰、抖动和带宽等。一方面，光衰和抖动无法控制，只能靠波分设备去探测，发现光衰和抖动，立即中断该链路，切向备链路，这对后端的 SAN 网络无感知，但对波分设备的要求很高，需要购买和建设时注意。至于带宽，可以监测，达到带宽预警阈值后，可向运营商申请提升带宽。另一方面，对于链路质量的监测机制一定要在建设存储双活或者其他双活之前建立，由于是运营商的链路，链路经过了多少中继、多少设备我们是不得知的，我们只能在波分端建立有效的监测机制，有些波分设备也有专门的监控软件支持。而且也要要求和运营商建立监测联动机制，运营商监测到链路质量（是质量而不是中断）有问题，也需要第一时间告知，做出合理的决策。4、想了解谁有 infiniband 下的存储双活的经验答：目前，支持 Infiniband 的存储设备很少，支持双活功能的就更少。Infiniband 用在 HPC 领域的并行数据访问的环境中比较多，如在航空航天、石油勘探、汽车设计等，为了保证数据访问的高性能和低时延，利用 IBM Spectrum Scale （GPFS）+ Infiniband 构建大型并行文件系统的案例很多。并且，IBM 的 Spectrum Scale 也支持基于 IP 网络的跨数据中心的双活功能，在银行和电信运营商都有实际案例。5、 FC 模式下，时延太高，长距会有问题，对 oracle RAC 支持有问题答：在存储双活环境中，对两个数据中心之间 SAN 网络的时延要求比较严格，所以，一般最佳实践都建议两个数据中心的距离不能太远，尽管理论上和少数专有环境中（如 IBM 大型主机+IBM DS8000）可以支持高达 100-300KM 的距离，但一般建议不超过 3050 公里，并且是裸光纤或者 DWDM 环境。6、 小同城大异地模式，异地集群有什么好的思路不？文件共享如何实现，应用时候有必要着手从传统 nas、gpfs 向对象存储的改造答：跨中心的文件共享，除非是只基于 LAN 而非 WLAN，由于 NAS 对 WLAN 的支持不够好和稳定，否则建议采用集群并行文件系统方式或者对象存储方式来实现文件的共享。例如，IBM 的 Spectrum Scale（GPFS）具有 AFM（活动文件管理，Active File Management） 功能，支持多中心的数据共享和文件访问，并且支持 WLAN 的环境，还能够实现多中心的数据灾备和双活。IBM 的对象存储 COS（Cloud Object Storage）支持三中心部署模式，支持 WLAN 环境，只需要付出大约 60%的冗余度（即存储 100TB 的数据，只需要大约 160TB 的物理容量），就可以实现防止站点级别的灾难。二、 应用双活方面1、单应用双活本身不难，但难在如何解决应用间跨中心穿插交互的问题，如何解决该问题？答：关于这个问题，有以下四种应对策略来解决该问题：1、尽量减少跨中心应用间交互2、两个数据中心重要业务系统间尽量解耦合，各成体系，独立运作3、允许必要的跨中心互联，如非双活数据库、核心、只能主备模式的系统的访问4、链路加强监控及链路波动/中断后的应急机制2、如何实现双中心之间的文件数据同步,包括联机交易和批处理数据？ 答：对于跨中心的文件数据共享，可按需求分类考虑：1、有数据共享需求，而且对 IO 性能要求较高的，只能用 SAN 存储双活方式2、对 IO 性能要求一般的，可以采用共享文件系统实现，如 GPFS SERVER+CLIENT，NFS Server+Client 或者双活 NAS 等3、对 IO 性能要求较低的，属于海量非结构化数据共享的，可以尝试用跨中心的对象存储实现三、 数据库双活方面1、 双活仲裁机制：存储双活与 DB 协同仲裁的机制与原理？答：假设定位到存储双活，那么是不是就割裂了数据库层的仲裁问题。实际上存储最终是为上层数据库及应用服务，如果这个跨中心的架构涉及到数据库、存储两层的组合，比如说存储双活之上是 oracle rac，那么就比较复杂了。首先对于存储本身的仲裁，应该有自己的算法，例如：（1）仲裁站点，获取了仲裁站点的投票的一方获胜（2）最坏情况下，默认的算法（3）偏好仲裁模式，偏好设定仲裁获胜的站点 对于跨中心的 rac 集群，同样有自己的规则：（1）仲裁盘（2）通过网络和磁盘心跳保证获得票数最多的子集活着。（3）实例 ID 小的节点存活。但是当存储双活和数据库双活二者结合的时候，就有更复杂的场景可