故障转移技术在数据中心是很常见的，许多大型企业都使用了故障转移技术处理服务器故障，数据库故障，甚至是整个数据中心故障。故障转移技术就是创建一个“热站点”或“热备用”同时运行与主站上相同的系统和服务，理想情况下，当主服务、系统或站点失效时，终端用户可以无缝地转到备用站点，备用站点与主站点是全部同步的，因此无需恢复操作，业务不会因此中断。

　　在正常情况下，这种架构不会有什么问题，服务不会中断，数据不会丢失，在切换时，终端用户最多能轻微感觉到一点延迟。高级故障转移技术已被证明可以很好地工作，但传统的故障转移技术非常昂贵，采购、部署和管理成本都非常高，对大多数企业而言，都承受不起。
　　
　　现代企业面临的一个挑战是，他们需要实施负担得起的应用程序故障转移，仅保护那些重要的应用程序，在某些情况下，他们唯一的办法是重新设计应用程序以适应故障转移，但使用组织现有故障转移技术，可能无法实现重构，大多数情况下，打包的应用程序需要厂商设计故障转移功能，很多组织需要考虑购买特殊的产品，以满足他们的需要。但如果组织有自制打包应用程序，可能需要为应用程序故障转移重写代码，允许开发人员直接将故障转移功能合并到应用程序中的技术已经出现。虚拟化为故障转移提供了新的解决方案，在某些情况下，可以减少重新设计应用程序的需要。你选择哪种技术完全取决于你的业务需求和应用程序开发能力。

　　为故障转移自己动手编写代码

　　要让每个应用程序都具有弹性，没有一个固定的单一解决方案，弹性和故障转移应从妥善保护独立应用程序开始计划，这听起来象是一个不可能完成的任务，尤其是应用程序已经在服务的情况下，但应用程序开发工具厂商为我们提供了一些选择，不过大部分功能都是每个应用程序开发平台独有的，这意味着应用程序开发人员必须学习这些特定的开发生态系统，找到合适的工具实现故障转移功能。

　　例如，通过Visual Studio可以开发出具有“故障识别”能力的应用程序，当然前提是要结合微软的数据库和服务器运行。理想情况下，当用户被重定向到其它应用程序服务器、数据库服务器或文件服务器时，应用程序可以维护一个数据状态和会话状态。

　　相同风格的弹性可以适用于那些运行在Oracle数据库之上的应用程序，特别是那些用Java编写或依赖于Ajax技术的应用程序。这里，代码将感知故障的能力合并到Oracle数据库服务器上，在通知应用程序服务器数据传输目的地变化的同时，由Oracle服务器处理故障事件。开发人员也可以使用面向方面编程（Aspect-Orientated Programming，AOP），它是以重试和恢复过程为基础的方法，有些人可能会认为AOP是一种强制故障转移的方法，但无论如何，它是一种可以减少编码量，并已经证明是可以工作得很好的方法。

　　对于那些使用客户端/服务器模式本地执行的应用程序来说，要实现故障转移比较复杂，应用程序必须依赖于状态轮询或感知服务器（数据库或应用程序）状态，然后重新路由请求到正常运转的系统，在后端需要更多的技术，如负载均衡和故障转移设备。不过，根据应用程序的复杂性，将故障转移功能整合到现有应用程序花的时间可能很长，有时还不如重头开始开始写代码。同样，还需要大量的测试确保应用程序在故障转移环境下可以正常运行，这将会延长开发周期。

　　在C+或其它编程套件下开发的应用程序通常使用混合的故障转移方法，应用程序只需要知道请求和更新需要发送到哪里，而由后台技术处理物理路由。例如，微软提供了两个API用于创建故障转移功能：故障转移集群API（Failover Cluster API）和集群自动化服务器（Cluster Automation Server），故障转移集群API是一套丰富的开发集群感知应用程序的C/C++库，而集群自动化服务器提供了一套脚本对象，用于监控和管理故障转移集群。Oracle开发人员可以使用Oracle调用接口（Oracle Call Interfaces，OCI），加入到用户定义的回调函数。

　　其它应用程序故障转移方法

　　深入了解代码库后，你会发现其实靠应用程序本身实现故障转移不一定是最具成本效益的方法，还有其它选择，既满足弹性需要，又无需重新编码，在最好的情况下，这些替代方法不需要修改一行代码，但需要研究应用程序是如何执行的，以及数据是存储在哪里的。

　　第一个替代选择是虚拟化，许多企业都在数据中心使用了虚拟化技术，既节省了成本，又减少了数据中心空间占用，最大化了设备的投资回报。使用虚拟化的问题是它通常是一个可有可无的方法，对于虚拟化故障转移，应用程序服务器必须虚拟化，应用程序本身也需要虚拟化，有些应用程序之间共享服务器，这意味着虚拟化可能会使情况变得更加复杂，甚至比改造应用程序实现故障转移功能还要复杂。然而，虚拟化可以简化数据系统的弹性，支持关键应用程序故障转移。

　　许多第三方厂商提供了打包方案，结合了虚拟化和故障转移弹性的优势，例如，VMware提供了站点恢复管理器（Site Recovery Manager），它是一个检查故障和自动造就灾难恢复环境的管理框架。另一个厂商是InMage系统公司，它提供了一个产品可以在虚拟桌面上捕捉I/O和复制数据，可以快速恢复系统，甚至可以跨越广域网使用。另一种方法是使用冗余虚拟机，来自Marathon软件公司的EverRun就是这样的产品。
复制技术结合了虚拟化和热备用，看上去好像是企业中引入的最快速的故障转移方法，因为应用程序和数据都驻留在企业数据中心，客户端只需要做少量工作就可以快速创建一个故障转移环境。可以这么说，对传统应用程序而言，这是最快的故障转移方法，如果结合同步和虚拟化，还可以带来另一个好处 – 应用程序负载均衡。

　　通过整合进负载均衡技术，应用程序故障转移不仅可行，还可以创建更高的投资回报，而热备用需要一直等待触发故障转移事件，这些系统在高要求环境中可以用于共享负载，包括Barracuda网络，CoyotePoint系统，F5网络等公司在内，他们提供的负载均衡产品都整合了故障转移功能。

　　其它厂商的产品有可以创建统一的，虚拟化故障转移解决方案，如SteelEye的LifeKeeper高可用集群设备，Racemi的自动化服务器和灾难恢复套件，Novell的Platespin Protect，IBM的System x刀片服务器故障转移方案，以及VMware的高可应用服务，每个厂商提供的产品都具有不同水平的故障转移能力，在改写代码前，建议全盘考虑一下所有可能的解决方案。