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

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

一、 存储双活方面
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 的距离，但一般建议不超过 30~50 公里，并且是裸光纤或者 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 小的节点存活。
但是当存储双活和数据库双活二者结合的时候，就有更复杂的场景可能会出现，尤其是出现两层架构仲裁的结果不一致。
为了避免这个结果出现，那么我们需要攻克以下问题：
1. 如何保障仲裁触发的时间序列一致。可以设定双活存储仲裁的超时时间小于数据库仲裁的超时时间，来保证双活数据库的仲裁是在双活存储仲裁完成之后进行，这是目前通用的做法。
2. 极端情况下的仲裁算法一致性。可以设定偏好模式保证数据库和存储仲裁的结果是一致的，如将 ORACLE 实例 ID 小的放在偏好的站点 A，存储双活仲裁设为偏好模式，保证仲裁结果基本在站点 A。

2、想咨询一下 db2 数据库更换存储（只更换存储）有什么好的方案及相关的操作步骤？

答：有对于数据库更换底层存储我们实践过多次，通常按照以下四种标准做法去做，都基本没什么问题：
1、方案一：操作系统层数据镜像技术，如 AIX LVM，步骤如下：
（1）映射闪存阵列的 LUN 至 AIX OS，并加入 VG
（2）将原传统阵列 LUN 和闪存阵列 LUN 做 LVM
（3）同步完成后，找停机窗口，从 VG 中拆除镜像，剔除原传统阵列 LUN
（4）重新激活 VG，并挂载数据文件系统，验证
2、方案二：数据库备份恢复和 OS 层面的克隆技术，如数据库：DB2 BACKUP/RESTORE，ORACLE
RMAN,OS 克隆：AIX ALT_DISK_COPY,VM SNAPSHOT,VM P/V to V 等，步骤如下：
（1）搭建新环境，该环境存储采用闪存阵列
（2）通过 OS 层面的克隆技术，将 OS 数据复制/迁移至新环境
（3）通过数据库层备份恢复，将数据库数据恢复至新环境，并验证
3、方案三：存储本身自带的 LUN 镜像技术，如 IBM V9000 等
（1）找停机窗口，将原传统阵列 LUN 映射至 V9000
（2）在 V9000 中，将原传统阵列 LUN 数据镜像（VDM）至 V9000LUN
（3）待镜像同步完成后，将两个 LUN 主备关系反转，闪存作为主存储，原传统阵列 LUN 作为备存储
（4）将两个 LUN 虚拟化后形成的 VDISK 映射至主机，验证，此时主机存在 V9000 和原传统阵列两份数据保护
4、方案四：存储虚拟化网关的 LUN 镜像技术，如 IBM SVC、EMC VPLEX 等
（1）找停机时间，取消原传统阵列 LUN 至主机的映射，将该 LUN 映射至虚拟化网关进行管理
（2）虚拟化网关将该 LUN（mdisk）虚拟化成虚拟 LUN（vdisk），并映射给主机
（3）创建 vdisk 的闪存阵列 LUN 镜像拷贝
（4）待拷贝完成后，将闪存阵列 LUN 置为主拷贝，原传统阵列 LUN 置为备拷贝
（5）验证

答：
1）在线更换存储方法：首先将新的存储设备接入现有的服务器，然后利用操作系统的裸设备的镜像功能（如 AIX 操作系统的 LV Mirror 功能），在线将 DB2 数据库的所有裸设备和数据全部镜像到新的存储，当新旧存储设备的数据全部镜像完毕达到同步时，将旧存储拆除， 完成存储更换。这个方法的好处是可以完全在线操作，基本不影响生产；不利的地方是需要考虑同一台服务器同时访问新旧存储的多路径软件的兼容性问题；还有就是一般情况下，大型数据库的裸设备（LV）都比较多，不能有任何遗漏。
2）准在线更换存储方法：可以考虑使用存储虚拟化设备，如 IBM 的 SVC，实现准在线的存储更换方法。首先将存储虚拟化设备 SVC 和新存储接入现有 DB2 数据库的 SAN 环境和服务器环境，并实现 SVC 对新存储的管理；然后选择恰当的时间，将 DB2 数据库停下，实现 SVC 对旧存储的管理，并通过 SVC 将旧存储中的 LUN 以 Image Mode 的形式映射给现有服务器， 服务器可以读写原有的 DB2 数据后，马上将 DB2 数据库重启，恢复业务。然后利用 SVC 的在线数据迁移功能（或者磁盘镜像功能，如 VDM），将数据在线迁移到新的存储设备中。当数据完全迁移完毕，就可以拆除旧存储。此方法的好处是迁移数据较快，没有存储多路径软件兼容性问题；不利的地方是需要短时间停止业务。

3）离线数据迁移方法：利用系统备份恢复（如 Backup/Restore）功能，或者备份软件（TSM，
NetBackup）,或者 DB2 的数据迁移工具（db2move）等，将 DB2 数据库的数据和环境进行备份，然后再恢复到新的存储设备。这个方法业务停顿时间很长，一般较少采用。

3、 数据库、存储双活的架构实现问题

答：目前，存储双活的架构主要有两种实现模式：一种是基于磁盘阵列的底层数据同步复制技术来实现，如 HDS 的 GAD，IBM 的 Hyperswap，NetApp 的 Metro Cluster 等；这种技术只能在同品牌、同型号的磁盘阵列之间实现，不支持异构存储平台。
另一种是基于存储虚拟化网关（引擎）来实现，如 IBM SVC（SAN Volume Controller）的Enhanced Stretch Cluster 和 Hyperswap，EMC VPLEX 的 Metro Cluster。由于基于虚拟化技术，除存储虚拟化网关以外，其它磁盘阵列可以是虚拟化网关支持的任何一种品牌、任何一种型号的磁盘阵列，具有更大的灵活性。
数据库是介于应用和系统之间的一个“中间件”，数据库的双活必须基于其它基础架构设施的双活才能实现，如网络必须双活、存储必须双活，可见，存储双活是数据库双活的基础。此外，数据库双活还必须使用专用的“并行版数据库”，目前，主流的并行版数据库有 Oracle 公司的 RAC（或者 Extend RAC）和 IBM DB2 的 PureScale。