RealSync & H3C 技术对比

时间：2010-06-08 来源：吴险

	DSG RealSync	H3C	说明
获取数据方式	跟踪数据库日志	跟踪逻辑卷I/O
复制方式	逻辑交易指令复制	卷快照复制	从复制容灾角度讲，H3C对数据先做获取保存，再对卷做快照后，再复制传输，环节很多，无疑会造成复制的延迟加大。
信息传输量	少	多	数据库的数据改变主要包括日志文件和数据文件。据统计，数据文件数据块的改变量是日志文件的3-8倍左右。举例：假设日志增量块为1，那么数据文件平均为5，总改变为6。 DSG RealSync处理后的数据量约为日志量的1/3，传输时会再压缩掉70%，因此传输的数据量约为0.09； H3C 读取的数据量为6（I/O无法处理），在复制环节经过microscan压缩到1/4 ~ 1/8，取平均值1/6计算，传输的数据量为1；综合计算，DSG Realsync传输的数据量仅为H3C的1/10或更少。
带宽要求	2Mbps	10Mbps以上
逻辑一致性	利用数据库事务机制保证数据的一致性和完整性	不能完全保证一致	H3C的复制基于对卷的快照而不是生产卷的快照，卷在主机Agent帮助下可以记录数据库的checkpoint做恢复，但的快照是在生产主机之外的并不具有此功能，因此的快照是否可以保证数据库的一致性成为疑问。另外，如果数据库跨多个卷部署，需要一致性卷组（consistency group）功能保证卷之间的一致性，H3C目前还没有此功能。因此基于H3C的数据库容灾切换可能存在风险。
容灾端数据库状态	打开	关闭
对生产主机系统影响	轻微资源占用，少量CPU资源用于读取分析日志和传输	在主机部署DiskSafe Agent执行虚拟化和多路I/O发送	H3C以虚拟化为基础做，主机I/O同时写向主存储和H3C 存储。目前主要是同步写。由于H3C 存储性能往往低于主存储，因此启用后，生产系统的整体I/O能力会被拖慢，甚至会影响很多。众多案例表明，H3C解决方案不适合对性能要求很高的应用，这也是业内对H3C的主要负面评价。 DSG Realsync由于原理的优势，性能表现和资源占用都很优秀。因此被电信级用户广泛采用。
容灾切换时间	分钟级	需要数据库启动和recovery，无法确定时间	DSG Realsync在切换时不需要启动数据库，仅作IP地址的切换。 H3C在切换时需要启动数据库，而且有可能启动失败。
切换可靠性	无风险	数据库有无法启动的风险
两端操作系统要求	异构	同构	DSG Realsync可以实现不同Unix和Linux之间的复制。由于各地市设备不统一（ibm和hp都有），因此在容灾中心可以使用Linux服务器，即实现了数据的集中，也可以极大地节约成本。 H3C容灾需要生产与灾备系统主机、操作系统完全同构。
两端硬件平台要求	异构	异构
容灾距离	基于IP，距离不限	基于IP，距离不限
传输模式	异步	异步	DSG Realsync的复制延迟主要包括：1、跟踪数据库日志的间隔时间1-2秒；2、网络延迟。根据经验，一般在本地复制延迟为2-4秒，远程复制为10秒左右。 H3C复制延迟主要包括：1、快照的间隔时间；2、网络延迟。显然，由于快照间隔时间更长，而且传输的数据量更多，因此在灾难发生时，H3C的解决方案会丢失更多的数据。
其他数据支持	不支持	支持其他数据库和文件系统	H3C的优势为对数据类型的更多支持。
复制资源利用	容灾数据库可以随时读取数据，外围系统可以任意抽取数据。	复制数据库需要做磁盘快照才能读取。但数据为静态。需要mount操作系统和open数据库的复杂过程。还要占用存储空间。
复制灵活性	可以灵活的多对一数据集成、一对多数据分发。多个数据库对一个数据库。	从主机和数据库的角度，必须严格的1对1
应用级别	环境复杂、对性能有苛刻要求的企业核心数据库应用	环境简单，对性能不敏感的中小型系统
磁盘阵列的硬件投资	只需要在目标端保证和生产端相同的存储空间即可	（1）要求在生产中心额外准备相当于生产阵列1.5倍的存储空间；（2）要求在容灾中心也准备一个相当于生产阵列1.5倍的存储空间	因为H3Cc必须将数据先同步到本地系统上，加上H3C要求保存若干个快照，因此要求大量的额外磁盘存储空间。在数据量较大时将极大的增加系统投资。
容灾系统出现问题对生产线体统造成的影响	DSG进程对生产数据库不会造成任何阻碍，即使当生产系统上的同步进程出现问题时，也绝对不影响对生产系统的正常运行	由于H3C利用主机上的IO Mirror功能实现IO操作的镜像，当H3C的设备出现故障时，将导致生产中心的IO操作失败，严重影响到生产系统的正常运行