白皮书Stratus 与 Clusters 的比较

Appendix EStratus ftServer与Cluster集群系统的比较Stratus ftServer与 Cluster 集群系统的比较目录概述11. 容错技术发展历程21.1 系统可用性级别定义21.2 著名顾问咨询公司分析报告31. Cluster集群技术简述42.1 Cluster集群技术定义？42.2 术语42.3 Cluster可以做什麽？52.4 Cluster不能做什麽？63. Stratus容错解决方案优势73.1 零停顿时间73.2 无故障恢复时间73.3 无内存数据丢失73.4 标准Windows 2003兼容性73.5 Windows 2003可靠性增值73.6 应用透明性83.7 生命周期总成本和风险83.8 先进的远程维修服务84. Stratus与Cluster的竞争比较94.1 硬件体系结构94.2 系统选购104.3系统安装104.4 系统配置114.5 应用投产114.6 故障处理与恢复124.7 应用系统故障恢复周期134.8 Windows 2003可靠性增值功能144.9 系统维护144.10 Service154.11 Total Cost of Onwership 总成本核算154.12 解决方案比较综述165. 典型比较案例18ConfidentialPage III Appendix EStratus ftServer与Cluster集群系统的比较概述此文主要描述怎样与当前Stratus Technologies, Inc.所面临的称为Cluster集群系统的最大竞争者，如IBM、Sun和HP等，竞争的策略。潜在市场的变化：近期咨询调查表明，在Stratus传统的竞争市场中，High Availabitity（Cluster集群）市场潜力比CA市场要大，而且Cluster集群市场发展更快一些。这就是Stratus凭借其产品优势而涉足Cluster集群市场的初衷。Continueous Availability（CA）系统的变化：今天，Stratus能够提供非常低的购买和维护成本的、基于Intel技术和Microsoft Windows 2003操作系统的WinTel架构硬件容错服务器 ftServer。这些系统运行已被公认为是开放环境的操作系统环境。因此，Stratus ftServer可以认为与Cluster集群方案在价位上是可比的，而无须涉及应用或应用供应商。1. 容错技术发展历程了解容错技术的发展有助于对Stratus容错服务器和Cluster集群系统的比较有很大的帮助。从容错技术实现的模式角度，实现容错技术大体上分为两条途径：一条是从系统体系结构开始设计容错体系结构。目前主要产品表现为以Stratus产品为代表的CA连续可用性的硬件级容错服务器；另一条是在通用服务器的基础上，配合Cluster技术及相应集群软件而构成的Cluster集群高可用性Cluster集群系统。这两条途径呈现不同的产品设计目标和容错能力。1.1 系统可用性级别定义为了帮助企业更深入了解不同系统产品的可用性差异，著名顾问咨询公司International Data Corp. （IDC）为系统可用性作了详细的定义：可用性级别定义系统保护特性部件故障对用户的影响AL4 ( CA )100%冗余部件和功能对用户透明；无运算中断；无交易丢失；无系统性能降低。AL3 ( Cluster集群 )自动故障恢复，将用户会话及工作流转到备份部件；多台系统联至磁盘。用户保持在线；当前交易可能需要重启动；系统性能降低。AL2 ( Cluster集群 )用户会话及工作流转移到备份部件；多台系统联至磁盘用户中断；可快速重新登录；需根据日志文件重新运行某些交易；系统性能降低。AL1 ( RAID )磁盘镜像或RAID以及日志记录或日志文件系统提供为完成动态交易的标示和恢复。运算中止；不可控制的停机；数据完整性无法保证。AL0 ( stand-alone )无冗余系统部件。运算中止；不可控制的停机；数据完整性无法保证。注：ALn Availability Level n （可用性级别n）CA Continuous Availability （连续可用性）Cluster集群 High Availability （高可用性）RAID 磁盘阵列1.2 著名顾问咨询公司分析报告面对Stratus推出业界首台基于WinTel架构的硬件级容错服务器，一些著名顾问咨询各机构给予高度评价，认为Stratus ftServer产品的问世为关键业务应用的企业提供了卓越的系统平台选择。l 1.2.1 IDC的分析报告IDC在对ftServer的分析报告中指出：“Finally, since availability is a major concern for NT users, why choose a server designed to recover from failure rather than a server designed not to fail in the first place? The answer is obvious: Dont let the outage happen at all.”l 1.2.2 D.H. Brown Associates的分析报告“D.H. Brown admires Stratus for having the confidence and fortitude for producing the ftServer system. With this multi-year effort by Stratus, we believe that the firm has made a major contribution to the art and science of fault-tolerant systems.”l 1.2.3 Butler Group的分析报告Butler Group believes that the ftServer product family will have wide appeal to enterprises in all industry sectors that increasingly need 99.999% availability.l 1.2.4 ARC Advisory Group的分析报告通过Stratus ftServer技术及产品的分析，ARC总结到：“New, low-cost technology for fault-tolerant platforms is now available for Microsoft Windows 2003 environments. Manufacturers should revisit some old assumptions about where they benefit from deploying these platforms. Collaboration puts a premium on real-time manufacturing information, and these systems can help ensure that the information is always available. Next, generation automation systems, production management systems, business systems, and collaborative systems can call benefit from this technology.”1. Cluster集群技术简述如果你已经熟悉Cluster技术，可以跳过此节。本节适合那些对Cluster技术不太熟悉的读者。2.1 Cluster集群技术定义？Clusters 集群系统是两个或多个标准服务器通过冗余网络连接一些外部RAID或JBOD磁盘设备以提供无单点故障的硬件平台，可以支持具有快速硬件、软件、或LAN故障恢复（重启动）能力的应用环境。Cluster在“很短的时间内”将应用由故障系统“切换”到Cluster的另一个系统上，并建立应用环境。Clusters由“标准”的HW/SW组件构成，一般地，“特殊”的组件仅是“Cluster Monitor”和“Package Monitor”（HP-MCSG）。2.2 术语Node -标准的计算机系统。在本文中，node是在Cluster中的一个计算机。也称为“服务器”（然而，服务器也可以是某个软件组件）。Packages -Cluster将资源集成为“package”（HP-MCSG术语）。Package定义了软件程序（系统和应用）故障恢复集（既，如果程序A，B，和C构成一个应用，当“B”出现故障，我们希望A和C也中止，所有三个程序将在另一个服务器上同时重启动）。此外，package定义了package运行的磁盘资源（逻辑卷），以及程序采用的IP地址。如果一个package通过硬件或软件或管理员命令恢复到另一个node，所有程序、磁盘和IP地址将转移到另一个机器上。磁盘文件实际上并不驻留在“node”上，而是驻留在外部的RAID或JBOD磁盘阵列上。在故障恢复的过程中转移的是拥有与该package相关的磁盘文件（实际磁盘逻辑卷）的权利。Scripts -用于启动和中止package，管理Cluster node，以及管理Cluster. 编写script并不很困难；但是欲覆盖所有可能的故障恢复却有些难度。Script包含了IP地址信息、node名字，和其它一些Cluster规定的信息，这就给将script从一个Cluster转移到另一个Cluster造成困难，即使第二个Cluster运行相同的应用package。Monitor Programs -Cluster Monitor 和 Package Monitor 是两个特殊的Cluster 组件。它们是运行于Cluster中所有node上的软件程序，确定Cluster和网络的状态，以及在出现故障时控制package的恢复。Package Monitor 管理package，而Cluster Monitor 管理Cluster中的node。Duplicate LANs - 一般来说（但并不必要），Cluster中的每个node连接两个分离的LAN，提供对LAN故障的保护。大多数Cluster提供第三个LAN来支持Cluster “心跳”（确定Cluster和package状态的监测程序之间的通信机制）。所有这些LAN的联接可能会用光在HP D-系列服务器上的很多插槽，使得它无法满足Cluster的需求。Cluster Reconfiguration - Cluster Monitor监测Cluster心跳，并且当检测到某个node出现故障时进行“Cluster的重新配置”。Cluster重新配置的完整描述已超出本文的内容，但是重要的是故障node将从Cluster中“移去”，在故障node上运行的package将在其它node上重新启动。Gotchas 包含了使重新配置复杂化的网络故障，因为一些node认为其它的node已经崩溃了，而此时那些node仍然在运行，这种无法连通的原因在于网络的故障。尽管具备某些预置的手段来处理这种情况，遗憾的是，这些手段令人失望。这些硬件厂商没有设置电话呼叫来通报这种实效的系统。Package Failover - Package Monitor监测package心跳以及在监测到package 出现故障时执行故障恢复。故障恢复包含了过程，有一个“stop”script杀掉在那个node上的所有package进程，然后在另一个node上的“start”script去启动在这个node上的package。在此需要考虑的是如果stop script出现问题，或不能中止所有的进程（由于某些悬挂的Unix进程），这将产生一些令人头疼的现象。此外，数据库又会怎样呢？start script应该确定数据库是一致的，尽管它可能是容易或不容易去做，一个script不可能去解决数据库的一致性问题！可以按故障恢复需要来将package配置到Cluster上一组node上或任何可用的node上。Cluster Flavors - Cluster分为两个集合（一个处于工作状态，而另一个处于随时承接故障恢复状态）来支持在多至8个node (Cluster技术的上限一直在改进)上的关键性应用，或者可以多至16个node来支持一些关键性应用和一些非关键性应用。因为销售策略的不同（更多的见后文），了解这些“flavors”是很重要的。IP Re-direction - 当一个故障恢复执行时，Cluster monitor具有将所有IP地址从故障node转移到另一个node上的能力。RAID and JBOD Disk Arrays - 这些术语将在本文的最后去定义。在这里指出的将是Cluster（一般的）采用多端口SCSI总线将外部磁盘联接到Cluster的node上，使得任一node均可访问磁盘阵列上的数据。在同一时刻，阵列可以为所有node提供全部逻辑卷（无论在哪里定义）。然而，在某一时间点，指定的逻辑卷仅能为一个node提供服务。SCSI寻址限制（一个SCSI总线最多16个）一般地成为在Cluster上node数的约束因数。通常允许多达8个控制器（每个node一个：8个node）及8个RAID或JBOD磁盘组。2.3 Cluster可以做什麽？由于软件或硬件，或者由操作员命令，Clusters能够在Cluster的一个node上重新启动失效的package。这将允许应用在另一个服务器上重新启动，并提供某种HW/SW升档的策略。附加的（昂贵的）软件亦可允许在Cluster中的node间“automatic package balancing”。可以说Clusters对应用是透明的。Clusters 是可行的。不要试图去灌输Cluster不可行的概念。供应商提供Cluster应用功能的能力依赖于供应商的技巧和承诺。某些供应商缺乏高级的技术支持（例如临床实验室和公共安全范畴的供应商），经常难以实施和维护Cluster。常常地，他们放弃了使Cluster运转的努力，采取了标准LAN配置的硬件（即，HW费用并没有浪费，但应用却不是Cluster集群结构的）。高级的供应商一般能够实施Cluster的应用，但是，一般来说，他们承认实施的难度和项目需要长期支持。2.4 Cluster不能做什麽？最重要的，Cluster并没有消除停机时间；他们通过提供重启动失效应用的策略来减少停机时间。在应用出现故障恢复期间，用户能够发现停机现象。而Stratus致力于消除非计划的停机时间。Cluster技术可以改进应用的可用性，但他并没有改进应用的伸缩性。在Cluster中任何伸缩性的改进是因为LAN，并非Cluster。没有什麽Cluster技术可以将应用“spread across”Cluster。可以使应用在Cluster的node上“spread across”的技术是LAN网络及其高明的编程，而不是Cluster！大多数RAID/JBOD设备不允许在Cluster的node上共享磁盘资源（逻辑卷）。这是因为逻辑卷包含了文件系统，Unix将很多文件系统缓存在node的内存上以提高访问速度。一个node上的文件系统信息是不能够被其他node访问的，因而，RAID不能在node间共享逻辑卷。Unix提供了软件工具（NFS和RFS)，使得“拥有”一个逻辑卷的node可以与网络上的其它node共享数据。这是Unix功能，不是Cluster功能。Cluster集群系统提供和标准的计算机一样的服务。没有类似Stratus在线诊断那样的call home功能。Cluster 厂商（IBM，SUN，和HP）都没有建立或具备象Stratus一样的保证客户满意的服务组织结构。在故障恢复过程中，Cluster集群系统不能恢复或转移内存的内容。这就是为什麽在故障恢复中交易将丢失“In flight”数据，这也是Stratus可以作为坚强的OpenView（NNM）服务器（因为NNM采用大规模的内存驻留技术的数据库）的原因。Cluster不能在Cluster的node之间转移象SNA，X.25，Async，或Bisync非网络的物理连接。这就是为什麽在OLTP报文交换应用中担忧Cluster的道理。3. Stratus容错解决方案优势Stratus是业界唯一一家全力致力于研发，推广硬件级容错机技术的厂商，并始终成为提供连续可用性计算机系统的领先者。伴随计算机系统的普及，特别是越来越多的企业采用Microsoft Windows 2003作为其应用系统环境，企业的关键性应用对系统环境的可靠性和可用性要求欲以剧增。Stratus适时在今年六月推出了业界第一台基于Intel技术和Microsoft Windows 2003的硬件级容错服务器系列产品 ftServer。Stratus生产的容错服务器秉承Stratus传统的容错硬件体系结构，为联机事务处理（OLTP）领域的关键性应用提供了新的连续可用性平台选择。其特点是：3.1 零停顿时间Stratus容错计算机系统提供业界最高可靠性、和可用性。服务器系统采用双模（DMR）和三模（TMR）硬件体系结构。双模系统可用性达到99.999%，平均每年非计划（意外）停机时间不超过5分钟。而三模系统可用性可超过99.999%的可用性。与其它解决方案低于99.99%，平均每年非计划（意外）停机时间超过45小时的可用性相比，用客户获得极大的稳定性。3.2 无故障恢复时间系统所有关键部件均为冗余配置。冗余部件时钟同步运行相同指令。保证即使在硬件出现故障时，其冗余部件仍然保持继续运行，从而保证当前交易的处理，应用不会因此而停顿和数据丢失。其它方案下，应用需要等待计算机系统的故障恢复，数据库的恢复，网络联接的恢复以及应用的恢复。3.3 无内存数据丢失Stratus独特的冗余硬件结构不但保证磁盘静态数据的完整性，而且保证内存数据的完整性。从而保证交易的完整一致性。而其它解决方案使无法做到的。在故障恢复期间，当前交易和内存数据将要丢失。3.4 标准Windows 2003兼容性Stratus ftServer支持标准的Windows 2003 Advanced Server操作系统环境。保持应用二进制兼容。标准Windows 2003下运行的软件无需任何需该即可运行在ftServer容错平台上。3.5 Windows 2003可靠性增值Stratus ftServer利用其独特的冗余结构和容错技术，改进和完善了Windows 2003的可靠性和稳定性。; 强化驱动为加强可靠性而设计的Stratus强化驱动不但可以实时检测和隔离故障部件，而且可以检测和隔离不良驱动的内存越界写操作，防止造成系统严重后果。; 在线转存在Windows 2003发生崩溃后，ftServer立即可从一个CPU重启动，使关键应用立即投入生产。与此同时，另一个冗余CPU保持内存状态数据，并在线将故障状态转存至磁盘，以供调试和诊断。; 快速重启动Stratus ftMemory提供预先定义内存段，使得当系统崩溃后的重启动期间，此定义的内存段数据保持不被刷新，从而重要数据、上下文生成数据、以及较大的驱动程序维持在定义的内存段，减少重启动时间，并保护了重要数据。3.6 应用透明性Stratus故障处理在硬件部件级完成。任何故障均能被自动隔离，而不会导致系统进一步严重问题。Stratus容错系统对应用使透明的，即：; 在单机上开发的应用无需修改，即可获得Stratus容错技术的特征。不象其它方案那样需要额外编制面向故障的脚本程序；; 应用的测试仅限于正常的软件测试。而无需进行繁琐的、重复的脚本程序测试来验证脚本程序能够正确地进行恢复工作；; 功能系统的维护如同单机一样。没有额外备份或集群技术的维护需要。3.7 生命周期总成本和风险Stratus的故障处理和维护使可预测的，为企业的成本预算奠定基础，从而Stratus解决方案总成本是最低的。相反，其它利用脚本程序解决故障的方案因为一些不可预测的故障没有相应的脚本程序处理而使应用瘫痪，企业将面临不可预测的成本和风险。3.8 先进的远程维修服务Stratus系统可故障检测到板件级。并且当部件出现故障，系统会自动通知Stratus客户服务中心，减少客户维护员的涉足，缩短问题解决的延迟，减少企业风险。换句话说，Stratus客户服务中心承担了客户系统维护员的部分职责，从而使得Stratus特别适合远程的、要求更为苛刻的、无人职守的的应用环境。Stratus提供基于互联网技术的eCAC客户界面。据此，客户可以直接查询Stratus客户服务中心接受的故障报告，以及客户服务中心工程师解决问题的历史资料。从Stratus硬件容错服务器的特点可以看出，容错服务器所组成的网络系统将是结构简单，连续可用性的。由此为用户带来众多的利益，如系统开发建设简单，系统维护管理成本低，系统扩充简单方便等好处。4. Stratus与Cluster的竞争比较Stratus ftServer是为那些基于Wintel架构的关键性业务应用的客户设计的。Stratus二十多年的关键性业务应用的经验告诉我们“可用性”对那些要求苛刻的客户意味着什麽。对于那些客户，Stratus解决方案的优势不仅仅就体现在可用性更高的概念上，亦包含了众多衍生而来的利益上。Stratus ftServer硬件容错服务器的优势主要表现在：l 业界最高的99.999+%可用性l 无故障恢复时间l 数据，特别是In-flight数据的完整性 l 应用和系统维护的简易性l 容错处理透明性l 最低总成本 Total Cost of Ownershipl 先进的可维护性4.1 硬件体系结构Stratus ftServer与Cluster集群系统尽管在功能上有些相似，然而，这是两种截然不同的产品。首先从结构上将，Stratus ftServer的硬件体系结构是为消除停机时间，特别是消除非计划停机时间而设计的。而Cluster集群系统仅仅是多台硬件系统、共享资源、及系统软件组合协同工作，其目的是减少停机时间，加快系统恢复时间。而且这个快速恢复时间不是恒定的，依业务的规模而变化。Stratus ftServer硬件结构是所有影响系统停机的关键部件均为双份冗余的，冗余部件时钟同步运行。也就是说，在同一时钟内，冗余部件执行相同的运算。当某个部件出现故障时，其冗余部件保持继续运行，保证交易的完整性。它是一种“并串”结构。系统容忍多个部件的故障，即无单点故障。而Cluster集群系统是一种“串并”结构，仅允许出现一个故障。参见下面示意图：4.2 系统选购实现Cluster集群系统是一个费时，费力的过程。无论是设备的选购，还是环境的安装调试，Cluster集群系统是由几台可共享资源、可互操作的单系统构成，属系统级容错，它的设计目标是尽量缩短因故障造成的停机时间。要将普通的单机系统构造成多机集群的Cluster集群系统，用户要先确定Cluster集群系统的可用性指标，按该指标计算机出一年的累计停机时间及由停机造成的损失，确认该损失额是否在用户可以忍受的范围之内：然后要考虑应用系统故障切换恢复时有可能造成的计算机系统性能下降问题，最后要对有关人员进行Cluster集群管理、编程等方面的培训。Stratus的容错计算机系统只需单机配置，一套硬件，一套系统软件，一套应用软件，没有切换软件，用户的开发管理都非常方便，并且容错对用户透明，从而使系统的建设费用大大降低。Stratus ftServer与Cluster集群系统相比，都具有省时，省力的优势。FtServer对客户及应用来说是一个单机界面。这就是说，一旦客户购置了此产品，她立即获得一个完全容错的环境。4.3系统安装Cluster集群系统不是一个完整系统。它是两台通用服务器，阵列磁盘存储子系统，Cluster及相应集群软件经过集成调试才能获得。因而，客户首先需要确定自己的可用性目标，制定可承受停机风险的能力。据此选择相应的组件。Cluster集群系统安装之前，需要制定安装和配置计划和工程实施计划。过多的组件链接不但繁琐，而且因为链接点的增多造成网络的不稳定性增大。而Stratus容错计算机的安装是对一台单机的安装，没有特别的容错软件，安装后也无需对容错进行调试，系统就自动具备了容错功能4.4 系统配置Cluster集群系统的安装需由专业的Cluster集群系统专家进行，除安装两套软件系统外，还需安装Cluster集群切换软件及Cluster集群管理工具。安装后，需进行Cluster集群系统的调试工作，测试系统软件和第三方软件是否具备Cluster集群功能，是否能在双机间进行切换。因此Cluster集群系统的安装调试需花费较长的时间才能完成。而Stratus容错计算机的配置是对一台单机系统进行配置，没有特别的容错环境配置，无需对容错进行调试，系统就自动具备了容错功能4.5 应用投产Stratus与Cluster集群系统相比的显著优势之一就是计划的实施。采纳Cluster集群厂家的“计划”作为指导。很多额外的步骤在CA方案中不需要执行。额外的步骤意味着额外的拖延。你的客户安装计算机是为了创造“利益”或保护“利益”，Cluster集群方案均拖延它们。这种利益的损失是无法弥补的。应用软件除了正常的标准软件测试外，在Cluster集群系统环境下，需要根据应用的要求，针对一致的故障类型编制相应的脚本程序，以在故障出现时能够作适当的环境切换。脚本程序必须反复进行测试，以证明其执行的正确性。悲哀的是，只有在应用正常运行时，特别是在业务高峰期，一些致命的故障的出现。有时这些故障是无法预测的，相应的故障恢复脚本策略是无法预先设计的。应用系统即使要经过繁琐的测试，仍要面临着严重的风险。这就是说，建立一个Cluster集群系统，实现所有的故障恢复脚本，以及应用的故障恢复是可能的，但当出现另一个情况时将会怎样？在这种情况下，Cluster集群系统可能还会运作，可是紧接着的故障恢复可能就不会工作了！在夜间，或者当单点故障的Cluster管理员休假，她（他）已经“离开”，甚至在更坏的情况的时间内，这种故障恢复失效都可能出现。而且，故障恢复脚本的测试并不是只指调试（在安装阶段），而且是长期的测试，以保证Cluster依然在正常工作！在CA方案中并不需要这些。因为Stratus方案对故障是基于硬件的、一步到位的处理，这些对应用系统是透明的。无需编写这些额外的脚本程序，可以更快的实现故障的隔离和处理，为您的客户产生更多的效益或保护其投资成本。某些产生这种故障恢复失效情况的例子：; 所有用户采用telnet访问node A。另外一些应用B的用户增加在node B上。当node A崩溃，应用A在node B上重启动时，因为在node B上存在着用户，没有足够的telnet socket供应用A的用户去登录 结果是，一些用户不能访问在node B上的应用。.; 一个应用使用了各种系统资源：memory，swap space，CPU cycles。因为新的应用由不同的应用开发组加入到以存在的Cluster上，当应用的故障恢复将应用转移到另一个node上时，在那个node上没有足够的资源去运行所有的应用，性能将降低，或者应用瘫痪。; 大多数Cluster顾问和喜爱者也得承认“Cluster”周期性的进行测试。然而，他们没有指出在“off-peak”时间的测试时没有意义的！你怎样知道在峰值期的用户负载没有在线实现时，所有用户都可以登录。你不能在“off-peak”时间得到有效测试! “假如在峰值时间，测试引起停机， ！”4.6 故障处理与恢复在Cluster承诺中，没有涉及数据的一致性、完整性。没有任何硬件来查询瞬间的或中间的问题。Cluster是标准计算机网络环境，只有可以“package”的应用能够重启动。大部分功能，如通信中间件，以及其它“封装”的软件采用内存数据库，不能受Cluster保护。而在Stratus上 所有软件得到保护！当Volume Groups或Logical Volumes进行结构上的修改时，Cluster必须暂停。RAID可使你随时增加磁盘，但应用却不能利用这附加空间的便利条件，除非这个“package”重新启动！当package作结构上的修改时，此package必须暂停。这包括新的程序、新的逻辑卷，或IP资源。当某个package失败，在node上退离，此package将自动失效于返回该node，除非由Cluster管理员手工采用sysadmin命令去改变（logic: 你不希望应用返回到正在维护服务的node）。如果在修复系统之后，没有人去重置“allow”设置，那将会怎样？没有任何package可以恢复到该node上。在典型的维护服务强制下，这种情况有时会发生的。最终此package在此失败，而无法恢复到任何node上。在故障恢复出现后，与性能相关的又是怎样？在node崩溃后，Cluster就不再有那麽多的CPU核资源了。必须配置足够多的node以预留这些额外处理的资源。 在应用实施Cluster脚本程序后，它是否可以无变动的移植到另一种硬件平台上？（C语言代码可以移植，而脚本程序就不可能了）。怎样理解对“开放系统”应用的需求？理解应用系统采用“驻留内存数据库”的含义。Oracle，Informix 以及Sybase都不是驻留内存数据库，而是基于此磁盘技术来组织公司信息。这些软件工具包含了许多内存驻留的指针和索引，这些指针和索引在硬件崩溃的情况下将会丢失或者遭到破坏。然而，这些软件一般都具有重建和交易重运行的功能，这样在硬件崩溃以后，可以重新构造数据库。这些工具需要时间来执行恢复处理（应用是停顿的），而且不承诺保证数据的完整性和一致性。 “驻留内存数据库”实际上是存储在内存中的、而不是磁盘中的“重要”数据。对于采用此技术的应用来说，这是内存驻留“形态”的表，它记录了当前在系统上处理的每一笔in-flight交易的状态。对银行应用来说，每一笔正在处理的金融交易都有一个“纪录”。对电信应用来说， 由服务器系统处理的每个过程中的每一次呼叫多有一个“纪录”。华尔街应用同样也透内存驻留数据。OpenView NNM 维护着大量的在网络上每个设备地状态表。正是这些Cluster切换不能恢复的内存驻留数据使Cluster不能保护正在流动的交易。4.7 应用系统故障恢复周期 如果故障恢复脚本程序不正常工作怎麽办？现在应用运行停止了，而在远程进行问题的确定及应用重启动将是一个很严肃的问题。即使脚本程序正常工作，故障恢复及故障还原将会维持多长时间？如果由于系统崩溃而出现故障恢复，那末，数据的恢复将会持续几分钟，几小时，甚至几天。上图示意了一个典型的故障期间，在Stratus与Cluster集群系统上应用系统不同的表现。一般来说，应用系统总的恢复等待时间由四大因素构成，即：Total recovery time= Basic system recovery time+ Database recovery time+ Network recovery time+ Application recovery timeBasic system recovery time是可以从Cluster系统供应商得到承诺的。然而，其余的三项是由应用的规模，资源使用的技巧决定的，是不定因素。无法得到肯定的承诺。而且在故障恢复期间，系统性能明显降低。因而，客户所承担的应用停顿所带来的风险是不可预测的。在Stratus容错服务器环境下，应用是不会存在产生等待恢复的停顿发生。4.8 Windows 2003可靠性增值功能 ftServer利用其独特的硬件体系结构，提供了若干增值功能，进一步完善了Windows 2003可靠性和可用性。l Online dump在Windows 2003发生崩溃后，ftServer立即可从一个CPU重启动，使关键应用立即投入生产。与此同时，另一个冗余CPU保持内存状态数据，并在线将故障状态转存至磁盘，以供调试和诊断。这个功能即可使应用即刻投入运行，又可提供诊断问题的资料。这种功能在亦通用服务器体系结构为基础的Cluster集群系统上是做不到的。l 快速重Stratus ftMemory提供预先定义内存段，使得当系统崩溃后的重启动期间，此定义的内存段数据保持不被刷新，从而重要数据、上下文生成数据、以及较大的驱动程序维持在定义的内存段，减少重启动时间，并保护了重要数据。保护重要数据，特别是对那些以来上下文生成的数据，以及保留大驱动程序在内存中驻留即可最小化停机时间，加快重启动时间；又可以保护交易的完整性。在Cluster集群系统环境中使无法保护现场数据，从而保护交易的完整一致性。l 管理通信板FtServer配置运行环境独立于Windows 2003的冗余管理通信板。即使在ftServer处于停机状态，仍然可以透过管理通信板做到远程的系统启动及维护。4.9 系统维护 Cluster集群系统是一个复杂的环境，对系统管理员提出了额外的更高的技术水准要求。Cluster技术人员是昂贵的。Cluster技术的使用要求维护员对网络、系统、应用、故障及解决要有清晰、准确的了解。潜在客户或者要为昂贵的顾问咨询付出代价，或者需要培训内部技术人员。而且，对维护员的依赖给企业带来潜在的风险。例如医院或公共安全部门是没有足够的支付能力将他们留住。由于Cluster技术的使用，企业被迫依赖足够的，稳定的、长期的技术支持。而在Stratus容错技术环境下，维护员仅需要标准单机环境的维护技术水准就可胜任。4.10 Service如果你的潜在客户具有多个场点的系统，这将意味着只有Stratus可以为所有场点提供完全一致的、高质量的服务和支持。l Stratus自公司成立起，就把客户服务列为公司文化宗旨之一。Stratus的先进服务机制已嵌入到其硬件体系结构之中。Stratus Service Network SSN，这种服务器在检测到故障，自动通知Stratus客户服务中心的主动性、自动性服务机制一直为其它硬件供应商追求的水准。l 借助Stratus提供的基于互联网技术的eCAC页面界面，客户可以透明的访问驻留在Stratus客户服务中心的客户服务数据库资料。客户可以清楚的了解自ftServer安装以来系统历史纪录，Stratus客户服务中心工程师诊断、处理、解决故障请求，以及当前系统服务状态的服务全过程。其他的厂商是否在服务与支持上具备关键性应用的主导思想？是否能提供Stratus所能提供的服务标准？4.11 Total Cost of Onwership 总成本核算企业的发展在于追求持续的利润最大化。而建立的生命周期总成本核算上的系统评估将是采纳服务器系统平台的基础。系统在开发建设规划时能定量的指定出成本，同时，系统投入运行后，可以预测以后的维护成本，并将此成本控制到最小。在项目系统的有效生命周期总成本有以下几点组成：投资成本：硬件投资成本；单机硬件容错，不消耗CPU效能，投资均用于应用系统；软件投资成本：数据库仅需单机版本，不需要并行版本，节省版本及维护开支；操作系统仅需单机安装，不需要双机均要安装。开发成本：系统开发成本单机系统的开发技术成本，人工成本，设备成本及开发环境成本均较Cluster结构的应用系统的开发成本大大降低。系统测试成本系统功能测试，模拟故障测试，故障恢复测试均只需在单机系统结构下进行，较Cluster系统的测试无论从时间上，系统测试条件的准备上还是测试的难度均大大减低，从而大大减低其测试成本。在Cluster集群系统上，除了正常的软件测试之外，还需反复测试针对移植故障所编写的脚本程序，验证脚本程序可以诊缺的执行故障切换和恢复。由于脚本程序的设计依赖于对故障的认知，以及整个系统环境的配置定义，所以在配置有所便动时，还要重新编写脚本程序或重新测试脚本程序的诊缺性。运行成本：运行速度成本硬件容错的同步内存保护方式可以保证应用系统使用共享内存编程方式大大提高系统运行速度。减少为达到同样的响应速度需要选择更高档次的服务器及大硬盘资源的成本。系统升级成本硬件升级，系统软件升级，应用系统升级均只需考虑单机设备，单版本的升级成本。系统停机成本这也是Stratus ftServer最大的、又无法量化的优势之一。应用系统的停顿意味着效益的降低、收入的减少、善后工作的损耗、成本与投入，对Cluster集群来讲，这是无法避免的问题。Cluster集群系统故障处理依赖于面向已知故障的脚本程序，当出现未知的或意料之外的故障时