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%，平均每年非计划（意外）停机时间超过4~5小时的可用性相比，用客户获得极大的稳定性。

3.2 无故障恢复时间

系统所有关键部件均为冗余配置。冗余部件时钟同步运行相同指令。保证即使在硬件出现故障时，其冗余部件仍然保持继续运行，从而保证当前交易的处理，应用不会因此而停顿和数据丢失。其它方案下，应用需要等待计算机系统的故障恢复，数据库的恢复，网络联接的恢复以及应用的恢复。

3.3 无内存数据丢失

Stratus独特的冗余硬件结构不但保证磁盘静态数据的完整性，而且保证内存数据的完整性。从而保证交易的完整一致性。而其它解决方案使无法做到的。在故障恢复期间，当前交易和内存数据将要丢失。

3.4 标准Windows 2003兼容性

Stratus ftServer支持标准的Windows 2003 AdvancedServer操作系统环境。保持应用二进制兼容。标准Windows 2003下运行的软件无需任何需该即可运行在ftServer容错平台上。

3.5 Windows 2003可靠性增值

Stratus ftServer利用其独特的冗余结构和容错技术，改进和完善了Windows 2003的可靠性和稳定性。

;  强化驱动

为加强可靠性而设计的Stratus强化驱动不但可以实时检测和隔离故障部件，而且可以检测和隔离不良驱动的内存越界写操作，防止造成系统严重后果。

;  在线转存

在Windows 2003发生崩溃后，ftServer立即可从一个CPU重启动，使关键应用立即投入生产。与此同时，另一个冗余CPU保持内存状态数据，并在线将故障状态转存至磁盘，以供调试和诊断。

;  快速重启动

StratusftMemory提供预先定义内存段，使得当系统崩溃后的重启动期间，此定义的内存段数据保持不被刷新，从而重要数据、上下文生成数据、以及较大的驱动程序维持在定义的内存段，减少重启动时间，并保护了重要数据。

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 Ownership

l  先进的可维护性

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或LogicalVolumes进行结构上的修改时，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 time

Basic system recovery time是可以从Cluster系统供应商得到承诺的。然而，其余的三项是由应用的规模，资源使用的技巧决定的，是不定因素。无法得到肯定的承诺。而且在故障恢复期间，系统性能明显降低。因而，客户所承担的应用停顿所带来的风险是不可预测的。在Stratus容错服务器环境下，应用是不会存在产生等待恢复的停顿发生。

4.8 Windows 2003可靠性增值功能

ftServer利用其独特的硬件体系结构，提供了若干增值功能，进一步完善了Windows 2003可靠性和可用性。

l  Online dump

在Windows 2003发生崩溃后，ftServer立即可从一个CPU重启动，使关键应用立即投入生产。与此同时，另一个冗余CPU保持内存状态数据，并在线将故障状态转存至磁盘，以供调试和诊断。

这个功能即可使应用即刻投入运行，又可提供诊断问题的资料。这种功能在亦通用服务器体系结构为基础的Cluster集群系统上是做不到的。

l  快速重StratusftMemory提供预先定义内存段，使得当系统崩溃后的重启动期间，此定义的内存段数据保持不被刷新，从而重要数据、上下文生成数据、以及较大的驱动程序维持在定义的内存段，减少重启动时间，并保护了重要数据。

保护重要数据，特别是对那些以来上下文生成的数据，以及保留大驱动程序在内存中驻留即可最小化停机时间，加快重启动时间；又可以保护交易的完整性。

在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集群系统上，除了正常的软件测试之外，还需反复测试针对移植故障所编写的脚本程序，验证脚本程序可以诊缺的执行故障切换和恢复。由于脚本程序的设计依赖于对故障的认知，以及整个系统环境的配置定义，所以在配置有所便动时，还要重新编写脚本程序或重新测试脚本程序的诊缺性。

运行成本：

运行速度成本—硬件容错的同步内存保护方式可以保证应用系统使用共享内存编程方式大大提高系统运行速度。减少为达到同样的响应速度需要选择更高档次的服务器及大硬盘资源的成本。

系统升级成本—硬件升级，系统软件升级，应用系统升级均只需考虑单机设备，单版本的升级成本。

系统停机成本—这也是StratusftServer最大的、又无法量化的优势之一。应用系统的停顿意味着效益的降低、收入的减少、善后工作的损耗、成本与投入，对Cluster集群来讲，这是无法避免的问题。Cluster集群系统故障处理依赖于面向已知故障的脚本程序，当出现未知的或意料之外的故障时，仍存在系统无法恢复的风险。

维护成本：

系统维护成本—由于单机结构容错且远程联机维护，大大节省了服务器硬件维护成本。由于单机的系统软件配置，其维护容易且维护难度及成本大大低于Cluster系统软件维护。应用系统升级维护不会受Cluster结构的复杂性约束，其维护升级成本减低。由于无论从硬件到软件的维护升级均不需特别训练的人员承担，所以，系统维护人员技术成本费用低。

4.12 解决方案比较综述

综上所述，Stratus具有Cluster集群系统无法比拟的优势。

5. 典型比较案例

下面是ftSever2700与一套HP DL 380（类似于IBM3650)集群之间实际测试的差距。在两套系统上同时运行Windows 2008及SQL2008，由相同的客户端软件去访问同一数据库。由人工触发系统故障，集中观察了发生故障时两套系统的切换时间以及是否有数据丢失的情况发生。具体结果如下：

由上述结果可见在ftServer上没有任何的切换时间以及数据的丢失，而在集群系统中则产生了58秒的切换时间和5行的丢失数据。需要强调的是，测试用的SQL脚本是非常简单的，仅有4行语句。在实际环境当中所运行的程序远比此脚本复杂得多，所以万一发生故障时所需的切换时间远不止58秒，丢失的数据也远远大于5行。在关键部门的应用当中，这是致命的和不可接受的。

注解：以上测试使用StratusftServer 2700与对应的Cluster产品的比较。