SQL+双机方案.docx

SQL SERVER 双机热备方案背景分析：随着IT技术和应用的发展，企业业务支撑对IT系统的依赖程度越来越高，而且这类应用的访问量也开始成指数级增长，如何保护现有数据的可用性，又如何提供数据访问的连续性，已经是摆在所有企业面前的关键性问题。可以想象，在如今的越来越激烈的商用竞争中，由于业务运营对 IT 系统的依赖，IT 系统的可用性直接决定着业务的可用性，即便是一小时的宕机，也会给企业带来生产力和销售方面的损失，如果宕机频繁发生，则可能影响客户对您的企业、品牌以及成本的看法。服务的中断，信息的中断，会给企业内部和客户带来巨大的损失。所以,如何管理维护、保护数据已经越来越为人们所重视。在企业运行关键系统业务而不能有长时间停机时，单台服务器已经不能满足企业的应用需求，这就需要多台服务器并选购相应的存储产品，相关的数据保护软件一起实现业务的持续运行。现状分析：常见单机系统缺点：由于服务器硬件故障引起停机。现今服务器技术已经高度发展了，服务器的性能、功能相对数年前已经有了很大的提高，但可靠性方面的发展却相对较慢，即使设计良好的X86服务器，可靠性始终维持在99.9%~99.95%之间（即，以三年计，平均每年的故障修复时间为4-8小时），始终无法避免由于硬件故障产生的停机。由于软件故障引起停机。在应用软件高度发展的今天，软件的功能越来越强，复杂性越来越高，即使是历经数年，广泛使用的操作系统及应用软件，都无法避免由于自身的缺陷引起的系统故障，根据统计，WINDOWS系统的可靠性为99.96%要低于LINUX的99.98%与UNIX的99.99%，WINDOWS系统的年故障时间大约在3小时左右，商业版LINUX系统的年故障时间大概为1个多小时，最可靠的为IBM 的AIX,可靠性99.99%,每年的平均故障时间仅为不到30分钟。系统性能难以扩展。随着企业的发展，企业的应用规模也在不断的扩大，单机系统由于自身的限制，扩展能力有限，无法满足应用扩展需求。数据安全性无法保障。服务器非专业存储系统，对数据的安全保护方面，只能基于基本的RAID冗余方式，有一定的局限性，无法满足企业对核心数据的保护要求。病毒、蠕虫攻击引起网络故障。系统需求在如今的企业环境下，我们对服务器整体系统的要求可以归纳如下：网络故障，系统故障，应用程序故障等全系统检测.当高可用系统中的某个节点故障，无须人工干预自动切换，保障系统运行.快速恢复,减少业务中断.金蝶方案：金蝶针对企业应用的要求，联合合作伙伴，提供了全面的解决方案，方案拓扑如下：双机 热备双机热备形式Active/Standby，Active/ActiveActive/Standby方式是传统的双机热备份解决方案，主机运行时，备机处于备用状态，当主机故障时，备机马上启动将服务接替。因备机平台没有其它的访问量，所以故障切换后用户访问速度不会有大的影响，此种容错方式主要适用于用户只有一种应用，主备机设备配置不太一样，并且用户访问量大的情况。Active/Active这种方式的主备机平时各自有一种应用运行，当系统中的任何一台主机出现故障，应用都会集中到一台服务器上运行，此时这台备用服务器不仅要承担以前的程序运行而且还要运行宕机服务器上的应用程序，所以此时备机的负担会加重。这种方式的故障切换往往会造成备机访问量增大，系统运行变慢。此方式主要适合用户有不只一种应用，用户主备机配置一样且数据访问量不大的情况。双机热备拓扑图：Server1是主“激活”节点，Server2是次“备用”节点。如果Server1发生故障了，它的被保护资源由Server2 节点来恢复。当节点Server1恢复后， 资源可以被Server1重新获得APPA 处于Volume w中，并且在Server1上激活。APPB存储在Volume M上，并且在Server2上激活。在这一配置中，Server1应该是Volume W：资源的主节点，Server2应该是Volume M：资源的主节点。当Server2失败时，集群功能应该将Volume M：转换到Server1上去。如果系统资源是足够的，这一转换不会影响到已经在Server1上运行的APPA，转换只是简单地将Server2上的被 保护应用程序（APPB）加到Server1的运行负载上集群技术原理(1)心跳工作过程通过IP做心跳检测时，主备机会通过此心跳路径，周期性的发出相互检测的测试包，如果此时主机出现故障，备机在连续丢失设定数目的检测包后，会认为主机出现故障，这时备会自动检测设置中是否有第二种心跳，如果没有第二种心跳的话，备机则根据已设定的规则，启动备机的相关服务，完成双机热备的切换。(2)IP工作过程IP地址使用虚拟IP地址的方法来实现，主要原理如图主机正常的情况下虚拟IP地址(即访问IP:192.16