系统集成灾备建设
从数据的操作类型方面谈谈几种容灾方式的使用场景
目前接触到的容灾方式有如下几种：
1、基于硬件的容灾，比如通过阵列的复制卡进行远程复制或者是飞康容灾方式，需要购买单独硬件盒子；
2、基于软件的容灾，常见的有Oracle的两款软件，Datagurd和Goldengate，其他的，比如赛门铁克的VERITAS等；
第二个问题，这些容灾手段，可能跟业务类型也有关系，有的容灾手段可能更适合大数据环境，比如BI系统；
有的可能更适合BOSS系统，这根数据的操作类型有关，比如DDL操作多还是DML操作多，系统从这个方面也讨论下。
1、基于硬件的容灾，比如通过阵列的复制卡进行远程复制或者是飞康容灾方式，需要购买单独硬件盒子；
2、基于软件的容灾，常见的有Oracle的两款软件，Datagurd和Goldengate，其他的，比如赛门铁克的VERITAS等；
第二个问题，这些容灾手段，可能跟业务类型也有关系，有的容灾手段可能更适合大数据环境，比如BI系统；
有的可能更适合BOSS系统，这根数据的操作类型有关，比如DDL操作多还是DML操作多，系统从这个方面也讨论下。
5同行回答
没想到“phanx”见解这么深，学习中，谢谢了！收起
浏览1676
只是希望大家在做灾备项目的时候，要从用户的角度出发，不要一来就高大上的忽悠。真正落地又不是那么回事了。 做技术的，虽然为了混口饭吃，合着销售一起坑蒙拐骗的时候不少，但是还是不要过分。静下心来，分析用户的需求，真正从用户的角度来想问题，找到合适的解决方案，生意才做的长久，才能实现共赢。收起
浏览1701
非常感谢这么详细的回复，讲的都是心里话了，实施经验加心得体会，大家能好好读读这段回复的话，会受益非浅。我们这边做的容灾大都是异地的容灾，距离比较远，上面各种容灾手段不少都搞了些案例，有些只是在实验室环境下验证过，通过比较后，我们这边也是推荐在异地容灾首选Datagurd；Datagurd容灾做的最多，EMC RecoveryPoint容灾方式也在用，项目不多，飞康的只有一个项目在用，用的效果不理想； GG的方式有个项目正在实施，看看情况了，估计很可能也会被坑下。。。。收起
浏览1691
基于硬件的复制，特别是同步的复制对带宽的要求会很高，一般都要求直接的SAN连接，因此，要求两个站点间必须是裸光纤或者加上波分设备。 这对于同城站点间的灾备来说不算什么难事，因此，基于硬件的同步复制比较适合同城的灾备站点。但是，注意，同步复制必然会带来性能的损耗，特别是会受到链路质量的影响。我们同机房SRDF同步复制实施后大概有40％左右的下降。当然，这不排除是个别现象，但是总体来说是有一定的性能下降的。
硬件同步复制对远距离站点不太现实，链路质量也满足不了需求。 所以，异地的复制一般都是异步基于IP的。但是，如果系统的写入数据量大的话，例如 一条update语句更新几亿行这种，那么硬件复制在没有进行压缩的情况下，相对于与Dataguard这种基于日志的复制数据传输的数据量则要大很多。
当然，这两中技术的优劣还是得依据具体的业务系统来看，要经过详细的测试才会有适合的结论。
飞康/EMC RecoveryPoint这种设备提供的好处则是数据的连续性保护（CDP），其实并不算是专门为灾备设计的。
虽然也可以用作灾备，但也基本是适合异地远程复制。同城灾备很少有用这种设备做的，虽然飞康也有案例。
Oracle DataGuard和GoldenGate比较的话，如果是做选择数据复制的方式做灾备，请选择DataGuard。因为很多Oracle的售前和销售会很不厚道的刻意回避了GoldenGate里面的种种限制，例如不支持某些数据类型，还有一些例如“构成唯一索引的索引列 的列定义不允许为null”这类的各种限制，当你想把GoldenGate作为灾备复制技术的时候，请自行去oracle网站上下载一份GoldenGate的管理手册（公开的），看看里面的支持和不支持的各种特性。如果你没有看就决定用了，那么你只有祈祷你的业务系统的数据库够简单，你的应用也不会用到一些稀奇古怪或者投机取巧的特性。 GoldenGate是一个优秀的数据复制软件，但是它不是专业的灾备解决方案。 如果你考虑采用它的话，请结合你的业务系统慎重评估它。反正我是被坑过了。
Oracle DataGuard / DB2 HADR 这种是传统的解决方案。用起来也不复杂，成本低（软件自带，无需额外费用-Active DataGuard除外），对基础设施也不太挑剔（主机设备档次可以不同，存储也可以异构），带宽要求也可能相对较小（以传输日志这种方式，但也跟业务系统特点相关，不绝对）。一般出于应用性能上的考虑，就算在同城站点，也大多采用异步复制的方式，RPO肯定没有基于硬件的好（虽说DataGuard也有同步模式，但是相信在应用不够优化的情况下，一般不会贸然选择Maximum Availability甚至Maximum Protection的同步模式吧，如果有的话我只能佩服应用做得好了。）。 因此，DataGuard（Maximum Performance）更适合距离稍远的异地站点灾备。
当然，这类技术也会有一些限制，例如Oracle 10gR2 不支持RAC作为主库的的cascade级联备库配置方式（11gR2支持），DB2 V10.1以前的HADR就不支持多Standby节点（我们的9.5想要HADR既做同城又做异地就不行）。。。。 因此，选用一种技术的时候，要充分考虑是否适合自己的环境。
赛门铁克的Storage Foundation一个方式可以做卷的镜像，类似LVM的mirror和Oracle ASM提供的Disk redundancy这种方式。通过在两个站点间的SAN通道使得主机分别挂在位于两个站点的存储设备上的LUN来实现。另外也可以在卷管理层面做数据复制，类似与DataGuard这样的软件复制。 这种方案相对要复杂一点点因为中间多了一层独立的卷管理软件。 当然，它也有优势，例如同城站点同步复制下存储可异构（远程异步存储异构就更不在话下）等。具体与基于硬件的同步复制技术来讲谁的性能好，开销低，我没有测试过，不好评价。不过如果是Oracle数据库（特别是11gR2以后的版本）如果像考虑这种模式的话，还不如用ASM自带的磁盘冗余功能。把两个站点的存储的LUN加入磁盘组直接用ASM做镜像就可以了，相对赛门铁克来讲软件成本为0（oracle自带，前提是你卖了oracle，不买就更不用说了）。
另外，最近EMC在推的VPLEX，所谓存储双活，甚至加上Extended RAC做的数据库双活，大家可能要谨慎点（IBM也有SVC或者GPFS/ DB2 GDPC的双活方案）。 毕竟这种技术成熟度还不够，偶尔出个bug也够受的。 特别是Extended RAC，现在国内大多数软件开发商做的应用连基本的RAC支持都不好，跑起来就两边抢资源，节点间GC流量猛增一类的，就更别说还是远距离的Extended了。或许基于IB的 DB2 GDPC要好些，我还不知道国内有哪些成功案例。。。 IBM的SVC相对VPLEX要早一些，相对要成熟些吧，没有用过，不做评价了。
一己之见，大家讨论。收起
硬件同步复制对远距离站点不太现实，链路质量也满足不了需求。 所以，异地的复制一般都是异步基于IP的。但是，如果系统的写入数据量大的话，例如 一条update语句更新几亿行这种，那么硬件复制在没有进行压缩的情况下，相对于与Dataguard这种基于日志的复制数据传输的数据量则要大很多。
当然，这两中技术的优劣还是得依据具体的业务系统来看，要经过详细的测试才会有适合的结论。
飞康/EMC RecoveryPoint这种设备提供的好处则是数据的连续性保护（CDP），其实并不算是专门为灾备设计的。
虽然也可以用作灾备，但也基本是适合异地远程复制。同城灾备很少有用这种设备做的，虽然飞康也有案例。
Oracle DataGuard和GoldenGate比较的话，如果是做选择数据复制的方式做灾备，请选择DataGuard。因为很多Oracle的售前和销售会很不厚道的刻意回避了GoldenGate里面的种种限制，例如不支持某些数据类型，还有一些例如“构成唯一索引的索引列 的列定义不允许为null”这类的各种限制，当你想把GoldenGate作为灾备复制技术的时候，请自行去oracle网站上下载一份GoldenGate的管理手册（公开的），看看里面的支持和不支持的各种特性。如果你没有看就决定用了，那么你只有祈祷你的业务系统的数据库够简单，你的应用也不会用到一些稀奇古怪或者投机取巧的特性。 GoldenGate是一个优秀的数据复制软件，但是它不是专业的灾备解决方案。 如果你考虑采用它的话，请结合你的业务系统慎重评估它。反正我是被坑过了。
Oracle DataGuard / DB2 HADR 这种是传统的解决方案。用起来也不复杂，成本低（软件自带，无需额外费用-Active DataGuard除外），对基础设施也不太挑剔（主机设备档次可以不同，存储也可以异构），带宽要求也可能相对较小（以传输日志这种方式，但也跟业务系统特点相关，不绝对）。一般出于应用性能上的考虑，就算在同城站点，也大多采用异步复制的方式，RPO肯定没有基于硬件的好（虽说DataGuard也有同步模式，但是相信在应用不够优化的情况下，一般不会贸然选择Maximum Availability甚至Maximum Protection的同步模式吧，如果有的话我只能佩服应用做得好了。）。 因此，DataGuard（Maximum Performance）更适合距离稍远的异地站点灾备。
当然，这类技术也会有一些限制，例如Oracle 10gR2 不支持RAC作为主库的的cascade级联备库配置方式（11gR2支持），DB2 V10.1以前的HADR就不支持多Standby节点（我们的9.5想要HADR既做同城又做异地就不行）。。。。 因此，选用一种技术的时候，要充分考虑是否适合自己的环境。
赛门铁克的Storage Foundation一个方式可以做卷的镜像，类似LVM的mirror和Oracle ASM提供的Disk redundancy这种方式。通过在两个站点间的SAN通道使得主机分别挂在位于两个站点的存储设备上的LUN来实现。另外也可以在卷管理层面做数据复制，类似与DataGuard这样的软件复制。 这种方案相对要复杂一点点因为中间多了一层独立的卷管理软件。 当然，它也有优势，例如同城站点同步复制下存储可异构（远程异步存储异构就更不在话下）等。具体与基于硬件的同步复制技术来讲谁的性能好，开销低，我没有测试过，不好评价。不过如果是Oracle数据库（特别是11gR2以后的版本）如果像考虑这种模式的话，还不如用ASM自带的磁盘冗余功能。把两个站点的存储的LUN加入磁盘组直接用ASM做镜像就可以了，相对赛门铁克来讲软件成本为0（oracle自带，前提是你卖了oracle，不买就更不用说了）。
另外，最近EMC在推的VPLEX，所谓存储双活，甚至加上Extended RAC做的数据库双活，大家可能要谨慎点（IBM也有SVC或者GPFS/ DB2 GDPC的双活方案）。 毕竟这种技术成熟度还不够，偶尔出个bug也够受的。 特别是Extended RAC，现在国内大多数软件开发商做的应用连基本的RAC支持都不好，跑起来就两边抢资源，节点间GC流量猛增一类的，就更别说还是远距离的Extended了。或许基于IB的 DB2 GDPC要好些，我还不知道国内有哪些成功案例。。。 IBM的SVC相对VPLEX要早一些，相对要成熟些吧，没有用过，不做评价了。
一己之见，大家讨论。收起
浏览1992