张家界化工机械网

当前的位置是:主页 >> 化工机械

印刷控制应用程序故障切换的速度

时间:2021-08-18 来源网站:张家界化工机械网

印刷控制应用程序故障切换的速度

可以采取哪些步骤来确保最快速地实现故障切换?

如果确实发生了一个故障并造成应用程序被移动到(故障切换到)另一节点,应用程序可以采取多种措施来缩短恢复应用程序并使之运行所需要的时间。本节讨论下列主题:

复制非数据文件系统

使用原始卷

评估 JFS 的使用

使数据丢失最少

使用可重新启动的事务

使用检查点

多服务器设计

复制数据站点的设计

复制非数据文件系统

非数据文件系统应该进行复制而不是共享。应用程序数据本身只能有一个副本。它放在一组运行此应用程序的系统可以访问的磁盘上。故障切换后,如果这些数据磁盘是文件系统,则它们必须经过文件系统恢复 (fsck) 后,数据才能被访问。为减少恢复所用的时间,应尽量缩小这些文件系统,从而加快恢复速度。因此,最好不要在数据文件系统上存放可以复制的数据。例如,各个系统上都应放置应用程序可执行文件的副本,而不是把可执行文件的副本放在共享的文件系统上。此外,如果需要的话,复制应用程序可执行文件使其接受滚动升级。

使用原始卷

如果应用程序使用数据,请使用原始卷,而不是文件系统。原始卷不需要文件系统的 fsck,从而消除了故障切换期间潜在的冗长步骤。

评估 JFS 的使用

如果必须使用文件系统,则与 HFS 相比,JFS 在文件系统恢复时的速度明显快得多。不过,JFS 的性能可能会因应用程序而异。

使数据丢失最少

尽量减少发生计划外中断时丢失的数据量。发生故障时,不可避免地要丢失一些数据。但是,建议采取一定的措施尽量减少将丢失的数据量。下面将具体进行解释。

尽量避免使用基于内存的数据并使其数量最小化

发生故障时,内存中的任何数据(内存中上下文)都会丢失。除非内存中的数据可以轻易地通过重新计算得出,否则应用程序的设计应当尽量使基于内存的数据量最小化。当应用程序在备用节点上重新启动时,它必须重新计算或从磁盘中重新读取所有需放在内存中的信息。

估算故障切换速度的一种方法是,计算在普通系统上重新引导后,应用程序需要花多长时间启动。应用程序是否立即启动?是否必须通过许多步骤,最终用户才能连接到应用程序?理想状态下,应用程序能够快速启动而无须重新初始化内存中的数据结构或表。

从性能角度看,数据应该保存在内存中而不是写入磁盘。不过,应权衡数据丢失带来的危险与将数据置入磁盘对性能的影响这两者的利弊得失。

从共享磁盘读入内存,尔后作为只读数据使用的数据可以保存在内存中,而无须担心丢失这些数据。

让日志保持较小

某些数据库允许日志缓存在内存中,以增强联机性能。当然,在发生故障时,所有正在进行的事务都会丢失。不过,尽量减小内存中日志的大小,可以减少出现故障时丢失的已完成事务的数据量。

将磁盘上日志文件保持较小,可以更频繁地归档或复制日志,从而减少发生灾难时数据丢失的风险。当然,在联机性能和日志大小之间,存在权衡利弊的问题。

消除对本地数据的需求

如有可能,应消除对本地数据的需求。在一个三层的客户端/服务器环境中,中间层通常没有数据(也就是说,没有特定于客户端或需要修改的数据)。此“应用程序服务器”层,可以提供更高级别的可用性、负载平衡及故障切换能力。不过,这种情况要求所有数据都存储在客户端(第一层)或数据库(第三层)上。

使用可重新启动的事务

事务必须是可重新启动的,这样服务器出现故障且应用程序在另一系统上重新启动时,客户端才不必重新进入或回退事务。换句话说,如果事务过程中发生了故障,应该不需要从头再重新启动。这一能力使应用程序更为健壮,并且降低了用户觉察到故障切换的可能性。

