故障转移技术的思考

故障转移技术在数据中心是很常见的，许多 大型企业都使用了故障转移技术处理服务器故障，数据库故障，甚至是整个数据中心故障。故障转移技术就是创建一个“热站点”或“热备用”同时运行与主站上相 同的系统和服务，理想情况下，当主服务、系统或站点失效时，终端用户可以无缝地转到备用站点，备用站点与主站点是全部同步的，因此无需恢复操作，业务不会 因此中断。
　　在正常情况下，这种架构不会有什么问题，服务不会中 断，数据不会丢失，在切换时，终端用户最多能轻微感觉到一点延迟。高级故障转移技术已被证明可以很好地工作，但传统的故障转移技术非常昂贵，采购、部署和 管理成本都非常高，对大多数企业而言，都承受不起。
　　
　　现代企业面临的一个挑战是，他们需要实施负担得起的应用程序故障转移，仅保护 那些重要的应用程序，在某些情况下，他们唯一的办法是重新设计应用程序以适应故障转移，但使用组织现有故障转移技术，可能无法实现重构，大多数情况下，打 包的应用程序需要厂商设计故障转移功能，很多组织需要考虑购买特殊的产品，以满足他们的需要。但如果组织有自制打包应用程序，可能需要为应用程序故障转移 重写代码，允许开发人员直接将故障转移功能合并到应用程序中的技术已经出现。虚拟化为故障转移提供了新的解决方案，在某些情况下，可以减少重新设计应用程 序的需要。你选择哪种技术完全取决于你的业务需求和应用程序开发能力。
　 　为故障转移自己动手编写代码
　 　要让每个应用程序都具有弹性，没有一个固定的单一解决方案，弹性和故障转移应从妥善保护独立应用程序开始计划，这听起来象是一个不可能完成的任务，尤其 是应用程序已经在服务的情况下，但应用程序开发工具厂商为我们提供了一些选择，不过大部分功能都是每个应用程序开发平台独有的，这意味着应用程序开发人员 必须学习这些特定的开发生态系统，找到合适的工具实现故障转移功能。
　 　例如，通过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的高可应用服务，每个厂商提供的产品都具有不同水平的故障转移能力，在改写代码前，建议全盘考虑一下所有可能 的解决方案。
如果你是或曾经是一名服务器管理员，则你总是会以某种方式远程管理服务器。随着网络基础设施逐渐延 伸到典型机房以外的地方，无论你是使用Citrix独立计算体系结构（Independent Computing Architecture，ICA）通道还是支持远程桌面管理的VPN（虚拟专用网）登录，远程服务器管理都不可否认地成为一项日常性工作。
　　而要进行远程服务器管理，就要用到远程管理工具。现在，许多服务器都配备了无人值 守管理（Lights-Out Management，LOM）工具，集成了完善的功能。通常情况下，一个服务器系列的远程管理工具有一个专有名称。例如，戴尔PowerEdge服务器 上的管理工具称作OpenManage，而惠普ProLiant服务器上的管理工具则称作Integrated Lights Out（iLO）。尽管这些嵌入式软件和硬件名称各异，功能丰富，但是我们必须了解这些技术本身的缺陷，才能轻松驾驭这些远程管理工具。
　　远程服务器管理失败的原因
　　显而易见的是，只有服务器在接通电源的情况下，无人值守管理工具才能运行。当然， 你可能会为运行关键业务的服务器提供后备电源。但是，如果这两个电源都断电了，那么很不幸，你的服务器仍然无法运行。此时，你应该调用现场的远程服务器管 理工具，以检查问题所在。除此之外，无人值守管理工具也可以为你排忧解难。
　 　作为一名远程服务器管理员，你将为一些重要的非现场工作做些什么准备？适当的灾难恢复管理和规划可以帮助你应对和解决与远程服务器有关的简单问题。除了 显而易见的电源全部断电的情况以外，远程服务器管理还需要考虑以下三个重要问题。
　 　首先，远程服务器管理依赖于Internet。如果Internet无法连接，远程管理当然也就无从谈起。在紧急情况下，有时管理员会使用拨号连接。但 是，如果你曾经利用拨号连接管理过服务器，你就会知道，这可不是一件轻松的事。许多管理员必须远程登录，而且离开Internet服务就无法管理服务器。 此时，他们可以考虑使用冗余路由。如果你选择在服务器场所建立第二条Internet线路，则一定要选择使用不同线路的另一家Internet服务提供商 （Internet Service Provider，ISP）。因为选择两家不同的ISP并不意味着他们使用的不是同一条线路，所以要验证它们是不是由完全不同的运营商提供的完全独立的线 路。一种实现冗余路由的方法是选择两家运营商，其中一家提供T1/T3线路，另一家提供企业级电缆连接。更有甚者，一些强调正常运行时间的管理员还会建立 冗余ISP基础设施，其中可能包括移动解决方案、卫星链路以及作为最后一招的拨号连接。
　 　其次，管理员只能管理自己所能发现的问题。因此，选用的工具要能够提供最符合自己需求的功能和接口。管理员通常可以选择无人值守管理和IP-KVM（基 于IP的键盘、显示器和鼠标，有时也称作iKVM）工具。无人值守管理集成了安装有专用服务器软件的硬件芯片，这些软件允许管理员管理服务器。另一方面， 独立的IP-KVM是在机架或服务器环境中管理大量服务器的辅助产品。无人值守管理和IP-KVM各有利弊，都可以远程管理服务器。例如，Avocent 公司生产的IP-KVM允许管理员在服务器上插入键盘、显示器、鼠标甚至串行端口，对管理员大有裨益。利用Avocent IP-KVM，管理员可以解决思科防火墙、网络交换机以及其他没有配置任何无人值守管理工具设备的问题。管理员甚至还可以在IP-KVM设备上通过串行连 接管理PBX（专用交换机）。
　　David Langlands是国际安全和IT咨询公司Cyberklix的首席安全架构师，他需要管理和监视位于全球各地的众多服务器。他说，“当需要远程管理服 务器时，IP-KVM就像人的结肠一样，不是一种选择，而是一种需要。”然而，单一的IP-KVM也会发生问题。正如Langlands指出的那样，使用 辅助IP-KVM也有弊端。他说：“使用辅助IP-KVM的成本往往比较高昂，且对服务器的物理组件几乎没有可见性。而令人遗憾的是，你还不能使用简单的 IP-KVM实现电源循环。”
　　最后，在试图全面诊断物理问题 时，无论使用独立的IP-KVM还是无人值守管理，管理员都可能会遇到一些麻烦。对于远程管理和快速修复，IP-KVM和无人值守管理都是重要的工具。但 如果是内部风扇或服务器中的其他组件出现故障，远程管理软件不一定总是能够显示这些故障信息。由于无人值守管理并不能解决所有问题，所以你必须准备第二套 解决方案，以排除严重的硬件故障。
　　因此，当发生远程管理工具无 法识别或修复的问题时，现场管理员需要一双慧眼，以准备解决这个问题。有些企业可能会在远程位置派驻一名管理员，依靠远程托管场所的IT人员或利用合同工 程师服务，获得上门服务或按需服务。通常情况下，托管场所将会与企业签订一份服务级别协议，约定如果服务器出现硬件故障，现场工作人员可以马上更换出问题 的硬件。由于托管场所是全天候运行，因此不会出现服务器等待修理的问题。托管服务的不利之处在于，托管合同和专业服务价格昂贵。因此，要尽量少用托管服 务。合同工程师服务的价格也便宜不了多少。例如，如果你在芝加哥，而远程托管的服务器在纽约，则你可以依靠外部网络工程师来帮助解决问题。这些合同可以累 计，雇用一名工程师检查服务器的最低费用约为每小时150美元。
　 　远程管理工具的局限
　　请记 住，远程管理工具不能解决你所有的问题，因而不能保证你的服务器不发生重大灾难。如果说远程管理工具有作用，它们也只是一些可以在紧急情况下使用的辅助工 具而已。没有任何软件或硬件是十全十美的。因此，在使用诸如无人值守管理硬件和软件这样的远程管理工具时，请牢记以下事项：
    •    无人值守管理功能通常是通过嵌入在服务器硬件芯片中的软件实现的，因此你可能 会发现其GUI缺少某些功能。
    •    由于资源有限，这种板载软件可能需要非常具体的Java/Active-X版本甚至特定的浏览器才能运 行。
    •    如果你的服务器要求高分辨率，则你在访问服务器时可能会遇到一些问题，因为有些远程管理工具不完全支持高分辨率访问。
    •    慎 用键盘上的功能键组合（功能键+f2、功能键+ctrl+f12）。当使用无人值守管理工具时，由于软件不能识别你试图输入的内容，你可能会遇到真正的风 险！
　　规划和准备可以突破远程管理的局限
　　那么，什么时候无人值守管理真的相当于现场操作呢？通常情况下，这取决于你的网络基 础设施的规划。作为一名IT管理员，一定要在远程服务器的无人值守管理和现场操作之间采取折中的办法。当对公司进行灾难分析时，一定要弄清业务关键型设备 的重要程度究竟如何。问自己一个问题：“这台设备有多重要？如果它宕机，我的业务还能运行多长时间？”在托管现场雇用经验丰富的工程师准备修复服务器是必 须的。IP-KVM或高端无人值守管理工具功能是有限的。在弄清什么时候无人值守管理真的相当于现场操作时，业务连续性起着非常重要的作用。