一个常见的示例是打印作业。打印机应用程序通常对作业进行调度。打印作业完成后,调度程序转至下一项作业。但是,如果系统在打印较长作业(比如打印工资单需三小时)的过程中死机,那么系统恢复后会出现何种情况?作业是从头开始,重新打印所有的工资单,还是从上次中断处开始,调度程序是否会认为作业已经完成,而不再打印尚未打印的工资单?高可用性环境中的正确行为应是从上次中断处重新开始,确保每个人都得到一份工资单,并且只有一份。

另一个示例是在某个应用程序环境中,一个职员正在输入一个新员工的有关数据。假定该应用程序要求员工编号是唯一的,而在输入了新员工的姓名和编号后发生了故障。既然故障发生前已经输入了员工的编号,应用程序是否会拒绝重新输入员工的编号?它是否会要求首先删除已输入的部分信息?在高可用性环境中,应用程序较适当的行为应是允许此职员轻松地重新开始该项,或允许此职员继续输入下一个数据项。

使用检查点

将应用程序设计为可以用检查点记录复杂的事务。在用户看来非常简单的一项事务,实际上会分成多项数据库事务。尽管此问题关系到的是可重新启动的事务,但这里还是建议在客户端的本地记录进程,以便使被系统故障中断的事务能在故障切换后得以完成。

例如,假定使用的应用程序正在计算 PI。在原来的系统上,应用程序已经计算到了第 1,000 个小数,但应用程序尚未把任何数据写入磁盘。就在此刻,节点崩溃了。应用程序在另一个节点上重新启动,但要从头开始。应用程序必须重新计算那 1,000 个小数。但是,如果应用程序已定期将小数写入磁盘,则应用程序将会从中断处重新启动。

平衡检查点频率和性能

平衡检查点频率和性能很重要。在磁盘上使用检查点的代价是其对性能的影响。显然,如果过度频繁地使用检查点,应用程序就会变慢;如果使用检查点的频率不足,在发生故障切换后要花较长时间才能使应用程序恢复到当前状态。理想的情况是,最终用户应该能够决定使用检查点的频率。应用程序应提供可定制的参数,以便最终用户可以调节检查点的频率。

多服务器设计

如果使用多个处于活动状态的服务器,多个服务点就可以为客户端提供相对透明的服务。不过,这种功能要求客户端有一定的智能,以了解多服务器的相关信息,并且具有查询这些服务器地址的优先权。它还要求客户端能访问发生故障的服务器上的数据或复制的数据。

例如,不是让某个应用程序在出现故障时切换到另一个系统,而是要考虑使用两个系统来运行这个应用程序。在第一个系统出现故障后,第二个系统就接管第一个系统的工作。这就省去了应用程序启动的时间。设计这类体系结构有很多方法,这类设计也涉及到很多问题。不过,除给出一些示例外,本文将不讨论有关细节。

最简单的方法是让两个应用程序以主/从关系运行,其中从应用程序只是主应用程序的热备用程序。当主应用程序出现故障时,第二个系统上的从应用程序仍需要判断数据处于什么状态(也就是说,还会发生数据恢复)。但是,这样可以省去派生应用程序以及进行初始启动的时间。

另一种可能是拥有两个处于活动状态的应用程序。比如有两个应用程序服务器都在伺服一个数据库。客户端的一半连接到第一个应用程序服务器上,另一半连接到第二个应用程序服务器上。如果一个服务器出现故障,那么所有的客户端都连到剩下的那个应用程序服务器上。

复制数据站点的设计

复制数据站点对快速地实现故障切换和灾难恢复都有帮助。有了复制的数据,数据磁盘就不在系统间共享,也就不需要进行数据恢复。这样就加快了恢复的速度。不过,复制数据可能会影响性能。复制数据有很多方法,应用程序设计人员应对此进行全面的研究。

很多标准数据库产品都向客户端应用程序提供透明的数据复制功能。将应用程序设计为使用标准数据库后,最终用户就可以决定是否需要进行数据复制了。

来源: CA800搜索

声明:

本文来源于网络版权归原作者所有,仅供大家共同分享学习,如作者认为涉及侵权,请与我们联系,我们核实后立即删除。